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 derde artikel gaat over zijn uitleg van de the story about the quality of the testing. Het is handig om eerst de vorige twee artikelen te lezen, over de product story en de testing story.
Citaat Michael Bolton
Level 3: To make the testing story credible, tell a story about the quality of the testing. Just as the product story needs warrant, so too does the testing story. To tell a story about the quality of testing requires us to describe why the testing we’ve done has been good enough, and why the testing we haven’t done hasn’t been so important so far. The quality-of-testing story includes details on what made testing harder or slower, what made the product more or less testable, what the risks and costs of testing are, and what we might need or recommend in order to provide better, more accurate, more timely information. The quality-of-testing story will shape and be shaped by the other two stories.
Gaat de testing story over de dekking die is bereikt, the story about the quality of the testing beschrijft de problemen die zijn ervaren met het bereiken van die dekking of problemen die het bereiken van de gewenste dekking nog in de weg staan. Dit gaat vaak over de testbaarheid van het product, de testomgeving en testdata: hoe goed kunnen we testen en tegen welke kosten? Daarnaast kan het zijn dat we tijd, tools, spullen, testers of expertise missen. We bespreken dat met de klant als de belanghebbende. De klant kan besluiten om een deel van de problemen te laten oplossen. Zo niet, dan accepteert de klant het risico of de kosten die een gevolg zijn van de beperkingen in de te bereiken testdekking.
De story about the quality of the testing vind ik een lastig deel van de testrapportage. Dat komt omdat het vaak gaat over zaken die ik niet zelf in de hand heb. Wat ik wel zelf kan doen is knelpunten altijd meteen onder de aandacht bij de testklant te brengen: om hulp te krijgen of om de verwachtingen voor het maximaal te bereiken testresultaat alvast bij te stellen.
Hiermee ronden we deze reeks over de basis van testrapportage af. Er resten nog genoeg vragen, zoals hoe ziet zo’n testrapport er eigenlijk uit en hoe pas je het toe in agile of devops teams? We werken aan meer artikelen over testrapportage die onder meer daarop ingaan. Houd de Polteq website in de gaten!
