Requirements and Testing Flashcards

1
Q

Wat is het doel van een Procescyclus-test

A
  • Vaststellen of een nieuw (onderdeel van het) systeem werkt in combinatie met bestaande bedrijfsprocessen.
  • De omvang van het bedrijfsproces is niet relevant
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Waar ligt de focus bij een Procescyclus-test?

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Wat is de testbasis van een Procescyclus-Test?

A

Alle documentatie (van handleidingen / procedurebeschrijving tot en met use-cases en business rules)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Welke Foutsoorten zijn er binnen een Procescyclus-Test?

A
  • Organisatie van administratieve processen
  • Geautomatiseerde processen
  • Toekenning van autorisatie
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Noem één voordeel van een beslissingstabel.

A

Een decision table kan rechtstreeks in code vertaald worden.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Noem één nadeel van een beslissingstabel.

A

Het opstellen vergt (veel) oefening en tijd

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Wanneer is een beslissingstabel van toepassing?

A

Geschikt voor de analyse van complexe problemen met meervoudige condities en acties.
Functionele juistheid
Functionele volledigheid
Functionele geschiktheid

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Benoem de procedure van de beslissingstabel. (1tm6)

A
  1. Identificeerbaar condities en acties.
  2. Beslissingstabel opstellen.
  3. Beslissingstabel Vereenvoudigen.
  4. Logische testgevallen.
  5. fysieke testgevallen.
  6. Test uitvoeren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Waar moet een logisch Testgeval (LTG) aan voldoen

A
  • Voorwaarden voor input en output
  • Abstract en afleidbaar uit de documentatie
  • Geen concrete waarden
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Waar moet een fysiek testgeval (FTG) aan voldoen

A
  • Concreet en legt de echte testgevallen vast
  • fysiek testgeval per logisch testgeval
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Wat houdt een Equivalentie-klasse in?

A

Een equivalentieklasse is een verzameling van mogelijke invoerwaarden, die tot eenzelfde soort verwerking leiden.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Wat is de Achterliggende gedachten van een Equivalentie-klasse?

A

Meer testgevallen van dezelfde equivalentieklasse levert geen (substantiële) verbetering op van de vindkans van fouten.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Wat kun je aan tonen na het gebruik van een Equivalentie-klasse?

A
  • Functionele geschiktheid
  • Functionele juistheid
  • Beveiligbaarheid
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Wanneer is een Equivalentie-klasse van toepassing?

A
  • Invoercontroles, relatiecontroles
  • Complexe berekeningen
  • Functionele beslissingen
  • Autorisaties
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Wat is de Procedure om testgevallen op te stellen ?

A
  1. Test situaties analyseren.
  2. Logische testgevallen opstellen.
  3. fysieke testgevallen opstellen.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Waar staat OTAP voor?

A

Ontwikkelomgeving
Testomgeving
Acceptatieomgeving
Productieomgeving

Oftewel, een permanente testomgeving

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Waarom testen op infrastructuur?

A

Beperkte ondersteuning ‘oude’ producten
Hogere eisen aan de IT-infrastructuur
Optimalisatie, centralisatie, consolidatie van IT-componenten
Uitdragen innovatief karakter

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Hoe testen we infrastructuur?

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Uitleg over Planning van testen infrastructuur

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Wat is Exploratory testen?

A

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.

20
Q

Is Exploratory testing een Test techniek ?

A

Exploratory testing (verkennend testen) is geen testtechniek.
Het is een manier van denken over testen.

21
Q

Wat zijn de voordelen van Exploratory testing (ET)?

A
  • 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
22
Q

Wat zijn nadelen van Exploratory testing?

A

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

23
Q

Wat is het doel van een acceptatieplan?

A

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.

23
Q

Kwaliteit bepalen,
Validatie = ?
Verificatie = ?
Kwalificatie = ?

A

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.

24
Q

Welke 3 manieren zijn er om Identificatie aan te geven bij een eis?

A

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

25
Q

V-MODEL| Wat betekent requirements in het v-model, en wat is daar het product van?

A

Wat: Eisen van de klant worden opgehaald en vastgelegd.
Product: Programma van Eisen

26
Q

V-MODEL| Wat gebeurt er tijdens de acceptatiefase/Accepting Testing? (denk aan wat is het, wanneer ga je testen etc..)

A

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

27
Q

V-MODEL| Wat betekent System Specification in het v-model, en wat is daar het product van?

A

Wat: Architecten bedenken high level design van het systeem.
Product: Ontwerpdocument, inclusief hoog niveau architectuur

28
Q

V-MODEL| Wat gebeurt er tijdens de System Testing? (denk aan wat is het, wanneer ga je testen etc..)

A

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

29
Q

V-MODEL| Wat betekent System Specification in het v-model, en wat is daar het product van?

A

Wat: Architecten / programmeurs maken low level ontwerp.
Document: Ontwerpdocument(en) op detailniveau.

30
Q

V-MODEL| Wat gebeurt er tijdens de Integration Testing? (denk aan wat is het, wanneer ga je testen etc..)

A

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

31
Q

V-MODEL| Wat betekent Unit Design in het v-model, en wat is daar het product van?

A

Wat: Kleinste module die ontworpen wordt, vaak gedaan door de programmeur zelf of het ontwikkelteam.
Document: Uitgewerkte beschrijvingen van complexe stukken code (indien nodig).

32
Q

V-MODEL| Wat gebeurt er tijdens de Unit Testing? (denk aan wat is het, wanneer ga je testen etc..)

A

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

33
Q

Wat is de template van een user story?

A

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>

34
Q

Wat zijn Businessrequirements?

A

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?

35
Q

Wat zijn Gebruikersrequirements?

A

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?

36
Q

Wat zijn Systeemrequirements?

A

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?

37
Q

Noem verschillende elicitatiemethoden

A
  • Documenten
  • Bestaande systemen
  • Interview
  • Workshop
  • Taakanalyse/Observatie
  • Brainstorm creatie
  • Observatie
  • Dossiers en formulieren
38
Q

Wat zijn de 12 eisen van requirements?

A

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)

39
Q

Waaruit bestaat een use-casemodel en wat is het precies?

A

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.

40
Q

Welke 6 elementen bevat een use-case diagram?

A
  • Actor
  • Relatie
  • Use-case
  • Systeem(grens)
  • Include
  • Extend
41
Q

Kan er een relatie bestaan tussen 2 use-cases?

A

Nee, een relatie zit ALTIJD tussen een actor en een use-case

42
Q

Wat betekenen de include en extend bij use-case diagrammen

A

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.

43
Q

Wat betekenen de include en extend bij use-case diagrammen

A

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.

44
Q

Wat is en hoort bij een use-casebeschrijving?

A

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

45
Q

Hoeveel testgevallen maak je per use-casebeschrijving?

A

1 testgeval per beschreven scenario.

46
Q

Wat levert gestructureerd testen op?

A

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

47
Q

Er zijn 3 risicosoorten in de ict: Productrisico, Projectrisico en Bedrijfsprocesrisico. Beschrijf deze:

A

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).