Als alle testen geen defecten meer aantonen

Als alle testen op bedrijfskritische situaties correct door het systeem worden behandeld

Als de manager van de organisatie waar het nieuwe systeem wordt ingevoerd, het systeem accepteert

Als er in het systeem (geautomatiseerde) en in de organisatie organisatorische maatregelen zijn getroffen om defecten te identificeren

Tijdens deze fase workshops met gebruikers organiseren, zoals RAD- en JAD-sessies, zoals SCRUM

Een kort-cyclische aanpak van analyse, ontwerp en validatie

Prototyping

Formele acceptatie door gebruikers van opgeleverde resultaten

Een technische systeem-test is een test die specifiek op alle technische aspecten van het informatiesysteem is gericht; dat vraagt een specifieke opzet van de systeem-testen

Een technische systeem-test biedt de beheerders de mogelijkheid om op de implementatie-aspecten van het systeem te testen; het is dus een specifieke beheerders-test

Het gaat om het doel van de diverse systeem-testen; de technische systeem-test definieert dat specifieke doel

De test op de specifieke technische eisen aan een informatiesysteem zijn niet opgenomen in de niet-functionele eisen/requirements; daar moet echter wel op worden getest

Ja, die wordt later verantwoordelijk voor het gebruik van het informatiesysteem; die is immers integraal verantwoordelijk voor de bedrijfsprocessen van zijn organisatie

Ja, die is immers de opdrachtgever voor het project en moet het ontwikkelde systeem accepteren

Nee, de opdrachtgever heeft altijd het laatste woord bij de acceptatie-test; hij is immers de opdrachtgever voor het ontwikkelen van het nieuwe systeem

Nee, dat hangt van de relatie tussen de opdrachtgever en de betreffende manager af; in de governance van het project waarin het nieuwe systeem is ontwikkeld, zou dat moeten zijn beschreven

Het organiseren van workshops waarin gebruikers en ontwikkelaars samen de analyse uitvoeren (bijvoorbeeld in de vorm van SCRUM-sessies)

De analyse en het definiëren van de specificaties te organiseren in kort-cyclische fasen

De gebruikers formeel de opgestelde specificaties te laten accorderen

Prototyping

Je voert een gestructureerde validatie van het ontwerp uit

Je laat de gebruikers het ontwerp valideren (en niet de ontwerpers)

Je simuleert de werking van het informatiesysteem en toetst zowel de specificaties als het ontwerp

Gebruikers zijn meestal erg gemotiveerd om ‘de game’ voor deze techniek ‘te spelen’; ze zijn dus extra gemotiveerd om goed te testen hetgeen de kwaliteit van deze test bevordert

Testen c.q. valideren moet je altijd doen; dit ondanks het principe van “gedegen uitvoeren bepaalt 80% van de kwaliteit”

Structured walkthrough’s zijn een integraal onderdeel van agile wijze van systeemontwikkeling

Structured walkthrough’s bieden een andere benadering van valideren, dan tijdens analyse en ontwerp; ze werken dus ‘aanvullend’

Bij de analyses en het ontwerp kunnen fouten worden gemaakt; de structured walkthrough biedt de laatste kans om deze fouten alsnog te vinden

Een programma-test wordt alleen door de programmeur die het programma heeft geschreven, uitgevoerd

Een programma-test wordt alleen op het betreffende programma uitgevoerd; de samenwerking met andere programma’s wordt dus niet getest

Een programma-test wordt niet in de productie-omgeving (of een kopie daarvan) uitgevoerd

Een programma-test betreft alleen een validatie van het programma, maar wel op de gestelde functionele en niet-functionele eisen/requirements, c.q. het functioneel ontwerp van dat programma

Ja, dit betreft een component-test gericht op complexiteitsreductie, en past in een gestructureerde opbouw van alle testen om uiteindelijk de totale kwaliteit van het systeem te valideren

Ja, het testen van bijvoorbeeld een server vraagt om specifieke expertise

Nee, je kan beter een integratie-test uitvoeren op de combinatie ‘server plus applicatie’

Nee, bijvoorbeeld een server wordt met standaard serversoftware opgebouwd; apart testen is dus niet zinvol

Ja, dat is precies het doel van integratie-testen

Ja, je wilt immers de samenwerking tussen de diverse componenten van het informatiesysteem testen

Nee, een integratie-test kan je beter partieel opbouwen vanwege complexiteitsreductie

Nee, dat hangt af van het doel van de uit te voeren integratie-test

De grafentheorie ondersteunt je bij het opzetten van volledige testen

De grafentheorie ondersteunt je bij het identificeren van kritische testgevallen

De grafentheorie borgt een theoretisch verantwoorde opzet van testen

De grafentheorie ondersteunt het opstellen van testscenario’s

Een regressie-test focust op de functionaliteit van de niet-gewijzigde componenten; die niet-gewijzigde componenten moeten nog steeds correct werken

Een regressie-test biedt een andere insteek op het testen van de gewijzigde component en de correcte werking met de niet-gewijzigde componenten

Regressie-testen passen in het kader van de complexiteitsreductie van testen

Je toont met een regressie-test aan de gebruikers aan dat een wijziging in een component correct is gerealiseerd

Ja, door het laten uitvoeren van testen in de eerdere fase van systeemontwikkeling, zou je moeten borgen dat de acceptatie van het systeem door de beheerders al is geregeld

Ja, en feitelijk vertragend voor de invoering van het systeem; bovendien hebben de beheerders – als het goed is – hun eisen al voor het ontwerp gesteld, en moeten de ontwikkelaars borgen dat die eisen tijdens de bouw worden gerealiseerd

Ja, beheerders hebben al in de eerdere fasen van de systeemontwikkeling hun eisen kunnen stellen; vervolgens is het niet de beheerder maar de opdrachtgever verantwoordelijk te stellen voor de acceptatie van het nieuwe systeem

Nee, beheerders worden verantwoordelijk voor het beheer van het systeem tijdens de fase ‘Gebruik en beheer’; zij moeten ook de kans krijgen om het uiteindelijke systeem te accepteren

Het zodanig inrichten van de acceptatie-test dat wordt gevalideerd dat het nieuwe systeem aan alle gestelde eisen voldoet

Het zodanig inrichten van de acceptatie-test dat wordt gevalideerd dat het nieuwe systeem alle bedrijfskritische situaties correct afhandelt

Dat de reeds uitgevoerde testen (tijdens de vorige fasen) aantonen dat het systeem aan alle daaraan gestelde eisen voldoet

Dat de manager van de afdeling waar het nieuwe systeem in gebruik wordt genomen, en de beheerders, het systeem accepteren

Dat het systeem conform specificaties werkt na de invoering en de installatie van de technische componenten op de technische infrastructuur

Dat de conversie correct is verlopen

Dat de gebruikers optimaal kunnen werken met het systeem (dat nu pas voor gebruik beschikbaar is)

Dat de invoeringsactiviteiten correct en volledig zijn uitgevoerd

Ja, je maakt dan gebruik van eerder geaccepteerde testen, zowel qua uitvoering als qua kwaliteit daarvan

Ja, maar dan alleen de testen die relevant zijn voor het valideren van het uitgevoerde onder

Nee, de tijdens de fase systeemontwikkeling ontwikkelde test-sets zijn teveel en leiden tot een te grote werklast om tijdens de fase ‘Beheer’ te gebruiken

Nee, je zit in de fase ‘Beheer’ in een andere fase dan systeemontwikkeling, en dat vraagt om andere testen

Het benoemen van de doelen van de uit te voeren testen

Het benoemen van de uit te voeren testen

Het benoemen van een gestructureerd en op het doel afgestemd testtraject

Het reduceren van de complexiteit van het testtraject