Ohjelmistotestauksen työuupumus: 6 syytä & miten korjata se

Onko ohjelmistokehitystiimissä mahdollista luoda tilanne, jossa testaaja todennäköisesti uupuu työssään? 

Jos on, mitä testaajat voivat oppia tästä ajatuskokeesta? 

Osoittautuu, että ohjelmistotestauksen ammattilaisten työuupumus ei ole ohjelmistotestausalalla vain ajatuskoe – se on todellinen ja laajalle levinnyt ongelma, joka vaikuttaa moniin kehittäjiin, insinööreihin ja testaajiin.

Syvennyin ohjelmistotestauksen työuupumusongelmaan ja kysyin:

• Miltä työuupumus tällä alalla näyttää?
• Kuinka suuri ongelma se on?
• Mikä luo järjestelmiä, joissa ohjelmistotestaajat uupuvat?
• Miten voimme purkaa työuupumusongelman osiin – ja ratkaista sen?

Vastaukset – tai ainakin niiden alku – löytyvät tästä artikkelista.

Ohjelmistotestauksen ammattilaisten työuupumus IT-alalla 

Työpaikkaan liittyvä stressi on jotakin, jota monet meistä IT-alalla työskentelevistä kokevat. Olen varma, että sinullakin on osasi stressistä. Omassa tilanteessani työuupumuksesta on valitettavasti tullut näkyvämpi aihe viime vuosien aikana.

Onko työuupumus ongelma?

Kun kysyin Jonathon Wrightilta: “Kuinka suuri ongelma työuupumus mielestäsi on laadunvarmistuksen ammattilaisten keskuudessa?”, hän vastasi näin:

“Se on valtava ongelma. Kuuluisat sanat: Et voi jatkuvasti juosta sprinttiä.”

Jonathon Wright, The QA Lead Podcastin juontaja

Hän jatkoi selittämällä:

“Agilen ja DevOpsin kaltaiset menetelmät kannustavat ajatukseen, että kaikki pitäisi tehdä vielä ‘nopeammin’. Miten laadunvarmistuksen ammattilainen tuottaa mitattavaa arvoa epäonnistu nopeasti ja opi nopeasti -ympäristössä?”

Äskettäisessä QALeadin podcastissa nousi esiin ilmaus ‘hidasta, jotta voit nopeuttaa’. Ellei yrityksissä juhlita epäonnistumista (mikä on hyvin harvinaista), et auta tiimin muuta osaa etenemään joka kerta, kun epäonnistut. 

Vihje löytyy liikaa käytetyn Burndown-kaavion nimestä. Tarinan pisteiden määrään sitoutumisen pelillistäminen synnyttää epätervettä kilpailua.

"Sinut pakotetaan tekemään enemmän vähemmällä ja työskentelemään epärealistisen odotuksen mukaisesti, jonka mukaan työ voidaan toimittaa kahden viikon sprinteissä."

Jonathon Wright, The QA Lead Podcastin juontaja

Miltä työuupumus laadunvarmistuksessa näyttää?

Työuupumus ei ole ohjelmistoalalla yksittäinen ilmiö – mutta miltä se näyttää?

Tässä on ohjelmistotestauksen ammattilaisten vastauksia siitä, millä tavoin työuupumus näkyy laadunvarmistuksessa.

“Meidän on todistettava arvomme. Tiimit kertovat minulle olevansa ketteriä eivätkä tarvitsevansa testaajia.”

“Ahdistus. Laadunvarmistuksen ammattilaisten on vaikea olla murehtimatta ennen suurta julkaisua tai tuntematta olevansa vastuussa kaikista seurauksista.”

“Aikapaine. Testaajat ovat aina viimeisiä. Enkä koskaan saa tarvitsemaani aikaa. Lisäksi se puolittuu, koska kehittäjät myöhästyvät aikataulusta.”

“Epärealistiset odotukset. Voisin testata ikuisesti enkä silti pystyisi testaamaan kaikkea. Kerro tämä projektipäällikölle. Mitä hyötyä on testaajasta, joka ei löydä virheitä?!”

“Sen selvittäminen työlistan kohteista, mitä pitäisi testata, on lähes mahdotonta. Eikä kukaan mainitse poikkeustapauksia.”

“Hukka turhauttaa. Kehittäjät eivät pysty toistamaan virhettä, työlistan kohde on vanhentunut tai he ovat jo korjanneet sen.”

“Monet eivät halua rehellistä raporttia eivätkä varsinkaan huonoja uutisia. Kun pidät pääsi, asia voi muuttua henkilökohtaiseksi.”

Miksi työuupumusta syntyy?

Kirjallisuudessa luetellaan monia tekijöitä, jotka aiheuttavat stressiä ja lisäävät työuupumuksen todennäköisyyttä. On olemassa yksilöllisiä tekijöitä, kuten henkilökohtaisia toimintamalleja: ole täydellinen, pidä kiirettä, yritä kovasti, ole vahva tai miellytä muita. Lisätietoja saat tutustumalla transaktioanalyysiin. 

Lisäksi työympäristöstä aiheutuu kuormitustekijöitä. Suuri työmäärä, aikapaine, saavuttamattomat tavoitteet ja odotukset, hallinnan puute, kärjistyneet konfliktit, työpaikan menettämisen pelko, tyytymättömyys työhön, kiusaaminen ja työpaikkahäirintä sekä monet muut tekijät. Tunnemme ne.

Jonkin aikaa sitten aloin tarkastella työuupumusta systeemisestä näkökulmasta ja loin simulaatiopelin, jossa pelaajat voivat vaikuttaa ohjelmistokehitystiimin kohtaloon. He voivat ajaa tiimin jäsenet työuupumukseen tai luoda kaikkien aikojen palkitsevimman projektin. 

Simulaation ytimessä on työuupumusjärjestelmä eli järjestelmä, joka on rakennettu niin, että jotkut tiimin jäsenet päätyvät lopulta uupumaan. Voit saada esimakua pelistä blogissani.

Tämä systeeminen lähestymistapa toimii myös tiimin eri rooleissa. Olen tehnyt tämän käyttäjäkokemuksen ammattilaisille ja yllätyin siitä, kuinka helppoa nämä ihmiset on työntää työuupumusjärjestelmän kuormittavaan keskiöön. Erityisesti käyttäjistä huolehtiessaan he ovat valmiita ottamaan vastaan vielä yhden taistelun ja vaarantamaan oman jaksamisensa.

Alla sukellan Alan-nimisen laadunvarmistuksen ammattilaisen tarinaan ymmärtääkseni paremmin ja havainnollistaakseni työuupumuksen ongelmaa ohjelmistoalalla. 

Sen jälkeen kerron, miten työuupumusjärjestelmät syntyvät ja mitä voimme tehdä näiden järjestelmien parantamiseksi.

Henkilökohtainen tarina työuupumuksesta

Kun nyt olen varma, että pystyn rakentamaan laadunvarmistuksen ammattilaisille työuupumusjärjestelmän, esittelen teille Alanin ja hänen tarinansa. 

Alanilla on lähes vuosikymmenen kokemus ohjelmistotestauksesta ja erityisesti suorituskykytestauksesta. Hän on liittymässä kehitystiimiin. Tiimi on työskennellyt kymmenen sprintin ajan, ja ensimmäiseen julkaisuun on jäljellä vielä neljä sprinttiä. 

Millainen Alanin ensimmäinen päivä projektissa oli?

Alan: Minulla on paljon tehtävää. Ohjelmiston laatu on heikko. Odotan, että huomaamatta jääneitä virheitä on paljon, ja pelkään ongelmia, jos en löydä niitä ennen julkaisua.

Markus: Virheiden tunnistaminen on siis tärkein prioriteettisi laadun parantamiseksi?

Alan: Se on yksi osa kokonaisuutta. Odotamme myös paljon käyttäjiä. Ohjelmiston suorituskyky on äärimmäisen tärkeää, kun julkaisemme sen laajemmalle yleisölle. Tiimi odottaa innolla voivansa hyödyntää asiantuntemustani siinä.

Toistaiseksi Alan on melko optimistinen sen suhteen, että tiimin kanssa sovitut toimenpiteet parantavat ohjelmiston laatua. Valitettavasti yhden sprintin kuluttua, kun jäljellä on enää kolme sprinttiä, Alan ei vaikuta enää kovin iloiselta. 

Mikä on ongelmana?

Alan: Kaksi viikkoa olivat intensiiviset. En ole tyytyväinen edistymiseeni. Halusin tehdä ensimmäisen, yksinkertaisen suorituskykytestin, mutta olen kaukana sen saavuttamisesta.

Markus: Mikä estää sinua?

Alan: Tarvitsen kehittäjien tukea, mutta heillä on kädet täynnä töitä. Tarvitsin myös paljon odotettua enemmän aikaa ohjelmistoon tutustumiseen ja löytämieni virheiden raportointiin.

Markus: Pystyitkö testaamaan tiimin toimittamat uudet tarinat?

Alan: En oikeastaan, tiimi käytti aikansa niiden viimeistelyyn. Sprintin lopussa testaamiseen varatusta kahdesta päivästä jäljelle jäi vain puoli päivää. Jäin kyllä pidemmäksi aikaa ja työskentelin lauantaina, mutta olen kaukana valmiista.

Kun sprinttiä kaksitoista käsitellään retrospektiivissä ja jäljellä on enää kaksi sprinttiä, testaaminen on tärkein aihe: tuoteomistaja valitti Alanin löytämien virheiden määrästä.

Kehittäjä: Useimmat Alanin löytämistä virheistä ovat joko merkityksettömiä tai eivät ole virheitä lainkaan. Käydään ne ensin läpi ennen kuin teemme johtopäätöksiä.

Alan: Ohjelmiston pitäisi tehdä -asioita oli vaikea ymmärtää backlog-kohteiden perusteella. Määrittelystä olisi todella apua.

Kehittäjä: Vain kuolleen ruumiini yli! Emme halua vesiputousmallia. Tässä on enimmäkseen kyse maalaisjärjestä. Tule vain kysymään meiltä. Miten suorituskykytestaus etenee?

Alan: Olen jumissa. En saa työkalua toimimaan palvelukerrosta vasten, koska kaikki turvallisuusrajoitukset ovat tiellä. Tarvitsen apua.

Kehittäjä: Käytimme edellisessä projektissa toista työkalua. Se toimi erinomaisesti. Lähetän sinulle linkin.

Tämän seurauksena PO järjestää seuraavaan sprinttiin napakan kahden tunnin kokouksen. Tavoitteena on käydä virheet läpi ja keskustella siitä, mitä backlog-kohteisiin pitäisi kirjata, jotta uuden tulokkaan, Alanin, olisi helpompi työskennellä. Tunnetko, kuinka Alanin turhautuminen kasvaa?

Alanin kohtalokas asema syntipukkina käy yhä ilmeisemmäksi sprintin kolmentoista jälkeen, kun jäljellä on enää yksi sprintti. Tässä ovat retrospektiivin päätökset:

• Alan löysi paljon virheitä tarinoista, jotka hänen olisi pitänyt testata jo edellisessä sprintissä. Yhtäkään tarinaa ei saa sulkea ilman, että Alan on testannut sen.
• Suorituskykytestiä ei vieläkään ole. Pyydämme asiantuntijan tarkastelemaan asiaa. Alan perehdyttää hänet tehtävään.
• Kahta tarinaa ei saatu valmiiksi. Menetimme kaksi päivää hyödyttömien virheraporttien hylkäämiseen. Alan merkitsee jokaisen virheen merkityksellisyyden. Jos olet epävarma, kysy tuoteomistajalta.

Huomasitko sen? Tiimi ei saanut kahta tarinaa valmiiksi ja onnistui vierittämään syyn Alanin niskoille! 

Kuvittele seuraava sprintti, kun tarinoita ei suljeta, koska Alanilla ei ollut aikaa testata niitä! Ei ihme, että Alan näyttää uupuneelta.

Alan: Julkaisuun on vain kaksi viikkoa, ja laatu on painajainen. Kerro se tuotteen omistajalle! Ja he veivät vielä suorituskykytestauksen pois. Se oli koko syy, miksi liityin projektiin. Esimieheni on tyytymätön. Hän halusi minun näyttävän esimerkkiä siitä, miten testaajat otetaan mukaan ketteriin tiimeihin. Joudun kuitenkin viemään tämän läpi, sillä maineeni yrityksessä on vaakalaudalla.

Neljä viikkoa myöhemmin, kaksi viikkoa ensimmäisen rajatulle yleisölle suunnatun julkaisun jälkeen, loppuunpalamisen järjestelmä on täysin toiminnassa. 

Alanin yhteenveto tähänastisista saavutuksistaan:

• Suorituskykytestaus: epäonnistui
• Suorituskykytestauksen asiantuntijana tunnustetuksi tuleminen: epäonnistui
• Kyky testata perusteellisesti uudet asiat: epäonnistui
• Kyky testata perusteellisesti uudelleen jo rakennetut asiat: epäonnistui
• Testaajien ottaminen mukaan ketteriin tiimeihin: epäonnistui
• Ei kriittisiä virheitä julkaisussa: epäonnistui
• Suositelluksi tuleminen: epäonnistui
• Ahkera työskentely ja syytösten kohteeksi joutuminen: saavutettu
• Pelko työpaikan menettämisestä: saavutettu
• Loppuunpalaminen: etenemässä sitä kohti täydellä vauhdilla

Tämä on klassinen esimerkki loppuunpalamisen järjestelmästä. Mikä siis luo tämän järjestelmän, ja miten voimme ehkäistä sitä?

Mikä luo loppuunpalamisen järjestelmän?

Alanin tapauksessa kyse on alusta lähtien toivottomasta yrityksestä, voisi sanoa. Ja olisit oikeassa. Alan on loppuunpalamisen järjestelmässä, joka on toiminut tiimissä jo melko pitkään. Loppuunpalamisen järjestelmä eristää Alanin kuin saalistaja uhrinsa. Mutta mikä tämä loppuunpalamisen järjestelmä on ja miten se toimii?

Loppuunpalamisen järjestelmä on ihmisten, vaikuttimien ja ristiriitojen muodostama kokonaisuus. Vahvistavan kierteen kautta se luo tilanteen, joka on täynnä niin paljon stressitekijöitä, että jotkut ihmiset palavat lopulta loppuun. Se on erityisen voimakas silloin, kun se voi aktivoida ihmisten selviytymislogiikan.

1. Energia seuraa vaikuttimia

Alanin tarinassa voimme havaita joitakin vaikuttimia:

• Kunnianhimo ja innostus lempiaihetta, suorituskykytestausta, kohtaan saavat Alanin haluamaan sen tekemistä.
• Epäonnistuneesta julkaisusta vastuussa olemisen aiheuttama ahdistus saa Alanin etsimään virheitä.
• Jokin saa tiimin jäsenet rakentamaan ominaisuuksia ennen kaikkea muuta.

Vaikuttimet muuttavat toiminnan suuntaa. Ihmisten on todella vaikea ajatella selkeästi sitä, mitä pitäisi saavuttaa ja miten se saavutetaan. Ihmisten sijoittama energia seuraa vaikutinta, ei sitä, missä sitä eniten tarvitaan. Alanin tiimi ei koskaan kyseenalaista, onko kaikkien ominaisuuksien rakentaminen oikea ratkaisu. Alan ei myöskään kyseenalaista, onko virheiden metsästäminen tarkoituksenmukaista.

Useimmille meistä vaikeinta on tiedostaa, että jokin vaikutin on ottanut vallan. Meidän onneksemme psykologit ovat tutkineet niitä. Henkilökohtaisten vaikuttimien kohdalla kannattaa aloittaa transaktioanalyysistä. Tiimitasolla ryhmäajattelu on hyvä lähtökohta. Löydät sieltä runsaasti neuvoja.

Julkaisua edeltävään ahdistukseen liittyen eräs kokenut QA-ammattilainen neuvoi: ”Sinun täytyy vain päästää siitä irti ja ottaa rauhallisesti”. Tällaisella ajattelutavalla Alan olisi todennäköisesti tavoitellut alusta lähtien eri päämäärää kuin kaikkien virheiden metsästämistä ja suorituskykytestauksen käyttöönottoa. Tärkeimpiä tavoitteita voisivat olla, että tiimi poistaa kriittiset virheet ja toimittaa yleisesti laadukkaampaa ohjelmistoa. Yksi tapa vähentää toistuvien tehtävien aiheuttamaa stressiä on hyödyntää huippuluokan ohjelmistotestaukseen suunniteltuja työkaluja.

2. Ristiriidat kärjistyvät ja muuttuvat henkilökohtaisiksi

Vaikuttimien ohella tiimissä leimahtaa ristiriitoja. Esimerkiksi Alan tarvitsee kehittäjiltä enemmän aikaa kuin he ovat valmiita varaamaan. Seurauksena Alan aiheuttaa paljon hälyä, ja kehittäjät yrittävät pitää hänet loitolla. Vähäisen tuen varassa Alan ei pysty vastaamaan odotuksiin. Hän pelkää maineensa puolesta, kaksinkertaistaa ponnistelunsa ja aiheuttaa vielä enemmän hälyä.

Kaikkein pahempaa on se, että ristiriidoista tulee henkilökohtaisia. Kymmenen vuotta testaajana työskennellyt Alan on todennäköisesti melkoinen asiantuntija. Silti tiimi näkee hänet surkimuksena ja toimii sen mukaisesti. Mitä pidempään tämä jatkuu, sitä syvemmäksi se muuttuu. Tämä vaikuttaa myös Alaniin: hän alkaa kyseenalaistaa pätevyyttään.

Kuinka monta kertaa olet syyttänyt jotakuta? Kuinka moni ympärilläsi oleva henkilö ei tee hyvää työtä? Jokainen tällainen ajatus viittaa ristiriitaan, josta on tullut henkilökohtainen.

Useimmat tiimit eivät pysty ratkaisemaan ristiriitoja. Se ei käy helposti. Konfliktinhallinta on avainsana, josta löytyy neuvoja. Perusviesti on tämä: tiimit tarvitsevat kulttuurin, jossa ajatuksia voidaan vaihtaa avoimesti, eriävät näkemykset otetaan vastaan mahdollisuuksina luoda uusia asioita ja toistensa auttamista arvostetaan. Vaikea tavoite saavuttaa, jos vertaat sitä erään haastateltavan kuvaamaan nopeuden kulttuuriin: ”Ellei yritys juhli epäonnistumista, et auta tiimin nopeutta joka kerta, kun epäonnistut”.

3. Tiimirakenne vaikuttaa tiimidynamiikkaan

Alanin tiimi varasi sprintin kaksi viimeistä päivää testaamiseen, sprintin päättämiseen ja seuraavan sprintin valmisteluun. Tiimi oletti yksinkertaisesti, että Alan noudattaa tätä rakennetta. Hän testaisi hiljattain toteutetut toiminnot sprintin lopussa, tekisi jonkin verran uudelleentestausta myös seuraavassa sprintissä ja parantaisi testausta yleisesti. Ei kuulosta pahalta, vai mitä?

Todellisuus kertoo toisenlaisen tarinan. Ohjelmisto on saatavilla vasta sprintin viimeisenä päivänä. Työlista-alkiot auttavat vain vähän sen täsmällisen toiminnan ymmärtämisessä. Kun tiimi keskustelee seuraavassa sprintissä tehtävistä asioista, Alan yrittää selvittää, mitä tästä sprintistä pitäisi testata. Sitten hän esittää kysymyksiä juuri ennen kuin kehittäjät lähtevät ja testaa viikonlopun yli. Hienoa, että tiimi keskustelee siitä, mitä pitäisi kirjoittaa muistiin. Alan voi sen jälkeen testata häiritsemättä kehittäjiä. Bingo.

Tiimin rakenne eristää Alania yhä enemmän. Tiimi ei näe hänen kamppailevan. He huomaavat vain tyhmiä kysymyksiä ja myöhästyneitä, vähän arvoa tuottavia tuloksia. Melkoinen väliinputoaja.

Esimerkkien avulla tehtävä määrittely osoittaa varsin hyvin, miten testaus ja testaajat voivat olla olennainen osa ketterää tiimiä. Testaajat osallistuvat tarkennuksiin, auttavat luomaan testattavan määrittelyn, keskittävät testaustoimet sinne, missä niillä on merkitystä, parantavat tiimin prosesseja, yksilöllisiä taitoja ja työkaluja sekä tekevät myös osan testauksesta. Testausta tehdään jatkuvasti, ei vain sprintin lopussa.

4. Jätä perussäännöt huomiotta ja joudu vaikeuksiin

Alanin tiimi jättää ohjelmistotekniikan perussäännöt huomiotta. 

Tässä niistä viisi:

1. Odottamattomia asioita tapahtuu. Jos niille ei ole riittävästi tilaa, seurauksena on kiirehtimistä, oikoteitä, tyhmiä virheitä, kärjistyneitä ristiriitoja ja siten pitkällä aikavälillä hitaampaa etenemistä.
2. Paine aiheuttaa viivästyksiä. Paine vähentää odottamattomille asioille jäävää tilaa.
3. Laatu syntyy vähitellen. Tiimillä täytyy olla laatukulttuuri. Testaus on vain yksi palanen kokonaisuudesta. Ja yksi tiimin jäsen yksin kaikkia muita vastaan epäonnistuu yleensä.
4. Tiimin muuttaminen hidastaa. Luottamuksen rakentaminen, prosessien mukauttaminen ja uusien ristiriitojen ratkaiseminen: tiimi tarvitsee aikaa ja energiaa uusien jäsenten integroimiseen. Ihmisten lisääminen myöhässä olevaan projektiin tekee siitä vielä myöhäisemmän.
5. Virheistä pitää oppia. Kun prosessi tuottaa liikaa virheitä, pysäytä se, korjaa se ja opi siitä. Älä syytä ketään ja ennen kaikkea älä nopeuta prosessia.

Tällaisia sääntöjä on enemmänkin, ja aina kun ihmiset jättävät ne huomiotta, asiat pahenevat. Niin kävi myös Alanille.

5. Koettu tiukka tilanne laukaisee tämän

Miksi tiimi jättää tällaiset perusasiat huomiotta? Vastaus on helppo. Tämä on tyypillistä tiukassa tilanteessa, jossa lähtötekijät – toimitettavat asiat, käytettävissä oleva aika ja tiimi – eivät jätä riittävästi joustovaraa odottamattomien asioiden käsittelemiseen. Kun tiimi kokee tilanteen tiukaksi, se toimii ikään kuin kaikki olisi jo ennalta päätetty ja tehty. Loppuunpalamisjärjestelmät hyödyntävät ainoaa muuttujaa tiukassa kokonaisuudessa: sitä, kuinka kovasti tiimi työskentelee eli kuinka paljon energiaa tiimin jäsenet kuluttavat akuistaan.

Oleellinen kysymys on, onko Alanin tiimi todella tiukassa tilanteessa ja onko kaikkien ominaisuuksien toimittaminen paras tapa edetä. Voimme vain olettaa. Tiimi teki samoin ja kiirehti rakentamaan kaikkia ominaisuuksia.

Merkitystä on sillä, miten tiukka tilanne koetaan. Tällaisen kokemuksen voi laukaista sopimuslauseke, kannustin, suuri markkinamahdollisuus, pomon voimakas vaatimus, annettu lupaus, asiakkaan toive tai viranomaismääräys.

Alan odottaa valtavaa määrää virheitä, ja ahdistus saa hänet metsästämään niitä. Hänelle olennainen kysymys on: onko virheiden löytäminen tässä tapauksessa todella niin tärkeä vaihe? Voimme vain spekuloida, ja niin teki myös Alan. Hän oletti vastauksen olevan kyllä.

Tiukan tilanteen kokeminen on tärkeä vipuvarsi loppuunpalamisjärjestelmän murtamiseen. Sen taustalla on toinen ohjelmistotekniikan perussääntö:

• Liian korkeat odotukset. Sidosryhmät – myös kehittäjät itse – toivovat, odottavat tai vaativat enemmän kuin ohjelmistotiimi voi realistisesti toimittaa.

Kun tarkastelen projektikokemustani viimeisten 25 vuoden ajalta, en muista yhtäkään projektia, jossa näin ei olisi ollut. Odotetun ja toimitettavissa olevan välinen ristiriita on kipupiste. Projektin onnistuminen riippuu siitä, kuinka hyvin mukana olevat ihmiset pystyvät ratkaisemaan tämän ristiriidan. Suosittelen tutustumaan sidosryhmien ja odotusten hallinnan, ristiriitojen hallinnan, vaatimusmäärittelyn, ketteryyden ja vastaavien aiheiden hyviin käytäntöihin.

Joka tapauksessa on ymmärrettävä ristiriidan täsmällinen luonne. Kuinka voimakas se on? Mikä sitä ajaa? Keiden kanssa sinun täytyy työskennellä? Tai kuten eräs haastatelluista laadunvarmistuksen ammattilaisista asian ilmaisi: “Uskon, että jokaisen yrityksen on tehtävä tietoinen päätös laadun, kustannusten ja nopeuden suhteen”. Jokaisen yrityksen on työskenneltävä odotustensa parissa.

Laadunvarmistuksen ammattilaiset eivät yleensä ole asemassa, jossa he voisivat johtaa tätä keskustelua. He voivat yrittää osallistua siihen. Saattaa olla hedelmällisempää hallita henkilökohtaisesti kohtaamiaan odotuksia. Eräs haastateltava kertoi minulle toimintatapansa: “Kaikkea on mahdotonta testata. Paras tapa on määritellä aikaraja ja prioriteetit yhdessä tuoteomistajan kanssa. Prioriteetit kuvastavat testaamatta jättämisen riskiä. Jos tilanne ei tyydytä, neuvottele aikarajasta ja prioriteeteista uudelleen.”

6. Ketteryyden ansa

Vahva tiimi, joka mukautuu jatkuvasti muuttuviin tarpeisiin, epäbyrokraattinen tapa käsitellä muutosta, yksinkertaiset suunnittelun ja edistymisen seurannan keinot: ketterä liike toi esiin runsaasti innovaatioita, joista kehitystiimien on viisasta hyötyä. Silti ketteryys näyttää pahentavan tilannetta.

Kaikki alkaa nimityksistä: sprintti tarkoittaa nopeaa, nopeus tarkoittaa nopeaa, epäonnistutaan nopeasti. Ketterät periaatteet asettavat koodin etusijalle, ja tulevan pohtiminen sivuutetaan helposti hukkana. Jopa termi scrum on peräisin rugbysta, lajista, jossa urheilijat taklaavat toisiaan täydellä vauhdilla. Näin ketteryys edistää vakaumuksistaan huolimatta nopeutta laadun kustannuksella. ”Ketterän kehityksen ja DevOpsin kaltaiset menetelmät rohkaisevat ajatukseen, että kaikki pitäisi tehdä vieläkin nopeammin”, eräs laadunvarmistuksen ammattilainen valitti.

Esimerkiksi scrumin toimintatavat ovat vieläkin pahempia kuin nimitykset. Scrum-menetelmän luojat eivät toki halunneet edistää loppuunpalamista. Scrum kuitenkin johdattaa tiimit harhaan.

Ensinnäkin se keskittää tiimin huomion työjonoon. Tuoteomistajan tehtävä on lisätä asioita työjonoon. Tiimin jäsenen tehtävä on ottaa ne ja tehdä ne yksi kerrallaan. Scrum-mestarin tehtävä on varmistaa, että tämä tapahtuu nopeammin. Lisäksi ketterä edistymisen seuranta edellyttää pieniä työjonon tehtäviä, jotka voidaan tehdä muutamassa päivässä. Asiantuntijat suosittelevat myös tarkasti laadittuja hyväksymiskriteerejä ennen sprinttiä. Tiimin jäsenet saavat toimitettavakseen tarkasti määriteltyjä ja pieniä kokonaisuuksia. He ilmoittavat päivittäin, kuinka paljon aikaa he vielä tarvitsevat niiden saattamiseen päätökseen. Nopeus kertoo kaikille, kuinka hyvin he suoriutuvat. Mikrojohtajat riemuitsevat ja valvovat jokaista minuuttia: kontrollin puute, luovan tilan puute, paine nopeuttaa: oravanpyörä.

Kun tilanne on tämä ja näyttää kireältä, onko sillä väliä, onko tuote käyttäjille loistava? Ei todellakaan, se on käyttäjäkokemustiimin tehtävä. Onko sillä väliä, onko siinä järkeä? Tuoteomistajan tehtävä. Onko sillä väliä, ovatko hyväksymiskriteerit täydelliset? Jälleen tuoteomistajan tehtävä. Onko virheettömyys tärkeää? Testaajan tehtävä sen jälkeen, kun hyväksymiskriteerit on täytetty. Millä on väliä? Sillä, että saan työjonotehtäväni valmiiksi ajoissa. Näetkö Alanin aseman? Scrum johtaa tiimit toteuttamaan kaikki ominaisuudet. Laatu on Alanin tehtävä. Perussääntöä rikotaan, ja asiat huononevat.

Alanin tiimi noudattaa myös sitoumusta. He täyttävät sprintin niin monilla työjonon tehtävillä kuin nopeus osoittaa. Sitten he vannovat toimittavansa ne. Seuraava peruslaki osuu heihin: ennalta arvaamattomia asioita tapahtuu. Sen sijaan että rikkoisi valansa, tiimi oikaisee ja nipistää hieman testauksesta. Valmista ajoissa, hienoa! Yksi haastatelluista ilmaisi asian varsin suoraan: ”Tietyn tarinapistemäärän toimittamiseen sitoutumisen pelillistäminen luo epätervettä kilpailua.”

Alanin tiimi on langennut ketteryyden ansaan. He soveltavat Scrumia olematta ketteriä. Vertaa seuraavia kahta kuvaa: ensimmäinen kertoo, mistä Scrumissa on kyse, ja toinen siitä, mistä ketteryydessä on kyse.

Scrumissa on kyse prosessista, jossa työjonon tehtävät muutetaan tuotteeksi.

Ketteryydessä on kyse vaikuttavuuden luomisesta tuotteella ja mukana olevien ihmisten vuorovaikutuksesta: niiden, jotka tilaavat tuotteen, niiden, jotka käyttävät sitä, ja niiden, jotka luovat sen.

Vaikka Scrum on erinomainen työkalu sisäisesti motivoituneille ketterille tiimeille, se on tuhoisa ylhäältä alaspäin johdetussa komentohierarkiassa!

Keskeiset opit

Ohjelmistoalalla on tärkeää kehittää puolustusmekanismeja ohjelmistotestauksen ammattilaisten stressiä ja loppuunpalamista vastaan. Joissakin yrityksissä tämä on tärkeämpää kuin toisissa. Jotkin tilanteet ovat todella kireitä, toiset tehdään tarkoituksella kireiksi. Useimmat tilanteet vaikuttavat kuitenkin paljon kireämmiltä kuin ne todellisuudessa ovat. Tämä saa meidät seuraamaan ohjaimiamme, lopettamaan ristiriitojen työstämisen ja jättämään perussäännöt huomiotta. 

Seuraava taulukko kokoaa yhteen loppuunpalamisjärjestelmän rattaat.

Loppuunpalamisjärjestelmän keskeiset osatekijät

• Koettu kireys on sen välinen kuilu, minkä näemme tehtäväksemme, ja sen, mitä voimme toimittaa. Sen selvittäminen, mikä todella on parasta saavuttaa, voi purkaa loppuunpalamisjärjestelmän.
• Ohjaimet määrittävät, mihin energia virtaa, ja estävät meitä toimimasta viisaasti kireässä tilanteessa. Omien ohjaimiemme tunnistaminen voi auttaa meitä käyttämään vähemmän energiaa ja käyttämään sitä viisaammin.
• Ristiriidat pahentavat tilannetta, heikentävät tiimin tehokkuutta ja kuluttavat energiaa. Luodaan tiimikulttuuri, jossa ristiriidat otetaan tervetulleina vastaan ja jossa autamme toisiamme.
• Perussäännöt jätetään helposti huomiotta. Niiden huomiotta jättäminen on varma merkki siitä, että asiat tulevat huononemaan. Meidän on toimittava!
• Tiimirakenteet jähmettävät hyvät ja huonot käytännöt. Tiimirakenteiden muuttaminen voi muuttaa perusteellisesti sitä, kuka tekee mitä ja miten ihmiset ovat vuorovaikutuksessa. Se voi muuttaa pelin säännöt täysin.
• Noidankehät syntyvät tiimissä ja sen ympärillä toimivien ihmisten vuorovaikutuksesta ja pahentavat tilannetta yhä enemmän. Tunnistammeko noidankehät, joihin olemme joutuneet? Meidän on pysäytettävä ne ja korjattava tilanne!
• Ketteryyden ansa on ketterien viitekehysten omaksuminen olematta ketteriä. Tuloksena on oravanpyörä. Keskitytään käyttäjiin, loistavan tuotteen luomiseen ja vuorovaikutukseemme sen sijaan, että kuluttaisimme työjonon tehtäviä loppuun.

Laadunvarmistuksen ammattilaisena et ehkä pysty muuttamaan kokonaistilannetta paremmaksi. Voit kuitenkin todennäköisesti vähentää jonkin verran stressiä. 

Kysyin Jonathon Wrightilta: ”Missä olet nähnyt yritysten tai tiimien ryhtyvän toimiin laadunvarmistuksen ammattilaisten mielenterveyden edistämiseksi? Mikä toimii?”

Hän vastasi, 

”Autettuani viime vuoden ajan Yhdistyneen kuningaskunnan hallitusta valmistautumaan brexitiin olin erittäin vaikuttunut työmoraalista. Osallistuin ensimmäistä kertaa pakolliselle mindfulness-kurssille, joka oli erittäin hyödyllinen. Paikalla oli mielenterveysalan asiantuntijoita ja jopa tukiryhmiä, jotka kokoontuivat viikoittain.”

Hän huomautti myös, että QA-ammattilaiset voivat tehdä paljon stressinsä ja ahdistuksensa hallitsemiseksi henkilökohtaisella tasolla:

”Elämä on liian lyhyt murehdittavaksi pienistä asioista. QA-ammattilaisten on vaikea olla murehtimatta uuden tuotteen merkittävän julkaisun edellä tai tuntematta olevansa vastuussa lopputuloksesta. Mutta kuten Parveenin kanssa käsitellyssä jaksossa II, joskus sinun on vain ’annettava sen mennä, annettava sen mennä’ eikä ’oltava cool’.”

Jonathon Wright, The QA Lead -podcastin juontaja

”Koska olen hallinnut ahdistusta koko ammatillisen urani ajan, siihen on liittynyt omat sudenkuoppansa ja haasteensa, mutta olen aina selviytynyt niistä vahvempana ja paremmassa asemassa hallitsemaan ahdistustani entistä paremmin — oppien joka kerta lisää itsestäni. Ala vetää puoleensa ihmisiä, jotka sijoittuvat kirjon eri asteille (ja luen itseni heidän joukkoonsa). Kaikista lahjakkaimmat ihmiset, joiden kanssa minulla on ollut tilaisuus työskennellä, ovat kuitenkin kärsineet mielenterveysongelmista, minkä vuoksi pidän omaa mielenterveysongelmaani supervoimana!”

Kuten Jonathon huomautti, pienellä onnella ja oikealla asenteella voit muuttaa stressaavan työn palkitsevaksi. Kannustan sinua omaksumaan loppuunpalamisjärjestelmän käsitteen tarjoaman näkökulman. Päästä ahdistuksestasi irti ja pysy rauhallisena. Katso sitten käskyjen, prosessien ja työkalujen tuolle puolen. Keskity siihen, mikä todella merkitsee: siihen, miten sinä ja tiimikaverisi autatte toisianne luomaan erinomaisia tuotteita.