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/