Ohjelmistotestauksen maailmassa tehokas johtaminen osaa määrittää selkeän suunnan sille, miten testaussuunnitelmat sovitetaan yhteen kehitystavoitteiden kanssa. Ohjelmistojärjestelmien monimutkaistuessa perinteiset testausmenetelmät eivät pysy kehityksen tahdissa.
Tässä innovatiiviset lähestymistavat, kuten testimallinnus ja kattavuusanalyysi, ovat ratkaisevan tärkeitä. Näiden käytäntöjen avulla tiimit varmistavat kriittisten polkujen ja poikkeustapausten kattamisen sekä mahdollistavat paremman yhteistyön, pienemmän riskin ja nopeamman toimituksen.
Tässä artikkelissa tarkastelemme, mitä mallinnukseen ja kattavuuteen keskittyvä johtaminen tarkoittaa. Keskustelemme siitä, miten testauksen johtajat voivat hyödyntää näitä strategioita prosessiensa optimointiin, tuotteen laadun parantamiseen ja kattavan testikattavuuden varmistamiseen – samalla kun he edistävät erinomaisuuden ja vastuullisuuden kulttuuria. Olitpa laadunvarmistuspäällikkö, tiiminvetäjä tai haluatko vain syventää ymmärrystäsi testauksen johtamisesta, tämä opas tarjoaa käytännöllisiä näkemyksiä ja tekniikoita testauksen kehittämiseen.
Siirrytään asiaan.
Mikä on testimalli?
Testaus on prosessi, jossa luomme mentaalisia malleja ympäristöstä, ohjelmasta, ihmisen luonnosta ja testeistä itsestään. Kutakin mallia käytetään joko siihen asti, kunnes hyväksymme toiminnan oikeaksi, tai kunnes malli ei enää riitä kyseiseen tarkoitukseen.
Boris Beizer, Ohjelmistotestaustekniikat, 1990
Testisuunnittelu on prosessi, jossa valitsemme käytettävissä olevien vaihtoehtojen joukosta ne testit, joiden uskomme olevan meille ja sidosryhmillemme arvokkaimpia. Testimallit auttavat meitä valitsemaan testit järjestelmällisesti, ja ne ovat testauksen perusta.
Tapa, jolla testaajat käyttävät malleja:
- Tunnistamme ja tutkimme tietolähteitä testimallien rakentamista varten.
- Käytämme näitä malleja tietolähteidemme haastamiseen ja vahvistamiseen sekä tietolähteidemme ja malliemme parantamiseen.
- Käytämme näitä malleja testauksen ja myös kehityksen ohjaamiseen.
Kun testaustehtävä on määritetty, ensimmäinen tehtävämme on tunnistaa tietolähteet. Näitä voivat olla:
- Dokumentaatio: määritykset, suunnitelmat, vaatimukset, standardit, ohjeet ja niin edelleen.
- Henkilöt: sidosryhmät, käyttäjät, analyytikot, suunnittelijat, kehittäjät ja muut.
- Kokemus: oma tietämyksesi ja kokemuksesi samankaltaisista (tai erilaisista) järjestelmistä, mieltymyksesi, ennakkoluulosi, arvauksesi, aavistuksesi, uskomuksesi ja vinoumasi.
- Uusi järjestelmä: testattava järjestelmä, jos se on olemassa, saatavilla ja käytettävissä.
- Vanha järjestelmä: korvattava järjestelmä on ilmeinen tietolähde – se voi joillakin toiminnallisuuden alueilla toimia odotetun toiminnan vertailukohtana.
On tärkeää huomata, että kaikki tietolähteemme ovat erehtyväisiä ja puutteellisia, samoin kuin mallimme. Testaajat käyttävät kokemusta, taitoa ja harkintaa näiden lähteiden läpikäymiseen, vertailuun ja haastamiseen sekä yhteisymmärryksen saavuttamiseen.
Kaikki mallit ovat vääriä, mutta jotkin ovat hyödyllisiä
George Box, ekonomisti.
Testimalli voi olla tarkistuslista tai joukko kriteerejä. Se voi myös olla suunnitteluasiakirjasta johdettu kaavio tai kertovan tekstin analyysista muodostettu esitys. Monia testimalleja ei koskaan kirjata paperille – ne voivat olla mentaalisia malleja, jotka on rakennettu nimenomaan ohjaamaan testaajaa tämän tutkiessa testattavaa järjestelmää.
Mallien tarkoitus on yksinkertaistaa monimutkaisia tilanteita jättämällä pois yksityiskohdat, jotka eivät ole tällä hetkellä merkityksellisiä. Käytämme malleja ongelman yksinkertaistamiseen – esimerkiksi testattavien asioiden valitsemiseen. Malli ohjaa ajatteluamme, ja valitsemme testit tunnistamalla mallin jonkin keskeisen näkökohdan ilmenemismuotoja.
Voimme valita vuokaavion tai ohjausvuokaavion haaroja, tilasiirtymiä tilamallista, syöte- (tai tuloste-)alueen mallin rajoja sekä käyttäjätarinoista johdettuja skenaarioita, jotka on kirjoitettu Gherkin-toimialakohtaisella kielellä.
On kuitenkin syytä olla varovainen: joskus mallit tekevät vaarallisia poisjättöjä – esimerkiksi malli yksinkertaistaa tilannetta liikaa – ja tähän on kiinnitettävä huomiota. Jotta testimallisi olisivat tehokkaampia, on tärkeää hyödyntää erikoistunutta testinhallintaohjelmistoa.
Jos tietolähteemme eivät tarjoa meille suoraan malleja, meidän on kehitettävä ne itse. Kun vaatimukset esimerkiksi esitetään kertovana tekstinä, meidän on käytettävä vaatimusten kieltä ominaisuuksien ja niiden toiminnan logiikan johtamiseen. Tämä voi olla kehittäjille ja testaajille vaikeaa, ja usein kyse on yhteistyöstä, mutta meidän on jatkettava sinnikkäästi.
Mallien käyttäminen testauksessa
Käytämme testimalleja seuraaviin tarkoituksiin:
- Testin kontekstin yksinkertaistaminen. Mallissa jätetään huomiotta epäolennaiset tai merkityksettömät yksityiskohdat.
- Keskitä huomio yhteen järjestelmän käyttäytymisen näkökulmaan. Näitä voivat olla kriittiset tai riskialttiit ominaisuudet, tekniset näkökohdat, kiinnostavat käyttäjätoiminnot tai järjestelmän rakentamiseen tai arkkitehtuuriin liittyvät näkökohdat.
- Luo joukko ainutlaatuisia (mallin kontekstissa) testejä, jotka ovat malliin nähden monipuolisia.
- Mahdollista testauksen arviointi, suunnittelu, seuranta ja täydellisyyden (kattavuuden) arviointi.
Testaajan näkökulmasta malli auttaa meitä tunnistamaan järjestelmän näkökohtia, jotka voivat olla testin kohteena.
Have an account? Log In
Mallit ja kattavuus
Kattavuus on termi, jolla kuvaamme testauksemme perusteellisuutta tai täydellisyyttä suhteessa testimalliimme. Kattavuuskohde on asia, jota haluamme käsitellä testeissämme.
Ihannetapauksessa testimallimme pitäisi tunnistaa kattavuuskohteet objektiivisesti. Kun olemme suunnitelleet tai suorittaneet testejä, jotka kattavat mallimme tunnistamat kohteet, voimme määrittää saavutetun kattavuuden määrän ja ilmaista sen prosenttiosuutena kaikista mallin kohteista.
Mitä tahansa mallia, jonka avulla kattavuuskohteet voidaan tunnistaa, voidaan käyttää.
Mallit ovat usein graafisia, kuten vuokaaviot, käyttötapaukset ja sekvenssikaaviot. Näissä ja monissa muissa malleissa on elementtejä (tai muotoja), jotka on yhdistetty viivoilla tai nuolilla. Näitä kutsutaan yleensä suunnatuiksi graafeiksi.
Kuvitellaan graafinen malli, joka koostuu muodoista ja nuolista. Ainakin kaksi kattavuuskohdetta voidaan määritellä:
- Kaikkien muotojen kattavuus
- Kaikkien nuolten kattavuus
- Ja niin edelleen
Näin ollen mitä tahansa suunnattuna graafina toimivaa mallia voidaan käsitellä samalla tavalla.
Epämuodolliset mallit ovat yleensä tarkistuslistoja tai kriteerejä, joita käytetään kattavuuskohteiden luettelon ideointiin, testaamiseen liittyvien ideoiden synnyttämiseen tai testaukseen tutkivan testauksen istunnon aikana. Nämä luettelot tai kriteerit voivat olla ennalta määriteltyjä tai valmisteltuja osana testisuunnitelmaa tai käyttöön otettuja tutkivan testauksen istunnossa.
Epämuodolliset mallit eroavat muodollisista malleista siinä, että kattavuuskohteiden johtaminen riippuu ammattilaisen kokemuksesta, intuitiosta ja mielikuvituksesta, joten näitä malleja käyttävää kattavuutta ei voida koskaan määrittää määrällisesti. Emme voi koskaan tietää, mitä täydellinen kattavuus tarkoittaa näiden mallien suhteen.
Mallit yksinkertaistavat, joten käytä useampaa kuin yhtä
Hyvä malli tarjoaa keinon ymmärtää monimutkaisuutta, ja se saavuttaa tämän osittain jättämällä pois yksityiskohdat, jotka eivät ole merkityksellisiä. Mallisi voi käyttää tilan, vikatilojen tai virtausten, syöteyhdistelmien, toimialueen arvojen ja niin edelleen käsitteitä.
Yksi malli ei koskaan riitä järjestelmän täydelliseen testaamiseen. Kaikki mallit ovat kompromisseja, joten tarvitsemme useita malleja. Tätä käsitettä kutsutaan yleensä ”monipuolisiksi puoliratkaisuiksi”. Tämä tarkoittaa, että tarvitsemme monipuolisia osittaisia malleja järjestelmän asianmukaiseen testaamiseen.
Vaikka vesiputousprojektin testausvaiheita ei yleensä kuvata näillä termeillä, niissä käytetään malleja eri näkökulmista. Yksikkötestauksella, alijärjestelmien integrointitestauksella, järjestelmätason testauksella ja käyttäjätestauksella on erilaiset tavoitteet; jokainen käyttää eri mallia ja näkökulmaa – tästä monipuolisuus syntyy.
Mallien käyttäminen hallintaan
Mallit ovat testauksen ja myös testauksen hallinnan ytimessä. Tässä on neljä keskeistä näkökohtaa:
- Sidosryhmien osallistaminen
- Laajuus
- Kattavuus
- Arviointi ja edistymisen seuranta
Sidosryhmien osallistaminen
Kun suunnittelemme ja määrittelemme testien laajuuden sekä selitämme sidosryhmille edistymistä ja kattavuuden merkitystä, meidän on käytettävä malleja, jotka ovat ymmärrettäviä ja merkityksellisiä sidosryhmien tavoitteiden kannalta.
Jos suunnittelemme käyttäjätestin, omaksumme todennäköisesti liiketoimintaprosessin kulun malliksemme ja käytämme sitä pohjana jäljittäessämme polkuja käyttäjälle tärkeiden järjestelmäominaisuuksien testaamista varten. Jos testaamme palvelun komponenttien integraatiota teknisen arkkitehdin toimeksiannosta, käytämme testauksemme perustana arkkitehtuurimallia, yhteistyökaavioita, rajapintamäärityksiä ja niin edelleen. Jos testaamme käyttäjien määrittelemiä ominaisuuksia, käytämme käyttäjätarinoita, jotka syntyivät aiemman yhteistyöhön perustuneen vaatimusmäärittelyn tuloksena.
Jos sidosryhmät eivät ymmärrä mallejasi, he eivät ymmärrä testaustasi eivätkä luota siihen tai investoi siihen. He eivät ehkä edes luota sinuun.
Laajuuden hallinta
Järjestelmäajattelun ensimmäinen tehtävä on määrittää järjestelmän rajat. Testauksessa ensimmäinen määrittelemäsi malli auttaa sinua rajaamaan testauksen laajuuden. Alla oleva kaavio on organisaation järjestelmäarkkitehtuurin – ”järjestelmien järjestelmän” – kaaviomainen esitys.
Jokainen järjestelmä (samankeskiset ympyrät) sijaitsee sovellusalueella, kuten CRM:ssä, taloushallinnossa tai verkkosivustolla. Kaikki järjestelmät ja sovellusalueet sijaitsevat ”järjestelmien järjestelmän” sisällä. Mallissa ei tietenkään ole yksityiskohtia, mutta siitä näkee selvästi, kuinka kukin järjestelmä sopii kokonaisarkkitehtuuriin.
Voisimme helposti määritellä testauksemme laajuudeksi esimerkiksi ERP-järjestelmät.
Alla olevassa toisessa kaaviossa olemme lisänneet järjestelmäarkkitehtuuriin yksityiskohtia ja ehdottaneet kolmea tapaa määritellä laajuus täsmällisemmin.
- Keltaisella merkityt järjestelmät ovat niin kutsuttuja tietojärjestelmiä, jotka toimivat tietojen ensisijaisina lähteinä. Nämä järjestelmät saattavat esimerkiksi käyttää yhteistä tietokantaa, ja tietokantakaavion muutokset voivat vaikuttaa haitallisesti mihin tahansa näistä järjestelmistä – jolloin ne kuuluvat testauksen piiriin.
- Violetin viivan rajaamat järjestelmät saattavat jakaa yhteisiä toimintoja tai infrastruktuuria – ehkä ne kaikki käyttävät yhteistä verkkopalvelujen kokonaisuutta, samaa viestijärjestelmää tai toimivat samalla palvelimella.
- Katkoviivainen sininen viiva kuvaa käyttäjän matkaa, joka hyödyntää viivalla yhdistettyjä järjestelmiä. Ehkä käyttäjän matka on muuttunut, ja keskitymme näiden järjestelmien välisen tietovirran yhdenmukaisuuteen ja täsmällisyyteen.
Malli auttaa määrittämään testin laajuuden ja myös selittämään laajuuden sidosryhmille heidän ymmärtämillään ja arvostamillaan termeillä, jotta he toivottavasti hyväksyvät sen.
More Articles
Kattavuuden hallinta
Kattavuuden mittaaminen voi auttaa tekemään testauksesta hallittavampaa. Jos meillä ei ole käsitystä kattavuudesta, emme ehkä pysty vastaamaan kysymyksiin, kuten ”mitä on testattu?”, ”mitä ei ole testattu?”, ”olemmeko jo valmiita?” ja ”kuinka monta testiä on jäljellä?” Tämä on erityisen hankalaa testauspäällikölle.
Kun laajuus on määritelty, seuraava luonteva askel on suunnitellun kattavuuden saavuttaminen.
Testimalleja ja kattavuusmittareita voidaan käyttää määrällisten tai laadullisten tavoitteiden määrittämiseen testien suunnittelua ja suorittamista varten. Tällaisia tavoitteita voidaan käyttää vaihtelevassa määrin suunnitteluun ja arviointiin. Voimme myös mitata edistymistä ja päätellä suunnitellun tai suoritetun testauksen perusteellisuuden tai kattavuuden. Meidän on kuitenkin oltava erittäin varovaisia kaikkien käyttämiemme määrällisten kattavuusmittareiden tai prosenttiosuuksien kanssa.
Kattavuusmittari (joka perustuu muodolliseen testimalliin) voidaan laskea objektiivisesti, mutta mikään kaava tai laki ei sano, että X-kattavuus tarkoittaa Y-laatua tai Z-luotettavuutta. Kaikki kattavuusmittarit antavat vain epäsuoraa, laadullista ja subjektiivista tietoa testauksemme perusteellisuudesta tai kattavuudesta. Kattavuuden ja järjestelmien laadun tai hyväksyttävyyden välillä ei ole merkityksellistä suhdetta.
Määrällisiä kattavuustavoitteita käytetään usein määrittämään testauksen päättämiskriteerit, mutta nämä kriteerit ovat mielivaltaisia. Tiukempi kattavuustavoite saattaa tuottaa kaksinkertaisen määrän katettavia kohteita. Kaksinkertainen määrä testejä, jotka maksavat kaksi kertaa enemmän, ei kuitenkaan tee järjestelmästä kaksi kertaa testatumpaa tai kaksi kertaa luotettavampaa. Tällainen tulkinta on merkityksetön ja järjetön.
Joskus järjestelmän määrittelyyn ja rakentamiseen käytetyt muodolliset mallit voidaan määrätä testaajien käytettäviksi kattavuustavoitteiden määrittelyssä. Toisinaan testaajilla voi olla käytössään vain vähän dokumentaatiota, jolloin heidän on kehitettävä omat mallinsa. Testimallin ja kattavuustavoitteen valinta on jossain määrin mielivaltaista ja subjektiivista. Näin ollen epämuodolliset testimallit ja kattavuusmittarit voivat olla yhtä hyödyllisiä kuin vakiintuneet, muodolliset mallit.
Nopea mallin laatimisharjoitus
Lopuksi vielä nopea harjoitus. Luonnostele seuraavissa esimerkeissä, miltä mallin mielestäsi voisi näyttää – vain sen muoto – joko kuvana/kaaviona, taulukkona tai luettelona:
- Käyttäjiä kiinnostavat järjestelmän päästä päähän ulottuvat käyttäjäpolut.
- Viestipalvelu voi olla neljässä tilassa: sammutettuna, käynnissä, käynnistymässä ja sammumassa.
- Vakuutusmaksulaskurissa on 40 syötearvoa, jotka yhdessä vaikuttavat laskentaan; joidenkin syötteiden välillä on riippuvuuksia.
- Poiminta-, muunnos- ja latausprosessissa on seitsemän vaihetta. Poiminnan jälkeen kukin vaihe joko hylkää tietueet, lähettää ne keskeytystiedostoon tai muuntaa ne ja välittää ne seuraavaan vaiheeseen. Viimeinen vaihe on latausprosessi, joka käsittelee hylkäykset. Testaa, että kaikista poimituista tietueista on pidetty kirjaa.
Tilaa The CTO Clubin uutiskirje, niin saat lisää tietoa testaamisesta!
