Elokuvista saa mielenkiintoisia laatupohdintoja. Katselin lasten kanssa Star Wars I: Pimeä uhka. Mielenkiintoisin kohta on, kun robotit sammuvat niiden menettäessä yhteyden komentokeskukseen. Ne hylkäävät välittömästi kaikki tehtävänsä ja siirtyvät romuksi.

Onko tuo oikea ja paras toiminto? Mielenkiintoinen kysymys. Vaihtoehtoina kun on tuo robotin kuolema tai sitten robotti voisi siirtyä autonomiseen tilaan jatkamaan aikaisempaa tehtävää parhaansa mukaan. Elokuvassa robotit kuitenkin ovat jo valmiiksi älykkäitä, melko inhimillisiä ja autonomisia.

Kumpi on suurempi riski? Robotin kuolema voi jättää robottien puolen sotilaat tilanteeseen, jossa vihollisella on mahdollisuus hyökätä heidän kimppuunsa eikä heillä ole puolustautumismahdollisuutta. Tappio on varma. Autonominen tila taas saattaa johtaa siihen, että robotit hyökkäävät myös omien kimppuun. Ensimmäisessä tilanteessa tappio on nähdäkseni huomattavasti varmempi kuin jälkimmäisessä. Varsinkin, jos robotit eivät pysty korjaamaan itseään ja osapuolet voivat olla pois planeetalta eivätkä planeetalla olevat robotit pysyt tavoittamaan heitä.

Testaajana ainakin nostaisin selvän järjestelmän luotettavuuteen liittyvän bugin. Jos järjestelmän toimittajalla ei ole selkeitä perusteita kyseisenlaiselle toiminnallisuudelle, se olisi melko varmasti korkean prioriteetin bugi. Tietoturvan kannalta tuo on selvä heikkous, koska palvelunesto tapahtuu ”vain sillä”, että lapsi käy tuhoamassa komentokeskuksen kuten elokuvassa.

Onneksi vanhoissa Star Warseissa ei leikitty tietokoneilla niin paljoa kuin uusissa. Niissä ei tule niin paljoa mietittyä tietotekniikkaan liittyviä asioita. 😉

Usein muistamme avoimen lähdekoodin työkalut, kun teemme testausta, mutta voisimme oikeastaan käyttää avointa lähdekoodia myös oppimiseen. Ohjeet ovat hyvin yksinkertaiset: Ota jokin hauska softa, ala hakkaamaan sitä ja raportoi bugit. Kannattaa valita jokin sellainen ohjelma, jota kehitetään aktiivisesti.

Otetaanko kommentit tosissaan projektin yhteisössä? Riippuu projektista. Osa ottaa tosissaan, osa ei. Jos bugiraportti kohdistuu puuttuvaan ominaisuuteen, sitä ei todennäköisesti toteuteta ilman erittäin hyviä perusteita ja laajempaa tarvetta, koska ajatus on enemmänkin:”Jos jotain puuttuu, koodaa itse.”

Hyvin kuvattu, perusteltu ja jopa valmiiksi debugatut bugit korjataan melko varmasti. Aikaa kylläkin saattaa mennä paljon. Laajalti levinnyttä virhettä ei välttämättä korjata kunnolla, vaan pikaisella paikalla, joka jää elämään pitkäksikin aikaa.

Miksi näin kannattaa tehdä? Ainakin tietoturvatestauksen osalta se on opettanut minulle uusia tapoja löytää tietoturvavirheitä. Olen rikkonut mm. joitain Joomlan lisäkomponentteja, CMS Made Simplen ja TestLinkin. Joka kerta olen oppinut jotain uutta. Samalla yhteisö on saanut korjattua varsinkin tietoturvasta riippuvia bugeja. Kaikki ovat hyötyneet.

Laatukonsulttina joudun miettimään välillä omaa identiteettiäni ja olemassa oloani. Työ on sen verran monipuolista, että en voi sanoa:”Olen testaaja.” Ennemminkin taidan todeta:”Olen kaikkea muuta kuin tuotantokoodaaja (paitsi sitäkin voin päätyä tekemään).”

Missä roolissa sitä onkaan oltu muutaman viime vuoden aikana?

Testaus – useimmiten projektissa en ole päätoimisena perustestaajana, vaan sitä tulee tehtyä kiiretilanteessa. Roolini on olla tekninen ymmärtäjä ja tietoturva-analysaattori, jonka lisäksi käyttöliittymättömien osien testaaminen tulee mukaan.

Kirjastonhoitaja – tai oikeammin informaation järjestäjä. Hyvin monesti projektissa on niin kova kiire, että koodaajat ja muut eivät kerkiä laittamaan teknistä dokumentaatiota muuksi kuin kaoottiseksi kasaksi projektin wikiin. Tekninen testaaja taas on monesti riippuvainen juuri siitä informaatiosta, jota siellä on, joten sitten se tieto on pakko organisoida käyttökelpoiseen muotoon. Se on valtava homma. Saamassa syssyssä saattavat olla ajantasaisimmat tiedot myös vaatimusmäärittelyistä – kunhan jotenkin saa kaivettua ne useammasta eri sivusta.

Kirjailija – isoja dokumentteja on tullut kirjoitettua. Kirjallista taitoa vaatii konkretisoida abstrakti asia tai kuvata hyvin tekninen asia ”normaalille ihmiselle” ymmärrettävästä.

Rautalangan vääntäjä – Normaalille ihmiselle esimerkiksi tietoturva-aukon riskien esittäminen vaatii rautalankaa. Useampi bugi on päätynyt korjauslistalle korkealla prioriteetilla, kun sen seuraukset ja uhat on kirjoitettu auki. Silloin voi olla, että henkilöt on nimetty Eevaksi ja Lasseksi, joilla on aviokriisi tai romanssi.

Koodaaja – en ole siis tehnyt viimeiseen kolmeen vuoteen tuotantokoodia, mutta sitäkin enemmän on tullut koodattua työvälineitä ja testauksen automatisointia. Koodia on tullut väännettyä niin Execlin makrojen muodossa kuin Javaa osaksi testiautomaatiota, kuin erilaisia skriptejä helpottamaan raportointia ja muuta työtä.

3v1l h4x0r – tietoturvan testaaminen on täynnä ilkeyttä. ”Tuo näyttää hassulta – mitä nyt?” Demonstroin yhdessä projektissa asiakkaalle, miten yksi tärkeä tietoturvavaatimus rikotaan väkivallalla. Hommaan meni n. vartti, se oli hauskaa ja ilmeet olivat näkemisen arvoisia.

Koodin arvostelija – koodikatselmointia on tullut tehtyä. Aina ei riitä vain subjektiivinen käsite:”Koodi on hyvä.” Tarvitaankin objektiivinen ja todistettu näkemys siitä, että ohjelmistossa ei ole bufferin ylivuotoja eikä null-osoittimeen yritetä kirjoittaa mitään eikä siitä yritetä lukea. Siinä vaiheessa koodia on seinillä, lattialla, päässä ja ruudulla. Paperilappuja sitäkin enemmän, värikyniäkin löytyy.

Kirjallisuusarvostelija – dokumenttien katselmointi on välillä tätä. Juonesta ei ole niin väliä, mutta oikealla sisällöllä ja selkeydellä on.

Prosessipoliisi – monesti kiireessä pyritään oikaisemaan rajoittaviksi koetuista prosesseista. Kuitenkin prosessin ohittaminen merkitsee kaikista eniten testaajalle, koska silloin – melko – elintärkeä informaatio jää saamatta.

Näiden lisäksi montaa muutakin pientä hommaa on tullut tehtyä. Joten perustellusti kai voisi sanoa, että laatukonsultti on monitoimimies, jonka pitää hallita kaikkea. Mitähän muita rooleja vielä tulee nähtyä tämän työuran aikana?

Rakastan screenshotteja, koska yksi kuva kertoo enemmän kuin tuhat sanaa. Sain tämän näköisen ruudun Googlesta – luultavasti ei edes toistettavisssa. Hauskalta tuo kuitenkin taas näyttää.

Mistä on (pienet) testaajat tehty?
Ripauksesta ilkeyttä, jotta he löytävät virheet
kourallisesta tarkkuutta, ettei mikään jää huomaamatta
korillisesta viestintää, että varmasti muutkin ymmärtävät
monesta askeleesta luovuutta, jotta keksivät miten rikotaan
  kasasta kaaosta
  hyllyllisestä järjestystä
leveästä hymystä, jotta eivät liikaa pelottele
niistä on (pienet) testaajat tehty.

Tuon kysymyksen kysyin jokunen vuosi sitten ja se kysymys löi viimeisen naulan minun koodaja-uran arkkuun. Sukelsin pitkäksi aikaa etsimään vastausta, mitä laatu merkitsee. Vieläkään en  tiedä absoluuttista vastausta kysymykselle, mutta monesti tiedän osittain kontekstisidonnaisen vastauksen.

Paras asia, joka tuon tutkimisesta päähän on tarttunut, on laatumallit. Laatumallit ovat yksi arvokkain työkalu, jota voidaan käyttää testauksen suunnittelussa ja priorisoinnissa. Liian usein ollaan tilanteessa, jossa annettu aika ei riitä testaamaan koko sovellusta ja sen kaikkia ulottuvuuksia kunnolla. Silloin asioita täytyy priorisoida. Ominaisuuksien painottamisessa on hyvä lähteä liikkeelle riskienhallinnasta. Se ei kuitenkaan riitä, vaan asiakkaan tyytyväisyyden kannalta olisi hyvä tietää, mitä laatu hänen mielestään tarkoittaa.

Laatu on liian abstrakti käsite yksinään – sen olen havainnut, koska en vieläkään tiedä absoluuttista määritelmää sille. Jos haluan kysyä ihmiseltä, mitä hän pitää laadussa tärkeänä, minun pitää esittää hänelle jokin konkreettinen jaottelu sille. Silloin laatumallit ovat hyvä lähtökohta.

Laatumalleista suosikkini on FURPSS. Siinä laatu jaetaan toiminnallisuuteen (functionality), käytettävyyteen (usability), luotettavuuteen (reliability), suorituskykyyn (performance), tuettavuuteen (supportability) ja tietoturvaan (security). Niiden avulla päästään jo huomattavasti paremmin suunnittelemaan, miten rajalliset resurssit voidaan käyttää. Asiakkaalle noita pitää vielä tuostakin konkretisoida.

Kun laatumallia käytetään priorisointiin, pitää myös prioriteettien muutos ottaa huomioon. Muutoksen syynä voi olla testaajien havainnot ja raportointi. Tai sitten aikaa on syystä tai toisesta niin paljon, että yksi laatuominaisuus saadaan testattua tarpeeksi hyvin. Jälkimmäinen syy on kyllä niin teoreettinen, että sitä en kirjaisi minnekään.

Meidän työmme on usein abstraktin laatukäsitteen konkretisointia testattavan tuotteen kohdalla. Abstraktin laadun konkreettisin esitys on raportin kannessa oleva liikennevalotaulukko, joka kertoo, onko sovellus vihreä, keltainen vai punainen.

Minusta koodaustaitoisen testaajan olisi hyvä olla lähes joka testausprojektissa mukana. Minulle ainakin on tullut testauksen aikana lähes aina tilanteita, joissa kaipaan jotain elämää helpottavaa ohjelman pätkää tai työkalua. Työkalulla en tarkoita testauksen automatisointia, vaan mekaanisen ja yksitoikkoisen työn minimointiin tehtävää välinettä, joka säästää testaajan aikaa tärkeämpiin tehtäviin.

Yksitoikkoisen tarkastuksen suurin ongelma on se, että silloin tulee helposti virheitä. Jos oikoluen 100 sivua tekstiä, melko varmasti monet kirjoitusvirheet jäävät huomaamatta. Siksi käytänkin oikolukuun Wordin oikolukua.

Pidän tarinoista, joten muistelen hetken yhtä projektia. Testasimme web-sovellusta, jossa oli raportointi – kuten yleensäkin monissa laskutustietoa sisältävissä sovelluksissa. Minulla kuitenkin oli toteutustekniikasta johtuen vahva epäilys rinnakkaisuuden käsittelyyn liittyvistä virheistä. Ainoa tapa testata asia on tehdä valtava kasa raportteja useilla eri käyttäjillä ja tarkastaa niiden sisällön oikeellisuus. Testi suunniteltiin niin, että tukitaan raporttijono tuhansilla raporttikyselyillä.

Ensimmäinen ongelma: Miten lähetetään tuhansia kyselyitä eri käyttäjien sisäänkirjautumistiedoilla? Näpersin ”ihanan” skriptin, joka automatisoi prosessin. Toivottavasti en joudu enää ikinä siihen skriptiin koskemaan,  koska se oli lähes lukukelvoton.

Toinen ongelma: Miten tarkastetaan 10000 Excel-taulukkoa äärellisessä ajassa ja varmistetaan, että virheet eivät jää huomioimatta? Raporttien hyvä puoli oli se, että jos raportoitava ajanjakso oli sama kuin edellisessä raportissa, raportin sisältö luontiaikaan liittyviä kenttiä lukuun ottamatta sisältö on sama. Luontiajan vaihtelevuuden takia ei riittänyt vain tarkastussumman laskeminen joka lomakkeesta, vaan tarkastukset piti tehdä joka tiedoston sisällölle.

Laiskana koodaajana näpersin Javalla ohjelman, joka vertaili Excel-taulukoita. Sille annettiin alkuperäinen, vertailun kohde ja kerrottiin mitä soluja ei tarkasteta. Kaunis, helppo, nopea tapa käydä läpi valtava määrä Excel-taulukoita. Sen avulla havaittiin yhden raportteja tekevän koneen lokalisointiongelma, jota tuskin oltaisiin huomattu manuaalisessa vertailussa. Ainoa ero kun oli, että desimaalierottimena oli piste eikä pilkku. Virhe tapahtui noin 10%:ssa raportteja. Tylsä, yksitoikkoinen, valtavasti resursseja vaatinut homma teetettiin yksinkertaisella ohjelmalla vajaassa tunnissa.

Pitäisikö jokaisen testaajan osata koodata?

Luokaamme uusi kulttuuri ja tehostakaamme viestintää. Vaihdetaan tietoa aktiivisemmin. Miten? Aletaan kommentoimaan toistemme blogeja, pyritään yllyttämään muita kommentoimaan ja perustamaan omia blogeja tai jakamaan kommenttien kautta tietämystään, uusia ideoita ja kaikkea muuta laatuun ja testaukseen liittyvää sälää. Ajatusten vaihto on nopein tapa kasvattaa uusia menetelmiä.

Kerronpa tarinan: Erään työkaverin (hän saa itse paljastaa itsensä jos haluaa) kanssa satuimme olemaan samassa projektissa tekemässä hyvin erilaista testausta. Havaitsimme projektissa olevat ongelmat yhdessä ja aloimme keskustelemaan asiasta. Vaihdoimme ajatuksia ruokatauolla, josta sitten kasvoi vähitellen ratkaisu ongelmaan. Ratkaisu oli kaunis, innovatiivinen (kait) ja erittäin yksinkertainen, jolla olisi voinut helpottaa tuon projektin elämää.

Tuossa tärkeintä olivat: Ongelman ymmärtäminen, ongelman ääneen sanominen, yhteinen erilaisten tietojen ja osaamisen jakaminen. Siitä rakentui enemmän kuin kumpikaan olisi yksin omassa päässään pystynyt rakentamaan. Samassa roolissa voisivat blogit olla: Kommentoikaamme, pohtikaamme, ideoikaamme. Levitettäköön kommentointikulttuuri myös blogien ulkopuolelle.

Ugh. Olen puhunutkirjoittanut.

Laatukonsulttina käsite ”asiakas” on välillä hyvin mielenkiintoinen. Usein käy niin, että itsensä asiakkaaksi näkee se osapuoli, joka istuu rahakirstun päällä tai päättää hankinnasta. Hän kertoo, mikä on tärkeintä testauksen priorisoinnissa.

Hyvä – näin ehkä on. Mutta minusta tuo ei riitä, kun lähdetään pohtimaan käyttöön tulevan ohjelmiston laatua. Silloin minulle ”asiakas” tarkoittaa samaa kuin maksaja (sponsor) ja loppukäyttäjä (end user). Olisi kiva, kun joka projektissa olisi mukana yksi selvästi loppukäyttäjän edustaja kertomassa, mikä ohjelmistossa on hänelle tärkeä. Se saattaa yllättäen poiketa huomattavasti maksajan ajatuksesta.

Otetaan esimerkki: Tuote liittyy jotenkin pankkimaailmaan ja loppukäyttäjänä on normaali kuluttaja. Silloin lainsäädäntö luo hyvin paljon vaatimuksia järjestelmän tietoturvaan ja luotettavuuteen. Ne ovat maksajan näkökannasta tärkeimmät ominaisuudet. Sitten taas loppukäyttäjälle huomattavasti tärkeämpi ominaisuus saattaakin olla käytettävyys. Jos vain maksaja päättää, olemme testanneet yhden osan, mutta emme sitä, mitä saa loppukäyttäjän hyväksymään tuloksen.

Jatkossa kun kirjoitan ”asiakas” tarkoitan vähintään maksajaa ja lopullista käyttäjää.

Käytän säännöllisesti muutamaa sivustoa testauksen apuna.

Pravda (venäjäksi)
China daily (kiinaksi)
Al-Jazeer (arabiaksi)

Näiltä sivuilta on hyvä kopioida erilaisia merkkijonoja syötteeksi. Monet sovellukset testataan moneen kertaan jo kehittäjien toimesta länsimaisella merkistöllä. Useimmiten merkin pituus 7-8 bittiä tai maksimissaan 2-tavua vievä UTF-8-merkki.

Kun mukaan lisätään kyrillinen, kiinalainen ja arabialainen merkistö, testatuksi tulevat useamman tavun sisältävät merkit. Silloin mm. kenttien pituudet saattavat mennäkin väärin, koska huonosti toteutettu merkkijonon pituuden laskenta laskee vain tavujen määrät. Silloin voi käydä niin, että ohjelman käyttöliittymä ja ohjeet sanovat:”Voi syöttää maksimissaan 30 merkkiä”, mutta kiinalaisia merkkejä mahtuukin vain 10. Tai sitten pituudet tarkastetaan eri paikoissa eri tavoilla ja tietokanta ilmoittaakin virheen, kun kiinalaisia merkkejä on 15.

Onko sinulla joitain sivuja samanlaisessa käytössä?