NieuwsMagazine

Geautomatiseerde testplannen in een high-tech omgeving

Door: Gerben de la Rambelje
Auteur: Eric Spaargaren  ● erics70@kpnmail.nl
Eric Spaargaren
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)

camelcaseHet 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.
s2000px-scrum_process
 
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:
    • testdesigner geworden of
    • 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.

 

4 reacties

  1. Ik denk dat de toekomst van het testplan sterk afhankelijk is van het bedrijf / het type organisatie en de manier van werken en opleveren.
    Als ik naar m’n eigen situatie kijk (enige tester op een klein team in de high-tech R&D software development via een Kanban systeem) zie ik het schrijven van testplannen helemaal niet meer terug. De laatste versie van het MTP is gedateerd juni 2013. Niemand heeft de afgelopen 3 jaar meer gevraagd om een testplan. Er is simpelweg geen (informatie)behoefte meer die geadresseerd wordt met een testplan.
    Wat je wil weten is waar de prio’s liggen bij testen, dus de PRA is nog net zo relevant als altijd (en dat zal altijd zo blijven, een PRA is immers de basis…een testplan niet gebaseerd op een PRA heeft naar mijn mening geen enkele waarde). Gebaseerd op de PRA wordt de beslissing m.b.t. test effort en eventueel automatiseren genomen. Verder is wat er normaal gesproken in een testplan staat gewoon niet interessant / relevant meer; Budget? Staat vast / rolling forecast. Bemensing? Het vaste team met hier en daar wisseling van externe capaciteit. Omgeving? Zoals 3 jaar geleden (ok, de VMs hangen nu in Azure i.p.v. de lokale Hyper-V). Testobject? Het product. Scope? Het product. Etc.
    Bottom line: Als team zijn we verantwoordelijk voor het product en wanneer we een release uitbrengen hangt zeer sterk af van waar we aan bezig zijn (en / of voor welke klant). Een aantal weken geen release komt voor, meerdere releases per week ook.
    In omgevingen die veelal dynamischer worden, zie je allerlei plannen sneuvelen. Er zijn roadmaps voor de globale richting het komend jaar, er worden thema’s opgepakt en er zullen releases gepland worden voor bepaalde thema’s / feature sets. Vanuit de business zie ik daarvoor een verschuiving van dikke Word documenten voor de business case naar een PowerPoint van 2-3 kantjes. De thema’s / features worden met het team uitgewerkt en komen op het backlog / board. Daar komen ook geen development plans meer bij kijken. Het zou in z’n situatie vreemd zijn om nog wel een dik testplan te hebben.
    In andere branches en sectoren zal dit anders zijn. Een vliegtuig zal niet zomaar zonder dik en zwaar ge-audit plan getest worden. Ook voor andere redenen zullen testplannen in bepaalde situaties van belang blijven. Maar in veel situaties zal een testplan (in z’n huidige vorm) geen meerwaarde bieden en daardoor verdwijnen.

  2. Hallo Robin, Leuk dat je een reactie geeft op mijn artikel. En het klopt dat het per type organisatie verschillend is of een testplan belangrijk is. Dus het kan soms wel belangrijk zijn om een testplan te schrijven, echter in een nieuw formaat zoals beschreven in mijn artikel en met behulp van een geautomatiseerde testtool.

  3. Bedankt Eric,
    Een mooi, leerzaam artikel. Het lijkt mij ook een goed onderwerk voor een testavond/workshop.
    Weet jij misschien de naam of Website van z’n geautomatiseerde tool?

  4. Hallo Tony,
    De testtools die gebruikt worden voor het schrijven en samenstellen van geautomatiseerde testplannen zijn verschillend. Voorbeelden van geautomatiseerde testtools zijn: Qtest of Cucumber.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *