Towson Nederland BV

085 877 0920

Beemdstraat 12, 4158 EM Deil, Netherlands

SAFe Silver Partner

©2019 - towson.nl
Privacy policy

Impressum

Algemene Voorwaarden- Trainingen

  • admin31791

Agile Scrum Testing : Voorkom mini watervallen en start eerder met testen



Agile Scrum Testing:


1.Introductie

Dankzij Agile en de Scrum manier van werken leveren teams sneller werkende producten op. Er zit ook een keerzijde aan Scrum.

Teams worstelen met de uitvoering van de testactiviteiten. Enkele veel voorkomende problemen van Scrum teams zijn:


- Testers testen minder zwaar wegens tijdgebrek

- User stories schuiven door naar volgende sprint wegens het niet op tijd af kunnen ronden van alle testactiviteiten

- Testcases sluiten niet aan op de verwachting van de gebruikers

- Gevonden defects worden afgewezen door teamleden wegens verkeerde verwachting

- Negatieve feedback tijdens de Spint review door verkeerde focus.


Eén van de oorzaken is dat veel Scrum teams nog steeds (onbewust) volgens de traditionele waterval methode werken. Iedere user story wordt als een soort mini waterval ontwikkeld.

De user story moet bijvoorbeeld eerst volledig zijn opgeschreven voordat de bouw kan starten. De bouw moet volledig zijn afgerond voordat het testen kan starten, etc.

Kan dit ook anders? Ja zeker, maar voor het antwoord moeten we eerst terugblikken op het verleden, naar de tijd voor het Agile gedachtengoed.


2.Traditionele test activiteiten

Het kaderen van de testactiviteiten voor de introductie van Agile en Scrum was makkelijk.

Testers tekende meteen het “V-Model” en legde je uit dat alle testactiviteiten aan de rechterkant van het V-model plaats vonden. Vanaf de eerste unit test tot aan de uiteindelijke acceptatie test.


V-Model volgens TMap NEXT


Het V-model heeft echter één heel groot nadeel. Het lijkt alsof de testactiviteiten pas gestart kunnen worden nadat de code door de ontwikkelaars is opgeleverd. Dat klopt niet.

Een goede tester heeft namelijk veel meer gereedschappen in zijn toolbox zitten dan alleen testen.

Een tester kan bijvoorbeeld ook reviews uitvoeren van bijvoorbeeld requirements en op technische/functionele ontwerpen.


Als antwoord op deze tekortkoming van het V-model ontwikkelde Paul Herzlich in 1993 het minder bekende “W-Model” waarin reviewen wel is opgenomen als testactiviteit.


W-Model volgens Paul Herzlich


Waarom deze uitstap? Al in 1978 bewees Barry W. Boehm dat de kosten van defects exponentieel toenemen als ze later in het ontwikkelproces gevonden worden. Een bevinding gevonden tijdens een review is velen malen goedkoper te herstellen dan een defect gevonden tijdens het testen.

De wet van Boehm


3.Testen binnen de Scrum teams

Deze modellen lijken tegenwoordig volledig achterhaald. Ze zijn bedacht in de tijd van de traditionele watervalmethode. Om een product in gebruik te nemen volgens de watervalmethode moet iedere fase van het project individueel doorlopen worden.


Met de introductie van Scrum hebben veel organisaties dit model een kwartslag gedraaid. Fases worden nu per user story doorlopen.


De grootste voordelen van deze ontwikkeling zijn:


- De hoogst geprioriteerde user stories worden als eerste volledig opgeleverd

- Niet afgemaakte user stories (met lagere prioriteit) schuiven door naar de volgende sprint

- Feedback van de gebruiker kan direct worden meegenomen in de nog niet opgeleverde user stories


Kijk je echter iets langer naar dit model dan ontdek je dat veel Scrum teams nog steeds volgens de traditionele watervalmethode werken.


“Wat is er gebeurd met het statisch testen zoals reviewen? Geldt de wet van Boehm niet voor Scrum?”


Zeker wel. Bevindingen die worden gevonden in de user stories zijn net als bij bevindingen op de requirements nog steeds vele malen goedkoper op te lossen dan defects die gevonden worden tijdens het testen.


De wet van Boehm toegepast op Scrum



“Wacht even.. Reviewen van user stories? Maar die zijn lang niet zo goed uitgeschreven als traditionele requirements. Kan dit eigenlijk wel?”


Dat klopt. In veel organisaties zijn user stories niet goed uitgeschreven. Maar user stories zijn dan ook geen requirements.

Een tester binnen een Scrum team weet dat gebruikers vroeg of laat hun wensen gaan veranderen. User stories zijn geen requirements die in beton gegoten zijn. User stories zijn geschreven op Post-its en dagen teamleden uit om de face-to-face communicatie aan te gaan met gebruikers.


Dit betekent dat reviews niet langer op een zolderkamertje of in een gesloten hok uitgevoerd kunnen worden. Als tester binnen een Scrum team moet je gaan praten met gebruikers en ze vragen naar welke functionaliteiten ze uiteindelijk in hun producten terug willen zien en op welke manier. Tester moeten proactief opzoek naar acceptatie criteria bij de gebruikers.

Statisch testen binnen een Scrum team is dus van reviewen geëvolueerd naar interviewen.

Gelukkig voor testers is interviewen een andere tool die ze naast reviewen en testen in hun toolbox hebben zitten.


4.Tijdwinst door interviewen te combineren met Behavior Driven Development

De kracht van Scrum zijn de korte communicatie lijnen. Maar als teamleden individueel gebruikers vragen naar hun wensen kan informatie versnipperd raken. Daar tegenover staat dat ieder keer dat een wens opgeschreven en gedeeld wordt je kwaliteit verliest.

Een oplossing voor deze nieuwe uitdaging kan het toepassen van Behavior Driven Development (BDD) zijn.

Met BDD worden interviews uitgevoerd volgens het “Three amigos” principe waarbij de interviewsessies altijd worden bijgewoond door één tester, één ontwikkelaar en één gebruiker.


De belangrijkste voordelen van het gebruik van BDD zijn:

- Een gezamenlijk en gedragen begrip over het beoogde doel van een user story

- Een mogelijkheid om in een vroeg stadium misverstanden te identificeren en op te lossen

- Een beperking van de wildgroei van het aantal discussies en mensen die betrokken zijn bij het ontwikkelen van een user story.

-De mogelijkheid om van gemaakte fouten te leren met betrekking tot het opstellen van een user story.


De manier van vastleggen van acceptatie criteria met BDD biedt ook grote kansen. In traditionele ontwikkelomgevingen worden acceptatie criteria vaak in zinnen vastgelegd die goed te begrijpen zijn voor gebruikers maar polyinterpretabel zijn. Neem bijvoorbeeld de volgende acceptatie criteria:

“Nieuwe gebruikers moeten een bevestigingsemail krijgen en een persoonlijke begroeting op de website”

Voor een doorsnee gebruiker is dit begrijpelijke criteria maar voor zowel testers als ontwikkelaars roepen dergelijke criteria allerlei vragen op zoals:


- Wat moet er gebeuren voor bestaande gebruikers?

- Moet de bevestigingsemail eerst worden verstuurd/ontvangen worden voordat de persoonlijke begroeting wordt getoond?

- Moet de gebruiker eerst zijn ingelogd voor de persoonlijke begroeting?


Andersom als een ontwikkelaar gedacht vanuit de code de acceptatie criteria schrijft is deze vaak te technisch en niet te begrijpen voor een doorsnee gebruiker.

BDD lost dit op door acceptatie criteria vast te leggen in zogenoemde “Gherkin language”. Gherkin is een programmeertaal die zowel door Business als IT goed te begrijpen is. Dir komt doordat de bijbehorende woordenschat niet meer dan 10 woorden is.

Het eerder beschreven voorbeeld ziet er in Gherkin als volgt uit:


Het opschrijven van acceptatie criteria in Gherkin kan meteen in testtools als Cucumber worden ingelezen. Hierdoor is de testcase meteen geautomatiseerd terwijl de acceptatie criteria voor iedereen in begrijpelijke taal beschreven blijft.

5.Het Testing Manifesto

Of je nu de principes van BDD toepast binnen je Scrum team of niet het voorkomen van defects is belangrijker dan het vinden van defects.

Dat testen niet alleen een activiteit is op het einde van het ontwikkelproces wordt ook duidelijk onderstreept in het Testing Manifesto van Karen Greaves en Sam Laing.

The Testing Manifesto volgens Karen Greaves en Sam Lain


Testers binnen een Scrum team kunnen zich beter concentreren op wat gebruikers echt willen in plaats van reactief controleren of het product werkt zoals verwacht. Dit is namelijk een taak die meer en meer overgenomen wordt door geautomatiseerde tests.

Ook zorgt het actief zoeken en vinden van defects vaak voor frictie tussen ontwikkelaars en testers terwijl het gezamenlijk voorkomen van defects juist voor meer samenwerking en vertrouwen zorgt tussen teamleden.


6.De weg naar hogere kwaliteit binnen Scrum teams

Voor organisaties die werken volgens de Agile en Scrum methode en die sneller willen opleveren met hogere kwaliteit tegen lagere kosten is het belangrijk om testactiviteiten onder de aandacht te brengen.

Start eerder met het uitvoeren van de testactiviteiten door o.a. het uitvoeren van interviews waardoor:


- Testactiviteiten minder vaak in tijdnood komen

- Testcases en producten beter aansluiten op de verwachting van de gebruiker

- Defects worden minder vaak worden afgewezen door andere teamleden

- Er meer samenwerking en vertrouwen ontstaat tussen teamleden onderling en met de gebruikers.


Wil je meer weten over Agile Scrum testen en ben je na het lezen van dit artikel geïnteresseerd geraakt?

Neem gerust contact op!

william.van.der.maas@towson.nl









Wij zijn Towson Nederland. Met onze consultants werken wij samen met mooie opdrachtgevers die vooruit willen. Wij geloven in een aanpak op basis van Agile principes om veranderingen succesvol te realiseren. Wij helpen onze opdrachtgevers de veranderingen te realiseren door Agile delivery, training en coaching aan te bieden.

0 views