Categorie: Agile testen

In dit deel worden drie ontwikkelmodellen kort besproken en daarbij bekeken hoe deze in principe afgeleiden van elkaar zijn. De ontwikkelmethoden zijn het watervalmodel, het V-model en vanzelfsprekend het Agile ontwikkelmodel.

Het watervalmodel

De ontwikkeling in een klassiek watervalmodel kan als volgt omschreven worden. Als eerste wordt een idee geopperd. Dat idee wordt in business specificaties uitgeschreven waarbij de wensen vanuit de business beschreven worden. De business specificaties worden in functionele specificaties uitgeschreven. Hierbij wordt beschreven hoe een te ontwikkelen stuk software zich functioneel moet gaan gedragen. De functionele specificaties worden uitgeschreven in een architectuur en technische specificaties. De uitgeschreven technische specificaties worden ontwikkeld in componenten van databases tot code en gebruikersinterfaces. Deze componenten worden vervolgens aan elkaar gekoppeld tot een geheel werkend stuk software. Het hele softwarepakket wordt vervolgens aan een test onderworpen. De fouten worden hersteld door het ontwikkelteam. Daarna wordt er nog een korte controle uitgevoerd. Vervolgens wordt de software aan de klant opgeleverd

Het V-model

Het probleem bij het klassieke watervalmodel is dat testen pas betrokken wordt aan het einde van de ontwikkelfase. Testen mag dan een controle uitvoeren, maar door uitlopende ontwikkelingen wordt daar vaak veel te weinig tijd voor ingeschat. Tevens is niet geheel voorbereid en een belangrijke kwaliteitsslag wordt gemist, namelijk het controleren van de documentatie op basis waarvan de software is gemaakt. Testen wordt kortweg te laat betrokken. En het is algemeen bekend dat hoe later fouten gevonden worden in het ontwikkeltraject hoe duurder het is om deze fouten op te lossen. Het is namelijk niet altijd duidelijk waar de fouten het ontwikkelde systeem raken. Dus als een fout wordt opgelost kan het eenvoudig nieuwe fouten introduceren.

Om dit manco tegen te gaan is het V-model ontwikkeld. Het is eigenlijk niets anders dan het aanbreng van een knik op de plek van ontwikkeling in het watervalmodel.

Wat er dan te zien is dat tegenover elke vorm van documentatie een vorm van testen staat. Dat betekent ook dat op het moment dat een eerste stuk documentatie opgesteld wordt, testen al een globaal plan kan opstellen wat er getest moet worden en wat de risico’s in de software gaan zijn. Er kan ook al gecontroleerd worden of er fouten in de documentatie zitten, waardoor deze opgelost kunnen worden nog voordat deze ontwikkeld worden. Er worden Early testcase designs opgesteld, waarbij het vaak is dat de volledige details nog ontbreken, maar het framework er wel al staat.

Wat er met het V-model ontstaat is een kwaliteitsproces vanaf het begin van een project.

Wat grappig is om te zien is dat veel organisaties pretenderen volgens een V-model te werken, maar eigenlijk een watervalmodel hanteren, omdat ze testen niet vanaf dag één betrekken om de kwaliteit te controleren. Testen mag na  het opstellen van de specificaties, eigenlijk aan het begin van de ontwikkeling de testgevallen opstellen om ze vervolgens in meerdere fasen uit te voeren.

Dat is uiteraard wel een verbetering, omdat er meer en dieper getest wordt, maar het is eigenlijk een verlenging van het watervalmodel zonder de voordelen van een V-model te gebruiken.

Grappig genoeg wordt de inzet van testen aan het begin van een project als te duur gezien, terwijl het vinden van een fout in een testfase al vele malen duurder is dan het vinden van een fout in een documentatiefase, voordat software ontwikkeld wordt.

Het agile ontwikkelmodel

Het agile ontwikkelmodel zorgt ervoor dat ontwikkelteams kleine stukken software kunnen maken in korte perioden. Het geheel uitschrijven van een project met complete functionele documenten, uitgebreide technische beschrijvingen en dergelijke wordt achterwege gelaten, zodat er snel een resultaat kan worden neergezet. De klant heeft een directe input en werkt nauw samen om onder andere de betrokkenheid te verhogen.

Zoals dit beschreven wordt is de agile ontwikkelmethode eigenlijk de juiste toepassing van het V-model. Dit wordt verkregen door de ontwikkeltijden kort te houden en direct terug te koppelen en af te stemmen wat er gebouwd gaat worden. Omdat het in feite veel kleine V-modelletjes achter elkaar zijn is het testen binnen een agile project niet slechts testen maar een gehele kwaliteitscontrole (QA of Quality Assurance). Testen dient vanaf moment één in de gaten te houden dat er geen gaten vallen in de specificaties. Alle juiste risico’s vastgesteld worden en alle testsituaties bepaald worden om de kwaliteit van de software binnen een en dezelfde sprint vast te stellen.

Let op: zodra er gesproken wordt dat testen een sprint later wordt uitgevoerd, dan is dit niet meer een schone agile manier van ontwikkelen, maar een afgeleide, waardoor er in principe aan de voordelen van de agile ontwikkelmethode gesleuteld wordt. Vaak overigens niet ten goede. Het doel van één sprint is namelijk werkende software. De basis van de agile ontwikkelmethode.

Het Agile ontwikkelmodel is eigenlijk gebaseerd op de continue terugkoppeling en de wisselwerking tussen alle betrokken partijen. Dit gaat van het samenzitten door ontwikkelaars met de klant, de testgedreven ontwikkeling, de dagelijkse standups, retrospectives, etc. tot het continue verbeteren van het gehele ontwikkelteam en de brede inzetbaarheid van het team in verschillende onderdelen.

In het eerste deel van Testen in Agile projecten zijn we ingegaan op het Agile manifest en waar in de twaalf principes testen kan thuishoren. In dit tweede deel van Testen in Agile projecten gaan we in op de vormgeving van Agile projecten en waar testen betrokken dient te worden.

Agile projecten

Agile projecten lopen van kleine projecten tot grote projecten. In eerste instantie werd gedacht dat met name kleine projecten zich leenden voor de Agile aanpak, maar meer en meer is het besef gekomen dat ook grote projecten op een Agile manier aangepakt kunnen worden. Het is dan wel zeer belangrijk dat de afstemming en communicatie soepel verloopt. Misschien nog wel belangrijker dan in een normaal project. Er zullen namelijk meerdere scrum teams zijn, meerdere onderdelen en deze dienen allemaal op elkaar aangesloten worden. Hoe groot het project ook is, de basis is uiteindelijk een (deel)project wat uitgevoerd wordt door een scrumteam. De belangrijkste taak voor het testen is zorgen dat er een afstemming plaatsvindt over de impact die nieuw ontwikkelde software kan hebben op de bestaande ontwikkeling en op gerelateerde deelprojecten. De sessies waarin dit plaatsvindt worden ook wel eens grooming sessies genoemd.

De samenstelling van een scrum team

Voor het project wordt een team samengesteld. Dit team bestaat uit een product owner. Dit is in principe de klant of de afgevaardigde, danwel gedelegeerde van de klant. Dan is er een scrum master. Deze persoon leidt, of beter gezegd, begeleid het team. Hij is de persoon die moet plannen, bijsturen en faciliteren. Vervolgens zijn er de teamleden, bestaande uit ontwikkelaars die het product maken. Per 2 á 3 ontwikkelaars is er 1 Quality Assurance expert. Teams moeten klein blijven om wendbaar te zijn. Een team van 3 tot 6 ontwikkelaars met 1 tot 2 Quality Assurance specialisten is ideaal.

De kennis en kunde van de teamleden moet complementair zijn. Liefst wel met enige overlap. Uiteraard mogen er wel personen met gelijke kennis zijn, maar dat is alleen verstandig als er veel van dezelfde soort software ontwikkeld moet worden.

Vanuit het testen is de rol te bewaken dat de kwaliteit van de opgeleverde software van voldoende kwaliteit is. Dit betekent het assisteren bij het unit testen en meedenken in de verschillende situaties die de ontwikkelaars moeten bekijken, maar ook vanuit een functioneel perspectief de software aan een test onderwerpen.

Product owner

De product owner is de klant of de gedelegeerde vanuit de klant. Hij is de persoon die het overzicht van de software moet houden en moet toezien dat de software ontwikkeld wordt gericht op het beoogde eindresultaat. Aan het einde van een sprint wordt de ontwikkelde software dan ook in een demo getoond aan de product owner.

Vanuit testen is de afstemming met de product owner belangrijk om te zien of alle juiste onderdelen ontwikkeld worden en of alle juiste gebruikersscenario’s gecontroleerd worden op hun werking. Verder is het belangrijk om de grenzen van de gebruikersscenario’s te achterhalen. Dat zijn de situaties waar testen het interessantste is.

Scrum master

De scrum master faciliteert het Agile traject. Het is de taak van de scrum master om de binding te behouden, het proces soepel te laten verlopen, processen bijsturen, uitspattingen monitoren en zo nodig bijsturen. Verder dient de scrum master te plannen en de kwaliteit te bewaken.

Vanuit testen gezien is het dus het beste dat er een scrum master is met een sterke testbril op. Op die wijze wordt er meer gericht op een test driven development, waarbij er in eerste instantie gekeken wordt het QA proces vanaf moment één in de ontwikkeling in te brengen. Het leven van QA wordt zo veel gemakkelijker gemaakt. Daardoor wordt de kwaliteit van de opgeleverde software naar de product owner ook hoger.

Korte sprints

In plaats van een volledig project uit te schrijven, te ontwikkelen en te testen, wordt de functionaliteit in korte deeltrajectjes gemaakt. Deze trajecten worden sprints genoemd. In een sprint, die zo’n twee weken duurt wordt een geheel werkend stuk software opgeleverd. Wat de kwaliteit van het werkende stuk software is en de conclusie of het stuk software daadwerkelijk werkt is de taak van testen. En deze taak wordt anders ingevuld dan in standaard V-model trajecten. De specificaties zijn niet uitgeschreven en moeten daarmee achterhaald worden door communicatie met alle partijen. De risico’s dienen telkens nieuw bekeken te worden en elk nieuw onderdeel dan impact hebben op een ander onderdeel.

User stories

De functionaliteit die in een sprint ontwikkeld zal worden wordt beschreven in user stories. Dit wil dus zeggen een vanuit de gebruiker benaderde functionaliteit die kort beschreven wordt. Deze beschrijving bevat meestal niet meer dan een geeltje. De aandachtspunten die komen kijken bij de ontwikkeling en de test van een user story zijn essentieel voor de ontwikkelaars, maar ook voor testen. De aandachtspunten beschrijft tevens de risico’s en daar kan met testen op afgestemd worden.

Planning poker

De planning van wat er in een sprint samengevoegd kan worden wordt bepaald door het hele team. Elk teamlid geeft op hetzelfde moment aan hoe lang, volgens het eigen inzicht, het ontwikkelen en testen van een functionaliteit kost. De twee uitersten gaan met elkaar in discussie waarom de uitersten gekozen zijn en de achterliggende gedachten. Na deze discussie wordt nogmaals door alle teamleden de inschatting gegeven. Als er een gelijke lijn is dan wordt deze inschatting genomen.

Door de functionaliteiten in een sprint samen te voegen op basis van de inschattingen wordt bekend wat er in een sprint ontwikkeld wordt.

Planning poker is een volledige team effort, waarbij testen vooral moet kijken hoe lang het nodig is om een stuk software te testen en in te schatten welke mogelijke onderdelen aan een regressietest onderworpen moeten worden. Deze inschatting kan dus behoorlijke impact hebben op de inschatting van een ontwikkeling.

Als voorbeeld: een database aanpassing kan binnen een uurtje gedaan zijn. Het testen van deze aanpassing kan mogelijk een gehele applicaties op meerdere niveaus raken. De poker planning zal dan fors hoger uitkomen dan een uurtje werk, maar eerder op een paar dagen werk.

Wiki’s

Alle documentatie wordt in een wiki geschreven. Het voordeel is dat iedereen deze documentatie door iedereen in het team kan worden gewijzigd. Aangezien iedereen binnen het team aan dezelfde user stories werkt en de user stories op een hoog niveau beschreven worden kunnen alle teamleden details toevoegen die ervoor zorgen dat de software beter gebouwd wordt en daardoor beter getest wordt.

De rol van testen en met name QA in dit geval is zorgen dat de documentatie in voldoende detail beschreven is om te zorgen dat de software goed gebouwd wordt. Tevens is het de taak van QA om te zorgen dat de gaten opgespoord worden en door de beschrijving van de details de impact op andere onderdelen of systemen helder wordt.

Pair programming

Pair programming is een sterkte techniek waarbij twee ontwikkelaars samen aan 1 pc werken. Hierdoor wordt aan meer details gedacht en wordt door twee personen naar een functionaliteit gekeken, waardoor hogere kwaliteit geleverd kan worden.

Naast pair programming bestaat er ook pair testing. Pair testing is door twee testers werken achter 1 pc, waardoor er twee andere blikken geworpen worden op de software. Het gaat, net als pair programming, niet sneller, maar wel beter en dieper binnen dezelfde tijd.

Retrospectives

Retrospectives zijn sessies waarbij terug gekeken wordt op de afgelopen sprint. Er wordt geanalyseerd wat goed is gegaan en wat minder goed is gegaan. Er wordt tijdens deze sessies door elk van de teamleden enkele hun bevindingen genoteerd. Al deze punten samen worden vervolgens door de alle teamleden aan een stemming onderworpen. Zo komen de grootste aandachtsgebieden voor het hele team naar boven. Uiteraard is het niet zo dat als in het eigen werkgebied iets niet lekker liep er vervolgens niets mee gedaan gaat worden. Vanuit het eigen werkgebied kan dat gewoon opgepakt worden.

De taak van het testen en met name QA is met een blik op QA naar de verbeterpunten kijken. Verder is het belangrijk om te kijken hoe vanuit het testen de belangrijkste aandachtsgebieden meegenomen kunnen worden in het gehele QA proces. QA begeeft zich namelijk overal in de Agile ontwikkeling.

Standups

Elke dag wordt in 15 minuten of minder kort besproken wat ieder teamlid gedaan heeft, wat het teamlid van plan is te gaan doen en wat de knelpunten zijn. Dit wordt gericht aan het team om het team te informeren. Het is belangrijk dat discussies voorkomen worden. Discussies worden offline gehaald.

Vanuit testen zijn de standups essentieel om de testen te focussen op de knelpunten en te achterhalen waar fouten in de software gemaakt kunnen worden.

Agile testen is een buzzword. Wat is nu nu precies agile testen, of beter gezegd het testen in agile projecten? En hoe kan dit testen het beste vorm gegeven worden? Als eerste in de serie ‘testen in Agile projecten’ wordt het Agile manifest en de principes waaruit het bestaat bekeken.

Er wordt veel gepraat over Agile softwareontwikkeling en agile testen. Hoewel er veel gepraat wordt blijkt in de praktijk dat veel organisaties niet weten waar testen precies in Agile softwareontwikkelingsprojecten past. Misschien nog belangrijker weten organisaties niet wat het belang van testen in Agile projecten is. Dit artikel gaat daarop in.

Het Agile manifest 
Het manifest voor Agile software ontwikkeling is opgesteld door 17 ontwikkelaars van verschillend pluimage in een dagenlang forum, waar ze over weinig eens konden worden. Over een ding werden ze het wel eens en dat is dat een Agile manier van software ontwikkeling voor een hogere kwaliteit en klanttevredenheid kan zorgen. Het Manifest voor Agile Software Ontwikkeling wat ze hebben opgesteld bestaat uit vier onderdelen wat eigenlijk voorkeuren zijn. Deze vier onderdelen komen voort uit 12 principes. De vier onderdelen/ voorkeuren zijn:
·       Mensen en hun onderlinge interactie boven processen en tools
·       Werkende software boven allesomvattende documentatie
·       Samenwerking met de klant boven contractonderhandelingen
·       Inspelen op verandering boven het volgen van een plan

Er zijn 12 principes die het Agile manifest vormen. Deze 12 principes gaan met name in op software ontwikkeling. Het agile manifest is namelijk opgesteld door 17 ontwikkelaars. Waar testen binnen deze principes valt wordt hieronder beschreven.

Principe 1. Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.
Tevredenheid van de klant verkrijg je door betrokkenheid van de klant. De klant is tevreden als zijn wensen werken. Deze werking bewijs je door een test. Door een early testcase design en een review proces kan direct aan de klant teruggekoppeld worden wat de software zou moeten doen. Met name op de grenzen van de functionaliteit. De klant kan daarmee vroegtijdig bijsturen.

Principe 2. Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.
De klant heeft altijd wijzigende behoeften naar nieuwe inzichten. Het verwerken van deze behoeften op het juiste moment en op de juiste wijze is een van de doelen van het project. Testen moet ervoor waken dat de wijzigende specificaties in de software gecontroleerd worden. Verder is het zaak te controleren of aangrenzende of betrokken onderdelen nog juist blijft werken.

Principe 3. Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.
Werkende software is één. Werkende software die waarde toevoegt aan de klant is een ander. Alleen een goede controle bewijst dat de software werkt zoals gewenst.

Principe 4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
Het samenwerken van de mensen is waar een bruggenbouwer als een tester optimaal van pas komt. Door vertalingen en controles, creatieve ideeën en kritische vragen houdt een tester zowel de ontwikkelaar als de business scherp en gefocuste.

Principe 5. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
Hoewel dit een van de primaire taken van de scrum master is, is testen de bewaker van de kwaliteit van de software en de kwaliteit van de processen. Daarom zou een scrum master met een sterke testachtergrond en enige kennis van development de ideale scrum master zijn en niet zo zeer een sterke development achtergrond met enig gevoel voor testen. Testers staan over het algemeen open voor creatieve ideeën vanuit development, terwijl development van nature testen iets meer zal zien als een noodzakelijk kwaad.

Principe 6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
Communicatie en heldere notatie zijn onderdelen waar testen bij van dienst kan zijn. Daardoor wordt een soort van test driven development gecreëerd. De basis voor testers is een helder stuk documentatie. Deze moet kort en lean blijven, maar wel dermate helder dat beschreven is wat de klant wil en wat development moet maken.

Principe 7. Werkende software is de belangrijkste maat voor voortgang.
Alleen door een terdege controle is vast te stellen dat software juist werkt en dat de reeds ontwikkelde software nog steeds juist werkt.

Principe 8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.
Agile wil zeggen dat iets wendbaar is. Testen kan goed in de gaten houden dat de processen niet rigide worden. Testen dient daarom ook zelf flexibel te zijn en continu aan te passen zijn aan de omstandigheden. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

Principe 9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.
Testen kan met early test plans en early testcase design zorgen dat fouten in het design opgespoord worden. Gaten worden door een snelle analyse blootgelegd. Vooral belangrijk is de continue en snelle wisselwerking van testen met development. De wederzijdse inzichten van testen en development zorgen ervoor dat een hoge kwaliteit software behaald wordt.

Principe 10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.
Wellicht vreemd, maar juist door een kritische tester kan voorkomen worden dat er op ontwikkelingen doorgeschoten wordt. Testers zijn de bewakers van de stories en zien eriop toe dat er ontwikkeld wordt wat binnen de stories als wens wordt neergelegd.

Principe 11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
Door de oplossingsrichting vrij te laten wordt creativiteit maximaal gestimuleerd binnen de technieken die op dat moment voorhanden zijn. Testers bewaken daarbij de kwaliteit en de haalbaarheid en testbaarheid van technieken en de risico’s die gelopen worden bij de verschillende oplossingen. Fouten worden vanzelfsprekend daar gevonden waar de risico’s het grootst zijn.

Principe 12. Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.
Testen is de bewaker van kwaliteit. Testen is de rapporteur van kwaliteit en het proces. Daarom kan testen vanuit het kwaliteitsperspectief uitstekend zien hoe zaken verbeterd kunnen worden en mogelijk hoe deze geïmplementeerd kunnen worden. Dit laatste is met name eenvoudiger naar mate er meer ervaring is.

Er kan dus wel degelijk gesteld worden dat testen een essentieel onderdeel vormt in agile softwareontwikkeling. Op alle twaalf principes is quality assurance nodig. Testen wordt wel iets breder getrokken door het testen en quality assurance te noemen.