Keuzes maken. Het is nou niet bepaald mijn sterkste kant. Ik ben een enorme twijfelaar, en als ik dan uiteindelijk iets heb gekozen, dan denk ik nog vaak of ik niet toch beter de andere optie had kunnen nemen. Tijdens mijn middelbare schoolperiode twijfelde ik over mijn vervolgopleiding. Geschiedenis of toch IT? Uiteindelijk koos ik voor geschiedenis. Tijdens mijn studie ben ik nog eens veranderd van specialisatie. En na die opleiding afgerond te hebben, ben ik heel snel toch in de IT terecht gekomen en leer ik alleen nog in mijn vrije tijd over geschiedenis. Keuzes, ik zei het al, zijn niet mijn sterke kant.

Maar als tester maken we veel keuzes. En er wordt expertise van ons verwacht. Een van de gebieden waar we keuzes op maken, is op het gebied van tools. En dan bedoel ik niet alleen automatische testtools, maar ook breder, alle tools die ons bij ons dagelijks werk kunnen helpen. Van een notitieblok, tot een command line client, tot een uitgebreide tool als HPE UFT. Wat mij daarbij helpt is om de keuze goed te onderzoeken en te onderbouwen. Tijdens mijn carrière heb ik geleerd dat dit betekent dat ik een stuk verder moet kijken dan alleen maar de benodigde functionaliteit (kan de tool mijn product wel testen?). Er is een hele waslijst aan factoren waar je rekening mee moet houden om een keuze goed te maken, en er niet steeds op terug te hoeven komen.

Een voorbeeld

Ik neem een fictief maar realistisch ontwikkelproject als voorbeeld. Het is een modern opgezet project, dat werkt volgens Agile/Scrum. Het team bestaat uit twee testers en vijf ontwikkelaars, ze hebben beschikking tot een architect, er is een product owner en meerdere stakeholders die zowel het bedrijf dat de software gaat verkopen als hun klanten vertegenwoordigen. Het product is een webapplicatie voor notities en taken, met opslag in de cloud. De software zelf is een database, met daarboven een webapplicatie. Via API requests worden de CRUD-handelingen uitgevoerd. Het bedrijf is redelijk vooruitstrevend en heeft het team veel autonomie verleend in het bepalen wat er nodig is voor het werk.

Ik ben tester in het team, en na enkele sprints beginnen we allemaal de pijn van de regressietest te voelen. Doordat het product groeit, duurt het steeds langer om deze met de hand uit te voeren. Daarnaast willen we onze klanten goed ondersteunen, dus we testen op verschillende browsers, waardoor we die lange test ook nog eens meerdere malen moeten uitvoeren. Als we op het laatste moment nog een bevinding doen, dan moeten we de product owner teleurstellen. We halen het niet om dan nog een fix te maken, deployen en testen. Als team doet dat zeer.

Ik vind het tijd om te automatiseren. Daarvoor heb ik een plan gemaakt, en wat ik vooral wil is dat ik de API ga testen, in plaats van alleen maar de website. Als we deze tests automatisch uitvoeren, verwacht ik dat deze sneller gaan en op tijdstippen die handiger zijn in onze planning. Midden in de nacht bijvoorbeeld, of als onderdeel van onze build/deploy pipeline. Hiervoor heb ik een tool nodig. Tijd om op onderzoek uit te gaan.

11 factoren

Als leidraad heb ik elf factoren waar ik op ga letten. Ik maak voor mijzelf een overzicht van wat wij nodig hebben per factor, en ik hoop aan het einde genoeg informatie te hebben om een goede keuze te maken. Mijn doel is om een lijst van eigenschappen te maken waartegen ik de beschikbare tools ga beoordelen.

Functionaliteit

Ik ben op zoek naar een tool die API’s kan testen. Daarnaast wil ik dat hij op basis van een schema gestart kan worden (al dan niet met behulp van andere tools) en dat ik hem in onze build-pipeline kan integreren. Ik wil dat er een rapportage wordt gemaakt die voor verdere verwerking kan worden gebruikt, bijvoorbeeld om te bepalen of een build wordt gedeployed of niet op basis van de testresultaten.

Kosten

Als team zijn we autonoom, maar we hebben ons natuurlijk wel aan een budget te houden. Samen met de product owner maak ik een overzicht van het beschikbare budget. Ik informeer hierbij ook naar het budget in de toekomst omdat enkele tools werken met jaarlijks terugkerende kosten (in ruil voor upgrades en ondersteuning). Naast de kosten voor aanschaf/licenties neem ik ook de kosten voor training, ondersteuning en upgrades mee.

Kennisniveau

Wat is het kennisniveau in het team? En in de organisatie eromheen? Welke talen of technieken beheersen we? Welke absoluut niet? Ik probeer ook rekening te houden met wie de kennis beheerst. Kennis die nodig is om het gebruik van de tool te initialiseren, is van een ander niveau dan kennis die continu nodig is om de tool te kunnen beheren en gebruiken. Vaak is voor het schrijven en aanpassen van tests minder technische kennis nodig dan voor het integreren in de bestaande processen.

Snelheid

Wat verwachten we van de snelheid van de tool? Dit is natuurlijk erg subjectief, en is waarschijnlijk ook lastig te beoordelen op basis van de beschikbare productspecificaties. Toch zal ik wel wat kunnen zeggen over de extremen. Ik wil bijvoorbeeld dat onze regressietest niet langer duurt dan twee uur en onze smoketest niet langer dan tien minuten.

Rapportage

De rapportage uit de tool gebruiken we op verschillende manieren. We gebruiken de testresultaten natuurlijk om eventuele bevindingen (op het product of de tests zelf) te fixen. We gebruiken ze ook om te bepalen of we verder kunnen (naar productie, naar deploy, naar het volgende item). Het is ook verantwoording richting de product owner over ons werk en de staat van het product. Daarnaast willen we ook graag een historie van testrapporten kunnen bewaren. Het rapport moet dus zowel door onze continuous integration tool gelezen kunnen worden, als (na eventuele transformatie) door mensen.

Werkwijze

Als we het hebben over automatische testtools zijn er verschillende werkwijzen. De meest bekende zijn opnemen-afspelen en volledig handmatig coderen. Daartussen zitten nog allerlei varianten. In mijn team zijn de testers in staat om stukken code te schrijven. Dit is ook onze gewenste werkwijze, omdat we hiermee het werk het beste kunnen delen, onderhouden en gebruiken.

Continuous integration

Zoals al bij eerdere factoren aan bod kwam, is in mijn team continuous integration belangrijk. Ik wil een tool die ik naadloos in mijn pipelines kan hangen, zodat ik bijvoorbeeld een smoke test kan uitvoeren na een deployment of een nachtelijke regressietest. Dat betekent ook dat de resultaten gebruikt worden om te bepalen of de pipeline door kan gaan en dat bepaalde acties (zoals een check-in) ervoor zorgen dat de tests gestart worden.

Landschap

Wat voor systemen hebben wij tot onze beschikking? Ik probeer het hele landschap te beschrijven om een zo goed mogelijk beeld te krijgen. Ik heb tijdens een eerdere stap al vastgesteld dat er geen budget is voor nieuwe machines of omgevingen, maar een software-upgrade behoort wel tot de mogelijkheden mits de reden goed genoeg is.

Wij werken allemaal op Windows en ook onze buildservers zijn Windows. Ik maak alvast een overzicht van de (gemiddelde) specificaties van de machines en de exacte versies van de software op die machines. Een upgrade van de software of het besturingssysteem is niet uitgesloten, maar ook niet gewenst. Ik maak een overzicht van de gebruikte taal, IDE, CI tool, repositories et cetera.

Ondersteuning

Ondersteuning is een factor die van tevoren moeilijk te kwantificeren is. Natuurlijk wil ik hulp als ons iets niet lukt. Ik wil graag weten hoe ik aan die hulp kom. Zijn er bijvoorbeeld actieve communities online? Of heeft de fabrikant een goede oplossing om ondersteuning te bieden? En wat gaat die ondersteuning ons kosten? Van tevoren kan ik hier niet echt iets over zeggen, behalve of hier budget voor zal zijn. Wel moet ik het meenemen in mijn overweging.

Team

Als tester ben ik niet alleen, ik werk in een team. En hoe subjectief ook, de tool moet in mijn team passen. Als ik de enige ben die er mee kan of wil werken, dan is het geen goede tool voor ons. Daarom maak ik een beschrijving van mijn team. Dit gaat verder dan de eerder beschreven kennis, maar bijvoorbeeld ook beschikbaarheid. We hebben bijvoorbeeld wel een ontwikkelaar in ons team die goed Java kan, maar hij is maar drie dagen beschikbaar en heeft het dus al erg druk.

Toekomst

Als laatste probeer ik naar de toekomst te kijken. Ik bedoel hier zowel de toekomst van het project en het team, als van de tool zelf, hoewel ook hier dat laatste niet van tevoren te beschrijven is. Bij het project kijk ik of er nieuwe versies van onze basis (taal, tools, platform) ondersteund moeten worden, en zoja hoe snel. Bij een eerder project werkte ik bijvoorbeeld aan een iOS-applicatie, die zo snel mogelijk iedere nieuwe versie van iOS moest ondersteunen. Dan moet de testtool dit dus ook doen. Dat betekent dat de tool in het verleden ook redelijk snel al nieuwere versies of nieuwe technieken heeft ondersteund. Onze wens voor de toekomst van de tool is een stabiele basis waardoor verwacht kan worden dat de tool in de nabije toekomst ondersteund en doorontwikkeld wordt. Dan gaat het ons niet alleen om nieuwe versies, maar ook om bugfixes in de tool zelf.

Keuze maken

Ik heb gekeken naar de factoren die invloed hebben op mijn keuze. Ik weet nu naar wat voor soort tool ik op zoek ben. Ik moet nog een paar dingen doen om een goede keuze te maken.

Inventariseren

Eigenlijk heb ik de eerste stap bij het maken van de keuze al genomen, door te inventariseren wat ik nodig heb. Alle zaken die bij het bekijken van de bovenstaande factoren aan bod zijn gekomen, zet ik in een lijst. Ik geef ook aan welke factoren echte dealbreakers zijn. We kunnen natuurlijk heel objectief kijken naar welke tool echt de beste is, maar als een tool met jaarlijkse kosten niet in het budget zit, dan zal die nooit onze keuze zijn. Een uitgebreide manier om dit te doen is door de lijst te prioriteren met de MoSCoW-methode (Must have, Should have, Could have, Want to have).

Daarnaast ga ik inventariseren wat er is. Ik ga op zoek naar de beschikbare tooling en maak een simpele lijst van de tools en de plekken waar ik informatie kan vinden.

Evalueren

De tooling die ik gevonden heb, ga ik evalueren aan de hand van de lijst met factoren die ik gemaakt heb. Ik pak mijn lijst en zet simpelweg vinkjes bij de factoren waaraan de tool voldoet. Ik maak altijd zo’n vergelijkingslijstje van productspecificaties, simpel en overzichtelijk. Op basis van deze lijst zijn er waarschijnlijk een of enkele tools die lijken te voldoen aan de meeste of de belangrijkste eisen.

Proberen

Met de tools die op basis van de evaluatie een goede keuze lijken, ga ik een proof of concept maken. Ik ga, alleen of samen met het team, een paar tests schrijven, de tool in de pipeline integreren en de rapporten lezen. Kortom, even proberen of het echt zo mooi is als het lijkt. Dit hoeft echt niet heel uitgebreid te zijn, maar je wilt graag even zien of de verhalen van de makers van de tool wel waar zijn. Mocht zelf een proof of concept maken niet kunnen (bijvoorbeeld omdat er geen demoversie of proeflicense beschikbaar is) dan zou ik altijd om een demo van de fabrikant vragen. Hierbij zou ik vragen voorbereiden die heel specifiek op de echte situatie slaan, zodat je zoveel mogelijk gedetailleerde informatie kan verkrijgen.

Kiezen

Tja, en dan is de laatste stap na dit lange en uitgebreide proces, natuurlijk de keuze maken. Dit wordt dan een van de tools, of misschien wel een combinatie van enkele tools, die het beste past bij de situatie en de wens die het team en de opdrachtgever hebben. Gefeliciteerd, en veel plezier bij het gebruik ervan!