5 Aandachtsgebieden voor testen binnen Scrum

In 1986 deed de vorm ‘Scrum’ zijn intrede als projectaanpak voor ontwikkeltrajecten in software. Vanaf 2000 werd deze methodiek in Nederland op grote schaal gebruikt. Ik ben zelf sinds 2006 werkzaam in de IT. Als senior testcoördinator/testmanager heb ik ervaren dat Scrum zeker voordelen biedt, maar dat  er ook zeker nog verbeterpunten zijn. Tijdens mijn opdrachten bij o.a. KPN, De Telefoongids en Dienst Uitvoering Onderwijs ben ik een vijftal aandachtsgebieden tegengekomen, te weten:

1. Testbasis
2. Integreren functionaliteiten
3. Regressie
4. Omgaan met bevindingen
5. Configuratie testomgeving

1. Testbasis

De focus binnen een Scrumtraject ligt op het werkende eindresultaat van een Sprint. Binnen een Sprint moeten nieuwe inzichten snel kunnen worden geabsorbeerd. De kracht van Scrum is dat  tijdens het softwareontwikkeltraject niet met vooraf gefixeerde en geaccordeerde requirements (testbasis) wordt gewerkt, maar met iteratieve sessies tussen het ontwikkelteam en de product owner. Op die manier wordt gewaarborgd dat datgene wordt ontwikkeld wat de product owner voor ogen heeft.

Als tester hebben we nu een uitdaging. Een tester is immers in de regel opgeleid om testcases te definiëren aan de hand van de testbasis. Die is er nu niet.

Om als tester toch succesvol te kunnen testen, zal hij mee moeten gaan met deze dynamiek. Hij zal korte lijnen moeten onderhouden met alle leden van het Scrumteam, inclusief de product owner. Op die manier zit hij bovenop de laatste ontwikkelingen. Dit vereist wel goede communicatie- en soft skills.

Daarnaast verschuift het werkveld van de tester van testvoorbereiding naar testafronding. In het testrapport moet nadrukkelijker de focus liggen op wat hij nu daadwerkelijk heeft getest (een soort testlogboek) en de decharge hiervan.

2. Integreren functionaliteiten

In een Scrumtraject wordt gewerkt met een Scrumteam. Een Scrumteam is verantwoordelijk voor de ontwikkeling van een specifieke functionaliteit. Binnen een groot Scrumtraject kunnen meer Scrumteams tegelijk aan het werk zijn. Elk team is verantwoordelijk voor een bepaalde functionaliteit. Focus binnen een Scrumteam is de werking van de functionaliteit waar het team verantwoordelijk voor is. Die verantwoordelijkheid geldt niet voor de werking van alle geïntegreerde functionaliteiten.

Hoe zorgen we er als tester nu voor dat de functionaliteiten ook geïntegreerd worden getest?

Binnen de Scrum of Scrums zal het onderwerp ‘integratie’ een vast onderdeel moeten zijn. Hierbinnen moet vooraf worden vastgesteld of de verschillende Sprintbacklogs op elkaar aansluiten. Het team moet tijdens de Sprint constant monitoren of de gekozen oplossingen voor de integratie op elkaar aansluiten.

Bij grotere projecten moet een integratiecoördinator worden aangesteld, die verantwoordelijk is voor de planning en monitoring van de integratietesten.

3. Regressie

In een Scrumtraject vinden binnen een Sprint regelmatig aanpassingen plaats. Deze aanpassingen kunnen ervoor zorgen dat er regressie optreedt binnen de Sprint. Er kan ook regressie optreden over sequentiële Sprints heen.

Om deze regressie inzichtelijk te maken, wordt voor het einde van de Sprint een hiervoor bestemde set aan testcases uitgevoerd. Na iedere Sprint wordt de functionaliteit echter uitgebreid en dus ook de testcases van de regressietest.

Het volgende probleem is hoe we ervoor zorgen dat niet alleen de aangepaste functionaliteit, maar ook impliciet geraakte onderdelen binnen de Sprintplanning kunnen worden getest.

Om te voorkomen dat de uitvoering van de regressietesten een te grote impact heeft op de beschikbare testcapaciteit en de doorlooptijd, zal er gebruik moeten worden gemaakt van risk-based testen en geautomatiseerd testen.

Bij de keuze voor geautomatiseerd testen moet rekening moeten worden gehouden met de tijd die het oplevert en de tijd die het kost om de testcases te onderhouden.

4. Omgaan met bevindingen

In een Scrumtraject loopt de testuitvoer vaak parallel aan de ontwikkeling. Door deze dynamiek tussen test en ontwikkeling is de kans op bevindingen groot. Het registreren en bijhouden van al deze bevindingen kost tijd.

Als tester moeten we nu zorgen dat de bevindingen zijn opgelost voordat de software in productie wordt genomen, zonder dat de registratie hiervan te veel tijd in beslag neemt.

Bij ontdekking van een bevinding zal directe afstemming moeten plaatsvinden met de betreffende ontwikkelaar.  De bevinding kan direct worden opgelost, óf er is meer tijd voor nodig.

In de eerste situatie is afstemming voldoende: het probleem wordt immers direct opgelost. De hertest kan dan ook direct na de implementatie plaatsvinden.

In het tweede geval is er wél een registratie nodig, om de status van de openstaande bevindingen te kunnen monitoren en opvolgen.
5. Configuratie testomgeving

In een Scrumtraject volgen softwareversies elkaar in rap tempo op. Afstemming over de softwareversies vindt plaats binnen het team, waardoor opleveringen snel kunnen worden getest. In het geval van integraties kan deze opleveringssnelheid echter leiden tot een onoverzichtelijke situatie.

Het volgende punt voor de tester is  zorgen dat bij de integratietesten de juiste softwareversies met elkaar communiceren.

Hiervoor is niet alleen een duidelijke afstemming binnen het eigen team nodig, maar ook met de teams van de omliggende systemen. Die systemen moeten met elkaar kunnen communiceren, middels de juiste interfaces en versies .

Om een duidelijk overzicht te hebben en te behouden voor de configuratie van de testomgeving, zal er dagelijks moeten worden afgestemd tussen de teams welke opleveringen op de korte en lange termijn worden verwacht. Zo kunnen de ontwikkelaars en testers anticiperen op de toekomstige releases.