Agile en Scrum software testing

Werken in een Scrum of Agile aanpak vereist een kortere cyclus tussen definitie (user-story) en het uitvoeren van de software testen.

Hieronder laten wij u zien hoe die cyclus versneld kan worden, en hoe u besparingen kunt bereiken.

Uitdagingen voor Software Testen in een Scrum of Agile project

Met de steeds korter wordende cycli van software ontwikkeling komt in de praktijk het testen van de in een sprint opgeleverde functionaliteit vaak onder druk te staan.
Daarnaast lijkt het of de verworvenheden uit de meer traditionele ontwikkel en test aanpak bij Agile niet meer toepasbaar zijn. Denk hierbij aan het V-model.

Niets is volgens ons minder waar. Het V-model is ook toe te passen op korte cycli (User Story – Sprint). Echter dan zijn er wel hulpmiddelen nodig om de keten van Requirements (User Story) tot en met testen te versnellen.

Aanpak met BenderRBT

BenderRBT is gebaseerd op Risk en Requirements Based Testing (RRBT).

De Requirements (User Story) worden vastgelegd in een Cause Effect Graph (Oorzaak Gevolg Diagram). In dit geval van een koffieautomaat.

Cause Effect Graph Koffie automaat

Cause Effect Graph Koffie automaat

Iedere Actie of Status wordt een Node (knoop), met bijbehorende logica. Zo zal er alleen spanning beschikbaar zijn, als de stekker erin zit en de knop in “Aan” staat.
Dit principe geldt voor het hele schema, waarbij voor iedere Node in de True of False situatie moet worden afgehandeld in de logica en vervolgens moet worden getest.

Dit triggert echter de volgende vragen tijdens de evaluatie met de opdrachtgever. De volgende vragen rijzen:

  • Wat doen we als er geen heet water is ?. In dit geval hoort er een melding “TempLaag” te komen op de False status van “HeetWater”.
  • Kunnen de selectieknoppen voor de Koffiesoort (Zwart, Suiker, Melk, etc) tegelijk worden ingedrukt (fysiek), of is er sprake van “Radio-Buttons”. In dit geval hebben we een scherm met “Radio-Buttons”, dus wordt er een “One – Constraint” aangebracht, zodat geen testgevallen worden gegenereerd, die niet uitvoerbaar zijn.

Vervolgens garandeert BenderRBT, dat bij het aanmaken van de testen, iedere Node in True en False wordt getest (tenzij we Constraints hebben aangebracht)

Als één van de rapporten is de “Functional Specification” beschikbaar.

Functional Specification (gegenereerd uit de CEG) van de Koffie Automaat

Functional Specification (gegenereerd uit de CEG) van de Koffie Automaat

Hierboven staat de omschrijving van de Nodes in pseudo code beschreven. Een extra hulpmiddel om het model te valideren en vervolgens bij programmering te gebruiken.

Het volgende analyse rapport is de “Definition Matrix”

Beslissingstabel, tevens alle gegeneerde testgevallen

Beslissingstabel, tevens alle gegeneerde testgevallen

Deze tabel toont de gegenereerde testgevallen in een compacte vorm. Dit is de minimale testset, die alle Nodes in True of False test. (tenzij er Constraints zijn toegepast)

Ook dit overzicht wordt gebruikt voor validatie van het opgestelde model. Hier wordt meestal duidelijk dat er testen gaan ontstaan, die niet kunnen. Dat komt doordat er nog fouten zitten in de logica (AND, OR, XOR etc) of dat er onvoldoende aandacht is besteed aan Constraints.

Wij gebruiken de volgende proces stappen met BenderRBT in Agile / Scrum ontwikkeling en testen:

Stap 1. Eerste schets maken samen met de klant, de logica vastleggen

Cause Effect Graph Koffie automaat

Cause Effect Graph Koffie automaat

Stap 2. Met behulp van de Neon functie kunnen we (samen met de opdrachtgever) de scenario’s van de User-Story aanblikken. We hebben nu de mogelijkheid om een functioneel prototype te beoordelen. Op deze wijze wordt het testen geïntegreerd in het ontwerp.

Dit kunnen meer scenario’s zijn, dan de gecomprimeerde minimale testset (zie Definition Matrix)

Validatie van de logica, door condities in zelf True en False te zetten.

Validatie van de logica, door condities in zelf True en False te zetten.

Stap 3. Ready voor Sprint / begroting.

Na analyse van de rapporten wordt de logica “afgetekend” en een begroting van de inspanning gemaakt:

  • Voor iedere Node kan afhankelijk van het type (Input, DB access, etc) een aantal punten / uren worden toegekend voor de realisatie
  • De begroting van de testinspanning kan worden gemaakt aan de hand van het aantal uit te voeren testen en hun complexiteit (aantal stappen en typen invoer en uitvoer)

Stap 4. Testuitvoering.

Alle informatie voor de testuitvoering is beschikbaar, hetzij in vorm van de Definition Matrix  dan wel als uitgeschreven testcases, die aan de tester(s) kunnen worden uitgereikt.

Gegenereerd testscript

Gegenereerd testscript

Vervolgstappen:

  • Bepalen van de testen met de hoogste functionele dekking. BenderRBT garandeert een 100% functionele dekking (van het ingebrachte model). Echter tijdsdruk kan betekenen dat niet 100% van de testen kunnen worden uitgevoerd. Er zijn meerdere functies beschikbaar om de coverage te optimaliseren.
  • Bevriezen en opslaan van de huidige versie. Op deze wijze kan bij regressie testen beoordeeld worden
    • welke bestaande testen nog bruikbaar zijn,
    • welke nieuw gegenereerde aanvullende testen noodzakelijk zijn voor de 100% dekking.

Voordelen voor Agile en Scrum aanpak:

  • Validatie direct mogelijk door de designer, doordat verschillende representaties van de User-Story worden getoond.
  • Direct te gebruiken in overleg met de opdrachtgever (logisch prototype)
  • Hulpmiddel bij de ontwikkeling (exacte specificatie)
  • Testen zijn direct beschikbaar
  • Testinspanning eenvoudig te begroten, doordat het aantal testgevallen al tijdens specificatie van de User-Story bekend is.
  •  Tijdsbesparing, doordat maar 1 keer gespecificeerd hoeft te worden

NB. In de plaatjes die op deze pagina zijn gebruikt, zijn bewust fouten en ommissies gemaakt. Die zijn nodig om hier de discussie te verfijnen. Indien u (of uw klant) een commentaar / verbetering aanbrengt, wordt u “eigenaar”  van de specificatie. En dat is precies wat de doelstelling is.

Wilt u zelf ondervinden hoe deze aanpak werkt voor Agile en Scrum, wij helpen u graag verder, net als vele andere klanten.

Geplaatst in Requirements Based Testing, Scrum, Agile, Geen categorie Getagd met , , , ,