De Cloud ontslaat je niet van de noodzaak te testen. De risico’s en dus de wijze van testen verschillen wel tussen Cloud en niet-Cloud. Je zult regelmatig regressietesten moeten doen en je testset moeten aanpassen om geen risico’s te missen of te veel te testen. Een goede administratie van testgevallen is daarom essentieel.

Werken in de Cloud is volledig ingeburgerd. Particulieren gebruiken Chromebooks, Dropbox, Gmail en Office Online volop en bedrijven hebben delen van hun IT in de Cloud gezet: dataopslag, complete applicaties en soms zelfs diensten. De voordelen en de risico’s zijn bekend: je betaalt voor wat je gebruikt, je wordt ontzorgd en kunt je meer op je eigenlijke dienst richten, maar je bent ook afhankelijk van de stabiliteit en snelheid van het Internet en je moet er op vertrouwen dat er vertrouwelijk met je gegevens wordt omgegaan. Software as a Service, Data as a Service, Platform as a Service zijn voorbeelden waarin hele delen van de Informatietechnologie buitenshuis zijn belegd.

Wat is de Cloud?

Als iets in de Cloud staat betekent het dat het (software, dataopslag, werkplek) via Internet door een gespecialiseerd bedrijf wordt aangeboden en dat het niet meer daadwerkelijk op apparatuur bij je eigen bedrijf hoeft te staan. Als je Software (SAAS) uit de Cloud haalt, dan bezit je de software niet, je hoeft hem ook niet op eigen computers te hebben geïnstalleerd en je hoeft het zelf niet in de lucht te houden of te onderhouden. Je gebruikt  de software, of nog sterker: je neemt een dienst af. Vergelijk het met het leasen van een auto. Als je least betaal je er voor dat je in de leaseperiode die auto tot je beschikking hebt. De leasemaatschappij garandeert de auto. Gaat de auto stuk, dan moet de leasemaatschappij er voor zorgen dat je steeds een zelfde auto beschikbaar hebt. Je betaalt voor het gebruik en je koopt niets.

Testen en de Cloud

De Cloudleverancier garandeert dus de kwaliteit en beschikbaarheid van de software (in geval van SAAS). Je lijkt hierdoor een aantal zaken niet meer te hoeven doen die normaal bij ontwikkeling en beheer van software horen, zoals testen. Maar schijn bedriegt.

  • Of je nu zelf software ontwikkelt en beheert of iemand anders: je moet weten of de software aan jouw eisen voldoet en je proces en dienst goed ondersteunt en niet verstoort. Je kunt acceptatietesten niet uitbesteden. Je kunt dit deels uitbesteden, maar dan moet je toch zelf nog strenge regie voeren.
  • Als software in een keten met andere software functioneert (meerdere SAAS aanbieders): wie test dan de samenhang? Eén van de SAAS-leveranciers of allemaal samen? Hoogstwaarschijnlijk doen zij dit niet. Je zult dus zelf integratietesten moeten uitvoeren.
  • Softwareleveranciers, zeker in geval van SAAS, bedienen heel veel, diverse klanten. Snappen ze alle processen bij al die klanten? Weten ze van alle klanten wat de meest bedrijfskritische functionaliteit is en testen ze dat? Het antwoord is steeds: hoogstwaarschijnlijk niet (volledig). Je zult kritische functionaliteit en processen dus moeten hertesten.

Wat is anders?

  • Verschil tussen basisfunctionaliteit en eigen inrichting en specifieke aanpassingen: het heeft geen zin om de basisfunctionaliteit (waar alle andere klanten ook gebruik van maken) intensief te testen. Dit is al gedaan door de leverancier en waarschijnlijk andere klanten, zeker als je niet de eerste gebruiker van een versie bent. Kleine kans op fouten, laag risico. Echter: veel organisaties hebben een eigen inrichting (instellingen, koppelingen met andere software of kleine softwarepakketjes die iets extra’s doen). Deze moet je dus WEL met aandacht testen. Als tester (of testcoördinator) moet je dus weten wat basisfunctionaliteit is en wat niet. Dit moet in je testgevallen tot uitdrukking komen. Een goede administratie van je testgevallen is dus belangrijk zodat je de juiste keuzes kunt maken op basis van de wijzigingen in een versie en het verschil tussen basisfunctionaliteit en specifieke functionaliteit.
  • Integratietesten: dit moest je altijd al doen maar in geval van Cloud zijn hier de risico’s het hoogst. Sommige Cloudapplicaties werken ook bij veel andere klanten met dezelfde koppelingen, dan is de noodzaak weer minder en kun je de testinspanning delen met andere klanten. Maar denk aan een EPD dat een koppeling heeft met hartbewakingsapparatuur: deze is ook afhankelijk van je eigen infrastructuur, rechten van gebruikers, versies van die apparatuur, instellingen en dergelijke. Cloudapplicaties zullen hier niet automatisch goed mee om kunnen gaan en je eigen beheerafdeling zal steeds ook instellingen moeten aanpassen. Hoog risico, dus: goed testen. Hiervoor moet je goede testomgevingen inrichten, waarin je bijvoorbeeld apparatuur (zoals de hartbewaking) tijdelijk koppelt. Integratietesten moeten goed worden geadministreerd zodat je steeds precies weet wat je moet doen, wie wat moet doen en wat je nodig hebt om te kunnen testen (zoals klaarzetten van testgegevens en een goede testomgeving).
  • Bugfixing is anders: als je een fout vindt tijdens testen, verwacht niet dat de fout in een dag is opgelost, zoals in het geval je eigen IT-afdeling onderhoud van de software doet. Je komt op een wachtlijst (van alle bugfixes met andere klanten). Je moet als tester kunnen inschatten hoe belangrijk een fout is: kunnen we toch in productie gaan, moet er een andere oplossing worden gevonden (buiten de Cloudleverancier om) of moeten we wachten op de versie waarin de fout is opgelost? Het is daarom van belang dat je een goede administratie hebt van je testen en je gevonden fouten zodat je deze duidelijk kunt communiceren (aan de leverancier en management) en in latere instantie kunt hertesten.