Requirements and Testing Flashcards
Wat is het doel van een Procescyclus-test
- Vaststellen of een nieuw (onderdeel van het) systeem werkt in combinatie met bestaande bedrijfsprocessen.
- De omvang van het bedrijfsproces is niet relevant
Waar ligt de focus bij een Procescyclus-test?
De keten van activiteiten (een of meer processen) van het bedrijf, waar het systeem een onderdeel van is en met name de aansluiting van het systeem op de handmatige processen.
Wat is de testbasis van een Procescyclus-Test?
Alle documentatie (van handleidingen / procedurebeschrijving tot en met use-cases en business rules)
Welke Foutsoorten zijn er binnen een Procescyclus-Test?
- Organisatie van administratieve processen
- Geautomatiseerde processen
- Toekenning van autorisatie
Noem één voordeel van een beslissingstabel.
Een decision table kan rechtstreeks in code vertaald worden.
Noem één nadeel van een beslissingstabel.
Het opstellen vergt (veel) oefening en tijd
Wanneer is een beslissingstabel van toepassing?
Geschikt voor de analyse van complexe problemen met meervoudige condities en acties.
Functionele juistheid
Functionele volledigheid
Functionele geschiktheid
Benoem de procedure van de beslissingstabel. (1tm6)
- Identificeerbaar condities en acties.
- Beslissingstabel opstellen.
- Beslissingstabel Vereenvoudigen.
- Logische testgevallen.
- fysieke testgevallen.
- Test uitvoeren
Waar moet een logisch Testgeval (LTG) aan voldoen
- Voorwaarden voor input en output
- Abstract en afleidbaar uit de documentatie
- Geen concrete waarden
Waar moet een fysiek testgeval (FTG) aan voldoen
- Concreet en legt de echte testgevallen vast
- fysiek testgeval per logisch testgeval
Wat houdt een Equivalentie-klasse in?
Een equivalentieklasse is een verzameling van mogelijke invoerwaarden, die tot eenzelfde soort verwerking leiden.
Wat is de Achterliggende gedachten van een Equivalentie-klasse?
Meer testgevallen van dezelfde equivalentieklasse levert geen (substantiële) verbetering op van de vindkans van fouten.
Wat kun je aan tonen na het gebruik van een Equivalentie-klasse?
- Functionele geschiktheid
- Functionele juistheid
- Beveiligbaarheid
Wanneer is een Equivalentie-klasse van toepassing?
- Invoercontroles, relatiecontroles
- Complexe berekeningen
- Functionele beslissingen
- Autorisaties
Wat is de Procedure om testgevallen op te stellen ?
- Test situaties analyseren.
- Logische testgevallen opstellen.
- fysieke testgevallen opstellen.
Waar staat OTAP voor?
Ontwikkelomgeving
Testomgeving
Acceptatieomgeving
Productieomgeving
Oftewel, een permanente testomgeving
Waarom testen op infrastructuur?
Beperkte ondersteuning ‘oude’ producten
Hogere eisen aan de IT-infrastructuur
Optimalisatie, centralisatie, consolidatie van IT-componenten
Uitdragen innovatief karakter
Hoe testen we infrastructuur?
Structuur Tmap Infra:
Risk-based testen
Sturing van activiteiten op tijd, geld en kwaliteit
Structuur: zodat duidelijk is wat, door wie, wanneer en in welke volgorde wordt uitgevoerd.
Handvatten: zodat niet steeds opnieuw het wiel moet worden uitgevonden.
Sturing: sturing van testactiviteiten in het kader van tijd, geld en kwaliteit.
De vier essenties van TMap
1. TMap is gebaseerd op een Business Driven TestManagement (BDTM) aanpak.
2. TMap beschrijft een gestructureerd testproces.
3. TMap bevat een complete gereedschapskist.
4. TMap is een adaptieve testmethode. (aangepast aan de omstandigheid)
Uitleg over Planning van testen infrastructuur
Fase Planning (P):
1. Opstellen opdracht en verzamelen testdoelen
2. Bepalen risicoklasse
3. Bepalen testzwaarte
4. Toewijzen testontwerp technieken
Fase Beheer (B) :
Het primaire testproces zal zelden volgens plan worden uitgevoerd. Dus ook de uitvoering van dit testplan zal bewaakt en eventueel bijgestuurd moeten worden. Dit gebeurt in de fase Beheer.
Fase Inrichting en beheer infrastructuur (I):
De fase Inrichting en beheer infrastructuur heeft als doel om zorg te dragen voor de benodigde testinfrastructuur en middelen. Hierbij wordt onderscheid gemaakt tussen testomgevingen, testtools en werkplekken
Fase Voorbereiding (V):
In de fase Voorbereiding wordt de detailintake van de testbasis uitgevoerd. Het einddoel van deze fase is het kunnen beschikken over een, met de opdrachtgever van de test overeengekomen, testbasis die voldoende van kwaliteit is voor het ontwerpen van de tests.
Fase Specificatie (S):
Tijdens de fase Specificatie worden de benodigde tests en uitgangssituatie(s) gespecificeerd. Het doel is zoveel mogelijk voorbereid te hebben om de testuitvoering zo snel mogelijk te laten verlopen wanneer de ontwikkelaars het te testen product opleveren.
Fase Uitvoering (U):
Het doel van de fase Uitvoering is om inzicht te krijgen in de kwaliteit van het te testen product door het uitvoeren van de afgesproken tests.
Fase Afronding (A):
Met de gestructureerde testaanpak van TMap kan veel winst worden behaald in de herhaalbaarheid van het proces. Hierdoor kunnen producten, mits ze voldoen aan bepaalde eisen, weer hergebruikt worden in een volgende test.
Wat is Exploratory testen?
Exploratory testen van software is een stijl die de persoonlijke vrijheid en de verantwoordelijkheid van de individuele tester benadrukt door het werk voortdurend te optimaliseren met test-gerelateerd leren, testontwerp, testuitvoering en interpretatie van de testresultaten als elkaar ondersteunende activiteiten die parallel lopen gedurende het hele project.
Is Exploratory testing een Test techniek ?
Exploratory testing (verkennend testen) is geen testtechniek.
Het is een manier van denken over testen.
Wat zijn de voordelen van Exploratory testing (ET)?
- Deze test is nuttig wanneer vereiste documenten niet of slechts gedeeltelijk beschikbaar zijn
- Het omvat een onderzoeksproces dat helpt meer bugs te vinden dan normaal testen
- Ontdek bugs die normaal worden genegeerd door andere testtechnieken
- Helpt de verbeeldingskracht van testers uit te breiden door steeds meer testgevallen uit te voeren, wat uiteindelijk ook de productiviteit verbetert
- Dit testen gaat door tot in het kleinste deel van een applicatie en dekt alle vereisten
- Deze test omvat alle soorten tests en omvat verschillende scenario’s en cases
- Moedigt creativiteit en intuïtie aan
Genereren van nieuwe ideeën tijdens testuitvoering
Wat zijn nadelen van Exploratory testing?
De kwaliteit van testen hangt af van de vaardigheden van de tester
Beperking domeinkennis van de tester
Ongeschikt voor lange uitvoeringstijd
Het testteam heeft ervaren testers
Vroege iteratie is vereist
Er is een kritische toepassing
Nieuwe testers komen in het team
Wat is het doel van een acceptatieplan?
Een acceptatieplan zorgt voor een meetbare basis voor de acceptatie van het product.
Hierbij ligt de focus op het aantonen van de kwaliteit van de software.
Kwaliteit bepalen,
Validatie = ?
Verificatie = ?
Kwalificatie = ?
Validatie: is het juiste product gerealiseerd?
Doet het systeem wat de klant wil?
Afstemming met klant / opdrachtgever.
Controle of het juiste systeem is gemaakt
Verificatie: is het product op de juiste manier gerealiseerd?
Zijn alle eisen verwerkt?
Interne afstemming met het (ontwikkel)team.
Controle of het systeem juist is gemaakt.
Kwalificatie: voldoet het product aan normen, standaarden en (interne) afspraken?
Is het systeem niet in strijd is met wetten (bijv. avg) en voldoet aan standaarden.
Interne controle door het (ontwikkel)team.
Controle of het systeem voldoet aan normen en standaarden.
Welke 3 manieren zijn er om Identificatie aan te geven bij een eis?
Symbolisch ID (bijv. Login-001)
Databaserecord ID
Autokey, gegenereerd door de database (eventueel aangevuld met symbolisch id)
Dynamische nummering
Overnemen van de documentindeling aangevuld met volgnummer
Toepassen kruisverwijzingsfunctie van de tekstverwerker
V-MODEL| Wat betekent requirements in het v-model, en wat is daar het product van?
Wat: Eisen van de klant worden opgehaald en vastgelegd.
Product: Programma van Eisen
V-MODEL| Wat gebeurt er tijdens de acceptatiefase/Accepting Testing? (denk aan wat is het, wanneer ga je testen etc..)
Wat: Afronding van het project
Wanneer testcases beschrijven: Tijdens de requirements-fase
Wanneer testen: Aan het einde van het project
Hoe: Blackbox testen
Wie: Onafhankelijk testteam, vaak samen met de klant
Resultaat: Overdracht van het ontwikkelde product aan de klant
V-MODEL| Wat betekent System Specification in het v-model, en wat is daar het product van?
Wat: Architecten bedenken high level design van het systeem.
Product: Ontwerpdocument, inclusief hoog niveau architectuur
V-MODEL| Wat gebeurt er tijdens de System Testing? (denk aan wat is het, wanneer ga je testen etc..)
Wat: Het complete systeem testen (ookwel Alpha-testen genoemd).
Wanneer testcases beschrijven:Tijdens de Systeem Specificatie
Wanneer testen: Als alle losse onderdelen geïntegreerd zijn
Hoe: Blackbox testen
Wie: Onafhankelijk testteam
V-MODEL| Wat betekent System Specification in het v-model, en wat is daar het product van?
Wat: Architecten / programmeurs maken low level ontwerp.
Document: Ontwerpdocument(en) op detailniveau.
V-MODEL| Wat gebeurt er tijdens de Integration Testing? (denk aan wat is het, wanneer ga je testen etc..)
Wat: Werking van los geteste modules samen testen.
Wanneer testcases: Tijdens System Design & eerdere integratie testen.
Wanneer testen: Als losse onderdelen klaar zijn om samen getest te worden
Hoe: Meestal blackbox testen (soms grey of glass box)
Wie: Onafhankelijk testteam en/of integratie team
V-MODEL| Wat betekent Unit Design in het v-model, en wat is daar het product van?
Wat: Kleinste module die ontworpen wordt, vaak gedaan door de programmeur zelf of het ontwikkelteam.
Document: Uitgewerkte beschrijvingen van complexe stukken code (indien nodig).
V-MODEL| Wat gebeurt er tijdens de Unit Testing? (denk aan wat is het, wanneer ga je testen etc..)
Wat: Module los testen.
Wanneer testcases beschrijven: Tijdens Unit Design.
Wanneer testen: Tijdens ontwikkeling en als afronding van de module
Hoe: Meestal whitebox testen (soms grey of glass box)
Wie: Programmeur of collega programmeur
Wat is de template van een user story?
Als <rol> wil ik <activiteit> zodat <reden>
Als standhouder
wil ik bijhouden wie bij onze stand is geweest,
zodat ik later kan vragen of ze interesse hebben in meer informatie over ons bedrijf.</reden></activiteit></rol>
Wat zijn Businessrequirements?
De doelstellingen van de business. Deze requirements bepalen de scope en richting van de overige requirements. De businessrequirements geven antwoord op de waarom-vraag van het systeem: Waarom moet dit systeem gemaakt worden?
Wat zijn Gebruikersrequirements?
De doelen en taken die de eindgebruikers van het systeem moeten kunnen uitvoeren. De gebruikersrequirements geven antwoord op de wat- en de wie-vraag: Wie zijn de gebruikers en wat kunnen ze met het systeem doen?
Wat zijn Systeemrequirements?
Een systeemrequirement is een eis of beperking waaraan het systeem dient te voldoen om de business- en gebruikersrequirements te realiseren. De systeemrequirements geven antwoord op de wat-vraag en hoe-vraag van het systeem: Wat moet het systeem doen? Hoe moet het systeem werken om aan de bovenliggende requirements te voldoen?
Noem verschillende elicitatiemethoden
- Documenten
- Bestaande systemen
- Interview
- Workshop
- Taakanalyse/Observatie
- Brainstorm creatie
- Observatie
- Dossiers en formulieren
Wat zijn de 12 eisen van requirements?
Geïdentificeerd (unieke code)
Grammaticaal correct
Atomair (één issue)
Geen verboden woorden (niet meetbaar)
Geen ontwerpaspecten (button/knop/menu)
Uniform (indien nodig: woordenlijst)
Meetbaar
Onderling consistent
Geprioriteerd
Eigenaar
Geaccepteerd
Traceerbaar (waar gebruikt)
Waaruit bestaat een use-casemodel en wat is het precies?
Use-casemodel bestaat uit:
- 1 use-casediagram per (deel)systeem
- Per use-case in het diagram 1 use-casebeschrijving
Een use-casediagram geeft taken van de gebruikers weer, die door het systeem ondersteund worden.
Welke 6 elementen bevat een use-case diagram?
- Actor
- Relatie
- Use-case
- Systeem(grens)
- Include
- Extend
Kan er een relatie bestaan tussen 2 use-cases?
Nee, een relatie zit ALTIJD tussen een actor en een use-case
Wat betekenen de include en extend bij use-case diagrammen
Include relatie:
Wordt gebruikt als de (sub)use case altijd uitgevoerd moet worden.
Een include mag niet gebruikt worden om een hiërarchie / tijdsvolgorde aan te brengen tussen de use cases.
Extend relatie
Wordt gebruikt als de uitbreiding (andere use case) soms uitgevoerd wordt.
Bijvoorbeeld: De use-case “Excursies reserveren” wordt alleen uitgevoerd als de reizigers daar behoefte aan hebben.
Wat betekenen de include en extend bij use-case diagrammen
Include relatie:
Wordt gebruikt als de (sub)use case altijd uitgevoerd moet worden.
Een include mag niet gebruikt worden om een hiërarchie / tijdsvolgorde aan te brengen tussen de use cases.
Extend relatie
Wordt gebruikt als de uitbreiding (andere use case) soms uitgevoerd wordt.
Bijvoorbeeld: De use-case “Excursies reserveren” wordt alleen uitgevoerd als de reizigers daar behoefte aan hebben.
Wat is en hoort bij een use-casebeschrijving?
Code en naam van de use-case
(korte) Beschrijving van de taak
Actoren die de use-case kunnen uitvoeren
Precondities (optioneel)
Postcondities (verplicht)
Stappen (TCT -> 2 kollommen)
Hoofdscenario
Alternatieve scenario’s
Fout scenario’s
Hoeveel testgevallen maak je per use-casebeschrijving?
1 testgeval per beschreven scenario.
Wat levert gestructureerd testen op?
Tijdig inzicht in de kwaliteit van het systeem
Fouten worden in vroeg stadium opgespoord
Testproducten zijn herhaalbaar / herbruikbaar
Infra medewerkers worden mede-eigenaar van de op te leveren producten
Testinspanning beperkt door risk-based testen
Testproces is meetbaar en herleidbaar
Er zijn 3 risicosoorten in de ict: Productrisico, Projectrisico en Bedrijfsprocesrisico. Beschrijf deze:
Productrisico: Risico direct gerelateerd aan het product en heeft direct te maken met het te ontwikkelen product of het gebruik ervan. De productrisico’s vormen samen met de requirements de basis voor de teststrategie.
Bedrijfsprocesrisico: Speciaal soort productrisiso. Risico dat afbreuk doet aan het optimaal functioneren van een bedrijfsproces (bijv. bestellingen via pizza.nl komen niet aan bij de besteller).
Projectrisico: Risico gerelateerd aan het managen en beheersen van een project. Deze zijn tijdelijk van aard en bestaan na het project niet meer. Deze risico’s worden geanalyseerd en beschreven in projectdocumentatie (denk aan PvA en SWC).
