Column: Waterval of agile…

In de software wereld is een kentering gaande. Van waterval naar agile is één van de ontwikkelingen. Maar wat is de grote agile commotie nu eigenlijk? En waar zit het verschil voor de tester?

Testgevallen
Ik schrijf nog steeds testgevallen van te voren, gezien er nog niets te testen is in de eerste dagen van een iteratie. Ik kan ze niet volledig uitschrijven van te voren, maar werk ze meer op logisch niveau uit (of als test ideeën, testcharters). Maar dit deed ik ook al in zogenaamde ‘waterval projecten’.

Samenwerking in het team
Samenwerking tussen mensen gebeurt niet automatisch, ook al noem je een project “agile” en plaats je een team in een hok met de deur op slot.
Tester is betrokken in de planning: Vaak wordt de tester vergeten om uit te nodigen voor een planning overleg. Moet de tester meedoen in de scrum planning poker? Als de tester niet meedoet kijkt hier niemand vreemd van op.

Verantwoordelijkheid kwaliteit
Verantwoordelijkheid voor de kwaliteit van het product ligt bij het hele team? Bij wie klopt de CEO eigenlijk aan als het fout gegaan is? Toch zeker bij de product owner of scrum master? Of toch de tester, die zorgt toch voor de kwaliteit?

Automatisch testen
Door de vele korte iteraties is automatisch testen zeer belangrijk bij agile. Maar automatisch testen blijft nog steeds een “onbekend gebied” bij veel testers. Hulp van een ontwikkelaar is nodig, maar die heeft niet zoveel tijd, gezien hij of zij bezig is met zijn story points op te branden.

Bevindingentools
Ik heb nog steeds een goede bevindingentool nodig bij agile, zodat we in ieder geval geen bevindingen vergeten.

Ontwikkelaars testen ook
Ontwikkelaars automatiseren vooral hun unit testen.  Het idee is nog steeds: opzetten van een unit test is wel voldoende. Als je alles test op unit niveau, dan heb je automatisch het geheel getest.

Andere testtechnieken?
Bij “traditionele projecten’ in veel organisaties is het aantal testtechnieken wat gebruikt wordt al vaak beperkt tot één of twee technieken. Ik gebruik nog steeds mijn testtechnieken waar ik ze kan gebruiken.

Geen of beperkte testplan?
Er is nog steeds een testplan nodig, maak je die niet in de eerste iteratie, dan komt de behoefte vanzelf later in het traject. Wat was ook al weer de scope en wat moet ik de komende 3 maanden testen? Bij het overdragen van het werk blijft dit bijvoorbeeld een belangrijk overdracht document.

Testomgevingen
Binnen agile zou je dus op ontwikkel omgevingen moeten testen. “Waar de ontwikkelaars op werken, werkt ook de tester.”  Dit levert echter dezelfde problemen op als in elke andere situatie, een instabiele, onvoorspelbare omgeving waar je de testuitvoer elke keer opnieuw kan beginnen.

Is waterval anders dan agile?
Waterval of Agile, het testen blijft hetzelfde. Overigens is ook waterval iteratief. Je levert niet in één keer iets op en dit gaat ook in iteraties: Maak ontwerpen, programmeer, test en vind bugs, programmeer en pas ontwerp aan, test en vind bugs, programmeer en pas ontwerp aan, test en vind bugs, ……..

Dus blijft testen hetzelfde?
Begrijp mij niet verkeerd. Ik kan prima mijn werk doen binnen een agile project dan in enig andere methode. Elke organisatie, elk project is anders en je moet je toch altijd aanpassen aan de situatie. Er voor zorgen dat je het testen zo goed mogelijk kan doen.

Op school hebben we SDM geleerd, de ultieme waterval methode. Op project management cursussen leren we dit ook  en zijn we gewend om de ‘boel’ onder controle te houden via een stapel processen waar je ‘U’ tegen zegt.  Is er geen documentatie in een waterval project? Dan gaan we toch door. Is er wel documentatie, dan zijn het lijvige documenten die elk detail proberen te beschrijven.

Een scrumboard met wat taken, een proces die bestaat uit drie stappen (to do, progress, done) en een onzekere eindsituatie. Immers staat alleen de tijd vast bij agile en niet wat je uiteindelijk oplevert. Dit verlies van controle moet wel hard aankomen bij een hoop traditionele IT’ers.

Wennen dus?
Zolang bestaat de IT eigenlijk niet. Ook het principe “testen” is nog betrekkelijk jong. De testgemeenschap is zelf aardig in discussie wat de beste aanpak zou moeten zijn om zo goed mogelijk de kwaliteit van een applicatie te meten. Het is niet anders dan logisch dat we moeite hebben met dit soort IT revoluties.

Want de principes van agile spreken wel aan:

  • Personen en interacties, eerder dan processen en tools
  • Software die werkt, eerder dan lijvige documentatie
  • Samenwerking met de klant, eerder dan onderhandeling over het contract
  • Omgaan met verandering, eerder dan het volgen van een plan

Maar hoe we hier precies mee om moeten gaan, dat moeten we nog wel uitvinden.

——————–
Rob van Steenbergen is een onafhankelijke softwaretester en een actief blogger
Chickenwings Test Consultancy