Exploratory testen. Een introductie

Exploratory testen Een introductie

Algemene informatie voor medewerkers van SYSQA B.V.

Datum : 16-05-2004 Status : defintief Opgesteld door : SYSQA BV

Organisatie Titel Onderwerp

SYSQA B.V. Introductie Exploratory testen

Pagina Versie Datum

2 van 12 1.0 16-06-2004

Inhoudsopgave 1

Inleiding ..........................................................................................................................3

2

Exploratory testing ......................................................................................................4 2.1 2.2 2.3 2.4 2.5

3

Wat is het?.............................................................................................................. 4 Wanneer wel of niet toepassen.............................................................................. 5 De Exploratory Tester ............................................................................................ 7 Vergelijking met ET ................................................................................................ 8 Belang van ET........................................................................................................ 8

Sessoin based testmanagement .............................................................................9 3.1 3.2 3.3

Inleiding .................................................................................................................. 9 Testpunten.............................................................................................................. 9 Testsessie ............................................................................................................ 10

Versiebeheer Versie Datum Opmerkingen 0.1 24-05-2004 Eerste opzet nav tekst internet 1.0 16-05-2004 Management Review

Almere © 2004

Quality Assurance in ICT



Pagina Versie Datum

3 van 12 1.0 16-06-2004

1 Inleiding De laatste jaren zien we steeds meer iteratieve systeemontwikkelingtrajecten, met namen als RAD, DSDM of extreme programming. Dit geeft een probleem voor testen:als er al systeemdocumentatie is, komt deze meestal pas laat beschikbaar. De tester heeft nu een probleem om testgevallen af te leiden, want hoe kan hij/zij nu beoordelen of er voldoende testgevallen zijn én of de uitkomst van een testgeval goed of fout is. In VS is de trend voor iteratieve systeemontwikkeling al langer aan de gang en is een school van testers opgestaan die beperkte systeemdocumentatie niet meer ziet als iets ongewenst, maar als iets vanzelfsprekends. Exploratory testing of explorerend testen (verder afgekort als ET) komt uit deze school van denken voort. Hoewel ET als begrip sinds de jaren '90 bestaat in de Verenigde Staten, is het pas sinds 2002 naar Europa komen overwaaien. Het fascinerende aan ET is dat het veel discussie oproept tussen voor- en tegenstanders. Zo is een greep uit de mogelijke stellingen: <> Hoe verhoudt ET zich tot een gestructureerde testmethodiek als TMap? Dit document legt ET uit en beschrijft het inpassen van ET in TMap. Met deze inpassing kunnen de in paragraaf 2.2 genoemde toepassingsmogelijkheden van ET binnen Tmap ingepast worden. Anders gezegd: de flexibiliteit van ET en de structuur van het testen volgens TMap worden hiermee gecombineerd. Bij de lezer wordt kennis van TMap bekend verondersteld. Het document start met een beknopte uitleg van wat ET is, wat de toepassingsmogelijkheden zijn en wat de toegevoegde waarde is van ET. Hoofdstuk 3 beschrijft een specifieke variant van ET, namelijk ET in een op sessies gebaseerde aanpak (ET/SB). Hierbij wordt het testproces beheerst door het uitvoeren van het testen in kortdurende sessies. De reden om hiervoor te kiezen is dat ET hiermee beter beheersbaar wordt en daardoor makkelijker inpasbaar is in een gestructureerd testproces.

Almere © 2004




Pagina Versie Datum

4 van 12 1.0 16-06-2004

Exploratory testing

0.0 Wat is het? Exploratory testing (ET) is een begrip dat enkele jaren geleden is ontstaan in de VS. Cem Kaner [Kaner 99] is de eerste die de term heeft gebruikt om aan te geven dat dit meer is dan zomaar ad-hoc testen. James Bach komt de eer toe om exploratory testing als begrip en aanpak neergezet en beschreven te hebben. Waar gaat exploratory testing over? Volgens Bach [Bach expl] is ET: "simultaneous learning, test design and test execution, in other words any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests". Dit betekent dat de tester steeds een stukje van de te testen applicatie verkent (exploreert), nadenkt over wat getest moet of kan worden (testontwerp) en dit vervolgens ook doet (testuitvoering). Hierbij doet de tester gelijk al weer nieuwe kennis op over de applicatie, denkt na over wat vervolgens getest moet worden, voert dit uit, enzovoort. Het ontwerpen en vervolgens uitvoeren van de tests gebeurt daarmee zeer dicht op elkaar. Om het belang van dit voortschrijdend inzicht duidelijk te maken, maakt Bach de analogie met een legpuzzel. Bij een legpuzzel begin je eerst met een ruwe sortering van de stukjes bijvoorbeeld hoeken, zijkanten en overig, daarna op kleuren, etc. Het passen van stukjes aan elkaar is een testgeval ("past het wel, past het niet"). Het lukt nooit om in één keer alle stukjes op zijn plaats te krijgen, dus alle testgevallen te bedenken, je begint met enkele stukjes en probeert dat brok steeds uit te breiden met nieuwe stukjes. <> Wanneer je als tester een testscript uitvoert, stuit je nogal eens op "verdacht" systeemgedrag, dat wil zeggen dat het systeem er anders uitziet of anders reageert dan je verwacht. Dit hoeft niet per se opgeschreven te zijn in het testscript, je verwachting hoeft zelfs niet gegrond te zijn op bepaalde systeemdocumenten. Wanneer je dit verdachte gedrag nader onderzoekt, ben je explorerend aan het testen. De meeste testers zullen hierbij echter roepen dat dit vanzelfsprekend is en niet het gevoel hebben dat ze ET toepassen. Daarmee is het dus niet zozeer de vraag of iemand explorerend test, maar meer in welke mate hij of zij dit doet. Dit maakt het lastig om te onderscheiden wat nu wel of niet ET te noemen. Kaner geeft daarom een scherpere definitie van ET, namelijk: "any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests, and where the following conditions apply: • the tester is not required to use or follow any particular test materials or procedures • the tester is not required to produce materials or procedures that enable test re-use by another tester or management review of the details of the work done". [Bach expl] Hierbij hoeft de tester dus geen regels of procedures te volgen en ook geen bewijs van het testen op te leveren. In de praktijk krijgt de tester maar zelden zoveel vrijheid. Met deze scherpere definitie is het weliswaar makkelijker om aan te geven wat we wel en niet ET noemen, het feit blijft dat we zijn opgescheept met verschillende definities, de ene zeer breed en de andere zeer smal. In dit document kiezen we voor een middenweg en hebben we het over ET wanneer het bedenken en uitvoeren van tests vrijwel samenvalt en de testgevallen niet van tevoren worden opgeschreven. ET als op zichzelf staande testvorm heeft wel degelijk structuur, ook al is die vrij los. Zo kent ET doelstellingen, taken en op te leveren producten. Een tester krijgt telkens een doelstelling mee, bijvoorbeeld onderzoek de werking van een bepaald scherm. Door doelstellingen goed te kiezen, wordt voorkomen dat testers dezelfde zaken dubbel testen en worden de meest Almere © 2004




Pagina Versie Datum

5 van 12 1.0 16-06-2004

risicovolle aspecten getest. Gedurende een bepaald aantal uren exploreert de tester dan het betreffende deel van het systeem, bijvoorbeeld de functionaliteit van het scherm, en registreert de geconstateerde bevindingen. Afhankelijk van de gewenste mate van bewijs kan bijvoorbeeld ook nog worden vastgelegd wat getest is in de beschikbare tijd, maar als het even kan wordt de hoeveelheid testdocumentatie zo klein mogelijk gehouden. Onderkende taken in dit proces zijn bijvoorbeeld het kiezen van doelstellingen, het uitvoeren en loggen van tests en het vastleggen van bevindingen. Bevindingenrapporten, testverslagen en voortgangsoverzichten zijn mogelijke producten. ET wordt nogal eens geassocieerd met testen zonder formele testbasis zoals een functioneel ontwerp. Dit hoeft echter niet zo te zijn. Het is heel goed mogelijk om ET toe te passen bij een goed beschreven systeem. Wel is het zo dat ET zich goed leent om te gebruiken wanneer er geen beschreven testbasis is. ET legt minder nadruk op een beschreven testbasis en meer op andere manieren om te beoordelen of het testobject voldoet, onder andere door de applicatie te leren kennen tijdens de testuitvoering. In tegenstelling tot TMap kent ET voor andere aspecten van testen, zoals een testplan en strategie, beheer, infrastructuur, organisatie en rapportage, geen richtlijnen of voorschriften. Dit is ook een reden waarom het voor de hand ligt om ET met TMap te combineren.

0.0 Wanneer wel of niet toepassen Er zijn omstandigheden wanneer ET beter wel of niet kan worden toegepast. Bach steltdat ET toegepast kan worden wanneer de volgende test niet voor de hand ligt, of wanneer je meer wilt doen dan de voor de hand liggende tests ("beyond the obvious"). Volgens hem is dat overigens meestal het geval.

0.0.0 Wel toepassen Sterke punten van ET zijn dat het bij de volgende situaties toegepast kan worden: • Wanneer ervaren testers met materiekennis beschikbaar zijn waarin men voldoende vertrouwen heeft op goede testkwaliteit; Testers die niet hoeven te documenteren wat ze doen is goedkoper dan wanneer ze wel moeten documenteren. Keerzijdes van de keuze zijn een groter risico op onvoldoende kwaliteit van de test, langere doorlooptijd van testen op het kritieke pad van het project en minder overdraagbaarheid en herbruikbaarheid van de tests (waardoor mogelijk hogere testkosten op lange termijn). De randvoorwaarden en keerzijdes worden verderop in deze paragraaf toegelicht. (Bach, impliciet) • Wanneer zo goedkoop mogelijk testen verreweg belangrijkste overweging is; Omdat dit meestal het geval is, zou ET vrijwel altijd toepasbaar zijn. Deze stelling gaat echter niet op. ET kan ingezet worden vanuit kostenoogpunt, maar er zijn enkele belangrijke randvoorwaarden: men dient goede en ervaren testers te hebben (zie ook paragraaf 2.3) én ook volledig vertrouwen in hen te hebben en niet de dekking en diepgang van testen aangetoond te willen zien. Keerzijdes van de keuze zijn een groter risico op onvoldoende kwaliteit van de test, langere doorlooptijd van testen op het kritieke pad van het project en minder overdraagbaarheid en herbruikbaarheid van de tests (waardoor mogelijk hogere testkosten op lange termijn). De randvoorwaarden en keerzijdes worden verderop in deze paragraaf toegelicht. (Bach, impliciet) • Wanneer er onvoldoende gedocumenteerde testbasis is; Door explorerend bezig te zijn, krijgt de tester vanzelf een beeld van het testobject. Omdat ET nadruk legt op de inventiviteit en intuïtie van de tester, is het meer geschikt om te gebruiken wanneer er weinig systeemdocumentatie is of wanneer de documentatie sterk afwijkt (lees: verouderd is) ten opzichte van de gewenste werking van het systeem. Dit maakt ET ook heel geschikt bij "documentatie-lichte" en "agile" Almere © 2004



•


Pagina Versie Datum

6 van 12 1.0 16-06-2004

methodieken als Extreme programming, DSDM of Rational Unified Process. Aandachtspunten hierbij zijn dat het ontbreken van systeemdocumentatie een risico is dat men met het inzetten van ET niet kan opheffen en dat de testers naast testkennis dan ook moeten beschikken over veel systeem- en materiekennis omdat een referentiekader in de vorm van systeemdocumentatie ontbreekt. (Bach, impliciet) Als aanvulling op testen aan de hand van scripts, om creatief testen te stimuleren; Vaak zitten de fouten in de software op onverwachte plaatsen én zitten de fouten dicht bij elkaar (clustering). Formele testspedficatietechnieken zijn gericht op het vinden van bepaalde typen fouten. Het gebruik van deze technieken kan gezien worden als een filter waar de software doorheen gaat. Met elk filter, lees: testspecificatietechniek, worden bepaalde typen fouten gevonden. De vraag blijft dan of er no.g veel fouten van andere typen achterblijven en hoe ernstig deze zijn. ET kan hier aanvullend inzicht in geven. Door de informele aard van ET is deze minder gericht op bepaalde typen fouten. Bij een fout die met ET is gevonden, moet de tester zich daarom goed afvragen of de fout uniek en op zichzelf staand is of dat de fout ook op allerlei andere plaatsen kan voorkomen of een cluster aangeeft. Hierdoor is ET een goede aanvulling op de formelere technieken (Bach). Onderstaande figuur maakt dit duidelijk

<> •

Als er geen tijd beschikbaar is om de tests voor te bereiden. Hoewel geen ideale situatie en één waarbij vanuit testen zeker de risico's aangegeven moeten worden, komt dit toch regelmatig voor. ET is dan een middel om in de korte resterende tijd het maximale aan testen te bereiken en op korte termijn globaal inzicht in de productkwaliteit te verkrijgen. Stel, je hebt 8 uur om een bepaalde groep van functies of schermen te testen. Wat levert dan meer op: 8 uur lang de functies op allerlei explorerende manieren doorlopen, met gebruikmaking van checklists, en in te zoomen wanneer iets er verdacht uitziet of de helft van de tijd besteden om een aantal testgevallen op herbruikbare en controleerbare manier te specificeren en die in de resterende tijd nauwgezet te gaan uitvoeren? (Bach)

Andere omstandigheden wanneer ET goed toegepast kan worden is wanneer de testers snel willen leren hoe het systeem werkt, om de kwaliteit van andermans testen met een korte test te beoordelen, om een snelle eerste indruk te krijgen van de kwaliteit van de applicatie of om een specifieke bevinding of mogelijke foutbron te onderzoeken. (Bach)

0.0.0 Niet toepassen Dit wil niet zeggen dat wanneer aan één van bovenstaande situaties wordt voldaan, ET gelijk dé oplossing is. Er zijn namelijk ook diverse situaties wanneer het toepassen van ET minder geschikt is: • Wanneer hogere eisen aan de aantoonbaarheid/verslaglegging van testen worden gesteld, bijvoorbeeld door opgelegde standaards; Het ET proces is moeilijker beheersbaar, meetbaar en toetsbaar (auditable) omdat geen testgevallen worden gedefinieerd en aan de logging van tests lage eisen worden gesteld. Deze testaanpak voldoet bijvoorbeeld niet aan standaards van FDA, Nederlandse Bank of FAA. Je weet niet goed wat de tester gaat doen en hoe hij/zij het gaat doen. Achteraf is nauwelijks controleerbaar wat er gedaan is. Dit kan consequenties hebben, wanneer later een juridisch geschil ontstaat over de softwarekwaliteit. (Bach, maar met de opmerking niet te snel toe te geven aan de auditors) • Bij kritische functionaliteit, waarvan het falen grote schade kan veroorzaken; Omdat weinig wordt vastgelegd, leunt ET erg op het vertrouwen in de individuele tester. De potentiële schade wanneer dit vertrouwen ongegrond blijkt te zijn, kan zo Almere © 2004



• • • •

•


Pagina Versie Datum

7 van 12 1.0 16-06-2004

groot zijn voor bepaalde systemen of delen van een systeem, dat de organisatie dit risico niet kan of wil nemen. (Bach). Voor onervaren testers, omdat deze de kennis en ervaring missen om zonder expliciete ondersteuning door een techniek goede testgevallen te bedenken; Wanneer testgevallen door een andere tester dan de bedenker of door een testtool moeten kunnen worden uitgevoerd moeten zijn of herbruikbaar moeten zijn, bijvoorbeeld in later onderhoud; Wanneer er geen rechtstreekse feedback van testuitvoering is, zodat de testresultaten niet direct beschikbaar zijn, bijvoorbeeld bij nachtelijke testruns van batchprogrammatuur; (Bach). Bij testen die veel voorbereiding vergen zoals het testen van ingewikkelde berekeningen, performancetesten, het testen van beveiliging of testen van usability; Deze voorbereidingen, die zowel kunnen slaan op testgevallen, testuitgangsbestanden, referentieta bellen als testomgevingen, kunnen beter ruim vóór testuitvoering plaatsvinden om niet onnodig veel tijd kwijt te zijn tijdens testuitvoering. (Bach geeft dit argument in algemene zijn: wanneer de feedback-loop zwak, lang, langzaam of kostbaar is) Wanneer het testen zo kort mogelijk op het kritieke pad van het project moet zitten; De tester begint bij ET laat, pas nadat het testobject is opgeleverd en doet zowel ontwerp als uitvoering van tests tijdens deze fase. Meestal is dit op het kritieke pad van het project. Dit vergt meer doorlooptijd dan wanneer de tests al vóór oplevering van het testobject ontworpen zijn in de vorm van testscripts of checklists. Van belang hierbij is dan wel dat de testscripts voorbereid kunnen worden, dus dat er een voldoende gedocumenteerde testbasis is. Overigens moet gezegd worden dat het onderhouden van testscripts tijdens de testuitvoering meestal ook extra tijd kost, waardoor het tijdsvoordeel van testscript voor het kritieke pad enigszins vermindert.

Of ET zinvol toegepast kan worden hangt dus af van diverse factoren. Het is aan de testmanager om dit goed te beoordelen.

0.0 De Exploratory Tester Wat voor persoon is de exploratory tester? Om ter plekke goede tests te bedenken en uit te voeren, zijn goede testers nodig. ET stelt hoge eisen aan de tester. Belangrijke eigenschappen zijn: • Testontwerper; met grondige kennis van principes als testdekking en testtechnieken. De tester kan deze kennis gebruiken zonder dat hij of zij het nodig heeft om testgevallen van tevoren uit te schrijven. • Focus houden op productrisico's; De tester kan hoofd- en bijzaak goed scheiden, dat wil zeggen wat wel of niet van belang is om te testen. Uitgangspunt hierbij is dat de tester denkt vanuit risico's van het product voor de organisatie. Grote risico's moeten goed getest, kleine risico's kunnen licht of niet getest. • Goede observator; Niet alleen het direct te controleren resultaat wordt bekeken, maar de tester is ook alert op allerlei indirecte zaken. Voorbeelden hiervan zijn verkeerde plek, vorm of kleur van buttons op de schermen terwijl je de invoervelden controleert, onderlinge inconsistenties tussen de schermen of velden, etc. • Kritisch en vasthoudend; De tester heeft een goed gevoel wat wel of geen bevinding is en kan ook goed omgaan met de ongedocumenteerde eisen aan een systeem. Zij laat zich niet zomaar afschepen met opmerkingen als "omdat het nergens beschreven staat, hebben we het maar op deze manier opgelost". Almere © 2004



•

•


Pagina Versie Datum

8 van 12 1.0 16-06-2004

Creatief in het bedenken van tests; Wat kan er fout gaan en hoe test ik dat? De tester hanteert hierbij vuistregels ("fouten in een systeem zitten meestal geclusterd"), richtlijnen, checklists, etc. Bij geconstateerde bevindingen probeert de tester te generaliseren, d.w.z. op welke plaatsen zou de bevinding nog meer kunnen zitten. Grote (toegang tot) kennis en ervaring; Het gaat hier in algemene zin om de kennis en ervaring die bij het testen nodig is. Dit betreft dus zowel kennis van en ervaring met testen zelf als ook bijvoorbeeld het systeem en de organisatie. Deze kennis en ervaring hoeven niet noodzakelijk tussen de oren van de tester te zitten, maar kan ook toegankelijk zijn via collega's, literatuur, testmagazines, conferentiematerialen, internetsites, nieuwsgroepen of discussiefora.

Deze hoge eisen aan de tester betekenen dat ET met name ingezet wordt in testteams waarin professionele testers participeren, in de praktijk zijn dit de systeem- en acceptatietesten.

0.0 Vergelijking met ET Het op ongestructureerde manier zoeken naar fouten in het systeem wordt al jaren toegepast als een nuttige aanvulling op gestructureerde testtechnieken en staat bekend als error guessing. Het feit dat ET wel degelijk structuur kent met doelstellingen, taken en op te leveren producten, en nog meer wanneer het in sessies wordt georganiseerd (zie ook hoofdstuk 3), geeft grote voordelen boven error guessing in termen van effectiviteit, beheerbaarheid en communiceerbaarheid.

0.0 Belang van ET ET ligt daarmee als het ware tussen gestructureerd testen en ongestructureerd testen in (figuur 3). Deze combinatie biedt ook de grootste meerwaarde ten opzichte van het ongestructureerde error guessing. ET moet daarom als een waardevolle toevoeging aan het testarsenaal worden beschouwd. <> Zoals in paragraaf 2.2 aangegeven zijn er diverse toepassingsmogelijkheden waar ET tot zijn recht komt. Een andere belangrijke waarde van ET ligt ook in een stuk bewustwording. Testers zijn vaak getraind in het opstellen en uitvoeren van testgevallen volgens bepaalde technieken. De tester leert in dergelijke trainingen niet om te testen op basis van onvoldoende documentatie, op basis van intuïtie, of om explorerend te testen. Het gevaar hiervan is dat dit uiteindelijk inflexibele testers oplevert, die niet of nauwelijks uit het keurslijf van testscripts kunnen komen. Expliciete aandacht voor ET voorkomt dit en stimuleert het opleiden van creatieve, kritische en toch flexibele testers.

Almere © 2004




Pagina Versie Datum

9 van 12 1.0 16-06-2004

2 Sessoin based testmanagement 0.0 Inleiding Als groot nadeel van ET wordt vaak de onbeheersbaarheid genoemd. Om dit te ondervangen, heeft Bach session based testmanagement als aanpak geïntroduceerd [Bach SB]. Lyndsay [Lyndsay 2002] heeft dit in meer detail uitgewerkt. Bij op sessies gebaseerd testen wordt het systeem verdeeld in een aantal testpunten. Een aantal testers onder leiding van een testmanager test de testpunten in zogenaamde testsessies. De tester kan tijdens de sessie nieuwe testpunten bedenken, deze worden dan toegevoegd aan de lijst met testpunten. Door sessies en testpunten te administreren, kan de voortgang van het testproces bewaakt worden en kan de buitenwereld inzicht krijgen in wat er in het testen is gebeurd en nog moet gebeuren.

0.0 Testpunten Een testpunt kan van alles zijn, denk bijvoorbeeld aan een functie, scherm, menu, gebruikershandleiding, usability of performance, of heel algemeen een gebied met mogelijke instabiliteit zoals geheugengebruik. Andere termen waaronder deze punten bekend staan zijn missies of charters [Bach SB]. In TMap-termen moet een testpunt gezien worden als het testen van een kwaliteitsattribuut met een bepaalde scope, bijvoorbeeld de gebruikersvriendelijkheid van een aantal invoerschermen, de performance van de rapportagefunctie of de functionele werking van de menustructuur. Criteria die aan een testpunt gesteld worden, zijn: • het stelt een eenheid van werk voor, die ongeveer tussen een half en 4 uur in beslag neemt. • het is onafhankelijk testbaar, oftewel een tester kan met elk testpunt beginnen of eindigen. Hiermee is een testpunt dus iets anders dan een testgeval of een testscript. Bij het testen van een testpunt worden vaak diverse testgevallen uitgevoerd. Een testpunt wordt gekoppeld aan een risico door het geven van een risico-indicatie (laag/middel/hoog). Het testen van de testpunten wordt op basis van deze risico's geprioriteerd door degenen met de hoogste indicaties het eerst te doen. Hiermee wordt voorkomen dat de testers zich een te groot deel van hun tijd bezighouden met het testen van onbelangrijke zaken, een mogelijk probleem bij ET. Als testbasis voor de testpunten kunnen dienen documentatie als requirements of functioneel ontwerp, maar ook memos, interviews, requirementsessies, informele gesprekjes, internationale of bedrijfsstandaards, concurrerende systemen, ervaringen van vorige testteams, "gezond verstand", et cetera. Het uitvoeren van de test van een testpunt gebeurt explorerend. De tester begint met te leren over het betreffende aspect van de applicatie, bijvoorbeeld door het bedienen van de applicatie en/of het raadplegen van documentatie. Vervolgens bedenkt hij/zij wat getest kan worden en voert dit uit. De resultaten brengen de tester mogelijk weer op nieuwe ideeën wat te testen, enzovoort. Zolang dit binnen de scope van het testpunt past en binnen de tijd, wordt dit getest. Is dit niet het geval, dan kan de tester een nieuw testpunt aanmaken, want de lijst met testpunten is dynamisch. Ook bij een bevinding of een nieuwe release kan de tester besluiten om een nieuw testpunt toe te voegen. Zo op het eerste gezicht geeft dit een indruk van onbeheersbaarheid. Aan de andere kant is het wel de praktijk van testen dat voortschrijdend inzicht leidt tot nieuwe tests. Door de prioriteiten te bewaken kan het proces beheersbaar worden gehouden. Bij het volgen van de voortgang kan bijvoorbeeld blijken dat tijdens de eerste tests veel nieuwe testpunten worden ingediend. Ook kan blijken dat het testen van een Almere © 2004




Pagina Versie Datum

10 van 12 1.0 16-06-2004

testpunt meer tijd kost dan begroot. De keus is dan om meer resources in te zetten, uit te lopen in de tijd of bepaalde testpunten met lagere prioriteit niet of minder te testen. Dit wijkt niet af van standaard testmanagement, ofwel business as usual. Het is aan te bevelen om het indienen en omschrijven van een testpunt de verantwoordelijkheid te maken van de individuele testers en niet van de testmanager. Dit vergroot de betrokkenheid van de testers bij het testproces. De volgende informatie wordt vastgelegd van een testpunt: • unieke identificatie, • titel, • opsteller, • omschrijving, • risico indicatie (bijvoorbeeld laag/middel/hoog), • documentatie referenties, plannings- en voortgangsinformatie: (per release opnieuw initialiseren) • geschatte tijd, • tijd besteed, • compleet, • tijd nog nodig (= tijd besteed / (compleet) - tijd besteed)

0.0 Testsessie Testpunten worden getest in testsessies. Een sessie is een tijdsperiode, normaal gesproken tussen een half en vier uur, waarin de tester ononderbroken één of meer testpunten kan testen. Tijdens testen legt de tester zijn/haar acties (op hoofdlijnen) vast in de vorm van notities op het sessieblad. Hierdoor zijn de tests tot op zekere hoogte herbruikbaar, omdat de hertest van een testpunt kan plaatsvinden op basis van de aantekeningen van de vorige sessie(s). Het is dan de keuze van de tester om de vorige sessie zoveel mogelijk te herhalen óf juist om andere variaties te proberen. In tegenstelling tot de testpunten die meerdere keren getest kunnen worden, zijn de testsessies eenmalig: je begint en eindigt een sessie op een bepaald moment. Wanneer je op een later moment een testpunt opnieuw moet testen, vindt dit plaats in een nieuwe sessie. Het voordeel van sessies is dat deze in de tijd begrensd zijn en daardoor beter beheersbaar. Overigens blijkt dat een 8-urige werkdag niet opgedeeld kan worden in bijvoorbeeld 4 testsessies van 2 uur. De ervaring [Bach SB] is dat testers een behoorlijk deel van hun tijd besteden aan niet-test activiteiten, zoals overleg, e-mail en coachingstaken. Bij het totale budget voor het testen moet hier dan nadrukkelijk rekening mee worden gehouden. Een sessie kan uitlopen, maar wordt liever niet over meerdere dagen verspreid omdat het de bedoeling is om ononderbroken te kunnen werken. In dat geval kan beter één van de bij de sessie horende testpunten naar een andere sessie worden overgeheveld. Na afloop van de sessie neemt de testmanager de sessie door met de tester in een zogenaamde debriefing. Deze debriefing dient meerdere doelen: • de tester coachen bij het exploratory testen; • beter risico's inschatten; • prioriteit van bevindingen vaststellen; • informatie via de testmanager verspreiden. Bach [Bach SB] stelt bij de debriefing de vragen aan de hand van het PROOF concept. PROOF staat hier voor Past, Results, Obstacles, Outlook, Feelings: wat gebeurde er in de

Almere © 2004




Pagina Versie Datum

11 van 12 1.0 16-06-2004

sessie (Past), wat is bereikt (Results), wat waren de obstakels om te testen (Obstacles), wat moet nog gebeuren (Outlook) en wat is het gevoel van de tester over de sessie (Feelings). Naast het bijwerken van de geteste testpunten wordt van een testsessie de volgende informatie vastgelegd: • unieke identificatie, • titel, • omschrijving, • inhoud (testpunten), • tester, • release, • datum/tijd, • notities, • gedane bevindingen.

Almere © 2004




Pagina Versie Datum

12 van 12 1.0 16-06-2004

3 Literatuurverwijzingen [Bach Expl] Bach, James, (2002) Exploratory testing explained, www.satisfice.com [Bach SB] Bach, Jonathan, (2000) Session-based test management, www.satisfice.com Veenendaal, Erik van, Exploratory testen: zinvol of onzin? Automatiseringsgids… Engelsma, Erwin, Organisaties die zweren bij Exploratory testen zijn scheefgegroeid. Automatiseringsgids … Schotanus, Chris, Exploratory testen: een uitstapje tijdens een busreis. Automatiseringsgids … Lith, Peter van, Exploratory testen zet vakmensen weer in de schijnwerpers, Automatiseringsgids … Sassenburg, Hans, Een ander doekje voor het bloeden, Automatiseringsgids … Henzen, Rob, Een eenzijdige benadering, Automatiseringsgids … Veenendaal, Erik van, Error-guessing is grootste gevaar. Automatiseringsgids … Laan, drs A.F.Th., Meer vragen dan antwoorden. Automatiseringsgids …

Almere © 2004


Exploratory testen. Een introductie

Recommend Documents