Testomgevingen beheer

Transcriptie

1 Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden weg te nemen of om risico s goed in te schatten. Bij al deze zaken bevinden de te testen systemen zich in omgeving van vele andere systemen. De waardevolle informatie ontstaat als deze gehele omgeving in lijn is met de uiteindelijke situatie waar u met uw klanten of interne eindgebruikers zaken doet. Door Derk Masselink Walk to Quality 11-juni

2 Inhoud 1. Inleiding Belanghebbenden en doel testomgeving Opzetten en beheer van de testomgeving Initieel opzetten van de testomgeving Beheer Toewijzen van de testomgevingen Betrokken partijen Reserveringssysteem Release planning Configuratiemanagement van de testomgevingen Software en data Hardware Systeemdekking Probleemoplossen Sanety-check en probleemlokalisatie Resources

3 1. Inleiding Een wedstrijd win je tijdens de training. Dat zei mijn roeicoach vroeger. Je kracht, conditie en techniek bouw je op tijdens de training en ook je mentaliteit. Om een goed aantal samenwerkende systemen neer te zetten moet je die in samenhang ontwikkelen en testen. Het is van belang dat je de toekomstige productiesituatie nabootst. In dit artikel ga ik in op hoe je end to end testomgevingen kunt opzetten en beheren op een manier waar alle belanghebbenden wel bij varen. We hebben het dan met name over de afdeling software ontwikkeling, infrastructuur en test en de business in geval die acceptatietesten uitvoert. U kunt uw bedrijf veel plezier doen met beschikbaar maken van stabiele testomgevingen. Het grote voordeel is dat u een vertragingsfactor wegneemt en daarmee uw collega s de mogelijkheid geeft om zich te concentreren op het maken van winstgevende producten in plaats van op rennen achter problemen die ze maar zeer beperkt zelf in de hand hebben. Die heeft u immers in de hand omdat ze niet specifiek aan een afdeling zijn toe te kennen maar zich juist bewegen tussen de afdelingen of tussen projecten. 2. Belanghebbenden en doel testomgeving De reden voor een organisatie om testomgevingen op te zetten is dat ze de wijzigingen in hun systemen en organisatie willen kunnen beoordelen voordat deze worden aangeboden voor gebruik. Denk hierbij aan in productie gaan of gebruik door een ander team op een andere testomgeving. Redenen hiervoor zijn: Mogelijkheid om verbeteringen door te voeren Input krijgen om te beslissen over het in productie gaan of andere kwaliteit gerelateerde beslissingen Voorbereiden op productie fase door problemen te verzamelen en opleiding te verzorgen Projecten of organisatieonderdelen die wijzigingsverzoeken laten uitvoeren of teams die verantwoordelijk zijn voor de nieuwe software hebben belang bij een stabiele en representatieve testomgeving. Het is ook mogelijk dat bv. een eindgebruikersafdeling als belanghebbende optreedt maar meestal zal dat onder de verantwoordelijkheid van een project plaatsvinden. 3. Opzetten en beheer van de testomgeving Hoe kunt u een testomgeving opzetten en beheren? Dit is een project op zich. Maak onderscheid tussen het initieel opzetten van een testomgeving en het beheren. Bij initieel opzetten draait het vooral om infrastructuur, oplevermethodiek en wijze van installeren. Bij het beheer draait het vooral om de versies van de software en om wie de omgeving waarvoor mag gebruiken Initieel opzetten van de testomgeving Het initieel opzetten van een testomgeving over verschillende systemen is een grote klus. Om dit succesvol te doen is het aan te raden om van te voren een zo volledig mogelijk overzicht te maken van de systemen en hun onderlinge samenhang en om regelmatig contact te onderhouden met de 3

4 verantwoordelijke voor infrastructuur. Breng vervolgens globaal in kaart welke infrastructuur hiervoor nodig is. Plan in welke volgorde de verschillende onderdelen van de testomgeving zullen worden geïmplementeerd en voer dit stap voor stap uit. Zorg dat er steeds een duidelijke stabiele situatie is voor je met de volgende stap begint. Als men performance testen wil doen op de testomgeving dan is het van belang dat de omgeving qua performance representatief is voor de productieomgeving Beheer Beheerder testomgevingen Maak een centrale persoon of afdeling verantwoordelijk voor het beheer van de testomgevingen en zorg dat deze afdeling geen testverantwoordelijkheid heeft omdat die twee rollen moeilijk te combineren zijn. Zie Figuur 1 voor een overzicht van processen voor het beheer van de testomgevingen. Wijzigingen Spreek af wie er opleveringen mag doen naar welke omgeving. En spreek af hoe die gecommuniceerd worden. Tijdens de beheerfase zullen er ook nieuwe systemen gemaakt worden of zullen bestaande systemen toegevoegd worden aan de testomgeving. Bespreek dit tijdig met de verantwoordelijke Infrastructuurafdeling en bekijk wat er precies nodig is. Gebruik Zorg voor de juiste accounts voor de verschillende gebruikers van de testomgevingen. Daarnaast kan het nuttig zijn tools beschikbaar te stellen of te laten maken om veelvoorkomende zaken snel te kunnen uitvoeren. Configuratie en status De beheerder van de testomgevingen communiceert alle wijzigingen en problemen op de testomgevingen naar de belanghebbenden. Hij houdt ook een overzicht bij van de volledige configuratie dat alle versies van de systemen bevat inclusief versies van stuurgegevens en content. De beheerder houdt ook bij op welke machines alles draait en hoe die bereikbaar zijn. Zie ook het hoofdstuk Configuratiemanagement van de testomgevingen. 4

5 Figuur 1. Testomgevingsbeheer 4. Toewijzen van de testomgevingen 4.1. Betrokken partijen De beheerder van de testomgevingen brengt in kaart welke partijen willen testen en wat hun eisen zijn aan de testomgeving. Deze kunnen per partij verschillen. Voor sommige testomgevingen is het makkelijk aan te geven wie hem waarvoor mag gebruiken. Bijvoorbeeld een ontwikkelomgeving wordt door een ontwikkelaar of een team gebruikt en ze mogen daarop testen wat ze maar willen (eventueel met beperkingen ten aanzien van vertrouwelijke data). 5

6 4.2. Reserveringssysteem Vaak zijn er meerdere betrokken partijen die een verzoek indienen voor een testomgeving. Het is meestal kostbaar om voor elke partij een aparte omgeving op te zetten. Om toch aan iedereen tegemoet te komen kun je een reserveringssysteem op zetten. Breng bij elke reservering in kaart wat de eisen en wensen zijn aan de testomgeving. Denk hierbij aan: Welke systemen worden gebruikt Welke versies van deze systemen zijn nodig Welke systemen worden getest en welke versies Welke testdata is nodig Wat zijn de afhankelijkheden tussen releases In welke periode heeft men de testomgeving nodig U krijgt nu een overzicht van welk deel van een omgeving gebruikt wordt. Probeer op grond hiervan te kijken of je meerdere teams op een omgeving kunt toelaten of dat ze elkaar in de weg zitten. Ga er hierbij vanuit dat systemen die getest worden over het algemeen niet stabiel genoeg zijn voor een ander team dat deze systemen slechts gebruikt als schil om het systeem dat zij testen. Maak een overzicht van alle reserveringen dat voor iedereen toegankelijk is bv. via intranet of verspreid het wekelijks via de mail Release planning Houd met het toewijzen van omgevingen rekening met de volgorde waarmee releases naar productie gaan en met de afhankelijkheden tussen releases. In het algemeen probeer je de situatie op de testomgeving zoveel mogelijk te laten lijken op de situatie waarin de release op productie zal gaan draaien. 5. Configuratiemanagement van de testomgevingen 5.1. Software en data Als men kwaliteitsmetingen wil doen en op grond daarvan verbeteringen doorvoeren of problemen oplossen dan is het van groot belang dat duidelijk is waarover het men het heeft. Daarom houd u van alle systemen de versies bij en zorgt u dat u ook versies heeft van de content of een duidelijk inzicht in de content. Denk bij content bijvoorbeeld aan stuurgegevens, productdata of teksten op de website. Houd een overzicht bij van alle systemen op de testomgeving met daarbij vermeld het versienummer. Geef ook aan welke data op de testomgeving staat. In geval van productiedata kun je de datum aangeven waarop de data zijn gekopieerd (eventueel geanonimiseerd) van productie. Houd ook een overzicht bij van versiewijzigingen in de omgeving zodat je bv. problemen kunt matchen met wijzigingen op een bepaalde datum of tijdstip. 6

7 5.2. Hardware Daarnaast maak je een overzicht van toegangsgegevens van de verschillende systemen op de omgevingen. Dit is van belang omdat het per omgeving verschilt en teams eenvoudig moeten kunnen switchen van omgeving vanwege het reserveringssysteem. Denk hierbij aan: URL s en ip-adressen Accountgegevens (zowel gebruikers accounts als bv. accounts om logging of databases te bekijken Systeemdekking In de systeemdekking geef je aan welke systemen er beschikbaar zijn in elke testomgeving. Dit kan variëren van één systeem tot een volledige end to end omgeving. 6. Probleemoplossen Op de testomgevingen zullen ongetwijfeld problemen ontstaan. Dit kunnen problemen zijn in de software van een bepaalde versie die op de testomgeving staat of in de testomgeving als zodanig. Het is vaak moeilijk te achterhalen waar een probleem precies door ontstaat en daarom valt hier ook veel winst te behalen. Problemen die zich voor kunnen doen zijn onder anderen: Fout in de opgeleverde software Systeem dat down is Toegankelijkheidsproblemen zoals verkeerd ingestelde firewall Ontbrekende content (bv. nieuw product) Gebrekkige capaciteit van netwerk of te weinig schijfruimte (bv. vollopende logging) Versie-mismatch tussen verschillende releases In alle gevallen is het van belang: Informeer belanghebbenden welk probleem er is Lokaliseer het probleem Zet mensen aan het werk om te een oplossing te komen In geval van een fout in de opgeleverde software is het wellicht niet nodig het probleem op te lossen omdat dit dient te gebeuren in het reguliere proces waar een ander team al voor verantwoordelijk is. Bij het gezamenlijk gebruik van de testomgeving door verschillende teams kan het echter toch nodig zijn dat de beheerder van de testomgeving actie onderneemt en bv. een andere versie van de software laat installeren Sanety-check en probleemlokalisatie Elk probleem kan ervoor zorgen dat bepaalde teams de testomgeving niet nuttig kunnen gebruiken. Als dit lang duurt leidt het tot vertragingen bij de verschillende projecten. Daarom is het van de belang problemen te voorkomen en de duur van probleemsituaties te beperken. Dit kan als volgt: Sanety check Voer bij elke oplevering een sanety check uit op de testomgeving. Is de omgeving aangetast door de oplevering doe dan een roll back naar de vorige versie. 7

8 Probleemlokalisatie Wanneer zich een probleem voordoet probeer dan zo precies mogelijk te bepalen waardoor het komt. Dit is ook een kwestie van ervaring. Zowel voor de sanety check als voor probleemlokalisatie is het handig om geautomatiseerde testscripts te maken die je regelmatig en snel kunt draaien. Als er ergens een situatie is dat testautomatisering zich terugverdient dan is het hier wel. Van belang is dat je de scripts steeds uitbreidt op grond van de problemen die je lokaliseert en laat oplossen. Elke keer als je een probleem gelokaliseerd hebt maak je een nieuw test case voor in je sanety check die specifiek dat probleem naar voren laat komen. Soms is dit erg lastig maar je zult zien dat de kennis die je hiermee opdoet van grote waarde is voor het bedrijf. Je kunt immers ook andere mensen wijzen op afhankelijkheden en zwakke punten Resources Bij het analyseren en oplossen van problemen heb je bijna altijd hulp nodig van anderen. Zorg dat anderen het nut inzien om deze problemen op te lossen en laat zien dat jij er alles aan doet om de omgevingen stabiel te houden. Afhankelijk van de organisatie waar je werkt is het handig je claim op mensen te formaliseren. 8