Testen geeft inzicht in de kwaliteit van de software. Maar hoe weet je wat je moet testen? Releasedocumentatie is de basis van het testen. Hierin staat wat de wijzigingen zijn in een release. In dit artikel lees je alles over het belang van goede releasedocumentatie.
Wat zijn release notes?
In je releasedocumentatie 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 releasedocument over een release item. In een release note staat of iets nieuwe of gewijzigde functionaliteit is, 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 kun je onze handige checklist downloaden. Deze checklist is opgesteld vanuit verschillende perspectieven: gebruikers, systeemtesters, beheerders en programmeurs. Gebruik de paragrafen die voor je van toepassing zijn.
gratis checklist releasedocumentatie
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?). Misschien zijn er nog meer zinnige testgevallen 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”?
Releasedocumentatie en release-management
De release notes uit het release document moeten worden gerelateerd aan testers, testgevallen en verschillende versies. De testcoördinator wil overzicht van alle release-items en hun testen. Hij 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 kunt delen. In Supportbook kun je release notes inladen en gebruiken 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. Lees hier meer over de functionaliteiten van Supportbook.
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 eerder 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 je alle documentatie (release en test) beheert op één plek. Meer weten? Neem contact met ons op, of lees verder op de kennisbank pagina.
