Mitä tarkoitetaan mustalla tai valkoisella laatikolla testauksessa? Aloitetaan laatikoiden määritelmillä.

Musta laatikko (Black-box) on järjestelmä, jonka sisäinen toimintalogiikka on tuntematon. Pystymme havaitsemaan järjestelmään liitetyt sisääntulot (input) ja siitä lähtevät ulostulot (output), muttemme tiedä, miten  ulostuloa on tässä välissä muokattu. Usein pystymme päättelemään sisään- ja ulostulon eroista, mitä muutoksia järjestelmä tekee sisääntuloon, muttemme voi varmuudella sanoa, miten tai millä logiikalla ne on toteutettu.

Valkoinen laatikko (White-box) on järjestelmä, jonka sisäinen toimintalogiikka on tunnettu. Meillä on tietoa järjestelmän toteutuksen teknisistä yksityiskohdista ja sen logiikkaa kuvaava tekninen dokumentaatio. Logiikkakuvauksen avulla tiedämme täsmälleen, miten tai millä logiikalla järjestelmä muokkaa sisääntuloa.

Entä näiden laatikoiden testaus? Mitä black-box & white-box testing tarkoittavat käytännössä ja mitä eroja niillä on?

White-box testauksessa (tunnetaan myös nimellä Structure-based testing) järjestelmän sisäisestä rakenteesta johdetaan dynaamisesti testicaset, kun taas black-box testauksessa meillä on käytössä vain tiettyjä, järjestelmän ulkoisiin ominaisuuksiin nojaavia, spesifejä testejä. White-box testaus on siis testaajan kannalta monta kertaa mukavampaa ja tehokkaampaa, koska tiedämme, miten järjestelmä toimii, eikä sitä tarvitse arvuutella. Black-box testauksessa olemme täysin omillamme, eikä meillä ole mitään varmuutta siitä, että käyttämämme testit suorittavat kaiken ohjelmakoodin - vaikka maailman osaavin testausammattilaisten tiimi black-box testaisi mitä tahansa järjestelmää, on silti hyvin mahdollista, että peräti 70 prosenttia kaikesta koodista ei suoritettaisi kertaakaan! (Mitchell & Black, 2015)

Boris Beizer kirjoittaa kirjassaan Software Testing Techniques (ITC Press, 1990) yleisiä sääntöjä liittyen ohjelmakoodin suoritukseen ja bugien todennäköisyyteen:

1. Testaamatta jätetty koodinpätkä jättää järjestelmään bugeja. Bugien määrää voidaan arvioida kaavalla: testaamaton koodi * bugien todennäköisyys
2. Ohjelman yleisimpien suoritusteiden (pathien) testaus, varsinkin yksikkötestitasolla, ei ole niin tärkeää kuin harvinaisten suoritusteiden, koska järjestelmän toiminta kokonaisuudessaan testataan vielä myöhemmin järjestelmätasolla.
3. Logiikkavirheet tai logiikan sumeus (fuzzy thinking) ovat kääntäen verrannollisia pathin suorittamisen todennäköisyyteen.
4. Ohjelmoijat eivät useinkaan osaa arvioida ohjelman käyttämien pathien suoritustodennäköisyytttä - vain analyysi kertoo, mitä patheja suoritetaan todennäköisimmin.
5. Koodisegmenttien tärkeyden arviointi on subjektiivista ja voi johtaa virheisiin. Ohjelmoija voi olla niin ylpeä kauniista koodistaan tai tekemästään monimutkaisesta algoritmista, että testaa sen monta kertaa, mutta jättää testaamatta yksinkertaisen for-loopin, koska ajattelee "Mikä noin yksinkertaisessa lauseessa voi mennä pieleen?".

Listassa on ainakin muutama hyvä syy, miksi testaajan on tärkeää tietää suoritetun koodin määrä ja miksi järjestelmiä pitäisi aina testata white-box testauksella - testaus on siis sitä helpompaa, mitä enemmän tietää ohjelman suorittamista reiteistä tai koodin määrästä. Mustat laatikot kannattaa suosiolla jättää lentokoneisiin.

Lähteet:
Mitchell, Jamie L. & Black, Rex. "Advanced Software Testing, Vol. 3. Second Edition". (2015). p. 24-26. Rocky Nook.
Beizer, Boris. "Software Testing Techniques". (1990). ITC Press.

Paljonko bugit maksavat?

Paljonko virheet koodissa voivat pahimmillaan maksaa? Tämähän on se syy, miksi testataan - jotta vältyttäisiin katastrofeilta ja miljoonien eurojen vahingonkorvauksilta. Tiedämme, että määrittelyvaiheessa löydetyn bugin hinta on keskimäärin 100€, laatutestausvaiheessa 1500€  ja tuotannossa 10 000 euroa (Leon, 2015). Toisten arvioiden mukaan hintaluokka kasvaa aina tason noustessa yhdellä nollalla. Joka tapauksessa kallista. Ja aina silloin tällöin epätodennäköisiltäkin vaikuttaneet riskit voivat realisoitua ja pahin tapahtua.

Tähän alas olen kerännyt muutaman esimerkin projekteista, joissa testaus on pettänyt ja kaikki on mennyt pahimman laatuisesti pieleen:

- Ariana 5 avaruusraketti:
Ariane 5:n ensimmäinen testilento 4.6.1996 päättyi näyttävään räjähdykseen 37 sekuntia lähtönsä jälkeen, koska sitä ohjanneessa ohjelmistossa oli bugi  - tyyppimuunnos 64-bittisestä liukuluvusta (floating point number)16-bittiseksi etumerkilliseksi kokonaisluvuksi (signed integer) aiheutti virheen, koska liukuluku oli liian suuri esitettäväksi 16-bittisenä etumerkillisenä kokonaislukuna.
BUGIN HINTA: Raketin lähdön hinnaksi oli arvioitu 165 - 220 miljoonaa dollaria (Wikipedia, 2016)

- Toyotan takaisinveto:
Elokuussa 2009 neljää matkustajaa kuljettanut Toyota Lexus ES350 alkoi yllättäen kiihdyttää yli 160 km/h nopeuteen, kunnes ajoi ulos tieltä, tappaen matkustajat. Toyotan mukaan autossa oli ohjelmistovirhe, joka aiheutti lagia auton lukituksenestojärjestelmässä. Toyota päätyi vetämään maailmanlaajuisesti takaisin yli 9 miljoonaa autoa vuonna 2010. 
BUGIN HINTA: Takaisinvedot, vahingonkorvausvelvoitteet ja markkinointikulujen arvioidaan maksaneen Toyotalle jopa 3 miljardia dollaria. (Leon, 2015)

-Knight Capital:
Vuonna 2012 pörssivälitysyhtiö Knight Capital otti käyttöön uuden osakkeiden välitysohjelmansa. Valitettavasti ohjelman osto- ja myyntialgoritmi toimi hieman kehnosti, se nimittäin osti osakkeita pyydetyllä hinnalla, mutta myi ne välittömästi 15 prosenttia halvemmalla.
BUGIN HINTA: Vääriä välityksiä tapahtui 40 kertaa sekunnissa, 2400 kertaa minuutissa ja ne polttivat rahaa Knight Capitalilta lähes 440 miljoonaa dollaria. (Gang, 2016)

Tästä voi ottaa vain opiksi. Testaa tai itke.

Lähteet:
Ariane 5, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ariane_5
Janet Leon, "The True Cost of a Software Bug: Part One". 28.02.2015. Celerity. Saatavilla: http://blog.celerity.com/the-true-cost-of-a-software-bug
Gang, T. Penn State University. Saatavilla: http://www.cse.psu.edu/~gxt29/bug/softwarebug.html