Author: ohjelmistotestaus

Mitä tiedät suunnistuksesta? Tai mitä tuosta lajista tulee mieleen? Kenties koulun liikuntatunnit. Kenties radiolähetyksen maastossa kuiskaileva selostaja. Jos olet suunnistanut, todennäköisesti muistisi lokeroista löytyy joku makea pummi. Olen itse eksynyt suunnistusporukoihin ja laji on vienyt siinä määrin mennessään, että edessä on elämäni kolmas Jukolan viesti. Tässä blogisarjassa kerron harrastelijan havaintoja suunnistuksesta ja liitän ne ammattimaiseen ohjelmistotestaukseen.

Yllä on kartta Oulun alueen kuntorasteilta kesältä 2017. Kartasta puhuimmekin jo edellisessä artikkelissa. Nyt haluan kiinnittää huomiosi rasteihin. Niitä on 19 kappaletta ja niistä muodostuu suunnistusrata. Reitti, jolta kaikki rastit olisi tarkoitus löytää ja tehdä tämä vieläpä mahdollisimman nopeasti.

Suunnistuksessa ratamestari usein etsii rasteille sellaiset paikat, jotka eivät ole ihan helpoimmasta päästä löytää. Lisäksi rastien suoritusjärjestys on mietitty niin, että rastivälit aiheuttavat suunnistajalle jotain ylimääräistä päänvaivaa. Kahden rastin välillä voi olla haastavaa maastoa ja lähestymissuunta ei ainakaan helpota rastin löytämistä.

Ajatellaan, että nämä rastit ovat ohjelmistomaailmassa ne testattaviksi sovitut toiminnallisuudet. Paikat, joissa sinun tulee ohjelmistossa vierailla testauksen aikana. Sijaitsevatko rastit riittävän haastavissa paikoissa ja missä järjestyksessä testaaja nuo rastit käy läpi? En tunne montaakaan testaajaa, joka itse asettaa itselleen ylimääräisiä haasteita. Yllättäen ratamestarina toimiikin paras kaveri, joka päästää testaajan sieltä missä aita on matalin.

Testaajan suunnistuskoulun opetus 2: Testaajan on rakennettava itselleen mahdollisimman haastava rata. Ystävällinen ratamestari jää lopulta laiskottelusta kiinni.

Testaajan suunnistuskoulu kokonaisuudessaan:

1. Kartta tyhjää täynnä
2. Juonikas ratamestari
3. Oletko kuivan kesän orava?
4. Apinoiden armeija
5. Viestistä kattavuutta 2.7.2018
6. Mestariksi kertaamalla 9.7.2018

Mitä tiedät suunnistuksesta? Tai mitä tuosta lajista tulee mieleen? Kenties koulun liikuntatunnit. Kenties radiolähetyksen maastossa kuiskaileva selostaja. Jos olet suunnistanut, todennäköisesti muistisi lokeroista löytyy joku makea pummi. Olen itse eksynyt suunnistusporukoihin ja laji on vienyt siinä määrin mennessään, että edessä on elämäni kolmas Jukolan viesti. Tässä blogisarjassa kerron harrastelijan havaintoja suunnistuksesta ja liitän ne ammattimaiseen ohjelmistotestaukseen.

Suunnistajan tärkein työkalu on kartta. Kartta kuvaa suunnistusmaaston erinäisin merkein. On maastotyypit, vesistöt, maaston muodot ja erilaiset kiintopisteet. Paljon muutakin toki on, jokaista karttamerkkiä ei liene syytä tässä luetella. En taida edes kaikkia karttamerkkejä tuntea.

Suunnistustapahtumasta riippuen karttojen taso vaihtelee. Ympäri Suomen järjestettävissä kunto- ja iltarastitapahtumissa vastaan voi tulla monenlaista tekelettä. Käteen ilmestyvä kartta voi olla tarkemmin tehty tai sitten vähän sinne päin. Voi olla, että kartta on päivitetty ihan tuoreeltaan tai sitten ei ainakaan pariin vuoteen.

Virallisemmissa kilpailuissa, kuten Jukolassa, muoveista löytyykin sitten ihan eri tason tekele. Näitä karttoja on hiottu vuosia ja niihin on panostettu paljon. Kilpakartan tärkeimmät ominaisuudet ovat toisaalta tarkkuus ja toisaalta luettavuus. Nämä eivät tietenkään kulje käsi kädessä, vaan kyse on sopivasta tasapainosta.

Kartta siis toisinsanoen vastaa olemassa olevaa maastoa vaihtelevalla menestyksellä. Jos suunnistajalle tulee yllätyksiä, kartta saa usein syyt niskoilleen. Joskus syystä, joskus aiheetta. Soittaako tämä mitään kelloja sinulle lukemattomien sovellusten käyttäjänä?

Jos suunnistusmaasto on ohjelmisto, jota alat ensimmäistä kertaa testaamaan, minkälaisen kartan sinä saat testaajana käteesi? Ovatko vaatimusmäärittelyt kaiken kattavat? Ovatko vaatimusmäärittelyt varmasti oikeassa? Uskallan väittää, että vastaus on “ei” valtaosassa softaprojekteja. Joskus testaaja jopa lähetetään matkaan tyhjän kartan kera!

Testaajan suunnistuskoulun opetus 1: Testaajan tulee toimia kartan laatijana. Tutkia ja rakentaa tarkempi kuva. Tuottaa informaatiota, jota ei aiemmin ohjelmistosta tiedetty.

Testaajan suunnistuskoulu kokonaisuudessaan:

1. Kartta tyhjää täynnä
2. Juonikas ratamestari
3. Oletko kuivan kesän orava?
4. Apinoiden armeija
5. Viestistä kattavuutta 2.7.2018
6. Mestariksi kertaamalla 9.7.2018

Jo aiemmin työssään uupumuksen kokenut nainen muisti jälleen, että uni on tärkein. Hän lähti parantamaan uudestaan iltarutiinejaan, jotta saisi levättyä yöt.

Nainen oli antanut itsestään tavallista enemmän työssään, hän kävi edustamassa yritystä Sveitsissä ja tunsi matkan jälkeen jälleen uupumuksen merkkejä. Tällä kertaa nainen havahtui pohtimaan: haluanko uupua yhä uudestaan vai otanko itselleni aikaa levolle ja uudistumiselle, jotta jaksan taas jatkaa?

Unirytmi löytyi työmatkan jälkeen taas pikaisesti ja nainen tunsi virkistyneensä. Työpäivät sujuivat osittain pienessä usvassa ja hän tiesi, ettei anna itsestään parastaan. Työnantajalle voisin osoittaa olevani energisempi, jotta voisin edetä urallani, nainen ajatteli. Hän ryhtyi tarkkailemaan työpäivien kulkua ja ryhtyi pitämään taukoja, jolloin hän käveli hieman, haukkasi raitista ilmaa ja joi vettä. Työt hän jätti tauon ajaksi työpöydälle ja keskittyi kaupungilla kävellessään siihen mitä näki ja tunsi. Ilma oli raikas ja pieni tuulenvire tuntui kasvoilla. Kauempaa kuului lasten ääniä ja lähellä työmaan koneiden paukkumista. Jalkojen alla tuntui märkä asfaltti ja pienet lätäköt, jotka hieman räiskyivät hänen kävellessään niiden läpi. Hetken aikaa nainen tunsi olevansa vapaa.

Pian nainen huomasi, että oli työpäivän jälkeen virkeämpi kuin aiemmin. Hän jaksoi työpäivän läpi hyvällä energialla ja työpäivän jälkeen oli virtaa lähteä urheilemaan.

Rutiinit muuttuvat kun on vahva motivaatio muuttaa tilanne toiseksi ja oppii tunnistamaan miten rutiini sujuu tällä hetkellä ja pohtii millaiseksi sen haluaa muuttaa. Sen jälkeen kyse on asian muistamisesta yhä uudestaan ja uudestaan. Energiaasi ammattilaisena voit aina vaikuttaa.

Kaveri kysyi kahvilla kiinnostavan kysymyksen. Miten testaisit uuden mobiilisovellukseni? Se on yksinkertainen appsi, johon asiakas pystyy syöttämään kriittiset mittansa ja saa tuloksena painoindeksin.

Hetken tuntui, kuin olisin työhaastattelussa. Sitten riemastuin. Tämähän on viihdyttävä peli. Keksitään kimpassa testausideoita vaikka muille jaettavaksi asti.

Ensin voitaisiin katsoa, miltä käyttöliittymä näyttää. Sitten kokeilla syöttää systeemille vähän tietoja. Eri kokoisten ihmisten aluksi, sitten tutkia miten sukupuoli vaikuttaa asiaan. Syötteiden ja vasteiden leikistä saadaan jo paljon hauskaa testattavaa aikaiseksi.

Sitten mieleen tuli kysymys. Niin millä mobiilialustoilla tämän pitikään toimia? Olin nopeasti ajautunut testaajan tyypillisimpään ansaan. Aloitin olettamuksistani ilman ymmärrystä viitekehyksestä. Minusta testaajan tulee aina aluksi hankkia tarpeelliset taustatiedot työn täysimääräiseen suorittamiseen.

Aloitan yleensä näistä:

1. Paljonko aikaa meillä on käytettävissä?
2. Mitä tietoa haluamme testauksen tuottavan?
3. Mikä asetetaan tämän session tavoitteeksi?
4. Kuka maksaa tuotteesta ja miksi?
5. Millä alustoilla tämän tulisi ensisijaisesti toimia?
6. Mitä muita huolia työn pyytäjällä on mielessään?

Kysymysten tulva olisi kyllä aivan ääretön, kun alkuun pääsee. Tärkeintä vain on muistaa ja osata päästä alkuun. Ilman kehystietoa tehtävästä, tulokset jäävät joutaviksi.

Testauksen ensimmäinen työvaihe on aina ymmärtää asiayhteys. Vasta sitten on bugien pyydystämisen vuoro.

Muistatko, miten Harry Potterilla alkoi ensimmäinen lukuvuosi Tylypahkan noitien ja velhojen koulussa? Jäbä sai ensin yhden kirjeen Likusteritielle, mutta ilkeä Vernon-setä hävitti sen. Tylypahkan markkinointiautomaatio ei kuitenkaan antanut periksi ja pian kirjeitä satoi ovista ja ikkunoista. Pöllö pöllön perään puski pojalle postia.

Tunsin perjantaina oloni Harryksi. GDPR -kirjeiden määrä on kyllä ylittänyt odotukseni. Kaikki toimittajasta tilaajaan tykittävät kirjeitään kavereille. Säntäilemme virittämässä omia papereitamme tilanteessa, missä sama lainsäädäntö sitoo jo valmiiksi meitä kaikkia. Erikoista sanon minä.

No. Jos joku myöhemmin tulisikin tutkimaan, että onko tietosuoja-asetuksen eteen tehty jotain, niin pino papereita tietysti auttaa auditoinnissa. Mutta miten on niiden softatuotteiden ja itse infran laita?

Olen huomannut, että tietoturvan rakentamiseksi softatuotteisiin, olipa kyseessä sitten verkkopalvelu tai mobiilisovellus, on huolehdittava kaksi asiaa.

Ensimmäiseksi ehdotan todistusaineiston rakentamista siitä, mitkä asiat on testattu ja miten. Hyvä ajatustyön peruskivi voisi olla esimerkiksi OWASP top lista haavoittuvuuksista. Käymällä tiimin kanssa lista läpi ja dokumentoimalla työ, saadaan hyvät valmiudet kestää myös ulkopuolinen tarkastelu.

Toiseksi, mikäli budjettia vielä on ja riskit ovat keskimääräistä korkeammat, ehdottaisin vielä piiloonjääneiden bugien etsimistä ja pyydystämistä. Kantavana ajatuksena voisi kuljettaa esimerkiksi kysymystä, mitä hyvä hakkeri tekisi tuotteellemme viikossa?

Parhaat lopputulokset tottelevat yleensä painetta spektrin molemmista päistä. Tarkastamalla ja dokumentoimalla, että perusasiat ovat yhä kunnossa ja toimivat. Sekä saalistamalla systemaattisesti uusia paikkoja mistä bugi saattaa vielä pilata pelin.

Testaus on kahden työlajin summa. Tarkistamisen ja saalistamisen.

Mikä on riittävä määrä taustatietoa, jotta testaus kyetään hoitamaan asianmukaisesti? Tämän kysymyksen äärellä on jokainen testaaja joutunut viettämään pitkiä tunteja uransa uuvuttavissa vaiheissa. Mitä enemmän kysymystä maistelee, sitä todellisemmaksi muodostuu ymmärrys, että mikään määrä taustatietoa ei ole tarpeeksi. Jokin meissä kuitenkin saa aikaan päätöksen:

“Nyt riitti! Aletaan testaamaan!”

Uskomme, että päätöksemme on rationaalinen, optimaalisen suunnittelu- ja taustatutkimustuottavuuden (ihan mieletön sana, keksin sen juuri itse!) tulos. Olemme käyneet kaiken mahdollisen tiedon läpi, mikä auttaa meitä tuottamaan sen parhaan ja kustannustehokkaimman ratkaisun suunnittelun ja testauksen vaakalaudalla. Olemme tutkineet kaiken perinpohjin ja ei ole epäilyksen häivääkään, että yksikään tärkeä taustatiedon murunen olisi päässyt livahtamaan ohi katseemme. Onkohan sittenkään näin?

Todellisuudessa olemme kuitenkin lapsia. Päätöksemme ovat spontaaneja, vaikka harhaudummekin ajattelemaan niitä suunnitelluiksi.

Emme koskaan pysty korjaamaan puutteellisten taustatietojemme määrää, emmekä oikeastaan tiedä miksi yhtäkkiä päätämme, että taustatietomme ovat juuri nyt riittävät. Sen kuitenkin tiedämme, että energia alkaa pulppuamaan suonissamme, kun asiat alkavat etenemään. Minimoimalla taustatutkimuksen ja suunnittelun määrän emme kahlitse itseämme perinteisiin kaavoihin ja emme kompastele klassisiin softaprojektien sudenkuoppiin. Puutteellisten taustatietojen paratiisissa leikkiminen on moninverroin merkityksellisempää kuin leikin suunnittelu.

Taustatiedot selviävät usein parhaiten kun aletaan töihin. Ainoa taustatieto jonka tarvitset, on reittiohje ja tienviitat testauksen leikkikentälle.

Olemme taipuvaisia toteuttamaan kaikenkarvaisia softakehitykseen liittyviä asioita tarpeettoman monimutkaisella tavalla. Tuon luonnollisen taipumuksen kuoleman kentiltä löytyy myös testauksen ala, jota kutsumme perffitestaukseksi. Perffitestaus ei ole lajina rakettitiedettä, eikä sen toteuttaminen vaadi päiväkausia kestävää määrittelytyötä, jonka jälkeen päästään viikkoja kestävään testausvaiheeseen, minkä tuloksia kaikki parhaansa mukaan esittävät ymmärtävänsä.

Perffitestaus on Rubikin kuutio, jossa optimaalinen lähestymiskulma ratkaisee koko pelin.

Kun 3×3 kuution tekemiseen menee 1 minuutti (meiltä kaikiltahan se onnistuu, kysymys on vain käden käänteestä!), niin 4×4 työstäminen vie 45 minuuttia, ja 5×5 tahkoaminen kestää jo 2,5 tuntia. Trendi on melko selkeä. Jännä juttu on, että kaikki nuo kuutiot ratkeavat samalla metodilla, ja siirreltävien palikoiden lukumäärä merkkaa pitkälti ratkaisemiseen kuluneen ajan. Perffitestit voi tehdä 5×5 tai jopa suurempana Rubikin kuutiona, vaikka 3×3 on yleensä täydellisen riittävä. 2×2 ei välttämättä vastaa enää ympäristön odotuksiin ja 1×1 -kuutiosta voidaan sanoa ainoastaan, että se on.

Kun aitojen PerffiGurujen elämää seuraa, voidaan havaita, että Gurut löytävät optimaalisen tien kaikken tekemiseen. Elämiseenkin.

Samat testien tekemisen metodit pätevät aina toistaan monimutkaisemmissa perffiprojekteissa, kysymys on vain siihen käytetystä ajasta. Työmäärä ei kasva lineaarisesti testiskoopin ja -skriptien monimutkaistuessa, vaan työmäärä kasvaa useamman kertaluokan hyppäyksin. Minkä tahansa kokoinen Rubikin kuutio ratkaistaankaan, lopputuloksena on kuitenkin väistämättä ratkaistu Rubikin kuutio.

Perffitestausta ja sen hyödyllisiä tuloksia ei kannata uhrata monimutkaisuuden alttarilla. Siitä seuraa ainoastaan kipua ja kärsimystä, höystettynä kuluneella ajalla ja rahalla. Aina kun ajatuksesi hipovat perffitestauksen pyhää tieteenalaa niin muista, että haluat ratkaista mieluummin 3×3 -kuution kuin suuremman.

Joskus käy niin, että ideat ehtyvät. Sitten alkaa tutkimusmatka uusien eteen. Quorassa eteen eksyi testaustyön ensimmäinen kysymys. Mitä se ohjelmistotestaus sitten on?

Ja niin sai alkunsa tämä filkka:

Asiakkaan teknologiajohtajan ilme oli kullan arvoinen. Istuin softaprojektimme ohjausryhmän tapaamisessa testimanagerin saappaat jalassa. CTO oli tullut kylään. Halusi tavata tiimin ja nähdä, mitä tälle kehittämällemme uudelle uskomattomalle puhelimelle kuuluu. Erityistä siinä oli mullistava kosketusnäyttö ja siihen liittyvä värähdevaste, joka mukaili oikeiden nappien painamista.

Ei ollut Applen projekti, joten arvaat varmaan, että nyt ei olla onnistumistarinan äärellä. Siihen aikaan kosketusnäyttöpuhelimia ei kuitenkaan vielä näkynyt markkinoilla, joten olimme kehityksen terävimmässä kärjessä.

Teknologiajohtajan ilme johtui juuri värähdevasteesta kosketusnäytöllä. Kehitystiimimme kaukomailla oli tulkinnut vaatimuksia vapaasti. He ajattelivat, että laitteen kuuluu värähtää aina, kun näytöllä tapahtuu jotain. Niinpä tavallinen pyyhkäisyliike tai nipistyszoomaus muuttivat laitteen pieneksi vibraattoriksi. Pomolla oli ilmeessä pitelemistä puhelimen näköinen dildo kädessään.

Jo kuukausia aikaisemmin testaustiimi oli törmännyt testaajalle tuttuun lauseeseen, joka on nykyisin jo ihan klassikko.

Ei tuo ole bugi, se on feature!

Ja niinhän se olikin feature. Speksin todellakin pystyi tulkitsemaan juuri niin kuin kehittäjämme olivat päättäneet. Speksi ja järki eivät aina kulje käsi kädessä. Tämän projektin suurin sudenkuoppa oli keskittyä testauksessa siihen täsmääkö tuote speksiin. Täsmäsi se. Ja vieläpä varsin hyvin. Jokaisella tuotteen osa-alueella päästiin 98% läpäisyprosenttiin testitapausten kanssa siitäkin huolimatta, että itse tuote oli susipask…siis huono. Projekti ajettiin alas kaksi kuukautta myöhemmin.

Testaus on aina suhteellista vaikka harhaudummekin usein keskittymään enimmäkseen siihen miten tuote toimii suhteessa speksiin. Mutta mitä muita vertailukohtia keksisit? Tässä muutamia näin alkuun.

• Miten tuote toimii suhteessa lakiin?
• Miten tuote toimii suhteessa omiin odotuksiisi?
• Suhteessa standardeihin?
• Suhteessa sen käyttötarkoitukseen?
• Suhteessa kilpailijan tuotteeseen?
• Suhteessa historiaanne?
• Suhteessa käyttöohjeisiin?
• Suhteessa tyypillisen käyttäjän tilanteeseen?
• Suhteessa verkkosivujenne lupaukseen?
• Suhteessa messujen myyntiesitteeseen?
• Suhteessa testattauvustarpeisiin?

Entäpä, jos seuraava testaussuunnitelmasi keskittyisikin vastaamaan siihen, mitkä vertailukohdat ovat tärkeimmät ja missä järjestyksessä?