Drie misvattingen over het testen van cloudoplossingen - en hoe je ze voorkomt

Het is maandag 8:30 als Martha – een logistieke medewerker – de helpdesk belt. “Goedemorgen, ik kan niet printen. Iedere keer krijg ik de melding: 'Can't find printer'. Ik heb de printer zelfs opgetild en voor de monitor neergezet. De computer zegt nog steeds dat hij de printer niet kan vinden…”

Wat kon het probleem zijn? Het projectteam had het weekend ervoor een nieuwe cloudoplossing geïmplementeerd en de printer deed het daarvoor al twintig jaar zonder problemen. In de loop van de ochtend stapelden de problemen zich op. Doordat de printer niet werkte, werden geen transportlabels geprint. Dozen met goederen werden daardoor niet verstuurd. In de dagen erna werden pallets vol artikelen geleverd. Waardoor het magazijn overvol begon te raken. Pas na vier dagen waren de oorzaak en de oplossing gevonden.

Hadden we dit cloudproduct in combinatie met de standaardprinter dan misschien wél moeten testen in het Go-live weekend op de productie-omgeving?

Een perfecte illusie

Werken ‘in de cloud’ is tegenwoordig niet meer weg te denken uit het bedrijfsleven. Dit geldt zowel voor de Private als de Public Cloud. Een leverancier van een SaaS (Software as a Service) oplossing garandeert klanten de kwaliteit en beschikbaarheid van hun product. De illusie wordt gewekt dat daardoor minder testen nodig zijn dan bij software-ontwikkeling. Dat is slechts ten dele waar.

Hoe dan?

Migreren naar een cloudoplossing betekent vooral dat je op een andere manier test dan bij een software-ontwikkeltraject. Cloudoplossingen ondersteunen handelingen en integraties met andere ondersteunende software die nodig is voor jouw bedrijfsproces. Dat doe je door diverse (belangrijke) praktijksituaties op te schrijven en deze uit te voeren (testen) in de nieuwe cloudoplossing. Een praktisch voorbeeld bij de implementatie van een nieuw inkoopsysteem is: maak een inkooporder aan met twee artikelen, keur deze goed en controleer of de bestelling wordt verzonden en correct ontvangen naar de applicatie van je leverancier. Ook functionele integratietesten op kleinere schaal is essentieel. Het lokaal printen vanuit de cloudoplossing is een mooi voorbeeld hiervan.

Naast het functioneel testen is het testen van non functionals ook een zeer relevant aspect bij cloudtrajecten. Dat beschrijf ik in een volgend blog.

Misvattingen

Er zijn nog veel misvattingen over het testen van cloudoplossingen. In deze blog noem ik er drie.

1. Bij een migratie naar de cloud hoef je niet meer te testen

De leverancier heeft de functies van zijn SaaS-oplossing al goed getest voor hij deze beschikbaar stelt aan klanten. Het is dus zinloos dat de klant het SaaS-product (de Software) eveneens test. Dit betekent niet dat de klant geen testen meer uit hoeft te voeren. Het grote verschil tussen de testaanpak bij software-ontwikkeltrajecten en cloudoplossingen is dat bij cloud de focus op het testen van bedrijfsprocessen ligt. Een goed voorbeeld hiervan is het testen van SAP S/4 HANA in de cloud. Deze testaanpak geldt ook voor standaard pakketten die niet in de cloud staan. De zogenaamde Commercial Of The Shelf producten (COTS). 

2. Testen in de productie-omgeving is niet mogelijk

Softwareleveranciers hebben vooral verstand van hun software en niet van de kritische bedrijfsprocessen van klanten. Die kennis zit bij de klant zelf, bij kerngebruikers en materiedeskundigen. Het is dan ook verstandig om die te betrekken bij het uitvoeren van (keten)testen. Deze test je vooral op de acceptatie-omgevingen. Testen op productie-omgevingen is ook mogelijk. Denk aan Operational Acceptance Testing (OAT), bijvoorbeeld het testen van je randapparatuur in het Go-live weekend waarmee je voorkomt dat je magazijn vol raakt vanwege het niet uit kunnen leveren van producten.

3. Testautomatisering inzetten is noodzakelijk

Bij regressietesten, in geval van nieuwe releases, kan testautomatisering helpen maar het is geen vereiste. Het opzetten van een automatiseringstraject is een project op zich. Welke afwegingen je hierbij maakt vind je hier. Testautomatisering vraagt wel een bepaalde volwassenheid van de (test)organisatie. Voor het maken van de stap naar geautomatiseerd testen raad ik aan om dit artikel over TestSavvy te lezen.

Kwaliteit is een keuze

Bij traditionele ontwikkeltrajecten ligt de focus op het functioneel testen van de applicatie. Daarbij passen bedrijven tegenwoordig moderne technieken toe zoals Behaviour Driven Development (BDD) en Test Driven Development (TDD). Deze zijn minder toepasbaar bij cloudimplementaties waar in principe alleen een bedrijfsspecifieke configuratie plaatsvindt.

Je kunt testen van cloudoplossingen (deels) uitbesteden aan testers of testautomatiseerders. Realiseer je wel dat zij daarvoor kennis nodig hebben van de bedrijfsprocessen. Zelf de regie blijven voeren over testen als eindgebruikersorganisatie is daarom aan te raden. ‘Gezond Boerenverstand’ en een gedegen vastlegging van testgevallen en testresultaten helpen hierbij om de testdoelstellingen te bereiken: zo min mogelijk operationele verstoringen. Een handige methode die helpt om de testdekking te bepalen is Risk & Requirement Based Testen. Deze methode is prima toe te passen op het testen van bedrijfsprocessen.

De best practices die bestaan voor testen (inclusief bedrijfsprocessen) zijn ook voor cloudoplossingen van toepassing. Dit geldt ook voor het ‘Project A-B-C’ dat ik zelf graag hanteer:

‘Assume Nothing, Believe Nobody, Check Everything’

Er zijn drie misvattingen over testen in de cloud

Ook dit is natuurlijk een misvatting want er zijn er nog veel meer. Welke misvatting of leerpunt gerelateerd aan testen over een cloudproject wil jij delen? Ik zie ze met belangstelling tegemoet in de comments onder dit artikel :)