Als je een tester vraagt of hij een applicatie wil testen dan wil hij als eerste weten of de applicatie beschreven is. Is er een uitgewerkt functioneel ontwerp of een andere vorm van ontwerpdocumentatie aanwezig waarin beschreven staat hoe de applicatie is opgebouwd en wat de functionaliteit is? Een tester heeft dit nodig om hieruit zijn testcases te herleiden voor de testen die hij uit gaat voeren.
Geldt bovenstaande voor alle testtrajecten? Nee, niet helemaal, want als we kijken naar een Agile testtraject dan is het belangrijk om werkende software op te leveren. Wat betreft uitgewerkte documentatie wordt dit gewaardeerd, maar is het zeker geen must.
Wat betekent Agile Testing nou eigenlijk. Waarom zou ik hier voor kiezen en klopt het dat ik echt geen testcases nodig heb om mijn testen goed uit te voeren?
In een waterval ontwikkeltraject is een in detail uitgewerkte ontwerpdocumentatie uitermate belangrijk om met de bouw en test te kunnen starten. Binnen een Agile-traject niet, want het Agile Manifesto zegt het volgende over documentatie: 'Wij waarderen werkende software boven uitgebreide documentatie'. Het feit dat er dus eerder wordt gekeken naar goed werkende software boven uitgewerkte documentatie heeft tot een zeker spanningsveld geleid tussen ontwerpen in traditionele omgeving en ontwerpen in een Agile omgeving.
Agile testing is een methode die voornamelijk in kleine projecten wordt gebruikt, omdat hier persoonlijke communicatie erg belangrijk is. Doordat er weinig is gedocumenteerd, ben je als tester genoodzaakt om over alles waar je over twijfelt navraag of onderzoek te doen. Het is fijn dat je dan meteen de betrokken personen kunt raadplegen om te vragen hoe het ook al weer zat. In een groot project waarbij je ook nog eens te maken hebt met externe partijen gaat dit allemaal niet zo makkelijk. Hier komen de uitgewerkte functionele specificaties om de hoek kijken. Natuurlijk kun je wanneer je twijfelt de betrokkenen benaderen, maar het is de vraag of deze meteen reageren en of deze het antwoord weten.
Agile Manfesto
Het Agile Manifesto stelt dat goede software wordt gemaakt door personen en interacties, eerder dan door processen en tools, software die werkt, eerder dan lijvige documentatie, samenwerking met de klant, eerder dan onderhandeling over het contract en omgaan met verandering, eerder dan het volgen van een plan.
Het Agile Manifesto laat duidelijk zien wat belangrijk is in een Agile-traject. Om de bouw en test van een applicatie goed uit te voeren, wordt er software ontwikkeld in korte overzichtelijke perioden (timeboxes), die 'iteraties' genoemd worden. Het is de bedoeling om na iedere iteratie iets bruikbaars op te leveren en uiteindelijk zal dit (als het allemaal goed gegaan is) moeten gaan leiden tot een succesvolle release. Agile-testen houdt ook in dat je moet inspelen op veranderingen. Als dit gebeurt moet je als tester niet in paniek raken, maar een risicoanalyse uitvoeren om te kijken wat er allemaal getest moet worden om de impact van de change goed op te vangen.
Als team hiermee omgaan
Hoe moet je hier als team nou mee omgaan? Wat gaat dit betekenen voor elke oplevering? Zullen we in staat zijn om als team op tijd op te leveren? Dit zijn natuurlijk vragen die moeilijk beantwoord kunnen worden. Zoals we weten is elk project anders en ligt het voornamelijk aan de teamleden om hier goed mee om te gaan. Zo is het gebruikelijk om bij toepassing van een Agile-methode om een intake/review moment in te plannen. Er wordt dan gekeken of de requirements goed genoeg zijn om mee te beginnen. Ook wordt er in deze sessie de mogelijkheid gecreëerd om vragen te stellen aan de functionele ontwerper. Deze zal de vragen dan zo goed mogelijk beantwoorden voor zover deze beantwoord kunnen worden.
In deze fase wordt er een begin gemaakt met wat er gebeuren moet. Naarmate we verder zijn in deze fase zal er meer domeinkennis worden opgebouwd en zullen de nodige vaardigheden verder zijn ontwikkeld. Hierdoor zal het begrip wat 'noodzakelijk' beschreven moet zijn, steeds minder diep en breed zijn.
Conclusie
Agile Testing is goed toe te passen, mits het niet om een te groot project gaat. De Agile-methode zegt niet dat documentatie niet belangrijk is, maar juist dat de aanwezige documentatie zo veel mogelijk gebruikt en toegepast moet worden. Daarnaast beschrijft de Agile methode wat het team nodig heeft om zo effectief mogelijk werkende software op te leveren. Met andere woorden een prima methode.
Wat uitdagender is; hoe test je de kwaliteit van het testen in Agile project? En welke verantwoordelijkheid ken je hieraan toe?
@Henri: heel simpel. zorg dat je een Definition of Done (DoD) hebt.
DoD is een “checklist van de noodzakelijke waardevolle activiteiten, waarmee de kwaliteit van de functionaliteit en niet de werkelijke functionaliteit beoordeeld wordt”
Voor meer info over DoD en een aantal voorbeelden, zie bijvoorbeeld:
http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
In tegenstelling tot Waterval of RUP, wordt het Scrum Team afgerekend en niet het individu.
Als Agile testen een methode is, veronderstelt dit een methodische aanpak en dus structuur. Ik betwijfel of dit zover is. Ook bestaan er vele vormen van testen. Welke van de vele bedoelt de auteur?
Los daarvan: Ik veronderstel dat agile testen eenzelfde kortcyclische en beperkte diepgang/detail beoogt als agile ontwikkelen. Als snelle realisatie een eis is en 100% betrouwbaarheid niet, moeten we vooral ook agile testen. Eens dus met de auteur.
@Pep
Je lijkt er nu vanuit te gaan dat er een apart team is dat op een Agile manier aan het testen is. Naar mijn mening hoort er een tester onderdeel uit te maken van het Agile team. Het hangt waarschijnlijk wel af van het soort Agile invulling, maar het lijkt me sterk dat er een Definition of Done is waar niet op z’n minst het werkwoord ’testen’ op de een of andere manier in staat.
Helemaal zonder leidraad testen is overigens onbegonnen werk, het enige wat je dan kunt vaststellen is hoe een applicatie zich gedraagd na een bepaalde stimulans. Je kunt nooit zeker weten of het waargenomen gedrag de juiste is (het kan zelfs de bedoeling zijn dat het elke keer anders reageert).
Het gaat al mis bij “werkende software”. Software werkt altijd, de vraag is alleen of het ook doet wat jij gewenst had. Er zijn natuurlijke meerdere wegen die naar Rome leiden. Eén ding weet ik zeker na jaren testervaring met diverse methoden incl. Agile en LMW (laat maar waaien): succes valt of staat bij goede designers en bouwers én testers. Die drie-eenheid zorgt voor de kwalitatief goed “werkende” software. Agile doet hier een gooi naar, maar het is nog veel belangrijker om als tester na te gaan hoe het team eruit komt te zien en welke methode daar het beste bij past.
Brahim,
Je verwijst naar “de agile methode”, maar ik ben ‘m nog niet tegengekomen. Agile is een paraplu begrip waar meerdere methodes onder vallen. Scrum is een Agile teammanagement framework, eXtreme Programming is een Agile softwareontwikkelaanpak, DSDM/Atern en RUP op Maat zijn Agile methodes die meer op middelgrote projectteams gericht zijn.
Daarnaast stel je: Hoe moet je hier als team nou mee omgaan? Wat gaat dit betekenen voor elke oplevering? Zullen we in staat zijn om als team op tijd op te leveren? Ik zal ze beantwoorden:
1) Je moet hier als team mee om gaan door inderdaad de tester in je team op te nemen en hem te betrekken bij alle relevante technische en functionele beslissingen. Dan kan hij namelijk de beste testscripts schrijven en hij kan de rest vh team helpen om rekening te houden met het testen. Daarmee voorkom je bottlenecks voor het team.
2) Voor de oplevering betekent dit dat ELKE oplevering GETEST is, tot het niveau dat de Definition of Done aangeeft. Er is dus in principe geen separaat testteam of testtraject, behalve voor “exclusieve” testsoorten die moeilijk in te bedden zijn binnen de iteratie. Maar voor die testsoorten bouw je dan wel weer een feedback loop in de iteratie in (om te voorkomen dat je laat constateert dat je vroeg een fout hebt gemaakt).
3) In een Agile team ben je ALTIJD in staat om op tijd op te leveren, omdat niet de tijd flexibel wordt gemaakt maar de scope. Je stopt dus 2 a 3 dagen voor het eind vd iteratie met het oppakken van nieuwe user stories en zorgt dat alle stories voldoen aan de DoD. Mis je er een, dan weet je de volgende keer dat je (nog) eerder moet stoppen met het oppakken van nieuwe stories. Door kwaliteit op tijd op te leveren, lever je waarde.
zie ook http://www.agileopmaat.nl
Oja, en voor wat betreft die leidraad: die is er echt wel hoor. Alleen niet meer in de vorm van een document maar in de vorm van een team met een klant waaraan je vragen kan stellen. Natuurlijk is er nog wel het een en ander gedocumenteerd (denk aan interface specificaties). Alleen vinden agile teams (terecht) dat interactie met teamleden over een onderwerp belangrijker is dan het (vaak zonder multidisciplinaire interactie) opschrijven ervan in een document en dat “over de muur gooien”.
Ik mis in het verhaal het uitgangspunt dat je niet alleen tester bent maar ook ‘ontwikkelaar’. Idealiter zou je ook moeten kunnen bouwen en ontwerpen. Het idee in scrum is dat je met z’n allen een systeem ontwikkeld en niet sec naar je eigen dingetje kijkt.
Gisteren vroeg mijn dochter Aisya van 10 aan mij, “pappa wat heb je vandaag gedaan”? Ik dacht oei.. hoe ga ik dat uitleggen.
Ik zei: “als jij nu een bedrijf A(isya) bent en ik bedrijf B(enno), en jij (A) wil graag dat een toren gemaakt wordt en dat B dit voor je maakt, dan vraag je aan B hoeveel dat kost en dan vraagt B aan A om te beschrijven wat A wil hebben zodat B dit kan maken. En dan zegt A tegen B dat dit 10 euro kost en dat dit goed is”. Stel nu dat B de toren klaar heeft en jij (A) de toren in ontvangst neemt, hoe weet je dan dat je ook hebt gekregen wat je wilde hebben?”. Toen moest ze even denken.. en zei “dat moet je dan controleren”.. toen zei ik “juist! dat is de taak van pappa om dit te (laten) controleren”. (het verhaal ging nog verder door)…
Ik lees hieronder: ‘Wij waarderen werkende software boven uitgebreide documentatie’. Dat is an sich een lose kreet aangezien je niet objectief en aantoonbaar kan bepalen of de software ‘werkend’ is zonder ‘documentatie’. Oftewel een zogenaamde drogreden.
Daarna staat er ook dat (vrije vertaling) een tester eigenlijk domein kennis op moet doen en navraag moet doen als hij vragen heeft. Dat geldt ook voor een V-model project. En als de testbasis is de ‘hoofden’ zit dan kan je niet objectief aantoonbaar maken dat de software werkt zoals alle stakeholders ‘m bedoelt hebben. RUP van Ivar Jackobson is een vorm van Agile en daar wordt wel degelijk voldoende vastgelegd in documentatie om zonder concessies testen voor te bereiden en uit te voeren. Daarnaast is de ‘gereedschapskist’ van de tester de testtechnieken. Formele testtechnieken worden gebruikt om gestructureerd obv documentatie testgevallen af te leiden. Zonder gedocumenteerde testbasis zal je dus minder testgevallen kunnen maken (grotere kans op bevindingen en fouten in productie). Als je alleen obv domein kennis gaat testen (informele testtechnieken) dan mis je dus een heel scala aan testgevallen. En als zaken niet gedocumenteerd zijn is de kans groot dat wat tester A in zijn hoofd is anders is dan tester B en nog erger business X. Nog een voordeel van documenteren is dat je reviews toe kan passen. Iedereen die een document ooit heeft gemaakt weet dat je ‘blind’ wordt op een gegeven moment voor je eigen tekst.
Wanneer je een document maakt wordt je als eerste extra gedwongen na te denken voordat je zaken SMART op papier zet, en ten tweede kunnen de teamleden vanuit diverse invalshoeken de tekst reviewen en er vroegtijdig fouten uit halen (zie wet van Bohm). Zonder documentatie is de kans groter dat ‘denkfouten’ onopgemerkt blijven, dat teamleden een ander beeld hebben bij hetzelfde, en dat de kans op fouten in productie groter wordt aangezien je minder af kan dekken mbv testgevallen. Ook al zit je elke dag bij elkaar en praat je met elkaar… (alsof dat niet bij een V-model project gebeurt).
Ik denk dat het ook geen tester was die deze tekst heeft geschreven aangezien er staat “Agile Testing is goed toe te passen, mits het niet om een te groot project gaat.” Tsja… wat is dan een ‘groot’ project… daar valt natuurlijk elke tester over…
En het zit vol met drogredenen “De Agile-methode zegt niet dat documentatie niet belangrijk is, maar juist dat de aanwezige documentatie zo veel mogelijk gebruikt en toegepast moet worden” — wordt in een V-model project de documentatie dan niet gebruikt?
En “Daarnaast beschrijft de Agile methode wat het team nodig heeft om zo effectief mogelijk werkende software op te leveren. Met andere woorden een prima methode.”. Echter beschrijft hij niet wat dan beschreven staat in de agile methode wat zorgt dat het team zo effectief mogelijk werkende software kan opleveren, en waarom het dus een prima methode is.
En is naast effectiviteit, efficiency niet belangrijk dan?
Korting Agile levert meer vragen dan het succesvol realiseren van een ict-project, met de beoogde resultaten. Leuk bedacht, maar bedrijven zullen terughoudend met de poging toe te passen van Agile.