Whitepaper Test Management Business case voor geautomatiseerd testen Waarom we informatiesystemen testen behoeft geen uitleg: Testen is nodig om inzicht te geven in de kwaliteit. Het voorkomen van risico s op fouten in een systeem, preventie dus, stelt heel wat eisen aan kwaliteitsborging. In de IT sector gaat het hierbij om het gehele software ontwikkelproces: het monitoren en verbeteren van dit proces, ervoor zorgen dat alle overeengekomen normen en procedures worden gevolgd en, last but not least, ervoor zorgen dat problemen worden gevonden en behandeld. Veel bedrijven weten dat het testen inmiddels een noodzaak is geworden, maar vragen zich nog af hoe men dit nu het best kan opzetten. Deze whitepaper probeert handvaten aan te reiken om te kunnen bepalen wat er binnen de organisatie nodig is en hoe dit efficiënt kan worden ingericht. Immers, niet ieder bedrijf is gebaat bij een aparte testafdeling, het gaat om het bereiken van een balans tussen baten en lasten. Deze whitepaper gaat hier dieper op in. Aannames Laten we eerst beginnen met te bepalen wat we verstaan onder software kwaliteit: Het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. De software moet dus voorzien in verwachtingen van verschillende gebruikers. Software testen is vervolgens weer gericht op risico beperking en het genereren van vertrouwen in het systeem. Kortom, testen heeft betrekking op de werking van een applicatie onder gecontroleerde omstandigheden en grondige evaluatie van de resultaten na het testen. Organisaties verschillen sterk in de manieren waarop ze verantwoordelijkheden voor kwaliteitsborging en testen toewijzen. Meestal liggen beiden op één plek in de organisatie, maar testen kan ook worden ingericht als een specifieke unit. Ook is het bij veel organisaties gebruikelijk dat een mix van testers en ontwikkelaars nauw samenwerken in projectteams met projectmanagers die de algemene kwaliteitsborgingprocessen bewaken. Door zo veel verschillende onderlinge invloeden is er dus niet één manier op het organisatorisch vast te leggen. Het zal in het algemeen afhangen van wat het beste past bij de omvang en economische structuur van het bedrijf. Testen Uit de nieuwsberichten is het duidelijk dat er bij veel organisaties kwalitatief onvoldoende wordt getest. Als er dan al getest wordt, dan gebeurt dit meestal handmatig, op ad-hoc basis en vaak onvoldoende gedocumenteerd. De resultaten van het testen geven dan inhoudelijk geen informatie. Zonder goede documentatie is iedere test onbruikbaar en feitelijk weggegooid geld. Het gevolg hiervan is dat het in productie nemen van nieuwe software of het updaten van bestaande software in veel gevallen onverwachte en tegenvallende resultaten opleveren. Fouten die pas worden ontdekt terwijl de software al in gebruik is genomen, leveren een enorme kostenpost op. Het is tot 100x duurder om een fout in software te herstellen als het product al live is gegaan, vergeleken met een identificatie en herstel in de ontwerp- en test-fase. Risico s van fouten in productie moeten dus zo veel mogelijk worden voorkomen en daarom zal men tijdens het ontwikkelproces risico s, kwaliteit, geld en tijd tegen elkaar dienen af te wegen. Wat is software testen niet? Het is NIET: Vrijgeven of accepteren Een fase na ontwikkeling Implementatie Per definitie goedkoop, het kan wel.
Ondanks dat het wellicht niet bij iedereen direct in gedachten komt, zien we bij het testen ook een belangrijke taak weggelegd voor het beoordelen van de testdocumentatie. Hier kunnen ervaren test consultants hun toegevoegde waarde bieden door te bepalen of de te testen activiteiten wel voldoende specifiek en uitvoerbaar zijn gemaakt. Op basis van de uitgangspunten, die eerder zijn opgesteld, wordt dan bepaald of de testscripts wel voldoende diepgang hebben en of wel het juiste wordt getest. Een belangrijk verschil dat we opmerken bij organisaties die het testen al permanent in hun organisatie hebben geborgd, is dat zij het testen vooral zien als een uitdaging, als een middel om het systeem kwalitatief te verbeteren en niet als het klusje dat uitgevoerd moet worden omdat dat eenmaal zo is afgesproken. Testen hoort een continu proces te zijn, verankerd in de organisatie, kortom: er moet sprake zijn van een Testorganisatie. Gestructureerd Testen Alleen maar testen is binnen de Testorganisatie is echter niet voldoende; het testen dient gestructureerd te gebeuren. Willekeurig een steekproef uitvoeren in een programma is niet de manier. Een test kan veel beter opgezet worden door te kijken naar waar de meeste risico's gelopen worden en daarbij is een gedegen testmethodiek onontkoombaar. Verder moet testen op basis van economische en logische gronden te gebeuren, gedreven door het bedrijfsproces. Het test traject dient goed te worden voorbereid met daarbij een strakke planning, onafhankelijk of het nu in een project wordt uitgevoerd of als onderdeel van dagelijkse gang van zaken. Vervolgens moet de scope van het te testen object worden bepaald, naast de criteria om iets te accepteren of niet. Een hulpmiddel hierbij is een methodologie om gestructureerd te testen: bijvoorbeeld TMap Next of ISTQB. Ongestructureerd testen leidt dus tot verschillende nadelen waarvan één van de belangrijkste is dat het leidt tot onvoldoende inzicht in de kwaliteit van het systeem en er dus geen solide advies kan worden gegeven. Het kan tevens leiden tot onverwachte overschrijdingen in planningen en budgetten en vervelende negatieve publieke exposure. Gestructureerd testen daarentegen is inzetbaar in elke situatie, geeft inzicht in risico s ten aanzien van de kwaliteit, vindt fouten in een vroeg stadium, is beheersbaar en vaak zijn de testgevallen ook nog eens herbruikbaar. Om deze redenen wordt gestructureerd testen ook steeds belangrijker. Testen is dus veel meer dan alleen het uitvoeren van de test: twee belangrijke fasen voor het uitvoeren zijn het plannen en het voorbereiden. De uitvoering wordt doorgaans geschat op 40% van de totale inspanning, plannen en voorbereiden respectievelijk 20% en 40%. Verschillende manieren om te testen Er zijn verschillende manieren om te testen. De meest gangbare manier is om testgevallen handmatig of geautomatiseerd te ontwerpen zodat er expliciete informatie over het te testen onderdeel wordt verkregen. Vervolgens worden de verwachte resultaten vergeleken met de uitkomsten uit de tests. Een andere manier is door informatie te verzamelen zonder expliciete testgevallen. Hierbij kan men kijken naar gebruikersvriendelijkheid of performance zonder daadwerkelijk daar specifieke testgevallen voor te definiëren. Tot slot is er nog een vorm van testen waarbij er wordt gekeken naar documentatie, handleidingen, procedure beschrijvingen en dergelijke zonder de software daadwerkelijk te gebruiken. Het proces dat is gekoppeld aan het testen heet, logischerwijs, het testproces. De fasering van het testproces vertoont veel overeenkomsten met die van het ontwikkelproces. Het ontwikkelproces bestaat doorgaans uit de fasen: eisen en wensen (ook wel specificaties genoemd), functioneel ontwerp, technisch ontwerp en de bouw; het testproces kent in
omgekeerde volgorde de ontwikkeltest door de ontwikkelaar uit te voeren bij de bouw, de systeemtest, de geïntegreerde systeemtest test en uiteindelijk worden specificaties getest met de gebruikers acceptatie test. Voor zowel het ontwikkelproces als het testproces geldt dat iedere fase haar eigen publiek en doel kent. Om het testen goed uit te kunnen voeren moet worden bepaald wat getest wordt, waarmee, hoe en door wie. We richten onze focus hier nu op het hoe. Verificatie en validatie Bij verificatie controleren we of onderdelen conform bijbehorende specificaties reageert. Software testen is een type van verificatie, net als reviews, analyse, inspectie en walkthroughs. Bij validatie daarentegen hebben we het over het proces waarbij gecontroleerd wordt of dat wat is gespecificeerd ook dat is wat de gebruiker werkelijk wenst. Dus: Verificatie: voeren we de juiste activiteit uit? Validatie: voeren we de activiteit juist uit? Requirements Validatie en verificatie zijn zinloos als er geen specificatie is van de software. Deze specificatie kan bestaan uit: de eisen en wensen die beschrijven wat de software zou moeten doen; de specificaties met betrekking tot architectuur; de gedetailleerde ontwerp specificaties die beschrijven hoe ieder component van de software geïmplementeerd zou moeten worden. Specificaties worden doorgaans voor de aanschaf (denk daarbij aan de pakket selectie trajecten) of ontwikkeling van de software opgesteld. Natuurlijk wordt er nog steeds wel gekeken door organisatie naar wat de concurrenten of branchegenoten aan software aanschaffen, maar men mag toch minimaal wel verwachten dat de bedrijfsprocessen enigszins worden gemapt op de functionaliteiten van een pakket. Gedurende zowel de inrichting als bij de ontwikkeling van de software is er meestal voor het eerst sprake van het testen. Hier wordt immers werkelijk getracht de wensen van de gebruiker te realiseren. Zo kunnen we verschillende formele tests onderscheiden gedurende een implementatietraject, waarbij de gebruikers acceptatie test de meest bekende is. Een andere veelvoorkomende test is de regressietest, waarbij gedurende de implementatie en nadien in beheer bepaald kan worden of wijzigingen al dan geen slechte invloed hebben gehad op de kwaliteit. Voor veel bedrijven is het structureel opnieuw testen, van vaak ongewijzigde functionaliteit met deze regressietests een tijdrovend onderdeel. Het levert veel voordelen op als deze regressietests geautomatiseerd zouden kunnen worden. Geautomatiseerd testen Regressietests worden vooral uitgevoerd in de beheerfase, maar kunnen al worden opgestart in de bouwfase, dus ook tijdens de implementatiefase. Indien de testorganisatie een gestructureerde aanpak kent, dan kunnen al vroeg in het project de basisfunctionaliteiten worden vastgelegd middels geautomatiseerde testscripts. In de latere fasen kunnen de testers zo steeds meer hun focus leggen op het testen van nieuwe functionaliteiten. Zodra deze vastliggen kunnen ook deze scripts worden geautomatiseerd, waarmee een overgang naar de beheerfase (na de go live) wordt vergemakkelijkt. Ook indien er iteratief en incrementeel wordt ontwikkeld kunnen deze onderdelen direct worden getest met scripts, die zodoende worden opgebouwd tot een aangroeiende set van regressietests. Geautomatiseerd testen levert vele voordelen op. Het is een proces dat eenvoudig kan worden herhaald, met verschillende data bestanden als input. Het resultaat van de test wordt
vastgelegd in rapportage die precies aangeven wat er in de test wel en niet goed is verlopen. De tester hoeft dus alleen nog te focussen op wat er níet goed is verlopen. De doorlooptijd van een geautomatiseerde test is veel korter en vergt minder inspanning van testers. Dit betekent dat ook kleine releases of wijzigingen goed en diepgaand getest kunnen worden zonder veel extra inspanning. Het geeft de testers ook de mogelijkheid om juist te focussen op het testen van nieuwe functionaliteit waarbij de bestaande functionaliteit snel en met betrouwbare resultaten automatisch getest kan worden. De voordelen op een rijtje: Betrouwbaar: De testgevallen worden op dezelfde wijze uitgevoerd. Ze voorkomen menselijke invoerfouten. Herhaalbaar: de testgevallen kunnen meerdere malen achter elkaar worden uitgevoerd, waarbij de invoergegevens met een Excel of ander bestand uniek en dus traceerbaar gemaakt kunnen worden. Uitgebreid: Met geautomatiseerd testen kunnen veel functies in de software getest worden, in een zelfde tijdsbestek meer dan met handmatig testen. Denk hierbij aan het s nachts testen en synchroon testen van verschillende functies. Herbruikbaar: De testgevallen kunnen uitgevoerd worden in verschillende fasen van de ontwikkeling, maar ook bij het beheer, zoals met regressietests in het geval van upgrades en patches. Snel: Geautomatiseerde tools voeren de testgevallen sneller uit dan mensen, behoeven geen pauzes en kunnen ook buiten kantoortijden worden uitgevoerd. Time to market en Quality to market kunnen dus significant worden verbeterd met geautomatiseerd testen. Het is bij geautomatiseerd testen wel essentieel dat de fouten die geconstateerd worden geen fouten in de testscripts betreft. Het is daarom noodzakelijk dat de software die gebruikt makkelijk werkt met de te testen applicatie. Tevens is het voor geautomatiseerd testen belangrijk dat het schaalbaar en onderhoudbaar is. Oracle ApplicationTesting Suite Er zijn diverse tools op de markt die het hergebruik van componenten toestaan. Voor Oracle applicaties is de Oracle Application Testing Suite (ATS) ontwikkeld. ATS is een geïntegreerde verzameling van test tools, bestaande uit: Oracle Functional Testing (OFT) Oracle Load Testing (OLT) Oracle Test Manager (OTM). Functional testing Met Functional Testing is het mogelijk om scripts tijdens het testen van de bedrijfsprocessen op te nemen. Het genereert een bestand dat door de tester kan worden aangepast zodat hetzelfde proces kan worden hergebruikt. De testanalist kan met specifieke kennis het invoer databestand aanvullen en het script generiek maken voor hergebruik met verschillende parameters en variabelen. Enige kennis van de programmeertaal Java is dan wel een toegevoegde waarde. Load Testing Load testing is uitermate geschikt om de infrastructuur door te lichten, waarbij deze applicatie direct de knelpunten kan aangeven. Dit houdt wel in dat deze infrastructuur eerst in kaart gebracht moet worden binnen het Load Testing. Hiermee kunnen dan simulaties worden uitgevoerd met duizenden gebruikers, zonder dat deze daadwerkelijk hoeven te participeren.
Test Manager De Oracle Test Manager is het onderdeel van ATS waarmee de gebruiker inzage heeft in het test proces. Het is de tool waarmee scripts kunnen worden opgestart en worden ingepland, handmatig en geautomatiseerd en het geeft per script aan of het succesvol is afgerond of niet. De issues die worden gevonden tijdens het testen kunnen hierin worden opgenomen en opgevolgd. Indien de klant reeds een tool bezit om issues op te volgen, dan kan in veel gevallen de gegevens uit de Test Manager aan die tool worden gekoppeld. Oracle Test Manager biedt een centrale web console met drie geïntegreerde modules: De Requirements Module biedt de testers de mogelijkheid om de test requirements te documenteren voordat het test proces begint. Binnen de Test Module kan de tester gedetailleerde tests plannen, geautomatiseerde en handmatige testscripts opslaan, uitvoeren en het resultaat ervan opslaan. De Issues Module geeft testers en ontwikkelaars de mogelijkheid om gevonden issues te registreren en de oplossing er van op te volgen: het track & trace van eventuele issues die uit de testscripts komen. Geautomatiseerd testen van Oracle Applicaties Voor de meeste Oracle applicaties zal de voorkeur uitgaan naar een soort record and playback-achtige toepassing, die gebruikt maakt van de gebruikers interface, dus via de schermen die de gebruikers ook zullen moeten invullen. Ook de maatwerkschermen voor de Oracle applicaties die door de organisatie zelf zijn ontwikkeld en toegevoegd kunnen daarbij worden getest. Oracle ATS heeft een krachtige record and playback functionaliteit voor het Functional Testing deel. Een unieke toepassing is daarbij dat de scripts ook volledig werken als de gebruiker een eigen schermindeling hanteert. Het is een robuuste en flexibele tool waarvan de scripts eenvoudig herbruikbaar zijn. Geautomatiseerde scripts zullen, net als handmatige scripts, regelmatig moeten worden bijgewerkt zodra functionaliteit wijzigt in de applicatie, bijvoorbeeld door set- up wijzigingen. De tijd die hiermee gemoeid gaat mag niet meer zijn dan het voordeel dat de geautomatiseerde scripts opleveren. Het is daarom goed om scripts dermate gestructureerd op te knippen, dat aanpassingen in het proces eenvoudig zijn in te passen, met oog voor de som van de totale onderdelen van het bedrijfsproces. Op deze wijze worden de testscripts op een modulaire wijze opgebouwd. Dit vereist deskundigheid op het gebied van testen maar ook van softwareontwikkeling en van Oracle ATS. De consultants van Hollandium zijn TMAP en ATS gecertificeerd en staan de klanten bij in de initiële opzet, maar ook in het beheer en in de overdracht naar de klant-organisatie De business case voor geautomatiseerd testen Nu de risico s van niet of slecht testen bekend zijn en we op de hoogte zijn van de voordelen van geautomatiseerd testen, rest de bedrijfseconomische vraag voor het management: hoe ziet de business case er uit voor het gebruik van Oracle ATS voor onze organisatie, specifiek voor het testen van onze Oracle Applicaties. Wat levert het de organisatie op? De eerste stap in de business case is een assessment van de huidige situatie. Hier worden vooral de volgende onderwerpen besproken: wordt er reeds getest? wat is de huidige test dekking? wat zijn de test vereisten? wat zijn de risico s bij huidig manier van testen? hoe zijn de scripts en resultaten gedocumenteerd?
Dat niet alle scenario s direct in aanmerking komen voor automatiseren is evident. Het gaat in eerste instantie om de bedrijfskritische processen en de processen met een hoog afbreukrisico. Daarna kan stapsgewijs een steeds groter deel van de totaal aantal te testen scenario s verder worden geautomatiseerd. Met andere woorden: de organisatie moet bewust automatiseren. Vervolgens wordt bepaald wat er gemeten gaat worden: de dekkingsgraad, de tijd per test, het aantal tests per iteratie. Dit is een belangrijke stap in het kunnen meten van het succes van de automatisering. De laatste stap is het bepalen van de Return On Investment (ROI). We kunnen daarbij de toegevoegde waarde, de ROI, in twee splitsen: Meetbare ROI, gerelateerd aan tijd, kwaliteit en geld; Onmeetbare ROI, gerelateerd aan een verbeterde afstemming van de verschillende fasen waarin wordt ontwikkeld, getest en opgeleverd. De meetbare ROI kunnen we als volgt onderverdelen: Kortere doorlooptijd: het uitvoeren van een geautomatiseerd script gaat sneller dan handmatig uitvoeren. Ook zijn scripts te agenderen, zodat ook buiten kantooruren scripts kunnen worden uitgevoerd. Verbeterde testdekking: men kan eenvoudigweg meer testen in minder tijd. Verbeterde herhaalbaarheid van het testen: dit geldt zeker voor het gebruik van geautomatiseerde test scripts tijdens regressie tests, maar ook tijdens de bouwfase van het project kunnen scripts worden gedefinieerd die vaker en met andere testdata herhaald kunnen worden. Minder defects in de productie omgeving: deze is minder goed te meten dan de eerste drie, maar door het verbeteren van de test dekking en het vaker herhalen met meerdere verschillende gegevens in de datafiles, kunnen meer defects worden voorkomen in productie. Belangrijk bij het berekenen van de meetbare kant van de business case zijn natuurlijk de kosten die gemaakt worden voor de aanschaf en het beheer van licenties, tijd om de scripts te automatiseren en het beheer ervan. Tijd die besteed wordt aan het analyseren van de uitkomsten en ook eventuele hardware die aangeschaft dien te worden dienen in de vergelijking te worden meegenomen. De minder goed meetbare ROI op een rij: Kwaliteitsverbetering tijdens het ontwikkelen: tijdens het ontwikkelen van software kunnen geautomatiseerde scripts dienen als een functionele baseline. Wijzigingen op het ontwerp kunnen zo eenvoudig in later tijdstip worden doorgevoerd en kan worden getest wat de impact op het totale proces is. Vertrouwen in de test resultaten. Bij geautomatiseerd testen is er geen context, het is goed of fout. De foutscenario s moeten daarna worden verklaard door de testers. Klanttevredenheid: voor de IT-afdeling binnen organisaties is de klanttevredenheid een belangrijke doelstelling. Minder defects betekent doorgaans een hogere tevredenheid. Al met al is de business case voor geautomatiseerd testen een afweging tussen de genoemde voordelen en resultaten versus de kosten die gepaard gaan met het automatiseren. Een andere factor die mee kan spelen is de houding van de organisatie ten aanzien van automatiseren. De ene organisatie gaat daar verder in dan de ander. Bij organisaties die veel automatiseren heeft men doorgaans ook een ander profiel voor haar personeel dan bij organisaties die minder zwaar leunen op automatisering. Dit laatste is
redelijkerwijs te ondervangen door bijvoorbeeld het automatiseren en het testen van processen uit te besteden aan een derde partij. Is het interessant voor uw organisatie? Er is een mogelijkheid om voor uw eigen organisatie te bepalen wat voor u de toegevoegde waarde kan zijn. Gaat het bij u om geautomatiseerd testen te implementeren, of juist om gestructureerd testen in (delen van) de organisatie te verankeren? Hollandium biedt u tegen aantrekkelijke voorwaarden een workshop aan, waarbij u gezamenlijk met onze ervaren consultants uw eigen testorganisatie tegen het licht kunt houden. Neemt u hiervoor contact op met ons. Over de Auteur: Niels van Opzeeland is éen van de oprichters van Hollandium en heeft een jarenlange ervaring in het implementeren, testen en beheren van de Oracle applicaties. Niels is optimistisch over de mogelijkheden en voordelen van het (geautomatiseerd) testen voor de klant en heeft deze whitepaper mede vanuit dit oogpunt geschreven. Over Hollandium Testing your Business. Dat doet Hollandium graag. Van implementatie tot beheer is Hollandium uw partner, met name ook op het gebied van het testen van uw software. Veel bedrijven beseffen dat een project eerder en binnen budget kan worden afgerond als er deskundig is getest. Bij Hollandium blijkt deze deskundigheid uit het feit dat de test consultants zowel TMAP als ISTQB gecertificeerd zijn, ze een achtergrond hebben in structureel testen en ze een gedegen structurele test(organisatie) kunnen opzetten en beheren. Oplossingsgericht werkend is Hollandium voortdurend bezig met verbeteringen in haar diensten, zoals bijvoorbeeld het geautomatiseerd uitvoeren van testscripts. Als Oracle Gold partner is Hollandium bij uitstek uw partner voor alle testwerkzaam- heden rondom de Oracle applicaties. Maak kennis met ons via www.hollandium.nl of neem direct contact op met Niels: nvanopzeeland@hollandium.nl