Gap-analyysin käyttäminen testauksessa Devs: n ja testaajien

tasaamiseksi on yleisesti pidetty uskomus, että kehittäjät ja testaajat tulevat toimeen kuin liitu ja juusto. Kehittäjät katsovat usein nenäänsä pitkin testaajia, pitäen heitä joustamattomana ja hyödyttömänä vetona uuden koodin kehittämiseen, jotka eivät anna selkeitä yksityiskohtia vikalipuissaan. Samoin testaajat suhtautuvat kehittäjiin usein ärsyyntyneesti siitä, että he eivät ole pitäneet heitä ajan tasalla koodimuutoksista ja tyrkyttäneet uusia muutoksia testisyklien aikana. Tämän vuoksi laadunvarmistuksen testausprosessin gap-analyysi voi olla erityisen hyödyllinen sekä devs: n että testaajien yhdenmukaistamisessa.

vaikka tämä näkemys voi olla apokryfinen, on usein niin, että kehittäjät ja testaajat eivät kommunikoi hyvin. Usein viestintä tapahtuu vain johdon (projektipäälliköt ja linjajohtajat) tai lippujen kautta Jirassa. Tuloksena on, että testaus osoittautuu usein riittämättömäksi. Erityisesti aivan liian usein uudet säännöt ovat huonosti testattuja tai niitä ei ole testattu lainkaan. Tutkimus on osoittanut, että tämä testaamaton uusi koodi on suurin tulevien vikojen ja epäonnistumisten lähde. Tässä vaiheessa Testivälianalyysin käsite tulee kuvaan.

tässä blogissa tutkimme, mitä Testivälianalyysi on, näytämme, miten se voi auttaa tunnistamaan testattavan koodin ja tutkimme, onko tämä lähestymistapa ihmelääke, joka voi kuroa umpeen devs: n ja testaajien välisen kuilun.

mikä on Testivälianalyysi?

kun ensin kehittää ohjelmistojärjestelmän, on helppo olla varma, että testaa koko järjestelmää. Testaajat pystyvät noudattamaan koodimäärityksiä ja käyttämään suunniteltujen ja eksploratiivisten testien yhdistelmää varmistaakseen, että he testaavat kaikki codebasen liikkuvat osat. Useimmat ohjelmistot eivät kuitenkaan ole staattisia. Yritykset joko tekevät monoliittisia määräajoin julkaistavia pitkäikäisiä koodeja tai ne käyttävät jonkinasteista jatkuvaa integraatiota ja jatkuvaa käyttöönottoa (CI/CD). Kummassakin tapauksessa koodebaasi muuttuu jatkuvasti. Kuitenkin, aivan liian usein testitapaukset eivät päivity samaan tahtiin. Joskus testaajat eivät yksinkertaisesti tiedä, että koodinmuutos on tehty. Muina aikoina koodinmuutos työnnetään juuri sen jälkeen, kun tietty testisarja on ajettu. Testit näyttävät menneen läpi, mutta koodinmuutos on saattanut rikkoa ne.

Test Gap Analysis on näiden aukkojen tunnistamisprosessi, jossa uutta koodia on otettu käyttöön, mutta sitä ei ole vielä testattu. Tämä edellyttää kaikkien koodimuutosten staattisen analyysin ja kaikkien nykyisten testausten dynaamisen analyysin yhdistelmää. Vertailemalla näitä kahta analyysiä voit helposti nähdä, missä mahdolliset aukot ovat. Toisin sanoen uusia koodeja, joita on testattu riittävästi. Tyypillisesti tämä tehdään piirtämällä koodi käyttäen puudiagrammin muotoa, jossa koodi on jaettu funktionaalisiin lohkoihin, kunkin lohkon alapuolella ovat osatekijäluokat, näiden alapuolella ovat varsinaiset menetelmät ja funktiot. Jokaisella hierarkian tasolla lohkon suhteellinen koko ilmaisee koodin määrän. Kun koodin muutoksia osoittava puu asetetaan päällekkäin testauksen nykytilan osoittavan puun kanssa, on helppo havaita alueet, joilla testipeitto puuttuu.

puukartta, jossa on muuttumaton koodi (harmaa), tarkistettu/uusi koodi, joka on testattu (vihreä), tarkistettu koodi, joka on testaamaton (oranssi) ja uusi koodi, joka on testaamaton (punainen).

miksi Testivälianalyysillä voi olla merkitystä testauksessa?

Münchenin teknillisen yliopiston tutkijat tekivät vuonna 2013 tutkimuksen, jossa tarkasteltiin uusien, testaamattomien koodin ja tulevien ohjelmistovirheiden välistä korrelaatiota. He työskentelivät München Re (suuri vakuutusyhtiö), seuranta niiden pitkäikäinen IT-järjestelmän kautta 2 tiedotteet. Julkaisun aikana he selvittivät, mikä koodi oli uusi ja tarkastelivat myös, mitä koodia testattiin ja mikä koodi julkaistiin testaamatta. Sen jälkeen he valvoivat järjestelmää pitkään ja jäljittivät kaikki raportoidut viat takaisin alkuperäiseen lähteeseen. He löysivät kaksi keskeistä asiaa. Ensinnäkin, noin kolmannes kaikesta koodista julkaistiin testaamatta. Toiseksi, kun he jäljittivät vikoja, joita he löysivät kaiken kaikkiaan 70-80% kaikista vioista oli testaamattomassa koodissa. Tämä käy selvemmin ilmi oheisesta graafista.

kuten näette, vanhassa testatussa koodissa ei ollut vikoja. Uudessa testatussa koodissa oli 22-30% vioista ja loput bugit jakautuivat melko tasaisesti uuden testaamattoman koodin ja vanhan testaamattoman koodin välillä. Koska uuden koodin osuus oli kuitenkin vain 15% Koko koodista, voit nähdä, että Uuden testaamattoman koodin osuus oli suhteettoman suuri määrä vikoja.

Testivälianalyysin tarkoituksena on tunnistaa tämä testaamaton uusi koodi. Se voi kuitenkin auttaa sinua myös muilla tavoin. Esimerkiksi, koska se valvoo mitä testaat, se voi tunnistaa olemassa olevan koodin alueita, jotka ovat vanhentuneita (esimerkiksi niitä testataan vielä, mutta niitä ei oikeastaan kutsuta millään koodilla). Se voi myös korostaa, mihin alueisiin sinun täytyy keskittää testausresurssisi. Käyttämällä sitä säännöllisesti johtajat voivat parantaa testauksen suunnittelua, keskittyä testaamaan uutta koodia ja yrittää varmistaa tasaisen testauksen kattavuuden.

Devs ja testaajat linjassa Testivälianalyysin avulla

Testivälianalyysi on selvästi tehokas käsite. Mutta on myös selvää, että kaikki joukkueet eivät hyödy siitä yhtä paljon. Joukkueet, jotka hyötyvät eniten ovat ne, jotka ylläpitävät pitkäikäisiä codebases määräajoin monoliittisia julkaisuja. Pitkäikäisissä koodibaaseissa Kehittäjät työstävät usein muiden ihmisten kirjoittamaa koodia. Testaajat saattavat tukeutua testisuunnitelmiin, joita on tehty useita versioita aiemmin. Yhdessä nämä tekijät voivat tarkoittaa, että kukaan ei ole täysin selvää, mitä koodia testataan tai miten kyseinen koodi on vuorovaikutuksessa järjestelmän muiden osien kanssa. Tässä, TGA voi antaa testaajat nähdä, mitä koodi on muuttunut, jonka avulla he voivat keskittyä tähän. Ne voivat myös tunnistaa olemassa olevasta järjestelmästä koodin, jota ei ole testattu.

CI/CD: tä käyttävät tiimit voivat myös hyötyä tästä lähestymistavasta, koska sen avulla testaajat voivat nopeasti tunnistaa, mitä koodia on muutettu, Ja näin he voivat keskittyä siihen. Se voi myös välttää edellä mainitun ongelman, jossa koodi muutetaan heti sen jälkeen, kun se on testattu ja sitten saa vapauttaa muutokset testaamatta.

toisaalta uutta tai lyhytaikaista koodia työstävät tiimit hyötyvät vähemmän, sillä lähtökohtaisesti suurin osa koodista on aluksi testaamatta. Tässä on tärkeää käyttää standarditestausmenetelmiä, jotta testaus on hyvä. Tällaisille tiimeille voi kuitenkin olla hyödyllistä alkaa seurata testin kattavuutta TGA: n avulla, koska näin ne voivat välttää tulevat ongelmat.

mitkä ovat mahdolliset ongelmat?

TGA: ssa on muutamia ongelmia. Yksi suurimmista liittyy siihen, että se ei voi kertoa, mikä koodi on aktiivisesti kutsutaan codebase. Kehittäjät lisäävät usein uutta koodia valmistautuessaan tuleviin julkaisuihin, mutta koska tämä ei ole aktiivinen, testisarja ei voi kutsua sitä. Tämän seurauksena tämä koodi näkyy aina uutena testaamattomana koodina. Samoin monet suuret koodibaasit sisältävät palikoita vanhaa tai orvoksi jäänyttä koodia. Nämä pitäisi puhdistaa ajoittain, mutta jälleen nämä vääristävät kuvaa Testivälianalyysissä.

toinen tärkeä havainto on, että vain se, että koodia testataan, ei estä sitä laukaisemasta vikoja muualla. Pahimpia vikoja ovat sellaiset, joissa pieni muutos yhdessä koodinpätkässä aiheuttaa funktion tai menetelmän epäonnistumisen täysin liittymättömässä koodilohkossa. Niin, on tärkeää pitää tehdä sekä alustavia testejä ja regressio testaus. Mitä TGA voi tehdä on tunnistaa alueita olemassa codebase, joita ei ole kunnolla testattu aikana regressiotestauksen.

mitkä muut vaihtoehdot auttavat kuilun kuromisessa umpeen?

Testivälianalyysi on varmasti hyödyllinen työkalu joillekin tiimeille. On kuitenkin olemassa muita tapoja välttää epäsuhta sen välillä, mitä testaajat testaavat ja mitä koodaajat koodaavat. Yksi tapa on käyttää älykkäämpää testiautomaatiota, joka pystyy tunnistamaan, missä ja milloin asiat ovat muuttuneet, sekä etupäässä että, mikä tärkeintä, myös taustapäässä. Täällä Functizessa testimme käyttävät älykästä sormenjälkitunnistusta yhdistettynä koneoppimiseen ja itsensä parantamiseen vähentääksemme testien ylläpitoa. Näin testit voivat ennakoivasti sopeutua frontend muutoksia sekä seurata asioita, kuten palvelimen puhelut, vasteajat ja onko painikkeet / toiminnot todella näkyvissä. Tämä tarkoittaa, että testaajat eivät saa kiinni tekemistään muutoksista backend-koodiin tai design/CSS-muutoksiin, jotka muuttavat frontend-asettelua.

älykäs järjestelmämme voi myös luoda testejä seuraamalla, miten käyttäjät ovat vuorovaikutuksessa järjestelmän kanssa. Tämä auttaa varmistamaan, että testin kattavuudessa on vähemmän aukkoja. Yksi uusimmista työkaluistamme mahdollistaa uusien testien kirjoittamisen selkokielellä. Nämä jäsennellään luonnollisen kielen käsittelytyökalumme avulla ja muunnetaan käyttökelpoisiksi testeiksi. Tämä tarkoittaa sitä, että kehityksen aikana devs voi yksinkertaisesti määritellä, mitä täytyy testata normaalilla englannilla, jolloin kuilu näiden kahden tieteenalan välillä kaventuu entisestään.

päätelmät

Testivajeanalyysi auttaa tunnistamaan, mitä koodia julkaistaan testaamatta, ja siten voi auttaa sinua kohdentamaan testausresurssisi tehokkaammin. Ei ole yllättävää, on käynyt ilmi, että testaamaton koodi sisältää paljon todennäköisemmin vikoja, joten mikä tahansa työkalu, joka voi auttaa varmistamaan, että tämä koodi testataan oikein, on hyödyllinen. Kuten olemme nähneet, TGA voi kuitenkin vain täydentää nykyisiä parhaita käytäntöjä. On tärkeää jatkaa regressiotestausta ja tunnustelevia testejä. Monet TGA: n eduista voidaan saavuttaa myös älykkäillä testausvälineillä. Mutta kaiken kaikkiaan, tärkeintä välttää on eristää testiryhmä työstä devs. Jos haluat siteerata vanhaa sanontaa väärin, varmista, että vasen käsi tietää, mitä oikea käsi tekee!