Deel 2 - Hoe 'praten' tools met de applicatie?

Vorige keer hebben we gezien waarom geautomatiseerd testen geen luxe meer is, maar bittere noodzaak. We hebben ook gezien dat het een software project erbij is, dat te vaak wordt onderschat. In deze aflevering gaan we iets meer de diepte in: HOE praten die tools nu precies met het te testen systeem?

Voordat we daar in duiken wil ik eerst even twee misverstanden uit de weg ruimen:

Misverstand één: Geautomatiseerd testen is het gebruik van tools.

Waarom is dit een misverstand?  Nou, vergelijk het met een bouwvakker. Die gebruikt een scala aan tools zoals een hamer, beitel, boormachine en betonmolen. Maar daarmee doet hij nog niet aan 'geautomatiseerd bouwen'. Ook testers gebruiken allerlei tools, bijvoorbeeld voor testdata generatie, link-checking, test management en bevindingenbeheer. Maar we spreken pas van geautomatiseerd testen als de tool min of meer zelfstandig en onbemand de interactie met de te testen applicatie van de mens overneemt. De test runners dus, de tools voor daadwerkelijke testuitvoering, dat is waar het nu over hebben.

Misverstand twee: we gaan het nu zeker over Cucumber, SpecFlow en Fitnesse hebben?

Het antwoord is nee, en ik zal uitleggen waarom. Deze drie tools zijn erg populair, en terecht. Je kunt met deze tools heel goed je requirements en ook je testen vastleggen in een soort gewone mensen taal: het GIVEN ... WHEN...THEN formaat, ook wel het Gherkin formaat genoemd, naar de uitvinder.

Deze tools zijn super populair voor het aansturen van geautomatiseerde testen, maar voeren niet zelf de testen uit. Daarvoor moet je er een tool zoals Junit of Selenium onder hangen, die daadwerkelijk met de applicatie praat. Wat je ook veel ziet is dat de bouwers die testuitvoering zelf programmeren. De standaard softwarebibliotheken die iedere developer tegenwoordig tot zijn beschikking heeft helpen daarbij.

OK, dat wilde ik eerst even kwijt. Nu terug naar de kern van deze aflevering:

Hoe 'praat' een test tool met de applicatie?

Test tools interacteren op een bepaalde manier met de te testen applicatie. Het is belangrijk om te weten hoe die tools dat doen - of hoe de tool van jouw keuze dat doet. Want elke techniek heeft zijn voor- en nadelen waar je in je verdere strategie rekening mee moet houden.

OK, daar gaan we, er zijn 4 manieren van praten met de applicatie onder test:

1.       Pixelherkenning

2.       Objectherkenning

3.       Interactie op berichtenverkeer niveau, via de API

4.       Interactie op het laagste (unit test) niveau

Als je nu denkt aan de zogenaamde test automation piramide dan heb je helemaal gelijk. Het klopt dat deze vier grofweg overeen komen met de niveau's in de T A P. Maar die komt in een latere aflevering nog uitvoeriger aan bod. Voor nu wil ik de vier technieken graag uitleggen, en dan zijn we door onze tijd heen. Hou je vast, we beginnen met manier 1:

1. Pixelherkenning

De meest primitieve vorm van herkenning en interactie is op pixel- en muispositie niveau op je scherm. Via de Grafische User Interface, de GUI dus. De tool geeft commando's als 'klik met de muis op die en die schermcoordinaten', 'voer die en die toetsaanslagen' in en 'druk op Enter'. De eerste generatie tools werkte op die manier, en leverde zeer kwetsbare scripts. Want je kunt je voorstellen: een iets andere plaats van een knop of een iets andere schermresolutie en de synchronisatie gaat mis en je script doet het niet meer. Al snel gingen daarom bijna alle tools over op herkennen van de 'objecten onder de motorkap'. Dat is methode 2 en die leg ik straks uit.

Er zijn inmiddels ook moderne tools die op pixel-niveau werken. Maar die doen dat op een slimmere manier, namelijk met letterherkenning (Optical Character Recognition: OCR) en patroonherkenning. De reden dat we die oude pixel-gebaseerde interactie - op een slimme manier - weer van stal hebben gehaald is als volgt: Omdat je alleen via de buitenste buitenkant praat, namelijk via de pixels op het scherm, zijn de scripts totaal onafhankelijk van de onderliggende technologie. Het werkt dus met alles wat een beeldscherm heeft, maakt niet uit wat er achter of er onder zit: browser, non-browser, Windows, Apple, mainframe green screen oostblok schermen wat mij betreft, het maakt allemaal niks uit.

Het nadeel van relatief onderhoudsgevoelige scripts is er nog steeds wel een beetje, maar deze tools kúnnen een uitkomst zijn bij E2E ketentesten in hybride omgevingen. En bij lastige technologie onder de motorkap, waar andere tools niet goed mee kunnen praten. Omdat je met de techniek niks te maken hebt kunnen ook niet-technici met dit soort tools een groot deel van het werk doen.

Voorbeelden van tools die deze technologie gebruiken zijn ICTestAutomation (gebaseerd op de CitraTest engine) en Eggplant, een echte rising star momenteel.

Goed, tot zover pixelherkenning. We gaan nu naar de tweede manier van praten met je te testen systeem:

2. Objectherkenning

De meeste moderne tools werken met deze techniek. Ze herkennen niet op pixelniveau en nemen geen muisbewegingen en muisklikken op. De herkenning en interactie vindt plaats net onder de motorkap, namelijk op GUI-objectniveau. Die objecten zijn knoppen, invoervelden, hyperlinks, radio buttons, menu's, etc. Als je via een browser werkt kun je met de rechtermuisknop van je browser die objecten zelf inspecteren.

Deze manier van interactie, objectherkenning dus, levert tamelijk robuuste en onderhoudbare scripts.

Want ga maar na: een ander kleurtje, een tekstuele aanpassing of een andere positie op het scherm beïnvloedt de herkenning niet want het blijft hetzelfde onderliggende object. Verandert een OK-knop of een invoerveld van vorm of plaats? Het script vindt 'm nog steeds, aan de hand van zijn unieke technische ID of andere stabiele kenmerken.

Maar let even op: wijzigingen van positie en op pixelniveau zijn hier geen probleem, maar wijzigingen onder de motorkap juist weer wel. In sommige ontwikkelomgevingen is het niet ongewoon dat onderliggende ID's niet stabiel zijn maar met een nieuwe build opnieuw gegenereerd worden. Als de scripts afhankelijk zijn van die ID's zullen ze daarna niet meer werken. Maak hier dus goede afspraken over met de ontwikkelaars. Dit is een van de voorbeelden van het belang van goede samenwerking in je team rondom geautomatiseerd testen.

Populaire tools die deze technologie hanteren zijn Micro Focus-UFT (voorheen HP-QTP), Tosca, TestComplete en Ranorex. Net als tools die met pixelherkenning werken zijn ook deze tools vaak relatief gebruiksvriendelijk en kunnen ze ook door niet die-hard technici worden ingezet.

Dat was objectherkenning, nu over naar de derde manier van interactie. Die zit een stukje dieper in de technology stack:

3. Services en berichten via de API

Deze tools slaan de GUI helemaal over en praten direct met de applicatie via berichten, vaak SOAP of REST berichten. Meestal gaat dat via een gestandaardiseerde interface die we de Application Program Interface noemen, oftewel de API. API berichtenverkeer wordt ingezet voor interne communicatie tussen verschillende onderdelen van een applicatie. Maar ook voor externe interactie in de vorm van services. Een voorbeeld van zo'n bericht is "doe mij de woonplaats die hoort bij deze postcode en dit huisnummer". Of "Doe mij de kredietwaardigheidsgegevens van deze persoon", of "stuur mij een Google maps fragment met markering van dit bedrijfsadres". Als dit soort services via het internet lopen noemen we het web services. Het communicatieprotocol voor (web) services is meestal het XML-gebaseerde SOAP protocol en in toenemende mate het eenvoudigere REST protocol dat zowel met XML als met andere datanotaties zoals het snellere Json kan werken.

De testtools die op die manier werken slaan de GUI helemaal over. Wijzigingen in de schermen maken niet uit en dat maakt de scripts robuuster en beter onderhoudbaar. Bovendien zijn ze sneller: dezelfde tests draaien op API niveau tot een factor 1000 of meer sneller dan via de GUI. Daarmee zeg ik overigens ook dat automatisering via de GUI wel sneller gaat dan met de hánd, maar voor grote testsets is het soms toch te langzaam om ze frequent te draaien. In dat geval is het een goed idee om te kijken hoe je buiten de GUI om op berichtenverkeer niveau kunt testen.

Voor niet-technici is het nadeel dat je de test niet meer via je vertrouwde GUI kunt zien afspelen op het scherm. Want het speelt zich allemaal onder de motorkap af. Techneuten kunnen het berichtenverkeer natuurlijk prima volgen in hun technische omgeving, maar het staat verder bij de echte User Experience vandaan.

Populaire tools zijn SOAP-UI, Postman, RestAssured, JMeter (performancetesten én API testen), en SOAtest van Parasoft.  

Tot zover geautomatiseerd testen via het berichtenverkeer. Tot slot kijken we naar de vierde manier van interactie:

4. Interactie op software unit niveau

Dit is het niveau van de slagers die eigen vlees keuren. Met die slagers bedoel ik de bouwers: de programmeurs, developers, of ontwikkelaars, of hoe je ze ook wilt noemen).  Zij doen de zogenaamde software unit testen, de testen op het laagste niveau, op het niveau van je softwarecode dus. Denk aan .NET C# of C++, Java, JavaScript, Perl en Python. Op dit unit-test niveau loopt de interactie tussen tool en applicatie niet via een zichtbare interface (GUI/browser) en meestal ook niet via standaard berichten, maar op een nog technischer software niveau. Daarvoor wordt meestal een framework opgezet om met de te testen unit te kunnen interacteren. Zo'n framework voorziet in een testrunner, faciliteert de data setup en regelt de opbouw en afbraak van alles wat je nodig hebt voor een unit test. Gedrag van nog niet beschikbare code kan worden gesimuleerd (gemock't zeggen insiders) en de respons van het testobject kan worden afgevangen en geverifieerd. Dit is allemaal noodzakelijk omdat software units 'kale' brokken code zijn, zonder GUI en vaak ook zonder API en andere context die een complete applicatie wel biedt.

Hier zijn het meestal open source tools zoals de populaire combinatie van Xunit, Moq en Autofixture.