De essenties van testrapportage - deel 2 - de testing story
Delen Printen E-mail

Hoewel sinds de 80-er jaren van de vorige eeuw veel is veranderd in softwareontwikkeling, is de essentie van testrapportage gelijk gebleven: adviseren over kwaliteit en risico’s. Dat betekent echter niet dat het opstellen van een goede testrapportage voor iedereen gesneden koek is. Het komt regelmatig voor dat collega’s op zoek zijn naar een goed voorbeeld van of sjabloon voor een testrapport in agile, waterval, devops, outsourced, standaard-pakket of nog een andere context. Ervaring leert dat achter zo’n vraag vaak een andere vraag schuilt: wat en hoe moet ik in mijn situatie rapporteren over testen?

In een aantal korte blogs ga ik in op die vraag, om te beginnen met drie korte publicaties die opgebouwd zijn rond citaten van blogs van Michael Bolton, welke naar mijn mening de essenties van rapporteren over testen heel goed beschrijven op https://www.developsense.com/blog/2012/02/braiding-the-stories/. Daarna volgen stukjes die ingaan op het toepassen van de basis van rapporteren in hedendaagse context zoals die van agile en devops teams.

Dit tweede basisartikel gaat over de testing story.

Het is handig om eerst het vorige artikel te lezen over de product story

Citaat van Michael Bolton

Level 2: To make the product story credible, tell the testing story. The testing story is about how we configured, operated, observed, and evaluated the product; what we actually did and what we actually saw. The testing story gives warrant to the product story; it helps our clients understand why they should believe and trust the product story we’re giving. The testing story is centred around the coverage that we obtained and the oracles that we applied. Coverage is the extent to which we’ve tested the program; it’s about where we’ve looked and how we’ve looked, and it’s also about what’s uncovered—where we might not have looked yet, and where we don’t intend to look. Oracles are central to evaluation; they’re the principles and mechanisms that allow us to recognize a problem. The product story will likely feature problems in the product; the testing story, where necessary, includes an account of how we knew they were problems, for whom they would be problems, and inferences about how serious the problems it might be. We can make inferences about the significance of problems, but not ultimate conclusions, since the decision of what matters and what constitutes a problem lies with the product owner. The product story and our clients’ reactions to it will influence the ongoing testing story, and vice versa.

Testing story

Waarop en hoe hebben we het product geëvalueerd en op basis waarvan konden we vaststellen of het product goed is?
In de testing story geven we antwoord op deze vragen door te vertellen wat we hebben getest, hoe we hebben getest, waar we diep hebben getest, waar we globaal hebben getest, waar we niet hebben getest, waar we wilden testen maar niet hebben gedaan en waar we sowieso niet van plan waren om te testen. Ook geven we aan welke bronnen we geraadpleegd hebben om te bepalen of wat we zagen goed was of niet. Bolton noemt dat ‘oracles’, wij kennen hiervoor ook het begrip testbasis. Welke bronnen hebben we hiervoor gebruikt? Dit kunnen documenten zijn, maar in de praktijk spelen ook andere bronnen een grote rol, zoals materiedeskundigen en voorbeelden van gelijksoortige producten.

De antwoorden op al deze vragen geven autoriteit aan de product story. De klant kan daarmee beoordelen of het juiste getest is en of er voldoende getest is. Het kan dus gebeuren dat de klant op basis van de ‘testing story’ besluit dat verder testen nodig is.

Wanneer we met testen tegen beperkingen aanlopen bij het vervullen van de opdracht van de klant om een gewenste testdekking te bereiken, geven we dat ook aan. Daar gaat het derde artikel in deze reeks over,the story about the quality of the testing’.

Kees Blokland

Meer informatie

Heeft u een vraag of wilt u een vrijblijvende afspraak maken? Laat hieronder uw gegevens achter, dan nemen wij zo snel mogelijk contact met u op. U kunt ons natuurlijk ook bellen:

+31 (0) 33 277 35 22 (Nederland)
+32 (0) 16 39 48 04 (België)

    Uw gegevens gebruiken wij alleen voor een correcte afhandeling van uw vraag. Lees voor meer informatie onze privacyverklaring.

    Hoe wij dat doen?
    Lees meer
    Focus
    Focus
    Vakmanschap
    Vakmanschap
    Kennisdeling
    Kennisdeling
    Persoonlijk
    Persoonlijk
    Lokaal
    Lokaal
    Oprecht
    Oprecht
    Plezier
    Plezier
    Meer
    Deze website is gerealiseerd door Webheads.

    Neem contact op!