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)
