Laatufantasia pilaa parhaankin projektin

“Hyvä idea!” tuumasi Päivi Projektipäällikkö. Tuotekehityksen budjettihan on ilman muuta järkevää jakaa siten että testaus ostetaan palveluna sitten kun sitä tarvitaan. Tehdään ensin testauskierros ensimmäiselle release kandidaatille. Tulosten perusteella korjataan virheet ja toisella kierroksella veridioidaan, että kaikki meni putkeen. Kaksi kierrosta riittää!

Päivin tyylillä toimii hämmästyttävän moni softaprojekteja ja -tuotteita tekevä yritys. Lähestyminenhän on ihan huippujärkevä niin kauan kun

• Uusia testejä/käyttötapauksia ei enää tule,
• Tuote ei muutu millään tavalla muuten kuin bugikorjausten osalta ja
• Bugikorjaukset eivät koskaan riko muita toiminnallisuuksia

Tällaisissa projekteissa käy lähes poikkeuksetta niin että aikataulu kusee testauksen astuessa kuvaan. Alkuperäiset odotukset nimittäin ovat hyvin epärealistiset. Virheitä löytyy aina odottamattoman suuri määrä jo ensimmäisellä kierroksella. Deadlinet paukkuvat, koska korjaaminen vie odottamattoman paljon aikaa. Yleensä ensimmäisellä kierroksella kuvaan astuvat myös testit joille lyödään “cannot run” -leima. Tämä johtuu siitä että osa virheistä estää niiden takaa löytyvän toiminnallisuuden luotettavan testaamisen.

Verifiointikierroksella löytyy jälleen lisää virheitä pelkästään jo sen takia että tuote on tullut tutummaksi testaajille. Lisäksi todennäköisyys sille, että koodaajat saavat virheettömästi korjattua kaikki oleelliset ongelmat, on oikeasti häviävän pieni. Päivin tyylillä myös yksi testauksen keskeisimmistä vahvuuksista jää saavuttamatta koko tiimillä. Se on oppiminen.

Älä siis pilaa hyvää projektia epärealistisilla laatufantasioilla.