Auteur: Rob van Steenbergen ● rob@chickenwings.nl ● @rvansteenbergen
Het is lastig en wellicht onmogelijk om in de toekomst te kijken. Maar door goed op te letten, artikelen en boeken over je vak te lezen, met andere testers te praten en ook lerend van eigen ervaringen kan je heel dicht bij komen. In dit artikel in het kort mijn resultaten van een onderzoek van de mogelijke toekomst van de testautomatisering.
De korte geschiedenis van automatisch testen
Een kort overzicht van de geschiedenis van automatisch testen ziet er in hoofdlijnen ongeveer zo uit:
- Compileren van software met automatische controles;
- Unittests, gebouwd door de ontwikkelaar;
- Robots: deze ondersteunden record & playback als belangrijkste functie;
- Data en keyword driven testing: Data in Excel sheets of een database sturen ‘robots’ aan;
- Model based testing: specificaties waarvan automatische testgevallen vanaf geleid kunnen worden;
- Open Source testtools: combineren van diverse software tools.
Geleerde lessen uit het verleden
- Automatisch testen = programmeren: testscripts die met Record & playback zijn gemaakt, zijn slecht onderhoudbaar. Het parametiriseren van scripts maakt het onderhoud beter, maar de tester moet niet gaan programmeren. Je hebt programmeerprincipes nodig, versiebeheer en source control, net zoals je ‘echte’ software ontwikkelt. De beste automatiseerder is een programmeur.
- Automatisch testen = onderschat: het creëren van volledige testautomatisering is een project op zich. Er is training nodig en begint met een bewustzijn traject van de organisatie. ‘Even snel’ automatiseren is niet mogelijk, ‘alles automatiseren’ eveneens.
- Automatisch testen = checken: niet alles kan van tevoren bedacht worden, software reageert vaak buiten te voorspellen paden en zorgt voor vreemde bugs. Automatisch testen gaat ervan uit dat je van tevoren een scenario of algoritme hebt die je afspeelt, dus je doet een check op basis van wat je al weet. Bij vreemde situaties ‘breekt een script’ al snel. Als je dit handmatig test, pas je je snel aan zodat je anders kan interacteren met de software. Ook zijn zaken als ‘imago van het bedrijf’, ‘claims van marketing’ en ‘usability’ lastig om te automatiseren.
De combinatie van tools
Alle tools die je gebruikt om je werk te doen als tester zijn in principe testtools. Voorbeelden van tools die ik zelf veel gebruik, zijn:
- Selenium IDE: opnemen en afspelen van weggooi scripts. Ik doe zelf niet al te veel aan onderhoud bij opgenomen scripts (tot nu toe dan) en deze scripts zijn voor mij tijdelijke scripts die ik niet lang ga gebruiken.
- Rapid Reporter: live een blog maken tijdens een Exploratory testen sessie.
- Perlclip: genereren van testdata
- WinParrot: een macro tool (opnemen, afspelen, beetje scripten). Handig bij niet browser gebaseerde software.
- Notepad++: te gebruiken om bijvoorbeeld XML en andere soorten scripts te bestuderen.
Op testcongressen hoor je steeds meer over combinaties van open source software, zoals bijvoorbeeld Selenium en Fitnesse. Een commerciële suite van testtools kan nog steeds een goede oplossing zijn om als basis te dienen in het automatisch testproces. Hierbij verwacht ik, of het nu een open source of een commerciële oplossing is, dat het aansluiten van software van derden steeds belangrijker wordt.
Eén tester op meerdere teamleden met meerdere disciplines
Een andere trend in de IT is het agile werken, waar het gehele team verantwoordelijk is voor de kwaliteit van het testen van een product. Ontwerpers, ontwikkelaars, de product owner, supportmedewerkers, eindgebruikers en meer. De verhouding van het aantal testers in relatie tot ontwikkelaars verandert ook. Waar we vroeger dachten dat in een team één tester op één ontwikkelaar moest zijn, is dit binnen de huidige agile trend eerder één op vier.
Het is voor iedereen van belang dat er goed getest wordt. Het liefst op alle niveaus, van unittesten tot aan de acceptatietest. En veel van deze testen kunnen geautomatiseerd worden. Alle disciplines moeten testen, maar hebben wel hulp nodig van de tester. De tester staat niet alleen in deze nieuwe IT wereld, alhoewel er nog steeds wat overwonnen moet worden moet ik eerlijk toegeven. Maar dit stuk gaat over de toekomst.
Iedereen zijn tool
Als de tester straks in een verhouding van één op vijftien staat, kan de tester niet meer zonder tools. Voor het geautomatiseerd testen zijn er diverse tools die deze moderne tester helpen. Ik heb er al een paar genoemd die ik zelf gebruik, maar ben er niet zo zeker van dat ik tools als Junit ga gebruiken. Dat zijn bijvoorbeeld tools voor ontwikkelaars. De gebruiker heeft misschien meer iets aan een soort van opname studio (video opnemen of een record & playback tool).
Het automatisch kunnen testen over het gehele testproces en wetend dat hier veel meer disciplines bij betrokken zijn, vereist dat iedereen zijn eigen testtool gebruikt.
Specifieke disciplines, specifieke test tools
Waar we heen moeten met automatisering is dat we alle verschillende tools die gebruikt worden voor het testen, moeten gaan ondersteunen vanuit de techniek. Tools die onafhankelijk van elkaar werken maar toch aan elkaar verbonden zijn, zodat het efficiënt delen van analytische informatie plaatsvindt. De tools moeten als plug-ins ‘ingeprikt’ worden in een centraal testautomatiseringsysteem (de motor). En de motor stuurt dan weer tools aan voor het uitvoeren van de testen.
De rol van de tester verandert
Waar zijn de mensen die dit gaan regelen? De meeste testers zijn niet echt goed in programmeren. Een integratie van componenten en het testen daarmee vereist test- en technische kennis. Wie gaat de plug-ins en nieuwe testtools maken en aansluiten op de onderliggende ‘motor’? Wie gaat voor aansturing vanuit de business zorgen en wie vanuit de techniek.
Een aantal Testnet-leden hebben een boek geschreven: ‘Bepaal je koers!’. Hierin schrijven de auteurs over de veranderingen in de wereld en de IT en de invloed op de rol van de tester. Ga je meer richting de business of meer richting de techniek? Onlangs op het congres ‘Test automation day’ in Rotterdam was er een keynote presentatie van Emily Bach waarin zij aangeeft dat de pure rol van de tester straks niet meer bestaat en dat je combinatierollen krijgt. Hierbij heb je de tester en ontwikkelaar en de tester gecombineerd met de business analist rol.
Dit wil zeggen dat de tester straks overal zit. Aan de business kant is dan de behoefte duidelijk van een goed geautomatiseerd systeem en aan de techniek hebben we testers die het kunnen bouwen.
Belangrijkste om mee te beginnen is de bewustwording aan de business kant en dat kan misschien het beste met testers die bij de business aangehaakt zijn. Dit voor de nodige ondersteuning en budget. Dat ziet er waarschijnlijk goed uit in onze nabije toekomst.
Hoe nabij die toekomst is dat is nog wel de vraag.
Referenties voor dit artikel kun je vinden op mijn blog pagina.
Prima artikel. De veranderingen die worden geschetst zie ik de eerste voortekenen al van. Nieuwe rol, nieuwe uitdagingen.
Beste Rob,
Het tweede deel van je stuk is iets wat ik al sinds 2010 loop te verkondigen, zie mijn artikel op de website van de computable: wie test een service oriented architecture en van recenter datum de rol van de tester verandert.
Dus ik kan je stuk alleen maar onderschrijven.
Groet
Tom
Rob,
duidelijk stuk,
ik ben van mening dat, als je bij wilt blijven met de snelheid van development, er vooraf duidelijk de keus voor automatisering van je testen gemaakt wordt.
Vrgr Henk
Van mij een aantal gedachten op een artikel dat een goede aanzet doet een idee over de toekomst te geven. Hopelijk doen meer mensen zoals ik een poging mee te denken.
Toen ik met testen begon was voor mijn gevoel een ratio van 1 tester op 4-5 ontwikkelaars goed te doen. Dat dat in de toekomst 1 op 15 wordt, gaat bijna naar mijn ideale plaatje van “Test by Exception”; dat betekent zoveel als dat het proces dermate goed is, dat het testen wat we nu doen eigenlijk overbodig is; alleen als er nog iets fout gaat, testen we weer even.
De historie van tools koppel ik aan CHUI, GUI, Internet, MBT, waarbij ik bij de laatste categorie het begrip Model zeer verschillend ingevuld zie worden en soms tot een niveau dat ik denk dat je QTP of Selenium aan het gebruiken bent.
Bij specifieke tools had ik iets over performance en security tools verwacht. Hiervoor zijn tools gewoon nodig. Anders geen test.
Iedereen zijn eigen tool: Unittesttools zijn inderdaad geen reden om te zeggen dat we dan voor de systeemtest geen tools meer nodig hebben. De integratie van units tot een werkend geheel zal getest blijven moeten worden.
Integratie met andere type tools is altijd een issue geweest. HP, IBM en in mindere mate Oracle hebben daarom een suite van tools gekocht. Open Source breekt deze gedachte weer af, door de veelheid aan tools. Zelf denk ik dat een goede mix van tools je ver kan brengen.
Dat de tester met tools meer technische kennis/affiniteit moet hebben, ben ik het helemaal mee eens.
Dat de gebruikers ook tools moeten gebruiken, kan ik me minder in vinden. Wel zou je kunnen zeggen dat regressie door gebruikers niet nodig is; maar ja de techniek is niet altijd voorspelbaar.
Rob,
ondanks dat ik het wel met je eens ben, valt het me wel op dat je met de genoemde tools niet echt kunt spreken van testautomatisering. Selenium IDE is een klik-klak recorder voor huis-tuin en keuken gebruik. Testautomatisering komt pas echt tot z’n recht met een object georiënteerde taal zoals C# of Java. Dit kan bv met Selenium Webdriver, Silktest of Microsoft CodedUI (om er maar een paar te noemen). Daarnaast ben ik het niet eens dat unittesting uitsluitend is voorbehouden aan ontwikkelaars. Denk aan de piramide van Mike Cohn; unittesten zijn het fundament van verdere testautomatisering. Webservices kunnen bv het beste worden getest via tools via het unittest framework (in bv Eclipse of Visual Studio). Veel krachtiger dan uitsluitend via SoapUI.