Model Based Testing

Hoe je het ook went of keert, testen gebeurt eigenlijk altijd op basis van een model of het nu een functioneel ontwerp is of echt een model als in de essentie bij MBD. Testers gebruiken altijd modellen om hun testen op te baseren. Zoals in het stuk MBD staat aangegeven is het testen van een systeem dat gegenereerd is, net even anders dan een systeem dat gecreëerd is. Toch valt er nog genoeg te doen voor een tester bij een MBD-traject. Laten we beginnen bij het begin.

Het begin

Ook bij MBD-trajecten geldt dat hoe eerder een fout wordt gevonden in het traject hoe goedkoper het is om hem op te lossen. Op het moment dat een systeem gerealiseerd wordt, worden er eisen opgesteld waar het systeem aan moet voldoen.

Testers kunnen hier een uitstekende rol bij spelen om te reviewen of deze eisen bijv.:

  1. Testbaar zijn en daarmee realiseerbaar;
  2. Requirements elkaar tegenspreken;
  3. Requirements een tijd volgordelijkheid in zich herbergen;

Wanneer er de requirements de toetsing van de tester hebben doorstaan kunnen ze in een model worden vastgelegd. Ook bij de toetsing van de vastlegging in een model kan een tester een uitstekende rol spelen.

Ten eerste kunnen zij controleren of alle requirements op een juiste en eenduidige wijze zijn ondervangen in het model. Ten tweede kunnen zijn het model controleren op fouten in de beslispunten een fout met een kleiner dan dat een groter dan had moeten zijn is immers zo gemaakt. Ten derde kunnen tester ook beoordelen of de juiste modelleringtechniek is toegepast.

Tot slot kunnen testers helpen bij het opstellen van de acceptatiecriteria, wanneer is het systeem volgens de business (de gebruikersorganisatie) goed genoeg om in productie genomen te worden.

De realisatie

Wanneer het model is gevalideerd en als voldoende dekkend is beoordeeld, kunnen testers zich focussen op het beschrijven van de testgevallen voor het afdekken van de nonfunctionele eisen. Te denken valt hierbij aan, de lijst is zeker niet uitputtend:

  • Interoperablilteit – de samenwerking met andere systemen;
  • Performace, Load en Stress – De werking van het systeem wanneer deze in extremis wordt belast;
  • Security – Mag iedereen het systeem gebruiken of niet;
  • Traceerbaarheid – Worden acties gelogd en gaan er alarmbellen af wanneer er iets ongeoorloofds gebeurd;
  • Gebruikersvriendelijkheid – Hoe eenvoudig kan het systeem bediend worden;
  • Installeerbaarheid – Hoe eenvoudig is een nieuwe versie van het systeem op een omgeving te installeren;
  • Etc.

De testen

Naast de hierboven genoemde aspecten waar testers het systeem op kunnen beoordelen, kunnen de testers ook alvast beoordelen of het systeem voldoet aan:

• De opgestelde acceptatiecriteria door de gebruikersorganisatie, als een tester het al niet voldoende vindt, dan vinden gebruikers het meestal nog minder;

• De huisstijl, de userinterface van een gegenereerd systeem voldoet meestal niet aan huisstijl, wanneer de tester hierachter komt kan hier al actie op ondernomen worden voor dat de gebruikers het zien en teleurgesteld zijn;

• De gestelde ingaand of uitgaande interface definities, interfaces blijven in alle vormen van systeemontwikkeling een punt van aandacht. Of het nu gaat om de implementatie van maatwerkoplossingen bij standaardpakketten of (micro-)services daar waar systemen met elkaar gegevens uitwisselen is de kans op fouten groter.

Daarnaast kunnen testers zich nu bezighouden met het realiseren van een testautomatisering oplossing die aan het einde van de model generatie fase het model valideert op regressie.

Daarnaast kan deze oplossing ook gebruikt worden om een deel van de non-functioneleeisen te testen

Advertisements