Blog

Agile tester v.s. niet agile tester

Een tester is toch gewoon een tester?

Dit is een veel gestelde vraag bij bedrijven die in de transitiefase verkeren van waterval/prince2 naar agile of het plan hebben om deze transitie te maken.

Toch zijn er 3 gebieden waarop een agile tester een hele andere tester is dan de traditionele tester (Tmap tester)

Een agile tester moet een aantal persoonlijke skills hebben

Een tester is niet langer de controleur die achteraf alles checkt en de fouten rapporteert. Hij zorgt er samen met het team voor dat de kwaliteit van het opgeleverde product uitstekend is.

  • positief en oplossingsgericht denken en doen, want een Agile team kan alleen optimaal presteren als de sfeer goed is en er open en eerlijk gecommuniceerd kan worden
  • zich tegelijk ook kritisch en kwaliteit georiënteerd tonen richting het product
  • zelf actief op zoek gaan naar de benodigde informatie en niet uitgaan van een afgetekende set documenten die compleet is
  • zelf zorgen dat er goede acceptatiecriteria in de user stories komen samen met het team
  • samenwerken in het team. Denk aan b.v. pair-testing met developers, maar ook met acceptanten en gebruikers
  • om kunnen gaan met wijzigingen en hierop snel anticiperen
  • zelfstandig je werk kunnen plannen en signaleren van eventuele knelpunten in het team en die samen ook oplossen
  • het besef hebben dat je als team verantwoordelijk bent voor (de kwaliteit van) het product. De tester is niet een ´kwaliteits-gateway´
  • snel kunnen leren. Je moet multi-inzetbaar zijn in een klein team

Een agile tester kan meer dan alleen testen

Agile teams zijn klein en doen meestal al het werk van specificeren tot beheer(´You build it, you run it´). Het volstaat niet meer om hierin alleen te kunnen testen. Teamleden moeten meer kunnen en van elkaar leren zodat ze multi-inzetbaar zijn.

  • opzetten en inrichten van testomgevingen en testdata
  • opzetten, inrichten en gebruiken van de benodigde testtools
  • het coachen van andere teamleden op het vlak van testen en kwaliteitsbewustzijn
  • de rol van scrum master op zich nemen
  • het opzetten en uitvoeren van testautomatisering van de uit te voeren regressiechecks, al dan niet samen met een teamlid-ontwikkelaar
  • ´beheer´ werkzaamheden zoals monitoring of deployments

Een agile tester bezit een andere ´Toolbox´

De traditionele tester is veelal in het bezit van de Tmap toolbox waarin een hele set hulpmiddelen zitten die vooral in een waterval traject goed inzetbaar zijn. Voor een agile tester moet deze toolbox worden aangevuld met een flink aantal nieuwe tools. Wat je ons hier niet hoort zeggen is dat de oude toolbox moet worden weggegooid en onbruikbaar is. Er zijn zeker elementen en technieken in de oude toolbox die ook voor een agile tester prima bruikbaar zijn.

  • risico analyse 2.0. Ook een agile tester baseert de testen op daar waar de risico´s te verwachten zijn. Gebruiken al je klanten IE11, ga dan niet de testen uitvoeren in Chrome…. Doe ook geen eenmalige grote risico analyse bij de start, maar 1 bij aanvang voor de algemene gebieden en dan elke maand een kleintje die meer gericht is op de aanpassingen en aanvullingen.
  • exploratory testing. De traditionele methoden leiden veelal alleen tot checks. Deze zijn zeker waardevol en kunnen dan ook prima in een geautomatiseerde test worden gestopt. Zie https://nl.wikipedia.org/wiki/Exploratief_testen voor meer toelichting over exploratory testen.
  • Test Driven Development. Baseer je code op geautomatiseerde testcases. Test first, develop later.
  • Acceptance Test Driven Development.  Acceptatiecriteria en tests worden tijdens het aanmaken van de user stories direct gemaakt. Hierdoor ontstaan in een vroeg stadium herbruikbare regressietest cases en is er een groter begrip in het team over het beoogde doel van de story
  • Behaviour Driven Development. Ontwikkeling van acceptatiecriteria in Gherkin (Given/When/Then) waardoor er minder ruimte is voor interpretatie wat de story moet doen. Tevens zijn er tools die dit kunnen omzetten in automatische testen.
  • Context Driven Testing. Context-driven testers kiezen hun test doelstellingen, aanpak en test documentatie door goed te kijken naar de details van de specifieke situatie. De essentie van context-driven testen is het toepassen van kennis en vaardigheden die passen in jouw specifieke situatie. Niet het toepassen van een standaard recept.
  • Specification by example. De requirements worden opgesteld met realistische voorbeelden in plaats van in abstracte verwoordingen. Deze methode wordt vaak gebruikt bij Behaviour Driven Development
  • De testpyramide en testkwadranten
  •  automatedtestingpyramid-300x214Agile-Testing-Quadrants
  • Bughunts. Een manier om in een ´spelvorm´ bugs uit het systeem te halen samen met stakeholders en gebruikers. Ook prima geschikt om exposure te creëren voor je product en mensen er beter kennis mee te laten maken. Tevens geeft het hele waardevolle feedback over je product. Kijk eens hier voor meer toelichting http://www.ministryoftesting.com/2014/05/bughunts/
  • Crowdtesting. Als je om welke reden dan ook geen automatische regressietest kunt maken, kan dit een alternatief zijn. Je biedt je product aan aan de ´crowd´ en zij testen het dan op de door jou aangegeven wijze. Er zijn diverse aanbieders van deze diensten zoals Applause, Testbirds, Testbats… Wat je natuurlijk wel zelf moet regelen zijn de omgeving, het hoe en wat dat je precies wilt en optioneel kun je ook scenario´s aanleveren die doorlopen moeten worden. Voordelen zijn dat de crowd over oneindig veel verschillende browsers en devices beschikken en je ook localization testen kunt laten uitvoeren als je product internationaal is.

 

Conclusie: we kunnen wel stellen dat een traditionele Tmap tester toch echt iets heel anders is dan een Agile Tester.