Begin oktober sprak ik op de STARwest conferentie in San Diego. Het onderwerp was testtechnieken. Een dankbaar maar ook riskant onderwerp. Dankbaar, omdat je er niet over uitgesproken raakt. Hoe moeten we technieken gebruiken, wat zijn de verschillen tussen de technieken, zijn ze een vloek of een zegen? Elke tester heeft wel te maken met testtechnieken en er zijn eigen ideeën bij. Vanwege deze betrokkenheid is het ook een gevaarlijk onderwerp. Er zijn testers die de theorie erg serieus nemen, en als je tijdens een presentatie iets verkeerd zegt vliegen de referenties naar de onderbouwende literatuur door de lucht. Ikzelf geloof dat je je technieken goed moet kennen, maar dat je bij de toepassing niet moet verstarren door de theorie. Gebruik ze, en doe dat zodat je je voordeel bieden. Van mij mag je dan regels overtreden. Een beetje testtechnieken? Alles mag! dus, maar gebruik ze.
De presentatie ging over hoe we de technieken kunnen gebruiken. Een acroniem stond hierbij centraal; TBYDWTFIP. Ervaren testers herkenen hierin meteen het acroniem voor “The bugs you don’t want to find in production”. Testen kan gezien worden als activiteit waar we op zoek gaan naar fouten. Maar weten we wel, waar we onze zoektocht op moeten richten? Vaak denk ik dat we erg vanuit de specificaties redeneren en vergeten aan onze gebruikers en operationeel managers te vragen welke problemen of fouten ze straks echt niet in productie willen hebben.
Testtechnieken helpen ons gericht naar de applicatie te kijken, en elke techniek is gespecialiseerd in het vinden van een bepaalt type fouten. Met BVA vind je in principe geen fouten in de toestandsovergangen en met State testing geen fouten in de input validatie. Als we weten welke fouten onze belanghebbende niet in productie willen vinden, weten we wat ons te doen staat. Ze vinden voordat we live gaan. Door gericht die ontwerptechnieken kiezen die ons helpen deze te vinden vergroten we onze slagingskans.
Om gericht testtechnieken te kiezen is het belangrijk gevoel te hebben voor welke fouten met welke technieken gevonden kunnen worden. Om dit te bevorderen liet ik tijdens de presentatie drie probleem-rapporten zien met de opdracht ” Vertel me welke techniek gebruikt zou kunnen zijn om deze fout te vinden”. Geloof het of niet maar ik heb zelden een zaal met 127 mensen zo stil gezien. Blijkbaar is de vraag moeilijker dan ik dacht. Of was het toeval? Onderstaand toon ik jullie dezelfde probleem-rapporten. Doe jij het beter?
Als je het antwoord weet, laat dan gerust onderaan deze pagina een reactie achter. Ik ben benieuwd naar de eensgezindheid of diversiteit in de antwoorden. Succes!
Nice one! :-) hope I have them correct..(without the reference books at hand).
I would ‘guess’:
1.state transition diagram or tree/node technique
2. Boundary value analysis
3. Data combination technique or pairwise testing
Curious towards other answers … Probably will cause ‘ow..that was it-response’
He Derk-Jan,
even uit het blote hoofd denk ik aan het volgende:
1. Status overgangstesten
2. Grenswaarde analyse / equivalentie klasse
3. Beslissingstabel / Elementaire vergelijkingstest
Ik kan me levendig voorstellen dat er een diversiteit aan antwoorden gaat komen.
Het is misschien saai maar ik heb ongeveer het zelfde lijstje:
1: State transion
2: Grenswaarde\boundary value
3: Data combinatie
De 3e was wel het ‘oh ja’ moment.
Daarbij was ik niet op tree/node en pairwise gekomen. (In ieder geval niet tot dat ik het hier zag).
Venster 1:
Ik zou eenvoudig de beslistabel gebruiken. Deze beslistabel zou dan specifiek zich kunnen richten op de acties bij status overgangen. Wordt de juiste actie uitgevoerd.
Je kunt dit natuurlijk doen door een state diagram te maken en de techniek gegevenscyclustest erop los te laten.
Venster 2:
Dataflowtest lijkt mij het meest passend.
Venster 3:
Datacombinatietest
Hoi DJ,
Ik heb niet naar de andere inzender gekeken en zou zeggen deze:
1. Proces Cyclus Test (maar met DataFlow vind je ‘m ook).
2. Grenswaardetest
3. Beslistabeltest, waarbij een vrij lage coverage (condition coverage) al volstaat vermoed ik.
Groet, Egbert
In real-life is er waarschijnlijk iets meer informatie en kan ik zo maar een andere techniek kiezen. Het is natuurlijk ook afhankelijk van waar de risico’s liggen en hoe zwaar er getest moet worden. Welke test zitten we in? FAT, GAT of misschien een systeemtest? Hoe lang hebben we om te testen en testen we met ‘normale gebruikers’ of testen we met onafhankelijke testers? Ook dat bepaald uiteindelijk welke techniek ik zou kiezen.
Op basis van de probleem rapporten hierboven zou ik zeggen: “state transition voor het eerste screenshot, en decision tree voor de volgende 2 screenshots.”
What if I’m wrong? I have to check my books….
TBYDWTIP? hey, je vergeet de F
toegepaste techniek: kon TIP niet plaatsen
Ik zou zeggen:
1. state transition (mis in de beschrijving informatie over de gebruikersrechten)
2. grenswaarde analyse
3. elementaire vergelijkingstest
Derk-Jan suggereert een vraag waar geen antwoord is.
Geen van deze bugs vind je met formele [test]technieken, als niet eerst scherp is beschreven hoe de gewenste reactie mag/moet zijn.
Waarom zou je een nieuwe bug niet mogen sluiten? Dat is puur een keuze die je maakt, en de keuze bepaalt of “system reaction” een bug is. Zo ook de anderen.
De enige “techniek” die alle genoemde bugs vindt, is expert-testing.
He Lisa, je hebt gelijk, gelukkig in de titel wel goed gedaan. Ik krijg leuke reacties, ook via de mail. Bv “Ik ben een testmanager en ken geen technieken” en “dit zijn fouten die je toevallig tegen moet komen, niet zoeken”. Dit zijn reacties die mij verrassen
Ik ga voor deze:
1) state testing
2) BVA/GWA
3) ECT/ EVT