Er zijn meerdere momenten tijdens mijn werk als tester, waarbij ik mezelf afvraag wat testen is en hoe ik dat het beste kan uitleggen aan andere mensen. Deze andere mensen kunnen collega's zijn in andere rollen, met een andere kijk op het testen, of mensen die helemaal geen beeld van testen hebben.
Dit is een herschreven versie van een blog wat ik wilde maken met een reactie op veel vacatures die ik zie op bijvoorbeeld LinkedIn. Ik vond dat de vacatures zich te veel met het uitschrijven en uitvoeren van scenario's bezighielden. Er is geen of te weinig aandacht voor het analyseren en exploreren van het op te leveren product, waarbij belangrijke, niet op voorhand bedachte, informatie naar boven kan komen.
Naarmate ik meer schreef hoe meer ik zelf in een valkuil terecht kwam en het alleen maar had over mitigeren van risico's. Ik werd er terecht op gewezen door mijn collega Rob van Steenbergen. Met zijn input ben ik teruggegaan naar mijn figuurlijke tekentafel.
Wat is testen?
Terug naar de basis. Ik stelde mezelf de vraag: “wat is testen?” Bij mijn huidige opdracht merk ik dat ik het lastig vind om het uit te leggen. Ik weet wat ik wil bereiken en zelfs hoe ik het kan bereiken, maar het goed uitleggen lukt mij nog niet. Ik kan wel met de vinger wijzen dat andere mensen een andere kijk erop hebben en niet open staan, maar dat is niet waar.
Misschien dat ik in mijn eigen uitleg te diep ga met betrekking tot context, omdat deze ook bepaald kan worden vanuit risicosessies en het bepalen van acceptatiecriteria. Wat ik wel zeker weet, is dat ik bij de ‘algemene’ uitleg risico's mis.
Testactiviteiten
Met het bovenstaande is er een betekenis van testen gegeven. Er kan eeuwig gediscussieerd worden over de details. Ik ga er echter gemakshalve vanuit dat we het erover eens zijn dat het gaat om het verkrijgen van inzicht op de risico's en kwaliteit van het product. Want hoe wordt dit inzicht verkregen? Hiervoor zullen verschillende activiteiten uitgevoerd moeten worden.
Product & Project Outline
Een goed begin is het vastleggen van de eigenschappen van het op te leveren softwareproduct in een product outline. Dit kan bijvoorbeeld met behulp van een mindmap. Ik ben daar zelf nog niet zeer bedreven in, maar dat is een kwestie van veel doen. In een product outline worden bijvoorbeeld de scope, functionaliteit, autorisaties, programmeertalen, en hard- en software architectuur genoteerd.
Wanneer deze eigenschappen uitgeschreven zijn, zullen er al de nodige risico's gevonden worden met betrekking tot het softwareproduct. Denk daarbij aan de juiste autorisaties en het afschermen van datagevoelige schermen en API's, of functionaliteit dat consequent werkt en goed wordt afgevangen mocht er toch iets verkeerds gaan.
Een product outline is iets wat een tester prima kan maken en kan delen met het team. Zelfs met het ophalen van de benodigde informatie kan de tester al inzichten en kennis delen, waardoor er nog vroeg geacteerd kan worden op nodige veranderingen.
Naast een product outline is het ook handig om een project outline te maken. We hebben het dan over bijvoorbeeld de samenstelling van het team, afhankelijkheden met andere teams, budgetten, deadlines, en autorisaties tot systemen en/of testdata. Ook hier zullen snel risico's gevonden kunnen worden die het leveren van het softwareproduct in gevaar kunnen brengen. Denk aan het niet hebben van de juiste bezetting, of te veel afhankelijk zijn van een ander team. Of iets wat ik zelf meegemaakt heb, dat de testbaarheid in gevaar komt door slechte en/of te weinig testdata om test scenario's echt goed te kunnen testen.
Risk storming
Met de product outline is er een sterke start gemaakt met het in kaart brengen wat het softwareproduct moet doen. Maar niet alle risico's zullen eruit geschud kunnen worden. Het zijn voornamelijk de voor de hand liggende, of gemakkelijk te herleiden risico's zijn. Om nog meer risico's bloot te leggen, kunnen er nog andere activiteiten georganiseerd worden door de tester. Eén van de mogelijke methoden die hiervoor gebruikt kan worden is een risk storming sessie. Dit is een oefening waarbij het team gezamenlijk risico's identificeert, prioriteert en mitigeert op thema's als architectuur, oplevering en onderhoud. Er wordt hierbij meer aandacht gegeven aan de kwaliteitsattributen, dan de functionele eisen en wensen.
Uitschrijven van scenario’s
Wanneer de wensen, eisen en risico's op tafel liggen heeft de tester genoeg informatie om te verwerken en komen op de activiteit wat altijd onder de aandacht ligt bij de vacatures. Het schrijven van de test scenario's op functionaliteit en kwaliteitsattributen. Het liefst zijn deze scenario's al bekend bij het bespreken van het op te pakken werk (denk aan stories/tickets wanneer men volgens Scrum werkt). We moeten ons er ook van bewust zijn dat dit alleen nog maar de known knows zijn met betrekking tot de risico's (wensen en eisen) en dat er ook nog unknows zijn.
Exploratory testing
Met het uitvoeren van bovenstaande technieken is er een hoop werk tevoorschijn gekomen. Hiervoor zal ongetwijfeld onvoldoende tijd voor zijn om alles uit te voeren. Met het team, onder leiding van de expertise van de tester kan er een werkverdeling afgesproken worden tussen de verschillende teamleden. We beantwoorden o.a. de volgende vragen:
Exploratory testing moet ons helpen om de eerdergenoemde unknows boven tafel te krijgen. Dit zal deels ontstaan vanuit ervaring van de tester en deels door het uitvoeren van eerder bepaalde scenario's die bij het uitvoeren vragen oproepen of kansen laten zien. Hier ligt de echte kracht van de tester. Dit is waar de kritische blik en het eigenwijs anders doen dan uitgelegd is gaat schijnen. Dit is ook waar het beeld vandaan komt, dat testers alles maar slopen.
Maar als we eerlijk zijn wordt hier veel te weinig aandacht aan gegeven en is er vaak zelfs geen tijd voor. Daar zullen verschillende redenen voor zijn, of dat nu vanuit management komt of slecht georganiseerd is binnen het team zelf. Ik zou graag zien dat bedrijven de waarde inzien van exploratory testing en soortgelijke testtechnieken.
Rapporteren
Tijdens en na al het testen heeft de tester inzicht gekregen in de kwaliteit van het product, in de context waarbinnen het gebruikt wordt en welke risico's daarbij gelden. Er zijn verschillende manieren om te rapporteren en elk bedrijf (en afdeling) zal daar afspraken over hebben hoe zij dat willen hebben. Het rapporteren is uiteraard niet alleen aan het einde, maar een activiteit dat in verschillende fases terugkomt, want hoe eerder er gerapporteerd wordt, des te sneller kan er actie ondernomen worden indien dit nodig is.
Over de gehele linie werkzaam
Ik heb zeker niet alle activiteiten uitgewerkt, er is nog een hoop meer te bedenken wat een tester doet, of kan doen. Maar wanneer we naar de testactiviteiten kijken, kunnen we al vaststellen dat de tester in alle fasen van het ontwikkeltraject betrokken is of behoort te zijn. Vanaf het opstellen van de project/product outline tot en met het delen van bevindingen en inzicht in risico's en kwaliteit, wij zijn meer dan bureaucraten die scenario's opstellen en uitvoeren om vervolgens een rapport te overhandigen. We zijn continu bezig met ophalen, verwerken en delen van informatie door middel van verschillende activiteiten. En hoewel het uitwerken en uitvoeren van testscenario's een belangrijk onderdeel is van ons werk, is dat zeker niet alles. Wanneer de tester voldoende ruimte en steun krijgt om de juiste activiteiten uit te voeren, zal de ware kracht van de tester te zien zijn: het kritisch zijn, het uitproberen en het kleuren buiten de lijntjes, om er zo zeker mogelijk van te zijn dat risico's geborgen zijn.
Alain Bultink | Managing Director
[email protected]
06-15361077
Benno Kuipers | Directeur
[email protected]
06-52600438
Emilie Lamers | Directeur
[email protected]
06-15653500