Wat is nu eigenlijk gestructureerd testen? Wat is eigenlijk testen? Testen doet iedereen, elke dag! We kijken of iets het doet of niet. Maar dit kan je ook in een breder verband zien dan alleen software testen. Als je bij de supermarkt staat kijken veel mensen naar de houdbaarheidsdatum. Is het product nog goed (voor de datum) of verlopen (na de datum)? Bij het kijken of zelfs kopen van een nieuwe auto vraagt men zich af is de auto mooi of niet mooi? Een nieuwe TV, is deze goedkoper bij winkel 1 of goedkoper bij winkel 2. Hierin kan ik nog heel lang doorgaan. Punt is dat al deze dingen testen zijn. Echter spreken de verwachtingen voor zich. Je wilt producten die nog niet zijn verlopen, een mooie auto en die TV bij de goedkoopste winkel. Echter soms zijn er minder makkelijk uitkomsten te bepalen. Wat is daarbij nu de verwachting en wat is het resultaat?

Indien we de verwachting gaan bepalen aan de hand van technieken en dat vastleggen en daarna de uitkomst vergelijken met de verwachting, zijn we gestructureerd bezig. Dus we gaan aan de hand van bepaalde technieken verwachtingen bepalen en controleren of de uitkomst gelijk is of niet. In het geval van software testen is het dus: het uitvoeren van vooraf bepaalde testgevallen, waarbij gecontroleerd wordt of de verwachtingen voldoen aan de uitkomsten. Deze testgevallen zijn daarbij opgesteld aan de hand van testtechnieken.

In onderstaande ga ik open deuren intrappen, maar dan is voor iedereen weer duidelijk wat gestructureerd testen nu is.

Opstellen van testgevallen
Bij gestructureerd testen is het belangrijkste om testgevallen op te stellen. Deze testgevallen geven namelijk weer wat je wilt gaan controleren. Nu is het soms heel makkelijk om testgevallen te maken. Denk bijvoorbeeld aan een postcode veld in een applicatie. Deze moet voldoen aan de postcode notatie van vier cijfers en 2 letters. Je kunt dat veld dus gaan testen door andere combinaties dan de standaardnotatie in te voegen (foutsituatie) of controleren of het veld een postcode accepteert (goedsituatie).

Bij een postcodeveld is dus duidelijk wat de juiste situatie moet zijn. Echter bij veel applicaties is dat niet altijd duidelijk. Hoe moet een bepaald scherm zich gedragen, hoe is de menustructuur, welke zaken worden er opgestart zodra ik iets invoer of juist verwerkt. Deze zaken moeten dus van te voren bekend zijn, ofwel in een ontwerpdocument staan. Vaak zijn dit functionele ontwerpen, maar het kan een ook een bierviltje zijn waarop staat hoe de applicatie moet functioneren.

Aan de hand van dat ontwerp wil je dus de testgevallen opstellen. Dat kan op vele manieren, maar hoe kan je nou zoveel mogelijk uit de kast halen om de hele applicatie af te dekken. Natuurlijk 100% testen bestaat niet vanwege tijd en kosten, maar stel nou dat het wel kan. Dan moeten we elk onderdeel in het ontwerp aan een test onderwerpen en dus voor al die onderwerpen een testgeval opstellen. Nu lijkt dat makkelijker dan het is, maar in een document van meer dan 10 bladzijden wordt het al moeilijk om volledig dekkend te zijn om de juiste testgevallen op te stellen. Daarom zijn er gelukkig meerdere testtechnieken, of testontwerptechnieken, die je kunnen helpen bij het opstellen van de testgevallen. Er zijn werkelijk allerlei verschillende testtechnieken die je kunnen gebruiken bij het opstellen van de testgevallen. Op zo’n manier krijg je dus de beste testgevallen of de meest simpele manier. Ook al zijn sommige testontwerptechnieken soms best complex. Bekende voorbeelden zijn real-life test, gegevenscyclustest, beslissingstabeltest en datacombinatietest. Natuurlijk zijn er nog veel meer testontwerptechnieken te vinden.

Tip: Zoek eens op Google of Wikipedia naar testontwerptechnieken die je kunt gebruiken. Ook op o.a. tmap.net is informatie te vinden.

Verwachtingen bepalen
Als eenmaal bekend is wat er getest gaat worden is het wel van belang te bepalen wat de verwachtingen zijn bij het uitvoeren van deze testgevallen. Dus gaan we de verwachte uitkomsten bepalen van die testgevallen die we willen gaan uitvoeren en dit verwerken bij die testgevallen. Ook dit doen we aan de hand van de ontwerpdocumenten. In de ontwerpdocumenten staat namelijk ook beschreven wat de reactie van de applicatie moet zijn. Dus kunnen we van te voren bepalen wat de verwachte uitkomst is. Denk aan iets simpels als de ‘Start’ knop in Windows. Als je op deze knop drukt verschijnt het startmenu. In de ontwerpen van Windows heeft dus gestaan dat bij het klikken op die knop het startmenu zou moeten verschijnen. Natuurlijk is dit een simpel voorbeeld, maar soms is testen ook heet simpel. Een andere mogelijkheid is bijvoorbeeld het invullen van een bankrekening op een webshop. Er bestaat namelijk de mogelijkheid om een bankrekening te controleren of deze echt bestaat, de zogenaamde 11-check. Hetzelfde geld voor BSN-nummers (oude sofinummer), maar die heeft een andere controle. De applicatie kan zodra de bankrekening is ingevoerd een controle uitvoeren of het rekeningnummer echt bestaat door de 11-check uit te voeren. Dus bij het invullen van een bestaand rekeningnummer verwacht je dat deze goed gaat en bij een niet bestaand nummer verwacht je een foutmelding. Je uitkomst is dus afhankelijk van je invoer in de applicatie. Dus bij het opstellen van je testgevallen dien je daar al van te voren rekening mee te houden.

Uitkomsten controleren
Nu we de testgevallen hebben opgesteld en de verwachte uitkomsten hebben bepaald is het zaak om deze ook echt te gaan uitvoeren. Zodra de applicatie is gebouwd kunnen we van start gaan. Soms ook eerder, maar laten we het simpel houden. We gaan de testgevallen uitvoeren en controleren daarbij de uitkomsten.

Indien een uitkomst overeen komt dan noteren we dat. Maar indien een uitkomst niet overeenkomst dan noteren we dat ook. Daarbij kijken we ook wat er mis is. Het noteren van een foute test noemen we een bevinding. In een bevinding noteren we wat er fout is en wanneer we het hebben ontdekt. Ook geven we nog andere informatie mee die een administratie van bevindingen verbeterd en een bouwer van de applicatie het versimpeld de bevindingen op te lossen.

Zodra dit is gebeurd doen we, normaal gesproken, een nieuwe test (hertest) op dat testgeval om te kijken of alles nu wel goed functioneert. Ook deze uitkomst noteren we weer. Uiteindelijk zijn alle testgevallen uitgevoerd die we hebben willen uitvoeren en kunnen we zeggen of de applicatie goed is of juist slecht.

Op deze manier heb ik geprobeerd simpel uit te leggen wat gestructureerd testen nu eigenlijk is. In andere postings van ons zullen we soms dieper ingaan op de problemen rond gestructureerd testen.