De roep om testautomatisering wordt groter nu releases van software elkaar steeds sneller opvolgen, time en quality to market van steeds groter belang zijn en de kosten van (her)testen oplopen. Hoe kan het dan zo zijn dat er ondanks de vele voordelen, maar weinig aan geautomatiseerd testen wordt gedaan en dan in het bijzonder aan het geautomatiseerd uitvoeren van testen?
Het is echt niet moeilijk om op een generieke manier testautomatisering in te richten voor het geautomatiseerd uitvoeren van testen. Organisaties hoeven daarbij geen grote investeringen te doen. Omdat geautomatiseerde testuitvoer zorgt voor consequente testuitvoering en een betere benutting van tijd, zullen de uiteindelijke testresultaten, in tegenstelling tot handmatig uitgevoerde tests, van hogere kwaliteit zijn.
Voordelen
Bij geautomatiseerde testuitvoer wordt de menselijke factor geëlimineerd. Tijdens handmatige testuitvoer zal ondanks de inspanning van een tester niet elke actie hetzelfde uitgevoerd worden. Dit kan leiden tot fouten in de testuitvoering en zodoende de uitkomst van de test negatief beïnvloeden. Een kleine fout in de input kan grote gevolgen hebben in een complex testscenario.
Het beter benutten van tijd voor testers is misschien wel de belangrijkste reden voor geautomatiseerde testuitvoer. Invoer van de testscripts, uitvoer van de test en controle van de resultaten gaan geautomatiseerd vele malen sneller dan handmatig. Tijdens de geautomatiseerde testuitvoer kan de tester andere (test)werkzaamheden oppakken. Een ‘test robot' kan namelijk 24×7 testen. Hierdoor kan de doorlooptijd aanzienlijk verkort worden of kan er meer getest worden in dezelfde tijd. Zo wordt niet alleen de 'Time to Marke't verkort, maar ook de 'Quality to Market' verhoogd.
Valkuilen
Testautomatisering wordt na invoering vaak gezien als een zeer onderhoudsgevoelige, dure oplossing om ‘bugs' te vinden. Er zijn vijf valkuilen die leiden tot het falen van het inrichten van testautomatisering.
– Veel testautomatiseringstrajecten worden verkeerd opgezet. Bijvoorbeeld omdat organisaties op basis van een summiere (of helemaal geen) toolselectie een product kiezen. Veelal wordt gekozen voor een bekende tool of een tool van een leverancier die toch al aanwezig is binnen de organisatie. Men realiseert zich onvoldoende wat er allemaal bij komt kijken om testautomatisering goed in te richten.
– Bestaande testware (testscripts) worden vaak één op één overgezet naar geautomatiseerde scripts. Het lijkt alsof veel bereikt wordt omdat alle handmatige tests geautomatiseerd uitgevoerd worden. Helaas levert dit in de praktijk vaak een andere situatie op. Wijzigingen in de applicatie leveren meer dan eens veel onderhoud aan de geautomatiseerde scripts op, waardoor testautomatisering een dure, ineffectieve manier wordt die weinig tot geen voordelen biedt.
– Een veelvoorkomend misverstand is dat automatisch uitgevoerde tests van betere kwaliteit zouden zijn dan de handmatig uitgevoerde tests. Ook hier geldt dat de geautomatiseerde test zo goed is als de tester die hem heeft opgezet. Dat wil zeggen dat een test met een bepaalde dekkingsgraad niet ineens een hogere dekkingsgraad krijgt als deze geautomatiseerd wordt uitgevoerd. Of als de test slechts 50 procent van de requirements afdekt en dit percentage niet stijgt door de test te automatiseren. Natuurlijk, doordat de invloed van de menselijke factor is uitgeschakeld, is er bij herhaaldelijke uitvoeren minder kans op fouten bij de testuitvoer. Hierdoor wordt de kwaliteit van de test en de testresultaten doorgaans wel verhoogd.
– Testautomatisering zien veel organisaties als ‘iets voor erbij'. Naast een goed beleid om te testen, wordt er al gewerkt volgens een beproefde methodiek. De organisatie wil nu zonder enige voorkennis groeien richting testautomatisering. Na een ‘toolselectie' wordt er gekeken wie er op dat moment beschikbaar is en deze tester mag dan testautomatisering gaan opzetten en toepassen. Maar testautomatisering is niet iets om naast de reguliere werkzaamheden te doen. Het vraagt om een tester die affiniteit heeft met tools, een meer technische achtergrond heeft en de taal spreekt van de tester, maar ook die van de ontwikkelaar. Kortom, een tester die testautomatisering uitvoert moet een dedicated specialist zijn.
– Cruciaal voor succesvolle testautomatisering is een generiek framework. Zo ingericht dat het onderhoudbaar en schaalbaar is. Belangrijke aspecten hierbij zijn het loskoppelen van testscripts en testdata en het opzetten van herbruikbare modules en functies. Als dit ontbreekt, kost het onderhouden van bestaande testscripts en het opstellen van nieuwe testscripts steeds meer tijd.
Gestructureerde testautomatisering
Het opzetten van een gestructureerde en generieke aanpak voor testautomatisering vergt de nodige inspanning aan zowel de kant van de testanalyse (het opstellen van testscripts), als aan de engineeringkant (het omzetten naar geautomatiseerde testscripts). Voor een goede afstemming tussen testanalist en testengineer is een eenduidige, generieke manier van het vastleggen van de testanalyse nodig.
De testanalist legt in een testscript de paden vast die binnen een applicatie worden doorlopen (flow). Een pad heeft een aantal stappen en elke stap bestaat uit een scherm waarop velden worden gevuld, controles worden gedaan en acties worden uitgevoerd. Door deze paden verticaal op te stellen in Excel wordt een leesbaar en overzichtelijk testscript gecreëerd.
Bij testautomatisering worden vaak ‘low-level' acties gebruikt, zoals ‘druk een knop in' en ‘vul een veld'. Daarnaast zijn er samengestelde acties als ‘voer op contact' en ‘vul scherm adresgegevens', de zogenaamde ‘high-level' functies. Deze acties en functies dienen generiek gemaakt te worden binnen het automatiseringsframework. De grote uitdaging zit in een tweetal aspecten. Hoe wordt het testscript uit de analyse dusdanig omgezet dat de standaard functies en acties aangeroepen kunnen worden? Hoe ontstaat de koppeling tussen de technische naam van objecten op het scherm van de applicatie, bijvoorbeeld ‘edit_naam_1' en de naamgeving van de objecten die de tester in het testscript gebruikt, bijvoorbeeld ‘voornaam'?
Om dit te bereiken zal de input voor de automatiseringstool zo generiek mogelijk moeten zijn. Dit wordt bereikt doordat de output van het testscript generiek is. Standaard wordt het testscript zo opgezet dat deze elke keer dezelfde functies en acties uitvoert, maar met verschillende parameters, variabelen en argumenten.
Abc’tje
Wanneer een automatiseringsframework voldoet aan de genoemde eisen, is een eenvoudige en succesvolle testautomatisering mogelijk binnen nagenoeg elk project.
Het benutten van de voordelen van geautomatiseerde testuitvoer wordt, door het ontwijken van de valkuilen en het toepassen van een gestructureerde testautomatisering, een abc'tje.
Bernd Beersma en Simon van Zessen, senior consultants non-functional testing Squerist
Let een beetje op wat u schrijft: testuitvoer is iets anders dan testuitvoering. Ter illustratie staan de relevante Engelse termen er hier achter:
Uitvoer = output
Uitvoering = execution
Voor applicatie testen gaat deze vlieger misschien wel op, maar bij het testen van complexe (en embedded) systemen wordt het verhaal van testautomatisering een heel stuk ingewikkelder.
Door een deel van de hardware te simuleren middels stubs (bijv. gaspedaal als input en toerental van de motor als output) kun je een deel automatiseren.
Echter, als het neerkomt op het echte systeemgedrag of real-time gedrag is het automatiseren geen ABC-tje meer
Daarnaast stelt het automatiseren van testen ook eisen aan de software, waar hier wel heel makkelijk aan voorbij gegaan wordt.
Is je software automatisch te installeren, is je software automatisch te configureren, accepteert je software commando’s van buitenaf, worden bij embedded componenten stubs meegeleverd, en wie zorgt ervoor dat deze stubs up to date blijven
En, kan/mag alles wel geautomatiseerd draaien. In de medische wereld bijvoorbeeld worden ze niet vrolijk als je geautomatiseerd met rontgenstraling gaat werken als er niemand in de buurt is.
Dito voor testen met motoren, hoogspanning etc.
@ir. K.E. van Zanten: goed punt, alleen wel jammer dat je je Nederlandse taalkennis wil demonstereren met een Engels voorbeeld!
Dit zijn allemaal goede punten, het zijn ook punten die al heel lang bekend zijn binnen de testautomatisering gemeenschap. Je zou zeggen dat we dan zo langzamerhand er iets aan kunnen doen?
Door de jaren heen zie je uiteindelijk pogingen meestal stranden op organisatie en techniek. Organisatie is niet alleen de specialist(en) die tijd en ruimte krijgt voor het realiseren en onderhouden van de passende oplossing maar ook het omgaan met budgetten zodat niet alle uren tbv generieke oplossingen (en de licentiekosten) op 1 project gaan drukken (waardoor ROI weer stukje uitdagender wordt per individueel project).
En mbt techniek: hoe vaak komt het niet voor dat er een nieuw objectje in de applicatie wordt geplakt “omdat het nieuw is” (met name bij webapplicaties) of omdat gebruik van een bestaand (en bekend) object meer moeite kost voor development. Geautomatiseerd testen vraagt meer aandacht voor het begrip testbaarheid. Vanaf het ontwerp zou je eigenlijk rekening moeten houden met de requirements van het gebruikte testtool. En als de gewenste wijziging betekend dat er wel getest kan worden met de nieuwste versie van het testtool die pas over 2 weken beschikbaar komt (en dan een week moet proefdraaien voor inzet) denk dan heel goed na of die wijziging perse in de huidige applicatie versie moet komen of dat er gewacht kan worden.
Een leuk artikel dat het testgebeuren weer eens goed onder de aandacht brengt.
Een interessant artikel, maar het artikel gaat wel erg kort door de bocht. In de praktijk is geautomatiseerd testen vaak geen ABC-tje!
Naar mijn mening is de ROI (tijd/geld) op geautomatiseerd testen grotendeels afhankelijk en bepalend op basis van het type organisatie. In een organisatie met een dynamische beheeromgeving is het testobject een bewegend doel. Dit zorgt voor een grotere belasting van het component onderhoudbaarheid. In de praktijk wordt hier te weinig rekening mee gehouden, wat zich uitbetaald in (nog) hogere kosten achteraf. Bezint eer gij begint is hierin een wijze les.
Een belangrijke valkuil uit mijn eigen ervaring, die ik niet in het artikel zie terugkomen, is de rol en het kennisniveau van de specialist. Een specialist van de testtool is nog geen specialist van het testobject en vice versa. Gedegen kennis van het testobject is net zo belangrijk (misschien wel belangrijker) als de juiste hoeveelheid kennis van de testtool. Een niet onnoemenswaardige valkuil naar mijn mening. Vaak wordt veel tijd verloren met het ‘bekend’ raken met de testtool of het te testen object. Een te rooskleurige inschatting van het automatiseren van de testware wordt vaak door de realiteit ingehaald, en blijkt het achteraf toch even wat moeilijker te zijn dan vooraf wordt gedacht.
Ik vind het een mooi artikel. Maar in de praktijk zie ik dat niemand het ervaart en uitvoert als een ‘abc-tje’. Waarom? Omdat heel vaak nonchalant wordt gedaan over de zogeheten testvolwassenheid van een organisatie. Vanuit stilstand beginnen met automated testing en chique gangster tools gebruiken, maakt het natuurlijk GEEN succes. Ik denk dat veel organisaties gewoon vergeten om eerst te kruipen en dan pas te gaan lopen. Maar nogmaals, ik ben blij met het artikel. Het bevat positieve berichtgeving, simpele zaken en als hoofdonderwerp: testen. Prachtig.
Ik sluit me volledig aan bij Michael Nazaar. Hij slaat de spijker op de kop!
Het is opvallend hoe de auteurs ondanks de vele rake opmerkingen in hun boeiende betoog niet weten door te dringen tot de meest actuele ontwikkelingen op het gebied van testautomatisering en zodoende de titel van hun artikel niet weten waar te maken.
In de eerste plaats is de scheiding die gemaakt wordt tussen testanalisten die handmatige testscripts opstellen en testengineers die deze testscripts automatiseren al vele jaren achterhaald. In ieder geval binnen meer volwassen testafdelingen hebben testengineers een generiek testframework ingericht waarbinnen testanalisten (of liever: functioneel testers) direct hun geautomatiseerd uitvoerbare testscripts kunnen opstellen. Hiermee is de afstemming die nodig is tussen functioneel testers en testengineers van een heel andere aard dan de auteurs in hun artikel schetsen: testengineers verdoen hun tijd niet met het automatiseren van handmatige testscripts maar besteden hun tijd ten volle aan het ontwikkelen en uitbouwen van tools en testscriptconstructies die functioneel testers in staat stellen hun geautomatiseerd uitvoerbare testscripts op steeds hoger abstractienivo te kunnen vastleggen.
Waar de auteurs zeer terecht een pleidooi voeren voor een zo generiek mogelijk framework met ontkoppeling van testscript en testdata, daar is het in de tweede plaats opvallend dat na de ‘low-level’ acties en ‘high-level’ functies niet de stap wordt gezet naar het gebruik van testscript-templates (of test design patterns) die bij uitstek ‘generics’ worden genoemd. Juist met templates kunnen testscripts op zeer hoog abstractienivo worden vormgegeven, waar dit met acties en functie’s nog onvoldoende mogelijk is.
Zijn templates als ‘very-high-level acties’ nu zomaar een volgende stap in de ontwikkeling van actiewoorden binnen testtools die loopt van:
* low-level technische actiewoorden (zoals laad backup, draai proces, start transactiemenu) via
* intermediate-level schermactiewoorden (waarbij alle velden van een scherm worden gevuld) naar
* high-level functionele actiewoorden (die alle schermen van een transactie of applicatie vullen en daarmee dus de complete flow in de user-interface afhandelen)?
Een template is een functioneel samenhangend stuk testscript, bestaande uit technische en functionele actiewoorden (en met mate ook schermactiewoorden), die voorzien wordt van een label en een willekeurig aantal variabelen en geplaatst wordt op een afzonderlijk tabblad of in een afzonderlijke bibliotheek; tijdens het genereren van een testscript kan zo’n template aan de hand van het label worden ingevoegd waarbij de variabelen in de template zijn vervangen door (verwijzingen naar) concrete testgegevens, zoals de opeenvolgende draai- en mutatiedatums, de verschillende attributen van testgevallen (bijvoorbeeld NAW-gegevens, etc) en platformafhankelijke zaken. Templates worden dus gebruikt voor het beschrijven van een testscript op hoog abstractienivo (Logisch Testscript); uit dit testscript kan vervolgens een fysiek, uit actiewoorden bestaand testscript worden gegenereerd op zo’n wijze dat op ieder punt in het logisch testscript vanuit een helicopterview direct kan worden ingezoomd op het onderliggende fysieke testscript.
Net als schermactiewoorden en functionele actiewoorden worden templates gemaakt en onderhouden door testers en niet door testengineers. Met name wanneer ervaren testers een uitgebreide integratietest met templates opzetten kan deze test voor een forse tijdwinst zorgen bij het snel opzetten van afzonderlijke unittesten (die op hun beurt overigens weer interessante templates voor de integratietest kunnen opleveren). Maar zo’n integratietest kan ook tijdwinst opleveren bij het inwerken van nieuwe testers die nu eindelijk eens duidelijk en in één oogopslag kunnen zien wat er moet gebeuren om bepaalde situaties binnen een applicatie voor elkaar te krijgen.
Nou, dit artikel gaat wel heeeel kort door de bocht.
Het staat of valt met de volwassenheid van de ontwikkelorganisatie. Die moeten de randvoorwaarden invullen.
Ik zie kreten als ‘ROI’. Kan je alleen berekenen als je voldoende metrics hebt. En dan moet je organisatie toch al een redelijk volwassenheidsniveau hebben.
Daarnaast zal het testteam zeker betrokken moeten worden tijdens de start van bouw of herbouw. Mijn ervaring is dat wanneer je geautomatiseerd test, je tenminste requirements aan wilt kunnen leveren.
Pas daarna kan je gaan denken aan concrete invulling, toolselectie enzovoorts.