Leiderschap in testen: Documentatie
Noot van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestgoeroe en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring — vooral degenen in agile teams — te helpen uitblinken in hun rollen als testleider en manager.
In het vorige artikel schetsten we een risicomanifest om managers te helpen. In dit artikel stellen we de aloude vraag “Hoeveel testen is genoeg?”. Spoiler: dat wordt bepaald door de belanghebbenden.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepere duik in dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Ongeacht het project, de organisatie of de aanpak is er altijd plaats voor documentatie. Goede documentatie is een uitkomst en biedt een nuttig overzicht van de aanpak, reikwijdte, plannen, ontwerpen en de resultaten van analyse-, ontwikkel- en testactiviteiten.
In dit artikel bespreek ik:
- De waarde van documentatie
- De valkuilen van sjablonen en knippen/plakken
- Soorten testdocumentatie
- Advies voor het ontwerpen van documentatie
Laten we beginnen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
De waarde van documentatie
In gestructureerde projecten worden documenten doorgaans op zichzelf als op te leveren producten beschouwd. In agile of continue werkwijzen kan documentatie als bijproduct met meer of minder waarde worden geproduceerd.
Het schrijven van documenten kan de primaire activiteit van professionele technisch schrijvers zijn, maar voor de meeste vakmensen is het een vervelende klus — hoe nuttig het ook kan zijn. Hoewel het schrijven van documenten voor sommige mensen saai kan zijn, is het echte probleem met documentatie dat de meeste documentatie in veel contexten simpelweg tijdverspilling is. Ze heeft weinig waarde, is verouderd, onnauwkeurig — of alledrie.
Elke testmanager heeft teststrategieën geschreven die mensen niet hebben gelezen of onderschreven. Testers schrijven enorme hoeveelheden testplannen, scripts en rapporten, terwijl de enige waardevolle inhoud voor belanghebbenden de samenvattingen van één pagina aan het begin of einde zijn.
We hebben allemaal documenten geschreven waarvan we weten dat ze weinig waarde hebben en die niemand zal lezen.
Dit komt voort uit veelvoorkomende problemen met documentatie die we tegenkomen in zowel grote als kleine projecten. Voor elk document dat we schrijven, moeten we verschillende vragen beantwoorden:
- Welk type document? Een beleid of strategie, een aanpak of plan, een ontwerp of implementatie, of een resultaat en interpretatie?
- Wat is het doel van het document?
- Welke inhoud is nodig om dat doel te bereiken?
- Welke kennisbronnen zijn nodig om de inhoud te creëren?
- Als het document in de loop der tijd moet veranderen, hoe wordt het dan onderhouden?
- Welk detailniveau is vereist?
De valkuilen van sjablonen en knippen/plakken
Als je project bepaalt dat een bepaald document vereist is, bijvoorbeeld een systeemtestplan of een risicoregister, is het verleidelijk om op internet een kant-en-klaar sjabloon voor dit soort documenten (en vele andere documenttypen) te zoeken.
Sommige sjablonen beweren dat ze voldoen aan een bepaalde norm of conventie en duizenden keren zijn gedownload en gebruikt. Soms lijkt een sjabloon precies geschikt voor jouw doel. Maar, zoals we zullen zien, kan zelfs een uitgebreide inhoudsopgave je in de problemen brengen.
Het kan ook zijn dat jij of anderen binnen je bedrijf voor eerdere projecten een vergelijkbaar document hebben opgesteld. Je komt misschien in de verleiding om dit document te kopiëren en te hernoemen, de verwijzingen naar het oude project te wijzigen en de inhoud aan te passen.
Waarschuwing: In mijn ervaring als onafhankelijke beoordelaar komt dit zeer vaak voor en is het vaak een echt probleem.
Ten eerste is het meestal overduidelijk dat er een kopieer- en bewerkingsactie heeft plaatsgevonden. De taal die in de tekst wordt gebruikt, lijkt vaak los te staan van het project en overal zijn hiaten en overbodige tekst te vinden. Hoe komt dat?
Het gebruik van een vooraf opgesteld sjabloon of bestaand document als bron brengt verschillende risico’s met zich mee:
- Het ziet er uitgebreid uit, maar het kan onderwerpen bevatten die ongepast zijn en andere onderwerpen uitsluiten die essentieel zijn.
- Het biedt koppen voor een document, maar absoluut geen richtlijnen voor welke inhoud geschikt is voor elke kop.
- Het kan tekst bevatten die herbruikbaar lijkt en ongewijzigd is gekopieerd uit een eerder, niet-gerelateerd project, maar die tekst kan een verkeerde indruk wekken of onjuist of onvolledig zijn.
Het kan nuttig zijn om sjablonen te gebruiken voor koppen en een basisindeling, maar het belangrijkste probleem met sjablonen is dit:
De verleiding bij sjablonen is om er te veel op te vertrouwen en vervolgens voor de verschillende secties omslachtige tekst te schrijven. Je zou immers kunnen denken dat het document een ‘afvinkvakje’ voltooit en dat toch niemand het zal lezen. Het risico van sjablonen is dat je stopt met nadenken en een document schrijft dat weinig waarde heeft.
Typen testdocumentatie
In dit gedeelte bekijken we de verschillende vormen van testdocumentatie en bespreken we enkele aandachtspunten bij gestructureerde of agile/continue projecten versus traditionele watervalmethodeprojecten.
De belangrijkste testdocumenten vallen doorgaans in de volgende categorieën:
- Beleid en strategie (soms bekend als mastertestplan)
- Testdefinitie (ook wel specificatie of testplannen genoemd, wat verwarrend kan zijn)
- Testontwerp
- Testgevallen
- Testprocedures of scripts
- Testuitvoering
- Planning
- Logboek
- Testrapport
De bovenstaande reeks documenttypen omvat de definitie van het testproces, de belangrijkste activiteiten voor definitie en uitvoering en de rapportage.
Er zijn verschillende andere testgerelateerde documenten die in meer bureaucratische omgevingen definities en beheerprocessen voor testomgevingen, acceptatieprocedures, processen voor incidentbeheer enzovoort zouden omvatten (we behandelen incidentbeheer in een toekomstig artikel).
Een andere voor de hand liggende omissie in het bovenstaande zou een algemeen plan of een algemene planning voor testactiviteiten zijn. Een planning is niet echt een testdocument; het is een onderdeel van een algemeen projectplan voor een gestructureerd project (we behandelen het plannen van planningen ook in een toekomstig artikel, dus blijf op de hoogte!).
Beleid, strategie, mastertestplan
| Doel |
|
| Inhoud |
|
| Bronnen |
|
| Onderhoud |
|
Agile/continue aandachtspunten De teststrategie voor agile projecten die bijvoorbeeld Scrum gebruiken, zal waarschijnlijk vrij beknopt zijn en slechts enkele pagina's omvatten (als deze al wordt gedocumenteerd). Het testproces heeft mogelijk geen fasen, maar er zal waarschijnlijk wel een definitie zijn van testen op verschillende niveaus. Bijvoorbeeld:
| |
Testdefinitie (ontwerp, testgevallen, procedures)
| Doel |
|
| Inhoud |
|
| Bronnen |
|
| Onderhoud |
|
Agile/continue aandachtspunten Het gebied van testdefinitie is waar de aanpak van agile het duidelijkst verschilt van gestructureerde projecten. Mogelijk maken testers die zich richten op functies zodra deze worden opgeleverd helemaal geen documentatie. Dit is passend als er bijvoorbeeld een organisatiebreed beleid of handvest voor het testen van functies bestaat. Waarschijnlijker is er voor het testen van elke functie in een verkennende testsessie een beknopt handvest. Een handvest is vergelijkbaar met een plan voor een korte verkenningsperiode. In het handvest wordt doorgaans het volgende vastgelegd:
| |
Testuitvoering (planning, logboek)
| Doel |
|
| Inhoud |
|
| Bronnen |
|
| Onderhoud |
|
Overwegingen voor agile/continue ontwikkeling Als agile/continue projecten zich niet vastleggen op testdefinitiedocumenten, compenseren zij dit enigszins door testers aan te moedigen betere logboeken van de testuitvoering bij te houden. Waar testsessies worden uitgevoerd aan de hand van charters, wordt van de tester verwacht dat deze goede aantekeningen bijhoudt van de uitgevoerde tests. Er zijn maar weinig speciale hulpmiddelen voor het loggen van tests die meer bieden dan notitieboeken, dus veel testers gebruiken eenvoudige teksteditors, hulpmiddelen voor het maken van notities of papieren notitieboeken. Logboeken worden doorgaans gebruikt om alle belangrijke activiteiten en observaties tijdens sessies vast te leggen terwijl deze worden uitgevoerd. Een typisch logboek voor verkennend testen zou aspecten bevatten zoals:
| |
Testrapport
| Doel |
|
| Inhoud |
|
| Bronnen |
|
| Onderhoud |
|
| Overwegingen voor Agile/continu werken Het doel van een testrapport in een agileproject kan betrekking hebben op één iteratie of sprint, op testen voor een release, of op een testfase op hoger niveau, zoals integratie of algemene systeemacceptatie. In alle gevallen blijft het doel hetzelfde. Een groot deel van de inhoud van een testrapport komt uit hulpmiddelen of aantekeningen van testers. De beschrijvende samenvatting van de resultaten wordt geschreven door een testleider of door de tester bij een testfase op kleinere schaal. Zoals gewoonlijk zal het rapport waarschijnlijk minder formeel zijn en zal er vermoedelijk minder onbewerkte data zijn die als basis kan dienen voor geavanceerde analyses. Zeker tijdens de iteratie(s) kan de voortgang binnen de iteratie, in termen van functies of gebruikersverhalen die zijn opgeleverd, getest en door de gebruikers goedgekeurd, worden vastgelegd in een hulpmiddel of op een openbaar KanBan-bord. Op deze manier blijven de belanghebbenden gedurende de hele iteratie op de hoogte van de voortgang en is er aan het einde van een testperiode minder behoefte aan een formeel rapport. Zichtbaarheid van de voortgang is een belangrijk aandachtspunt voor agileteams. Met regelmatige, misschien dagelijkse stand-ups rond bijvoorbeeld een Scrum-bord delen teamleden voortdurend hun inzicht in de voortgang, stellen ze elkaar vragen en stemmen ze een standpunt (en vervolgstappen) af. Op deze manier is een formeel testrapport mogelijk nooit nodig, omdat het team altijd geïnformeerd en op de hoogte is. Als de testers schriftelijke aantekeningen bijhouden van hun sessieactiviteiten, zijn er geen analyseerbare gegevens beschikbaar om geautomatiseerde rapporten te genereren. Rapportage over sessies en voortgang kan dan op een openbare, visuele manier worden gepresenteerd. Dit vereist een hoge mate van discipline en goede communicatieve vaardigheden van de testers. De testleider of manager zal op basis van mondelinge rapportages een overeenkomstig informatief rapport voor de belanghebbenden moeten opstellen. | |
Enig advies
Het onderwerp documentatie in projecten is een gevoelig onderwerp voor zowel testers als andere projectteamleden.
De meeste mensen beschouwen het schrijven van documentatie als een vervelende klus.
Hier zijn enkele zaken om rekening mee te houden bij het ontwerpen van je documentatie.
- Documentatie moet een duidelijk omschreven doel en doelgroep hebben. Als je doelgroep de documentatie niet nodig heeft, zullen ze die niet lezen. Als de documentatie niet aansluit bij hun eigen doelen, zullen ze er niet achter staan.
- Over het algemeen is het beter om de vastlegging van een activiteit te maken voordat je die uitvoert of terwijl je die uitvoert. TDD legt bijvoorbeeld tests vast voordat de code wordt geschreven. Testlogboeken van sessies moeten tijdens de sessie worden bijgehouden en niet achteraf worden geschreven.
- De essentiële gegevens om een aspect van het testen vast te leggen, kunnen minimaal zijn. Een test die bijvoorbeeld in een notitieboek is vastgelegd, kan voldoende zijn voor de tester, maar kan niet eenvoudig worden geanalyseerd. Misschien kan een eenvoudig tekstlogboek met enige opmaak net zo snel worden vastgelegd, maar kan het ook door een aangepast hulpmiddel worden geanalyseerd.
- Testprocedures zijn mogelijk helemaal niet nodig als testers het te testen systeem goed kennen. Misschien is alleen een testdoel of testcharter nodig. Voorbereide testgevallen kunnen minimaal worden gedocumenteerd in een spreadsheet.
Tot slot
Noodzaak is de moeder van documentatie.
Als je uitgebreide documentatie voor je belanghebbenden opstelt en zij die niet lezen, komt dat doordat ze de waarde ervan niet inzien.
Het is beter om een belanghebbende een leeg vel papier voor te leggen en samen de onderwerpen toe te voegen die in een document moeten staan, en van daaruit verder te werken. Misschien vragen ze om pagina's vol inhoud, maar wat ze werkelijk nodig hebben, is vrij eenvoudig. Blijf vragen: ‘waarom willen ze dit?’
Bedankt voor het lezen. Kom de volgende keer bij ons terug terwijl we de mouwen opstropen en beginnen met testplanning.
Schrijf je in voor de nieuwsbrief van The QA Lead om op de hoogte te worden gebracht wanneer nieuwe delen van de reeks worden gepubliceerd. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!
