On paljon teollisuuden aloja, joita säätelee liiketoiminnan sääntöjen lisäksi jokin viranomaisen säädös tai alan oma standardi. Näillä aloilla täytyy tehdä kaiken muun testauksen lisäksi yleensä pakollisia testejä. Parhaimmillaan testaaja pystyy yhdistelemään itselleen optimaalisen testaustavan ja tuottamaan samalla säädösten sanelemat testaustulosdokumentit. Aina näin ei kuitenkaan ole, vaan joskus täytyy tehdä testejä periaatteessa moninkertaisesti. Tälläkin on kuitenkin tarkoituksensa, sillä moninkertainen testaus on yksi turvallisuuskriittisten alojen redundanssin luomisen keinoista – tehdään kriittiseen asiaan kaksi järjestelmää / toimintatapaa ja saadaan sitä kautta lisävarmuutta turvalliseen toimintaan.
Kyseessä on virallisesti termi nimeltä Yhdenmukaisuuden testaus [FiSTB], englanniksi Compliance testing, mutta joskus kuulee myös Finglish-termiä regulaatioiden testaus. Mitä sitten on yhdenmukaisuus eli Compliance [ISTQB]?
Yhdenmukaisuudella tarkoitetaan siis säädösten tms. mukaisuutta. Yleisin sovellutus yhdenmukaisuuden testauksesta on yksi hyväksymistestauksen muodoista eli ”Sopimuksiin ja sääntöihin perustuva hyväksymistestaus” [FiSTB]. Kuten asian positiointikin jo ilmaisee, niin ajatellaan, että ohjelmistokehitysprojekti tekee hyvän järjestelmän ja testaa sen hyvin ja sitten lopuksi hyväksymistestauksen aikana tarkistetaan, ovatko yhdenmukaisuuskriteerit täyttyneet.
Yhdenmukaisuus on käytännössä aina joidenkin dokumenttiin kirjattujen vaatimusten todentamista, eli sillä ei vielä taata toimiiko järjestelmä todella kaikissa tilanteissa. Vaikka tällainen testaus on pitkälle todentamista (verification), kutsuvat standardit usein näitä pakollisia testejä kuitenkin kelpuutukseksi (validation). On toki semantiikkaa, mikä on oikeasti kelpuutusta, ja mukana on lisäksi paljon hyväntahtoista ajattelua, että kaiken kelpuutuksen saisi kirjattua paperille. Kuitenkin säädöksen tai standardin vaatimuksiin, tai joskus niistä johdettuihin standardisettiin testejä, on pyritty kuvaamaan olennaisimmat asiat, jotka pitää toimia. Käymällä nämä läpi saadaan hyvä perusvarmuus, että järjestelmä toimii vaatimusten mukaisella tavalla. Hyvänä esimerkkinä tällaisesta ovat tietoliikennealan standardit, jotka velvoittavat verkkovalmistajia ajamaan läpi vakiosetin TTCN-testejä [ETSI].
Näiden pakollisten testien lisäksi pitää tehdä normaalien hyvien testitapaussuunnittelutekniikoiden avulla hyvää kattavaa testausta. Joidenkin alojen standardit ohjaavatkin tähän suuntaan ja itse asiassa velvoittavat käyttämään tiettyjä testitapaussuunnittelutekniikoita, jotta saavutetaan hyviä kattavuuksia. Esim. ISO-61508 standardi määrittää Safety Integrity Leveleille (SIL:eille) eri tasoisia koodikattavuustekniikan käyttövaatimuksia. Kriittisimmälle tasolle (4) jopa vakavasti suositellaan moniehtokattavuutta (MC/DC Condition coverage) [Bullseye]. Tuo standardi on yleisesti elektroniikka-alan käytössä. Ilmailualan DO-178B standardi käyttää vastaavaa luokitusta.
Mielenkiintoinen esimerkki on terveydenhuoltoalan laitteiden tarve täyttää amerikkalaisen FDA:n vaatimukset [FDA]. Nuo vaatimukset kohdistuvat kaikkiin testausvaiheisiin (sekä kehittäjä että testaaja), mutta myös kaikkiin ohjelmistokehityksen vaiheisiin. Tämä standardi on yksi parhaita esimerkkejä tarpeesta tuottaa tietynlaisia raportteja (esim. Loppuraportti) ja tehdä testausta tietyssä järjestyksessä (esim. sekä kehittäjän että testaajan toimesta). Monet terveydenhuollon alan toimijat ovat näistä testauksen rakenteellisista vaatimuksista huolimatta menestyksekkäästi siirtyneet ketteriin toimintatapoihin, mutta läpäistäkseen FDA:n vaatimukset heidän täytyy lisäksi tuottaa määrämuotoinen dokumentaatio suunnitelluista testeistä, testien tuloksista ja vikaraporteista jäljitettävyyksineen. Käyttämällä sopivia testauksenhallinnan työkaluja tämä onnistuu.
Uusimpia viimeaikaisia esimerkkejä jonkin säädöksen mukaisuudesta on paljon tietojärjestelmien kehittäjiä ja tilaajia puhututtanut uusi eurooppalainen tietosuojalainsäädäntö[EUGDPR]. Olemmeko GDPR:n mukaisia? Pitkälti tämä liittyy tietojärjestelmien pitämien rekisterien kykyyn hallita itseään. Koska GDPR esittelee joukon oikeuksia yksilölle
- saada tieto omien tietojen vuodosta
- saada pääsy omiin tietoihin
- saada tiedot pois rekisteristä
- saada tiedot mukaansa
- rajoittaa tietojen antaminen vain niille, jotka niitä tarvitsevat
- saada vastuuhenkilö tietojen säilöntään.
GDPR toteutuu, jos tietojärjestelmä pystyy hoitamaan näitä asioita. Usein GDPR-implementaatio tarkoittaakin jonkin aineistonhallintaohjelmiston käyttöönottoa. Testaus taas lähtee liikkeelle näiden mainittujen skenaarioiden testauksesta, tarkastelleen koko ajan, mitä tapahtuu tietokannassa, kun jokin operaatio on tehty. GDPR on myös hyvä esimerkki säädöksestä, jossa hyvin suuri osa säädösten mukaisuuden työtä on tietojärjestelmän määrittelyä ja ohjelmointia, ei niinkään testausta. Näin tietysti tavallaan on tilanne kaikkien säädösten kohdalla, mutta monet säädökset jättävät vapauksia siihen, millä lailla tietojärjestelmä on toteutettu, kunhan sitten lopuksi voidaan testauksella todentaa, että ollaan säädösten mukaisia. GDPR taas ei toteudu testausta päälle liimaamalla, vaan tietojärjestelmään pitää esim. rakentaa kyky paikallistaa mikä tahansa tieto teratavuista käyttäjädataa ja sitten kyky poistaa tuo tieto kokonaan. Muuten vaatimus saada käyttäjän tiedot pois rekisteristä ei toteudu.
Summa summarum, eri aloilla on erilaisia säädöksiä ja niiden mukaisuutta voi ja täytyy sekä testata että toteuttaa jo määrittelyssä ja toteutuksessa. Paras yhtälö on, kun testauksen kattavuus ja säädösten vaatimukset saadaan yhdistettyä samaan tehokkaaseen testaajan ajankäyttöön.
Kari Kakkonen on tuotantotalouden DI Aalto-yliopistosta. Kari työskentelee Knowitilla Suomessa Lead Consultant ja Director, Quality and Competences -rooleissa. Kari on International Software Testing Qualifications Board (ISTQB):n johtoryhmän varainhoitaja ja Finnish Software Testing Board (FiSTB):n puheenjohtaja. Hän on TestausOSYn (Finnish Association of Software Testing) ohjausryhmässä. Kari on valittu 100 tietotekniikkavaikuttajan joukkoon ja hän on yksi Agile Testing Foundations –kirjan kirjoittajista.