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. 

Mitä on Ad hoc -testaus?

Sanapari Ad hoc tulee latinan kielestä ja se tarkoittaa "for this" - tätä varten. Sanaparia käytetään yleisesti etuliitteenä tapauksissa, joissa pitää nopeasti keksiä ratkaisu jotain tiettyä, usein yllättäen esiintynyttä, tapausta varten. Sama pätee myös Ad hoc -testauksessa.

Määritelmänsä mukaisesti Ad hoc -testaus on siis epäformaali prosessi, joka tehdään ilman suunnittelua tai dokumentointia. Sitä käytetään tyypillisesti, kun formaali, strukturoitu testaus on päättynyt, mutta järjestelmästä on silti löytynyt jokin bugi ja siitä pitäisi päästä nopeasti eroon ennen tuotantoon vientiä. Tällöin vian syy pitää löytää nopeasti, eikä testisuunnitteluun jää aikaa.

ISTQB Exam Certificationin (2016) artikkeli nostaa esiin viisi parasta käytäntöä (best practices) Ad hoc -testauksessa:

• Testaajalla on syvä tuntemus testattavasta järjestelmästä
• Testaus priorisoidaan koskemaan järjestelmän tärkeimpiä osia
• Voidaan tehdä kevyt, karkea testaussuunnitelma
• Testaaja hyödyntää työkaluja järjestelmän tehokkaassa tutkimisessa
• Havainnot dokumentoidaan, vaikka prosessia ei dokumentoitasi

Ad hoc -testauksen ehdottomana etuna ja ehkä ainoana syynä, jolla sen käyttöä voi hyväksytysti perustella, on sen kyky löytää vakavia virheitä nopeasti. Järjestelmän hyvin tunteva testaaja osaa tunnistaa järjestelmän vikaherkimmät osat ja kohdistaa testauksensa niihin osiin tehokkaasti. Ad hoc -testaus voi siten löytää virheitä, joita ei havaittu, eli ei siis testattu, formaalissa testausprosessissa. Tämä voi paljastaa mahdollisia virheitä itse testausprosessissa.

Kuitenkin Ad hoc -testausta pitäisi tehdä mahdollisimman vähän, sillä sen liiallinen käyttö kertoo strukturoimattomasta ja toimimattomasta testausprosessista, joka itsessään antaa syytä huoleen testauksen laadusta. Ammattimaisen ohjelmistotestauksen pitäisi olla aina formaalia, strukturoitua ja jäljitettävää. Siksi Ad hoc -testausta pitäisikin käyttää mahdollisimman vähän, tapauskohtaisesti, ad hoc.

Lähteet:
Ad hoc -testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ad_hoc_testing
"What is Ad hoc testing? Types, advantages and disadvantages". ISTQB Exam Certification, Saatavilla: http://istqbexamcertification.com/what-is-ad-hoc-testing/

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/