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) 

Mitä laatu on ja mitä laadulla tarkoitetaan ohjelmistotestauksessa? (TMap ja ISO 9126)

Ohjelmistotestauksessa on kyse ohjelmiston laadun selvittämisestä. Tämä tarkoittaakin sitä, että ennen kuin yhtään testiä on kirjoitettu, pitää määritellä, mitä laatu on – se on myös hyvä filosofinen kysymys, jota kannattaa pohtia kokonaisvaltaisesti projektin suhteen. Onneksi on olemassa valmiita standardeja, kuten kansainvälinen standardi ISO 9126 ja TMap Next (luku 10), joissa määritellään, mitä ohjelmiston laatuominaisuuksilla (quality characteristics) tarkoitetaan. Kummatkin standardeista ovat laajalti tunnettuja ja ohjelmistoteollisuudessa käytössä.

TMap Next määrittelee kahdeksantoista ohjelmiston laatuominaisuutta: liitettävyys (connectivity), jatkuvuus (continuity), datan hallittavuus (data controllability), vaikuttavuus (effectivity), tehokkuus (efficiency), joustavuus (flexibility), funktionaalinen tarkkuus (functional accuracy) ja funktionaalinen kokonaisuus (functional completeness), infrastruktuurin soveltuvuus (suitability of intrastructure), ylläpidettävyys (maintainability), hallittavuus (manageability), suorituskyky (performance), siirrettävyys (portability), reusability (uudelleenkäytettävyys), turvallisuus (security), soveltuvuus (suitability), testattavuus (testability) ja käyttäjäystävällisyys (user-friendliness).

Kansainvälisen standardointiorganisaation ISO 9126 määrittelee kuusi isompaa laatukokonaisuutta: toiminallisuus (funktionaalisuus), luotettavuus (reliability), käytettävyys (usability), tehokkuus (efficiency), ylläpidettävyys  (maintainability) ja siirrettävyys (portability).

TMapin ja ISO 9126 standardeissa on sisällöllisesti paljon samaa, mutta myös eroja. Ehkä yksi tärkeimmistä eroista on se, että ISO 9126 pitää funktionaalisuutta sateenkaarikonseptina, jonka alle menevät esimerkiksi turvallisuuden ja soveltuvuuden testaus. TMapissa funktionaalisuus on jaettu kahteen osaan: funktionaaliseen tarkkuuteen ja funktionaaliseen kokonaisuuteen ja turvallisuus ja soveltuvuus ovat omia laatuominaisuuksiaan. Funktionaalisella tarkkuudella tarkoitetaan sitä, että järjestelmä toimii virheettömästi ja tarkasti ja funktionaalisella kokonaisuudella sitä, että kaikki toiminallisuuden osat tulevat testattua. Suurin osa testauksesta kuitenkin keskittyy toiminallisuuden testaamiseen, joten sen laatutavoitteiden oikeanlainen määrittely on yksi tärkeimmistä testauksen suunnitteluvaiheen tehtävistä.

Kumpikin standardi määrittelee, mikä on niiden määritelmä laadusta ja siihen liitettävistä ominaisuuksista – eli hyvin tehdystä tuotteesta. Laatu on siis osien summa, joka rakennetaan pala palalta. Ohjelmistotestauksen ytimessä on tietysti kliininen toiminallisuuden testaus, mutta sen ympärillä olevat muut palaset muodostavat ohjelmiston laadun. Ohjelmiston pitää olla toiminnallisuuden lisäksi ainakin käytettävä (usability), tehokas (efficiency), ylläpidettävä (maintainability) ja siirrettävä (portability). Nämä ovat muuten ne nimenomaiset laatuominaisuudet, jotka sattuvat löytymään kummastakin laatustandardista. 

Lähteet:

TMap Next: for result-driven testing (2006), Sogeti Nederland B. V. Chapter 10, Quality Characteristics.
ISO/IEC 9126 Software engineering — Product quality. (2011). 
Available: https://en.wikipedia.org/wiki/ISO/IEC_9126