Door René van Veldhuijzen ● r.vanveldhuijzen@squerist.nl ● Jan Jaap Cannegieter ● j.cannegieter@squerist.nl
Testen kan verschillende doelen dienen. Het is voor testspecialisten, ongeacht of ze in een watervalproject of in een Agile-/DevOps-team werken, belangrijk om te weten welk doel of welke doelen het testen in hun situatie heeft. In dit artikel beschrijven we drie categorieën van doelen die projecten of organisaties kunnen hebben met testen. We bespreken ook twee cases hoe deze doelen in de praktijk toegepast kunnen worden.
De doelen van het testen zijn als vanzelfsprekend afgeleid van het projectdoel. Op hoog abstractieniveau onderkennen we drie categorieën van doelen met testen. De eerste categorie is vaststellen of het systeem in lijn ligt met relevante wet- en regelgeving, requirements, overeenkomsten en dergelijke. We noemen dit checken, omdat het alleen maar bevestigt of het systeem in lijn ligt met deze referentiekaders[1]. Afhankelijk van de wettelijke of organisatorische relevantie van het referentiekader is voor dit doel geen risicoanalyse of prioritering nodig. Als er voldaan moet worden aan een bepaalde wet of een set requirements, dan moet dat gewoon worden gecheckt. Daarom wordt er in dit soort gevallen geen risicoanalyse uitgevoerd.
De tweede categorie is risk based testen. Wat zijn de risico’s als we met het nieuwe systeem of de aanpassing in productie gaan? Deze risico’s worden onderverdeeld in businessrisico’s en technische risico’s; afhankelijk van de uitkomst van de analyse worden bepaalde delen van het systeem zwaarder of minder zwaar getest. Als er risk based wordt getest, testen we meestal niet alles maar alleen de componenten met de grootste risico’s.
De derde categorie is value based testen. Bij deze vorm van testen geven we antwoord op de vraag of de beoogde doelen van het systeem of de aanpassing worden gehaald. Value based testen kan zowel vóór als ná de implementatie worden uitgevoerd. Als value based testen vóór de implementatie wordt uitgevoerd, dan schatten we in of de doelen zullen worden behaald. Na de implementatie kun je dit daadwerkelijk vaststellen.
Afhankelijk van de organisatie, het project en het systeem zijn één of meer van de doelen van testen relevant. In de volgende twee cases behandelen we voorbeelden hoe we de drie verschillende doelen hebben gebruikt. Case 1 betreft een grote overheidsorganisatie die volgens de watervalmethodiek werkt. Case 2 gaat over een DevOps-team dat een webapplicatie ontwikkelt en beheert. De webapplicatie wordt gebruikt door een grote groep van onbekende gebruikers.
Case 1: Groot watervalproject
De organisatie in dit voorbeeld is de facilitaire dienst van een groot ministerie. Het systeem dat wordt gerealiseerd, zal gebruikt gaan worden door alle medewerkers van het ministerie. Het is een complex project met veel verschillende stakeholders, ieder met eigen belangen en doelen. De IT-afdeling is relatief klein en werkt veel met externe leveranciers. De meeste systemen zijn commerciële standaardpakketten, meestal aangepast aan de wensen van de organisatie. Bij dit project gaat het om een SaaS-oplossing die wordt geparametriseerd en aangepast voor de organisatie. Het ondersteunt één van de interne processen voor educatieve doeleinden. De leverancier doet het meeste werk, zoals requirements verzamelen, het parametriseren, aanpassingen doorvoeren en, volgens contractuele afspraak, testen. De IT-afdeling had, in ieder geval aan het begin van het project, alleen de opdrachtgeverrol en gebruikersrol.
In het oorspronkelijke plan zou de opdrachtgever niet testen, daar zou de leverancier voor zorgen. Dit is expliciet in het contract beschreven. De acceptatie zou bestaan uit een demo. De realiteit was echter anders. Vanaf de start van het project waren er allerlei signalen dat testen onprofessioneel of helemaal niet werd uitgevoerd. Als er al getest was, dan was dit ongestructureerd, zonder testontwerp, zonder de toepassing van testtechnieken, zonder inzicht in de testdekking en door niet-professionele testers. Vooral het gebrek aan een gestructureerd en idealiter ook geautomatiseerd regressietesten heeft voor verschillende problemen gezorgd. Deze problemen hebben geleid tot een slechte kwaliteit van het systeem. Uiteindelijk zijn er juridische stappen genomen vanwege de duidelijke afspraken in het contract. Wij gaan verder niet op de juridische consequenties in, maar focussen ons op de testaspecten.
De opdrachtgever had in verband met het gebrek aan testen bij de leverancier besloten om zelf te gaan testen omdat de opdrachtgever de kwaliteit onafhankelijk van de leverancier wilde vaststellen. Zij hebben toen doelen opgesteld voor het testen. Aan het begin van het project had testen twee aan checken gerelateerde doelen. Ten eerste moest het testteam vaststellen of alle stappen van het proces ondersteund werden door het systeem. De processen waren duidelijk, hoewel ze aangepast moesten worden om ze met behulp van het systeem efficiënter in te richten. Door alle processen en processtappen te testen werd duidelijk of de geplande processen met het systeem konden worden uitgevoerd. Er was geen prioritering, alle processen en processtappen moesten worden getest. Ten tweede moest voor de implementatie vastgesteld worden of aan alle contractuele requirements werd voldaan. Ook daar was geen prioritering noodzakelijk omdat de opdrachtgever er zeker van wilde zijn dat de leverancier de requirements juist had verwerkt in het systeem. Beide testactiviteiten waren dus checken, niet risk based testen of value based testen.
Naast het checken van de processen en requirements heeft de opdrachtgever een productrisicoanalyse uitgevoerd. Vier risicocategorieën werden vastgesteld: de happy flow, kritieke functies (vanuit organisatorisch perspectief), de jaarlijkse activiteiten en de financiële processen. Binnen deze categorieën werden risico’s geïdentificeerd en geprioriteerd. De risico’s en prioriteiten bepaalde in hoeverre specifieke onderdelen van het systeem getest zouden worden. De niet-functionele zaken waren niet meegenomen bij de risicobeoordeling. Tijdens het testen ervaarde de opdrachtgever dat performance een serieus probleem was geworden en dat er een professionele performancetest moest worden uitgevoerd. Andere niet-functionele zaken waren impliciet onderdeel van het testen, met uitzondering van securitytesten. Dit onderdeel werd door een aparte partij uitgevoerd.
Tijdens het schrijven van dit artikel bevindt het project zich in de testfase. De projectdoelen zijn duidelijk en regelmatig kijkt het team of de projectdoelen gehaald worden. Dit werd niet expliciet getest. Er zijn geen plannen om value based testen expliciet uit te voeren, deze vorm van impliciet value based testen volstaat.
In dit project zien we dat in deze situatie alle drie doelen van testen (checken, risk based testen en doelgericht testen) zijn toegepast en toegevoegde waarde hebben voor de opdrachtgever.
Case 2: DevOps-team dat een app bouwt
Case 2 is totaal verschillend van case 1. Case 2 betreft een DevOps-team dat een webapplicatie realiseert en beheert in de vorm van een responsive website. Doel van de webapplicatie is het bij elkaar brengen van vraag en aanbod van een specifiek product (marktplaats). Naast het bouwen van een applicatie werd een continuous integration en continuous deployment straat (CI/CD-straat) gebouwd om het mogelijk te maken nieuwe features binnen enkele minuten gecontroleerd live te brengen.
Aan het begin van de ontwikkeling van de website waren er geen teamleden die ervaring hadden met professioneel testen. In dit stadium werd dit niet als probleem ervaren, toen de implementatie van de eerste versie in zicht kwam veranderde dit. Zeker bij CI/CD moeten veel van de testen geautomatiseerd zijn. Het unittesten werd door de ontwikkelaars op professionele wijze uitgevoerd en geautomatiseerd. De dekking van de unittesten werd gemeten met een tool en toonde een hoge dekkingsgraad (meer dan 80%). Functionele en niet-functionele testen werden echter minder goed uitgevoerd door het team. Om dit te verbeteren werd er een testconsultant ingehuurd en snel daarna een testspecialist. De testconsultant is gestart met een inschatting van de productrisico’s en het team besliste wat er gedaan moest worden met betrekking tot de drie doelen van testen (checken, risk based testen en doelgericht testen). In dit geval waren er geen externe referentiekaders waaraan voldaan moest worden. Intern was er een stijlgids met eisen waar de website aan moest voldoen. Omdat de front-end ontwikkelaars deze richtlijnen goed opvolgden, was er geen noodzaak om dit te checken. Er werd dus geen vorm van checken toegepast in deze case.
Risk based testen was erg belangrijk in deze case. De testconsultant startte, samen met de andere teamleden, de productowner en afgevaardigden van de opdrachtgever, met een analyse welke niet-functionele kwaliteitsaspecten van belang waren. Er is gebruikgemaakt van de ISO 25010-standaard waar zeven relevante niet-functionele kwaliteitsaspecten uit voortkwamen. Deze aspecten leidde tot specifieke testactiviteiten (performancetest, securitytest) of focus bij het testen in de sprints.
Risk based testen op functioneel niveau werd geïmplementeerd in het testen van de user stories. Het team schatte aan het begin van iedere sprint de businessrisico’s en technische risico’s van iedere user story in. Op basis van dit resultaat bepaalde het team de diepgang van het testen. Dit was waardevolle informatie voor de sprintplanning in het algemeen en het testen gedurende de sprint in het bijzonder. De tester voerde de meeste testen eerst handmatig uit om zo snel mogelijk een beeld te krijgen van de nieuwe functionaliteit, de tester of een ander teamlid automatiseerde een deel van de testen met Selenium. De tester besliste welke testen onderdeel werden van de geautomatiseerd regressietest, de tester nam deze beslissing ook op basis van risico’s. De Selenium-testen werden onderdeel van de CI/CD straat. Naast het testen van de user stories voerde de tester end-to-end tests uit. Bij deze test voerde de tester een beperkt aantal testen uit om vast te stellen of de verschillende software- en hardwarecomponenten goed met elkaar samenwerkte. De end-to-end test was niet risk based, alle hardware- en software componenten moesten worden geraakt. Ook de end-to-end testen werden onderdeel van de CI/CD-straat.
Aan het begin van het project waren er duidelijke en haalbare doelen voor dit project opgesteld, op basis van deze doelen werden value based testen toegepast. De doelen waren een minimaal marktaandeel, voldoende business voor de deelnemende bedrijven en een vastgesteld investeringsniveau voor de investeerders. Tijdens de realisatie hebben het team en de andere belanghebbenden regelmatig beslissingen genomen welke richting de ontwikkeling uit moest gaan om de gestelde doelen te bereiken. Deze beslissingen werden genomen op basis van testresultaten en andere onderzoeken, zoals testsessies met gebruikers. Na de lancering verzamelden het team, de producteigenaar en vertegenwoordigers van de opdrachtgevers informatie om te beoordelen of de doelen waren bereikt. Value based testen werd dus zowel voor als na implementatie toegepast.
Afsluitend
Aan het begin van dit artikel hebben we gezien dat op een hoog abstractieniveau drie doelen met testen kunnen hebben: voldoen we aan alle wetten, voorschriften, vereisten en andere richtlijnen waaraan we moeten voldoen (checken), dekken we alle relevante risico’s af (risk based testen) en halen we de project- en systeemdoelen (value based testen). Testers doen er goed aan om, zowel aan het begin van een project als tussentijds, vast te stellen welke van deze doelen relevant zijn voor hun project. Deze analyse helpt om de juiste keuzes met betrekking tot testen te nemen.
[1] In de testwereld wordt checken door sommige anderen anders gedefinieerd. In dit artikel gebruiken we de hier gegeven definitie.