Een goed hulpmiddel bij onze 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 tweede deel van dit artikel worden de laatste twee fases van de testtool selectie pyramide beschreven.
We zijn nu aanbeland in de volgende fase, namelijk de Proof of Concept (PoC)-Fase
Proof of Concept fase
Gedurende de PoC-fase zullen een aantal tools/leveranciers worden uitgenodigd om aan te tonen dat hun tool geschikt is en aan de eisen van de PoC voldoet: een soort testrit voor de tool. Deze fase bestaat ook weer uit een aantal stappen die doorlopen moeten worden:
• Opstellen van de requirements voor de PoC: om elke leverancier op een gelijke manier te kunnen beoordelen is het belangrijk dat er requirements voor de PoC worden opgesteld. Requirements kunnen bijvoorbeeld zijn:
o De keten frontend –> middelware –> backend moet volledig geautomatiseerd uitgevoerd kunnen worden;
o 90 procent van de objecten binnen de applicatie moet standaard door de applicatie herkend worden.
Na afronding van de PoC zullen deze requirements dienen als criteria om te bepalen of de PoC geslaagd is.
• Nodig leveranciers uit voor een PoC: Zodra de requirements voor de PoC opgesteld zijn, kunnen er leveranciers worden uitgenodigd om een PoC te komen uitvoeren. Zorg ervoor dat iedere leverancier duidelijk heeft wat er van hem verwacht wordt en binnen welke tijd. Plan samen met de leverancier een PoC in en zorg ervoor dat alle betrokkenen geïnformeerd zijn.
• Voer PoC uit: Om de PoC te kunnen starten, moeten naast de externe voorbereidingen van de leverancier ook de interne voorbereidingen gestart zijn, zoals het verkrijgen van user accounts of rechten tot de te testen applicatie. Pas als aan alle voorwaarden is voldaan, kan gestart worden met de PoC. De leverancier zal in de afgesproken periode aantonen, dat zijn tool voldoet aan de gestelde requirements. Zodra alle leveranciers aan bod zijn geweest zal gestart worden met een evaluatie van de PoC’s.
• Evalueer de PoC: De PoC wordt geëvalueerd met het projectteam. Op basis van de resultaten en de requirements zullen de verschillende tools beoordeeld worden.
• Selecteer meest geschikte tool: Aan de hand van de evaluaties van de PoC’s zal het projectteam de meest geschikte tool(s) kiezen. De voorkeur zou zijn als er één tool uit zou komen die absoluut het beste is, maar het is niet uit te sluiten dat er na de PoC toch nog meerdere tools overblijven. Dan zal in de pilotfase een definitieve keuze gemaakt moeten worden.
• Request for Proposal (RFP): Nu er een keuze is gemaakt, zal er een Request for Proposal worden uitgestuurd. Deze zal inzicht geven in onder andere de kosten van de tooling, onderhoudskosten en opleidingskosten. Dit is uiteindelijk weer nodig voor de businesscase. Voor open source geldt hetzelfde als voor het uitsturen van de RFI.
• Update businesscase: In deze fase is het ook verstandig om een update op de businesscase te doen. Er is nu immers veel meer bekend over de tool. Bijvoorbeeld de kosten, support, opleidingen, maar ook al inzicht in hoelang de implementatie duurt.
Nu de PoC-fase is afgesloten, kan er een start worden gemaakt met de pilotfase.
Pilotfase
Gedurende de pilotfase zullen een of meerdere tools voor een langere periode binnen het project ingezet worden. Het heeft de voorkeur om de pilot als een apart project in te richten in een gecontroleerde omgeving. In deze fase doorlopen we nog een viertal stappen. Dan zijn we klaar met ons selectietraject en hebben we de juiste tool geselecteerd.
• Opstellen requirements: De eerste stap binnen de pilotfase is het afbakenen van de pilot. Dit doen we door requirements op te stellen voor de pilot, zodat uiteindelijk de pilot getoetst kan worden aan deze requirements en daarna geaccepteerd kan worden. Voorbeelden voor deze requirements zijn:
– De geselecteerde systemen moeten automatisch getest kunnen worden;
– De testers moeten zelf in staat zijn om testen te automatiseren;
– Applicatiebeheerders moeten de applicatie technisch kunnen beheren.
• Leverancier uitnodigen: Zodra de requirements zijn vastgesteld zal de leverancier uitgenodigd worden voor de pilot. Dit kunnen natuurlijk ook meerdere leveranciers zijn. Het doel en de planning voor de pilot worden opgesteld en na de kick off wordt er gestart met de pilot.
• Uitvoeren van de pilot: Tijdens het uitvoeren van de pilot zal het projectteam, samen met de leverancier of een afgevaardigde hiervan, het project doorlopen. Het uiteindelijke doel van de pilot is om aan te tonen dat de tool geïmplementeerd kan worden binnen het project of de organisatie.
• Evaluatie: De laatste stap in de pilotfase en ook meteen de laatste stap in de selectiefase is het evalueren van de pilot. Het projectteam zal aan de hand van de requirements en acceptatiecriteria de pilot evalueren.
Als al deze fases zijn doorlopen en als aan alle requirements en criteria is voldaan, dan is er succes en kan er gestart gaan worden met de implementatie van de geselecteerde tool.
Beste Bernd,
Leuk artikel! De door jou geschetste aanpak pas ook ik regelmatig toe in tool selectie trajecten. Toch zie ik dat klanten vaak een pragmatische insteek kiezen en de Pilot achter wegen laten. Zeker als het gaat om testautomatisering tooling wordt al tijdens de PoC ernaar gestreefd een compleet E2E-proces te automatiseren om zo juist interfacing en specifieke systeemcomponenten mee te nemen in de tests. Negen van de tien keer wordt de meerwaarde van een pilot dan niet meer gezien.
Daarbij komt dat je in je stuk over een aantal stappen spreekt waarbij het betrekken van een leverancier van toepassing is. Zeker als het gaat om openSource oplossingen is dit niet mogelijk en zal ondersteuning nodig zijn van experts. Denk hierbij aan tooling als Selenium of Fitness. Met de hedendaagse community rondom veel van deze openSouce testtools is dat steeds minder vaak een probleem, maar het brengt wel een belangrijke nuance aan jou verhaal.
Groet,
René
@ Bernd
Wat je beschrijft is m.i. een vrij generieke benadering van de selectie van iets ICT-erigs. Een degelijke opsomming doe je hier zeker, maar waar ik toch POC en Pilot zou willen combineren. Dat geeft een tijdbesparing zonder de kwaliteit van het eindresultaat aan te tasten. Het is ook van belang dat namelijk de kosten van het voortraject, en wat daarna volgt, enigszins in verhouding staan qua kosten en doorlooptijd. In dat licht is het zinvol om voor eenvoudigere omgevingen een kortere procedure te hanteren dan je nu beschrijft…
Heren,
Inderdaad is het een vrij generieke aanpak, welke breed gebruikt wordt in het IT landschap. Toch zijn er een aantal zaken, die samenhangen met het artikel (templates, overleggen etc) die het een aanpak maken die je goed kan ondersteunen om de juiste (test)tool te selecteren.
In de PoC zoals hij hier beschreven staat, dagen we de leveranciers inderdaad uit om onze moeilijkste testcases en systemen te testen. De uitkomsten van de PoC kunnen er natuurlijk voor zorgen dat een Pilot niet hoeft, maar de Pilot is hier ook zeker bedoelt om de organisatie kennis te laten maken met de (mogelijk) geselecteerde tool. Dus kan absoluut van meerwaarde zijn.
@Rene, tijdens de presentaties die ik over dit onderwerp gegeven heb, komt het gebruik van experts inderdaad uitgebreid aan bod. We kunnen met Open source oplossingen zeker niet zonder ze. Ben het met je eens dat communitys steeds belangrijker en groter worden, dus er komt meer hulp uit de markt, maar dat maakt de vraag naar experts nog niet minder denk ik.
Het is niet altijd zo, dat er voldoende tijd en geld is voor een gedegen onderzoek. Je kan de aanpak dan ook vereenvoudigen naar eigen inzicht, maar waak wel voor kwaliteit en laat de waan van de dag niet de keuze naar een tool bepalen.
Ik heb teveel tools na een paar maanden in een kast, la of prullenbak zien verdwijnen en dat is zonde van de tijd, geld en energie die er ingestopt is.