Vianhallintaprosessi ohjelmistotestauksessa
Thomas Hamilton
⚡ Älykäs yhteenveto
Ohjelmistotestauksen virheenhallintaprosessi on jäsennelty viitekehys virheiden tunnistamiseen, luokitteluun, ratkaisemiseen, varmentamiseen, sulkemiseen ja raportointiin. Se mahdollistaa ennustettavan kommunikaation testaajien ja kehittäjien välillä, parantaa julkaisujen laatua ja vähentää tuotantotason virheiden hallintaa projektin elinkaaren aikana.
Mikä on vianhallintaprosessi?
Vianhallintaprosessi on systemaattinen lähestymistapa, jota käytetään ohjelmistotestauksessa virheiden tunnistamiseen, luokitteluun, korjaamiseen ja varmentamiseen ennen ohjelmiston julkaisua. Elinkaari sisältää kuusi ydinvaihetta: 1) Vian löytäminen, 2) Luokittelu, 3) Kehittäjien suorittama ratkaisu, 4) Testaajien suorittama varmennus, 5) Päättäminen ja 6) Vikaraportointi projektin lopussa.
Tässä artikkelissa selitetään, miten vianhallinnan prosessia sovelletaan Guru99 Bankin verkkosivuston esimerkki, jotta aloittelijat ja keskitason testaajat voivat ymmärtää jokaisen vaiheen todellisessa projektikontekstissa.
Miksi tarvitset vianhallintaprosessia?
Kuvittele, että tiimisi on löytänyt useita bugeja testatessaan Guru99 Pankkiprojekti. Ilman jäsenneltyä prosessia testaajien ja kehittäjien välinen kommunikaatio tapahtuu suullisesti tai hajanaisten viestien kautta.
Viikkoa myöhemmin kehittäjä vastaa eri tavalla tulkitsemalla ongelman.
Seuraavalla viikolla testaaja vastaa uudelleen, mikä aiheuttaa lisää hämmennystä.
Kun vikailmoituksia käsitellään suullisesti tai epävirallisesti, asiat mutkistuvat hyvin nopeasti. Vikojen hallitsemiseksi ja tehokkaaksi hallitsemiseksi tarvitaan määritelty vian elinkaari, joka standardoi tiimien raportointitavat. track ja sulje ongelmat.
Vaihe 1) Löytäminen
In Löytö vaiheessa projektitiimin on tunnistettava mahdollisimman monta vikaa ennen kuin loppukäyttäjä kohtaa ne. Vika katsotaan "löydetyksi", kun kehitystiimi on kuitannut ja hyväksynyt sen, jolloin sen tila muuttuu muotoon Hyväksytty.
Esimerkkiskenaariossa testaajat löysivät 84 vikaa Guru99 Bankin verkkosivusto.
Testaajat ja kehittäjät eivät kuitenkaan aina ole samaa mieltä. Tarkastellaan seuraavaa tapausta, jossa testaustiimi tunnistaa ongelmia Guru99 Bankin verkkosivusto ja raportoi niistä, mutta kehitystiimi kiistää, ovatko ne vikoja:
Mitä sinun testipäällikön tulisi tällaisessa tapauksessa tehdä?
A) Samaa mieltä testausryhmän kanssa siitä, että kyseessä on vika.
B) Ota tuomarin rooli ja päätä, onko ongelma vika vai ei.
C) Olen samaa mieltä kehitystiimin kanssa siitä, ettei kyseessä ole vika.
Oikea lähestymistapa on vaihtoehto B. Konfliktin ratkaisemiseksi tulisi soveltaa ratkaisuprosessia, ja testauspäällikön tulisi arvioida ongelma puolueettomasti ennen kuin hän päättää, voidaanko se luokitella virheeksi.
Vaihe 2) Luokittelu
Vikojen luokittelu auttaa kehittäjiä priorisoimaan työtään siten, että liiketoiminnan kannalta kriittisimmät ongelmat korjataan ensin. Luokittelun suorittaa tyypillisesti testipäällikkö, ja se perustuu vakavuuteen ja liiketoimintaan kohdistuviin vaikutuksiin.
Viat ryhmitellään yleensä neljään prioriteettitasoon: Kriittinen, Korkea, Keskitaso ja MatalaKokeile määrittää oikea prioriteetti kullekin seuraavista vioista:
- Verkkosivuston suorituskyky on liian hidas.
- Sivuston kirjautumistoiminto ei toimi kunnolla.
- Verkkosivuston graafinen käyttöliittymä ei näy oikein mobile laitteita.
- Verkkosivusto ei muista käyttäjän kirjautumisistuntoa.
- Jotkin linkit eivät toimi.
Tässä ovat suositellut vastaukset:
| Ei. | Tuotetiedot | prioriteetti | Selitys |
|---|---|---|---|
| 1 | Verkkosivuston suorituskyky on liian hidas | Korkea | Suorituskykyongelmat aiheuttavat suuria haittoja loppukäyttäjille. |
| 2 | Kirjautumistoiminto ei toimi oikein | kriittinen | Kirjautuminen on pankkisivuston ydintoiminto. Jos se epäonnistuu, koko käyttäjän prosessi estetään. |
| 3 | Käyttöliittymä ei näy oikein mobiililaitteilla | Keskikova | Vika vaikuttaa käyttäjiin, jotka selaavat verkkosivustoa älypuhelimilla. |
| 4 | Verkkosivusto ei muista käyttäjän kirjautumisistuntoa | Korkea | Käyttäjät voivat kirjautua sisään, mutta eivät voi suorittaa muita tapahtumia. |
| 5 | Jotkin linkit eivät toimi | Matala | Helppo korjaus kehittäjille, ja käyttäjät voivat edelleen käyttää sivuston muita osia. |
Vaihe 3) Vian ratkaiseminen
Vianratkaisu Ohjelmistotestauksessa virheiden korjaaminen on vaiheittainen prosessi. Ratkaisuprosessi alkaa virheiden osoittamisella kehittäjille, jotka sitten aikatauluttavat korjaukset prioriteetin mukaan, toteuttavat korjaukset ja lopuksi lähettävät ratkaisuraportin takaisin testipäällikölle. Tämä prosessi tekee virheistä trackuningas läpinäkyvä ja vastuullinen.
Voit korjata vian seuraavilla tavoilla:
- Tehtävä: Vika on määritetty kehittäjälle tai teknikolle, ja sen tila muuttuu muotoon vastaaminen.
- Aikataulun vahvistaminen: Kehitystiimi ottaa ohjat käsiinsä ja luo korjausaikataulun vian prioriteetin perusteella.
- Korjaa vika: Kehittäjien korjatessa virheitä, testipäällikkö tracks etenee suunniteltua aikataulua vastaan.
- Ilmoita päätöslauselmasta: Kehittäjät lähettävät raportin, jossa vahvistetaan, mitkä viat on korjattu ja miten.
Vaihe 4) Vahvistus
Sen jälkeen, kun kehitystiimi on kiinteä ja raportoitu viat, testaustiimi tarkastanut että ongelmat on ratkaistu.
Esimerkiksi kun kehitystiimi raportoi korjanneensa 61 vikaa, testaustiimi testaa jokaisen uudelleen varmistaakseen, toimivatko korjaukset oikein samoissa olosuhteissa, jotka aiheuttivat alkuperäisen vian.
Vaihe 5) Sulkeminen
Kun vika on korjattu ja varmistettu, sen tilaksi muutetaan SuljettuJos vikaa ei korjata kunnolla todennuksen aikana, sinun on lähetettävä ilmoitus takaisin kehitystiimille, jotta he voivat tutkia asiaa uudelleen. Sulkeminen tarkoittaa, että vika ei ole enää aktiivinen järjestelmässä.
Vaihe 6) Vikailmoitus
Vikailmoitus Ohjelmistotestauksessa testipäälliköt valmistelevat ja jakavat vikatilanteen johtotiimin kanssa. Johtotiimi tarkistaa raportin ja antaa tarvittaessa palautetta tai lisätukea. Vikaraportointi parantaa viestintää, trackuningas ja näkyvyys vikojen ympärillä.
Johdolla on oikeus ymmärtää vikojen tila voidakseen tukea projektia tehokkaasti. Siksi sinun on raportoitava säännöllisesti vallitsevasta vikojen tilanteesta, jotta he voivat tarjota ohjausta ja resursseja.
Tärkeitä vikamittareita
Palataanpa alkuperäiseen skenaarioon, jossa kehittäjä- ja testaustiimit tarkastelevat vikoja yhdessä. Yhdistetyt tulokset on esitetty alla.
Miten voit mitata ja arvioida testien suorituksen laatua?
Tämä on kriittinen kysymys joka Testipäällikkö haluaa vastata. Tyypillisesti käytetään kahta keskeistä parametria:
Yllä olevassa skenaariossa Vikojen hylkäyssuhde (DRR) lasketaan seuraavasti: 20/84 = 0.238 (23.8 %).
Toisena esimerkkinä oletetaan, että Guru99 Bankin verkkosivuilla on yhteensä 64 vikoja, mutta testaustiimi havaitsee vain 44 — merkitys 20 vikoja ei havaittu. Vikavuotosuhde (DLR) lasketaan seuraavasti: 20/64 = 0.312 (31.2 %).
Yhteenvetona voidaan todeta, että testien suorituksen laatua arvioidaan käyttämällä kahta alla olevaa parametria:
Mitä pienemmät DRR- ja DLR-arvot ovat, sitä parempi on testien suorituksen laatu. Hyväksyttävä alue määritellään yleensä projektin tavoitteiden perusteella tai sitä verrataan vastaaviin projekteihin. Tässä esimerkissä suositeltu hyväksyttävä alue on 5%: sta 10%Nykyinen suoritus on tämän alueen ulkopuolella, mikä viittaa siihen, että testin laatua tulisi parantaa seuraavilla toimenpiteillä:
- Parantaa tiimin jäsenten testaustaidot.
- Vietä enemmän aikaa testien suorituksesta, erityisesti suorituksen tuloksia tarkasteltaessa.
Parhaat käytännöt tehokkaaseen vianhallintaan
Jäsenneltyjen parhaiden käytäntöjen noudattaminen erottaa kypsän vianhallinnan prosessin kaoottisesta. Tavoitteena ei ole vain korjata vikoja, vaan luoda järjestelmä, joka estää niiden vuotamisen tuotantoon ja minimoi testaajien ja kehittäjien väliset kommunikaatiokatkokset.
Tässä ovat parhaat käytännöt, jotka aloittelevien ja keskitason testaajien tulisi omaksua heti:
- Standardoi vikamallipohja: Käytä kiinteää vikaraporttimallia, joka sisältää kenttiä, kuten vikatunnus, Description, Toistamisen vaiheet, Vakavuusaste, Prioriteetti, Ympäristö ja Liitteet. Johdonmukaisuus vähentää testaajien ja kehittäjien välistä edestakaista tiedonvaihtoa.
- Priorisoi ennen määräämistä: Luokittele viat aina vakavuuden ja prioriteetin mukaan ennen niiden lähettämistä kehittäjille. Tämä varmistaa, että kriittiset ongelmat eivät jää kosmeettisten ongelmien taakse.
- Kopioi ennen raportointia: Toista vika vähintään kaksi kertaa puhtaassa ympäristössä ennen sen esiin nostamista. Toistettavissa olevat viat sulkeutuvat nopeammin ja vähentävät hylkäysprosenttia.
- Hyväksy vika tracKuninkaan työkalu: Käytä työkaluja, kuten KIERTUE, Bugzillatai Rukoilijasirkka keskittää trackuningas, historia ja raportointi.
- Pidä triage-kokouksia: Pidä lyhyitä, kohdennettuja vikasietoisuuskokouksia yhdenmukaistaaksesi laadunvarmistus-, kehitys- ja tuotetiimien prioriteetit.
- Mittaa vuoto ja hylkäys: Track DLR ja DRR joka sprintissä tai syklissä. Nouseva vuotoaste on varhainen varoitus siitä, että testikattavuus on puutteellinen.
- Suorita perussyyanalyysi: Toistuvien tai vakavien vikojen kohdalla suorita perussyyanalyysi, jotta saman luokan virheitä ei esiinny tulevissa julkaisuissa.
- Sulje raportointikierros: Jaa viikoittaiset vikaraportit sidosryhmien kanssa, jotta ongelmat pysyvät näkyvissä ja niihin voidaan puuttua.
Johdonmukaisesti sovellettuina nämä käytännöt vakauttavat vian elinkaarta ja parantavat jokaisen julkaisun yleistä laatua.
