Hoe bepaal je testprioriteiten

Ik heb veel leuke gesprekken over het simpel toepassen van testen, maar het gaat eigenlijk altijd buiten deze site om. En als er eens iemand reageert via twitter met een heel relevante vraag, dan mag daar zeker een blogje aan gewijd worden!

Eerst even het verhaal tot nu toe.

Vraag: @sander_mol bedankt voor de tips op http://sandermol.com/acceptatietesten/ … Hoe ga je om met de prioriteiten (moscow) tijdens acceptatie?

Reactie: Dank je. Je wilt met software de belangrijkste bedrijfsactiveiten ondersteunen. Ik zou daar eerst een top 5 van maken.

Vraag: @sander_mol hoort deze taak thuis bij teststrategie of de inhoud van acceptatietesten?

Reactie: Eerst bedrijfsbelangen uitsplitsen (http://sandermol.com/kwaliteit) , dan verdelen in systeem- en acceptatietest. Blogje volgt!

De dagelijkse praktijk bij Meeùs

Het leuke is dat ik precies op dit moment bezig ben met deze oefening, voor alle afdelingen bij Meeùs. Die oefening is dus het bepalen hoe we de belangrijkste bedrijfsactiviteiten ondersteunen. Al die afdelingen dragen bij aan de doelstelling van Meeùs, wat je kunt samenvatten als ‘het wegnemen van zorgen over risico’s van particuliere en zakelijke klanten’. Zo moet de Schade zorgen voor een efficiënte en klantvriendelijke afhandeling van schades. Daarvoor is er een website waar klanten zelf hun schadegegevens kunnen invullen. En is er een backoffice systeem waar taken op de agenda worden gezet.

Kwaliteitscategorieën

Voordat we onderscheid kunnen maken tussen systeemtest en acceptatietest, moeten we eerst bepalen welke kwaliteitscategorieën van belang zijn. Bijvoorbeeld:

gebruiksvriendelijkheid Gebruiksvriendelijkheid
We willen dat de klant op een gebruiksvriendelijke manier door de registratie heen wordt geholpen. De bewoording en mogelijkheden moeten sturing geven, zonder dat het beperkend voelt.
functionaliteit Functionaliteit
We willen dat de taken in de backoffice goed verdeeld worden, dat de voortgang goed wordt geregistreerd en dat er dus zéker geen taken verdwijnen door gebruikersfouten. Het moet dus robuust functioneren.
inpasbaarheid Inpasbaarheid
We willen dat het werken met agenda’s goed aansluit bij onze bestaande processen. Een voorbeeld van een bevinding zou kunnen zijn dat het systeem de taken niet op dezelfde dag kan inplannen, terwijl dit bij ons bedrijf regelmatig voorkomt.

Systeemtesten en acceptatietesten

Pas als je aan alle afdelingen hebt gevraagd naar dit soort risico’s, kun je een verdeling gaan maken tussen systeemtesten en acceptatietesten. In de bovenstaande drie voorbeeldjes zou de robuuste taakafhandeling in de systeemtest plaatsvinden. De gebruiksvriendelijke klantschermen en de inpasbaarheid van de agenda’s zijn typische acceptatietesten.

Bij Meeùs hebben we acht prioriteiten bepaald voor de schade afdeling. Op basis van complexiteit hebben we daar steeds tussen de 30 en 300 minuten aan testtijd aan gekoppeld, zodat er een (regressie)test van twee dagen ontstond.

En daarmee hebben we dus een teststrategie, completer en beter herleidbaar naar het bedrijfsdoel dan de meeste andere bedrijven. Succes!

door Sander Mol op maandag 9 december 2013 in Van alles

Plaats als eerste een reactie!

Naam*: E-mail*: