Olen viettänyt lähiaikoina aikaa perinteisen kehityksen, joskin inkrementaalisuudella maustetun, parissa. Teemat ovat hieman erilaisia kuin ketterän kehityksen ja testauksen osalta, ja ajattelin nyt lyhyesti tarttua yhteen lempiteemoistani: vaatimusten keskeiseen rooliin.
Perinteisissä projekteissa on varsin suuri kunnioitus vaatimuksia ja vaatimusmäärittelyjä kohtaan. Porukoissa nyökytellään, kun asiakas-toimittajasuhteessa toimittajalta tulee kohtuullisen kokoisia hintalappuja muutoksille, maustettuna kommentein "ymmärtämättömyydestä sakotetaan". Odotukset tilaajan taidoille määritellä asiat oikein ovat melkoiset, ja sitä myös muutoshallinnan perusteena on hyvä käyttää.
Vaatimuksia kunnioitetaan jopa siinä määrin että käytän siitä sanaa palvonta. Vaatimusten kanssa vietetään mahdollisesti vuosia ennen kuin mitään toteutetaan. Vaatimusdokumentit muodostuvat argumentoinnin aseiksi, eivätkä työkaluiksi tekemiselle.
Viimeisin inspiraation lähde tälle kirjoitelmalle oli oletus että "vaatimuksia vastenhan niitä testitapauksia on suunniteltava, ei sinne mitään muuta saa lähteä soveltamaan".
Minusta vaatimustenpalvonta on yksi yleisistä tehottoman ja heikkotuloksisen testauksen piirteistä. Vaatimuksia sopii palvoa toteuttajan testeissä, nehän kertovat asiat jotka on tarpeen vahvistaa. Testaajan näkökulmasta isossa osassa on etsiä asioita jotka jäävät vaatimusten väliin, ovat moniselitteisiä mahdollisesta hyvästä yrityksestä huolimatta.
Jos (kun) projektit lähtevät vaatimusten kirjaamiseen "yksiselitteisesti", saadaan aikaan uskomaton dokumentaatiomäärä, johon helposti haudataan merkittävääkin tietoa. Ei tämä silti tarkoita että mitään ei kirjata, mutta palvontaan viittaavat elementit ovat yleensä ikäviä.
Vaatimuksia vasten testisuunnittelu on eri asia kuin vaatimuksia hyödyntävä testisuunnittelu. Näkisin jälkimmäisen toivottuna tilana, jossa kirjatut vaatimukset asettavat rajoja sille mitä kohtuullisesti voidaan pitää "virheenä". Testaus voi ja toivottavasti löytää myös niitä "muutospyyntöjä" joiden puutteen vuoksi järjestelmät eivät käytännössä toimi. Rajaus näiden kahden välillä on varsinaista taiteilua. Viime kädessä kysymys tuntuu kuitenkin olevan rahasta: kenelle, keneltä ja kuinka paljon?
Tämä blogi on perustettu paikaksi pohtia mennyttä, nykytilaa ja tulevaa ohjelmistotestauksessa. Vaikka haluaisin kristallipalloni olevan kirkas, hämäryyttä riittää. Oppiminen on oleellista ja tämä toimikoon minulle oppimisen työkaluna. Sisarblogi englanniksi: http://visible-quality.blogspot.com
tiistai 29. syyskuuta 2009
Tilaa:
Lähetä kommentteja (Atom)
Lukijat
Blogiarkisto
-
►
2013
(2)
- ► joulukuuta (1)
- ► marraskuuta (1)
-
►
2011
(1)
- ► marraskuuta (1)
-
►
2010
(14)
- ► toukokuuta (2)
- ► huhtikuuta (1)
- ► maaliskuuta (1)
- ► helmikuuta (3)
- ► tammikuuta (3)
-
▼
2009
(12)
- ► marraskuuta (2)
- ► toukokuuta (5)
- ► huhtikuuta (1)
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.