Blog

Onderzoeker versus geautomatiseerde check-robot

Onderstaand stuk is ook gepubliceerd in het testnetnieuws voorjaarsmagazine van 2016.

De rol van de tester verandert. Van de veredelde analytische check-robot naar de echte tester: de onderzoeker. De reden is dat, mede door de komst van Agile-Scrum,  de handmatige check-robot vervangen kan/moet worden door automatisering. Wat hierbij echter vergeten wordt is dat daarmee het grootste deel van het werk van een tester dus niet geautomatiseerd kan worden. En hier gaat het op dit moment nog grondig mis in ICT-land…

Vraag naar testautomatiseerders

Overal zien we een enorme vraag ontstaan naar testautomatiseerders die de rol van tester moeten overnemen en invullen. Dat is echter de allergrootste fout die je kunt maken. Het automatiseren van checks (en dus niet van testers) is zeker nuttig en zelfs noodzakelijk. Maar het is slechts 25% van het werk dat een tester zou moeten doen. De andere 75% kun je simpelweg niet automatiseren. Deze 75% noemden we tot recent Exploratory (of onderzoekend) testen. Dit omdat zowel het ontstaan van het testgeval alsmede de uitkomst niet vooraf zijn te bepalen. Ik zou er liever voor kiezen om dit gewoon testen te noemen en wat we in het verleden wel testen noemde vanaf nu ´checken´ te noemen. Een onderzoeker volgt geen vaste patronen met vooraf gedefinieerde uitkomsten. Dan is het onderzoek zinloos. Dan bevestig je slechts datgene wat je al weet.

Daarom is de belangrijkste nieuwe vaardigheid voor een tester anno 2016: onderzoeksvaardigheid

Vaardigheid

Zoals het woord onderzoeksvaardigheid al aangeeft betreft het hier een vaardigheid. Geen tooltjes, methodes of trucjes om managers tevreden te stellen met prachtige metrics die de echte werkelijkheid niet weergeven.

Onderzoeksvaardigheid betekent dat je in staat bent een product te testen door met het daadwerkelijke product te gaan experimenteren, door het te gebruiken en het gedrag van het product te observeren, door modellen te maken van het product en door het product te bevragen. Een nuttig hulpmiddel hierbij zijn heuristics, hierover verderop meer.

TN-

Een tester anno 2016 is in staat om het gat te dichten tussen wat we weten en wat we zouden moeten weten om een beslissing te kunnen nemen of het verantwoord is om een product op te leveren naar een klant. Deze beslissing wordt overigens niet genomen door de tester. Deze geeft slechts zo goed mogelijk inzicht in de risico´s. Een tester is ook nooit verantwoordelijk voor de kwaliteit van een product, maar wel voor de kwaliteit van zijn werk.

Onderzoeken

De echte risico´s die de waarde van het product bedreigen zal een tester moeten onderzoeken. Hij zal moeten experimenteren, vragen stellen, modelleren, observeren en bestuderen. De echte risico´s zitten, zeker in de hedendaagse complexe systemen, vaak daar waar je ze niet ziet en daar waar je ze niet verwacht.

TN-Onderzoeksvaardigheden

Een product onderzoeken vraagt richting om het onderzoek ook waarde te geven. Hiervoor zijn ´heuristics´ bijzonder goed bruikbaar. Een heuristic is een feilbare methode om een probleem op te lossen. Feilbaar wil zeggen dat het niet een 100% zekerheid en garantie geeft, maar dat het goed genoeg is. Veel gebruikte heuristics zijn SFDIPOT wat staat voor Structure, Functions, Data, Interfaces, Platform, Operations en Time. Deze heuristics zijn een handvat om je product te testen. De aanpak die ik hanteer is om een product in een mindmap o.b.v. deze (en meestal nog vele andere relevante) heuristics te ontrafelen, en van hieruit samen met het team te bepalen waar de risico´s zitten en waar we onze testen op gaan richten. Welke heuristics relevant zijn is enorm afhankelijk van de aard van het product en zijn omgeving. Tijdens het testen hou je je heuristic en risico´s steeds voor ogen zodat je niet te ver afdwaalt in je testen.

testingmnemonics1

Samenvattend

Beperk je je tot het vervangen van de tester door een set van geautomatiseerde checks, dan zal het gat tussen wat je moet weten over de risico´s van een product en datgene dat je werkelijk weet zeer groot blijven. Daarmee komt direct de klantwaarde van het product in gevaar om je slecht maximaal 25% van waarschijnlijk ook slechts 1 heustic (Functions meestal) hebt ´getest´. Over alle mogelijke andere heuristics kun je geen enkele uitspraak doen en dus is het risico-gat slechts een heel klein beetje kleiner geworden.

Een tester kun je niet vervangen door automatisering, net zin min als dat je testen kunt vervangen door automatisering. Alleen ´checks´ kun je automatiseren. Laten we hopen dat dit besef snel doordringt tot de velen die leven met het beeld dat testen in Agile-Scrum vooral draait om automatisering.