Rol testmanager bij selecteren van website in de cloud.

Posted on May 24, 2013 by Kees Blokland

In deze blog sta ik stil bij de rol die een testmanager in het selectieproces kan spelen. Punt is dat na de selectie allerlei zaken vastliggen, dus ook productrisico’s bij de invoering en het gebruik van de geselecteerde cloud service. Welke bijdrage kan een testmanager leveren tijdens het selectieproces om die risico’s voor het selectiebesluit te managen?

In de vorige blog staan enkele eisen aan de CMS/website als basis voor selectiecriteria. Het compleet krijgen van selectiecriteria is een taak die de testmanager past: het lijkt op ‘intake van de testbasis’. Vervolgens de vraag: hoe kunnen we controleren of een kandidaat SaaS CMS aan bepaalde eisen kan voldoen? Hiervoor kan de testmanager (test)maatregelen uitvoeren vooraf aan een selectiebesluit.

Een interessante maatregel is een proof of concept (POC), waarbij de beoogde SaaS CMS wordt uitgeprobeerd met praktijkgevallen. Er hoeft niets voor worden aangeschaft of geïnstalleerd, het tijdelijk afnemen van de beoogde service (kan vaak gratis voor probeerdoeleinden) volstaat. Vervolgens worden een aantal testgevallen uitgevoerd. Als die na de uitvoering op OK staan, kan er een GO gegeven worden voor een selectiebesluit.

Terug naar het CMS dat onderwerp is van deze blog reeks. De kandidaat SaaS CMS leverancier bood inderdaad de mogelijkheid om een maand lang gratis een proef uit te voeren en een website op te bouwen. Daar is gebruik van gemaakt en de volgende ‘testgevallen’ zijn onder meer uitgevoerd.

menu’s maken
formulieren maken met verplichte velden en controles
evenementen aanmaken met registratiemogelijkheid
inlogmogelijkheid voor leden van de organisatie
mogelijkheid voor automatisch gegenereerde overzichten bv van nieuwitems
etc.
ook: hoe intuïtief werkt het CMS (hoe moeilijk is het om te leren)?
hoe vlot reageert de website?
is er een ‘testomgeving’?

In de volgende blog ga ik in op het aspect ‘leverancier’: met een cloud service kies je ook voor een leverancier. Leveringsvoorwaarden vormen interessante literatuur voor een testmanager in het selectieproces.

[Dit is de derde editie in een serie blogs over de migratie van een website naar een SaaS (Software as a Service) omgeving en de rol van testen in dat traject. Meer info over het testen van cloud services kan gevonden worden in het boek Testen van Cloud services.]

10 mei: Polteq Cloutest event op herhaling.

Posted on May 11, 2012 by Kees Blokland

Donderdag 10 mei j.l. werden ruim 50 extra gasten in staat gesteld om de Cloutest keynote van Martin Pol, Ruud Teunnissen, Jeroen Mengerink en Kees Blokland bij te wonen. Evenals de premiere van het verhaal op 8 maart werd de herhaling gegeven in de Eenhoorn te Amersfoort. De groep van afgelopen donderdag moest de bijdrage van Lee Copeland op 8 maart missen, maar hierdoor was er wel ruimte voor interactie met het publiek.

Enkele voorbeelden van vragen die werden gesteld.

Hoe moet dat met testen als je geen OTAP straat hebt voor de service?
Wat zegt load testen als je niet zeker weet wat de invloed van anderen is?
Als je de load opvoert om de elasticiteit te testen kun je dan het opschalen bij de leverancier waarnemen?
Hebben jullie ook stil gestaan bij juridische problemen bij faillissement van een cloud service leverancier? Wie is dan eigenaar van de gegevens/de software?
Betrokkenheid bij selectie is toch niet nieuw?
Moeten we ons als testers echt opnieuw invechten? (in selectie)
Loop je niet een geweldig risico door vendor lock-in?
Als je met testen in productie een probleem tegen komt is het toch al te laat?
Zou de leverancier geen Acceptatieomgeving moeten hebben om als afnemer een voorgenomen aanpassing in de service te kunnen accepteren?
…

We zullen in een aantal blogs nader ingaan op de vragen. We beginnen hier met het OTAP vraagstuk.

Hoe moet dat met testen als je geen OTAP straat hebt voor de service?
De vraag krijgt twee antwoorden. Om te beginnen vanuit het perspectief van de afnemer. De Productieomgeving staat voor de service die door de gebruikers wordt afgenomen. Kun je daar tests op uitvoeren? Zolang dat de gebruikers niet in de weg zit kan dat best. Een alternatief is om de service als het ware nog een keer af te nemen. Eventueel op kleinere schaal. Dan heb je dus een Testomgeving of Acceptatieomgeving gecreëerd. Of wellicht zelfs een Ontwikkelomgeving als je bepaalde instellingen of configuratie wilt uitproberen. Net zoals bij virtualisatie is het mogelijk net zoveel omgevingen te creëren als nodig. Die kunnen allemaal productiegelijk zijn omdat precies dezelfde service wordt afgenomen. Doordat de huur van de omgevingen eenvoudig kan worden opgezegd zijn er geen investeringen in apparatuur nodig.

Het perspectief van de leverancier ziet er traditioneel uit: die moet een informatiesysteem (de service) ontwikkelen, testen en in de lucht houden. Die zal dus het volledige OTAP register open moeten trekken. De afnemer ziet uiteraard alleen de Productieomgeving.

OTAP afnemer met 1 cloud service

In het Cloutest boek hoofdstuk 5.4 “Testen rond beheerbaarheid” wordt uitgebreid stil gestaan bij het omgevingenvraagstuk.

24/7 availability and performance monitoring

Posted on April 27, 2012 by Jeroen Mengerink

(From the Q&A session after Ruud’s EuroSTAR webinar).

Q: Would you slice the performance testing with a load test tool on parts of the cloud to provide 24×7 availability with a distributed (physically throughout the main markets) performance monitoring as a strategy? – Bernhard Klemm

A: Only if the risks are high enough to want to do this. 24/7 availability checking is an expensive measure to use. To perform a thorough check on availability it is needed to slice and distribute, since we want cloud services to be available from multiple locations – Ruud Teunissen

Cloud vereist meer testen

Posted on April 16, 2012 by Jeroen Mengerink

De betrokkenheid van testen in organisaties waar cloudservices gebruikt worden, moet hoger zijn dan in andere organisaties. Testen is niet enkel betrokken bij de implementatie, maar moet ook aanhaken bij selectie en zelfs in productie houdt het testen niet op.

Selectie van een service begint voordat testen normaal gesproken wordt aangehaakt. Bij cloudservices wordt vooraf al een traject doorlopen om de goede service uit te kiezen en ook hier moet al over risico’s nagedacht worden. Het gevecht om op het goede moment aangesloten te worden gaat dus weer beginnen. Aangezien het uitkiezen van een service vaak voornamelijk op prijs gebaseerd is, zal het testen zich binnen moeten vechten bij de afdeling inkoop. Organisaties moeten zich gaan realiseren dat voor een dubbeltje op de eerste rang zitten, veel risico’s meebrengt.

Tijdens implementatie moet nog steeds het “traditionele” testwerk plaatsvinden. Hiervoor kunnen beproefde technieken en methoden gebruikt worden, maar moet wel goed over de nieuwe context nagedacht worden. De cloud vereist soms een nieuwe manier van toepassen van een oude methode, of het combineren van oude methoden tot een terdege aanpak.

Vervolgens gaat men na de implementatie in productie. De wereld staat echter niet stil! In deze continu veranderende wereld, waarbij gedeeltes van processen in de cloud (dus buiten eigen beheer) plaatsvinden, moet continu getest worden of “alles nog werkt”. Naast deze vereiste controle, moet ook beoordeeld worden of een leverancier nog aan zijn verplichtingen voldoet. Monitoring gaat, vanwege minder beheer om dit uit te voeren, een prominentere plaats krijgen binnen het vakgebied testen.

Let op dat men niet te makkelijk het testen vòòr productie loslaat omdat “het nu toch ook in productie kan”. De testinspanning is in elk van de drie fases belangrijk en moet niet onderschat worden. Denk eraan dat het testen tijdens selectie en in productie wordt gebruikt om risico’s af te dekken, net als het testen tijdens implementatie! Ofwel no risk, no test.