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ä.