Blog deel 2
Auteur: TestNet TTM Werkgroep ● zemouri@gmail.com
Redactie: Eric Spaargaren en René van Veldhuijzen
Om testtoolmanagement efficiënter en effectiever toe te passen, verdiept de TestNet werkgroep Test Tool Management zich in dit onderwerp door middel van onderzoek, kennisdeling en -overdracht. In deze meerdelige blogserie delen collega’s uit de werkgroep hun ervaringen vanuit diverse testrollen, gedreven door de passie om een waardevolle bijdrage te leveren aan het testvakgebied.
Testblog 2 – Testtoolselectie, hoe organiseren we dit robuust?
In de vorige blogpost bespraken we de uitdagingen en tips rondom het selecteren van de juiste testtools in de wereld van het testen van software. Hierin werd een beeld geschetst over de verschillende soorten testtools, de voordelen en nadelen van elke type, en de factoren die van invloed kunnen zijn op de keuze en het gebruik van testtools. De keuze van passende testtools is cruciaal voor een efficiënt en effectief testproces binnen een organisatie. Wanneer testtools worden geselecteerd die aansluiten bij de behoeften van het team en worden gebruikt door mensen met de juiste vaardigheden en ervaring, kan dit het testproces efficiënter, effectiever en consistenter maken. Dit kan, in het ideale geval leiden tot software van hogere kwaliteit of kostenreducties en procesoptimalisaties . In deze blog richten we ons verder op het organisatorische aspect van testtoolselectie.
Hoe organiseren we het testtoolselectieproces op een robuuste manier? Om deze vraag goed te kunnen beantwoorden, moeten we eerst duidelijk hebben wat onder testtoolselectie wordt verstaan. Helaas is het lastig om een precieze definitie van testtoolselectie te vinden. Certificering frameworks als ISTQB [1] of testmethodes zoals TMap [2] bieden enig inzicht in testtoolselectie, maar missen vaak de eenduidigheid en context die nodig zijn voor een alledaagse praktijk. Daarom splitsen we het begrip het “testtoolselectie” allereerst in twee delen: “testtool” en “selectie”. Voor beide begrippen bestaan duidelijke definities. Zonder in teveel detail te treden, kan de term “testtool” worden gedefinieerd als een gereedschap of hulpmiddel dat wordt gebruikt om iets te testen. Van Dale [3] definieert “selectie” als volgt:
1. het uitkiezen (naar geschiktheid); = keuze
2. het uitgekozene
Het selecteren van een testtool is allereerst een proces van keuzes. Deze keuzes ontstaan door een complex samenspel van interne en externe factoren. Enkele concrete voorbeelden van interne factoren zijn de beschikbare vaardigheden en ervaring binnen het team, het bestaande budget voor testtools, en de interne beleidsregels of voorkeuren van de organisatie. Externe factoren kunnen variëren van de technologische trends en ontwikkelingen in de markt, feedback van gebruikers in vergelijkbare organisaties, tot de beschikbaarheid van ondersteuning en documentatie door leveranciers.
In de whitepaper Test Tool Management [4], wordt dit proces omschreven als “Het identificeren, evalueren en selecteren van geschikte test tools op basis van de behoeften en vereisten van het specifieke project. Dit is een belangrijke factor in het verbeteren van de volwassenheid van testprocessen. Door de juiste tools te selecteren, kunnen organisaties de efficiëntie en effectiviteit van het testproces vergroten, wat kan leiden tot een hogere kwaliteit van de software.”
Het kiezen van geschikte testtools is dus cruciaal. Door de juiste tools te selecteren, kunnen organisaties de efficiëntie, effectiviteit en kwaliteit van hun software verhogen. Maar wanneer start een testtoolselectieproces? Dit proces begint meestal wanneer er een behoefte ontstaat om een geschikte testtool te kiezen voor een specifiek project of organisatie. De aanleiding voor zo’n proces kan variëren, maar hier zijn enkele mogelijke redenen:
- Verouderde tools
- Nieuwe projecten
- Veranderingen in technologie
- Problemen met huidige tools
- Efficiëntieverbetering
- Kostenbesparing
Bestaande testtools kunnen verouderd zijn, niet meer voldoen aan de eisen of inefficiënt zijn. Dit kan leiden tot de behoefte aan een nieuwe selectie tools. Bovendien kan bij de start van een nieuwe project het nodig zijn om geschikte testtools te selecteren die passen bij de vereisten van dat nieuwe project. Als de “technology stack” van een organisatie verandert, bijvoorbeeld van “on premise” naar “cloud based” systemen, kan dit invloed hebben op de keuze van testtools. Ook als bestaande tools (om wat voor reden dan ook) niet goed (meer) werken, fouten veroorzaken of niet goed integreren met andere systemen, kan dit een aanleiding zijn voor een heroverweging, omdat organisaties eenvoudigweg efficiënter willen werken. Een nieuwe tool kan helpen bij het automatiseren van tests, het versnellen van het test- en ontwikkelproces en het verminderen van foutgevoelig handmatig werk. Tenslotte kan het overstappen naar een andere tool kostenbesparingen opleveren, bijvoorbeeld door licentiekosten te reduceren.
Testtoolselectie pyramide
Om het bovenstaande organisatorisch goed te kunnen begrijpen, zoomen we verder in en gebruiken we een bestaande en betrouwbare online publicatie over testtoolselectie. De vraag hoe een testtoolselectie traject succesvol kan worden georganiseerd, kan worden samengevat in de zogenaamde “testtoolselectie pyramide”, zoals weergegeven in figuur 1.
Figuur 1. Testtoolselectie pyramide (Beersma, 2014)
De publicatie van Beersma [5] beschrijft een piramidebenadering voor het selecteren van een testtool in 4 fasen:
1) Het creëren van een lange lijst met potentiële tools (Long list)
2) Het inkorten van de lijst tot topkandidaten (Shortlist)
3) Het uitvoeren van een “Proofs of Concept” met topkandidaten (PoC)
4) Een pilot van de top 1 of 2 tool(s) (Pilot)
Volgens Beersma, omvat elke fase het definiëren van vereisten, het evalueren van tools en het waarborgen van de betrokkenheid van belanghebbenden voordat naar de volgende fase wordt overgegaan. Het doel is om via een gestructureerd selectieproces het best passende tool te selecteren.
Belangrijke aspecten bij het organiseren
Om het gestructureerde selectieproces zoals hierboven benoemd in goede banen te leiden, zijn er enkele belangrijke aspecten waarmee je rekening moet houden:
1. Bepaal je behoeften
Bepaal je test tool strategie. Dit is een set van strategische keuzes die betrekking hebben op het gebruik van test tools:
- Waaraan moeten de testtools voldoen? (behoefteanalyse)
Als je organisatie werkt met Agile-methodologieën, moet de testtool integreren met Agile-projectmanagementtools zoals Jira. Als je voornamelijk mobiele applicaties test, moet de testtool compatibel zijn met verschillende mobiele besturingssystemen zoals iOS en Android.
- Welke soorten tests wil je uitvoeren? (bijv. functionele tests, performance tests, security tests)
Als je functionele tests wilt uitvoeren, heb je tools nodig zoals Selenium of TestComplete. Voor performance tests kun je denken aan tools zoals JMeter of LoadRunner. Als security tests belangrijk zijn, dan kunnen tools zoals OWASP ZAP of Burp Suite nuttig zijn.
- Welke functies heb je nodig? (bijv. defect tracking, rapportage, integratie met andere tools)
Als je een tool nodig hebt die defect tracking ondersteunt, kun je denken aan tools zoals Bugzilla of Jira. Voor rapportage-functionaliteiten kun je zoeken naar tools die gedetailleerde en aanpasbare testrapporten bieden, zoals TestRail. Integratie met CI/CD-pijplijnen kan ook cruciaal zijn, dus tools die naadloos werken met Jenkins of GitLab CI/CD zouden waardevol zijn.
- Wel of niet test automatiseren? (indien wel test automatiseren dan ook rekening houden met test automatiseringsstrategie)
Als je besluit om testautomatisering in te voeren, kun je tools overwegen zoals Selenium voor webapplicaties of Appium voor mobiele apps. Je moet ook nadenken over welke testsoorten je wilt automatiseren, zoals regressietesten, om te bepalen welke tools het meest geschikt zijn.
- Wat is je budget?
Als je een beperkt budget hebt, kun je kijken naar bijvoorbeeld open-source tools zoals Selenium en JMeter. Als je budget groter is, kun je overwegen commerciële tools aan te schaffen zoals UFT (Unified Functional Testing) of TestComplete overwegen, die vaak meer functies en ondersteuning bieden.
- Welke vaardigheden heeft je team?
Als je team vooral uit mensen met ervaring in Java bestaat, kan een tool als Selenium, dat voornamelijk Java ondersteunt, een goede keuze zijn. Als je team voornamelijk ervaring heeft met scriptloze tools, zou een tool als TestComplete, dat minder codering vereist, passender zijn. Het is ook belangrijk om na te denken over het opleidingsplan voor je team om nieuwe tools effectief te kunnen gebruiken.
2. Onderzoek je opties
- Maak een lijst van potentiële leveranciers.
Denk hierbij aan leveranciers die tools aanbieden die passen bij je behoefteanalyse en testtoolstrategieën, zoals Opentext voor UFT of SmartBear voor TestComplete.
- Lees recensies, whitepapers en bekijk demo’s.
Door bijvoorbeeld door websites te bekijken zoals G2 (https://www.g2.com) en Capterra (https://www.capterra.nl) voor gebruikersrecensies en vergelijk whitepapers van leveranciers om een beter begrip van de toolcapaciteiten te krijgen.
- Kijk op gebruikers forums en vraag rond bij collega’s
Bezoek forums zoals Stack Overflow of Reddit en vraag advies van collega’s in je netwerk die ervaring hebben met de tools die je overweegt.
- Vraag offertes op.
Neem contact op met de leveranciers voor prijsopgaven en vraag naar eventuele kortingen voor grotere teams of langere abonnementen.
- Bezoek conventies en conferenties om met verschillende leveranciers te praten en demo’s te bekijken.
Door een test evenement te bezoeken, zoals de EuroSTAR Conference, Test Automation Days of een TestNet event, kan je direct in gesprek komen met leveranciers en kan je demonstraties bekijken van de testtools die zij ten toon stellen. Daar kan je eventueel ook seminars & workshops bijwonen en in contact komen met testers die kennis en ervaring hebben in die tools.
3. Evalueer de tools
- Beoordeel de functies van elke tool en vergelijk dit met de behoefteanalyse.
Maak bijvoorbeeld een checklist van de benodigde functies en controleer welke tools deze functies aanbieden.
- Gebruik eerst trial versions van de tool.
Meld je aan voor proefperiodes of demo’s om de tools in je eigen omgeving te testen.
- Vergelijk de prijzen.
let op de “out of pocket” uitgaven en de langere termijn verplichtingen en ook het gebruikersgemak. Een goedkope tool kan op de lange termijn duurder zijn als deze moeilijk te gebruiken is en daardoor inefficiënt werkt. Overweeg tools die in eerste instantie duurder lijken, maar intuïtiever en effectiever zijn in gebruik, wat tijd en geld bespaart op lange termijn.
- Houd rekening met de ondersteuning die elke leverancier biedt.
Kijk of de leverancier een goed bereikbare helpdesk heeft, regelmatig updates biedt en een actieve gebruikersgemeenschap heeft.
- Houd rekening met de procedures en regels die binnen het bedrijf gelden waar je werkzaam voor bent (CISO, cyber security-afdeling etc.)
Zorg ervoor dat de tools voldoen aan de beveiligings- en compliance-vereisten van je organisatie, zoals GDPR-naleving of integratie met bestaande beveiligingsprotocollen.
- Maak een lijst met criteria waarmee je de tools uit de short list en poc kan ranken en zo een objectief oordeel, gekwantificeerd.
Bijvoorbeeld: Stel een scorecard op met gewogen criteria zoals functionaliteit, gebruiksvriendelijkheid, kosten en ondersteuning, en beoordeel elke tool hierop.
4. Maak een beslissing
- Kies de tool die het beste past bij je behoeften en budget.
Bijvoorbeeld dat na het evalueren van alle criteria, de testtool wordt gekozen met de hoogste totaalscore en die binnen het budget past.
- Stel een implementatieplan op.
Bepaal de stappen voor de invoering van de tool, inclusief training, migratie van bestaande gegevens, en integratie met andere systemen.
- Train je team om de tool te gebruiken.
Organiseer workshops en trainingen voor je team om hen vertrouwd te maken met de nieuwe tool en zorg voor documentatie en support.
Tot slot
Naast deze belangrijke aspecten, zijn er nog enkele andere dingen waarmee je rekening mee moet houden:
- Betrek alle belanghebbenden bij het selectieproces.
Bij het selecteren van een testtool is het essentieel om niet alleen de ontwikkelaars en testers te betrekken, maar ook de productmanagers, IT-beheerders en zelfs vertegenwoordigers van de gebruikersgroepen. Zo zorg je ervoor dat alle relevante perspectieven worden meegenomen en dat de uiteindelijke keuze breed gedragen wordt binnen de organisatie.
- Maak een duidelijke tijdlijn voor het selectieproces.
Een duidelijke tijdlijn kan er bijvoorbeeld uitzien als volgt: Week 1-2: behoeftenanalyse en strategiebepaling, Week 3-4: onderzoek naar leveranciers en demo’s bekijken, Week 5-6: evaluatie van tools en opstellen van een shortlist, Week 7-8: proefperiodes uitvoeren en feedback verzamelen, Week 9: definitieve besluitvorming en implementatieplanning.
- Documenteer je besluitvorming
Het opstellen van een gedocumenteerde besluitvorming kan bestaan uit een scorecard met criteria zoals functionaliteit, gebruiksvriendelijkheid, kosten en ondersteuning. Door deze criteria duidelijk te documenteren, kun je objectief vergelijken en de best passende tool selecteren.
- Herbeoordeel je behoeften regelmatig en evalueer of je testtool nog steeds aan je eisen voldoet (feedback-loop).
Na de implementatie van een testtool is het belangrijk om regelmatig feedback te verzamelen van gebruikers en stakeholders. Bijvoorbeeld door middel van (drie) maandelijkse evaluatiesessies waarin wordt besproken of de tool effectief blijft en nog steeds voldoet aan de veranderende behoeften van de organisatie.
Door deze aspecten in overweging te nemen, kun je een goed georganiseerd testtoolselectieproces opzetten en de juiste testtool kiezen die aansluit bij de specifieke behoeften en project doelstellingen.
Hopelijk vond je deze blog nuttig en interessant! Ben je nu getriggerd om je eigen ervaringen en tips met ons en de test community te delen? Laat dan je reactie hieronder achter.
Gebruikte bronnen:
[1] Black, R., McKay, J., Bath, G., Friedenberg, D., Homès, B., Onishi, K., Smith, M., Thompson, G., Yumoto, T., & International Software Testing Qualifications Board. (2012). Certified Tester Advanced Level Syllabus Test Manager. In International Software Testing Qualifications Board. https://istqb-main-web-prod.s3.amazonaws.com/media/documents/CTAL_TM_2012_Syllabus_v2.0.pdf
[2] TMAP: the body of knowledge for quality engineering and testing | TMap. (n.d.). https://tmap.net/
[3] Van Dale NEDERLAND. (n.d.). Van Dale NEDERLAND. https://www.vandale.nl/gratis-woordenboek/nederlands/betekenis/selectie
[4] Kerkhoff, R.; Zemouri, O.; Jacobs, M. & Veldman, B. (2024). Whitepaper Test Tool Management. TestNet.
[5] Beersma, B. (2014). The pyramid approach to testtool selection [Slide show]. SlideShare. https://www.slideshare.net/slideshow/ati-bernd-beersma/31934836