Efficient testen, kosten van ontwikkelen van testcases

Testen kost tijd en dus ook geld dat terugverdiend moet worden uit de afdekking van risico’s. Het is dus de kunst om de kosten van het software testen te minimaliseren.

Grofweg zijn de volgende benaderingen mogelijk bij de reductie van de test kosten:

  • Niet testen, indien dat uit oogpunt van risico afdekking acceptabel is.
  • Testaanpak bepalen op basis van de PRA (Product Risico Analyse). Daarbij wordt bewust een aantal aspecten minder dekkend getest en het aantal testen gereduceerd. Van belang is dat de testcoverage inzichtelijk moet worden gemaakt voor het nemen van een G0-Life beslissing.
    (hierover is voldoende informatie vrijelijk beschikbaar)
  • Offshoring van het testen, hetgeen mogelijk moet zijn indien de requirements en scripts éénduidig zijn. Echter de overhead / communicatie kosten zijn niet te verwaarlozen.
  • Automatiseren van de testuitvoering
  • Requirements Based Testing, waarbij de functionele requirements de basis vormen.

Ik wil in deze blog verder ingaan op Requirements Based Testing en hoe dat in de praktijk zijn voordelen heeft.

Zoals de naam het al zegt, begint de aanpak bij de Requirements. Het omzetten van tekst naar een formele logica, in de vorm van een Cause Effect Graph (Oorzaak Gevolg Diagram) haalt de discussie over “hoe het nu eigenlijk bedoeld is” naar voren in het project. De kosten reductie daarvan is enorm.

Testcase design Cause Effect Graph, basis voor genereren van testcases

Testcase design Cause Effect Graph, basis voor genereren van testcases

Het bovenstaande plaatje geeft een indruk van een CEG (Cause Effect Graph).

Het rendement van omzetten van tekst naar formele logica is hoog.

  • Bij het uitwerken van tekst naar het model hebben we in de laatste 15 jaar geconstateerd dat 1 pagina tekst ca 30 vragen oproept tijdens de Requirements fase. Op dat moment zijn de reparatiekosten vaak nog te overzien, terwijl als de onduidelijkheden pas tijdens testen / oplevering naar voren komen, de kosten erg uit de hand lopen.
  • Als het formele model is opgesteld, kunnen nu reeds de testen en If-Then-Else logica worden gegenereerd. (zie ook presentatie van Dick Bender Bender-RBT-Product-Overview )

 

Geplaatst in Requirements Based Testing Getagd met ,