Tuesday 21 June 2011

Testaajat ovat rokkitähtiä!

Teemu Vesala kirjoitti STC:n blogissa testauksesta verraten sitä runoiluun. Se polkaisi käyntiin ajatuslennon, jossa huomasin vertaavani testausta (substantiivina) klassiseen musiikkiin. "Testaustyö on kuin klassisen musiikin säveltämistä kaikkine nyansseineen" oli hyvin pitkälti oman kommenttini sanoma ko. blogissa. Tästä alkoi kuitenkin twittaus, joka meni näin:

Teemu Vesala:
Poem writing and #testing has plenty of common. See my blog entry @ #stc http://ning.it/jF60aR

Pekka Marjamäki:
@teemuvesala #Testing is more like composing classical #music: even the tiniest sounds change the feel to it. And testing tells a story.

Teemu Vesala:
@pekkamarjamaki Acctually #testing is much like any art. No matter if it's poetry, music or painting. All have same properties.I love'em all
Testaus on verrattavissa taiteeseen, kyllä, johtuen kaikista nyansseista mitä testaus sisältää. Vaan mikä ei olisi verrattavissa taiteeseen? Mitä taide on?

Wikipedia (ah! tuo tiedon ehtymätön lähde!) sanoo taiteesta näin:

Taide on yksi kulttuurin peruskäsitteistä. Se koostuu erilaisten elementtien tarkoituksellisen järjestelyn tuloksista ja prosesseista, joilla pyritään vaikuttamaan tunteisiin tai ajatteluun subjektiivisella tasolla. Taide on ilmaisun, viestinnän, kannanoton ja mielihyvän tuottamisen väline.
Voiko testaus olla kulttuuria? Hyvä kysymys. Voiko testaus olla olematta osa projektikontekstuaalista (onkohan tuo edes sana?) kulttuuria? Testaus on se elementti, millä tarjotaan tietoa asioista, sillä testausta ilmenee niin monella tasolla tiedostamattomasta kyseenalaistamisesta systemaattiseen järjestelmien kokonaisuuden koestamiseen dynaamisesti ja staattisesti. Eli kyllä, testaus on osa kulttuuria (kontekstia) jossa testausta tehdään.

Testaus, kuten taidekin, on erilaisten osasten (tekniikoiden, lähestymistapojen, työvälineiden, strategioiden) tarkoituksellisen järjestelyn tulosta. Kuten sanottu, testausta voidaan suorittaa adhoc, mutta kuten taide, se ei aina vastaa niitä tarkoitusperiä, mitä sillä haetaan. Prosessi (ajattelu- tai kehitys-), johon testaus pyrkii vaikuttamaan, voi hyvinkin olla ainakin osittain subjektiivinen, koska se on mielipide ja tulkinta. Poistamalla subjektiivisuuden taiteesta saadaan aikaan pakotettuja kauneusihanteita, ei-älykkäitä tulkintoja asioita. Subjektiivisuus on taiteessa voima, joka tekee taiteesta taiteen. Testauksessa subjektiivisuus on testauksen itsensä kannalta ehdottomasti voimavara, sillä erilaiset ihmiset tulkitsevat erilaisia asioita eri tavalla. Me voimme aina sanoa että "joku asia on X. Piste!", mutta se ei välttämättä ole oikein jossakin kontekstissa. Subjektiivisuus tulee siis kontekstien myötä tärkeäksi.

Tunteisiin vaikuttamisesta olen jo aiemmin muutaman sanan ylös kirjannut. Ei siis voida vähätellä sitä merkitystä, mikä tunteilla on testaukseen ja testauksella tunteisiin. Molemmat näistä ovat toisiaan ohjaavia tekijöitä. Taiteessa säveltäjän, maalarin, koreografin, kuvanveistäjän tunteet ovat eteenpäinvieviä voimia, jotka saavat taiteen aikaan. Toki on olemassa tunteetontakin taidetta, mutta onko se taidetta? Lisäksi on olemassa taidetta, joka ei vaikuta tunteisiin (tietyssä kontekstissa ja subjektiivisesti). Onko kaikki oleva jollakin tasolla taidetta? Taide pyrkii siis olemaan kaksisuuntainen tunteiden kanssa. Testaus myös: tuntemukset (käsitys riskeistä, priorisointi, jne) ohjaavat testausta ja testauksen herättämät tunteet ohjaavat päätöksentekoa.

Taide on ilmaisua, viestintää, kannanottoa ja mielihyvän/-pahan tuottamista. Tämä pätee testaukseen sanasta sanaan! Testaus on ilmaisua: me ilmaisemme järjestelmän sen hetkistä laatua testaamalla. Testaus on viestintää. Mitään muuta keinoa osoittaa ja viestiä laatua ei ole. Onko? Voidaanko koodaamalla ilmaista laatua? Ei koodaamalla luodaan se laatu, joka testaamalla ilmaistaan. Testaus ei tee laatua. Lisäksi kun puhutaan puhtaasti viestinnästä, testaus on sosiaalinen laji, jossa viestintä on tärkeä! Miten me voimme ilmaista laatua, jos emme viesti sitä viestikanavia pitkin sidosryhmille? Ja testaus ottaa kantaa! Michael Bolton sanoi hyvin: "Testin is defending the quality of the product." Testaus ottaa kantaa laatuun, testaus puolustaa tuotteen laatua. Jos testaus ei ota kantaa laatuun, kuka ottaa?

Mitä mielihyvään tulee, niin minulle jokainen testauspäivä tuottaa suurta mielihyvää (testaajani ovat sen varmaankin panneet merkille). Jokainen päivä, jona voin edistää testauksen voittokulkua sekä organisaatiossa että genrenä yleensä tuottaa mielihyvää. Jokainen päivä, jona opin lisää testauksesta, tuottaa mielihyvää. Joka kerta, kun löydän uuden vian järjestelmästä, se tuottaa mielihyvää (vaan mielipahaa projektipäällikölle ;) ).

Summa summarum: Testaus on taidetta. Testausta tulee arvostaa taiteena. Muistaakseni on olemassa matemaatikkoja, jotka ylistävät matematiikkaa suurimpana taiteena (fibonaccin lukuihin perustuvat graafit, kaaosteoreettiset kuvaajat ja fraktaalitaide). Testaajat ovat siis taiteilijoita. Me itseämme kunnioittavat, taitavat testaajat voimme pitää itseämme IT-maailman rocktähtinä (tai Leonardo da Vinceina). Me tuomme iloja ja suruja, viestimme tunteita, jopa kauneutta. Minulle, testaus on se suurin taide.

Sunday 19 June 2011

Testausheuristiikat 3/7

HICCUPPS
Tämä viittaa tuotteen testauksessa oraakkeleihin. Eli mihin voit perustaa havaintojen oikeellisuuden. Oraakkeli on kuten heuristiikan yleensä "ehkä päteviä omassa kontekstissaan". Oraakkeli siis kertoo /mielipiteen/, joka ohjaa toimintaa tavalla tai toisella. Oraakkelit koostuvat seuraavista: H = History, I = Image, C = Comparable products, C = Claims, U = User expectations, P = Purpose, P = Product itsef, S = Standards. Nämä ovat ylseensä jo testauksen aikana tapahtuvia heuristisia ajatusmalleja. Näillä voidaan mitata tuotteen yhteneväisyyttä jonkin oraakkein kanssa. Onko se yhteneväinen asiakkaan esittämien lupausten kanssa? Onko se yhteneväinen itsensä kanssa?

Historia antaa aina ideoita testaukseen. Miten tuote käyttäytyi edellisissä versioissa, eilen, jne. Tämä osittain sisältää myös bugilistat.

Yrityksen antama kuva toimii heuristiikkana silloin, kun testauksen kohde on räikeästi tai hienovaraisesti pois yrityksen antamasta linjasta. Esimerkiksi Officetuotteissa on samantyyppinen ulkoasu, joten linjasta poikkavien asioiden huomaaminen on helppoa. Toisaalta esimerkiksi vakavarainen vakuutustoimija saattaa haluta ilmaista järjestelmillään luotettavuutta, jota kirjoitusvirheet sivuilla eivät edusta.

Verrokkituotteet ovat äärimmäisen hyvä oraakkeli. Jos on olemassa esimerkiksi tuotantoversio, johon tehdään päivitys, voidaan alkuperäisestä varmistaa toimintojen käyttäytymistä. Jos kilpailijalla on saman tyyppinen tuote, sitä voidaan käyttää vertailuun.

Lupaukset ja julkaisut ovat omiaan tuottamaan testausideoita. Manuaalit, helppi-tiedostot, mainokset, jne. voivat tarjota ideoita, jotka käyttäjän näkökulmasta sotisivat lupauksia vastaan. Lisäksi käyttöohjeiden testaaminen sovellusta vasten voi olla hyödyllistä myös käyttöohjeen itsensä kannalta.

Käyttäjän odotuksien kanssa yhteneväisyydessä saatta olla ongelmia. Jos olettaa esimerkiksi, että ohjelma käynnistyy automaattisesti ja se vaatiikin pääkäyttäjäoikeudet, saattaa virheilmoitus aiheuttaa närää käyttäjällä. Odotukset ylipäänsä ovat vahva oraakkeli, koska ne viittaavat siihen miten oikeasti tuotetta käytetään.

Tarkoituksen vastaan sotivien asioiden testaus saattaa herättää mielenkiintoisia kysymyksiä. Onko tarkoitus, että sääennustussovellus täyttää veroilmoituksesi? Onko tarkoituksenmukaista kaksoisklikata linkkiä, jos yksi painallus selvästi riittää?

Tuote itsessään voi olla ristiriidassa itsensä kanssa. Esimerkiksi saman tiedon näyttäminen samassa järjestelmässä eri tavalla. Tämä saattaa horjuttaa luottamusta tietojen oikeellisuuteen ("Älä pidä kahta kelloa laivassa. Jos toinen on väärässä, niin mistä tietää kumpi on oikeassa."). Ongelmia voi tulla eri näkymien erilaisuudesta tai vaikkapa virheilmoitusten yhteneväisyydestä.

Lait, asetukset, standardit tuovat oman mausteensa testaukseen ja yhtenevyys lakeihin esimerkiksi vakuutus- tai ilmailuhallintajärjestelmissä voi aiheuttaa jopa vaaratilanteita. (Se että turvallisuuskriittisten järjestelmien testaus ei aina ole viisasta pelkästää heuristiikkoja hyväksikäyttäen, on aivan toinen lukunsa.)

Testausheuristiikat 2/7

CIDTESTD

Tämä heuristiikka viittaa projektiin ja ympäristön tuomiin testausajatuksiin. C = Customer, I = Information, D = Developers, T = Test team, E = Equipment, S = Schedule, T = Test item, D = Deliverables. Näillä heuristiikoilla on tarkoitus suunnitella ja priorisoida tulevaa testausta. Näillä heuristiikoilla helpotetaan kontekstin havaitsemista, ja tuotteen ja testaajien sijoittumista ympäristöönsä.

Asiakkaan tapauksessa testi-ideointi tapahtuu lähinnä sellaisella tasolla, että "mitä tietoa asiakas voi meille tarjota ko. asiasta, jota emme jo tiedä tai ole huomanneet kysyä". Tämä ei siis tarkoita, että asiakas on testausidea itsessään, mutta asiakkaan huomioiminen testausta ideoitaessa voidaan löytää asioita, joita projekti tai projektiryhmä itsessään ei pystyisi tarjoamaan. Asiakasta kannattaa ja pitääkin kyseenalaistaa, koska usein on niin, että asiakas ei itsekään aivan tarkkaan tiedä mitä haluaa. Kyseenalaistamalla voidaan parantaa asiakkaan tietämystä omista haluistaan ja vaatimuksistaan. Testaajalla on suuri rooli parantaa kaikkien sidosryhmien tietämystä ja ymmärrystä tuotteesta.

Informaation toimii heuristiikkaana käytännössä asettamalla fokuksen dokumentteihin. Tässä kohtaa painota, että dokumentteihin luottaminen ei saa olla testauksen pääasia. Dokumentit ovat vanhentuneita, viallisia, saavuttamattomissa, jne. Ne saattavat kuitenkin sisältää sellaista tietoa, mitä testauksessa tarvitaan. Ne ovat yksi heuristiikka eli ne "voivat olla päteviä ko. kontekstissa". Dokumentit ovat kuitenkin hyödyllisiä ja niiden olemassaoloon on usein syy. Ne tapaavat tuoda lisää tietoa asioihin, mutta niihin ei kannata sokeasti luottaa. Dokumentteihin pätee samat kyseenalaistamisen säännöt kuin ihmisiinkin!

Kehittäkät ja testaustiimi tuovat oman panoksensa testien ideoinnissa. Testausryhmän sisäinen dynamiikka yleensa johtaa tiettyihin painotuksiin ja jokaisen panos on tärkeä testi-ideoita mietittäessä. Jokainen nimittäin testaa eri lailla ja jokaiselle eri asiat ovat tärkeämpiä kuin toiselle. Kehittäjien mielipiteet, taidot, mieltymykset antavat myös omat ideansa testaukseen. Jonkin kehittäjän tuotteista saattaa löytyä tietynlaisia vikoja, joten kehittäjän passiivinen mukanaolo saattaa tuoda ideoita testaukseen. Tämän takia kannattaa aina käyttää ideoinnissa mukana eritasoisia ja jopa eri ryhmien asiantuntijoita. Taas kerran: käytetään hyväksi kyseenalaistamista ja kysymistä, jotta saadaan esille ne asiat, jotka pitää saada esille.

Työkalut, välineet, ympristöt vaikuttavat omalta osaltaan testaukseen. Voidaan miettiä asioita työkalujen kannalta ottamalla huomioon käytössä olevat työkalut ja niiden hyväksikäyttäminen testauksessa sekä tarpeet työkaluille, joita mahdollisesti tarvitaan. Esimerkiksi testausryhmässä on kokemusta suorituskykytestaustyökaluista, mutta integraatiotyökalut ovat vähemmän käytettyjä. Voisiko heuristiikkana olla tehdä tutkivaa testausta integraatiotyökalulla? Olisiko yrityksessä joku integraatioasiantuntija? Aikataulu saattaa myös herättää testausaiheisia kysymyksiä priorisoinnista ja testausryhmän kokoonpanosta. Aikataulu tuo yleensä oman leimansa testauksen suorittamiseen. Esimerkiksi aikataulun yhdistäminen vaikkapa asiakkaan vaatimiin suorituskykytesteihin määrittää tiettyjen alueiden testaamisen ennen toisia. Tai jos toteutus on pilkottu releaseihin, joissa testaus pitää kohdistaa tiettyihin osa-alueisiin, koska toisia ei ehkä vielä ole toteutettu.

Testauksen kohde on aina hyvä herättämään kysymyksiä: "Mikä tämä on? Mitä se tekee?" Se herättää todennäköisesti jatkokysymyksiä ja nostaa muita heuristiikkoja esiin. Jamesbachmainen heuristiikka "Huh? Really? So?" (HRS) pätee hyvin usein, kun kysytään ihmisiltä juuri noita kysymyksiä. Kyseenalaistamalla saamasi vastauksen testauksen kohteesta voi nousta uusi kysymyksiä ja ehkä juuri ne kysymykset ovat niitä, mitkä pitää kysyä.

Testaustuotteet voivat myös nostaa ideoita, esimerkiksi bugilistoista voi löytyä ideoita. Kaikki testauksen tuottama materiaali, opitut asiat, raportit, jne. voivat nostaa asioita esiin, joita täytyy miettiä tässä kyseisessä testausprojektissa. Testaustuotteena on tietenkin myös taitopääoma, joten käytännössä kaikki testausmateriaali ja taito, mitä yrityksessä on saatavilla kannatta jollakin tasolla hyödyntää.

Heuristiikan käyttäminen toimii myös muussa kuin dynaamisessa testauksessa. Kyseenalaistaminen ja katselmointi hyödyntävät myös näitä heuristiikkoja. Jokainen kehittäjä pystyy parantamaan omaa työtään kyseenalaistamalla määrittelyitä tai suunnitelmia hyväksykäyttäen testaukseen käytettäviä heuristiikkoja. Eikä pelkästään projektin alkuvaiheessa vaan pitkin toteutusta ja lopulta koodin valmistuttua koodikatselmoinneissa ja korjaus/muutospyynnöissä.

Testausheuristiikat 1/7

Kuten jo taannoin mainitsin, olin Rapid (vai oliko re rabid) Software Testing -kurssilla Suomen kauniissa pääkaupungissa. Kurssi veti testausalan kirkkaimpiin tähtiin kuuluva Michael Bolton. Kurssilla käytiin läpi asia jos toinenkin, mutta yhtenä osa-alueena siellä oli heuristiikkojen käyttö tutkivassa testauksessa.

Heuristiikkojen käyttö ei tarkoita sitä, että sinulla on checklist, jonka sitä tarkistat läpi softassa ja sen jälkeen softa on testattu. Heuristiikan voivat olla päteviä ko. kontekstissa tai olla olematta. Niiden tehtävä on tarjota ajattelulle lähteitä jotta itse testi-ideoiden luominen olisi helpompaa. RST-kurssilla heuristiikat oli niputettu listoiksi, joista tuli anagrammeja tai muistisääntöjä muistamisen helpottamiseksi. Näiden heuristiikkojen muistaminen voisi varmistaa sen, että kuljen koko ajan päässäsi satoja testi-ideoita mistä tahansa testattavasta aiheesta.

Muistisäännöt ovat lontoonkielellä seuraavaa: CIDTESTD (kid tested) , HICCUPPSS (hickups) SFDPOT (San Fransisnco Depot), CRUSSPIC STMPL (Crosspick Stample), FDSFSCURA (Fed-Jeff's Curae).

Jaan nämä heuristiikkamöhkäleet lukemisen helpottamiseksi omiksi blogimerkinnöiksi, joten näitä tulee tippumaan tänne sitä mukaa, kun saan näitä hiottua.

Wednesday 8 June 2011

Täh?! Oikeesti?! Mitä sitten?!

Michael Bolton mainitsi kollegansa James Bachin käyttävän äärimmäisen tehokasta kyseenalaistamisen heuristiikkaa: Huh? Really? So? (aiemmin viittamani HRS-heuristiikka) Päätin ottaa itsekin tuon heuristiikan käyttöön ja olen nyt kokeillut sitä erinäisissä tilanteissa, jopa testannut omia puheitani ja kirjoituksiani tuon heuristiikan kautta.

Huh? Täh? Siis mitä?

Oletko koskaan istunut neukkarissa, kun joku "sankari" esittää kuninkaan elkein hienoja prosessimalleja tai pitää yhteenvetoa asiasta, josta et ole kuullutkaan? Sinut on kutsuttu paikalle, koska se ehkä liippaa sinun asiantuntemusaluetta jollakin tasolla (normaali kriteeri palaverikutsulle). Mies tai nainen edessä selittää, osoittelee graafeja ja vuokaavioita, ja jokatoinen neukkarissa oleva henkilö piirtelee tikku-ukkoja paperin reunaan tai näpyttelee puhelintaan. Osa saattaa jopa tuijottaa taululle, koska luulee ymmärtävänsä jotakin, mutta silmissä on tyhjä katse.

Tässä vaiheessa taitava testaaja kysyy: "Täh?" Kaikki tuijottavat testaajaa kuin tämä olisi sanonut jotakin tyhmää - varsinkin "sankari". "Niin mitä tämä tarkoitti? Voitko selittää tämän niin, että testaajakin ymmärtää? En ehkä ole käynyt kaikkia kouluja enkä ole tehnyt kehitystä vuosia, mutta tiedän kuitenkin että en ymmärrä kaikkea, mitä sanot. Onko minun tarpeellista siis edes ymmärtää tätä (ja päätellen paikallaolostani ON)? Mielestäni on. Voitko siis kertoa, mitä tuo tarkoittaa?" Tässä vaiheessa kynät lopettavat tuhertelun ja kännykät menevät taskuun.

Muut ajattelevat ehkä: "Olipas fiksu testaaja. Vitsi, kun olis itse ymmärtänyt kysyä asiaa hetki sitten, niin en olisi niin pihalla." Kukaan tuskin ajattelee, että "onpa tyhmä kaveri kun ei ymmärrä, mistä puhutaan". Todennäköisesti tässä vaiheessa "sankari" selittää hieman matalammalla tai korkeammalla tasolla (riippuen kumpi on selkeämpi tai hänen mielestään selkeämpi). Tämän jälkeen suurin osa kallistuu tuolissaan taaksepäin ja alkaa taas tuhertelemaan. "Anteeksi, en kyllä vielä ymmärtänyt. Meneekö se oikeesti niin?"

Really? Oikeesti? Ootko ihan varma?


"Sankari" tuijottaa ja toteaa, että näinhän se menee. Esimerkkiä pyydettäessä taas kaikkien mielenkiinto palautuu. Nyt "sankari" esittää prosessimallia hieman käytännön tasolta tai raporttia henkilönäkökulmasta. Tässä vaiheessa testaajalla nousee useita kysymyksiä käytännön asioita. "Entäs tapaus 1? Entäs tapaus 1a?"

Tässä vaiheessa muut ajattelevat, että "olisiko minun pitänyt tietää kysyä näitä asioita? Olenko niin fiksu, kun luulen olevani?" Sankari kysyy tätä varmasti itseltään. Kun sankari on joko "oikeesti" pystynyt selittämään asian tai todennut, että ei ole miettinyt asiaa tuolta kantilta vaikka olisi ehkä pitänyt. Taas porukka rentoutuu... "Mitä tällä siis haetaan? Miksi näitä asoita esitellään?"

So? Mihin se johtaa? Mitä sitten?

... ja taas porukan mielenkiinto nousee taas. "Tämä saattaa koskea minua. Tämä seuraava lause voi vaikuttaa minun tulevaisuuteeni tai työntekooni."

Testaajan tehtävä on nostaa esille asoita, mitä muut eivät ole vielä osanneet miettiä. Testaajan tehtävä on tarjota tietoa asiayhteydestä siitä kiinnostuneille sidosryhmille. Testaaja itse on osa yhtä sidosryhmää, joten hänen tehtävänsä on vaatia se tieto, mikä hänelle kuuluu. Ei ole olemassa tyhmiä kysymyksiä - on olemassa kysymyksiä, joita pidetään tyhminä kunnes ne kysytään. Usein on tyhmää olla kysymättä. Näiden "tyhmien" kysymysten tarkoitus on herättää uusia kysymyksiä - kysymyksiä, joita kukaan ei ole vielä kysynyt. Käyttäkää tätä heuristiikkaa tulevissa palavereissa ja olkaa kriittisiä. Kyseenalaistakaa oma toimintanne siinä missä muidenkin.

Todennäköisesti palaverin jälkeen muu porukka kyselee asioita testaajalta eikä "sankarilta".