Waarom testen op basis van release notes?
Iedere functioneel-/applicatiebeheerder kent ze, release notes. Ze zijn het logische gevolg van nieuwe releases van applicaties. Ze bevatten een beschrijving van de bug fixes en nieuwe en gewijzigde functionaliteiten van je applicatie.
Vroeg of laat kom je ze tegen en moeten ze doorlopen worden om te bepalen wat de impact is van een nieuwe release. Iedere aanpassing in software brengt namelijk zichtbare en onzichtbare risico’s met zich mee. Reden genoeg om te bepalen waar de risico’s zitten en wat er moet worden getest.
Impact van release notes
De intentie van een nieuwe release van een applicatie is natuurlijk altijd een verbetering van de software. Denk bijvoorbeeld aan verbeterde functionaliteit of het oplossen van bugs. Echter, zoals kwaliteitsexpert Rik Marselis in Let’s Talk About Test aangeeft, is geen enkele ontwikkelaar onfeilbaar. Ook nieuwe releases bevatten zichtbare en onzichtbare risico’s en fouten. Daar komt bij dat de applicatie-leverancier geen rekening houdt met jouw inrichting. Laat staan hoe jij de applicatie gebruikt en welke integraties met andere applicaties je hebt.
De impact van de risico’s en fouten op kritische applicaties, integraties en bedrijfsprocessen wil je tijdig vinden. Daarom is het beoordelen van en testen op basis van release notes zo belangrijk.
Valkuilen bij het testen op basis van release notes
Het testen van applicaties op basis van release notes kent vele vormen. Hoe jij dit proces toepast ligt natuurlijk aan de voor jou geldende situatie. Ondanks de pluriformiteit aan testvormen zien we vaak drie veelvoorkomende valkuilen bij het testen van release notes. We hebben ze voor jou op een rijtje gezet:
- Een collega-organisatie heeft de release notes al goedgekeurd.
Door gebrek aan testkennis, mankracht of testervaring worden testresultaten van andere organisaties gebruikt om te bepalen of een wijziging moet worden getest. Hier schuilt een groot gevaar in. Weet jij hoe goed deze andere organisatie heeft getest? Gebruiken ze de applicatie op dezelfde wijze en maken ze gebruik van dezelfde integraties als jouw organisatie?
Het overnemen van testresultaten van andere organisaties brengt enorme risico’s met zich mee. Het biedt schijnzekerheid waardoor de aandacht voor het testen van de wijzigingen bijna onbewust verslapt. Daarnaast zal een accountant of een auditor nooit akkoord gaan met een dergelijke testaanpak. Je bent als organisatie zelf verantwoordelijk voor het testen van de nieuwe release van de applicatie die je in gebruik neemt.
- We testen alleen de gewijzigde functionaliteit zoals beschreven in de release notes.
Het is goed dat nieuwe functionaliteit getest wordt. Maar hoe weet jij zeker dat nieuwe functionaliteiten geen effect hebben op bijvoorbeeld integraties? En hoe test je de onderlinge samenhang tussen functionaliteiten? Neem als voorbeeld je mobiele telefoon. Je hebt net een update gedaan van de laatste iOS-versie of Android-versie en nog geen week later volgt er alweer een hotfix. Dit als gevolg van het optreden van regressie bugs in gerelateerde functionaliteit.
Daarom is het uitvoeren van een regressietest zo belangrijk bij het testen van een nieuwe release. Een goede manier om dit te doen is door altijd een aantal standaard regressietest-scenario’s door te lopen voordat je een nieuwe release goedgekeurd.
- Het aantal wijzigingen is te veel om te testen. We horen het wel als iets niet werkt.
Helaas komen we dit nog steeds tegen in de praktijk. Waarom dit een groot risico met zich meebrengt, wordt al in de vorige twee punten duidelijk gemaakt. Natuurlijk is het soms niet mogelijk om alle wijzigingen te testen. Zeker wanneer je maandelijks gemiddeld 1.500 wijzigingen moet beoordelen en testen.
Het toepassen van een piepsysteem (we horen het wel) is echter niet de juiste oplossing. Het is dan ook zinvol een op risico gebaseerde testaanpak te hanteren. Door wijzigingen te beoordelen op foutkans en impact zorg je ervoor dat de aandacht en testinspanning gaat naar de meest risicovolle wijzigingen.
Testtool
Het testen van applicatie-releases is geen bijzaak. Het vergt tijd en kennis om dit goed uit te voeren. Uiteraard is het niet voor iedere organisatie mogelijk om testconsultants in te huren om een gedegen testproces in te richten. Een testtool als Testersuite bevat de best practices voor het testen op basis van release notes en het uitvoeren van regressietest-scenario’s. Dit helpt jou om het testproces voor het testen van je applicatierelease snel en goed in te richten. Ongeacht hoe volwassen het testproces van je organisatie is.
Meer weten over dit onderwerp? Plan een vrijblijvend adviesgesprek met ons in.
