Workshopin ajatuksia testauksen raportoinnista

TestausOSYn Oulun osasto järjesti viime viikolla workshopin testauksenhallinnan asioista. Sain toimia tapahtuman ja keskustelun vetäjänä. Kiitoksia vielä osallistujille vilkkaasta keskustelusta. Eniten juteltiin testauksen raportoinnista. Käydään lyhesti läpi osallistujien näkemyksiä asiasta.

Aivan aluksi puhuttiin testauksen raportoinnin tehtävistä, ts. mitä asioita raporttien avulla haluttiin selvittää. Tässäpä listausta:

  • Testien kattavuus eli code coverage
  • Ohjelmiston testattavuus
  • Testien ajamiseen käytetty aika
  • Tavoitteiden seuranta
  • Testauksen tehokkuuden seuranta
  • Virheiden läpivuoto projektin aikana
  • Virhekertymä projektin eri vaiheissa
  • Testitapausten pass/fail-suhde
  • Verifioidut vaatimukset
  • Virheiden vakavuus
  • Tuotteen maturiteetti

Näiden raporttivaatimusten lisäksi todettiin, että käsintehtävä raportointi on tylsää ja vie kohtuuttoman paljon aikaa. Siksi raporttien pitäisi tulla oikeiden töiden sivutuotteena.

Siinä on erilaisia toiveita melkoisesti. Ja tuossa tuskin on lähellekään kaikki. Ovatko kaikki raportit kaikissa tapauksissa mielekkäitä? Tuskin. Miten testauksen raportointi tulisi rakentaa?

Kaikki lähtee tietenkin tuotteen käyttötarkoituksesta ja tuotekehityksen toimintatavoista. On täysin eri asia raportoida ydinvoimalan ohjausjärjestelmän kuin tietokonepelin testauksesta. Vastaavasti vesiputousmallia käyttävien yritysten raportointitarpeet lienevät oleellisesti erilaisia ketterillä menetelmillä kehittäviin yritykseen nähden.

Riippumatta toimintatavoista ja tuotekehitettävästä tuotteen käyttötarkoituksesta, testauksen raportoinnin tarkoitus voidaan palauttaa kahteen peruskysymykseen:

1. Raporttien on kyettävä antamaan tietoa tuotteen maturiteetista ja pystyttävä arvioimaan mahdollisten virhetilanteiden vaikutuksia *)

2. Raportin perusteella pitää voida tehdä aikataulutukseen liittyviä päätelmiä eli raportin perusteella voidaan vastata kysymykseen “Milloin olemme valmiita?”

Kun raportti kertoo sopivalla tavalla mitä on testattu, miksi on testattu ja miten on testattu, saadaan testaus tukemaan tuotteen koko elinkaarta. Tämä helpottaa paitsi laadunvarmistuksen, myös kehityksen ja tuotetuen keskittymistä oikeisiin asioihin. Loppukäyttäjät kiittävät.

*) Tapaamisessa todettiin, että maturiteetti itsessään voi olla hankala mittari käyttää. Maturiteetin määrittelylle on hirmuinen määrä vaihtoehtoja. Ensi viikon tekstissä Antti pyörittelee eri metriikoita vaihtoehdoksi maturiteetille.