Toimittajan huomautus: Tervetuloa ohjelmistotestauksen gurun ja konsultin Paul Gerrardin Johtajuutta testauksessa -sarjaan. Sarjan tarkoitus on auttaa muutaman vuoden kokemuksen omaavia testaajia – erityisesti ketterissä tiimeissä työskenteleviä – menestymään testauksen vetäjän ja esihenkilön rooleissa.
Edellisessä artikkelissa hahmottelimme riskimanifestin esihenkilöiden avuksi. Tässä artikkelissa esitämme ikiaikaisen kysymyksen: ”Kuinka paljon testausta on tarpeeksi?” Juonipaljastus: se riippuu sidosryhmistä.
Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen sarjan uusien osien julkaisemisesta. Nämä kirjoitukset ovat otteita Paulin Leadership In Test -kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, käytä yksinoikeudellista kuponkikoodiamme QALEADOFFER ja säästä 60 dollaria kurssin täydestä hinnasta!
Kuinka paljon testausta on tarpeeksi? Tämä on klassinen, mahdoton ja filosofinen kysymys, jonka kaikki testaajat esittävät, koska heidän sidosryhmänsä esittävät sen heille.
Sidosryhmät haluavat tietää tämän, koska ne haluavat varmuuden siitä, että järjestelmät on testattu riittävästi. Koska ne kuitenkin maksavat testauksesta ja niillä on määräajat, ne haluavat myös tietää testauksen mahdolliset kustannukset ja siihen kuluvan ajan.
Siksi sidosryhmien tehtävänä on arvioida, kuinka paljon testausta on tarpeeksi. Testauspäällikkönä sinun tehtäväsi on tuottaa niille mahdollisimman paljon arvoa auttamalla niitä tekemään päätöksen. Tässä artikkelissa käsittelemme seuraavia aiheita:
- Testauksen arvo sidosryhmille
- Kvanttiteoria ja suhteellisuusteoria (ei fysiikkaa)
- Oikean kielen käyttäminen
- Arviot, budjetit ja neuvottelut
Aloitetaan.
Testauksen arvo sidosryhmille
Jokaisella suorittamallamme testillä tulisi olla sidosryhmille arvoa, sillä se tuottaa näyttöä heidän päätöksentekonsa tueksi neljällä tavalla:
- Näyttöä siitä, että järjestelmä saavuttaa projektin liiketoimintatavoitteet.
- Näyttöä siitä, että järjestelmä ei vikaannu tai että vian vaikutukset ovat siedettävissä, jos vika kuitenkin ilmenee.
- Näyttöä, jonka avulla viat voidaan toistaa ja diagnosoida sekä vikaantunut järjestelmä korjata ja testata uudelleen.
- Näyttöä päätöksenteon tueksi projektin yhteydessä (hyväksymistä, julkaisua, hylkäämistä ja niin edelleen varten).
Testauksen tavoitteena on luoda testejä, jotka lisäävät asteittain järjestelmän testauskattavuutta tunnistettavissa olevaan testausmalliin nähden. Testiemme tulisi osoittaa, että järjestelmä saavuttaa liiketoimintatavoitteet ja että vikaantumisriski tunnetaan ja on toivottavasti hyväksyttävällä tasolla.
Edellä mainituista neljästä näyttötyypistä kolme ensimmäistä tukevat neljättä. Viime kädessä sidosryhmien on tehtävä näyttöön perustuva päätös. Päätös kuuluu niille, ei testaajille, joten niiden tehtävänä on arvioida, onko niillä riittävästi tietoa luottamuksen saavuttamiseksi. Joka tapauksessa testauksen arvo on sidosryhmän silmissä.
Jokainen testaaja tekee valintoja testattavista asioista käyttämällä muodollista mallia tai jopa vaistoaan. Nämä valinnat tehdään jonkin koetun arvon perusteella.
Ellei testaaja ole myös sidosryhmän edustaja, hän yleensä arvioi arvoa jonkin täydellisyyden tai kattavuuden mittarin perusteella. Tai jos hän tuntee sidosryhmien ajattelutavan, hän arvioi sitä sen perusteella, tukeeko testi jotakin hyväksymispäätöstä.
Edellä esitetyillä periaatteilla on tärkeitä seurauksia.
Ensinnäkin, jos et tunne sidosryhmän ajattelua, käsityksesi testin arvosta ei todennäköisesti ole sama kuin sidosryhmällä. Jos valitset testit ottamatta huomioon niiden arvoja, sidosryhmäsi saattavat tuloksia esitellessäsi huomata, että niillä on joillakin alueilla liian vähän tietoa ja toisilla liikaa. Ne eivät varmasti tunne oloaan niin luottavaisiksi kuin niiden pitäisi.
Toiseksi, kun suunnittelet tai suoritat testiä, mikä on sen vaikutus sidosryhmän päätöksentekoon? Jos testi ei tuota päätöstä tukevaa uutta tietoa tai jos sidosryhmiä ei kiinnosta, läpäiseekö testi vai ei, testillä ei ole sijaa testaussuunnitelmassa.
Sanoimme malleja käsittelevässä kolmannessa artikkelissa, että käyttämiesi testausmallien on oltava sidosryhmille merkityksellisiä. Jos testituloksesi voidaan yhdistää malleihin, jotka sidosryhmät ymmärtävät ja joita ne arvostavat, ne arvostavat myös panostasi.
Have an account? Log In
Kvanttiteoria ja suhteellisuusteoria
Testien arvoon ja merkitykseen liittyy vielä kaksi periaatetta. Kutsun toista kvanttiteoriaksi ja toista suhteellisuusteoriaksi. Nämä nimitykset kuulostavat mahtipontisilta (ne ovat ehdottomasti leikillisiä), mutta ne kuvaavat kahta ilmiötä, jotka muodostavat kaikkien testauksen arvoa, priorisointia ja rajausta koskevien keskustelujen perustan.
Kun suoritamme testin, tulkitsemme yleensä tuloksen läpäistyksi tai hylätyksi. Läpäisty/hylätty-arvio on binaarinen tulos – tosi tai epätosi, kyllä tai ei, yksi tai nolla. Testin tulos tuottaa erillisen kvantin verran näyttöä. Näyttöä kertyy, kun suoritamme yhä useampia testejä. Tuloksesta riippumatta testi kasvattaa vähitellen testimallimme kattavuutta ja tietämystämme järjestelmän käyttäytymisestä. Testit, jotka eivät lisää tietämystämme, eivät tuota lisäarvoa.
Jos testi ei kasvata kattavuutta vähitellen jollakin tavalla, sen arvo on vähäinen.
Toinen näkökulma on testin arvo. Mikä on testin arvo? Voisiko yksittäiselle testille todella määrittää dollarin, punnan tai euron arvon? Luultavasti ei. Mutta voimme tehdä – ja usein melko helposti – seuraavanlaisen toteamuksen: ”tämä testi on arvokkaampi kuin tuo”.
Oletetaan, että käytämme koodikattavuuden mallina lausekattavuutta. Voisimme suorittaa testin, joka käy läpi viisi koodiriviä tai viisituhatta koodiriviä. Mikä on kummankin arvo? Sitä on vaikea sanoa. Mutta jos tavoitteemme on lausekattavuus, toisella testillä on suurempi arvo.
Emme voi määrittää millekään testille absoluuttista arvoa, mutta voimme yleensä vertailla testejä ja päätellä niiden suhteellisen arvon. Jos olemme aikapaineen alla, voimme yleensä sanoa, että yhdellä testillä on vähemmän arvoa kuin toisella, ja siksi jättää ensimmäisen testin tarvittaessa laajuuden ulkopuolelle.
Voimme vertailla testien arvoa, mutta vain, jos ne perustuvat samaan malliin.
On kuitenkin korostettava, että nämä vertailut ovat todella merkityksellisiä vain, jos niissä käytetään samaa mallia. Testillä, joka kattaa prosessin laajan joukon äärimmäisiä olosuhteita, on todennäköisesti suurempi arvo kuin suoraviivaisen polun testillä. Monimutkaisen prosessin päästä päähän -testejä ei esimerkiksi voi verrata suoraan kriittisten komponenttien yksikkötesteihin.
Vaikka kvanttimekaniikan ja suhteellisuusteorian teoriat eivät ehkä suoraan päde testaamiseen, mukautuvuuden ja näkökulman periaatteet pätevät. Etsi näiden periaatteiden mukainen testinhallintatyökalu testaustrategiasi optimoimiseksi.
Oikean kielen käyttäminen
Kun olemme nyt määrittäneet, kuka vastaa sen päättämisestä, ”kuinka paljon testausta on riittävästi”, miten me vastuulliset testaajat voimme tukea tätä päätöksentekoa?
Huomaa, että käsittelymme testien arvosta on hyvin samanlainen kuin riskien arviointimme. Kuten edellisessä artikkelissa todettiin, riskin suuruudelle tai altistumiselle on erittäin vaikea määrittää numeerisia arvoja. Yleensä on kuitenkin mahdollista verrata yhtä riskiä toiseen ja asettaa ne järjestykseen, jotta voidaan tehdä valintoja testauksen piiriin kuuluvista riskeistä.
Käyttämällä riskien kieltä testaajat tulevat johdon kuulluiksi.
Kehitystiimien johtajia kuunnellaan usein esihenkilöiden toimesta, vaikka he puhuisivat teknisistä asioista. Erona on se, että he esittävät teknologian kiinnostavana ja hyödyllisenä. Kun testaajat puhuvat omilla teknisillä termeillään – testien ”hallinnollisista” yksityiskohdista, kuten poikkeamien tilastoista – viesti on yleensä kielteinen, ja esihenkilöt voivat pitkästyä tai ärsyyntyä.
Johto saattaa jo valmiiksi pitää testaajia hieman tylsinä olentoina, mutta tämän voidaan perustellusti katsoa johtuvan siitä, etteivät monet esihenkilöt todella ymmärrä, mitä testaajat tekevät ja mitä arvoa he tuottavat. Siksi testaajien tulisi mukauttaa kielenkäyttönsä johdon tasolle.
Riskiperusteinen testaus puhuttelee käyttäjähallintoa ja projektijohtoa niiden omalla kielellä.
Nämä ihmiset ajattelevat hyvin pitkälti riskien ja hyötyjen kautta. Jos testaajat lähestyvät heitä samankaltaisin termein, johto kuuntelee testaajia todennäköisemmin ja tekee siten parempia päätöksiä. Yhdistämällä testit projektin tavoitteisiin voimme keskittää huomion sidosryhmille arvokkaimpiin toimituksiin, jolloin käytämme aikamme tärkeimpien asioiden testaamiseen.
Lisäksi testauksen edetessä voimme osoittaa, että arvokkaimmat hyödyt ovat nyt saatavilla. Julkaisupäätös on viime kädessä arvio siitä, ylittävätkö saavutetut hyödyt riskit, joten testaus tarjoaa johdolle parempaa tietoa päätöksenteon perustaksi.
Käytä riskien (ja hyötyjen) kieltä testauksen laajuuden määrittämiseen, suunnitteluun ja edistymisestä raportointiin.
Testaajien on tietenkin puhuttava teknisesti kehittäjien ja muun teknisen henkilöstön kanssa. Esimerkiksi poikkeamaraporttien laatu on keskeinen tekijä siinä, että virheet saadaan korjattua nopeasti ja luotettavasti. Sanon vain, että puhuessaan johdolle testaaja puhuu käsitellyistä ja avoinna olevista riskeistä testien, poikkeamien ja virheiden sijaan.
More Articles
Arviot, budjetit ja neuvottelut
Uuden projektin alkuvaiheessa projektipäällikkö kysyy sinulta: ”Minun on aikataulutettava ja resursoitava testaus hyvissä ajoin. Voisitko antaa arvion siitä, kuinka monta henkilöä tarvitset ja kuinka kauan järjestelmätestaukseen kuluu?”
Pohdit asiaa ja menet puhumaan esihenkilölle.
”Tarvitsen kuusi testaajaa kahdeksaksi viikoksi.”
Projektipäällikkö miettii hetken ja tutkii alustavaa aikatauluaan ja resurssisuunnitelmaansa.
”Voit saada neljä testaajaa kuudeksi viikoksi, eikä muuta.”
Vastustat tätä ja sanot: ”Mutta siihen menee pidempään kuin kuusi viikkoa! Se maksaa enemmän kuin tämän järjestelmän testaamiseen on varattu. Järjestelmä on suurempi kuin viime kerralla. Se on monimutkaisempi. On ehdottomasti liian riskialtista säästää testaamisesta tällä kertaa. Se ei yksinkertaisesti riitä.”
Mutta projektipäällikkö pysyy kannassaan ja mutisee jotain muista riippuvuuksista, ylemmistä tahoista ja niin edelleen…
Mitä ajattelet: mikä oli arvion tekemisen tarkoitus, jos projektipäällikkö tiesi koko ajan, mikä budjetin täytyy olla? Mitä merkitystä mielivaltaisella budjetilla on käsillä olevan työn kannalta? Miksi testaamista ei koskaan oteta vakavasti? Kehittäjät saavat aina pyytämänsä ajan, eikö niin? Tämä ei vaikuta reilulta.
Saatat tuntea itsesi loukatuksi ja kokea, että ammatillinen harkintakykysi kyseenalaistetaan. Ongelma kuitenkin on, ja on aina ollut, että testaamiseen varattu budjetti oli tässä tilanteessa kiinteä. Ainoa mitä voit tehdä, on selvittää, mikä on parasta tai arvokkainta testaamista, jonka voit mahduttaa budjettiisi.
Usein projektipäällikkö kuitenkin todella haluaa tietää, kuinka kauan asioihin kuluu, jotta suunnitelmaa voidaan muokata. Jos ajattelet olevasi neuvottelutilanteessa, tarvitset neuvotteluvaraa. Sinun täytyy myös keskustella suunnitelman lopputuloksista, ei lähtötiedoista. Laajuus on suunnittelun lopputulos, käyttämäsi työpanos on lähtötieto.
Sinun täytyy neuvotella laajuudesta.
Testausbudjettien neuvottelun tulisi aina koskea laajuutta, ei työpanosta.
Laajuus voi esiintyä yhdessä tai useammassa muodossa, ja tapa, jolla esität laajuuden ja keskustelet siitä, vaihtelee, mutta tässä on joitakin yleisiä malleja. Riippumatta siitä, millainen laajuus sinulla on, käytät sitä arviosi ja sen perustelujen pohjana:
Laajuus vaatimusten tai ominaisuuksien luettelona
Kun arviota leikataan 30 %, kysy: ”Mitä järjestelmän 30:tä prosenttia minun ei pitäisi testata?”
Laajuus riskiluettelona
Kun arviota leikataan 30 %, kysy: ”Mitkä sidosryhmäriskit pitäisi jättää suunnitelmasta pois?”
Laajuus taulukoituna tai graafisena mallina
Kun arviota leikataan 30 %, kysy: ”Mistä poluista/käyttäjämatkoista/kohteista minun pitäisi kertoa sidosryhmille, ettei niitä testata?”
Toivon, että näet, mitä tässä tapahtuu.
- Testauksen laajuus perustuu johonkin malliin, josta on ensin keskusteltu sidosryhmien kanssa ja jonka kanssa he ovat yhtä mieltä. Tämä laajuus on alustava ja riippuvainen resurssien ja ajan saatavuudesta, ja sinun pitäisi tehdä tämä sidosryhmille selväksi.
- Laadi arvio tämän alustavan laajuuden perusteella. Aseta kattavuustavoite mallin (riskit, vaatimukset, liiketoimintaprosessi tai jokin muu malli) avulla, laske kattavuuskohteet ja tee arvio niiden perusteella.
- Keskustele projektipäällikön kanssa. Jos arvio on liian suuri, käytä yllä olevia vastauksia käynnistääksesi keskustelut sidosryhmien kanssa.
Testaajana tai testipäällikkönä et ole hyvässä asemassa neuvotellaksesi testauksesta projektipäällikön kanssa. Sidosryhmillä on huolenaiheensa, ja jos jaat testauksen laajuuden määrittävät mallit heidän kanssaan, heillä on mielipiteitä, he sitoutuvat laajuuteen ja voivat puolustaa sitä. Sidosryhmät vastaavat myös järjestelmäänsä koskevan budjetin perustelemisesta, joten he ovat parhaassa asemassa tasapainottamaan testauksen kustannukset ja tarpeen käsitellä heidän huolenaiheitaan.
Ajattelemisen aihetta
Mieti, kuka projekteissasi ottaa vastuun suoritettavan testauksen määrästä:
- Määritteletkö sinä testaajana testauksen laajuuden ja määrän?
- Asettaako projektipäällikkö budjetin, ja teetkö parhaasi sinulle varatun ajan puitteissa?
- Neuvotellaanko laajuudesta projektipäällikön ja sidosryhmien kanssa, jotta työpanoksen ja suoritettavan testauksen laajuuden välille löydetään tasapaino?
Yksi testaajan keskeisistä vastuista on varmistaa, että projekti on tietoinen otettavista tuotteen riskeistä, ja dokumentoida ne. Vasta kun nämä riskit ovat näkyvissä, johto voi tunnistaa riskit, joita se ottaa testaamista supistamalla.
Oikealle testauksen määrälle ei ole olemassa kaavaa. Useimmissa ympäristöissä testauksen taso voidaan määrittää vain projektijohdon, asiakkaan toimeksiantajien, kehittäjien, teknisten asiantuntijoiden ja testaajien välisellä yhteisymmärryksellä – testit kuuluvat laajuuteen, jos ne käsittelevät huolenaiheena olevia riskejä.
Riittävästä testauksen määrästä tulisi päättää yhteisymmärryksessä siten, että testaaja fasilitoi yhteisymmärrysprosessia ja tuo siihen tietoa.
QA-johtajan uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä kirjoitukset ovat otteita Paulin Testauksen johtaminen -kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä syvällisemmin tähän ja muihin aiheisiin. Jos teet niin, käytä eksklusiivista kuponkikoodiamme QALEADOFFER saadaksesi 60 dollaria alennusta kurssin täydestä hinnasta!
Aiheeseen liittyviä artikkeleita:
