Onderzoek geautomatiseerd testen Portaal

Hoewel het begrip automatisch testen iets van de laatste tijd lijkt te zijn, kent testautomatisering al een lange historie. Al in de jaren zeventig – de tijd van de groene, fluorescerende schermen – werden testrobots ingezet om software te testen.

Vanaf het jaar 2000 nam testautomatisering een toevlucht: de komst van concepten zoals Service Oriented Architecture (SOA), Web 2.0 en later ook vooruitgang in beeldherkenning zorgden voor allerlei nieuwe vormen van testautomatisering. 

In de afgelopen jaren is het gemiddelde percentage van de testautomatisering gestegen van 28 procent naar 45 procent, volgens de “World Quality Report”. Het is duidelijk: in de wereld van softwaretesten is het begrip inmiddels niet meer weg te denken.

Met alle vooruitgang die is geboekt bij automatisch testen (inclusief alle kansen, risico’s en voorwaarden) heeft CEPO in samenwerking met Portaal een onderzoek gestart waarin we centraal hebben gesteld welke rol testautomatisering kan hebben in de testorganisatie. Daarnaast bleken de vragen rondom de impact op de kwaliteitsmeting en de rendabiliteit van automatisch testen ook interessant. Op basis van dit onderzoek is een pilot gestart, waarin we concreet willen gaan aantonen welke bijdrage testautomatisering kan leveren en wat de gevolgen zijn voor de bestaande testaanpak.

Het doel van de pilot is het beantwoorden van een aantal onderzoeksvragen, waarbij de primaire vraag is: “Hoe kunnen we testautomatisering toepassen in de Portaal testorganisatie? En welke impact heeft dit op de bestaande testaanpak en afgeleide resultaten”

Definities
De testwereld kent vele begrippen, waarvan de definities niet altijd eenduidig worden omschreven. Dit geldt ook voor een bepaalde mate in de testautomatisering. Daarnaast komt er veel technische terminologie kijken, vanwege het automatiseringsaspect. Met die redenen lichten we een aantal begrippen in dit hoofdstuk toe, zodat de interpretatie binnen dit onderzoek duidelijk blijft.

Testen
Het startpunt van onze begrippenlijst is de term “testen” zelf. TMAP definieert testen als:

“Testen is een proces van plannen, voorbereiden en meten, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen.”

Opvallend aan deze definitie is dat er zeer abstracte benadering van het meten van kwaliteit en verwachte resultaten wordt aangehouden. De aanpak van CEPO gaat een stap verder door af te vragen: “Werkt het? En kun je ermee werken?”

Hiermee wordt niet alleen bekeken of het systeem aan de verwachtingen voldoet, maar worden ook de verwachtingen getoetst aan de praktijk. Beide definities spelen een grote rol gedurende een testtraject en er zijn verschillende vormen om de daadwerkelijke metingen in de praktijk te brengen.

Handmatig of geautomatiseerd
Om vast te stellen of een systeem aan de verwachting voldoet, kun je verschillende wegen kiezen. In dit onderdeel maken we een onderscheid tussen twee vormen:

• Handmatige test: Een (menselijke) gebruiker test of (een gedeelte van) de applicatie voldoet aan de verwachting. Deze verwachting kan impliciet zijn; we spreken dan al gauw van een exploratieve test. In de expliciete vorm maakt de tester gebruik van testscripts en uitgeschreven instructies; we spreken dan van een gestructureerde test.
• Automatische test: Speciale software wordt geprogrammeerd met de (expliciete) verwachting, waarna deze in staat is een oordeel te vormen door automatisch handelingen uit te voeren.

Het spreekt voor zich dat beide vormen voor- en nadelen hebben. Denk bijvoorbeeld aan de volgende punten:

• Impliciet versus expliciet: is er nog geen duidelijke verwachting en geen goed uitgedacht testscript, dan kies je voor exploratief testen. Echter, hoe kan je hier testautomatisering voor inzetten?
• Complexiteit en opschaling: naarmate het op te leveren systeem complexer wordt, wordt de testorganisatie groter. Hoeveel testers vereist een handmatige test dan? Hoeveel testrondes gaan er volgen? En hoe vaak moeten zij hetzelfde testen?
• Testbaarheid: welke onderdelen gaan er getest worden? Moet hiervoor speciale hardware gebruikt worden? Kan een gebruiker een webservice testen? Kan een testautomaat de correcte lay-out van een brief controleren?

In de afgelopen jaren heeft testautomatisering een flinke verbetering ondergaan, waardoor vooral de beperkingen steeds kleiner zijn geworden. In het volgende onderdeel bespreken we kort de technieken die tegenwoordig toegepast kunnen worden in een testtraject.

Automatische testtechnieken
Binnen de testautomatisering zijn er verschillende technieken om tot een resultaat te komen. In Mike Cohn’s test automation pyramid vinden we drie vormen:

Deze vormen kunnen als volgt omschreven worden:

• Unit tests: de meest elementaire vorm van automatisch testen. Hier test men broncode met testcode. In deze testcode zitten zowel de handelingen die uitgevoerd moeten worden als de uitgeschreven verwachting. Omdat deze tests slechts kleine stukjes code testen, zijn er veel van nodig om een grote testdekking te behalen.
• Service / API layer tests: deze techniek is zeer populair als gevolg van de blijvende opkomst van API’s en webservices. De tests communiceren hier met de API op basis van de documentatie.
• User Interface tests: door middel van beeldherkenning en toetsenbord/ muis emulatie probeert deze vorm de mens zo goed mogelijk na te doen. Een grote testdekking wordt veel sneller behaalt, omdat een dergelijke test vanuit de broncode gezien veel instructies impliciet raakt. De testscripts liggen tevens dicht tegen die van een eindgebruiker aan.

Van deze vormen speelt de UI-test een centrale rol: deze zal gebruikt worden gedurende de pilot. Deze testvorm test een proces, waarbij het proces meerdere applicaties kan “raken”, zoals de onderstaande afbeelding eenvoudig weergeeft. Omdat deze variant zo veel gelijkenis vertoont met de handmatige gestructureerde test, is deze ook goed te vergelijken op basis van investering en resultaat.

In het volgende hoofdstuk zullen we de aanpak van de pilot gedetailleerd omschrijven. Hierin zal ook de gebruikte applicatie voor de UI-test verder omschreven worden en hoe de handmatige test hiermee vergeleken zal worden.

Aanpak
Om het omschreven doel te onderzoeken, zal CEPO samen met Portaal een aantal testtrajecten opzetten waar zowel handmatig als automatisch getest zal worden. Door de testscope gelijk te houden kunnen we een goede vergelijking maken tussen de twee disciplines. Bij alle trajecten bewaken we de tijdsinvestering, van zowel de voorbereiding, de uitvoering en de analyse.

Tevens zullen we verschillende betrokkenen uit de testorganisatie interviewen, om naast de cijfers ook een kwalitatief beeld te krijgen van het gebruik van testautomatisering.

Testscope
Beide trajecten zullen worden uitgevoerd op Dynamics Empire van CegekaDSA, welke is gebouwd op het Navision platform. Navision, of NAV, wordt door meer dan 100.000 bedrijven over de hele wereld gebruikt voor het beheren van boekhouding, financiën, toeleveringsketen en de bedrijfsvoering. 

Als deelgebied voor de test kiezen we het proces klantcontact. Het klantcontactcentrum is het aanspreekpunt voor de huurder en cruciaal binnen de dagelijkse processen van Portaal. Alle tijd die kan worden bespaard door processen van het KCC te automatiseren, des te meer tijd men steken in de operatie.

Binnen het proces klantcontact hebben we als steekproef drie subprocessen geselecteerd:

• Interactielogpost met taak
• Interactielogpost zonder taak
• Verwijderen medehuurder bij overlijden

Bij deze processen is een procesbeschrijving aangeleverd, zodat zowel een handmatig- als een automatisch testscript opgesteld kon worden.

Handmatige test
De handmatige gestructureerde test zal voorbereid en uitgevoerd worden op de gebruikelijke wijze van Portaal:

• De interne testcoördinator bereidt het traject voor, begeleid de uitvoering en bespreekt de resultaten.
• Het bestaande script zal geoptimaliseerd worden in samenwerking met een medewerker van het KCC
• Zowel het script als de testresultaten zullen vastgelegd worden in TestMonitor, de acceptatietest software die CEPO inzet bij (grote) acceptatietesttrajecten.

Naast deze gebruikelijke wijze leggen we vast hoeveel tijd iedere fase in beslag neemt, zodat we een complete benchmark kunnen maken.

Automatische test
Voor de automatische test hebben we voor Portaal een nieuwe aanpak gedefinieerd gebruikmakend van software op basis van GUI-testautomatisering (dus simulatie van muis- en toetsenbord vanuit gebruikersperspectief) zonder dat daar enige programmeerkennis voor nodig is. 

Resultaten
De resultaten worden weergegeven in handmatige test, de automatische test, een vergelijking en als laatste de resultaten van de interviews.

Handmatig testen
De test is doorlopen door de kennisexpert van Portaal op dit vakgebied.

1. Interactielogpost met taak: Het aanmaken van één interactielogpost kost 50 seconden. In totaal zijn er 18 taken die aangemaakt kunnen worden binnen het KCC. Bij een 100% testdekking zou dit 18*50 seconden(gemiddelde wisseltijd tussen nieuwe acties is 25 seconden) is (18*50)+(17*20)=900+475=1375 seconden(≈22 minuten). In een normale testronde wordt één variant getest, wat neerkomt op een testdekking van 1/18 = 6%.
2. Interactielogpost zonder taak: Het aanmaken van één interactielogpost zonder taak kost 50 seconden. In totaal zijn er 9 unieke combinaties mogelijk. Bij een 100% testdekking zou dit 9*50 seconden (gemiddelde wisseltijd tussen nieuwe acties is 15 seconden) is (9*50)+(8*15)=450+120=570 seconden (≈9,5 minuut). In een normale testronde wordt één variant getest, wat neerkomt op een testdekking van 1/9 = 11%.
3. Verwijderen medehuurder bij overlijden: Het verwijderen van een medehuurder bij overlijden kost 133 seconden. Bij dit testgeval kent de expertgebruiker de applicatie en de verschillende velden goed en weet precies hoe dit proces te doorlopen. De brief is inhoudelijk niet beoordeeld. (≈2,5 minuut)

In de onderstaande tabel is tijdsbesteding van de handmatige test opgenomen.

Automatisch testen
In deze paragraaf worden de resultaten van het geautomatiseerd testen beschreven.

1. Interactielogpost met taak: Het aanmaken van 18 logposten kostte 237 seconden (≈4 minuten). Per interactielogpost kost deze actie 13 seconden. Echter de testrobot heeft hierin een standaard testdekking van 100%, omdat elke mogelijke combinatie is uitgevoerd.
2. Interactielogpost zonder taak: De testrobot doorliep alle 9 unieke combinaties in 108 seconden (≈2 minuten). Dit betekent dat de testrobot 1 taak kan afronden in 12 seconden. Ook hier geldt een standaard testdekking van 100%.
3. Verwijderen medehuurder bij overlijden: De testrobot voldeed deze taak in 164 seconden (≈2,5 minuten). Echter kan de testrobot deze handeling meerdere keren op een dag uitvoeren met telkens een margeverschil van 3 seconden, waarbij elke handeling consequent herhaald kan worden. Bij handmatig testen wordt de foutkans alleen groter bij de wet van de grote getallen, omdat een mens deze consequent dezelfde handelingen niet met dezelfde concentratie kan uitvoeren.

In de onderstaande tabel is tijdsbesteding van de automatische test opgenomen.

De optimalisatie van de scripts in de voorbereidingsfase kan nogal verschillen op basis van de wijzigingen in de software of wijzigingen in het werkproces. In dit onderzoek heeft hebben we een gemiddelde tijdsduur gebruikt op basis van ervaringscijfers.

Vergelijking
In deze paragraaf worden de twee tabellen handmatig testen en automatisch testen geïntegreerd.

Terugverdienperiode bij gelijkblijvende scope:

• De voorbereidingstijd zal na 5 testronden zijn terugverdiend.
• De uitvoeringstijd zal over deze 5 testrondes een besparing opleveren van (22+9,5+2,5=34 minuten) * 5 testronden = 170 minuten

Interviews
Vanuit de betrokkenen kunnen de algemene positieve bevindingen worden benoemd:

• “Geautomatiseerd testen kan grote voordelen bieden qua tijdswinst;”
• “Mooi om te zien hoe snel de testrobot een 100% testdekking mogelijk maakt;”
• “De testrobot is snel in te richten en laat ook direct resultaat zien;”

Vanuit de betrokken kunnen de algemene aandachtsgebieden worden benoemd:

• “Hoeveel tijd kost het om alle kritische paden voor onze organisatie te testautomatiseren;”
• “Kan de testrobot wel alle kritische processen overnemen;”
• “In hoeverre kan de softwareleverancier garanderen dat schermen en procedures minimaal wijzigen;”

Conclusies

Bevindingen
Dit onderzoek had als doel om vast te stellen hoe we testautomatisering kunnen toepassen bij de implementatie en het beheer van ERP-software. Uit de resultaten blijkt het volgende:

• Met de opgegeven testscope en binnen onze steekproef hebben we bewezen dat het mogelijk is om een aantal kritieke processen automatisch te testen.
• Naast dat de mogelijkheid voor automatisch testen aanwezig is, hebben we tevens vastgesteld dat de testrobot in een aantal gevallen efficiënter ingezet kan worden.
• De testdekking bij een normale handmatige test is gemiddeld 10% voor onze scope; de testrobot heeft een testdekking van 100%.
• De testrobot heeft geen beperkingen over de frequentie dat scripts uitgevoerd worden. Bij handmatig testen is dat in de huidige situatie 8 maal per jaar.
• Terugverdienperiode voor met name de voorbereidingstijd is 5 testronden.
• Besparing qua minuten testuitvoering over deze 5 testronden is 170 minuten. Over 8 testronden wordt dat al 272 minuten.
• Vanuit de interviews geeft iedereen een positief beeld, waarbij:
  • De extra inspanningen op termijn terugverdiend worden door effiëntere tests. Wel staan de verantwoordelijken binnen Portaal op het standpunt dat extra inspanningen niet alleen bij de eindklanten moet liggen,  maar ook zeker bij de softwareleverancier.
  • De grote inspanning om goede geautomatiseerde testscripts te maken afgezet moet worden tegen de verwachte tijdswinst. Hergebruik en samenwerking van “gelijkgestemden” zou hier een oplossing kunnen bieden.

Aanbevelingen
Ondanks het feit dat deze pilot over een beperkte scope is ingericht, kan geautomatiseerd testen voor een organisatie als Portaal een toegevoegde waarde bieden. Wel zijn de volgende aanbevelingen belangrijk om mee te nemen in de overweging:

• Maak een risicoanalyse over die processen die met deze berekeningen ook daadwerkelijk het verschil gaan maken.
• Begin klein, experimenteer en schaal dan op. Elk proces wat geautomatiseerd is, is er één.
• Betrek, naast de testcoördinator, één of twee expert gebruikers die (mee)bouwen aan de testscripts. Eén is geen en een gevaar voor de continuïteit.
• Continue communicatie over de verwachtingen en het doel van automatisch testen: het reduceren van handmatig testen en niet elimineren van handmatig testen.
• Zoek samenwerking met “gelijkgestemden” om het hergebruik en optimalisatie van geautomatiseerde testscripts te stimuleren.

Artikel is geschreven door René Ceelen (rceelen@cepo.nl) en Thijs Kok in samenwerking Michel van Nieuwstadt (CEPO), Hennie Hoogendoorn (Portaal) en Marcel Fischer (Portaal).

Bron: CEPO | Foto: Portaal