Testmethodieken
Testmethodieken
De normen achter onze testmethodieken
Goede test methodieken zijn er uiteraard op gericht om een zo correct mogelijk testresultaat te bereiken. Voor softwaretesters hangt deze ‘correctheid’ af van strenge, internationale normen, zoals de ISO 9126 standaard voor acceptabele software. Op basis van deze en andere normen werd onder andere een aantal wijzen ontwikkeld om tot gestructureerde softwaretesten te komen. Onze gecertificeerde testers werden speciaal getraind om deze methodes te hanteren:
- ISTQB, de meest verspreide standaard (o.a. EU, Canda, Australië);
- TMap (IP/Softwarecontrol).
TMap en ISTQB vermelden zelf Barry Boehm als inspiratiebron. Hij beschreef als eerste het belang van (vroeg) testen in de ontwikkeling van acceptabele software. In Nederland is verder ook het werk Kwaliteitszorg door Acceptatietesten (Mors) voornaam.
De criteria van onze testmethodieken
ISTQB en TMap test methodieken streven naar zogenaamd ‘agile’ of lenige, zuivere programmatuur. Uiteraard is dit ook het ultieme streven van onze softwaretesters. Zo helpen zij u op weg naar wat men ‘acceptabele’ software noemt. De leidraad van TMap en ISTQB is ook die van onze erkende testers. Zij halen de volgende eigenschappen in uw testscripts naar boven:
- Effectiviteit;
- Efficiëntie;
- Betrouwbaarheid (in moeilijke omstandigheden);
- Gebruiksvriendelijkheid;
- Flexibiliteit qua programmatuur- en omgevingsadaptatie;
- Veiligheid;
- Beheerbaarheid.
Statische versus dynamische testmethodieken
Zoals gezegd hangt de keuze van de juiste test methodieken nauw samen met de noden van uw scripts. Grofweg wordt echter een onderscheid gemaakt tussen statische en dynamische test methodieken. De eerste soort omvat bijvoorbeeld reviews, doorlopen of inspecties. Het gaat hier over verificaties. De tweede soort gaat daarentegen effectief stukjes programmatuur uitvoeren om die te testen op hun werkzaamheid. Hier gaat het over validering. Om tot een acceptabel script te komen moeten statische en dynamische test methodieken gecombineerd worden.
Box testmethodieken
Daarnaast worden software testmethodieken traditioneel ook opgesplitst in white box en black box testen. Met deze opdeling wordt vooral het standpunt van de software tester benaderd.
White box testen (ook clear box, glass box, transparant box of structurele testen) beproeven de interne structuur of werking van uw script in vergelijking met de functionaliteit die de eindgebruiker ervaart. De test gebeurt hier als het ware vanuit het perspectief van het programma. De software tester houdt tijdens de test ook zicht op de broncode. Hij gebruikt zijn inzichten als programmeur om de test uit te kiezen en uit te voeren. Dit kunnen bijvoorbeeld API tests zijn, maar ook code coverage, fault injection, mutatietesten of diverse statische testen.
Bij black box testen verandert het standpunt van de software tester in dat van een ‘normale’ eindgebruiker. Hij test nu de functionaliteit van het programma zonder bijkomende kennis van het interne systeem en zonder zicht op de broncode. Black box testers weten enkel wat de software zou moeten doen, maar niet hoe. Tot deze testen behoren onder andere equivalent partitioning, boundary value analyse, all-pairs testing, state transition tables, fuzz testen, decision table testen, model-based testen, use case testen, verkennende testen en specificatietesten.
Naast white en black box testen bestaan er, tot slot, ook nog grey (gray) box testen. Bij dit soort testen wordt interne kennis gebruikt om de test op te stellen (zoals bij een white box test), maar voert men die vervolgens uit ‘als eindgebruiker’ (zoals bij een black box test).
Tot zover de informatie over de testmethodieken van Testoo. Wilt u meer weten of kunnen wij u helpen bij het bepalen van de juiste methodiek? Wij horen het graag!