De Agile werkwijze is in de jaren negentig van de vorige eeuw ontstaan als een reactie op de traditionele manier van softwareontwikkeling, de waterval methode. De zwakheden van deze ontwikkelmethode zijn algemeen bekend en wereldwijd goed gedocumenteerd. Een voorbeeld hiervan zijn de Chaos Reports van de Standish groep. Volgens het rapport blijft maar 10-20% van dit type softwareprojecten binnen de gestelde kaders van tijd, geld en kwaliteit.
In 1995 werd het Scrum framework ontwikkeld die onder de Agile-paraplu kwam te hangen. Scrum is gebaseerd op drie pijlers; transparantie, inspectie en adaptatie. Scrum is nadrukkelijk geen methode of proces, maar een framework waarbij de invulling van het framework de mate van succes bepaald.
Binnen Scrum wordt met sprints gewerkt. Sprints zijn iteraties waarbij in maximaal 4 weken werkende software wordt opgeleverd. Het testen van nieuw ontwikkelde software zit in de sprint zelf verwerkt. De leden van het development teamtesten dan (automatisch) de code van de software die ze zelf ontwikkeld hebben. Vroeg in het ontwikkelproces testen heeft als voordeel dat bugs snel gevonden worden en dus relatief goedkoop kunnen worden verholpen. Illustratief hiervoor is de wet van Boehm.
Wanneer een development team de code van de software (automatisch) heeft getest, weet men of de software werkt. Maar weet men nu ook of er met de software te werken valt?
De kwaliteit van het testen zit bij Scrum verwerkt in de Definition of Done (DOD). De DOD is een checklist waaraan de software moet voldoen voordat het gereleased kan worden. Het Scrum team, bestaande uit een Product Owner, Scrum Master en Development Team, stelt deze DOD op.
De Product Owner heeft als taak om de maximale waarde uit de software te halen, de Scrum Master probeert het werken met Scrum continu te verbeteren en het Development team wil uiteraard een hoge mate van kwalitatief goede software afleveren. Maar waar is nou de eindgebruiker in dit verhaal? De eindgebruiker is slechts één van de stakeholders waarmee de Product Owner te maken heeft. Via de Product Owner kunnen de eindgebruikers hun wensen (eisen?) kenbaar maken die het Development team dan mogelijk gaat realiseren. Wát er gebouwd of ingericht wordt bepaald de Product Owner.
Aan het einde van een sprint wordt de ontwikkelde code door het Development Team met behulp van tooling automatisch getest. Het Scrum team weet dan of de software werkt, overigens biedt dit nog steeds geen zekerheid of de eindgebruikers er dan ook mee kunnen werken!
Scrum kent geen testsoorten. De DOD bepaald wat en hoe er getest moet worden. Het Development team voert de tests grotendeels automatisch uit. Binnen een sprint van maximaal 4 weken is er doorgaans geen tijd om een proces- of regressietest te doorlopen met verschillende eindgebruikers.
Want of een eindgebruiker zijn werk goed kan doen, hangt vaak af van meerdere applicaties die onderling met elkaar gekoppeld zijn.
Hoewel Scrum een framework is welke op vele gebieden positief bijdraagt aan de ontwikkeling van software, biedt het voor de complexe systeemlandschappen van onze klanten geen handvatten om nieuw geleverde functionaliteit (of inrichting!) end-to-end te testen om zo inzicht de verschaffen in de kwaliteit van de integratie. Want of een eindgebruiker zijn werk goed kan doen, hangt vaak af van meerdere applicaties die onderling met elkaar gekoppeld zijn.
Dus ook bij testen binnen Scrum is het nodig om volledige procestesten te doorlopen om zo de integratie te kunnen beoordelen en om regressie op te sporen. Op deze manier wordt ook voor de eindgebruikers maximale waarde gecreëerd: werkende software die hen ondersteund tijdens de dagelijkse werkzaamheden.
In een veilige omgeving beoordelen of de software werkt en of je ermee kunt werken voorkomt verassingen in de productie-omgeving. Dit geeft stakeholders zoals directie, managers, accountants maar zeker ook de eindgebruikers vertrouwen in de te gebruiken software. Testregistratie laat zien dat een organisatie IT-kwaliteit serieus neemt.
Scrum zegt niets over testregistratie. Agile stelt in haar Manifesto dat werkende software verkozen dient te worden boven de documentatie over de software. Helemaal waar, maar dat betekent niet dat er helemaal géén documentatie nodig is. Testresultaten geven zowel het Scrumteam als de stakeholders belangrijke ken- en stuurgetallen, traceerbaarheid en ‘root cause-analyse’ om zo goede beslissingen over eventuele risico’s te kunnen nemen.