Testaa prosessin parantamista (TPI) PDCA-mallilla

Mitä on testausprosessin parantaminen?

Testiprosessin parantaminen on käytäntö, jossa mitataan testausprosessin suorituskykyä, tunnistetaan sen heikot kohdat ja tehdään hallittuja muutoksia, jotta seuraava projekti tuottaa parempaa laatua alhaisemmilla kustannuksilla ja lyhyemmässä ajassa. Se käsittelee testausta prosessina, jota voidaan mitata ja säätää, sen sijaan, että se toistuisi samalla tavalla jokaisessa julkaisussa.

Kuvittele Guru99 Pankin projekti on juuri valmistunut. Johtokunta arvostaa työtäsi ja asiakas on tyytyväinen. Silti pomollasi on sinulle vielä kysymyksiä.

Johtajat kuvailevat usein ohjelmistojen testaus hankalana ja hallitsemattomana prosessina. Jälkikäteen ajateltuna Guru99 Bank -projekti, kohtasiko teillä seuraavia ongelmia?

Nämä ovat yleisiä ongelmia lähes kaikissa testausprojekteissa. Monet organisaatiot ymmärtävät, että testausprosessin parantaminen on ainoa kestävä tapa ratkaista ne, koska aiemmista virheistä oppiminen estää samojen virheiden toistumisen seuraavassa julkaisusyklissä.

Miksi testata prosessin parantamista?

Seuraava skenaario osoittaa, miksi testausprosessin parantaminen on tärkeää. Guru99 Bank -projekti on valmis, testauksen laatu oli erinomainen ja sait asiakkaalta hyvää palautetta.

Mitä tästä tilanteesta opimme? Se on yksinkertaisesti "Yritä aina tehdä paremmin"Vaikka itse uskoisit tehneesi hyvää työtä, on aina muita, jotka tekevät sen paremmin, koska he ovat löytäneet parempia ideoita ja parempia ratkaisuja kuin sinä.

Jokainen yritys haluaa projektin valmistuvan suurin laatu, osoitteessa alin kustannuksissa ja lyhin toimitusaika. Testausprosessin parantaminen auttaa testaustiimiä etenemään kohti kaikkia kolmea tavoitetta samanaikaisesti.

Kuinka toteuttaa testausprosessin parantaminen?

Testausprosessin parantamisen toteuttaminen Guru99 Pankkiprojektissa Test Manager voi seurata PDCA malli. PDCA (Plan-Do-Check-Act) on nelivaiheinen johtamismenetelmä, jota käytetään liiketoiminnassa prosessin hallintaan ja jatkuvaan parantamiseen. Jokainen läpikäynti silmukan on yksi parannussykli, ja toiminnan tuotoksesta tulee seuraavan suunnitelman syöte.

Vaihe 1) Suunnittele

Suunnitteluvaiheessa parannus suunnitellaan. Se on jaettu kolmeen pienempään vaiheeseen.

Vaihe 1.1) Tunnista ongelma

Testin parannusprosessin ensimmäinen toiminto on tunnistaminen nykyisessä projektissa ilmenneet ongelmat. Tämän projektin ongelmat voivat toistua toisessa projektissa. Testin parantamisen ensisijainen tavoite on ongelmien ratkaiseminen ja ratkaisujen löytäminen niiden välttämiseksi tulevaisuudessa.

Nyt takaisin projektiin Guru99 Bankin verkkosivusto, löydätkö ongelmia tai parannuskohteita? Valitse alta

Vaihe 1.2) Määritä kohde

Ymmärrä ongelma ja projektissa ilmenneet ongelmat. Näin määrität parannuskohteet ja testausvaiheet, joihin on kiinnitettävä huomiota ensin.

Oletetaan, että olet tunnistanut, että myös testin suoritusvaihe kesti paljon aikaa ja kustannuksia. Voitaisiinko testausta tehdä nopeammin ja halvemmalla? Tästä kysymyksestä tulee syklin tavoite. Hyödyllinen tavoite ilmaistaan ​​numerona ja määräaikana, esimerkiksi "vähennä regression suoritustyötä 30 prosentilla ennen seuraavaa julkaisua".

Vaihe 1.3) Määrittele parannustoimenpiteet

Sovitun tavoitteen perusteella määritellään parannustoimenpiteet. Näiden toimenpiteiden tulisi olla asteittaisia ​​ja niitä tulisi ottaa käyttöön pala palalta, koska ei ole realistista muuttaa kaikkea välittömästi.

Esimerkiksi testauksen nopeuttamiseksi ja halpenemiseksi seuraavat toimenpiteet ovat mahdollisia.

Yllä olevassa esimerkissä vaihtoehdot A ja B molemmat nopeuttavat ja halventavat testausta. Vaihtoehto C tekisi testauksesta nopeampaa, mutta se maksaa enemmän, koska kokeneemmalla testaajalla on korkeampi palkka. Juuri tämä kompromissi on syy siihen, miksi jokaista ehdokkaan toimintaa on arvioitava tavoitetta vasten, ei intuitiota vasten.

Vaihe 2) Tee

Olet jo määritellyt parannuskohdat. Nyt on aika laatia suunnitelma niiden toteuttamiseksi. Tämän suunnitelman on vastattava seuraaviin kysymyksiin.

• Mitkä parannuskohdat on toteutettava ja missä järjestyksessä?
• Milloin suunnitelman on oltava valmis?
• Mitä vaiheita on suoritettava suunnitelman saavuttamiseksi?
• Kuka omistaa kunkin vaiheen, ja miten valmistuminen vahvistetaan?

Suorita parannustoimet

Kun suunnitelma on laadittu, se on toteutettava. Parannustoimet voivat häiritä jo käynnissä olevaa testaustyötä, joten testauspäällikön on maksettava huomio heille, jotta välttää ei-toivottuja seuraukset.

Tarkastellaan seuraavaa tilannetta. Guru99 Pankkiprojektissa päätit käyttää testauksen nopeuttamiseksi ja halpenemiseksi automaatiotestaus suuren manuaalisten regressiotestien lohkon sijaan. Toimenpiteen soveltamisen jälkeen tuottavuus kasvoi merkittävästi.

Vaihe 3) Tarkista

Tarkistusvaiheessa teet kolme asiaa.

• Arvioi tehokkuus testin parannustoimista
• Mittaa miten tehokas ratkaisu oli
• Analysoi, voisiko se olla parani edelleen

Tämän vaiheen tavoitteena on varmistaa, että parannustoimenpiteet on toteutettu onnistuneesti, ja arvioida, onko suunnitelmassa asetettu tavoite todella saavutettu.

Paras tapa suorittaa arviointi on ns. mittaritMittarit ovat olennaisia ​​organisaation onnistuneen johtamisen kannalta. Testauspäällikkö kerää dataa ja käyttää sitä mittaamaan parametreja, kuten tuottavuutta, laatua ja kustannuksia.

Esimerkiksi ennen automaation soveltamista projektiin testauksen tuottavuus oli 10 testitapausta työtuntia kohdenAutomaation käyttöönoton jälkeen tuottavuutta mitattiin 20 testitapausta työtuntia kohden.

Mutta tuon voiton rinnalle ilmeni ei-toivottu ongelma.

Tässä tapauksessa käytetään automaatiota kasvoi testauksen tuottavuus, mutta testauksen laatu vähentynytParannustoimenpide voi siksi aiheuttaa vakavia seuraukset muualla. Tällaisessa tilanteessa testaustyökalu on valittava paljon huolellisemmin ja automatisoitua ohjelmistopakettia on tarkasteltava yhtä tarkasti kuin tuotantokoodia. Ehdokastyökalujen strukturoitu arviointi, kuten edellä kuvatussa Selenium oppituntiestää työkalun käyttöönoton pelkästään sen suosion vuoksi.

Tarkastellaan samaa tilannetta uudelleen. Guru99 projektin kustannukset olivat vallata koska tiimin jäsenet ottivat liian paljon aikaa suorittaa testitapaukset. Käyttämällä automaattista testityökalua olet tallentanut 30 prosenttia projektin kustannuksista. Se on hyvä parannus, mutta pomosi odottaa enemmän.

Siksi sinun on aina etsittävä uudempia ratkaisuja, jotka parantavat testausprosessia entisestään. Tässä tilanteessa muut vaihtoehdot voivat säästää projektikustannuksissa lisää.

• Hallitse henkilöstöresurssejasi tehokkaasti, jotta taitavia testaajia käytetään siellä, missä he tuottavat eniten arvoa
• Neuvottele paremmista kaupallisista ehdoista työkalu- ja henkilöstötoimittajiesi kanssa
• Poista kaksoiskappaleet tai arvoltaan vähäiset testitapaukset automatisoinnin sijaan

Vaihe 4) Toimi

Kun parannustoimenpiteet on toteutettu onnistuneesti ja tavoite on saavutettu, testauspäällikön tulee suorittaa silmukka seuraavilla aktiviteeteilla.

• Arvostelu parannustoimet ja toimi opittujen kokemusten pohjalta
• yhdenmukaistaa parannuskohde testauksenhallintaprosessissa
• Päivitykset käytäntöasiakirjat, testaussuunnitelman mallit ja vakioprosessiasiakirjat
• Määrittää milloin ja missä näitä muutoksia sovelletaan seuraavaan projektiin

Jos tavoitetta ei saavutettu, sykli ei pysähdy. Saavuttamaton tavoite siirretään uuteen suunnitteluvaiheeseen yhdessä kaikkien tarkistusvaiheessa paljastuneiden tietojen kanssa siitä, miksi toiminto ei toiminut.

TPI NEXT, TMMi ja CMMI verrattuna

PDCA on parannuksen moottori, mutta referenssimalli kertoo, miltä "parempi" näyttää. Yleisesti käytetään kolmea mallia, ja ne sekoitetaan usein toisiinsa.

TPI NEXT on Sogetin julkaisema testikohtainen vertailumalli. Se arvioi 16 keskeistä aluetta, jotka on jaettu kolmeen ryhmään neljän kypsyystason perusteella: alustava, kontrolloitu, tehokas ja optimoiva. Koska arviointi tapahtuu avainalue kerrallaan, tiimi voi olla tehokas yhdellä alueella ja silti kontrolloitu toisella.

TMMi, jota ylläpitää TMMi Foundation, on vaiheittainen testauskypsyysmalli, jossa on viisi tasoa: alustava, hallittu, määritelty, mitattu ja optimointi. Organisaatio saavuttaa tietyn tason vasta, kun kyseisen tason prosessialueet on täytetty.

CMMI ei ole lainkaan testausmalli. Se kattaa koko kehitysorganisaation, ja sen vaiheittaisella esityksellä on myös viisi kypsyystasoa: alustava, hallittu, määritelty, kvantitatiivisesti hallittu ja optimoiva. TMMi on suunniteltu täydentämään CMMI:tä sen korvaamisen sijaan.

Testausprosessin parantamista osoittavat mittarit

Tarkistusvaihe romahtaa ilman lukuja. Pieni, vakaa metriikkajoukko, joka on kerätty ennen jokaista sykliä ja sen jälkeen, riittää, ja samoja määritelmiä on käytettävä vertailun molemmilla puolilla.

• Testien suorituksen tuottavuus — suoritettujen testitapausten määrä työtuntia kohden
• Vianhavaitsemisprosentti (DDP) — testauksessa löydettyjen vikojen osuus kaikista löydetyistä vioista, mukaan lukien julkaisun jälkeen raportoidut viat
• Kustannukset suoritettua testitapausta kohden — testauksen kokonaiskustannukset jaettuna suoritettujen testitapausten määrällä
• Vaatimusten kattavuus — vaatimukset, joihin liittyy vähintään yksi testitapaus
• Viankorjauksen toimitusaika — vian keskimääräinen ikä koko alueella vian elinkaari

Käyttäen Guru99 pankin luvut, joissa testauksessa löydettiin 180 vikaa ja asiakas ilmoitti 20 virheestä julkaisun jälkeen, laskelma on suoraviivainen.

# Defect Detection Percentage and improvement deltas
def ddp(found_in_test, found_after_release):
    return found_in_test / (found_in_test + found_after_release) * 100

def delta(before, after):
    return (after - before) / before * 100

print("Defect Detection Percentage: %.1f%%" % ddp(180, 20))
print("Productivity gain: %.1f%%" % delta(10, 20))
print("Test cost change: %.1f%%" % delta(50000, 35000))

lähtö:

Defect Detection Percentage: 90.0%
Productivity gain: 100.0%
Test cost change: -30.0%

90 prosentin DDP-arvo tarkoittaa, että joka kymmenes vika pääsi asiakkaalle, joten laatutavoitetta ei täysin saavutettu, vaikka tuottavuus kaksinkertaistui ja kustannukset laskivat 30 prosenttia. Tämä yksi näkemys estää tiimiä julistamasta voittoa liian aikaisin.

Yleisiä testausprosessin parantamisvirheitä

Useimmat parannusohjelmat epäonnistuvat organisatorisista syistä pikemminkin kuin teknisistä. Seuraavat virheet selittävät suurimman osan hylätyistä aloitteista.

• Paranemista ilman lähtötasoa. Jos kukaan ei mitannut prosessia ennen muutosta, kukaan ei voi todistaa muutoksen auttaneen. Kirjaa lähtötilanne jo suunnitteluvaiheessa, älä jälkikäteen.
• Kypsyystason tavoittelu liiketoiminnan ajurin sijaan. Sertifikaatti, joka ei vähennä kustannuksia, vikoja tai toimitusaikaa, on kulu, ei parannus.
• Liian paljon muuttumista kerralla. Kun samaan julkaisuun sisältyy viisi toimintoa, regressiota ei voida tehdä. trackenellekään heistä.
• Rikkoutuneen prosessin automatisointi. Automaatio moninkertaistaa sen vaikutuksen mihin tahansa prosessiin, johon sitä sovelletaan, mukaan lukien heikko testisuunnittelu ja epäselvät aloituskriteerit.
• hyppiäping Act-vaihe. Parannus, jota ei koskaan ole kirjattu testauskäytäntöön ja ohjelmistotestauksen elinkaari dokumentit kuolevat sen keksineen projektitiimin kanssa.
• Testaajia lukuun ottamatta. Ihmiset, joita ei ole kuultu muutoksesta, löytävät luotettavasti keinoja kiertää sen.

Näiden ideoiden viemiseksi eteenpäin, tarkastele vaiheita ohjelmistotestauksen elinkaari, kiristä testitapaus suunnitella, virallistaa vianhallinnan prosessi, arvioi, missä automaatiotestaus antaa aitoa tuottoa ja katso, miten työkalu, kuten HP ALM voi sisältää mittarit, joista Tarkistusvaiheesi riippuu.

UKK