Mitä työkaluja käytetään vikaselvitysistunnon suorittamiseen?

mitään tracker tallennettujen suodattimien ja joukkomuokkauksen avulla toimii. Tiimit yleensä priorisoivat Jira-taulusta tai MantisBT-näkymästä suodatettuja uusia vikoja, muokkauksen vakavuutta, prioriteettia ja vastuuhenkilöä reaaliajassa kokouksen aikana.

Virhe-/vikatriage ohjelmistotestauksessa

⚡ Älykäs yhteenveto

Vika-asioiden triage on arviointikokous, jossa testausjohtaja, kehitysjohtaja ja projektipäällikkö luokittelevat jokaisen raportoidun vian vakavuuden, prioriteetin ja riskin mukaan, nimeävät sitten vastuuhenkilöt ja sopivat realistisesta korjausaikataulusta.

🔘 Tarkoitus: Arvioi, priorisoi ja määritä jokainen uusi vika, jotta mitään tärkeää ei jää huomaamatta.
☑️ Taajuus: Yleensä kaksi tai kolme tapaamista viikossa, mukautettuna projektin aikatauluun ja vikamääriin.
✅ Osallistujat: Projektipäällikkö, testaustiimin vetäjä, tekninen johtaja ja kehitystiimin vetäjä ovat läsnä pakollisia jäseniä.
🧪 Vakavuus ja prioriteetti: Vakavuusasteet vaikuttavat tuotteeseen, ja prioriteetti määrää korjausjärjestyksen.
🛠️ Kokouksen tulos: Vika-analyysin mittarit toimivat minuutteina ja niitä käytetään seuraavan triage-istunnon pohjana.
⚡ työkalut: Jokainen päätös tallennetaan bugiin tracking-järjestelmä, jotta tarkastusketju säilyy kokouksen jälkeen.

Lue lisää

Mikä on "vikatriage"?

Vika-asioiden triage on prosessi, jossa jokainen vika priorisoidaan sen vakavuuden, esiintymistiheyden, riskin jne. perusteella. Triage-termiä käytetään Ohjelmistotestaus / Laadunvarmistus uusien vikojen vakavuuden ja prioriteetin määrittämiseksi.

Nimi on lainattu ensihoidosta, jossa kiireellisyysluokittelu lajittelee potilaat kiireellisyyden mukaan resurssien ollessa rajalliset. Laadunvarmistustiimi kohtaa saman rajoitteen: vikalista on aina pidempi kuin käytettävissä oleva aika ennen vapautuspäivää, joten jonkun on päätettävä, mikä korjataan nyt, mikä korjataan myöhemmin ja mikä lykätään. Luokittelu on kokous, jossa päätös tehdään ja kirjataan.

Miksi tarvitsemme "vikatriasin"?

Bug Triagen tavoitteena on arvioida, priorisoida ja määrittää vikojen ratkaisu. Tiimin on vahvistettava vian vakavuus, tehtävä tarvittavat muutokset, viimeisteltävä vikojen ratkaisu ja osoitettava resurssit. Käytetään pääasiassa ketterässä projektinhallinnassa.

Ilman triageaa viat jäävät jälkeen tracriippumatta siitä, minkä vakavuusasteen raportoiva testaaja sattui valitsemaan, ja kehittäjät valitsevat työn henkilökohtaisten mieltymysten eikä liiketoimintavaikutusten perusteella. Alla oleva banneri tiivistää syyt, miksi tiimit pitävät kokouksen kalenterissaan.

Kuinka usein "vikatriage" on suoritettava julkaisussa?

Vikatriage-kokouksen tiheys ei ole kiinteä. Riippuu projektitilanteesta.

Seuraavassa on joitain tärkeitä tekijöitä, jotka määräävät Vikatriage-kokousten tiheyden:

Nämä tärkeät tekijät ovat:

Projektin aikataulun mukaan
Vikojen määrä järjestelmässä
Vaikutus tiimin jäsenten saatavuuden aikatauluihin
Projektin yleinen kunto

Yleensä Dfect Triage Meetings pidetään kaksi tai kolme kertaa viikossa.

Tahti kiristyy julkaisun lähestyessä. Tiimit työskentelevät lyhyesti Tungos iteraatiot usein sisällyttävät lyhyen triage-arvioinnin päivittäiseen rutiiniin viimeisen sprintin aikana, kun taas pidemmän suunnitelmapohjaisen syklin projektissa triage-arviointi voidaan tehdä kerran viikossa, kunnes regressiotestaus vaihe alkaa.

Ketkä ovat "vikatriagen" pakolliset ja muut osallistujat?

Pakolliset osallistujat

Alla olevat projektin jäsenet osallistuvat aina Vikatriage-kokouksiin.

Project Manager
Testiryhmän johtaja
Tekninen etumatka
Kehitysryhmän johtaja

Valinnaiset osallistujat

Kehittäjät
Testaajat
Business Analyst

Valinnaiset osallistujat kutsutaan paikalle, kun tietty vika vaatii heidän panostaan, esimerkiksi silloin, kun liiketoiminta-analyytikon on vahvistettava, onko raportoitu toiminta todella ristiriidassa vaatimuksen kanssa vai onko kyseessä naamioitu muutospyyntö.

Osallistujien roolit ja vastuut "vikatriagen" aikana.

Jokainen pakollinen osallistuja saapuu paikalle eri vastuulla, ja kokous etenee aikataulussa vain, jos kaikki kolme valmistautuvat etukäteen.

Testiryhmän johtaja

Suunniteltu bugitriage-kokous ja lähetä kokousilmoitus osallistujille.
Luo vikaraportti ja lähetä se kaikille osallistujille ennen kokousta.
Määritä prioriteetti ja ankaruus vioista.
Pidä esitys, jotta muut jäsenet ymmärtävät vian syyn.
Jokainen kokousmuistio tallennetaan ja lähetetään kokouksen osallistujille.

Kehitysjohtaja

Auttaa vikojen priorisoinnissa.
Keskustele vian vaikeudesta ja selitä vian aiheuttama riski.
Anna puutteiden korjaaminen asianmukaisille kehittäjille.
Päivitä vian ratkaisu ja liitä mukaan kehityshuomautuksia siltä varalta, että tietoja puuttuu tai kehittäjien tarvitsemia lisätietoja.

Project Manager

Apua vikojen priorisoinnissa.
Keskustele laadunvarmistuksen seuraavasta iteroinnin julkaisupäivästä.
On varmistettava, että myös asiaan liittyvät käyttäjien edustajat kutsutaan bug triage-kokoukseen.

Projektipäällikkö pitää hallussaan julkaisupäivämäärää, joten kiistanalaisen vian ratkaiseminen kuuluu yleensä kyseiselle roolille, kuten alla on esitetty.

Mitä tapahtuu "Dfect Triage" -kokouksen aikana?

Testiryhmän johtaja lähettää vikaraportin uusista vioista. Vikatriaasikokouksen aikana jokainen vika analysoidaan, jotta nähdään, onko sille asetettu oikea prioriteetti ja vakavuus.
Prioriteetit järjestetään tarvittaessa uudelleen.
Vikoja analysoidaan ja arvioidaan niiden vakavuuden mukaan.
Tämä sisältää keskustelun vian monimutkaisuudesta, riskeistä, hylkäämisestä, virheiden uudelleenmäärityksestä.
Päivitykset tallennetaan bugiin trackuningasjärjestelmä.
Laadunvarmistusinsinööri tekee muutokset jokaiseen virheeseen ja keskustelee niistä jokaisen osallistujan kanssa.
"Kommentit"-kenttä päivitetään oikein merkitsemällä kokouksen olennaiset kohdat.

Suurin osa keskusteluajasta menee kahteen kenttään, jotka on helpoin sekoittaa. Vakavuusaste ja prioriteetti asetetaan erikseen, ja vika voi saada korkean pistemäärän toisessa ja matalan toisessa.

Aspect	Vakavuus	prioriteetti
Mitä se mittaa	Kuinka pahasti vika vahingoittaa tuotetta tai sen toimivuutta	Kuinka pian vika on korjattava suhteessa muihin töihin
Normaalisti asetettu	Testaaja, joka ilmoittaa viasta	Sovittu triage-menettelyssä, projektipäällikön ja tuotepuolen johtaessa
Ohjaama	Tekninen vaikutus ja siihen liittyvä toiminnallisuus	Vaikutus liiketoimintaan, asiakasnäkyvyys ja julkaisupäivämäärä
Esimerkki epäsuhdasta	Vakavuusaste, matala prioriteetti: kaatuminen ominaisuudessa, jota kukaan ei käytä ennen ensi vuosineljännestä	Alhainen vakavuusaste, korkea prioriteetti: väärin kirjoitettu yrityksen nimi laskeutumissivulla

Vinkki: Pidä yksittäisen vian käsittely lyhyenä. Kun asiaa ei voida ratkaista muutamassa minuutissa, jätä se hyllyyn, määrää omistaja tutkimaan asiaa ja tuo asia takaisin seuraavaan istuntoon sen sijaan, että antaisit yhden vian kuluttaa kokouksen.

Mikä on "vikatriasin" tulos?

Jokaisen kokouksen päätteeksi laaditaan ja annetaan kaikille osallistujille Defect Triage -mittarit. Tämä raportti toimii kokouspöytäkirjana, josta on hyötyä tulevissa kokouksissa.

Raportti on kohta, jossa triage-prosessi kytkeytyy takaisin laajempaan kokonaisuuteen. vianhallinnan prosessiTiimit yleensä tallentavat siihen seuraavat asiat:

Istunnossa tarkastellut viat ja kunkin vian vakavuus ja prioriteetti sovittuina.
Äskettäin määritetyt viat sekä ne nyt omistava rakennuttaja.
Lykätyt, hylätyt tai kaksoiskappaleiksi merkityt viat ja niiden syy kirjattu.
Avaa vikojen määrä vakavuuden mukaan, jotta trendi istuntojen välillä on näkyvissä.
Toimenpiteet siirrettiin seuraavaan kokoukseen.

Koska jokainen muutos kirjataan takaisin tracker, jokaisen kohteen tila pysyy samana kuin sen sijainti vian elinkaari, ja seuraava istunto alkaa tarkasta listasta vanhentuneen sijaan.

UKK

Pidä kokous 30–60 minuutissa. Etukäteen jaettu vikaraportti hoitaa perusteellisen läpikäynnin, joten itse kokous vain vahvistaa päätökset. Kaikki perusteellista teknistä tutkimusta vaativat asiat jätetään omistajan hoidettavaksi ja palautetaan seuraavaan kokoukseen.

Ketterät tiimit arvioivat tuloksia lyhyissä, tiheissä tapaamisissa, jotka usein liitetään päivittäisiin stand-up-kokouksiin, koska sprinttihorisontti on vain kaksi viikkoa. Suunnitelmalähtöiset projektit pitävät pidempiä virallisia kokouksia harvemmin, ja niissä käytetään raskaampaa dokumentaatiota ja laajempaa sidosryhmäluetteloa.

Lykätty vika pysyy avoimena, mutta siirtyy pois nykyisestä versiosta, yleensä tallennettuna kohdeversiona. Hylätty vika suljetaan kirjallisella syyllä – ei toistettavissa, toimii suunnitellusti tai on kaksoiskappale – jotta päätöstä voidaan tarkastella myöhemmin uudelleen.

Yksi raportti säilytetään pääraporttina ja loput linkitetään siihen ja suljetaan kaksoiskappaleina. Niiden hiljainen sulkeminen menettää tietoja, joten linkillä on merkitystä: se säilyttää jokaisen raportoijien toimittaman kopiointivaiheen ja ympäristön yksityiskohdat.

mitään tractallennetut suodattimet ja joukkomuokkaus toimivat. Tiimit yleensä luokittelevat JIRA lauta tai MantisBT tarkastella suodatettuja uusia vikoja, muokata vakavuutta, prioriteettia ja vastuuhenkilöä reaaliajassa kokouksen aikana.

Koneoppimismallit ryhmittelevät samankaltaisia raportteja kaksoiskappaleiden esiin nostamiseksi, ehdottavat vakavuusastetta aiempien vikojen sanamuodon perusteella ja reitittävät jokaisen kohdan komponentin omistajalle. Käsittele tulosta ensimmäisenä luonnoksena – kokous vahvistaa silti jokaisen päätöksen.

Kyllä, epäsuorasti. GitHub Copilot osaa tiivistää pinon trace. laatia lisääntymistesti ja selittää kyseinen koodi, mikä lyhentää omistajan suorittamaa tutkimusta triage-menettelyn jälkeen sen sijaan, että se korvaisi varsinaisen kokouksen.

Projektipäällikkö, koska ratkaisuhetki on pikemminkin liiketoimintaan liittyvä kuin tekninen puhelu julkaisupäivästä. Kehitysjohtaja antaa työmääräarvion ja testausjohtaja vaikuttavuustiedon, jotka ohjaavat päätöstä.