De best practices van software testen

Na jaren ervaring in het testvak heb ik mijn lessen geleerd. Al deze geleerde lessen wil ik graag delen met de “testcommunity” en daarom dacht ik dat dit de ideale plek was om wat best practices te delen met de lezers van Testnieuws.nl

Neem dit artikel in ogenschouw en bekijk wat je er mee kunt. Als eerste wil ik u meenemen naar het begin van een project, waar de mensen nog enthousiast zijn en vol moed om te beginnen aan een waaghalzerij die elke dag weer wordt herhaald in de praktijk van de ICT.

De planning
Om te beginnen wordt van je verlangd om een planning te maken voor het gehele testtraject. Bij het antwoorden op de vraag: “Hoeveel tijd gaat het testen kosten”, kun je nooit uitgaan van ervaringscijfers, gezien elk project compleet anders. Het standaard antwoord dat je zou moeten geven is dan: “Het testen kost 50% van de tijd die dit project nodig heeft om specificaties te schrijven en de sofware te ontwikkelen”. Over het algemeen zal men er van schrikken en je vragen om dat nader te specificeren. Dit doe je dan via een testplan.

Testplan
Een testplan maken is niet moeilijk. Je begint op de site www.tmap.net en daar download je de sjabloon voor een Master testplan. In dit sjabloon vul je zoveel mogelijk in van wat je al van het project weet. Het mooiste zou zijn als je een groot deel van het projectplan kunt kopiëren en plakken naar het testplan, zodat je goed aansluit op de manier van werken van de project manager. Hiermee heb je al gauw de helft van een testplan gevuld. Vervolgens vul je zoveel mogelijk de rest van het testplan in. Met wat creativiteit kom je dan heel ver.

Test coverage
Op een gegeven moment kom je bij het hoofdstuk “risico’s”. Dit is een overgewaardeerde aanpak die ongeveer op elke cursus over testen wordt gegeven. Het beste is om dit hoofdstuk er uit te halen en aan te geven dat het testen “een 100% coverage van de functionaliteiten biedt”. Je plaatst hiervoor de lijst van functionaliteiten. Deze haal je uit het projectplan of andere project documentatie.

Begroting & planning
Vervolgens kan je per functionaliteit een inschatting maken van hoe lang het duurt om testgevallen te schrijven en te testen. Die inschatting kan je doen door de eerder geschatte testtijd te nemen en dat te verdelen over de functionaliteiten.

En dan verder: Hoeveel weken mag het project duren? Er is vast een globale planning. Aan de hand daarvan kan je aangeven hoeveel testers je nodig hebt in die tijd. Dus als een project 3 maanden mag duren (60 werkdagen) en je heb geschat dat je 240 dagen nodig hebt om te testen, dan zal je een team moeten hebben van vier testers voor dat project.
Start datum van het maken van testgevallen en het uitvoeren van de tests kan je het best op goed geluk schatten. Gezien elk project toch schuift hoef je niet al teveel tijd te besteden om dit uit te zoeken.

Dan nog even een lijst van testtooltjes invullen die je wilt gaan gebruiken (MS Excel, MS-Word, bevindingentool) en dan is je plan klaar!
Als je nu nog hoofdstukken overhoudt in het testplan kan je die gewoon verwijderen.
Vervolgens kan het plan voor akkoord naar de projectmanager. Bij elkaar moet je ongeveer twee weken rekenen voor het maken van dit plan.

Wachten op de specificaties
Na het maken van het plan zal je moeten wachten tot de ontwerpen klaar zijn en kan je een periode van rust inlassen. Want zonder goede gedetailleerde specificaties kan je niet beginnen aan een testontwerp. In deze tijd kun je de “George Constanza” methode toepassen om er toch uit te zien alsof je werkt. George Constanza is dat “kleine dikke mannetje” uit de serie “Seinfeld”. Deze methode is simpel en effectief: Moeilijk kijken en voor je uitstaren. Af en toe wat variatie hierin door heen en weer te lopen door het kantoor met je hand tegen je kin alsof je nadenkt. Naar buiten staren is ook goed, maar blijf moeilijk kijken. Hierdoor lijkt het alsof je druk bezig bent.

Reviewen van ontwerpen
Als men vraagt of je de specificaties wilt reviewen, neem dat dan met genoegen aan. Vooral eerste versies van deze documentatie zijn echt lachen! Je kunt zoveel fouten vinden dat het gewoon vissen in een vijver vol met vis is. Maak een lijst in MS-Word en gebruik een mooi review sjabloon, zodat het er professioneel uitziet. Elke opmerking maak je natuurlijk van een hoge prioriteit. Let expliciet op spelfouten en meldt deze ook zo snel mogelijk terug aan de ontwerpers.

Het uitwerken van de testgevallen
Als de specificaties af zijn en naar jouw smaak, dan kan je beginnen met het maken van het testontwerp. Gebruik het liefst, voor de consistentie, één testtechniek voor alles. Ik raad de beslissingstabellen test aan, want deze kan je echt overal voor gebruiken en je krijgt daarmee de meeste testgevallen. Het is goed om een tussenrapportage te maken hoeveel testgevallen je hebt per functionaliteit en hoeveel in totaal. Een projectmanager ziet het liefst zoveel mogelijk testgevallen.

Testomgevingen en bevindingendatabase
Als je nog steeds aan het wachten bent op de specificaties, dan kan je in deze fase ook nog nadenken over een testomgeving en een bevindingendatabase. Met een beetje geluk zijn deze zaken al ingeregeld en hoef je alleen nog maar de benodigde formulieren in te vullen en dit aan te vragen. Zijn deze zaken er nog niet, dan kun je bedenken om te testen in productie. Het opzetten van een testomgeving is een onmogelijke taak voor een tester. Als het een nieuw product is, dan zullen er toch geen gebruikers mee werken als je aan het testen bent en heb je dus helemaal geen testomgeving nodig.

Als het een verbetering van een bestaand product is wordt het wat lastiger en zal je toch een testomgeving moeten eisen van de bouwers en dit via de projectmanagers moeten spelen. In je testplan had je namelijk de verwachting staan dat er al een testomgeving was.
Is er geen bevindingendatabase, dan hoef je hier verder niets te doen. Maak een Excel sheet voor jezelf aan waar je de bevindingen in bijhoudt en communiceer de bevindingen per e-mail. Het is belangrijk dat mensen bevindingen oplossen en daar heb je geen database voor nodig. Je kunt bevindingen per e-mail communiceren en dan heb je gelijk een archief in je mailbox. Als dan iemand een bevinding niet oplost kan je dit altijd terugvinden, zodat je het bewijs hebt als men weer eens begint dat je niet goed hebt getest.

Gebruik wel prioriteiten voor je bevindingen. Het beste kan je één term gebruiken voor de gevaarlijkste bevindingen: Showstopper. Voor de rest van de prioriteiten kan je vage termen gebruiken zoals: normaal, ernstig, prio 3. En voor de bevindingen die je niet belangrijk vindt, gebruik je “cosmetisch”.

Uitvoeren van testen
Als je geluk hebt kun je andere testers aan het werk zetten om je uitgewerkte testscripts uit te voeren en zullen de bevindingen vanzelf binnen stromen. Zeker bij een eerste opgeleverde versie van een product is er voldoende te vinden. Zelf testen aan de hand van je scripts is ook goed, want je hoeft verder niet meer na te denken, want dat heb je al gedaan bij het maken van het testontwerp. Het is nu een kwestie van de scripts één voor één uit te voeren en bevindingen te noteren.

Testrapportage
Rapporteren is wel het mooiste gedeelte van het testvak. Dit omdat je de macht hebt om een product af te keuren. Gebruik op de voorpagina een mooie foto van een stoplicht die op rood staat om extra te benadrukken dat er een no-go beslissing ten grondslag ligt aan de te lezen rapportage.

Geef in je rapport aan welke bevindingen nog open staan, op wie zijn naam en noem deze bevindingen productrisico’s. Let op, dit is eigenlijk je risico analyse die vaak bij elke testmethode tevergeefs aan het begin worden gehouden. De echte risico’s zijn natuurlijk de bevindingen die nog niet opgelost zijn.

Voeg verder wat statistische gegevens toe van het aantal testgevallen wat je al hebt uitgevoerd en hoeveel er daarvan zijn gefaald. Benadruk dat er een hertest nodig is. Mocht dit zich vaker herhalen kan je meer budget en tijd vragen, omdat je in je testplan maar rekening had gehouden met één hertest.

In productie
Uiteindelijk zal je overruled worden door management. Bereid je daar goed op voor door een aantal zinnen te oefenen in de trant van: “Dit gaat straks duizend keer zoveel kosten dan als je deze bevinding nu zou oplossen” Of: “Wil je in de telegraaf of andere media komen hiermee”, “we moeten nog één build uitvoeren om de ergste showstoppers eruit te halen” en de mooiste: “Dat had een maand geleden allemaal al opgelost kunnen zijn.”

Als het product in productie wordt gezet, probeer dan goed tegen iedereen in het bedrijf te zeggen dat dit niet jouw idee was en dat management deze beslissing heeft genomen ondanks dat je het product hebt afgekeurd. Dit maakt je positie sterker in je organisatie en mensen zullen jou eerder gaan vertrouwen dan het management.

Conclusie
Dit zijn tips die heel krachtig zijn om er voor te zorgen dat iedereen de focus houdt op het belangrijkste wat er is: het oplossen van bevindingen en zorgen dat iedereen luistert naar de testers. Vaak vallen de bevindingen in productie wel mee omdat de projectmanager in dit soort gevallen beslist om extra mensen bij de helpdesk in te zetten zij vangen de eerste maanden de problemen toch wel op tot er een nieuwe versie is. Mocht er een probleem zijn in productie die je als tester niet hebt ontdekt wordt dit niet zo snel gerelateerd naar het testen.

Uiteindelijk heb je, door er op deze manier mee om te gaan je steentje bijgedragen aan een succesvol traject. Het testvak kan dan wel saai en vervelend lijken, zeker als je moet wachten op specificaties en elke keer opnieuw de zelfde testgevallen moet uitvoeren. Maar de voldoening van een product wat af is maakt dit allemaal goed.

Echte conclusie
Veel van bovenstaande punten zijn zaken die ik gehoord en zelf heb meegemaakt over echte praktijk situaties. Soms stond ik letterlijk met klapperende oren tot ze bijna van mijn hoofd vielen.
Hoe pijnlijk komt een dergelijk verhaal bij u over? Kunt u zichzelf terugvinden in het verhaal? Misschien kunt u zich terugvinden in bepaalde gedeeltes? Dan zijn dat de gedeeltes waar u misschien nog over na wilt denken en nog wat verder de literatuur wilt induiken.

De boodschap hierbij is: Blijf kritisch op je eigen werk en professionaliteit. Natuurlijk heeft iedereen wel eens een baaldag of een project wat niet lekker loopt. Een baaldag is reden om vroeg naar huis te gaan, een project wat niet lekker loopt zal wat meer zorgen baren. Maar ook daarbij is het de zorg van de tester om scherp te blijven en waardevolle informatie over de kwaliteit aan de belanghebbenden te leveren. Daarvoor zijn we aangenomen.

———————————
Rob van Steenbergen is een onafhankelijke softwaretester en een actief blogger
Chickenwings Test Consultancy