Tässä kirjoituksessa tarkastellaan esimerkkiä bugista, joka pysäytti Microsoftin Zune-mediasoittimet.

Oli joulukuun 31. päivä. Se päivä oli vuoden 366 päivä, karkausvuonna 2008. Ihmiset kävelivät iloisina kaupunkien kaduilla kuunnellen nappikuulokkeistaan Coldplayn Viva la Vidaa. Kunnes, tuona päivänä kaikki Microsoftin ensimmäisen sukupolven Zune-mediasoittimet sammuivat, eivätkä koskaan enää heränneet. 

Bugi johtui yhden ainoan numeron erosta loopissa, joka käsitteli vain 365 päivää. Sen seurauksena looppi ei koskaan pysähtynyt ja Zune jäätyi. Koodi näytti tältä:

// Tarkista karkausvuosi

year = ORIGINYEAR; /* = 1980 */
while (days > 365)
{
     if (IsLeapYear(year))
     {
         if (days > 366)
         {
             days -= 365;
             year += 1;

         }
     }
     else
     {
         days -= 365
         year += 1;
     }
}

Koodin ideana on ottaa päivien määrä kellosta ja laskea vuosi. Mitä koodissa oikeasti tapahtuu on se, että kun vuodessa on 366 päivää, ohjelma jää ikuiseen while-silmukkaan, eikä koskaan riko sitä. Ja koska tämä koodinpätkä oli Zunen käynnistysskriptissä, Zune jäätyi joka käynnistyksellä.

Lähde:
James A. Whitaker, "Exploratory Software Testing: Tips, Tricks, Tours and Techniques to Guide Test Design". (2009). Pearson Education. p. 256. 

Galen Framework (Responsiivisten web-sivujen layout-testaus)

Edellinen kirjoitukseni käsitteli Applitools Eyes -työkalua visuaalisen testauksen automatisointiin, mutta työkaluja siihen löytyy enemmänkin. Galen Framework on avoin ja vapaasti käytettävä framework, joka on kehitetty erityisesti web-sivujen layout-testien automatisointiin. Galenin lähdekoodi löytyy Githubista. Kattava dokumentaatio Galenin syntaksista löytyy Frameworkin kotisivulta.

Toisin kuin Applitoolsissa, missä testaus perustuu kahden erilaisen kuvatiedoston vertailuun, Galen Frameworkin ideana on kirjoittaa web-sivun layoutille vaatimukset (spesifikaatio, .gspec-tiedosto), jota vasten web-sivu ajetaan ja Framework ilmoittaa html-raporttina, läpäisikö vai reputtiko ulkoasu määritetyt vaatimukset. Galenin vaatimukset kirjoitetaan sen omalla kuvailevalla syntaksilla, mutta myös Javaa tai Javascriptia on mahdollista käyttää. Merkkauskieli on yksinkertaista ja helposti luettavaa, joten alkuunpääsy on suhteellisen helppoa.

Alla on esimerkki kuvitteellisesta Galen-spesifikaatiosta web-sivun "Koti" ja "Yhteystiedot" menu-buttonien ulkoasujen tarkistukseen:

// Alusta layout-elementit objekteiksi

@objects

    menu_home      id   home_btn

    menu_contact   id   contact_btn




// Aloita sektio (html-raporttia varten)

= Menu Section =
// Varsinaiset määrittelyt

    menu_home:

      visible

      height   64px

      width    64px

      text is  "Koti"

      aligned horizontally right menu_contact

 


     menu_contact:

        visible

        height   32px

        width    32px

        text is  "Yhteystiedot"

        aligned horizontally left menu_home

  

Aluksi siis määritellään web-sivun elementit niiden id:n, classin tai xpathin mukaan. Kun elementit on alustettu, voidaan niille asettaa erilaisia niiden ulkomuotoon liittyviä vaatimuksia. Edellisessä koodinpätkässä Koti-nappulalle asetetaan vaatimukseksi, että sen korkeus ja leveys ovat 64 pikseliä, nappulan teksti on "Koti" ja se on horisontaalisesti linjassa viereisen nappulan kanssa. Jos jokin näistä ei pidä suorituksen aikana paikkaansa, testi epäonnistuu.

Yksi Galen Frameworkin hyvistä puolista on mahdollisuus ajaa nopeasti ja helposti samoja vaatimusmäärittelyjä (.gspec-tiedostoja) eri selaimilla ja resoluutioilla. Sama testi voidaan ajaa yhdellä komennolla Firefoxilla, Chromella tai Internet Explorerilla ja samalla voidaan asettaa eri ajettavat resoluutiot. Näin esimerkiksi mobiilikäyttöön suunniteltu resoluutio voidaan tarkastaa samalla komennolla (tämän hyvin toimiminen voi tosin vaatia hyvin suunniteltua vaatimusmäärittelyä).

Mihin siis Galen Framework soveltuu erityisen hyvin ja mihin taas ei? Galen Framework on varteenotettava työkalu layout-testauksen automatisoinnille. Sen hyvinä puolina ovat ehdottomasti sen avoimuus ja ilmaisuus, sekä vaatimusmäärittelyn tarkkuuden. Tämä vaatimusmäärittelyiden tarkka kirjaaminen on tosin myös työlästä, eikä Galenia siksi kannata yrittää käyttää joka tilanteessa. Galenin testit ovat kuitenkin suhteellisen nopeita suorittaa, sillä raskaita kuvanvertailu-operaatioita ei suoriteta. Vain hullu (ruot. galen, galet, galna) jättäisi Galenin kokeilematta.

Lähteet:
Galen Framework, saatavilla: http://galenframework.com/
Galen Framework GitHubissa: https://github.com/galenframework/galen
Galen Frameworkin dokumentaatio ja syntaksi: http://galenframework.com/docs/all/

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