Antwoord.

Handmatige regressietesting is het proces van het herhaaldelijk controleren van al getestte functionaliteiten van het systeem na wijzigingen in de code, om te bevestigen dat deze wijzigingen geen nieuwe defecten hebben veroorzaakt in stabiele delen van het product.

Achtergrond van de vraag: Aan het begin van de levenscyclus van software richten testers zich meestal op het controleren van nieuwe functies. Na verloop van tijd ondergaat het systeem wijzigingen, wat de risico's op onvoorziene regressies verhoogt. Veel fouten in de geschiedenis van software ontstonden juist na een fix die iets dat eerder werkte "verbrak", daarom is regressietesting geleidelijk een verplichte praktijk geworden.

Probleem: De belangrijkste dilemma is hoe je, bij constante veranderingen, efficiënt en snel het maximale aantal functies kunt herzien. Als je de taak chaotisch of inconsistente aanpakt, kun je kritieke defecten missen, de deadlines niet halen, het team overbelasten, en soms worden de controles een formaliteit.

Oplossing: Voor een effectieve organisatie van regressietesting is het nodig om:

Een set stabiele, onderhouden testcases of checklists voor sleutel functies te hebben;
Deze sets regelmatig bij te werken bij aanpassingen;
Routine waar mogelijk te automatiseren, terwijl voor handmatige testing kritische of ongewone scenario's worden geselecteerd;
Prioriteit van functies voor controle af te stemmen op basis van bedrijfsrisico's en frequentie van veranderingen.

Sleutelkenmerken:

Regressie onthult niet alleen duidelijke bugs, maar ook verborgen foutketens gerelateerd aan de interactie tussen modules.
Het is belangrijk om regelmatig de sets van testcases te herzien en prioriteren.
De optimale strategie is om handmatige controles te combineren met geautomatiseerde waar mogelijk.

Misleidende vragen.

Wanneer is het het beste om regressietesting te starten - na alle wijzigingen of parallel aan hun implementatie?

Veel mensen denken ten onrechte dat regressietests alleen na voltooiing van alle wijzigingen worden uitgevoerd. In werkelijkheid is het beter om ze te plannen en gedeeltelijk uit te voeren naarmate de wijzigingen worden aangebracht, om sneller te kunnen reageren op kritieke uitvallen.

Is het voldoende om één keer een regressietest-case te schrijven en deze niet meer bij te werken?

Nee, testcases voor regressie vereisen constante actualisatie: met veranderingen in de bedrijfslogica of interface moet het testsysteem veranderen samen met het product.

Is smoke-testing een onderdeel van regressie?

Nee, smoke-testen is een snelle check op duidelijke fouten na de build, terwijl regressie een breder scala aan functionaliteit dekt en naar defecten "dieper" zoekt.

Typische fouten en anti-patronen

Verouderde testcases - hierdoor wordt testen een nutteloze formaliteit.
Het negeren van minder zichtbare, maar belangrijke scenario's.
Gebrek aan duidelijke prioritering - gelijke aandacht voor zowel sleutel- als minder belangrijke functies.

Voorbeeld uit het leven

Negatieve case

Het team doet een release, de tester controleert formeel de functies op basis van een verouderde lijst van testcases, zonder op de hoogte te zijn van de laatste aanpassing van de API. Een oude bug wordt gefixt, maar ergens anders in het systeem verschijnt een kritieke fout die niemand opmerkte tot de lancering.

Voordelen:

Tijdwinst bij het doorlopen van testcases.

Nadelen:

Hoog risico om belangrijke regressies te missen.
Het vertrouwen in de kwaliteit van testen vermindert.

Positieve case

Voor de release hebben testers de regressie-checklists geactualiseerd, samen met analisten actuele risicogebieden besproken, tests geprioriteerd op basis van werkelijke scenario's en handmatige regressietests uitgevoerd op belangrijke flows.