Over software testen: manueel testen

Als je als tester de software voor je neus krijgt, ga je de software testen. Maar hoe dan? Normaal gesproken doe je dat manueel, dus je klikt er zelf doorheen. Het kan ook automatisch, maar daar later meer over. Manueel testen dus.

Testen kan je grofweg gezegd op vier niveaus doen:

  • ‘Unit’-niveau: het kleinst mogelijk gedeelte van de software, bijvoorbeeld op een knop drukken op een rekenmachine.
  • ‘Module’-niveau: de samenkomst van de units, bijvoorbeeld de berekening achter het ‘+’-teken op een rekenmachine.
  • ‘Integratie’-niveau: de samenkomst van de modules, bijvoorbeeld één configuratie op een rekenmachine (de standaard Windows rekenmachine kan je zetten op ‘standaard’, ‘wetenschappelijk’, ‘programmeren’ en ‘statistieken’).
  • ‘Systeem’-niveau: het complete systeem.

Als je een hoger niveau test, test je ook alle onderliggende niveaus. Om zoveel mogelijk bugs te vinden en ze ook te lokaliseren op het juiste niveau, wil je in je test proces het liefst op elk niveau tests uitvoeren. De laagste twee niveaus, unit en module, zijn geschikt om bijna compleet te automatiseren. De hoogste twee niveaus, integratie en systeem, zijn daar minder geschikt voor, omdat het te veel tijd kost om ze te maken, onderhouden en uit te voeren. Je wil op die niveaus het liefst wel automatisch testen, maar dan met een niet-complete dekking.

Sowieso is een complete dekking met testen onmogelijk. Een rekenvoorbeeldje:

  • Stel één module berekent de leeftijd van een persoon.
  • Leeftijd bestaat uit twee datums: vandaag en de geboortedatum.
  • Je neemt aan dat mensen niet eerder geboren zijn dan 150 jaar geleden.
  • Je wil testen of het de komende 100 jaar werkt.
  • Er zitten 365 dagen in een jaar.
  • Komende 100 jaar: 100 jaar * 365 dagen per jaar = 36.500x ‘vandaag’.
  • Afgelopen 150 jaar plus komende 100 jaar: 91.250 geboortedatums.
  • 36.500 * 91.250 = 3.330.625.000 triljoen mogelijkheden.
  • Stel een computer kan per milliseconde bereken of de leeftijd klopt.
  • 3,3 triljoen * 0,001s = 39 volle dagen.

Het kost dus 39 volle dagen om alleen al dit te berekenen. En dat is nog een gunstige berekening: zou je niet ook de leeftijd van oudere dingen willen berekenen? Kost één berekening slechts één milliseconde, want dat is heel erg snel? Willen we niet ook datums testen die niet bestaan (29 februari 2017, of 32 december, …). Daarnaast is dit slechts één module, laat staan als je het verschil in leeftijd tussen twee dingen zou willen berekenen (3,3 triljoen * 3,3 triljoen * 0,001s = 128.391.931.604 volle dagen). Met andere woorden: je moet áltijd een selectie maken van mogelijke test cases. En daar zijn een heleboel nuttige en interessante manieren voor, maar dat is wat té theoretisch, dus laten we aannemen dat je het meer dan significant kan terugdringen.

Met dat terugdringen zal je altijd bepaalde delen niet kunnen testen. En dat is eigenlijk geen probleem, want met testen wil je de kwaliteit bewaken, en niet de kwaliteit garanderen. Je wil dus in zo min mogelijk tijd, met zo min mogelijk inspanning, zo zeker mogelijk zijn over de kwaliteit. Dat zal altijd een afweging zijn. Als er software gemaakt wordt voor een bedrijfskritisch proces, zal je meer tijd besteden aan testen. Als er software gemaakt wordt voor intern gebruik, is de kwaliteit minder belangrijk.

In het proces van het terugdringen van alle mogelijke test cases heb je een heleboel verschillende technieken, genaamd “testtechnieken”. Dat zijn uiteraard allemaal hele slimme manieren die gebruik maken van verschillende al dan niet bewezen theorieën. Bijvoorbeeld: “boundary value analysis”. Waarom alle dagen van het hele jaar testen, als je vooral problemen verwacht bij boundaries (1e en laatste dag van de maand cq. het jaar, 29 februari, als iemand vandaag jarig is, …)? Als alle boundaries werken, kan je er vrij zeker van zijn dat alles ertussenin ook werkt. Of een ander: “exploratory testing”, waarin je op basis van al jouw kennis niet vooraf allerlei test cases opschrijft, maar gelijk met de software aan de slag gaat en doet wat voor jou (als tester, maar ook als welwillende gebruiker, en ook als niet-welwillende gebruiker) logisch lijkt. Als dat allemaal goed werkt, is de kans klein dat er nog iets anders kapot gaat.

Het liefst gebruik je meerdere testtechnieken, omdat geen van allen perfect is en ze allemaal gebaseerd zijn op aannames die niet altijd kloppen. Uiteindelijk zal je op een gegeven moment het gevoel hebben dat je ‘alles’ ‘goed genoeg’ hebt getest, en kan je doorgeven dat je helemaal tevreden bent met de kwaliteit. Of niet, en dan kom je met je lijstje met test resultaten aanzetten.

Dit bericht is geplaatst in de categorie Beta met de tag . Bookmark de permalink.

Geef een reactie

Jouw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *