Als een tester te horen krijgt dat het testen in de pilot gaan plaatsvinden, samen met de eindgebruikers in de huidige kantooromgeving… Dan gaan er best wel wat haren overeind staan in de nek, kippenvel op de armen en er komt een aanstormend gevoel van onbehagen over de tester heen. Maar zouden we hier niet gewoon open voor moeten staan en onze eerste primaire reactie moeten onderdrukken?
De testers aan het woord
De testvakorganisatie van Nederland, Testnet, heeft 21 juni aanstaande een thema avond “ testen in productie” (http://www.testnet.org/Produktie/Evenementen/ThemaAvond.html). Volgens de beschrijvingen op deze site zullen de presentaties in gaan op het waarom en hoe.
Ik heb dit jaar een presentatie gezien van Egbert Bouman (Valori), waar hij aangaf dat we daar naar toe moeten gaan, testen in productie. Dit vanuit het perspectief van ketentesten en het beheer van test en productie omgevingen. De heer Bouman gaf tevens dat het vroeger toch anders ging: Elektronica werd gemaakt om te testen door extra testcircuits in elektronica te plaatsen. Een voorbeeld is je CV-ketel. Bij Mainframe systemen zie je dit bijvoorbeeld ook.
Ketentesten
Systemen zijn steeds meer aan elkaar gekoppeld en elk stukje software communiceert met een ander stukje software in het zelfde apparaat, in het apparaat onder je bureau, of met een apparaat aan de andere kant van de wereld. Zo zijn informatiestromen grotere “globetrotters” dan de gemiddelde mens.
Sterker nog, software communiceert met een stukje software onder je bureau, deze geeft de boodschap door aan een ander stukje software in de wereld, die het weer doorgeeft aan een ander stukje software, et cetera. Hoe weten we zeker dat als we informatie deze keten insturen, dat de goede informatie er aan de andere kant ook weer uitkomt?
Eén of meerdere Pc’s in een afgesloten testomgeving en een black box testtechniek gaan ons daar met deze toenemende complexiteit niet mee helpen.
Verschillende besturingssystemen, andere protocollen, migratie van data heen en terug. En dan de interpretatie van die data in al die stukjes techniek. En dit weer geïnterpreteerd door uiteindelijk de mens, die in het spel van een menselijke keten ook niet feilloos de boodschap kan overbrengen.
Links in de rij krijgt men te horen: “Dit is een proef, waarmee we gaan proberen de informatie die je nu krijgt aan de andere kan van de rij te krijgen. De toverspreuk is: Wattus unus daga ”. Deze zin gaat van oor tot mond tot oor en is dit na 10 personen in de keten vervormd tot “Moge de Mataglap met je zijn” bijvoorbeeld. Wij mensen maken deze software en koppelen al die onderdelen aan elkaar. Een interpretatie verschil van een 1 of een 0, crashed een component in de keten en kan zo ook de gehele keten onbruikbaar maken.
Mijn ervaring in de praktijk
Ik heb zelf meer dan tien jaar geleden ook software getest in productie, het zogenaamde CLIEP02 bestand waarmee je meerdere overboekingen kon maken (via batchbestand). Dat bestand werd in productie geplaatst met in de records een ‘t’ (voor test) in plaats van een ‘p’ (voor productie). Wel oppassen natuurlijk met dit soort acties. Ik was niet van plan om per ongeluk al het geld van mijn rekening op de rekening van het bedrijf te schrijven.
Bij een andere opdrachtgever hadden we voor het testen van een nieuw landelijk netwerk een “ extra circuit” ingebouwd, door naast de productie servers en switches testapparatuur te plaatsen. Zelfs de bekabeling tussen de diverse steden was voor testdoeleinden apart gereserveerd. Hierdoor ontstond ook een goede representatieve testomgeving. Dit stond echter niet in de initiële projectplannen en was ad-hoc opgebouwd vanuit test, waardoor het niet helemaal een ideale omgeving was, maar heeft wel de mogelijkheden getoond om een “ testcircuit” op te bouwen. In dit geval dus ook een fysiek testcircuit.
Hierbij hebben we wel per ongeluk een keer een geheel kantoor weggedrukt met performance testen door een foutje waardoor de testomgeving deel werd van de productie omgeving. We hadden snel de handen van de knoppen toen we het hoorde en de storing was minimaal, mede door de bewaking en snelle terugkoppeling vanuit de servicedesk.
Maar dat was een klein probleem. Testen in productie kan bijvoorbeeld ook een vliegtuig laten crashen, terwijl je alleen maar bezig was met het testen van zoiets als een administratie systeem.
De meeste tijd heb ik in mijn leven als tester gespendeerd in lab-omgevingen, waarna het product wordt verplaatst (bij een positief resultaat) naar de productie omgeving. En dan kan er nog heel wat fout gaan door verschillen in de twee omgevingen, bij sommige bedrijven is dit zelfs onvermijdelijk en zijn er standaard procedures om dit op te vangen.
Valt het allemaal wel mee?
Het valt allemaal wel mee, je kan goed geïsoleerd testen en voor ketentesten hebben we de testtechniek “programma interface test” . Hmja, voor functionele tests inderdaad.
Maar performance testen dan? Simuleren van een bericht dat door 10 systemen heen gaat die je niet allemaal in je privé laboratorium hebt? Drivers? Stubs? Simulatie software, dat kan al een heleboel doen.
En het testen op infrastructurele componenten. Geld om productie na te bouwen in een testomgeving zal er niet zo vaak zijn, als een productieomgeving überhaupt in kaart te brengen is. De complexiteit kan behoorlijk oplopen, zeker bij de grotere organisaties.
Testen in productie en andere oplossingen
Één oplossing is een extra circuit bouwen in het systeem voor testuitvoering, software en voor infrastructuur ook de hardware. Het gevoel hierbij is dat het niet de meest efficiënte oplossing is. Eén systeem bouwen kost al een hoop centen, maar om er dan nog een tweede ‘ernaast’ te bouwen. Hoe krijg ik dat in mijn testbudget gewaarborgd? Misschien kunnen we beter denken aan andere ontwikkelingen die nu spelen. Dit zijn huidige trends zoals virtualisatie van testomgevingen, testen in de cloud en crowd testing.
Virtualisatie van de testomgeving is prima, kan een hoop tijd en ellende besparen. Maar kan je ook de rest van de keten virtualiseren en meenemen in je testomgeving? Dat zou een goede optie kunnen zijn, en ik heb al een succesverhaal gelezen dit jaar. Dan blijft de vraag hoe je er achter komt wat je dan moet meenemen in de testomgeving.
Het probleem blijft bestaan dat je niet precies weet wat er buiten je eigen vertrouwde omgeving gebeurt. Testing in de cloud en crowd testing is op dit moment vooral gericht op het testen van web based applicaties, waarbij “de cloud” een soort van virtualisatie is (maar dan op steroïden, was een kreet die ik laatst las).
Crowd testing(zie als voorbeeld www.utest.com ) is goed om web based applicaties te testen op verschillende computer configuraties. Het wordt helaas beperkt doordat de testers ver weg zitten en er puur via het geschreven woord wordt gecommuniceerd. Hierdoor kan je het alleen maar toepassen op kleinere applicaties.
Misschien een combinatie van deze drie opties? Waarbij je het systeem bouwt in een virtuele omgeving, in een “cloud” en dubbel uitvoert, een voor het productie werk en een voor testdoeleinden. In dit geval blijf je de onbekende koppelingen met andere systemen behouden. Voor infrastructurele projecten (en overigens ook embedded software) moet je ook nog de afhankelijkheden met de hardware meten waardoor dit niet opgaat voor dit soort testtrajecten.
De beste representatieve test is in productie
De beste test is in productie, omdat je dan zeker weet dat wat je test representatief is voor de werkelijke situatie. Als ik het heb over grotere infrastructuur veranderingen is de keuze: beperkte test, waar de testresultaten feitelijk weinig zeggen over de échte situatie, niet testen en laat de risico’s maar aan de projectmanager over of dus toch in productie testen.
Voor alle testtrajecten geldt zeer waarschijnlijk hetzelfde: in de toekomst (nu al in vele gevallen) gaat de huidige testomgeving niet meer voldoende zijn en zullen we aan de slag moeten met andere oplossingen om de kwaliteit op een goede en representatieve manier te meten. Projectmanagers gaan ons wel vreemd aankijken als we steeds vaker gaan zeggen: “Maar dat kunnen we niet testen.” Voor dit soort uitspraken waren we niet ingehuurd en beperkt de toegevoegde waarde van testen.
Hoe we dat gaan doen is nog de vraag en moeten we nog maar eens goed over nadenken met zijn allen.
No comments:
Post a Comment