Door het oog van de tester

Vaak wordt er gevraagd naar een tester op het moment dat de kwaliteit tijdens een project blijkt tegen te vallen, of dat te veel zaken verkeerd gaan in de live omgeving. Maar wat wordt er dan eigenlijk gevraagd? In ieder geval niet om ‘handjes’ die testgevallen inkloppen, maar juist om een bepaalde kijk op de (ICT) wereld. Hieronder een poging om die ‘kijk’ te omschrijven.

Hij of zij kijkt naar de situatie en stelt de typische ‘moeilijke’ vragen.

  • Wat is de achterliggende reden dat dit systeem of deze wijziging gebouwd is? Zorg voor een frisse, objectieve kijk. Soms lijkt iedereen het al te weten, totdat jij met de vraag komt. Stel vragen over alle variaties en over toekomstig gebruik. Ken de business en zorg dat je precies weet wat er nodig is en waarom. Wees daarmee toekomstige requirements voor. Bovendien identificeer je zo gaten in het ontwerp.
    .
  • Welke (verborgen) startvariabelen zijn er? Waar komen die vandaan? Zijn ze correct en komen ze goed door? Zoals: “De medewerkers in het personeelsbestand mogen de cursus aanvragen.” Ook iedereen die al uit dienst is? Alleen internen en met een contract voor onbepaalde tijd? In iedere functie? Ongeacht aantal contracturen per week? En hoe kom je aan die informatie?
    .
  • Hebben we alle opties in een beslissing meegenomen? Zoals: “Het navigatiesysteem geeft de aanwijzingen voor de richting rechtdoor, linksaf of rechtsaf.” Uiteraard zijn er nog veel meer opties, zoals rotondes, afbuigingen, enzovoort).
    .
  • Wat zijn de (verborgen) gevolgen van de beslissingen? Inclusief de gevolgen van alle gevonden startvariabelen en opties. Moeten rapportages worden aangepast? Welke andere systemen krijgen deze informatie door? Wat moet er in die systemen worden aangepast, en moet de interface ook worden aangepast? Kloppen de procedures en werkinstructies nog? Verwachten we performance problemen? Zijn er security aspecten, zoals beveiliging of toegang? En mocht het fout gaan (lege waarden, tekst in datumveld, crashes), hoe handel je dit dan af? Veel van deze zaken zullen door een architect worden besloten.
    .
  • Vraag neutraal en objectief door op de details. Want juist daar gaat het vaak fout. Waarom? Hoe? Wanneer? Waarom? Hoe vaak? Hoe? Wanneer? Waarom? Hoe? Welke? Waarom? Wie? Hoe? Wanneer? Waarom? Waarom? Tot je het beeld helemaal compleet hebt. En niet alleen om de details boven water te krijgen, maar ook om de bestaande hoofdlijnen te valideren.
    .

“Wil je dit even testen” is een simpele vraag, maar goed testen betekent dus nogal wat. Gelukkig levert het ook nogal wat op!

door Sander Mol op woensdag 21 mei 2014 in Kwaliteit

Plaats als eerste een reactie!

Naam*: E-mail*: