Ohjelmistojen testauksen vianhallintaprosessi (virheraporttimalli)

Sisällysluettelo:

Anonim

Mikä on vika?

Virhe on seuraus / tulos koodausvirheestä.

Ohjelmistojen testauksen vika

Ohjelmistotestauksen vika on muunnelma tai poikkeama ohjelmistosovelluksesta loppukäyttäjän vaatimuksiin tai alkuperäisiin liiketoiminnan vaatimuksiin. Ohjelmistovirhe on virhe koodauksessa, joka aiheuttaa virheellisiä tai odottamattomia tuloksia ohjelmistosta, joka ei täytä todellisia vaatimuksia. Testaajat saattavat kohdata tällaisia ​​vikoja testitapauksia suorittaessaan.

Näillä kahdella termillä on hyvin ohut erotuslinja. Teollisuudessa molemmat ovat vikoja, jotka on korjattava, joten jotkut testausryhmät käyttävät niitä keskenään.

Kun testaajat suorittavat testitapauksia, he saattavat kohdata sellaisia ​​testituloksia, jotka ovat ristiriidassa odotettujen tulosten kanssa. Tätä vaihtelua testituloksissa kutsutaan ohjelmistovirheeksi. Näihin vioihin tai muunnelmiin viitataan eri nimillä eri organisaatioissa, kuten ongelmat, ongelmat, virheet tai tapahtumat.

Tässä opetusohjelmassa opit-

  • Virhe raportti
  • Vianhallintaprosessi
    • Löytö
    • Luokittelu
    • Resoluutio
    • Todentaminen
    • Päättäminen
    • Raportointi
  • Tärkeitä vikamittareita

Ohjelmistojen testauksen virheraportti

Vikailmoituksen Ohjelmistojen testaus on yksityiskohtainen dokumentti bugeja löytyy sovelluksesta. Virheraportti sisältää jokaisen virheen yksityiskohdan, kuten kuvauksen, virheen löytämispäivän, sen löytäjän testaajan, korjaavan kehittäjän nimen jne. Virheraportti auttaa tunnistamaan vastaavia vikoja tulevaisuudessa, jotta se voidaan välttää.

Kun ilmoitat virheestä kehittäjälle, virheraporttisi tulisi sisältää seuraavat tiedot

  • Defect_ID - Vian yksilöllinen tunnistenumero.
  • Vian kuvaus - Vian yksityiskohtainen kuvaus, mukaan lukien tiedot moduulista, josta vika löytyi.
  • Versio - Sovelluksen versio, josta vika löytyi.
  • Vaiheet - Yksityiskohtaiset vaiheet sekä kuvakaappaukset, joiden avulla kehittäjä voi toistaa viat.
  • Date Raised - Päivämäärä, jolloin vika on nostettu
  • Viite - missä sinä Anna viite asiakirjoihin, kuten. vaatimukset, suunnittelu, arkkitehtuuri tai ehkä jopa kuvakaappaukset virheestä vian ymmärtämisen helpottamiseksi
  • Havaittu - Vian esille ottaneen testaajan nimi / tunnus
  • Tila - Vian tila, lisätietoja tästä myöhemmin
  • Korjattu - Korjanneen kehittäjän nimi / tunnus
  • Suljettu päivämäärä - Päivämäärä, jolloin vika on suljettu
  • Vakavuus, joka kuvaa vian vaikutusta sovellukseen
  • Prioriteetti, joka liittyy vikojen korjaamisen kiireellisyyteen. Vakavuusprioriteetti voi olla korkea / keskitaso / matala sen vaikutuksen kiireellisyyden perusteella, jossa vika tulisi korjata

Napsauta tätä, jos video ei ole käytettävissä

Resurssit

Lataa esimerkki vikailmoitusmallista

Harkitse seuraavaa testijohtajana

Tiimisi löysi virheitä testatessaan Guru99 Banking -projektia.

Viikon kuluttua kehittäjä vastaa -

Ensi viikolla testaaja vastaa

Kuten edellisessä tapauksessa, jos vikaviestintä tapahtuu suullisesti, asiat muuttuvat pian hyvin monimutkaisiksi. Tarvitset vikojen elinkaaren hallitaksesi ja tehokkaasti vikoja.

Mikä on vianhallintaprosessi?

Vianhallinta on järjestelmällinen prosessi virheiden tunnistamiseksi ja korjaamiseksi. Vianhallintasykli sisältää seuraavat vaiheet: 1) vian löytäminen, 2) vikaluokitus 3) vian korjaus kehittäjien toimesta 4) testaajien suorittama todentaminen, 5) vikojen sulkeminen 6) vikaraportit projektin lopussa

Tämä aihe opastaa sinua, kuinka vianhallintaprosessia sovelletaan projektin Guru99 Bank -sivustolle. Voit hallita vikoja noudattamalla seuraavia ohjeita.

Löytö

Löytövaiheessa projektiryhmien on löydettävä mahdollisimman monta vikaa , ennen kuin loppuasiakas voi löytää sen. Vika sanotaan löytäjäänsä ja muutos tila hyväksytään , kun se on tunnustettu ja hyväksytty kehittäjät

Yllä olevassa skenaariossa testaajat löysivät 84 vikaa verkkosivustolta Guru99.

Katsotaanpa seuraava skenaario; testausryhmäsi löysi joitain asioita Guru99 Bankin verkkosivustolta. He pitävät niitä vikoina ja ilmoittivat kehitystiimille, mutta on ristiriita -

Tässä tapauksessa testijohtajana mitä aiot tehdä?
A) Sovi testiryhmän kanssa, että se on vika
B) Test Manager ottaa tuomarin tehtävän päättää, onko ongelma vika vai ei
C) Sovi kehitystiimin kanssa, joka ei ole vika Correct InCorrect

Tällöin konfliktin ratkaisemiseksi tulisi soveltaa ratkaisuprosessia. Te otatte tuomarina tehtävän päätöksen, onko verkkosivusto-ongelma vika vai ei.

Luokittelu

Vikaluokitus auttaa ohjelmistokehittäjiä priorisoimaan tehtävänsä. Tämä tarkoittaa, että tällainen prioriteetti auttaa kehittäjiä korjaamaan ensin viat, jotka ovat erittäin tärkeitä.

Test Manager luokittelee viat yleensä -

Tehdään pieni harjoitus seuraavasti vedä ja pudota vian prioriteetti alla

  • Kriittinen
  • Korkea
  • Keskitaso
  • Matala
1) Sivuston suorituskyky on liian hidas

2) Verkkosivuston kirjautumistoiminto ei toimi kunnolla

3) Sivuston käyttöliittymä ei näy oikein mobiililaitteissa

4) Sivusto ei muista käyttäjän kirjautumisistuntoa

5) Jotkut linkit eivät toimi

Tässä ovat suositellut vastaukset

Ei. Kuvaus Prioriteetti Selitys
1 Sivuston suorituskyky on liian hidas Korkea Suorituskykyvirhe voi aiheuttaa käyttäjälle suurta haittaa.
2 Sivuston kirjautumistoiminto ei toimi kunnolla Kriittinen Sisäänkirjautuminen on yksi pankkisivuston päätoiminnoista, jos tämä ominaisuus ei toimi, se on vakavia virheitä
3 Sivuston käyttöliittymä ei näy oikein mobiililaitteissa Keskitaso Vika vaikuttaa käyttäjään, joka käyttää älypuhelinta verkkosivuston katseluun.
4 Sivusto ei muista käyttäjän kirjautumisistuntoa Korkea Tämä on vakava ongelma, koska käyttäjä voi kirjautua sisään, mutta ei voi suorittaa muita tapahtumia
5 Jotkut linkit eivät toimi Matala Tämä on helppo korjaus kehityspojille, ja käyttäjä voi silti käyttää sivustoa ilman näitä linkkejä

Vian tarkkuus

Vika Resoluutio ohjelmistojen testaukseen on askel askeleelta prosessin vahvistamisesta vikoja. Vianratkaisuprosessi alkaa virheiden osoittamisesta kehittäjille, jonka jälkeen kehittäjät suunnittelevat vian korjaamisen prioriteettikohtaisesti, sitten viat korjataan ja lopuksi kehittäjät lähettävät päätöslauselman testauspäällikölle. Tämä prosessi auttaa korjaamaan ja seuraamaan vikoja helposti.

Voit korjata vian seuraamalla seuraavia vaiheita.

  • Tehtävä : Määritetty kehittäjälle tai muulle teknikolle korjaamaan ja muuttanut tilaksi Vastaa .
  • Aikataulun korjaus : Kehittäjäpuoli ottaa vastuun tässä vaiheessa. He laativat aikataulun näiden vikojen korjaamiseksi riippuen vian prioriteetista.
  • Korjaa vika : Kun kehitystiimi korjaa vikoja, Test Manager seuraa vian korjausprosessia verrattuna edelliseen aikatauluun.
  • Ilmoita tarkkuudesta : Hanki kehittäjiltä raportti ratkaisusta, kun viat on korjattu.

Todentaminen

Kun kehitystiimi on korjannut vian ja ilmoittanut siitä, testausryhmä tarkistaa , että viat on todella korjattu.

Esimerkiksi yllä olevassa skenaariossa, kun kehitystiimi ilmoitti, että he ovat jo korjanneet 61 vikaa, tiimisi testaa uudelleen varmistaakseen, että viat on todella korjattu vai ei.

Päättäminen

Kun vika on korjattu ja todennettu, vian tila muutetaan suljetuksi . Jos ei, lähetät kehotukselle ilmoituksen vian tarkistamiseksi uudelleen.

Vikailmoitus

Vika raportointi ohjelmistojen testaukseen on prosessi, jossa testauspäälliköille valmistelee ja lähettää vika kertomuksen johtoryhmä palautetta vika ja prosessia vikoja aseman. Sitten johtoryhmä tarkistaa vikaraportin ja lähettää palautetta tai tarjoaa tarvittaessa lisätukea. Vikaraportointi auttaa kommunikoimaan paremmin, seuraamaan ja selittämään viat yksityiskohtaisesti.

Hallintoneuvostolla on oikeus tietää vian tila. Heidän on ymmärrettävä vianhallintaprosessi tukemaan sinua tässä projektissa. Siksi sinun on ilmoitettava heille nykyinen vikatilanne saadaksesi palautetta heiltä.

Tärkeitä vikamittareita

Takaisin edelliseen skenaarioon. Kehittäjä ja testausryhmät ovat tarkastaneet ilmoitetut virheet. Tässä on tämän keskustelun tulos

Kuinka mitata ja arvioida testin suorituksen laatua?

Tämä on kysymys, jonka jokainen Test Manager haluaa tietää. On 2 parametria, joita voit pitää seuraavina

Yllä olevassa skenaariossa voit laskea, että vikojen hylkäyssuhde (DRR) on 20/84 = 0,238 (23,8%).

Toinen esimerkki, jonka oletetaan olevan Guru99 Bankin verkkosivustolla, sisältää 64 vikaa, mutta testausryhmäsi havaitsee vain 44 vikaa, eli heiltä puuttui 20 vikaa. Siksi voit laskea vikavuotosuhteen (DLR) olevan 20/64 = 0,312 (31,2%).

Johtopäätöksenä voidaan todeta, että testin suorituksen laatu arvioidaan seuraavien kahden parametrin avulla

Mitä pienempi DRR: n ja DLR: n arvo on, sitä parempi testin suorituksen laatu on. Mikä on hyväksyttävä suhdealue ? Tämä alue voidaan määritellä ja hyväksyä projektikohteessa tai voit viitata vastaavien projektien mittareihin.

Tässä projektissa suositeltava hyväksyttävän suhteen arvo on 5 ~ 10%. Se tarkoittaa, että testin suorittamisen laatu on heikko. Sinun pitäisi löytää vastatoimia näiden suhteiden vähentämiseksi, kuten

  • Paranna jäsenen testaustaitoja.
  • Käytä enemmän aikaa suorituksen testaamiseen, erityisesti testin suoritustulosten tarkistamiseen.