Havainnot, virheet ja vaatimukset

En ole koskaan välittänyt mitenkään erityisesti ISEB/ISTQB:n terminologiasta, joka jaottelultaan on sinänsä selkiyttävä:
- error (virhe) on jotain mitä ihminen tekee.
- fault/defect (vika) on jotain mitä syntyy ohjelmistoon ihmisten tekemisten seurauksena
- failure (häiriö) on se mitä testaaja näkee kun ohjelmisto ei toimi

Tästä on päästy aina ihaniin keskusteluihin: virhetietokannat ovatkin itse asiassa häiriötietokantoja.

Olen tykännyt vetää mutkat suoriksi suomen kielellä, koska minusta tuo erottelu ja yritys täsmälliseen kielenkäyttöön ei ole koskaan taipunut suuhuni käytännön tasolla. On virheitä jotka ihmiset tekevät, on virheitä joita ohjelmistossa on ja virheitä joita näkyy ohjelmistoja käytettäessä.

Lempimääritelmäni testaajan kirjaamille havainnolle tulee kirjasta Lessons Learned in Software Testing: "Bug = anything that might bug a user". Korvaan sanan user = käyttäjä kuitenkin sanalla stakeholder = sidosryhmä. Testaajana lähtökohtaisesti minua ei oikeastaan ensisijaisesti kiinnosta että onko havaintoni virhe ohjelmistossa, virhe määrittelyissä vai muuten vaan keskeiseltä tuntuva parannusehdotus. Toki usein projekteissa seuraavana pohdiskeluna lajittelen havaintoni - periaatteena siis kuka mielestäni maksaa korjauksen. Ja kiitän onneani silloin kun sillä ei ole väliä, niinkuin tuoteliiketoiminnassa usein on ja asiakas-toimittajasuhteissa juuri koskaan ei ole.

Lähdin tätä päivän pohdintaa kuitenkin kirjoittamaan ajatuksenani virheen (vapaasti määritellen) ja vaatimuksen ero. Kuuntelin Elisabeth Hendricksonin esitystä XP-testauksesta ja ihastuin yhteen hänen pointeistaan. Hän kertoi kokemuksestaan ja oivalluksestaan että toteuttajien kanssa rinta rinnan työskennellessään oli tajunnut, että monet asiat joita hän testaajana tuo esiin palautteena ovat itse asiassa toteuttajan näkökulmasta uusia vaatimuksia. Toteuttaja ei ehkä koskaan ollut kuullut / ajatellut vaatimusta että cross-site scripting -hyökkäys ei pitäisi olla sallittua.

Toimin nyt lähellä liiketoimintaa ja asiakasta. Henkisesti ainakin toistaiseksi vastustan ajatusta että vaatimukset pitäisi tilaajan toimesta kertoa äärimmäisellä yksityiskohtien tasolla ja korostaa jokaista yksityiskohtaa: "kyllä, me tosiaan sammutamme tietokoneet käskystä viikonlopuksi" ja "ei, emme sammuta tietokoneitamme joka työpäivän päätteeksi ja joskus emme haluaisi sammuttaa niitä kuukausiin".

On vaatimuksia ja vaatimuksia. Osa ohjelmistovaatimuksista voi ja pitää mielestäni kohtuudella tulla tekijäporukalta. Ketterien menetelmien osana on oivallettu että testaaja, tutkivaa testausta hyödyntäen, pystyy työstämään tälläisiä tekijäporukan tasoisia vaatimuksia yhteentoimivuudesta, pitkistä ketjuista ja erilaisista oleellisista tilanteista. Tämä tieto ei kuitenkaan ole testaajan salatiedettä, vaan koko tiimin opiskelusisältöä.

Muistiinpano itselle: pitäisi taas tarkastella mihin vaatimusten hallinnan kirjallisuus nykyään ehdottaa tuon rajan menevän. Jo vuosia sitten tiedettiin ettei vaatimusdokumentaatioon saa kirjattua lähellekään kaikkea.

Ihanan latautuneita sanoja. Jatkan siis havaintojen tekemistä.

Enkelin kärsivällisyys ja elefantin muisti

Kun tekee testaushommia ketjutettujen järjestelmien kanssa, tulee erityisen vahvasti sellainen fiilis että oma kärsivällisyys ja kapasiteetti ei meinaa riittää asioiden käsittelyyn ja läpivientiin.

Tässä testausmaailmassa ongelman löytäminen ei ole haaste. Ongelmien välissä luoviminen pidemmän päälle niin että löytää niistä merkittävän osan kun vanhoja ei tule korjattua on haaste. Ja ongelmista viestiminen on haaste.

Ensin pääsee yleensä keskustelemaan siitä että onko tehty havainto ongelmasta yleensäkään ongelma, vai voisiko jotenkin jo ihan käyttäjänä / testaajana tehdä jotain toisin - "eihän kukaan tee noin, ei ainakaan pitäisi". Sitten keskustelu jatkuu siitä onko havainto ongelmasta virhe suhteessa määrittelyyn vaiko määrittelymuutos, ja miten nämä määritellään. Lopulta vielä saatetaan ehdottaa että ketjussa korjaus pitäisi ollakin jossain ihan muualla kuin missä itse sitä kuvittelisi intuitiivisesti tarvittavan.

Tuntuu että testauksen tekeminen katoaa, kun testaajalta vaaditaan - otsikon mukaisesti - enkelin kärsivällisyys ja elefantin muisti.

Ketterien menetelmien korostuneita hyviä puolia on stop-and-fix mentaliteetti ja laatuvelan välttäminen. Valitettavasti vaan juuri tämä osa on yksi niitä vaikeammasta päästä olevia toteutettavia osia ketterään tekemiseen.

Parasta ennen päivämäärät testeillä

Projektipäällikkö on testauspäällikön ystävä. Onneksi näin välillä, valitettavasti ei vain aina. Aihetta pureskellessani erästä esitystä varten jäin miettimään erilaisia ongelmallisia suhteita projektipäälliköihin testauspäällikkönä toimiessani, ja olemaan hymyillen kiitollinen siitä hyvästä mitä joskus osuu kohdalle.

Ongelmalliset suhteet keskittyivät yleisesti ymmärryksen ja viestinnän ongelmiin. Jos itse on kovasti testaukseen ihastunut ja toisen osapuolen mielestä se on välttämätön paha ja oikeastaan sellaisenakin aika hyödytön, saattaa päätyä painokkaisiinkin sanakäänteisiin.

Eräs kohdalleni osunut varsin yleinen viestinnän ongelma projektipäälliköiden kanssa on koittaa selittää että testin tulokset eivät pysy vakiona. Erityisen tuskaisaksi tämä minulla on muodostunut ympäristöissä joissa on vahvasti mukana kaupallinen testauksen hallinnan työkalu, ja projektipäällikkö on "aseistettu" testauksen mittarein. Voi sitä projektipäällikköparkaa, joka koittaa tulkita edes kevyesti iteratiivisessa projektissa suoraan mittarista että onkos nyt kaikki testit suoritettu kertaalleen, kun minä mokoma omassa roolissani menen ja tyhjennän koko listan säännöllisin väliajoin.

Tästä pohdinnasta mieleeni muistui keskustelu erään kolleegan kanssa muutamia vuosia sitten. Hänellä oli ajatus parasta ennen päivämäärien käytöstä prosessidokumentaatiossa. Idea kaikessa yksinkertaisuudessaan oli että sen sijaan että prosessikuvaukseen pitäisi kirjoittaa päivä jolloin se on luotu, pitäisi viestinnällisistä syistä sanoa että kun se on ollut riittävän kauan olemassa, siihen pitäisi suhtautua vähän samoin kuin vanhentuneeseen maitopurkkiin.

Parasta ennen päivämäärät voisivat toimia testitapauksillakin mainiosti. Olen koittanut peukkulaaturaportoinnin yhteydessä harrastaa kolmatta peukkua kuvaamaan muutoksen määrää, eli tahtia jolla varaan oikeuden muuttaa mieltäni laadusta. Ajatusta vaatii minulta vielä hauduttelua, mutta tuntumaksi ajattelusta jäi että jokusen projektipäällikön kanssa olisi ollut yhteiselo helpompaa jos tälläisen konseptin olisi heti projektin alusta lanseerannut. Testien tulokset happanevat ja se kuinka nopeasti riippuu ympäristötekijöistä. Pitääkö ne sitten korvata tuoreemmilla onkin kokonaan toinen kysymys...

Pohdin projektipäälliköitä, mittareita ja ikuista viestinnän vaikeutta, kun muistiini palautui keskustelu muutaman vuoden takaa erään kolleegan kanssa parasta ennen päivämääristä ohjelmistoprosessidokumentaatiossa.