Monia vuosia sitten, sinä päivänä, jolloin päätimme julkaista merkittävän päivityksen tuotteeseemme – päätös, joka tietenkin edellytti hyväksyntääni laadunvarmistusjohtajana – kävelin käytävällä, kun toimitusjohtaja tuli vastaan.
Hän pysäytti minut ja sanoi: ”Voinko siis olettaa, että toimitamme ohjelmiston ilman virheitä?”
Sen kummemmin ajattelematta kuin olisi varmaankin pitänyt, vastasin huolettomasti: ”Tietenkään emme. Virheetöntä ohjelmistoa ei ole olemassa.”
Hän oli vastauksestani järkyttynyt ja tyrmistynyt. Hän suuttui minulle niin paljon, että lopetti keskustelumme ja marssi raivoissaan pitkin käytävää.
Tuolloin selitin asian itselleni sillä, että hän oli uusi ohjelmistoalalla ja ohjelmistojen elinkaaren suhteen, sillä hän oli tullut kustannusalalta (pitkä tarina – ehkä joskus toiste). Kehitystiimin kaikki jäsenet tiesivät, että toimitamme ohjelmiston, jossa oli virheitä. Mutta tiesimme alusta alkaen, mitä nämä virheet olivat, ja sillä oli ratkaiseva merkitys riskinarvioinnillemme.
Olen kuitenkin huolestuneena huomannut, että viime aikoina entisen toimitusjohtajani väärinkäsitys on levinnyt alallamme laajalle. Virheetön, ”nollavirheinen ohjelmisto” on uusi kehuskelun aihe ja hokema, jota näen ja kuulen yhä useammin. Eikä sitä julista vain tietämättömät toimitusjohtajat (tiedän, tarpeetonta toistoa), vaan myös alan ihmiset, joiden pitäisi tietää paremmin. Ja jotka itse asiassa tietävätkin. Mikä huolestuttaa minua suuresti.
”Nollavirheajattelussa” on kyse jossain mielessä muustakin kuin vain valheellisesta ja omaa etua palvelevasta hölynpölystä. Länsimaissa se on enimmäkseen pelkkää sanahelinää ja tehokeinoksi tarkoitettua poseerausta. Japanissa sillä on kuitenkin todellinen merkitys. Ja kaikilla sen teollisuudenaloilla.
Työskentelin Japanissa vuoden ajan, ja tämä mullisti ajatteluni – erittäin hyvällä tavalla. Syy oli siinä, että heidän määritelmänsä ”virheelle” on hyvin erilainen kuin meidän. Jos tehtaan lattialle on esimerkiksi jäänyt purukumipaperi, sitä pidetään virheenä siinä missä koneistossa tai prosessin tuotoksessa olevaa ongelmaa. Jos suhtautuisimme ”nollavirheisiin” todella vakavasti, ajattelisimme tätä asiaa japanilaisten tavoin. Mutta emme ajattele, joten emme myöskään toimi niin.
Yritin sanoa tuolle onnettomalle toimitusjohtajalle ehkä liian suoraan, että jokainen nykyaikainen kaupallinen ohjelmisto on äärettömän monimutkainen, ja siksi myös tavat, joilla se voi olla vuorovaikutuksessa itsensä tai ympäristönsä kanssa, ovat rajattomat. Kaikki virheet on mahdollista löytää vain, jos testaamiseen on käytettävissä ääretön määrä aikaa. Mutta kukaan meistä ei ole kuolematon.
Vaikka voisitkin löytää jokaisen viimeisen virheen ensimmäisellä kerralla, sinulla ei olisi aikaa korjata niitä kaikkia ja toimittaa tuotetta tämän vuosisadan aikana – markkinoille saattamiseen kuluva aika on todellinen tekijä. Joten vaikka virheet löydettäisiin, ohjelmisto on toimitettava niiden kanssa.
Niinpä koko ajatus ”nollavirheisestä ohjelmistosta” on alusta alkaen pohjimmiltaan harhainen.
Mistä ajatus nollavirheisestä ohjelmistosta on peräisin?
Tämän harhan taustalla on ajatus, että laadunvarmistuksen tehtävänä on ”varmistaa” laatu. Se ei tee sellaista. Se on tuotehallinnan ja ohjelmistokehityksen tehtävä. Laadunvarmistuksen tehtävänä on *arvioida*, kuinka hyvin ne ovat siinä onnistuneet.
Mutta tähän ongelmaan liittyy toinenkin haitallinen kerros.
Keskustelin hiljattain juuri tästä aiheesta ohjelmistokehittäjän kanssa. Hän huomautti, että hänelle ”nollavirheinen ohjelmisto” oli selitetty juuri kuten edellä kuvasin. Se tarkoittaa toimittamista kaikkien niiden virheiden korjaamisen jälkeen, jotka tiimi päätti korjata ennen toimitusta. Sen jälkeen ohjelmisto toimitetaan kaikkien niiden virheiden kanssa, joita tiimi päätti olla korjaamatta. Keskustelukumppanini ei tosin ollut tästä määritelmästä samaa mieltä.
Tämä on selvästi vain määritelmillä kikkailua ja savuverhoa. Todellisuudessa toimitat ohjelmiston virheineen ja tiedät sen itsekin, mutta käytät ”nollavirheiden” iskulausetta piilottaaksesi tämän tosiasian itseltäsi – ja tietenkin johdolta. Kaikkihan tietävät, että tyhjät iskulauseet, jotka saavat johdon tuntemaan itsensä menestyneeksi, hypnotisoivat sen helposti.
Kyse on valikoivasta virheiden vähentämisestä, ei mistään muusta.
Have an account? Log In
Miten pääsemme eroon nollavirheiden harhautuksesta?
Tämän harhautuksen perusta on itse kieli – kieli, joka muovaa ja rajoittaa ajatteluamme jo ennen kuin voimme edes alkaa käsitteellisesti vastata siihen, mitä se sanoo. Juuri tämä väärä kieli luo alun perin tilanteen, jossa meidän on selitettävä, miksi se on väärässä. Näin iskulauseen sanasto alkaa ajaa meitä nurkkaan.
Tämä on ohjelmistokehityksessä hyvin yleinen käytäntö. Valitettavasti se ei rajoitu siihen, että valehtelemme itsellemme ”nollavirheistä”. Se saastuttaa ajattelumme ja toimintamme jokaisen tason: testaajina, kehitysprosessissamme, menetelmissämme ja mittareissamme.
Ryhdytään kohtaamaan todellisuus sen suhteen, mitä teemme ja mitä emme tee. Ja ensimmäinen askel toipumisessa on käyttää kieltä, joka kuvaa rehellisesti sitä, mitä teemme ja mitä emme tee. Jos nimittäin käyttämämme kieli, jolla näistä todellisuuksista viestitään, on itsessään pohjimmiltaan petollista, epärehellistä ja harhaista, emme tee laadukasta ohjelmistoa. Me tuotamme propagandaa.
“Nollavirheisen ohjelmiston” diskurssiin liittyy toinenkin ongelma: vaikka tämä olisi aidosti tavoiteltu päämäärä – siinä mielessä, että ihmiset todella uskovat sen olevan mahdollinen eikä kyse ole vain kyynisestä harjoituksesta – toinen, vakavampi ongelma rajoittaa tämän ajatuksen hyödyllisyyttä. Ongelma on tämä:
Miten voisit mitenkään tietää ja todistaa, että olet löytänyt “kaikki” testattavasta ohjelmistosta löytyvät virheet? Eikä vain niiden virheiden määrää, jotka olet onnistunut löytämään käytettävissä olleen ajan kuluessa? Miten voisit todistaa itsellesi, että löytämiesi bugien joukko on täydellinen joukko bugeja, joita ohjelmisto todellisuudessa sisältää?
Et mitenkään. Se edellyttäisi QA:sta itsestään riippumatonta prosessia, joka määrittelisi tämän. Muuten kyse olisi vain kehäpäätelmästä. Ja mikä tämä ulkopuolinen prosessi olisi?
Ja tämä pitää paikkansa riippumatta siitä, kuinka monta bugia olet jo löytänyt. Olet voinut löytää niitä miljoona. Se ei todista, ettei ohjelmiston varjoissa vaanisi miljoonasensimmäinen bugi.
Onko nollavirhekonseptissa mitään arvokasta?
“Nollavirheisestä ohjelmistosta” puhumiseen ja sen ajattelemiseen liittyvät räikeät loogiset ja epistemologiset ongelmat ovat yksinkertaisesti ylitsepääsemättömiä. Itse nimitystä ei voi pelastaa, vaikka muotoilisimme sen uudelleen miten tahansa.
Jos kuitenkin katsomme harhaanjohtavan iskulauseen taakse ja perehdymme siihen, mikä tekee siitä alun perin houkuttelevan ja käsitteellisesti pätevän muuten järkevästi ajatteleville ihmisille, löydämme jotakin arvokasta, johon keskittyä.
Tuo “jokin” on eri kysymys, mutta se vastaa nollavirheisen ohjelmiston virheellisen diskurssin näennäisesti täyttämiin käytännön ja tunneperäisiin tarpeisiin johdonmukaisemmalla ja paremmin perusteltavalla tavalla.
Asia, jota ohjelmistojen parissa työskentelevät ihmiset tässä todella yrittävät itsepetoksen avulla käsitellä, on itsessään petollisen yksinkertainen. Nimittäin: “Milloin tiedämme, että voimme lopettaa testaamisen?”
Se on ainoa kysymys, jonka esitän organisaatiossani QA-johtotehtävien hakijoille. Koska oikeastaan se on ainoa kysymys, johon QA:n täytyy vastata. Ja jos se ei pysty siihen, QA on pelkkää ajanhukkaa. Vastataksemme tähän kysymykseen meidän on ensin vastattava sitä edeltävään kysymykseen.
More Articles
Nollavirheisyys vs. testikattavuusprosentti
Mistä tiedämme, voidaanko jo löytämämme virheet – olivatpa niitä kuinka monta tahansa – perustellusti hyväksyä edustamaan sitä riskikehystä, joka on syntynyt testattavan ohjelmiston määrittelystä ja suunnittelusta? Voimmeko sen perusteella sanoa luottavaisin mielin, että havaitsematta jääneet virheet muodostavat hyväksyttävän riskin päätökselle julkaista ohjelmisto yleisölle?
Näin muotoiltuna näemme, että tämä kysymys ei oikeastaan koske virheitä lainkaan. Se koskee testikattavuutta. Löydettyjen bugien analyysi, olivatpa ne kuinka lukuisia tahansa, ei merkitse mitään, jos niitä ei voida yhdistää tähän mennessä saavutetun testikattavuuden analyyttiseen ymmärrykseen ja verrata siihen kattavuuteen, joka on vielä saavutettava QA-työssä.
Koska jos tunnettujen virheiden joukko – riippumatta siitä, kuinka paljon aikaa testaamiseen on käytetty – edustaa vain 30 prosentin todellista testikattavuutta – etkä tiedä tätä – sinulla ei ole rationaalista perustaa tietää, mitä nämä virheet merkitsevät ohjelmiston julkaisemista koskevan päätöksen kannalta.
aidosti tehokkaiden QA-työn ponnistelujen todellinen keskustelu ja todellinen tavoite eivät voi liittyä “nollaan virheeseen”, vaan pikemminkin “100 prosentin testikattavuuteen”. Edellä esittämäni syyn vuoksi.
Tämän ohjelmiston laadun ajattelutavan suuri etu on se, että se perustuu QA:n itsensä ennen testaamista määrittelemään riittävän testikattavuuden määritelmään. Siksi tätä määritelmää voidaan testata määrittelyjä, vaatimuksia, aiempia asiakasongelmia, asiakkaiden tarpeita ja niin edelleen vasten sekä muokata tarpeen mukaan.
Eteenpäin: aukoton testikattavuus
Tämän ongelman ajatteleminen virheiden näkökulmasta epäonnistuu juuri siksi, ettei sitä voida mielekkäästi määritellä etukäteen, koska ongelmien määrä ja vakavuus voidaan selvittää vasta testaamisen jälkeen.
Sen lisäksi sitä ei arvioida olemassa olevan (mielekkään) määritelmän perusteella, joka kertoisi, mitä “nolla” voisi todellisuudessa tarkoittaa. On ajanhukkaa määritellä onnistuminen muuttujan perusteella, jota ei ole itsessään määritelty eikä voida määritellä.
Siksi ainoa tapa pelastaa ajatus nollavirheisestä ohjelmistosta on suunnata tämä ajattelu ja suunnittelu kohti aukotonta testikattavuutta. Nollavirhemantran taustalla oleva motivaatio ei itsessään ole väärä. Se on vain suunnattu pois todellisesta kohteestaan. Tee tämä korjaus, ja hyväksyttävän ohjelmistolaadun mielekkäät, mitattavat määritelmät tulevat mahdollisiksi.
Jos olet valmis oppimaan lisää ja kuulemaan silti asiantuntijoiden ja toimitusjohtajien näkemyksiä, tässä on podcast, josta uskomme sinun pitävän: TIIMITYÖ, TEKOÄLY JA KONTTITEKNIIKKA (NASA:N MICHAEL RITCHSONIN KANSSA)
Aiheeseen liittyvää luettavaa: 10 PARASTA VIRHEIDEN SEURANTATYÖKALUA OHJELMISTOTESTAUKSEEN
