Altijd als eerste onze nieuwste blogs lezen? Laat je email adres achter en je ontvangt een bericht als wij een nieuw blog plaatsen.

Alles uitvoerig testen kan niet altijd en is ook niet even hard nodig. Hoe bepalen we nu wanneer het uitvoeren van testen juist wel of niet grondig gedaan moet worden? Uiteraard is daar een oplossing voor!

Projectteam softwareontwikkeling

Uiteraard moet een website of applicatie goed getest worden. Hierin kan wel per functie een onderscheid gemaakt worden van de intensiteit van testen. Wanneer de backlog gevuld is en de te bouwen functies dus in hoofdlijnen bekend zijn kan de impact van het testen hierop bepaald worden. Per backlog item (functie) wordt dan aangegeven hoeveel testwerk hiervoor nodig is en wat hiervoor gedaan moet worden. Om dit zo pragmatisch aan te pakken zetten wij de Risico matrix in.

Risico Matrix.

Dit is een schema waarin wordt aangegeven hoe groot het risico voor de applicatie is wanneer de functie niet goed functioneert. Het bepalen van dit risico wordt uitgevoerd door de Product Owner samen met het ontwikkelteam. De beslissing van de klant hierin is erg bepalend.

Het risico wordt bepaald aan de hand van twee attributen:

  • Fout risico
  • Imago risico

Als de functie bijvoorbeeld erg ingewikkeld is en het risico van een fout grote impact heeft op de rest van de applicatie of het proces is het foutrisico erg groot. Dit krijgt dan een hoge risicowaarde.

Bij Imago risico is het dat wanneer de functie niet goed werkt dat dit gevolgen heeft voor het imago van de website/ organisatie.

Gevolgen voor het testen

Functies met een hoog risico zullen dus extra uitvoerig getest moeten worden. Er kan gekozen worden om voor deze functies een uitgebreid testplan te schrijven en zoveel mogelijk scenario’s af te dichten. Ook de inzet van verschillende soorten testen kan de kans op fouten extra verkleinen.

Voor functies met een laag risico zal niet uitgebreid ingezet worden op testen.

Deze verdeling zorgt ervoor dat de focus tijdens de testfase ligt op dat wat bepaald is als belangrijk met een hoog risico.

Per risicogebied zou een protocol ingezet kunnen worden. Bijvoorbeeld alle functies met risicowaardes 1 of 2 alleen kort checken. Alle functies met risicowaarde 5, uitvoerig testen, maken van testscenario’s, unit tests en bijvoorbeeld dat dit door meerdere mensen getest moet worden.

Voordelen van de inzet van de risico matrix

Door vooraf aan het daadwerkelijk bouwen en testen van de applicatie tijd te besteden aan de impact van het testen biedt dit later veel voordelen. De belangrijkste voordelen hebben we voor je opgenoemd:

  • Er wordt pragmatisch getest
  • Hoge risico functies krijgen extra aandacht
  • Tijd- en kostenbesparing bij functies die lager ingeschat zijn qua risico’s
  • Mogelijkheid ontwikkeling functies in te plannen aan de hand van geschatte risico
  • Product owner/klant heeft invloed op hetgeen uitvoerig(er) getest wordt.
  • Er is vooraf duidelijk welke functies intensiever getest worden en welke niet.
  • Vooraf helder welke functies belangrijk zijn voor het imago en dus extra aandacht nodig hebben tijdens het ontwikkel- en testproces.
  • Vooraf helder welke functies een technisch risico zijn en dus extra aandacht nodig hebben tijdens het ontwikkel- en testproces.

Aan de slag met de risico matrix

Download nu geheel gratis onze risicomatrix. Bij Suneco bepalen wij per project het testprotocol per risicowaarde. Dit is om deze reden niet opgenomen in deze risico waarde.

Download de Risico matrix

Conclusie

Met de inzet van de risico matrix wordt per functie het risico bepaald. Het is een goede methode om helder te krijgen waar de risico’s liggen. Op basis van deze methode kan het juiste testprotocol ingezet worden. Dit leid tot kosten besparing en een hogere kwaliteit van testen op risicovolle functies.

Meer achtergrond nodig? Neem contact met ons op

Deel deze pagina