Geautomatiseerde testplannen in High Tech omgeving

Published 7 december 2016 | By Gerben de la Rambelje

Auteur: Eric Spaargaren  ● erics70@kpnmail.nl

Testplannen schrijven een nieuwe ontwikkeling
De afgelopen jaren schreven we testplannen volgens een bepaald formaat, waarbij Tmap en ISTQB als methodiek werden gehanteerd. Momenteel worden testplannen veelal geschreven in een document met een strakke opmaak. Echter, er lijkt nu een kentering te komen om het schrijven hiervan op een meer innovatieve manier te gaan doen. Op dit moment zijn de onderdelen van een testplan bijvoorbeeld:

·         Introductie en testbenadering;

·         In scope, out of scope;

·         Testtechnieken;

·         Systeemtesten;

·         Geautomatiseerd testen en testtools;

·         Indeling testcases en testuitvoering.

Een testplan kan geschreven worden voor diverse doeleinden. Bijvoorbeeld voor de interne of externe klanten. Dat is echter wel een groot verschil. Voor interne klanten zijn er maar een paar reviewrondes nodig, want het is voor intern gebruik en het plan wordt gelezen door medewerkers van een bepaalde afdeling. Maar het wordt anders als een testplan voor externe klanten wordt geschreven. De klant is hierbij de lezersdoelgroep en de klant is kritisch. Dit betekent meerdere reviewrondes en vele wijzigingen en dus doorzettingsvermogen. Want als een testplan extern wordt gepubliceerd, dan moet het heel goed worden geschreven.

Een aantal verschillen tussen intern en extern schrijven van testplannen:

Intern gebruik:

·         Binnen twee à drie weken gereed;

·         Drie reviewrondes;

·         Medewerkers als lezersdoelgroep;

·         Testplan wordt als werkmateriaal gebruikt.

Extern gebruik:

·         Twee tot drie maanden een document in concept;

·         Vele reviewrondes;

·         Wijzigingen van de indeling kan veel veranderen tijdens het schrijven;

·         Het mag geen fouten bevatten, de klant verwacht een ‘foutloos’ document.

De plannen worden dus handmatig geschreven, maar er zit verandering aan te komen. De trend is dat er nieuwe technologieën gebruikt worden om testplannen in een automatisch script te gaan schrijven volgens de ‘CamelCase opbouw’. CamelCase is een schrijfwijze om een testcase benaming makkelijk leesbaar te houden en dat kan handig zijn voor het verder opstellen van het programmascript in de geautomatiseerde testtool. Er zijn twee varianten van CamelCase:

1.     UpperCamelCase (voorbeeld naamgeving: ProcessingCheckTrail)

2.     LowerCamelCase (voorbeeld naamgeving: processingCheckTrail)

Het ontwikkelen van geautomatiseerde testplannen
Er zijn dus twee manieren om een testplan te gaan schrijven. In document-vorm of in een geautomatiseerde testtool. Dit laatste is een nieuwe ontwikkeling in 2016. Het standaard model van een testplan gaat niet verdwijnen, maar wordt minder belangrijk, omdat organisaties sneller willen werken. Het voordeel van een geautomatiseerde testtool is dat de content direct toegepast kan worden voor het programmeren van de geautomatiseerde testen. Een pluspunt hierbij is dat dit soort plannen opgebouwd zijn volgens één standaard methodiek en snel overdraagbaar zijn voor de ontwikkelaars, die de testplannen gebruiken om geautomatiseerde testscripts te schrijven.

Voorheen berustten de activiteiten op het schrijven van een testplan voorzien van alle testelementen zoals testscope, teststrategieën, testdoelen, testorganisatie en bevindingenbeheer. Momenteel zijn de daadwerkelijke logische testscripts veel essentiëler. Het werk van een senior tester lijkt dus te gaan veranderen. Voorheen was je bezig met zowel het testplan, testscript en de uitvoering.  De tester gebruikt de testscripts om de testen uit te voeren met de daadwerkelijk aangeleverde software patch van de softwareontwikkelaars. In een innovatieve omgeving werkt de tester veelal in een virtuele omgeving, waarbij de essentie ligt op testtools. Deze testtools worden gebruikt voor het schrijven van testplannen en testspecificaties op basis van de aangeleverde strategische functionele requirements. De testontwikkelaars bouwen de testscripts, die worden gebruikt voor het uitvoeren van de testen. Daarbij is het ook essentieel dat de geautomatiseerde testscripts gecontroleerd worden op juistheid. De ontwikkeling van de geautomatiseerde test wordt uitgevoerd door de testontwikkelaars. De testdesigners komen steeds minder in aanraking met de daadwerkelijke software. Dit lijkt een gevaarlijke ontwikkeling van de ‘testdesigners’, die de testscripts op logisch niveau ontwerpen. Termen als ‘sjoemel software’ zou hier van toepassing kunnen zijn omdat de testdesigner geen daadwerkelijk grip meer heeft op de software die wordt ontwikkeld. De testdesigner is veel meer actief met het design van het testplan en/of specificaties dan met de validatie van de opgeleverd software. Het testplan wordt geschreven op de aangeleverde functionele requirements.

Verschuiving van werkactiviteiten
Voorheen was de senior tester naast het schrijven van testspecificaties ook bezig met het daadwerkelijk testen van de ontwikkelde software. Nu veranderen de testopdrachten en werken senior testers meer in een virtuele testomgeving waarin het testdesign plaatsvindt. De senior tester krijgt meerdere vormen van requirements aangeleverd, zowel op strategische als op tactische niveau. Daardoor lijkt het soms alsof de tester activiteiten uitvoert als businessanalist. Echter, de inbreng van de ‘mindset’ van een tester blijft belangrijk. Zoeken naar informatie om de testscripts zoveel als mogelijk fysiek te krijgen voor de eerste oplevering blijft een mooie uitdaging, omdat documentatie of informatie ook kan ontbreken in een organisatie. De senior tester werkt in een high-tech omgeving en dient een brug te slaan tussen business en IT. Als de testscripts in de vorm van het testplan geschreven zijn, worden deze opgeleverd aan de softwareontwikkelaars (ook testers), die de testscenario’s omzetten in geautomatiseerde testscripts. De senior tester is in de afrondingsfase en beheerfase van het testdesign beland of er komt nog een review retour waarbij nog aanpassingen nodig zijn. De testontwikkelaar ontwikkelt de automatiseerde testscripts en heeft vaak nog vragen aan de senior tester. De testontwikkelaar geeft de senior tester een ‘link’, waarbij hij of zij wederom in een andere testomgeving de geautomatiseerde testscripts kan lezen. Ook de resultaten van de uitvoering van de geautomatiseerde testscripts kan in deze omgeving gelezen worden.

Scrum/Agile
Als er wordt gewerkt volgens Scrum/Agile is een testplan eigenlijk niet meer van toepassing, zo denkt men.  Maar juist met het schrijven van een geautomatiseerd testplan zou dit zeker ook van toepassing moeten zijn in een Scrum/Agile omgeving. Omdat het testplan in een automatische testomgeving is opgesteld, kan er juist heel goed per iteratie aanpassingen uitgevoerd worden en is het testplan prima bruikbaar voor iteratieve opleveringen en het testen van de software.

Validatie van het testplan

Het schrijven van een testplan kost tijd, omdat het een soort boek is met informatie waarbij een aantal review rondes plaatsvindt. Het moet steeds anders: de tekst, de indeling van het document et cetera. Review is validatie. Uiteindelijk is er een versie 1.0 klaar voor intern gebruik voor de medewerkers van de organisatie of er is een testplan geschreven voor de klanten van de organisatie. Het schrijven van een document of een plan zou ook wel eens een jaar kunnen duren. Het schrijven van geautomatiseerde testplannen in een virtuele omgeving en/of repository, waar ook anderen van het ontwikkeltestteam kunnen inloggen, zijn de huidige ontwikkelingen. Tussentijds kan er gevalideerd worden. Er wordt volgens één methodiek gewerkt, valideren gaat hierdoor sneller.

De ontwikkelingen in het testvak richting het jaar 2020:

·         De senior tester werkt in een high-tech testomgeving;

·         De senior tester is:

o    testdesigner geworden of

o    softwareontwikkelaar die geautomatiseerde testscripts ontwikkelt;

·         Er wordt gewerkt volgens de standaard van de Testdesign Tool;

·         De ontwikkeling van geautomatiseerde testscripts wordt uitgevoerd door softwareontwikkelaars (testers);

·         De senior tester heeft minder grip op de aangeleverde software;

·         De softwareontwikkelaar (tester) heeft alle grip op de aangeleverde software;

·         Het schrijven van testplannen in een document blijft, maar de ontwikkelingen gaan stevig door in het schrijven van testplannen in de geautomatiseerde high-tech testomgeving.