Miksi testataan?

Antti kertoi kirjoituksessaan “Feature managerin heiniä”, että projektissa oli käytetty varsin luovaa ja ketterää testitapausten päivittämistä. Kun projektin kannalta ikävään kohtaan testitapaus oli merkattu failiksi, muutettiin testiä siten, että tulokseksi tulikin pass.

Mikä onkaan testauksen tarkoitus? Voihan olla, että testitapaus oli vain niin spesifinen ja epätodennäköinen, että sen tuloksesta ei tarvitse välittää. Mutta silloin moista testitapausta ei olisi pitänyt edes alunperin laatia.

Kuinka monessa projektissa ylipäätään mietitään, että miksi jotakin testataan?

Cem Kaner toteaa mm. artikkelissaan What Is a Good Test Case, että testauksen tarkoitus tulee pitää mielessä testauksen suunnitteluvaiheessa. Miten muuten voisimme määritellä testauksen resurssit, työkalut, laatia testitapaukset jne?

Avataan Kanerin ajatuksia hieman. Testauksen tarkoituksen määrittelee testattavasta kohteesta, testauksen vaiheesta, kohteen ja käyttötarkoituksen kriittisyydestä jne. Näiden määrittelyjen jälkeen testauksen tarkoitus voi olla yksi tai useampia seuraavista:

• Teknisen tuen ja asiakaspalvelun kustannusten minimointi. Pyritään löytämään ne virheet, jotka aiheuttaisivat tekniseen tukeen paljon yhteydenottoja. Tällaisia voisivat olla esimerkiksi pankkien verkkopalvelut.
• Minimoida turvallisuudesta johtuvat syytteet. Onnettomuuteen tai loukkaantumiseen johtavien virheiden löytäminen on etusijalla. Lennonjohtosoftan kaatuminen voi aiheuttaa toimittajalle kylmää hikoilua.
• Tarkastus ohjelman spesifikaatiota vastaan. Ainoastaan spesifikaation vaatimukset testataan, muita mahdollisia kombinaatioita ei testata. Ei soveltune loppukäyttäjätuotteisiin 🙂
• Löytää tavat tuotteen käyttämiseen virheistä huolimatta. Vaikka jokin tapa ei toimisikaan spesifikaation mukaan, ei virhe ole kriittinen jos sen voi kiertää. Tähän ohjelmien käyttäjät ovatkin varmasti tottuneet.

Lista ei todellakaan ole täydellinen, mutta toimii esimerkinomaisesti. Jos Feature manager olisi ennen testausvaiheen alkua määritellyt testauksen tarkoituksen, ei a) epäkelpoja testitapauksia olisi suunniteltu tai b) olisi “vääriä” testituloksia.

Pysähdy hetkeksi, ennen kuin aloitat testauksen. Selvitä itsellesi ja tiimillesi, että miksi tässä oikein ollaan testaamassa. Turha riuhtominen jää paljon vähemmälle. Säästyy hermoja, aikaa ja rahaa. Lisäksi mahdollisuudet projektin läpimenoon kasvavat oleellisesti.

Onko teillä, blogin lukijat, täysin selvillä, että miksi asioita tehdään? Kertokaa hyviä tai huonoja kokemuksia.