Ohjelmistotestauksessa on kyse ohjelmiston laadun selvittämisestä. Tämä tarkoittaakin sitä, että ennen kuin yhtään testiä on kirjoitettu, pitää määritellä, mitä laatu on – se on myös hyvä filosofinen kysymys, jota kannattaa pohtia kokonaisvaltaisesti projektin suhteen. Onneksi on olemassa valmiita standardeja, kuten kansainvälinen standardi ISO 9126 ja TMap Next (luku 10), joissa määritellään, mitä ohjelmiston laatuominaisuuksilla (quality characteristics) tarkoitetaan. Kummatkin standardeista ovat laajalti tunnettuja ja ohjelmistoteollisuudessa käytössä.

TMap Next määrittelee kahdeksantoista ohjelmiston laatuominaisuutta: liitettävyys (connectivity), jatkuvuus (continuity), datan hallittavuus (data controllability), vaikuttavuus (effectivity), tehokkuus (efficiency), joustavuus (flexibility), funktionaalinen tarkkuus (functional accuracy) ja funktionaalinen kokonaisuus (functional completeness), infrastruktuurin soveltuvuus (suitability of intrastructure), ylläpidettävyys (maintainability), hallittavuus (manageability), suorituskyky (performance), siirrettävyys (portability), reusability (uudelleenkäytettävyys), turvallisuus (security), soveltuvuus (suitability), testattavuus (testability) ja käyttäjäystävällisyys (user-friendliness).

Kansainvälisen standardointiorganisaation ISO 9126 määrittelee kuusi isompaa laatukokonaisuutta: toiminallisuus (funktionaalisuus), luotettavuus (reliability), käytettävyys (usability), tehokkuus (efficiency), ylläpidettävyys  (maintainability) ja siirrettävyys (portability).

TMapin ja ISO 9126 standardeissa on sisällöllisesti paljon samaa, mutta myös eroja. Ehkä yksi tärkeimmistä eroista on se, että ISO 9126 pitää funktionaalisuutta sateenkaarikonseptina, jonka alle menevät esimerkiksi turvallisuuden ja soveltuvuuden testaus. TMapissa funktionaalisuus on jaettu kahteen osaan: funktionaaliseen tarkkuuteen ja funktionaaliseen kokonaisuuteen ja turvallisuus ja soveltuvuus ovat omia laatuominaisuuksiaan. Funktionaalisella tarkkuudella tarkoitetaan sitä, että järjestelmä toimii virheettömästi ja tarkasti ja funktionaalisella kokonaisuudella sitä, että kaikki toiminallisuuden osat tulevat testattua. Suurin osa testauksesta kuitenkin keskittyy toiminallisuuden testaamiseen, joten sen laatutavoitteiden oikeanlainen määrittely on yksi tärkeimmistä testauksen suunnitteluvaiheen tehtävistä.

Kumpikin standardi määrittelee, mikä on niiden määritelmä laadusta ja siihen liitettävistä ominaisuuksista – eli hyvin tehdystä tuotteesta. Laatu on siis osien summa, joka rakennetaan pala palalta. Ohjelmistotestauksen ytimessä on tietysti kliininen toiminallisuuden testaus, mutta sen ympärillä olevat muut palaset muodostavat ohjelmiston laadun. Ohjelmiston pitää olla toiminnallisuuden lisäksi ainakin käytettävä (usability), tehokas (efficiency), ylläpidettävä (maintainability) ja siirrettävä (portability). Nämä ovat muuten ne nimenomaiset laatuominaisuudet, jotka sattuvat löytymään kummastakin laatustandardista. 

Lähteet:

TMap Next: for result-driven testing (2006), Sogeti Nederland B. V. Chapter 10, Quality Characteristics.
ISO/IEC 9126 Software engineering — Product quality. (2011). 
Available: https://en.wikipedia.org/wiki/ISO/IEC_9126

 

Mitä pitäisi testata?

Tämä on yksinkertainen kirjoitus siitä, mitä pitäisi testata. ”No, miksei testattaisi kaikkea?” kysyy projektijohtaja ja testaajan leuka loksahtaa auki. ”Tästähän tuli sitten vähän pidempi projekti kuin ajattelin…”, testaaja manaa hiljaa itsekseen ja palaa työpisteensä ääreen. Miksi ei testata kaikkea? Koska aina voi testata enemmän. Testattavat asiat eivät lopu koskaan kesken.

Otetaan esimerkki: verkkokaupan sivuilla on 10 eri vetovalikkoa, jossa jokaisessa on 8 eri vaihtoehtoa. Mahdollisia testattavia kombinaatioita on siis 8*8*8*8*8*8*8*8*8*8 eli 8^10 eli yhteensä 1 073 741 824 kappaletta. Jos testaajalla menee yhden kombinaation testaamiseen aikaa 1 minuutti, kestää kaikkien mahdollisuuksien testaaminen 1 073 741 824 minuuttia, eli 17 895 698 tuntia, eli 745 654 päivää, eli 2043 vuotta. Kaikkien mahdollisuuksien testaaminen kestää siis kauemmin kuin on kirjoitettua maailmanhistoriaa, ottaen vielä huomioon, että testaaja ei nuku, syö tai kuluta aikaa mihinkään muuhun kuin testaamiseen. Siksi kaikkea ei voi testata.

Elämme rajattujen resurssien maailmassa (finite world). Tämä pitää erityisesti paikkansa liike-elämässä, missä kaikki resurssit ovat rajattuja: aika, raha ja jaksaminen. Nämä kolme tekijää (vähintään) ovat siis testausta rajoittavia tekijöitä. Tästä päästään johtopäätökseen, että ajan, rahan ja jaksamisen käyttöä pitää priorisoida. Siksi pitää laittaa tärkeysjärjestykseen ne asiat, mitä halutaan testata. Pitää siis valita testauksen laajuus (scope) ja syvyys (depth). Mutta miten tämä tärkeysjärjestys pitäisi sitten määrittää?

Kun tehdään ohjelmistotestausta liiketoiminnan tarpeisiin, pitää ensiksi määrittää liiketoiminnan kannalta tärkeimmät järjestelmät: mitkä osat tietojärjestelmistä ovat kriittisimpiä yrityksen bisnesprosesseille? Jos tietty osa tietojärjestelmästä kaatuu, mitkä ovat sen taloudelliset seuraukset yrityksen liiketoiminnalle? Kuinka suuri taloudellinen riski tietojärjestelmän kaatuminen on liiketoiminnalle? 

Otetaan esimerkki: Kuinka paljon tappiota verkkokaupan tilauksen toimimattomuus aiheuttaisi? Tämä voisi tarkoittaa tuhansien eurojen tappiota päivässä menetettyinä kauppoina. Riski liiketoiminnalle on siis suuri. Toisaalta esimerkiksi verkkokaupan tuotesuosittelujen epätarkkuus ei estäisi kauppoja ja sen seuraukset liiketoiminnalle ovat paljon pienempiä. Riski liiketoiminnalle on siis pieni.

Testaamisen priorisointi lähtee siis liiketoiminnallisesta riskistä ja sen määrittävät yrityksen liiketoiminnan johtajat. Tietojärjestelmissä on aina riskiä, eikä sitä voida koskaan poistaa täysin, edes täysipäiväisellä testaamisella. Bisnesprosessien laatijat arvioivat, mikä on hyväksyttävä riski liiketoiminnalle. He päättävät, mikä on hyväksyttävä riskin taso suhteessa testauksen kustannuksiin ja sen, milloin järjestelmä on valmis tuotantoon.

Ensimmäisessä esimerkissä mahdollisia testitapauksia oli yli miljardi. Testaamalla nämä kaikki testitapaukset saadaan sata prosenttinen toimintavarmuus ja liiketoiminnan riski on nolla. Mutta onko se riskin arvoista? Pairwise-testisuunnittelutekniikalla on mahdollista vähentää testitapausten määrä 149 testitapaukseen, samalla, kun riskin mahdollisuus nousee vain 0,2 prosenttiin. On liiketoiminnan tehtävä määrittää, onko tämä työmäärän lasku suhteessa riskiin riittävä. Testaaja vain testaa.

Lähteet:

Ole Chr. Hansen, Training Delivery Manager and Managing Consultant at Sogeti

TMap Next: for result-driven testing (2006), Sogeti Nederland B. V.

Pairwiser-tool, Inductive (https://inductive.no/pairwiser-tool)