Tienduizend steden — Testobjectivering & documentatie

Of toch wel?

Ik heb QA-teams vaak gewetensvol en nauwgezet aan de heroïsche taak zien beginnen om hun tests volledig te documenteren. Voor één release. En daarna raakt die documentatie meestal op de achtergrond. Er verzamelt zich digitale stof op een of andere netwerklocatie. En niet omdat het QA-team niet langer in het belang ervan gelooft. Ze zijn simpelweg volledig uitgeput door de inspanning die nodig is om de documentatie bij te werken voor de volgende grote release. 

Omdat het QA-team in zijn ijver ongelooflijk gedetailleerde testbeschrijvingen schreef, waarbij alles werd opgesplitst tot op een manisch microscopisch niveau van hyper-specificiteit. Voor elk aspect of kenmerk van één functie of gebruikersinteractie werd afzonderlijke testdocumentatie gemaakt. Er werden tientallen afzonderlijke testbeschrijvingen en taken opgesteld voor wat in wezen één testtaak is. Het is net als die persoon achter wie je in de rij bij de supermarkt terechtkomt en die erop staat $80 aan boodschappen met kleingeld te betalen.

Het resultaat van deze atomiserende ijverzucht is de productie van honderden, soms duizenden testbeschrijvingen voor de betreffende release. QA is zich er onbewust toe gaan zetten een roman van Dickens te schrijven. Een verhaal van tienduizend steden. Heb je er ooit echt een gelezen? Ik ook niet.

Het gevolg is dat niemand de tijd of het geduld heeft om deze duizenden afzonderlijke testbeschrijvingen bij te werken. Omdat de prioriteit altijd bij het testen van de volgende iteratie van de software zal liggen, aangezien dat uiteindelijk inkomsten oplevert, terwijl het bijwerken van testdocumentatie dat niet doet. 

Maar ook omdat toepassingen voor testdocumentatie het helemaal niet eenvoudig maken om grote aantallen testdocumentatie-items tegelijk bij te werken. Globale wijzigingen aan groepen tests kunnen in de meeste toepassingen omslachtig en niet-intuïtief zijn (dit geldt zelfs vandaag nog voor veel toepassingen voor defectregistratie). Dat verhoogt de kosten in tijd en mentale gezondheid die ermee gemoeid zijn.

Als gevolg daarvan wordt al die nauwgezette testdocumentatie uiteindelijk verlaten. En alle tijd die aan het maken ervan is besteed, is uiteindelijk verspild. Omdat ze niet herbruikbaar is. Het is een eendagsvlieg. Het is de "Ik Smelt Met Jou" van softwaretesten. Toch is testdocumentatie absoluut noodzakelijk voor een herhaalbare, systematische testinspanning. Vandaar de Catch-22.

Er is een uitweg uit dit dilemma. En hoezeer het me ook pijn doet om dit toe te geven, we zouden voor de oplossing naar de techniek moeten kijken. Of op zijn minst naar de inspiratie ervoor. Ingenieurs werden in de beginjaren van de commerciële softwareontwikkeling met een vergelijkbaar probleem geconfronteerd. Door de beperkingen van de programmeertalen uit die tijd moesten ze voor elke functie de code voor dezelfde basiseigenschappen, acties en beveiligingen opnieuw schrijven. Steeds opnieuw. Geheugenbeheer en garbagecollection waren een goed (en gevaarlijk) voorbeeld van dit probleem.

Daardoor genereerden ingenieurs enorme hoeveelheden overtollige code en verspilden ze enorme hoeveelheden tijd (Niet dat ingenieurs dat laatste per se erg vinden. Ebay bestaat niet voor niets.). Toen kwam een slimme geest op het idee van objectgeoriënteerd programmeren, waarbij programmeerobjecten konden worden gemaakt die dankzij hun aard standaardeigenschappen overnamen. Dezelfde code hoefde niet telkens opnieuw te worden geschreven (of geknipt en geplakt). Dat betekende dat kwaliteit niet langer afhankelijk was van het geheugen of de typevaardigheid van een bepaalde ingenieur. Waar QA eeuwig dankbaar voor is.

Dit is een zeer bruikbaar perspectief voor QA terwijl het worstelt met de doodlopende straat van testdocumentatie. Het concept van objectoriëntatie zoals dat in engineering bestaat, kan niet rechtstreeks op dit probleem worden toegepast, maar als metafoor heeft het veel te bieden. Slimheid past zich per definitie gemakkelijk aan nieuwe situaties aan.

In mijn loopbaan ben ik vaak geconfronteerd met het probleem hoe ik testdocumentatie moest maken die uitgebreid maar beknopt is, op het moment zelf uitvoerbaar maar ook gemakkelijk herbruikbaar voor toekomstige releases. De oplossing waar ik uiteindelijk op uitkwam, is het toepassen van het idee van een "object" op testdocumentatie zelf. 

Hier heb ik het over veel meer dan een sjabloon voor testdocumentatie. Die zijn natuurlijk zeer nuttig als standaardisatiehulpmiddel, maar niet relevant voor het probleem dat hier voorligt. Ik ontwikkelde het idee dat tests zo konden worden gedocumenteerd dat één documentatieonderdeel al hun verschillende modi, omslagpunten, werkstromen en speciale voorwaarden omvatte. Toen dit lampje in mijn wat duffe hoofd eenmaal ging branden, leek het antwoord plotseling heel eenvoudig. En heel haalbaar.

Laten we daarop ingaan.

De rode pil nemen

Het antwoord is om elke afzonderlijke test, en dus ook het bijbehorende documentatieonderdeel, niet te zien als de bewering of beschrijving van tests tegen één enkel datapunt of een geïsoleerde voorwaarde. Maar als een beschrijving van de volledige matrix (zie je wat ik daar deed?) van voorwaarden waarin de functie of mogelijkheid moet worden gevalideerd. 

Dit houdt een holistische benadering van het definiëren van afzonderlijke tests in. Een samenhangende, afzonderlijke testtaak kan niet zinvol worden opgesplitst in tientallen onafhankelijke "tests" zonder paradoxaal genoeg de specificiteit ervan uit te wissen door de functie als geheel te testen. Het is een situatie waarin je door de bomen het bos niet meer ziet.

Hier is het nuttig om het concept van een testcontext te bekijken. Want om het idee van een testobject effectief te implementeren, moet je eerst in staat zijn om de onveranderlijke kern van een functionaliteit te scheiden van de secundaire contexten waarin deze wordt toegepast en uitgevoerd. Dit is een vraag die de atomaire stijl van testdocumentatie vermijdt, waardoor testers nooit leren hoe ze deze analyse systematisch en bewust moeten uitvoeren. Nog een nadeel van atomisering.

Eenvoudig gezegd zijn testcontexten voor een functie of systeem de verzameling voorwaarden, omgevingen, workflows of toestanden die onafhankelijk van elkaar kunnen variëren binnen de grenzen van de functie zelf. Besturingssystemen en versies van besturingssystemen zijn hier een duidelijk voorbeeld van. Vreemde talen zijn een ander voorbeeld. Systeemtoestanden vormen nog een voorbeeld (bijvoorbeeld bij een webserver: geheugencaching in- of uitgeschakeld). Zodra je dit onderscheid begrijpt, kun je gemakkelijk aan vele andere contexten denken die relevant zijn voor de soorten producten die je test.

Nadat je deze analyse hebt voltooid (die toch de basis zou moeten vormen van elke professionele testplanning), kun je compacte vormen van testdocumentatie maken waarin dit onderscheid is verwerkt. In het systeem dat ik beschrijf, bestaat één documentatie-item voor een test uit:

1. Een beschrijving van de kernfunctie of -mogelijkheid die wordt getest.
2. Een lijst van alle contexten waarin de kernfunctionaliteit moet worden gevalideerd.
3. Al het overige dat je normaal gesproken toch zou hebben opgenomen (voorwaarden waaraan moet zijn voldaan om de test geldig te laten zijn, systeembronnen en bevoegdheden die nodig zijn om de test uit te voeren, een link naar de relevante productvereisten enzovoort). Niets hiervan wordt vervangen door wat ik voorstel.

Op dit punt denk je misschien: "Hé, dat kunnen heel veel contexten zijn!" Dat klopt. Maar bekijk het eens zo. Op deze manier werken levert je niet meer werk op. Het vermindert het juist. Het opstellen van uitgebreide testplannen wordt eenvoudiger met onze zorgvuldig samengestelde lijst met softwaretesttools voor documentatie. Deze methode zal het aantal afzonderlijke tests waarvoor je tijd moet vrijmaken om ze te maken, en die je in de toekomst moet onderhouden (of moet weigeren te onderhouden), namelijk *aanzienlijk* verminderen. In het atomaire systeem zou je voor elke context afzonderlijk een documentatie-item voor een test moeten maken. Dat leidt tot de Catch-22 die aan het begin van dit artikel is beschreven.

Deze methode van testdocumentatie heeft wel bepaalde gevolgen voor het proces die in eerste instantie misschien onhandig lijken. Of zelfs verontrustend. En dat geldt niet alleen voor QA, maar ook voor andere belanghebbenden bij het project. Als alle betrokkenen echter de tijd nemen om deze gevolgen te begrijpen, zullen ze inzien dat het werkelijk verbeteringen zijn. Voor iedereen.

De belangrijkste daarvan is dat het bundelen van de matrix van functiecontexten in de test zelf logischerwijs betekent dat als die ene test in een van die contexten faalt, de volledige test is mislukt. Zelfs als het maar om één context gaat. Ik kan me voorstellen dat dit paniek veroorzaakt binnen de engineeringafdeling. Het kan namelijk lijken alsof je de kaarten tegen hen stapelt en de lat voor een test om als "geslaagd" te worden beschouwd op een onhaalbaar niveau legt. Maar deze angst is eenvoudig weg te nemen. Wijs hen op twee dingen en jezelf op een derde:

1. Deze methode zal het aantal bugs dat door het testen tegen hun werk wordt geregistreerd daadwerkelijk verminderen . Bij de atomaire methode zou het falen van elk van die contexten namelijk tot een afzonderlijke bug hebben geleid. Daardoor zou het totale aantal bugs voor die ene functie toenemen. Dat zou een glimlach op het gezicht van engineers moeten toveren. En op dat van projectmanagers.
2. Ten tweede zorgt testen volgens deze methodologie automatisch voor context bij de werkelijke omvang van de functionele fout. Want wat is de eerste vraag die de engineer die aan de bug is toegewezen om deze op te lossen je altijd zal stellen? "Eh, gebeurt dit overal? Of alleen in context X?" In plaats van terug naar je bureau te moeten rennen en de test in context X opnieuw uit te voeren (omdat je dat misschien in je oorspronkelijke test bent vergeten?) heb je dat antwoord al, en ontneem je de engineer een excuus om te voorkomen dat hij of zij eraan werkt (wat QA geeft in de vorm van minder bugs, neemt het later weer weg).
3. Ten derde zorgt de contextanalyse voor de testdocumentatie ervoor dat je bij het documenteren van de test daadwerkelijk hebt nagedacht over alle relevante contexten. Dat betekent dat je minder vaak die paniekerige momenten zult meemaken — drie dagen voor of, erger nog, na de release — waarop je beseft dat je bent vergeten in enkele zeer belangrijke contexten te testen. Een op paniek gebaseerde QA-inspanning is niet erg effectief. Ook psychologisch gezien is het geen bijzonder prettige ervaring.

In de machine

Deze objectgeïnspireerde methode van testdocumentatie zal de hoeveelheid documentatie-items die je moet produceren drastisch verminderen, waardoor het waarschijnlijker wordt dat je ze daadwerkelijk kunt en wilt blijven bijwerken voor toekomstige releases.

De enige smet op dit geheel is dat maar weinig toepassingen voor testdocumentatie standaard zijn ingericht om tests op deze manier te documenteren. Ze gaan meestal uit van het atomaire documentatiemodel, omdat dat helaas de norm is, en beschikken daarom niet over ingebouwde functionaliteit om het objectmodel dat ik hier heb beschreven eenvoudig te ondersteunen. 

Daarom heb ik vaak mijn toevlucht genomen tot veel minder uitgebreide applicatieoplossingen — zoals Excel — die voor dit doel in werkelijkheid veel flexibeler en gemakkelijker aan te passen zijn, omdat ze voor algemeen gebruik bedoeld zijn. Het nadeel van die strategie is dat het lastig wordt om ze met Jira enzovoort te integreren. Maar misschien wordt er wel te veel waarde gehecht aan integratie.

Hoe dan ook, het blijft een feit dat veel applicaties voor het documenteren van tests en defecten het verdomd moeilijk maken om afzonderlijke records in bulk bij te werken. Ongeacht welke protocollen je kiest om ze aan te maken. Maar dat geldt ongeacht hoe je ervoor kiest je testdocumentatie te schrijven. Eén probleem tegelijk, mensen.

Bij voorbaat excuses (of in jouw geval achteraf) omdat ik je geen sjabloon voor testobjecten geef. Mijn ervaring is dat het verstrekken van sjablonen meestal een slecht idee is, omdat mensen je sjabloon gewoon gaan gebruiken. De beschikbaarheid van kant-en-klare, generieke sjablonen heeft de neiging de creativiteit van het team zelf te onderdrukken en kort te sluiten bij het ontwikkelen van een sjabloon dat aansluit bij hun werkelijke behoeften, processen en hulpmiddelen in de praktijk. Dus geen harde gevoelens.

Ik sta altijd open voor je vragen en suggesties. Plaats ze gewoon op LinkedIn of stuur ze naar me.

En zoals altijd: veel succes.