Cloud
computing, vaak kortweg de cloud genoemd, is niet meer weg te denken. De
aandacht die de cloud krijgt, heeft alle kenmerken van een hype, maar dat neemt
niet weg dat het een wezenlijke ontwikkeling is van de manier waarop ICT-diensten
worden verleend. Het afnemen van een cloud service is steeds vaker
aantrekkelijker dan eigen software maken of kopen. In de cloud wordt er alleen
betaald voor wat er wordt gebruikt (pay–per-use) en er kan flexibel capaciteit
worden bij- of afgeschakeld (elasticiteit). Kortom, steeds meer ICT verdwijnt
in de cloud en dat heeft invloed op testen en de rol van de testmanager. Cloud
computing introduceert nieuwe eisen en risico’s waarvoor een speciale
testaanpak nodig is. Hoe test je bijvoorbeeld elasticiteit?Testen zelf verandert ook! Zo is er een significante rol weggelegd voor de testmanager in het selectieproces. Dat is een belangrijke fase om tijdig vast te stellen wat voor risico’s de gebruiker of de business loopt bij de keuze voor een bepaalde cloud service. Die risico’s kunnen liggen op allerlei vlakken. Dat is ook een verandering bij het testen: een accentverschuiving naar niet-functionele aspecten. Het zoeken naar functionele fouten in de software verschuift in de cloud naar de achtergrond.
Nieuwe eisen en risico’s
Cloud
computing is volop in ontwikkeling. Het is dan ook een illusie om te verwachten
dat voor alle nieuwe eisen en risico’s al pasklare testoplossingen beschikbaar
zijn. Dit artikel beschrijft een aantal voorbeelden van cloud-specifieke
risico’s en bijbehorende testaspecten en is een beknopt fundament voor verdere
ontwikkeling.Cloud computing omvat nogal wat. Kijk voor een goed bruikbare definitie op de website van het Amerikaanse NIST (www.nist.gov/itl/cloud/index.cfm).
Krachtige features van cloud computing zijn elasticiteit en pay-per-use. Is er meer capaciteit nodig, bijvoorbeeld omdat er meer gebruikers zijn, dan kan dat on-demand worden geleverd. De gebruiker ziet dit vanzelf terug in de afrekening. Maar hoe kan er getest worden of dit in de praktijk ook werkt? In de aanpak hiervoor is een combinatie nodig van load testen (wisselend gebruik nabootsen en zien dat er capaciteit bij komt en weer af gaat), grenswaardenanalyse (wat gebeurt er op de grens van mijn ’bundel’) en procescyclustest (het handmatige aanvraagproces en de financiële afrekening).
Risico’s
Met de transitie naar de cloud
storten alle risico’s van het internet zich over de afnemer heen. Wat voorheen
geen issue leek (de server stond in het eigen gebouw), wordt in één keer een
punt van aandacht. Wie kan er allemaal bij mijn gegevens in de cloud? Hoe
veilig is het transport eigenlijk? Dit leidt niet tot nieuwe soorten
beveiligingstesten, maar security eist wel een nog belangrijkere plek op bij
het testen.
In
de public cloud kan de service trager worden als gevolg van de (piek)belasting
van andere afnemers. Als de leverancier een abonneemodel hanteert waarbij de
service wordt overboekt (dat levert meer winst op), dan is dat een goede reden
om een real-time loadtest uit te voeren. Daarmee wordt bedoeld: het uitvoeren
van de loadtest op het moment van de dag dat de piekbelasting zich naar
verwachting zal voordoen.
Nieuwe acceptatiecriteria
Cloud services worden mondiaal
aangeboden en daarmee komt een nieuw pakket van acceptatiecriteria om de hoek
kijken: voldoet de cloud service aan allerlei wet- en regelgeving? Zo is onder
meer het bewaren van privacygevoelige gegevens aan allerlei wetten en regels
gebonden. De testmanager zorgt ervoor dat er, in samenspraak met bijvoorbeeld
een jurist, een checklist van wettelijke controlepunten wordt samengesteld. Bij
het afvinken daarvan kunnen er complicaties aan het licht komen, zoals
conflicterende of onduidelijke wetgeving in bepaalde landen en de (on)betrouwbaarheid
van de overheid waar de cloud provider is gevestigd. Dit kan tot verrassingen
leiden, zoals in het voorbeeld van de Amerikaanse overheid die de Patriot Act
in stelling bracht om toegang te krijgen tot de gegevens van WikiLeaks.
Beschikbaarheid
Wanneer een belangrijk business
proces afhangt van een cloud service, is de beschikbaarheid van de service van
groot belang. Als een cloud service leverancier (onaangekondigd) een wijziging
aanbrengt in de service, kan dat verstrekkende gevolgen hebben, zoals een
storing in de koppeling met andere systemen of handleidingen die plotseling
niet meer kloppen. In een end-to-end testopstelling kan de impact van
wijzigingen in een cloud service, maar ook in aangesloten systemen, worden
getest. Er is een groeiende noodzaak voor een continu draaiende, end-to-end
regressietest. Deze test moet niet alleen op functioneel gebied inzicht in de
risico’s bieden, maar ook op non-functionele aspecten, zoals performance. De
taak van de testmanager stopt dus niet na de implementatie, want ook in de
operatie moet er continu worden getest.
Leveranciersaspecten
De afnemer van cloud services
krijgt te maken met allerlei leveranciersaspecten. Wat gebeurt er bijvoorbeeld
precies met de gegevens in de cloud als de leverancier failliet gaat? Is er een
back-up scenario en, zo ja, is dat getest? Ook de migratie naar de cloud en van
de ene cloud service (leverancier) naar een andere moet worden getest. Als er
geen geteste migratiestrategie is, levert een afnemer zich over aan één
leverancier (vendor lock in).
Fenomenen die in de cloud hype
lijken mee te liften zijn Het Nieuwe Werken en Bring Your Own Device. Wordt de
ondersteuning van een veelheid van vaste en mobiele platforms een belangrijk
risico bij cloud computing of niet? De toekomst zal het leren.
Conclusie
Voor de testmanager is een
belangrijke rol weggelegd bij de invoering van cloud computing. De testmanager
moet al in actie komen bij de selectie van cloud services. Maar ook na de
implementatie ervan loopt zijn rol door tot in de operatie van cloud
services. Centraal staan daarbij de risico’s en (test)gerelateerde maatregelen
om die risico’s te beheersen.
No comments:
Post a Comment