Testen geeft inzicht in de kwaliteit van een product. Doet de software wat het moet doen? Is het stabiel, betrouwbaar, snel en veilig? Werkt het goed in alle omstandigheden? Kan iedereen er mee werken? Zijn er negatieve bijeffecten in het gebruik?

Maar hoe weet je of de testen klaar zijn en of je alle belangrijke zaken hebt gezien? Hoe minder je weet over wat er is gewijzigd, hoe meer je moet testen omdat alles dan een potentieel groot risico is.

Daarom is goede releasedocumentatie van belang. Hierin staat wat de wijzigingen zijn in een release. De onderdelen van een release worden “release items” genoemd, een “release note” is de paragraaf in het release document over een release item. In een release note wordt verteld of iets nieuw is of een wijziging op een functie die al bestaat, wat er is gewijzigd, waarom zaken zijn gewijzigd (bijvoorbeeld een bug) en hoe de wijziging is uitgevoerd. Op basis hiervan kunnen testers bepalen wat ze wel en wat ze niet moeten testen en hoe ze moeten testen.

Checklist beoordelen releasedocumentatie

Om de kwaliteit van een releasedocument te beoordelen kan een checklist worden ingevuld. Hieronder kun je een checklist downloaden. De checklist is opgesteld vanuit verschillende perspectieven: gebruikers, systeemtesters, beheerders en programmeurs. Gebruik de paragrafen die voor je van toepassing zijn.

 

Een voorbeeld: testen op basis van release notes

Goede release notes zijn op te breken in condities, acties en resultaten: er wordt beschreven onder welke voorwaarden iets kan, wat het systeem doet en wat de resultaten zijn. Als je de condities, acties en resultaten uit een release note haalt, kun je je testgevallen zo afleiden.

Een voorbeeld van een release note is: “Om vanuit het klantscherm direct inzicht te hebben in lopende afspraken is een schermpje toegevoegd waarin een lijst wordt getoond met alle toekomstige afspraken. Door op een afspraak te klikken wordt het afsprakenscherm in een nieuwe tab geopend.”

De startconditie in het voorbeeld is in het klantscherm een klant openen die lopende afspraken heeft.
Het resultaat hiervan is dan dat de lopende afspraken worden getoond in een deelscherm.
Een vervolgactie is dan het doorklikken op een afspraak.
Het resultaat van de vervolgactie is dan dat het afsprakenscherm in een nieuwe tab geopend wordt.
Vervolgacties kunnen dan bijvoorbeeld het bewerken van de afspraak zijn.

Testgevallen richten zich eerst op de condities en de resultaten: open een klant met lopende afspraken en open vervolgens een individuele afspraak. Daarna bedenk je varianten of afwijkingen: klanten zonder lopende afspraken, klanten met afgelopen afspraken, het verwijderen van een lopende afspraak en dan terug naar het eerste scherm (is de afspraak nog zichtbaar?). Wellicht zijn er nog meer zinnige testgevallen uit je praktijk te bedenken.

Het punt is: had je deze testgevallen kunnen bedenken als de release note niet zo specifiek was en alleen maar zei: “Lopende afspraken in klantscherm”?

Release documentatie en release management

De release notes uit het release document moeten worden gerelateerd aan testers, testen en verschillende versies. De testcoördinator wil overzicht van alle release-items en hun testen en wil later kunnen terugvinden wanneer iets is geïntroduceerd en wie wat heeft getest. Je hebt daarom een administratie nodig waarin de release documenten worden beheerd samen met test documentatie.

Supportbook biedt zo’n administratie, waarin ook nog eens informatie met andere afnemers van de software kan worden gedeeld. In Supportbook kunnen release notes worden ingeladen en gebruikt worden als uitgangspunt voor het testen. Zo kun je testen coördineren, terugvinden hoe anderen een release item testen, of er al bugs zijn gevonden op een release item en of je misschien testinspanningen kunt verdelen tussen andere afnemers van de software of eigen afdelingen.

Een laatste belangrijke aspect van release documentatie is tijdigheid. Als je de release notes pas krijgt op het moment dat de nieuwe versie binnen komt, moet je tegelijk nadenken over testgevallen en ze uitvoeren. De praktijk leert dat het dan haastwerk wordt en dat er nogal eens wat wordt vergeten: verlies aan testdekking. Als release documentatie vroeger is, kunnen testers zich nog voorbereiden op de testen voordat ze die moeten uitvoeren en heeft de testcoördinator nog tijd om in te schatten wat de testinspanning moet zijn en wie er nodig is. Bovendien weet de organisatie dan wanneer dat ene felbegeerde item opgeleverd wordt en kan daar wellicht nog invloed op uitoefenen bij de leverancier. Dit alles te samen wordt release management genoemd.

Conclusie: gestructureerd testen is afhankelijk van goede en tijdige release documentatie

Met goede release documentatie heb je de basis om een test bibliotheek en test organisatie op te bouwen. Voorwaarde is wel dat alle documentatie (release en test) beheerd wordt op één plek.