Nykypäivänä suuri osa uusista sovelluksista on appeja, joita käytetään älylaitteilla, kuten kännyköillä ja tableteilla, perinteisten pöytätietokoneiden sijaan.

Tämä asettaa omat vaatimuksensa testaukselle, sillä testattavien laite- ja käyttöjärjestelmäparien määrä lähestyy erityisesti Googlen Android-ekosysteemissä ääretöntä. Applen iOS-ekosysteemi on laitelukumäärältään helpommin hallittavissa, mutta siinäkin on omat niksinsä, miten laitteilla saadaa testit pyörimään sujuvasti. Windows-phonet voidaan jättää testaamatta (kirjoittajan mielipide, joka voidaan perustella laitteiden käytön vähäisyydellä). Miten siis saadaan  testattua sama mobiilisovellus mahdollisimman monella eri laitteella luotettavasti, nopeasti ja vielä mahdollisimman edullisesti?

Testausorganisaatio on siis ison valinnan edessä. Testausorganisaatio voi joko:

• rakentaa oman laitelabransa 
• käyttää pilvipalvelun laitelabraa

Kummassakin vaihtoehdossa on sekä hyviä että huonoja puolia. Käydään nyt läpi laitelabran rakentaminen ja seuraavassa kirjoituksessa pilvipalvelun käyttö (TestObject).

Laitelabra on tila, jossa mobiililaitteet puksuttavat testejä läpi. Laitteet sijaitsevat tavanomaisesti siististi riveissä ja niiden takaa kulkee suuri piuhaviidakko, joka yhdistää ne sisäverkkoon ja syöttää niille sähköä. Laitteista vastaava työntekijä asentaa säännöllisin väliajoin uusimpia mobiililaitteita räkkiin ja korjaa tai asentaa uudelleen kaatuneet laitteet. Erilaiset ohjelmistopäivitykset, kuten vaikka uusi Android-käyttöjärjestelmän versio, saattavat rikkoa kännykän yhteensopivuuden ja tiputtaa sen testiympäristöstä.

Labran ylläpitotyön määrä on suuri. Uusimpien laitteiden hankintaan käytettävä rahamäärä on suuri.  Etuina on täysi varmuus testauksen oikeellisuudesta ja erilaisten tavanomaisuudesta poikkeavien testitapausten toteuttaminen. Testilabra on strateginen resurssi, jota voidaan hyödyntää myös organisaation muissa sisäisissä testeissä.

Laitelabran rakentaminen on strateginen resurssi, jonka pystyttämistä pitäisi miettiä liiketoiminnan näkökulmasta. Labran rakentaminen ja ylläpito vaatii paljon resursseja, joten sen tuottama lisäarvo pitää pystyä liiketaloudellisesti perustelemaan suhteessa pilvipalvelun käyttöön. Pitää kysyä, mitä lisäarvoa oman laitelabran rakentaminen tuo testaukseen ja jos tuo, onko se lisäarvo riittävää - uskaltaisin sanoa, että pienten organisaatioiden on kannattavampaa ainakin aloittaa pilvipalvelun kokeilemisella ja vasta sitten siirtyä oman laitelabran suunnittelemiseen.

Lähteet:
TestObject, kotisivut: https://testobject.com/

Testrail (Kuinka ylläpitää ja organisoida testejä?)

Ammattimainen testaus järjestelmällistä, toistettavaa ja jäljitettävää. Käytännössä tämä tarkoittaa sitä, että testitapaukset dokumentoidaan selkeästi ja ymmärrettävästi yhteen paikkaan, josta niihin päästään helposti käsiksi. Testien dokumentaatio elää kuitenkin koko ajan uusien ohjelmistoversioiden myötä ja testicaset vanhentuvat nopeasti. Testicaseja onkin jatkuvasti päivitettävä vastaamaan uuden ohjelmistoversion vaatimuksia ja niiden ylläpito käy testaajalle nopeasti työlääksi, mikäli dokumentointiprosessi on tehty liian monimutkaiseksi.

Tähän tarpeeseen vastaa TestRail, joka on testicasejen hallintaan tarkoitettu ohjelmisto. Testrailissa voi nopeasti kirjoittaa testitapausten kuvauksia, asettaa niille automaattisesti tunnistettavan id:n (#00001), asettaa kategorian (unit test, system test, acceptance test) ja vakavuuden (low, medium, high) ja tyypin (esim. manuaalinen tai automatisoitu) ja tilan (valmis, kesken, päivitettävä). Testicaset jaotellaan test suitejen mukaan loogisiin kokonaisuuksiin (test suiteihin), joista ne on helppo löytää. Testicaseja voi myös tarkastella testin suorittamisen onnistumisen mukaan katsomalla testirunien tuloksia. TestRailissa on integraatiomahdollisuudet muihin yleisimpiin testaus- tai hallinnointiohjelmistoihin, kuten Jiraan, jos haluaa esimerkiksi määrätä tietyt testicaset tai testeistä löydetyt bugit tietylle henkilölle ratkaistavaksi.

Testitapaukset kuvataan jaettuna selkeisiin askeleisin, joiden pitää olla täysin eksplisiittisiä, eli vain yhdellä tavalla ymmärrettävissä. Kuvausten kielen pitäisikin olla mahdollisimman yksityiskohtaista ja kuvata asioita niin tarkkaan, että erehtymisen vaaraa ei ole. Jos askeleiden kuvaukset ovat liian korkealla abstraktiotasolla, kuten esimerkiksi "Täytä kyselylomake ja siirry seuraavalle sivulle", ne ovat liian epätarkkoja. Alemman tason kuvaus, kuten "Valitse 'Kotimaa'-nimisestä vetovalikosta valinta 'Finland' ja klikkaa 'Seuraava'-painiketta", on eksaktimpi ja vähentää väärinymmärrysten määrää.

TestRail on hyödyllinen testitapausten organisointiin ja dokumentointiin. Jotta sen käytöstä saataisiin kaikki mahdollinen hyöty, pitäisi testitapauksia ylläpitää ja päivittää aktiivisesti. Vaarana on, että testitapausten kuvaukset TestRailissa happanevat (go sour), samalla kun testiautomaation testitapaukset elävät omaa elämäänsä. Tällä hetkellä erilaiset CI-ratkaisut, kuten esimerkiksi automaattisten testitapausten tilan tarkastaminen suoraan Jenkinsistä ja testiautomaation lähentyessä luonnollista kieltä, testitapausten ja ajojen kirjaamisen ulkopuoliseen järjestelmään voi kyseenalaistaa. Erittäin ketterien tiimien ei välttämättä kannata laittaa resursseja siihen, vaan hyödyntää testausprosessissa syntyvää metadataa testitapausten ylläpitoon.

TestRailin kotisivut:
http://www.gurock.com/testrail/

Päivä, jona Zune pysähtyi (Esimerkki kuolettavasta koodista)

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/

Applitools Eyes (Visuaalisen testauksen automatisointi)

Usein testiautomaatiossa keskitytään funktionaaliseen testaukseen. Testiautomaatio-caset rakennetaan suorittamaan ohjelman vaatimusten mukaista toiminnallisuutta. Tärkeintähän on, että ohjelma toimii niin kuin pitääkin ja jos toiminallisuus on kunnossa, niin ohjelma on valmis tuotantoon, eikö niin? Vai onko sittenkään? Minkä näkökulman jätämme testaamatta? Sen, miltä ohjelma näyttää visuaalisesti.

Visuaalisen testauksen tarkoitus on löytää bugit, jotka syntyvät UI-komponentteja päivittäessä. Visuaalinen testaus vie manuaalisesti paljon aikaa ja sen onnistuminen riippuu testaajan silmän tarkkuudesta. Gregory Goldshteyn (2016) listaa artikkelissaan neljä kohtaa, jotka muodostavat hänen visuaalisen testauksen checklistinsa. Nämä neljä kohtaa ovat:

- Varmista, että jokainen UI-komponentti on oikean kokoinen, muotoinen, värinen ja oikeassa paikassa
- Varmista, etteivät UI-komponentit ole päällekkäin tai peitä toisiaan
- Varmista, ettei ruutukoon  muutos riko UI-komponentteja (esim. tabletit, kännykät, pöytäkone)
- Varmista, että kaikki kuvat näkyvät oikein

Miten voimme hyödyntää testiautomaatiota web-sivun visuaalisessa testaamisessa? Applitools Eyes (https://applitools.com/) on visuaalisen testauksen automatisointiin tarkoitettu työkalu, jota käytetään web-sovelluksena. Sovelluksen saa toimimaan esim. Chromeen ladattavana Applitools Eyes Express -lisäosana (https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh). Web-käyttöliittymä on yksinkertainen ja helppokäyttöinen, kuten myös lisäosan käyttäminenkin. Lisäosan toiminnolla voi ottaa kuvan aukiolevasta web-sivusta baselineksi, ja toisella kerralla otettua kuvaa verrataan baselineen. Kuvien erot näytetään vierekkäin, erot korostettuina. Jos kuvissa on eroja (eli uusi versio web-sivusta ei vastaa alkuperäistä), testi näyttää punaista ja epäonnistuu. Testicaseihin voi asettaa erilaisia suoja-alueita, esim. dynaamisesti vaihtuvaa sisältöä, kuten mainoksia, varten. Erojen huomaamisen tasoa voi säätää tiukasta löyhään tai sen voi asettaa tutkimaan vain sivun layoutin säilymistä.

Vaikka Applitools Eyes tuntuukin helpottavan visuaalisen testauksen työurakkaa, testicasejen suunnittelu (eli ensimmäiset ajot määritelmän asettamiseksi) vievät aikaa ja niitä pitää päivittää usein. Applitools on kuitenkin hyvä huomaamaan ne pienetkin erot tai virheet, mitkä helposti menevät ihmisiltä ohi. Sen käytön voidaan katsoa vähentävän graafisten virheiden määrää sovelluksen tulevaisuudessa. No, katsotaan. Kauneus on katsojan silmässä.

Lähteet:
Applitools Eyes, Saatavilla: https://applitools.com/
Applitools Eyes Express -lisä Google Chromeen, Saatavilla: https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh
"Review of Visual vs. Functional Testing with Applitools", Gregory Goldshteyn, 12.01.2016. Saatavilla: https://www.linkedin.com/pulse/review-visual-vs-functional-testing-applitools-gregory-goldshteyn
Robot-AppEyes, Robot Framework moduuli Applitoolsille, Saatavilla: http://navinet.github.io/Robot-AppEyes/

Ei savua ilman tulta (Mitä on smoke testing?)

Smoke testing, joka tunnetaan myös nimillä confidence testing, sanity testing, build verification test (BVT) ja build acceptance test, tarkoittaa ohjelmiston valmistavaa testausta ennen julkaisua, jonka tarkoituksena on varmistua siitä, että ohjelmiston tärkeimmät ominaisuudet toimivat. Smoke-testaus suunnitellaan siten, että testicaset kattavat järjestelmän tai sen moduulin kriittisimmän toiminnallisuuden. Mutta mikä on se syy, miksi smoke-testausta tehdään?

Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.

Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.

Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki  ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.

Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.

Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software)