Laadunvarmistus on ohjelmistokehityksen kriittinen tukipilari. Ilman sitä ja ohjelmistotestausta on ohjelmistokehitys kuin talo ilman kantavia seiniä – saattaa pysyä komeasti pystyssä, tai sitten koko rakennelma sortuu.
Yksikään kaupallinen ohjelmisto ei voi menestyä, jos sen käyttämisessä on puutteita. Ne voivat olla kaikkea käyttöliittymän helppoudesta ohjelmiston nopeuteen ja tietoturvaan asti. Ohjelmistotestauksessa on lukuisia osa-alueita, joista kaikista tulee huolehtia, jotta ohjelmisto toimii, kuten sen oletetaan toimivan.
Ohjelmiston laadunvarmistusta ei yksinkertaisesti voi unohtaa, jos ja kun haluat pitää käyttäjät tyytyväisenä, tai ylipäänsä saada käyttäjiä. Ikävä käyttökokemus karkottaa ihmiset tehokkaasti, antaa huonon laatuvaikutelman ja epäammattimaisen kuvan ohjelmiston tekijöistä. Ei kukaan halua antaa liiketoiminnastaan em. vaikutelmaa, ja sen voi välttää huolellisella laadunvarmistuksella ja testauksella.
Yleinen kuoppa ohjelmistokehitysprojekteissa on laadunvarmistuksen aikataulutuksen tai resursoinnin alimitoitus, joka voi helposti johtaa aikataulujen pettämiseen tai yleiseen laaduttomuuteen. Ei riitä, että käytössä on parhaat kehittäjät, tarvitaan myös parhaat laadun ymmärtävät ammattilaiset.
1. Onnistuminen laadunvarmistuksessa ja ohjelmiston testaamisessa näkyy viivan alla
Testaus mielletään usein investoinniksi, joka ei tuota mitään ja saattaa jopa hidastaa kehitystä. Kyseessä on kuitenkin ns. väärä positiivinen – mitä aiemmin mahdolliset virheet löydetään ja saadaan korjattua, sitä paremman tuotteen voi viedä tuotantoon – vaikka virheenkorjaukseen kuluisikin aikaa ja muita resursseja. Ei ole olemassa sellaista ohjelmistoa, jonka tekemisessä ei olisi syntynyt virheitä. Ohjelmistotestaus ei koskaan tuota positiivista lukemaa viivan alle juuri sillä hetkellä, sen arvo voidaan mitata vasta tulevaisuudessa, ja silloinkin lähinnä virheiden vähyydellä – mikä itsessään on suotava lähtökohta mille tahansa projektille.
Liian usein testaamattomuus tai testauksen vähyys nähdään jälkikäteen, ja silloin ”Mitä jos” -ajattelu on myöhäistä ja mahdolliset kurssin muutokset ja korjaukset voivat viedä hurjasti resursseja, aikaa ja rahaa. Jos testaus on suoritettu alusta asti suunnitelmallisesti ja yhdessä muun kehityksen kanssa, voidaan todeta viivan alle ilmestyvän muutakin kuin miinusmerkkejä.
Testauksen hallinnassa pääpainona on muutama perusasia. Mitä testataan, milloin testataan ja kuka testaa (testaussuunnittelu/strategia), testidatan sekä löydösten ja tulosten kirjaamisesta (testitapaukset, defektit ja raportit) ja analyysista (virheiden debuggaus, kehitysehdotukset ja kehityssuunnitelmien muutokset). Näiden osa-alueiden hallintaan on käytössä useampiakin työkaluja, ja niiden sulava yhteenliittäminen ja selkeästi kehitystiimille ja muulle organisaatiolle asioista viestiminen, kuuluu laadunvarmistuksen konsultin arkeen.
2. Ohjelmistotestaus on ainoa tie erinomaiseen ohjelmistoon
Ohjelmistotestaus on periaatteessa yksinkertaista, jossa kokonaisuuden hallitseminen on kuitenkin yllättävän laaja paketti, ja se vaatii monenlaista erityisosaamista. Alla hieman eriteltynä ohjelmistotestauksen joitakin eri osa-alueita.
2.1 Yksikkötestaus
Yksikkötestauksessa testataan nimensä mukaisesti yksiköitä, osia koodista, periaatteessa pienimpiä ohjelman osia, joita voidaan testata. Siinä varmistetaan näiden pienten osien oikeellisuus. Nämä testit on usein automatisoitu, ja luodaan lähes aina samaan tahtiin muun kehitystyön edetessä.
2.2 Integraatiotestaus
Integraatiotestauksessa testataan pääsääntöisesti, miten järjestelmän eri osat juttelevat keskenään, ts. toimiiko niiden välinen integraatio.
2.3 Systeemitestaus
Systeemitestauksessa sen sijaan keskitytään koko järjestelmään ja eri variaatioihin sen käytössä. Näitä edeltää kehityksen aikana tehtävät yksikkötestit, jotka jokainen itseään kunnioittava ohjelmistokehittäjä kirjoittaa samalla kun koodinsakin.
3. Testaustasoja voi olla useita
3.1 Toiminnallinen testaus
Toiminnallisen testauksen tarkoitus on varmistaa, että ohjelmisto toimii toivotulla tavalla ja täyttää asetetut vaatimukset toiminnallisuutensa puolesta. Toiminnallinen testaus tehdään usein loppukäyttäjän näkökulmasta, ja suoritetaan käyttöliittymää käyttäen.
3.2 Ei-toiminnallinen testaus
Ei-toiminnallisessa testauksessa käydään läpi nimenmukaisesti muuta kuin näkyvää toiminnallisuutta, esimerkiksi suorituskykyä, vikasietoisuutta tai resurssien käyttöä. Molemmat ovat yleisessä käytössä sekä integraatio- että systeemitestivaiheissa.
3.3 Regressiotestaus
Regressiotestaus pitää sisällään edellä mainitut testaustyypit, mutta on luonteeltaan erilaista. Kun toiminnallisessa (ja ei-toiminnallisessa) testauksessa pyritään kehityksen aikana löytämään mahdollisimman paljon uusia virheitä ja virhetilanteita, regressiotestauksessa tarkistetaan, että ohjelmistoon tehdyt muutokset eivät ole rikkoneet jo toimivaksi todettuja ominaisuuksia. Samalla tarkistetaan, että jo löydetyt virheet ovat pysyneet korjattuina.
3.4 Käytettävyystestaus
Käytettävyystestauksessa tutkitaan, kuinka hyvin suunniteltu tai jo toiminnassa oleva ohjelmisto toimii – onko se helppokäyttöinen, ns. intuitiivinen ja looginen, ovatko värit, kontrastit ja siirtymät hyväksyttäviä, ja joutuuko käyttäjä odottamaan toiminnallisuuksia tai latauksia liian kauan, ym. Päätelaitteesta ja käyttäjäryhmästä riippuen käytettävyyden vaatimukset voivat olla hyvinkin erilaisia, mutta hyvän käytettävyyden takana on kuitenkin aina vankka teoria ja hyvät käytännöt.
3.5 Hyväksymistestaus
Hyväksymistestaus on testauksen osa-alue, jossa loppuasiakas itse, tai heidän edustajansa, tarkastaa jo valmiin tai lähes valmiin tuotteen, ja tarkistaa vastaako se oikeita käyttötapausten vaatimuksia. Hyväksymistestaus vaatii usein hyvää liiketoiminta-alueen ymmärrystä, ja tietoa asiakkaiden vaatimuksista ja tavoista toimia, sekä mahdollisesti alan säädöksistä ja lainsäädännöstä.
3.6 Tutkiva testaus
Tutkiva testaus on vähemmän suunnitelmallista, perustuen usein testaajan ammattitaitoon ja kokemukseen. Yleensä painopistealueet sovitaan etukäteen ja testauksen aikana pidetään ”päiväkirjaa” tehdyistä asioista ja mahdollisista löydöksistä. Tutkiva testaus voi olla hyvin tehokas tapa käydä läpi kompleksisiakin asioita ilman suurta valmistelevan työn ja dokumentoinnin määrää, ja tulokset voivat olla yllättäviäkin – sessioiden aikana ehtii tehdä asioita monelta eri kantilta, ja epäortodoksisetkin lähestymistavat tulevat katettua, toisin kuin täysin suunnitellussa testauksessa.
Teksti: VALA Group
VALA Groupin Ite wiki-profiili
