Matti Vuori
Ketterien projektimallien potentiaalisia ongelmia ohjelmistotestaukselle
Lista on synteesi mahdollisista sudenkuopista, joita ketterät projektimallit voivat tuottaa testaukselle ja muulle laadunvarmistukselle. On tärkeää huomata, että hyviä puolia ei tässä käsitellä! Listan ongelmia esiintyy ennenkaikkea kokemattomissa yrityksissä ja yksiköissä, mutta onneksi silmät avautuvat vähitellen näille asioille. Keskeinen syy näille asioille on se, että ketterä toiminta onnistuu laadukkaasti vain silloin, kun asioita osataan tehdä kypsällä tavalla. Jos (yhteinen) osaaminen ei riitä, "ketteryyden" myötä palataan 1990-luvun kaaokseen, mikä on nimenomaan ollut monille organisaatioille kestämättömän kriisin tilanne, josta kehittyminen on aloitettu.
Hypetys
1. Joskus ollaan mukamas "ketteriä", vaikka toiminta on 1980-lukulaista täydellistä sekoilua - siihen aikaan oli testaus täysin mahdotonta. Testaajien pitää olla skarppeja ja estää ainakin johtajia huijaamasta itseään
2. Purismi. Ameriikan gurut toistavat, että heidän oppejaan pitää toistaa sellaisenaan - Se on valetta. Valheen taustalla on raha: gurut menettäv ät asemansa., jos ihmiset ajattelevat omilla aivoillaan. Juuri testaajien pitää ajatella omilla aivoillaan!
3. Ajatus, että ketterät projektimallit automaattisesti parantavat laatua - Ne voivat yhtä hyvin huonontaa laatua. Kyse on ihan siitä, mitä niiden mallien puitteissa tehdään.
Prosessien suunnittelu
4. Kuvitellaan, että yksi prosessi sopii kaikkialle - on kuitenkin jo pitkään ymmärretty, että ei ole yhden koon prosesseja: ydinvoimala ja pieni apuohjelma edellyttävät erilaista tapaa tehdä asioita
5. Toiminnan kehittämisen ammattilaiset ovat myös aina tienneet, että on ymmärrettävä konteksti, jotta prosessista voidaan tehdä tarkoituksenmukainen. Tämä merkitsee kaikkien ihmisten työelämän elementtien ymmärtämistä kulttuurista kommunikaatioon
6. Kehittäminen ja testaus pitää sovittaa kulloiseenkin kontekstiin
7. Sprinttien kuvitellaan olevan riittäviä - toimituksiin tähtäävien sprinttien jälkeen ei ole riittäviä prosesseja tuotosten ja julkistusten paketointiin ja testaukseen
8. Testauksen pääsuunnitelmaa ei tehdä - vaikka jokaisessa projektissa voidaan tietää aika hyvin, millaisia testausaktiviteetteja tarvitaan
9. Organisaation prosesseja suunniteltaessa kehittäjät dominoivat - ketterät prosessit ovat kehittäjien juttu; testaajilla tms. ei ole niiden edistämisessä samanalaista ajurin roolia (päinvastoin!)
Kehittämisen lähtötiedot
10. Arkkitehtuuria tai käyttäjien tarpeita tietylle konseptille ei selvitetä - siksi lähtökohdat ovat kevyet ja niiden validiteettia ei voida varmistaa
11. Loppukäyttäjien toiminnan heikko analyysi - Saatetaan luoda kevyitä skenaarioita, joita ei ole mitenkään validoitu. Testaukselle on heikko pohja.
12. Kehittämisen pitäisi perustua loppukäyttäjien tarpeiden tuntemiseen ja kontakteja heihin pitäisi luoda. Ketterät projektit regressoituvat usein "tuotepäällikkötuotekehitykseen", jossa tuotepäällikkö "edustaa" mukamas käyttäjiä, mutta oikeasti vain itseään.
Laadunvarmistusprosessit
13. Käytettävyyden varmistamisessa luotetaan asiakkaan edustajaan ja jatkuvaan vuorovaikutukseen - tämä on ihan sama tilanne kuin on ollut vuosikymmeniä ja joka on todettu täysin riittämättömäksi
14. Ei-toiminnallisia vaatimuksia ei määritetä. Ollaan liikaa skenaarioiden ja tarinoiden tasolla - Tämä on huononnus verrattuna systemaattisempaan käyttötapaus-analyysiin, joka sekin unohtaa joskus asiat, joita ei voi käsitellä luontevasti käyttötapausten kautta
15. Tuotteen laatua ei mitata, koska luotetaan "kommunikaatioon" - testaukselle on vaikeampaa osoittaa tilanne, jossa ollaan
Mekanistisuus
16. Paradoksaalisesti väheksytään manuaalista ketterää testausta! - ajatellaan, että automatisoidut yksikkö- ja integrointitestit riittävät. Vaarallista tietämättömyyttä!
17. Ketteryyttä halveksitaan - Scrum on oikeasti mekanistinen kone. Jos pitäydytään sen, ja siihen sidottujen periaatteiden puitteissa, ollaan koneita ja äärimmäisen kaukana ketteryydestä! Hyvä testaus pystyy soveltamaan erilaisia toimintamalleja ja menetelmiä aina tarpeen mukaan - ja ne voivat rikkoa puhdasta sprinttien päiväajattelua ja tuottaa siihen ristiriitoja
18. Simplistinen toiminnanohjaus - kaikki testaus halutaan nähdä atomisten tehtävien osana: speksaa - koodaa - testaa. Monitasoinen testaus ei toimi näin käytännössä.
19. Prosessipositivismin mutaatio. Ketterän toiminnan ajatellaan olevan jotain muuta kuin perinteinen prosessipositivismi, mutta oikeasti kyse on juuri siitä. Ero on vain näkökulmissa. - Jäykkien rakenteidensa vuoksi ketterä toiminta voi rajoittaa ajattelua ja testausta.
20. Hyvä ketteryys ei ole toteutuksen valintojen ketteryyttä, vaan ajattelun ketteryyttä. - Ei siis voimistelijan ketteryyttä, vaan vapautta toimia välillä kuin shakkimestari ja välillä kuin painonnostaja.
Suhde aikaan
21. Hirttäydytään sprintteihin, vaikka moni aktiviteetti tarvitsee enemmän aikaa , jona aikana kehittäjien on järkevää tehdä uusia asioita - regressiotestaus, yhteentoimivuustestaus, lokalisointitestaus, järjestelmäintegrointitestusa jne...
22. Sprinttirytmiin hirttäydyttäessä regressiotestauksen yms. aikajännettä kutistetaan murto-osaan ja sen laatu heikkenee - Ei ole mitään syytä tehdä kaikkia jonkin julkistuksen testauksia saman sprintin aikana
Realismin unohtaminen
23. Ketterien prosessien yksi kivijalka on toimiva yksikkötestaus - mutta oikeasti se on kehnoa tai täysin puuttuvaa ja siksi koko hommalta menee pohja
24. Ylipäätään koodin laatua pitäisi varmistaa kaikin tavoin, mutta esimerkiksi koodin staattisen analysoinnin ohjelmia hyljeksitään edelleen
25. Integrointitestausta ei tehdä - tehdään toki jatkuvaa tai tiivistahtista integrointia, mutta sitä ei pidä sekoittaa jatkuvaan tai tiivistahtiseen integrointitestaukseen! Onnistunut kääntäminen ei ole testausta
26. Automaatioutopia - täydellisesti automatisoitu testaus ei ole vielä koskaan onnistunut. Jos joku niin väittää, hän on ymmärtänyt testauksen liian kapeasti
Matalan tason laatuparadigmat
27. Yksikkö- ja integrointitestaus dominoivat ja järjestelmätestaus on kevyttä - hyvässä testauksessa on monta tasoa ja korostetaan moninäkökulmaisuutta. Koodilähtöisyys ei riitä. Koodi voi toimia vaikka miten hyvin, mutta softa ei
28. V-mallista on mukana vain alatasot - V-mallin ydintä eivät ole vesiputousmallin prosessit, vaan useat eri tasot, joiden olemassaolo on olennaista kaikissa projektimalleissa
29. Agile-mainen automatisoitu "hyväksymistestaus" on vitsi - oikea hyväksymistestaus on aivan jotain muuta kuin jonkin ohjelman logiikan validointi
Nykytoiminnan regressio
30. Unohdetaan useiden vuosikymmenten aikana kertynyt ymmärrys hyvästä testauksesta - se on helppo unohtaa, koska se ei ole vielä siirtynyt useimpiin organisaatioihin... jokainen uusi hype ylittää vanhan liian helposti
31. Moni organisaatio on jo pitkään tehnyt toteutuksia sprinttimallilla ja pohtinut tarvittavan testauksen perinpohjaisesti - Nyt tämä kaikki ollaan heittämässä romukoppaan, koska toiminta ei vastaa jotain formaalia ketterää mallia. Hullua!
32. Uusi toimintatapa, jonka piti olla testauslähtöistä muuttuukin toteutuslähtöiseksi ja testauksen kehittämisen esteeksi
33. Muutosten ja rekfraktoroinnin vaikutuksia ei hallita, koska käytössä ei olekaan oletettua yksikkötestauksen turvaverkkoa
Osaamattomuus
34. Tiimit ovat testaus-ignrantteja - Tiimeissä on harva saanut mitään testauskoulutusta
35. Osaamista ei osata arvostaa - Testauksen experttejä ei osata kuunnella tasa-arvoisesti
36. Vanha sääntö on: älä siirry ketterään toimintaan, ellet osaa tehdä asioita laadukkaasti - Monet organisaatiot eivät osaa. Puuttuu esimerkiksi testauksen kehittäminen kuntoon ja niiden asioiden siirtäminen ketterään maailmaan
Yhteistyö ja organisaatio
37. Kehittäjät dominoivat; testaajien rooli on heikko, sekundäärinen - kypsässä toiminnassa kaikki relevantit ammattiryhmät ja näkökulmat saavat välillä pääroolin
38. Erillisiä testaustiimejä ei integroida prosessiin riittävästi - prosessin ydintä on yksi tiimi; muita organisaation osia ei osata liittää mukaan vuorovaikutukseen tai työnkulkuihin
39. Toiminta on liian heterogeenista - liiallinen heterogeenisuus on vaarallista; se alkaa aina vinoutua jonnekin; polariteetti ja dialogi on aina paikallaan
40. Minne katoaa testauspäällikön rooli? - Vuosikymmenen verran on yritetty ajaa organisaatioihin ajatusta testauspäällikön tärkeydestä. Sille on vähitellen saatu resursseja ja ymmärrystä. Nyt se rooli on epämääräinen...
Lopuksi: Top 10
Yksikkö- ja integrointitestauspositivismi.
Matalan tason testaus ei monissa organisaatioissa käytännössä toimi.
Prosessien alkupää kehno.
Hirttäytyminen sprintteihin.
Siirtyminen ketteriin projektimalleihin, vaikka homma ei ole hanskassa.
Erillisten testaustoimintojen ja tiimien heikko integrointi.
Testaajien roolin epämääräisyys, läheisyyden ja riippumattomuuden vaikea hallinta.
Käsitesekoilu: testaus ketterissä projekteissa ei ole aina ketterää (miten voidaan nousta mestariluokkaan, jos perusasioita ei ymmärretä?).
Vaatimusten hallinta - laatuvaatimukset, testattavat asiat.