Testen: een vak apart

De laatste jaren wordt iedereen (de gehele markt) zich bewust dat bij een produkt een zeker kwaliteits-kenmerk zou moeten behoren. Een auto met een NCAP-waardering van 5 sterren ligt beter bij het publiek dan een andere auto met een waardering van 1 ster. Zo ook bij software. Helaas is software, zoals de naam zegt... zacht, niet tastbaar, niets fysieks.... Hoe er dan getest kan worden, wordt hier in uitgelegd. Vroeger waren programma's kort en krachtig, en kon de programmeur zelf een zekere waarde/oordeel afgeven aan de klant inzake zijn toepassing.
Nu, met alle grafische omgevingen, verbindingen met andere (externe) systemen, en afhankelijkheden is het overzicht niet goed meer te overzien. En TOCH moet men (als bedrijf) een goed stuk programmatuur opleveren.

Alles testen, simpel toch??

..Of niet. Het begrip "Alles" is erg ruim en omvat te veel en niet goed afgebakende gebieden.
Daarom is het enorm belangrijk om op basis van Risico en Kans de Impact te bepalen.
Voor een klein bedrijf is een korte verstoring erg minimaal, maar voor een financiele instelling is uitval van het telebankieren gewoon rampzalig (denk naast financiele schade ook aan imago ("de betrouwbare bank") en herstel-schade (tijd/geld/resources nodig voor herstel).
Vandaar dat het belang van een goed gedefinieerd gebied enorm is: op basis van dat gebied wordt de testaanpak bepaald.
Ofwel: de scope geeft aan wat geraakt of juist niet geraakt wordt.

Risico's

Risico's... iedereen weet dat ze er zijn, maar niemand die zijn hand er voor in het vuur wil steken...
Bij de ontwikkeling van een systeem, wordt in samenspel met de business (het bedrijf, of onderdeel van de organisatie) bepaald per programma-onderdeel welke risico's er kunnen optreden.
Door een lijst te maken met daarin concrete beschrijving, prioriteit en impact kan het testteam al heel wat meer!
De formule Risico = Impact x Kans geeft een 4-tal ratings af: de MOSCOW rating.
Dit is de samenstelling van de 4 risico's : Must, Should, Could, Would.
Het testteam zal zijn/haar effort steken in allereerst de Must-risico's, en indien mogelijk zo afwerken tot de laagste risico: De Would.

Testplan

De leider van het testteam (de testmanager) zal aan de hand van de input een zogenaamd testplan opstellen.
Zie hier, de geboorte van het Master Test Plan (MTP vaak weergegeven).
In dit plan staat nadrukkelijk vermeld:
  • Wie is de opdrachtgever?
  • Wie neemt de opdracht aan?
  • Wat is de scope (het afgebakende gebied)?
  • Welke resources (in manuren, aantal testers, financiën) zijn begroot?
  • Wanneer is voor de business de programmatuur van voldoende kwaliteit?

Uiteraard ontbreken de formele handtekeningen ter bekrachtiging niet!

Het master test plan wordt overhandigd aan de testcoördinator, waarmee hij/zij concreter de aanpak gaat uitwerken.
Het resultaat (een detail test plan (DTP)) omvat een aantal vaste rubrieken, zoals:
  • Hoe vaak en naar wie wordt er gerapporteerd?
  • Welke testtechnieken gaan toegepast worden?
  • De planning inclusief mijlpalen

Testtechnieken- en methoden

De uitvoerende medewerker in het testteam, de testanalisten, krigen hun takenpakket toegewezen.
Dit takenpakket kan een onderdeel zijn (module) van een applicatie/informatiesysteem, of een interface etc.
De testanalist zal met zijn/haar kennis, ervaring en inzicht trachten de genoemde risico's te verwerken in een testscript.
Nu zit er al een transitie van Risico > Logische Testgevallen > Fysieke Testgevallen.
Een logisch testgeval kan zijn: de leeftijd van een client dient tussen de 18 en 35 jaar liggen.
Een daaruit afgeleid fysiek testgeval zou kunnen zijn (voor dat onderdeel): gebruik een klant met de leeftijd van 24 jaar.

De vertaling van logisch naar fysieke gevallen, is met het oog op de beschikbare tijd versneld door gebruik te maken van testtechnieken.
Enkele bekende testtechnieken zijn: Beslissingstabellen, proces-cyclustest, Elementaire vergelijking, etc.
Andere methoden zijn oa. grenswaardeanalyse.

Testautomatisering

Zodra meerdere releases uitgeleverd zijn, en de testscripts verfijnder zijn geworden kan e.e.a her-gebruikt worden.
Men kan een zogenaamde regressie-test uitvoeren aan de hand van eerder gebouwde scripts, welke geautomatiseerd kunnen worden uitgevoerd door applicaties als Quick Test Pro (QTP) of WinRunner.
Voordelen: saai/eentonig hertesten is opgevangen en kan grotendeels volautomatisch (inclusief rapportages) geschieden.
Nadelen: elke release wijziing heeft mogelijk ook invloed op aanpassen van geautomatiseerde scripts.

Defecten

De gevonden afwijkingen tijdens de testuitvoer, worden door de testanalyst nauwlettend geregistreerd in een tool. Veelgebruikte tools zijn Rational ClearQuest en Mercury TestDirector 4 Quality Center.
Aan de hand van de verzamelde informatie, worden deze doorgespeeld aan de ontwikkelaar. Deze is tenslotte verantwoordelijk voor het herstellen van deze bevinding (defect). Na herstel volgt een her-test, waarbij (bij positief resultaat, dus defect opgelost) de analist nauwlettend het scenario reproduceren zal.
Als alles naar tevredenheid verholpen is, wordt deze afgesloten.
Dit proces herhaald zich continue tijdens de testuitvoer.

Certificering voor testers

Al deze activiteiten en de borging van kennis, kunde en inzicht vergen ook de nodige training van de personen.
Veel bekende en gevolgde opleidingen om in het test-vak te werken zijn de volgende cursussen:
  • TMAP/TMAP Next
  • ISTQB Foundation/Practioner/Expert
  • Prince2 Foundation/Practitioner
Dit zijn eigenlijk de meestgevolgde (inter)nationale trainingen die het "rijbewijs" voor de tester vormen.
Bij interesse in een dergelijk vakgebied, neem eens de moeite rond te surfen op het internet, of als je een tester spreekt: benader hem/haar gerust!

De toekomst

Ja.... de toekomst. Wie zal het zeggen hoe deze er uit komt te zien?
Met bloeiende economie is de vraag naar kwaliteit en kwaliteitsborging groeiende.
Momenteel is er een grote vraag naar testers of medewerkers in dit vakgebied.
Wel belangrijk om te zien, dat naarmate de ontwikkelingen van software in ons dagelijks leven toe zal nemen, de vraag vooralsnog ook ongehinderd groeit naar gemotiveerde en getalenteerde testers.

Dit artikel geeft slechts een beknopte indruk van het test-vak.
© 2008 - 2024 Solarpowerrrrrr, het auteursrecht van dit artikel ligt bij de infoteur. Zonder toestemming is vermenigvuldiging verboden. Per 2021 gaat InfoNu verder als archief, artikelen worden nog maar beperkt geactualiseerd.
Gerelateerde artikelen
Software testen in ScrumSoftware testen in ScrumScrum bestaat alweer sinds de vroege jaren 90, maar bedrijven kampen er soms mee dat het software testen binnen een Spri…
Mijn visie op: de rol van het softwaretestteammijn kijk opMijn visie op: de rol van het softwaretestteamEr zijn erg veel bedrijven die net zijn begonnen met software testen, of er zelfs nog mee moeten beginnen. Dit zal altij…
Software testen in ITILSoftware testen in ITILWat is ITIL nou precies, en hoe verhouden software testen en ITIL zich tot elkaar? Dit is een veelgehoorde vraag onder s…
De termen 'quality assurance' vs 'software testen' uitgelegdDe termen 'quality assurance' vs 'software testen' uitgelegdDe termen 'quality assurance' en software testen worden vaak te pas en te onpas gebruikt. Heel veel recruiters in Nederl…

De evolutie van ijzer en staalDe evolutie van ijzer en staalIjzer en staal zijn twee van de oudste metalen die de mens kent. In de moderne wereld zijn deze metalen onmisbaar geword…
Hoe werkt je afstandsbedieningWil je weten hoe de afstandsbediening van jouw televisie, stereo of video werkt? Hier staat in korte lijnen uitgelegd de…
Solarpowerrrrrr (8 artikelen)
Gepubliceerd: 15-03-2008
Rubriek: Wetenschap
Subrubriek: Techniek
Per 2021 gaat InfoNu verder als archief. Het grote aanbod van artikelen blijft beschikbaar maar er worden geen nieuwe artikelen meer gepubliceerd en nog maar beperkt geactualiseerd, daardoor kunnen artikelen op bepaalde punten verouderd zijn. Reacties plaatsen bij artikelen is niet meer mogelijk.