1. ”Ei kai se haittaa vaikka softaan jää bugeja, jos se kuitenkin toimii?”
Jos sinä ja käyttäjät olette tilanteeseen tyytyväisiä, niin mikäpä siinä sitten. Buginen softa ei vain ole kummoinen kilpailuvaltti, aivan kuten housut joiden vetoketju ei toimi kunnolla; pystyt ne pukemaan, saat ne napin avulla pysymään jalassa, mutta vetoketju pyrkii avautumaan itsestään jatkuvasti. Harkitsisitko käyttäväsi saman merkin housuja jatkossa?
Yksikään ohjelmisto ei ole virheetön, mutta ohjelmistotestaus on tuotekehityksen työvaihe varmistamaan, että ohjelmisto on vaatimuksiaan ja käyttökohdettaan vasten mahdollisimman laadukkaaksi todettu ja käyttökokemukseltaan asianmukainen.
Vaikka ohjelmistosi tuntuisi pikku bugeihin puuttumatta toimivan kohtuudella, tilanne saattaa seuraavan releasen tai järjestelmäpäivityksen myötä muuttua, tai pahimmillaan eskaloitua pahimpaan mahdolliseen suuntaan.
Usein ohjelmistot, joiden testaus on jätetty retuperälle, sisältävät myös paljon nopeasti kyhättyjä hätäkorjausratkaisuja ja dokumentoimatonta purkkakoodia. Kun sellaista koodia jätetään voimaan ohjelmiston versiohistoriaan, ollaan tikittävän aikapommin äärellä.
2. ”Eikös ohjelmistokehittäjät voisi vastata myös testauksesta?”
Todellakin testaus on myös yksi kehittäjien tehtävistä, mutta ei missään tapauksessa kokonaisvastuu. Kehittäjät vastaavat tyypillisesti yksikkötesteistä, ja mitä enemmän yksikkötestejä on kehitettynä, sitä varmemmalla perustalla koko ohjelmiston laadunvarmistus lepää.
Hyvin yksinkertaisella tasolla kuvaten, kehittäjät testaavat kehittämästään ohjelmakoodista pienempiä loogisia osia (ohjelmistokomponentteja) hyödyntäen yksikkötestejä, joita ajetaan suoraan kehitystyökalussa. Siihen jatkumona kehitetään yleensä myös integraatiotestejä, jotka ottavat kantaa ohjelmiston eri komponenttien/modulien/oheisjärjestelmien väliseen yhteistoimintaan.
Tämän jälkeen käyttöliittymätestaus, systeemitestaus ja e2e-testaus saattavat astua työvaiheina kuvaan, usein testiautomaation tai manuaalitestauksen kombinaationa. Yleensä tässä vaiheessa tuotekehitysprosessia ohjelmistotestaajan tai testiautomaatiokehittäjän roolit astuvat kuvaan, ja koko tämän hässäkän lopputulemana syntyy laadukas ohjelmistotuote.
Mutta mikäli vain kehittäjät vastaisivat tuosta kaikesta, milloin he sitten ehtisivät kehittää?
3. ”Muutokset olivat niin pieniä, että emme kai tuhlaa kallista aikaa testaamiseen?”
Riippuu muutoksesta. Mikäli päivität verkkopalveluusi sisältöä, sen testaamiseen riittää yleensä kevyt tsekkaus joka tuskin vie aikaa varttia enempää.
Mutta mikäli muutokset koskevat ohjelmakoodia tai järjestelmäsi osiin liittyviä versiopäivityksiä, saattavat vähäpätöiseltä tuntuvat muutokset nostaa kriittisiä ongelmia esiin joltain ohjelmistosi osa-alueelta. Ne ovat tilanteita, jotka on ehdottomasti turvallisinta havaita ennen tuotantoon vientiä ja maksavat takaisin testaukseen budjetoidun ajan ja pääoman.
Mieti kuitenkin, kumpi ajankäyttö on kalliimpaa: Testiympäristössä suoritettu hallittu testaus, vai tuotannossa esiin nousseiden laatuongelmien selvitys ja korjaustyö?
Suhtaudu siis julkaisemiisi muutoksiin äärimmäisellä vakavuudella!
4. ”Eikö olisi helpointa vain kerätä bugit käyttäjien palautteista?”
Mikäli olet valmis luottamaan siihen, että käyttäjät raportoivat havaitsemansa ongelmat ymmärrettävästi, seikkaperäisesti ja kohteliain sanankääntein, niin onnea matkaan! Tee kuitenkin käyttäjille H Y V I N selväksi, että testaamatta julkaisemasi ohjelmisto on versio, jossa saattaa esiintyä vielä joitain laatuongelmia, ja toivot käyttäjiltä paljon palautetta matalalla kynnyksellä. Beta-versiona julkaiseminen tarjoaa yleensä turvallisimmat raamit tähän riskialttiiseen toimintamalliin, mutta se ei ole missään tapauksessa ratkaisu projektin testauskysymykseen pitkällä aikavälillä.
Valitettavan harvoin kentältä vastaanotetut käyttäjäpalautteet tarjoavat sellaisen vikakuvauksen, jonka avulla kehittäjät pystyvät pureutumaan vian ytimeen nopeasti. Iso joukko ovat myös ne hiljaiset käyttäjät, jotka vain toteavat palvelun heikkolaatuiseksi ja lopettavat käytön välittömästi antamatta palautetta. Bugien korjaaminen on helpompaa ja nopeampaa, kun bugin raportoi ohjelmistotestaaja asianmukaisesti laadittuna bugiraporttina, ja on myös välittömästi tavoitettavissa lisätietojen ja uusintatestausten tarpeisiin.
Aivan pahimmillaan et tarvitse kuin yhden suositun some vaikuttajan, tai muun näkyvän tahon, tuomaan huonolaatuisen tuotteesi negatiiviset epäkohdat esille, ja mainehaitasta aiheutuva työn määrä kasvaa kertaheitolla moninkertaiseksi.
5. ”Kas kas, raportoidut testitulokset olivat 100% PASSED. Eikös nuijita tämä softa nyt tuotantoon ja lähdetä viikonlopun viettoon?”
Mikäli sunnuntaiaamusi aamupala meni väärään kurkkuun tuotannosta kantautuneiden hätähuutojen vuoksi, varaudu viimeistään maanantaiaamuna kärppänä vastaamaan uskottavasti kysymykseen: ”Millä tavoin ongelmiin johtaneet seikat olivat huomioidut viimeksi julkaistun version testauksessa?”
Suoritettujen testien dokumentoinnin kannalta ajetuista testitapauksista koostetut metriikat ovat toki hyvää informaatiota, mutta päätöksenteossa on tärkeää ymmärtää myös niiden taustalla tehdyt asiat; huomioiko testaus uusina kehitetyt asiat, ja toisaalta huolehtiiko se vanhojen toimintojen regressiotestauksesta?
Pelkkiin tarkasti määriteltyihin testitapauksiin pohjautuva testaus saattaa olla jopa karhunpalvelus ohjelmiston kokonaislaadulle, koska ne rajaavat testaustyön vain testitapauksissa dokumentoituihin steppeihin. Tutkivan testauksen menetelmillä taasen testaajilla on mahdollisuus ’kurkistaa kulman taakse’, josta löytyy usein kaikkea jännää. Niin, ja taisi vallan unohtua listata muutamia muita testauksen menetelmiä jotka saattavat tulla kysymykseen, kuten:
- Suorituskykytestaus
- Saavutettavuustestaus
- Käytettävyystestaus
- Tietoturvatestaus
- Hyväksymistestaus
Toivommekin, ettei yhdenkään ohjelmiston julkaisupäätös perustuisi yksinomaan pelkkien toiminnallisista testitapauksista generoitujen metriikoiden varaan, vaan käsitys ohjelmistotuotteen kokonaislaadusta pohjautuisi monipuolisesti suoritetun testaustyön kautta summattuihin faktoihin ja päätelmiin tiimin keskinäisten keskusteluiden kautta. Metriikat voivat mainiosti tukea näitä keskusteluita, mutta jollakulla tiimistä tulee aina olla aidosti ymmärrys miten tuotetta testattiin nyt ja miten sitä tullaan testaamaan ensi viikolla!
Lisäksi perjantaina ei julkaista ikinä koskaan milloinkaan mitään!!
