Virheilmoituksen kirjoittaminen esimerkkien avulla

Mikä on Bug Report? Miksi tarvitset hyvän virheraportin?

Bug Report on tärkeä asiakirja STLC:ssä, joka tarjoaa erilaisia ​​etuja testaustiimille. Se pitää kirjaa kaikista vioista, useista virheistä, virheistä ja muista ohjelmistotestauksen aikana löydetyistä eroista ja raportoi niistä.

Tämän testauksen jälkeisen dokumentaation tarkoituksena on antaa asianomaiselle ammattilaistiimille tietoa testausprosessin aikana havaittujen virheiden tasosta.

Sinun ohjelmistokehitysinsinööri voidaan tehdä tietoisiksi kaikista ohjelmistossa olevista vioista ja ongelmista tämäntyyppisen raportin avulla. Sen avulla voit myös selvittää, mikä virheessä on vialla, joten voit käyttää parasta tapaa korjata se. Se auttaa myös säästämään aikaasi ja rahaasi auttamalla sinua löytämään vikoja ja ongelmia.

Miksi sinun pitäisi välittää hyvistä virheselityksistä?

Tässä on se kohta, joka sinun on otettava huomioon kirjoittaaksesi hyvän, yksityiskohtaisen ohjelmistovirheraportin:

• Se toimii oppaana, joka auttaa välttämään saman bugin tulevissa julkaisuissa.
• Säästä aikaa viestintään (sähköpostit, puhelut).
• Less työskentelemään kehittäjille (he tekevät juuri mitä haluat).
• Sinulla on vähemmän pullonkauloja projektissa; virheet korjataan nopeammin ja tehokkaammin.

Virheilmoituksen kirjoittaminen (Virheraporttimalli)

Tarkkaa vikaraporttimallia ei ole, koska se riippuu virheenseurantajärjestelmästäsi. Mallisi voi olla erilainen.

Seuraavat yleiset kentät ovat kuitenkin aina tarpeen, kun haluat kirjoittaa virheraportin:

• Vian tunnus/otsikko.
• Vakavuus ja prioriteetti.
• Tuotetiedot
• ympäristö
• Vaiheet lisääntymiseen.
• Odotettu tulos.
• Todellinen tulos.
• Liitteet (kuvakaappaukset, videot, teksti)

Katsotaanpa kaikkia näitä virheenkorjauskomponentteja yksitellen:

1) Otsikko/virhetunnus:

Jokaiselle bugille tulee antaa yksilöllinen tunnistenumero. Virheilmoitustyökalujen tulee olla yksilöiviä numeroita äskettäin esiin tulleille virheille, jotta voimme helposti tunnistaa vian.

Esimerkkejä:

❌ Huono: "En näe tuotetta, kun taas kerran, tyrp se ei näy."

• Epämääräinen
• Aggressiivinen
• Liian sanallinen

pyytää ratkaisun toteuttamista.

✅ Hyvä: "OSTOSORI – Ostoskoriin on lisätty uusia tuotteita, jotka eivät näy".

• Tällainen otsikko löytää välittömästi ongelman (CART)
• Se keskittyy varsinaiseen tekniseen ongelmaan.

2) Virheen vakavuus:

Virheen vakavuus on erittäin tärkeä tekijä virheraportissa. Se kuvaa vian vaikutusta sovelluksen suorituskykyyn.

• Estoaineet: Tämä virhe aiheuttaa sovelluksen epäonnistumisen.
• Suuri: Kriittinen virhe tarkoittaa suurta muutosta liiketoimintalogiikassa.
• Minor: Ongelma, joka ei vaikuta sovelluksen toimintaan, mutta vaikuttaa odotettuihin tuloksiin.
• Triviaali: Se ei vaikuta sovelluksen toimivuuteen tai toimintaan. Se voi olla kirjoitusvirhe.

3) Virheen prioriteetti:

Seuraava on yleinen asteikko virheen prioriteetin määrittämiseksi:

• Korkea: Se kattaa kaiken, mikä vaikuttaa virtaukseen tai estää sovellusten käytön.
• Medium: Se vaikuttaa haitallisesti käyttökokemukseen.
• Minor: Kaikki muut virheet, kuten (kirjoitusvirheet, puuttuvat kuvakkeet, asetteluongelmat jne.).

4) Ympäristö:

Virhe voi esiintyä tietyssä ympäristössä, ei muissa. Joskus esimerkiksi virhe ilmenee, kun verkkosivustoa käytetään Firefox, tai sovelluksen toimintahäiriö vain käytettäessä Android laite ja toimii hyvin iPhonessa.

Nämä virheraportit voidaan tunnistaa vain selaimen tai laitteiden välisellä testauksella. Joten virhettä raportoidessaan laadunvalvontaviranomaisten tulisi pystyä määrittämään, tuleeko vika havaita yhdessä vai useammassa tietyssä ympäristössä.

5) Yhteenveto:

Pelkän otsikon lisääminen vikaraporttiin ei kuitenkaan palvele tarkoitusta. Joten jos otsikkosi ei riitä, voit lisätä lyhyen raportin yhteenvedon.

Yhteenveto mahdollisimman pienellä sanalla, mukaan lukien milloin ja miten virhe tapahtui. Otsikkoasi ja virhekuvaustasi tulee myös käyttää hauissa, joten sinun on varmistettava, että olet kattanut tärkeät avainsanat.

Esimerkit:

• huono: "Yritin lisätä asioita testiin, mutta mitään ei näkynyt, kun tein sen tai napsautin painiketta."
• Hyvä: "Kun yritin lisätä [TUOTETTA] ostoskoriin, mutta mitään ei tapahtunut, kun klikkasin "lisää" -painiketta tietyn tuotteen yleiskatsauksen verkkosivulla."

6) Toistamisvaiheet:

Kun ilmoitat virheestä, on tärkeää määrittää vaiheet sen toistamiseksi. Sinun tulee myös sisällyttää toimintaan, joka voi aiheuttaa virheen. Älä tee tässä mitään yleisiä lausuntoja.

Ole tarkka seuraavissa vaiheissa:

Tässä on esimerkki hyvin kirjoitetusta menettelystä:

Vaiheet:

1. Valitse tuote X1.
2. Klikkaa Lisää ostoskoriin.
3. Poista tuote ostoskorista napsauttamalla Poista.

7) Odotettu tulos:

Virheraporteissa on tärkeää kuvata odotettu tulos teknisen tehtävän, testitapauksen tulosten suunnittelun tai testaajan mielipiteen mukaan. Kaikki tämä auttaa kehittäjiä keskittymään tarvittavan tiedon nopeaan löytämiseen.

Esimerkiksi:

Pakolliset kentät tulee korostaa punaisella "Lähetä"-painikkeen painamisen jälkeen.

8) Todellinen tulos:

Kuten nimestä voi päätellä, tämä kenttä kuvaa vian todellista vaikutusta. On erittäin tärkeää kirjoittaa selkeä kuvaus todellisesta tuloksesta.

Esimerkiksi:

Pakolliset kentät on korostettu vihreällä "Lähetä"-painikkeen painamisen jälkeen.

9) Liitteet (kuvakaappaukset ja videot):

Virheraporteissa on parasta liittää tiedostoja virheraportteihin, mikä helpottaa tietojen havaitsemista, kun haluat näyttää ne visuaalisesti:

Esimerkiksi:

• Kuvakaappaus: Näyttökaappaukset voivat helposti kehittää ohjelman virheitä; on kätevää, kun vika on korostettu tietyllä merkinnällä, ympyrällä tai nuolella).
• Video: Joskus virhettä on vaikea kuvailla sanoin, joten on parempi luoda video, jotta kehittäjä voi korjata ohjelman vian).

10) Versio, jota asia koskee:

Se on ohjelmistoversio, jossa vika ilmoitetaan.

11) Korjausversio:

Se on ohjelmistoversio, jossa vika on korjattu. Joten kun virheestä ilmoittanut laadunvalvontaviranomainen tarkistaa, onko se korjattu, hän käyttää oikeaa ohjelmistoversiota.

12) Target versio:

Kohdeversio, johon virhe tulisi kohdistaa korjattavaksi. Joten kun kehitystiimi työskentelee virheen korjaamiseksi, ne kohdistavat enimmäkseen tiettyyn sovellusversioon.

13) Sulkemispäivä:

Se on päivämäärä, jolloin ohjelmistotestaustiimi sulkee virheen. Virheen sulkeminen on tärkeä ja olennainen osa ohjelmistotestausta.

14) Tila:

Kun uusi bugi luodaan, sen tilan tulee olla avoin. Sen jälkeen se käy läpi vaiheita, kuten käynnissä, korjattu, käynnissä, uudelleen avaaminen jne.

Vinkkejä virheraporttien kirjoittamiseen

Tässä on muutamia tärkeitä vinkkejä, jotka sinun tulee muistaa, kun kirjoitat tehokasta virheraporttia:

• Ole tarkka luodessasi virheraportteja. Varmista, että et sisällytä mitään hyödyttömiä tai merkityksettömiä tosiasioita.
• Sinun tulee ilmoittaa virheestä heti, kun se havaitaan.
• Valmistele raportti yksityiskohtaisesti, jotta kehittäjä voi käyttää tosiasioita ja tietoja ongelman korjaamiseen.
• Sinun tulisi testata samaa bugiesiintymistä muissa vastaavissa moduuleissa validointia varten.
• Revkatso vikaraportti vähintään kerran ennen sen lähettämistä.
• Varmista, että vikaraportti sisältää vain yhden virheen kuvauksen.
• Lopuksi, sinun ei pitäisi pelätä pyytää apua projektipäälliköltä, jos jokin asia tuntuu epäselväksi.

Virheilmoitustyökalut

Manuaalisesti suoritettava virheraportointiprosessi suoritetaan nyt erilaisilla markkinoilla olevilla virheraportointityökaluilla.

• KIERTUE
• Zoho Bug Tracker
• Bugzilla

Voit tarkistaa yksityiskohtaisen arvostelumme paras bugiraportointityökalu.

Yleinen ongelma ja ratkaisu vikaraporttia kirjoitettaessa:

Tässä on joitain yleisiä ongelmia ja niiden ratkaisuja virheraporttia kirjoitettaessa:

Esimerkki virheilmoituksesta	Ongelma
Kun kerrotaan 2 kolmella, vastaus on myönteinen.	Ilmoita malli, älä esimerkki.
Luettelo järjestetään aakkosjärjestyksessä, kun lisäät uutta tuotetta tämän välttämiseksi.	Älä vain kuvaile, mikä on vialla
Esimerkiksi: Jotta voisit olla, sinun on avattava selaimesi ja kirjoitettava sivuston URL-osoite. Ensimmäinen kenttä "käyttäjänimi" on kirjoitettu väärin.	Aina suoraan asiaan (älä koskaan kerro tarinaa!).
Asiakkaan nimi raportissa on kirjoitettu väärin. Prioriteetti: korkea, vakavuus: korkea	Älä koskaan sekoita tärkeysjärjestystä ja vakavuutta.
Veron laskentakaava on VÄÄRIN !!??	Ei käytä isoja kirjaimia, punaisia ​​kirjaimia, punaisia ​​ympyröitä, '!',
En usko, että kotisivu Ul design on hyvä.	Älä käytä arvostelukykyäsi.
Esimerkki epäselvästä kuvauksesta: Tee tämän sivun edellyttämät toimet tämän päivän keskustelustamme.	Tee kuvauksestasi ymmärrettävä kaikille.
Sivun taustan tulee olla sininen, oranssi tai vihreä, tai voit tehdä sen mustaksi tai valkoiseksi. Tämä ei ole hyvä, koska on epäselvää, mitä web-kehitys- ja suunnittelutiimiltä tarvitaan	Minimoi vaihtoehdot
Veron laskentakaava ei toisinaan toimi odotetulla tavalla.	Kultainen sääntö: Älä käytä sanaa "joskus".

Esimerkki virheraportista

Tässä pieni esimerkki virheraportista:

[OMA TILI] Alleviivaus näkyy, kun hiiren osoitin viedään Päivitä-painikkeen päälle.

Descriptioni: Meidän on poistettava alleviivaus vietäessä hiiren osoitin Oma tili -osion Päivitä-painikkeen päälle.

Linkki: http://test.com/mv-account/

Selain/käyttöjärjestelmä: Chrome 25. OSX Yosemite 10.10.2

Toistamisvaiheet:

1. Siirry osoitteeseen www.test.com

2. Kirjaudu sisään kirjautumistiedoilla

3. Siirry kohtaan Oma tili

4. Vie hiiri Päivitä-painikkeen päälle

Todellinen tulos: on alleviivaus.

Odotettu tulos: ei alleviivausta.

Sisäänkirjautumistiedot: test@test.com / mysecretpass12

Virheitä tulee välttää virheraporttien kirjoittamisessa

Tässä on joitain tärkeitä virheitä, joita sinun tulee välttää virheraporttia kirjoittaessasi:

• Älä kirjoita tyytymättömyydestäsi äläkä koskaan kerro henkilökohtaisia ​​tunteitasi.
• Se ärsyttää ihmisiä, jotka haluavat keskittyä tehtävään, kun ylikuormitat viestisi monilla hymiöillä.
• Älä koskaan ylikuormi viestiäsi huutomerkeillä; se ei nopeuta työtä.
• Kukaan ei halua olla loukkaantunut. Se tuhoaa motivaation ja hidastaa ongelman oivaltamista.