Testaus ja laadunvarmistus napit vastakkain
Quality Assurance, QA tai Laadunvarmistus. Kuulostaa hienolta ja näyttää kovalta käyntikortissa. Harmi vain, että sillä on hyvin vähän tekemistä testauksen kanssa.
Työskentelin taannoin eräässä isomman mittaluokan projektissa testaajana. Minä metsästin bugeja. Tittelinä meillä testauksen ammattilaisilla oli “QA engineer”. Asiakkaan kanssa keskustelimme aina QA-asioista ja QA:ta puski tuutin täydeltä ja joka suunnalta.
Kun projektia oli painettu vuoden verran alkoi näyttää selvältä, että eihän tästä saada ikinä valmista tuotetta. Me ymmärsimme sen tehtyämme töitä noin 9 kk ja me uskalsimme jopa sanoa sen ääneen. Tuotteen omistaja ymmärsi sen haaskattuaan rahoitusta vielä 8 kk lisää. Tuo viimeinen 8 kk oli ehkä urani opettavaisinta aikaa. Silloin seulottiin armottomasti ongelmia ja koitettiin löytää ratkaisuja. Harmi vain, että ratkomista yritettiin täysin väärästä päästä. Kaikki nimittäin lähti liikkeelle testauksesta, eli meidän projektissamme laadunvarmistuksesta.
Teidän tehtävänne on varmistaa laatu. Tehän olette laadunvarmistajia! Miksi tässä projektissa kaikki menee metsään?
Niinpä. Tästä asetelmasta lähtee hämmästyttävän monen testaajan arkipäiväisimmät ongelmat. Testaajan kuvitellaan olevan vastuussa laadusta, vaikka todellisuus on täysin toinen.
- Testaajalla ei ole valtaa tehdä muutoksia koodiin
- Testaajalla ei ole valtaa tehdä päätöksiä releaseista
- Testaajalla ei ole valtaa tehdä päätöksiä projektijohtamisesta
- Testaajalla ei ole valtaa päättää aikatauluista
Saman kysymyksen ilmaan heitti myös Michael Bolton Rapid Software Testing -kurssillaan.
Why on earth would you call it quality assurance, when people doing it have no control over the quality?
Laadunvarmistus on hieno sana, mutta yleensä se on täyttä huuhaata. Ainakin minulla tulee laadunvarmistuksesta mieleen, että nyt testaajan on varmistettava tuotteen laatu. Näin testaajan työn oikeasti hyödylliset tavoitteet voidaan heivata heti romukoppaan. Sana laadunvarmistus asettaa ajatusmaailman väärille raiteille jo ennen kuin työtä on edes aloitettu.
Testaajan todellinen tehtävä ei ole rakentaa luottamusta tuotteen toimivuudesta. Testaajan todellinen tehtävä on tuhota väärin perusteltu luottamus. Silloin ei ole kyse laadunvarmistuksesta, silloin on kyse testauksesta.
P.S. Jatkossa tagilla “bolton” merkityt tekstit ovat matkaeväitä, jotka kirjailin ylös Michael Boltonin Rapid Software Testing -kurssilla Helsingissä.
Suosittelemme myös:
Ei testaaja tähti ole
Mitä tapahtuu, jos softaprojektista tulee vallan ja ylpeyden pelikenttä? Kun jokainen leiriytyy omaan kahvipöytäänsä ja toisia katsellaan vain...
Testaus 2011 seminaari ja vuoden testaajan valinta
Hei lukija! Tieturilla on tapana järjestää testausaiheinen seminaari joka kevät. Aiheet iskevät jälleen napakasti testauksen kuumimpien...
Testaus ei taputtele selkään
Liiketoiminnan kehittämiskonsultin tehtävä ei ole taputella asiakasta selkään ja sanoa, että tässä firmassa on hommat hyvin hoidossa....
Mainio teksti! Varmasti yksi jos toinenkin testaaja maailmalla on kuullut pomonsa kysyvän sen legendaarisen kysymyksen: Miksi testaustuloksissa on näin paljon punaista?
Normaali käytäntöhän on se, että viestinviejä mestataan. Testaaja on softarumbassa se viestinviejä. Tällainen toimintatapa johtuu lähes yksinomaan pomon kokemuksen puutteesta. Asioiden tehokas johtaminen vaatii myös asioiden ymmärtämistä. Jos katselee vain käyriä ja käppyröitä ja Pass/Fail -ratiota, asioita ei valitettavasti voi ikinä ymmärtää. Mutta nähtävästi sitä voi olla johtaja ymmärtämättäkin!
Juuri muutamia päiviä sitten näin erään sähköpostin otsikon, mitä ei ehkä olisi pitänyt nähdä: Featuret x ja y merkitty doneksi ilman testausta. Ala siinä sitten testaajana olemaan vastuussa tuotteen laadusta kun joku valopää päättää, että featureja ei tarvitse edes testata 😀
James Bachin samaiselta RST kurssilta jäi muutama vuosi sitten kotia vietäväksi kova tunnelautaus, jota kätin hyväkseni kursseilla ja blogikirjoituksissa.
On kumma miten testausasiat, joita oli opettanut, lukenut ja tehnyt ja jotka eivät sinänsä olleet uusia, muuttuivat toden teolla aivan joksikin muuksi, kun opettajana oli sellainen höryjyrä ja innostuksen lähde kuin Bach on. Sanoille, joista tässäkin blogikirjoituksessa puhuttiin tuli uutta sisältöä, kun joku tunneperäisesti ilmaisi sen, että eri testaustavoilla on todella eroa ja on olemassa asioita joiden puolesta tässä työssä kannattaa tasitella.
Muilta, jotka eivät ole vastaavaa ”herätystä” kokeneet, voi jäädä näiden kirjoitusten pointti ymmärtämättä, vaikka sanat ymmärrettäisiinkin. Niin urautuneita tupataan olemaan.
Niinpä niin. Testaus on osa laadunvarmistusprosessia ei laadunvarmistusta yksinään. Monesti on itsekkin saanut kuulla, että lienee testauksessa vikaa, kun tuote on huono tai ei valmistu ajallaan.
Toki testauksessa voi olla vikaa esim. ei ole tehty kenttätestejä, jotain työkalua ei ole voitu käyttää. Monesti noissakin tapuksissa juurisyy on ylemmällä tasolla. On ajateltu, että kenttätestit ovat liian kalliita, työkalun käytön opettelussa menee liikaa aikaa, testaus maksaa. Miksi näin sitten käy, johtuu siitä, että lähimmän puun näkee paremmin kuin koko metsän.
Laadunvarmistuksessahan on kolme tahoa, se joka löytää virheen/testaa tuotteen, se joka päättää korjataanko virhe ja se joka korjaa virheen. Mikään tahoista ei yksinään takaa hyvää laatua.
Kiitos Teppo & Jussi & Testipena,
Minua kiinnostaisi kovasti nähdä myös Bach livenä. Vaikka kurssin sisältökin olisi sama, uskon häneltä löytyvän silti vielä erilaista näkökulmaa samoihin asioihin ja nimenomaan lisää ajateltavaa aihepiiristä ”herätys” 🙂
Blogaaminen ja keskusteleminen tämän aiheen ympärillä on nimeomaan sitä, mitä meidän kaikkien tulisi kannustaa urautumisesta huolimatta. Asioilla ei ole tapana muuttua jos kukaan ei tee töitä sen eteen.
Testipena muotoili asian mielestäni hyvin: ”Testaus on osa laadunvarmistusprosessia ei laadunvarmistusta yksinään”. Lisäksi totean, että nykyaikainen testaus voi olla hyvinkin moninaista. Riippuu paljon projektista, tekijöistä, asiakkaasta, teknologiasta, jne että mikä se testauksen aito merkitys ja paikka kyseisessä projektissa on.
Olen ollut projektissa jossa testaus käytännössä päätti julkaisuista eli siinä testaus otti tavanomaista suuremman vastuun koko tuotteesta. Olen ollut projektissa jossa testiraportin tuloksilla ei ollut mitään merkitystä managementille. Olen ollut projektissa jossa kehitettävä tuoteidea oli niin kehno, että sitä ei testauksella tai koodauksella voinut pelastaa. Olen ollut projektissa jossa testaus hoiti ison osan asiakaspalvelusta. Ja lista jatkuisi vaikka ja kuinka.
Toki puhun vain oman kokemukseni näkökulmasta ja sen perusteella teen yhteenvedon, että testaus voi (ja saa) olla paljon. Meillä testauksen ammattilaisilla kannattaa näyttää omalla esimerkillä tuolla kentällä se, että mihin kaikkeen testaus itseasiassa pystyy.
Terve Ammattitestaaja,
Vedät mainiosti yhteen sen kuinka laajasti testauksella voi olla erilaisia vastuita. Minusta tässä tullaan yhä usein siihen, että testausihmiset eivät vain osaa kertoa testaajan roolista ja todellisista vaikutusmahdollisuuksista pomolle tai kodaajalle. Liian monet testausihmiset vain mutisevat kahvihuoneessa epäoikeudenmukaisesta kohtelusta silloin, kun pitäisi osata herättää päättäjät niistä oikeista juurisyistä.
”Testaus voi ja saa olla paljon”. Se on hyvin sanottu. Paljon on lisäksi kiinni siitä, että testaajan täytyy myös uskaltaa olla paljon 🙂
Kyllä vain Antti. Kuten aikaisemmin jo painotin, niin paljon riippuu siitä mitä tehdään ja millä porukalla, että mille uralle testauksen rooli menee. Roolit ja vastuut on hyvä sopia heti projektin alussa ja siinä on ammattitestaajalla iskun paikka, kun tuo muiden saataville kaikki ne mahdollisuudet mitä testaus voi olla. Itse olen onnistunut esimerkiksi nostamaan testaustiimin nuppilukua kun olen kertonut, että kuinka draammattisia parannuksia tuloksiin saadaan oikein ohjatulla testauksella.
Mainio juttu! (löysin tän blogin vasta nyt, siksi myöhäiset kommentit).
Omaan kokemukseen pohjautuen uskallan väittää, että liian usein projektipäällikkö tai vastaava resurssoi testaamisen vaikka se kuuluisi test managerille. Sitten kun projekti manageri soittelee alihankkijoille ja kuulee saavansa ”laadun varmistajia” hän on myyty ja ostaa niitä vaikkei tajua mikä on testauksen tarkoitus.
Sama pätee myös toisin päin. Olen itse testi manageri ja Kerran minuun otti yhtyttä erään suomalaisen konsulttifirman edustaja kysellen töitä; nyt oli kuulemma firman parhaita ”laadun varmistajia” tarjolla. Kerroin, että palkkaan he kaikki, jos he todellakin pystyy varmistamaan laadun ja tuottamaan tuotteemme ajoissa markkinoille. Arvaatte varmaan, montako palkkasin?
Me kaikki olemme tavoite orientoituneita. Jos testaajan tavoite on näyttää, että ohjelmisto toimii, niin silloin he tekee testejä, jotka ei löydä vikoja. Mutta jos tavoite on löytää vikoja, niin silloin niitä myös löytyy.. Kiitos hyvien testi tapausten. Tämän vuoksi, en ymmärrä, että testaajien tuli taata laatu. En edes myyntipuheissa.
Parempi myöhään kuin ei milloinkaan. Kommentit ovat aina tervetulleita 🙂 Hienoa, että jaat kanssamme myös henkilökohtaista kokemusta tällaisista asioista!
Saanko kysyä, miten löysit blogin alunperin?
En muista enää ihan 100-varmasti. Oisko ollut joku LinkedIn ryhmä (TestausOSY ?), jossa oli puhetta vuoden testaajan valinnasta?
Sepä hienoa 🙂