Een goed hulpmiddel bij de dagelijkse testwerkzaamheden, is een testtool. Testtools zijn er in vele soorten en maten, en in nog veel grotere aantallen. Hoe weet je nu als tester, testmanager of test engineer hoe je de juiste tool selecteert voor je werkzaamheden. In het eerste deel van dit artikel worden de eerste twee fases van de testtool selectie pyramide beschreven.
Zoals hierboven al is beschreven, zijn er duizenden testtools die ons kunnen helpen bij onze werkzaamheden. Hier schuilt een gevaar in, wat als je een tool selecteert en deze voldoet uiteindelijk niet aan je verwachtingen, dan kan dat leiden tot:
• Slechte automatisering
• Frustratie
• Gebrek aan commitment
• Slechte businesscase
• Shelfware
Om dit te voorkomen is er een goed selectietraject nodig. Aan de hand van de toolselectiepiramide wordt een succesvolle aanpak besproken.
Binnen de toolselectie piramide onderkennen we 4 verschillende fasen:
• Longlist
• Shortlist
• Proof of Concept
• Pilot
Deze vier fasen leiden uiteindelijk tot een keuze voor een tool. Uiteindelijk zal deze tool natuurlijk ook nog eens geïmplementeerd moeten worden, maar dat is een geheel ander verhaal.
Longlist-fase
De uitkomst van de longlist-fase is, zoals de naam doet vermoeden een longlist met tools, maar voordat we zover zijn, doorlopen we nog een aantal stappen:
• Formuleer een doel: Er moet een helder en haalbaar doel worden geformuleerd waarom er een tool geselecteerd dient te worden. Dus niet 'We willen een tool, zodat we niet meer handmatig hoeven te testen', maar 'We willen onze regressietest automatiseren om zo de testdekking te verhogen en de doorlooptijd te verkorten'.
• Identificeer de stakeholders: Als er een nieuwe testtool geïmplementeerd dient te worden binnen de organisatie, heeft dit impact op de gehele organisatie en niet alleen op de testafdeling. Zorg ervoor dat alle betrokken afdelingen worden geïdentificeerd, zodat ze ook een stem hebben in het project.
• Formeer een projectteam: Het selecteren van een tool is meer dan een testaangelegenheid alleen. Er moet een projectteam geformeerd worden om het selectietraject te begeleiden en uit te voeren. Het team dient te bestaan uit minimaal een projectleider, een vertegenwoordiger van de business en een tester. Daarnaast is het verstandig om applicatiebeheerders, databasebeheerders, key users, etc. ook in te lichten over het selectietraject.
• Stel businesscase op: Er dient een initiële, valide businesscase opgesteld te worden, zodat de stakeholders kunnen zien dat er voldoende grond is om te starten met het project. De businesscase is aan verandering onderhevig en zal gedurende het project actueel en valide moeten worden gehouden.
• Benoem basisrequirements: Alle betrokken afdelingen dienen requirements op te stellen waaraan de testtool moet voldoen. De requirements dienen helder geformuleerd te worden en meetbaar te zijn. Het kan hier gaan om bijvoorbeeld technische requirements als ‘meerdere platformen dienen te worden ondersteund’, maar ook functionele requirements als ‘het moet mogelijk zijn om gebruikersbeheer in te richten’. Maar het gaat hier wel om de hoofdlijnen. Pas in de shortlist fase dienen gedetailleerde requirements opgesteld te worden.
• Verzamel globale toolinformatie: Om uiteindelijk een longlist op te kunnen leveren is het van belang dat er informatie over tools wordt verzameld. Deze info hoeft in eerste instantie alleen maar op hoofdlijnen te zijn. Als één requirement bijvoorbeeld is dat er gekozen is voor open-source-software; dan kan er op Internet alvast gezocht worden naar tools die hieraan voldoen. Naast het internet is het ook verstandig om binnen de organisatie of binnen je netwerk mensen naar hun ervaringen met tools te vragen, om zo informatie te verzamelen.
• Stel een longlist op: Als er voldoende informatie is, kan er gestart worden met het opstellen van de longlist. Deze lijst bevat alle mogelijke kandidaten die in eerste instantie in aanmerking komen als tool.
Shortlistfase
De shortlistfase is de fase die ervoor zorgt dat er uit de geselecteerde tools voor de longlist een shortlist komt. Om tot deze shortlist te komen, doorlopen we ook weer een aantal stappen:
• Stel gedetailleerde requirements op: In de vorige fase zijn de basisrequirements opgesteld, waaruit een voorselectie is gemaakt. Tijdens deze stap worden de requirements gedetailleerd uitgewerkt, zodat we een verzameling krijgen van meetbare requirements. Deze requirements worden onderverdeeld in de hoofdcategorieën zoals bepaald in de longlistfase. In de hoofdcategorie gebruikersbeheer kan bijvoorbeeld de volgende requirement worden opgenomen: ‘het moet mogelijk zijn verschillende gebruikersgroepen te definiëren’.
• Bepaal het gewicht en de prioriteit van de requirements: Elk requirement krijgt een prioriteit op basis van MoSCoW, daarnaast krijgt het een gewicht. Dit gewicht en de prioriteit zorgen uiteindelijk voor de score per onderdeel per tool.
• Request for Information(RFI): De RFI wordt opgesteld aan de hand van de requirements. Typische onderdelen voor een RFI kunnen zijn:
– Welke technologie wordt door de tool ondersteund;
– Hoe is support ingeregeld;
– Zijn er trainingen beschikbaar.
De RFI wordt uitgestuurd naar alle commerciële kandidaten van de longlist. Bij open source tooling ligt dit anders. Soms wordt een open-source-tool wel geleverd door een leverancier, dan kan de RFI hierheen gestuurd worden. Als er een partij is die kan helpen bij de implementatie van een open source oplossing, dan zou de RFI daarheen gestuurd kunnen worden. Mocht dit ook niet het geval zijn, dan zal de projectgroep intern de RFI moeten opstellen door info te vergaren via bijvoorbeeld het internet.
• Bepaal score per tool: Als alle RFI's ingevuld retour zijn gekomen, dan wordt per tool de score bepaald.
• Technische intake of demo: Na het bepalen van de score kan er gekozen worden om bijvoorbeeld nog een technische intake te doen met de tools, of de leveranciers te vragen om een demo te verzorgen. Deze stap kan duidelijk nog meehelpen in het bepalen van de uiteindelijke kandidaten voor de shortlist. Stel dat er nog onduidelijkheden zijn over een tool, of er mist een bepaald gevoel, dan kan een demo nog verhelderend werken.
• Stel een shortlist op: De shortlist is de lijst met kandidaten die in aanmerkingen komen voor de Proof of Concept-fase.
De volgende twee fases zijn beschreven in 'Succesvol een testtool selecteren (2).
Beste Bernd,
wat maakt deze manier van toolselectie nu zo specifiek voor testtools?
Zover mij kennis reikt, is dit een redelijk generieke manier van tools selecteren.
snik, ook hier helaas weer geen reactie van de auteur
Bernd,
Duidelijk verhaal. En ja, zoals de voorgaande reactie, dit geldt voor alle tool selecties, maar helaas wordt het niet zo uitgevoerd.
Door de stappen op papier te zetten zoals Bernd doet help het wel enorm in dit proces.
Beste Pavake,
Beter laat dan nooit toch nog een reactie. Deze aanpak zoals hij hier beschreven staat en in het vervolg stuk is een aanvulling op de pakketselectie zoals hij zo vaak wordt toegepast. Ik kan je daar alleen maar gelijk in geven. In het stuk probeer ik handvatten te geven hoe je op een gestructureerde wijze kan omgaan met het selecteren van een testtool. Niet alleen de aanpak, maar alles wat er nog omheen komt, templates, meeting structuren etc, zorgen er wel voor dat de aanpak kan leiden tot het succesvol selecteren van een (test)tool.