zondag 17 juni 2018

Testtools zijn geen doel op zich!

In mijn huidige baan ben ik vooral bezig met testautomatisering. Een baan waar je niet zonder testtool kan. Maar ook buiten de testautomatisering kwam en kom ik regelmatig de behoefte aan testtools tegen. Zeker als testautomatiseerder zou je verwachten dat ik een groot fan ben van het invoeren van testtools. Ik ben het niet. In mijn geval: juist door vele testautomatiseringsprojecten ben ik er alleen maar voorzichtiger mee geworden.

Ben ik tegen testtools? Nee, natuurlijk niet. Testtools, of ze nu zijn om bevindingen vast te leggen, test cases vast te leggen, testomgevingen te beheren of, natuurlijk, testen te automatiseren, kunnen heel waardevol zijn. Ze kunnen het werk van de tester verbeteren, versnellen of vereenvoudigen.

Een testtool lost veel problemen niet op
 
Wat is dan het probleem? Het probleem is dat het testtool als de oplossing wordt gezien. Om het voorbeeld bij testautomatisering te houden: testautomatisering wordt vaak als oplossing gezien om beter en sneller de regressietest uit te voeren. In een organisatie met goede, regelmatig uitgevoerde en goed onderhouden handmatige regressietesten is testautomatisering inderdaad een goede stap vooruit. In een organisatie waar de regressietesten van matige kwaliteit zijn, regressietesten bijna nooit worden uitgevoerd of eigenlijk niet worden onderhouden is testautomatisering heel erg moeilijk.

Datzelfde geldt voor het vastleggen van bevindingen of testcases. Een goede bevindingenregistratie kan heel handig zijn. Maar als men nu de tijd niet heeft of de behoefte niet ziet om bevindingen vast te leggen, gaat een invoer van een tool hiervoor niet helpen. Als de bevinding vaak onduidelijk is of moeilijk reproduceerbaar, gaat een testtool dit probleem niet oplossen. Datzelfde geldt voor testcases vastleggen. Testcases hergebruiken kan heel waardevol zijn. Maar als je nu nauwelijks testcases hergebruikt, waarom zou een testtool voor het beheer van testcases dat veranderen?

Elk testtool heeft zijn eigen eisenpakket

En een ander probleem. Testtools kunnen tijd besparen. Maar ze kunnen ook meer tijd kosten op momenten, dat je dat niet wil. Omdat elk testtool zijn eigen eisen heeft. Bevindingenregistraties verplichten je om meer gegevens in te vullen. Gegevens, die daarvoor niet werden ingevoerd. En misschien wel terecht. Als je altijd test op dezelfde testomgeving, is het bijhouden van de testomgeving niet nodig. Als je direct samenwerkt met een ontwikkelaar tijdens het testproces en daarom de bugs direct overlegd, is een omschrijving van de bug, zelfs het aanmaken van de bug, misschien wel onnodige administratie. En zo heeft elk testtool zijn eigen zaken, die je moet uitvoeren, om met het testtool te kunnen werken. Zijn die zaken voor jou wel echt nodig? Wegen ze op tegen de voordelen?

Van doel naar middel

Een testtool is een hulpmiddel bij het oplossen van een testprobleem. En vaak slechts een deel van de oplossing. Toch wordt het al snel een doel, zeker door de manier waarop bedrijven en voorstanders het verkopen. Na de invoering van testtools zal alles beter gaan werken. Wat er nog meer nodig is voor een goede invoering, kunnen of zullen zij je vaak niet vertellen.

Hoe kan je dat zelf controleren. Simpel: testtools verbeteren of versnellen een bestaande testproces stap. Wat ze niet doen: het invoeren van een nieuwe stap in het testproces. Dit kan op detail niveau zijn, zoals het invoeren van bepaalde gegevens bij een bevinding, op wat hoger niveau, zoals het schrijven van een testscript voor een testcase of op een heel hoog niveau, zoals het uitvoeren van regressietesten. Simpel gezegd: alleen als je alle stappen, waar je het testtool in wil zetten, nu al handmatig doet, kan het testtool een doel op zich zijn. Wanneer dit niet het geval is (waarschijnlijk bijna altijd), is je testtool slechts een middel om tot de oplossing te komen.

Een verstandig besluit nemen over de vraag "Wel of geen testtool"

Voordat je over gaat tot invoering van een testtool, is het verstandig om eerst een paar simpele vragen te beantwoorden:
  • Welke stappen in het testproces wil ik de testtool laten uitvoeren?
  • Bestaan deze stappen nu al? Zo nee, waarom niet?  
  • Welke problemen lopen we nu tegenaan bij deze stappen? Gaan deze problemen door de invoering  van het testtool opgelost worden? Of moeten ze opgelost zijn, om invoering zinvol te maken?
  • Welke werkzaamheden, die nu al worden uitgevoerd, gaan door de invoering verbeterd of versneld worden? Let op: het gaat dus alleen om werkzaamheden, die je nu al uitvoert, niet om werkzaamheden, die je zou willen gaan uitvoeren.
  • Welk extra werk is er nodig, als je gebruik gaat maken van dit testtool? Bijvoorbeeld welke handelingen zijn verplicht om uit te voeren, om dit testtool te kunnen gebruiken of welke extra onderhoudswerkzaamheden zijn nodig om het gebruik zinvol te maken? En is deze tijd ook beschikbaar te maken?
Invoeren van een testtool? Maak de juiste afweging

Een testtool kan een goed middel zijn om een probleem op te lossen. Maar het kan ook uiteindelijk de oplossing niet blijken te zijn. Zeker als je een stap op dit moment handmatig niet uitvoert, moet je je sterk afvragen of het automatiseren van een nu niet bestaande stap, je probleem op gaat lossen. Sta stil bij meer dan alleen de bekende voordelen van een testtool. Sta stil bij de nadelen van een testtool en bij de huidige problemen in je organisatie. Het antwoord op "Invoeren Ja/Nee" kan dan "Ja" of "Nee" worden. Maar als het antwoord "Ja" is, is de kans op succesvolle invoering wel veel hoger. Je weet veel beter waar je aan begint.