Vaak is het zo dat hoe ouder de systemen zijn, hoe minder documentatie er beschikbaar is, of dat deze verouderd is.

Dit veroorzaakt problemen voor zowel ontwikkelaars als testers. Voor beide zullen er onduidelijkheden zijn over wat het systeem doet. Dit maakt het lastig om te beslissen wat er moet veranderen en hoe dit vervolgens te testen.

In deze situatie kunnen we vertrouwen op deskundigen om te vertellen wat het systeem daadwerkelijk doet. Dit wordt natuurlijk lastig als er geen echte deskundigen op het systeem zijn.

Een ander risico bij onderhoudstesten is dat als het systeem niet volledig begrepen is, de gemaakte wijzigingen misschien verkeerd zijn of een effect hebben op een ander deel van het systeem waar de ontwikkelaars en / of testers niet van op de hoogte zijn.

Ook kan het testen langer duren dan oorspronkelijk gepland omdat de volledige impact van de wijziging niet begrepen werd

In dit geval zullen de developers en testers vooraf en in samenspraak met de business moeten bedenken wat de beste manier is om aan te tonen dat de wijzigingen correct zijn doorgevoerd en dat er geen regressie is ontstaan. Dit kan bijvoorbeeld door testgevallen zowel met de oude versie als in met nieuwe versie uit te voeren.

De verschillen in de resultaten moeten dan verklaard kunnen worden:

• Komen de verschillen door de doorgevoerde wijziging en is dat dan gewenst?
• Is er regressie ontstaan omdat de wijziging nog niet volledig of goed is doorgevoerd. Met ander woorden is er bij de analyse iets over het hoofd gezien

AA