Hyvien virheraporttien kirjoittaminen: suosituksia

Kuvittele, että olet kehittäjä, ja testaaja tuo sinulle bugin, joka löydettiin regression aikana. Haluat korjata tämän virheen, joten pyydät lipun luomista. Kuvittelet jo, kuinka noutat sen, linkität siihen vetopyynnöt ja lisäät arvioita, jotta tuotepäälliköllä ei ole kysymyksiä.

Aikaa kuluu ja uusi lippu ilmestyy, mutta sisällä on vain pari riviä ja kuvakaappaus. Huokaten yrität toistaa vian näiden tietojen avulla, mutta virhettä ei tapahdu. Yrität useita kertoja, mutta lopulta kirjoitat testaajalle, että vikaa ei voida toistaa, ja uusi selvityskierros alkaa.

Käytät aikaa, jonka olisi voitu käyttää uusien tehtävien parissa, muiden virheiden korjaamiseen tai jopa anime -koodin muokkaamiseen.

Nimeni on Evgeny Domnin ; Olen laadunvalvoja ja yritän jakaa näkemykseni siitä, mikä on hyvä virheraportti. Anteeksi pitkä esittely – aloitetaan.

Otsikko

Yritä vastata kolmeen kysymykseen lipun otsikossa:

1. Missä se tapahtuu?
2. Mitä tapahtuu?
3. Missä olosuhteissa?

Kokeneen kehittäjän tarvitsee vain vilkaista otsikkoa ymmärtääkseen ongelman. Esimerkiksi:

Kirjautumissivu: Kenttä ei ole korostettu, kun kirjoitat väärän salasanan

Ympäristö

Olen usein nähnyt testaajien unohtaneen lipussa ilmoittaa, missä ympäristössä ongelma esiintyi. Tämä on erityisen tärkeää käyttöliittymään liittyvissä lipuissa, joissa verkkosivuston osoite tai verkkopyyntö ei näy. Määritä tämä aina. Jos lipussa on erillinen kenttä, hienoa, laita se sinne. Jos ei, mainitse se kopiointivaiheissa, esimerkiksi:

Kirjaudu esitysympäristöön järjestelmänvalvojan tilillä.

Vaiheista puheen ollen...

Lisääntymisvaiheet

Yksi tärkeimmistä osista on virheiden toisto-ohjeet. Korostan kahta osaa, joihin keskittyä: vaiheiden muotoilu (visuaalinen) ja sisältö (sisällä olevat tiedot).

Visuaalinen osa

Säilytä rakenne

Virheraporteista on erilaisia muunnelmia, mutta perinteisesti niiden tulisi sisältää seuraavat osiot:

1. Vaiheet
2. Odotettu tulos
3. Todellinen tulos

Käytä tätä rakennetta ja pysy siinä aina. Tämä on yksi niistä tapauksista, joissa yhtenäisyys auttaa järjestämään ajatuksiasi kuvattaessa asiaa.

Käytä numeroitua luetteloa

Erittele vaiheet numeroidun luettelon avulla. Joskus testaajat kirjoittavat yksityiskohtaisia kuvauksia, mutta jatkuvana tekstilohkona. Älä tee tätä. Kaikkien on paljon helpompi lukea, jos vaiheet erotetaan toisistaan.

Aina kun mahdollista, kirjoita ilman kielioppivirheitä.

Siirrytään nyt näiden vaiheiden sisältöön.

Maalaisjärki kuvauksissa

Sinun ei tarvitse jakaa jokaista yksittäistä toimintaa erilliseen vaiheeseen, jos se ei ole ratkaisevan tärkeää virheen toistamisen kannalta – tätä on vaikea lukea ja käyttää käytännössä. Älä pelkää sisällyttää useita toimintoja samaan vaiheeseen. Mitä tarkoitan?

Huono :

1. Siirry osoitteeseen test.com/login

2. Napsauta kirjautumiskenttää
3. Anna kirjautumistunnus
4. Napsauta salasanakenttää
5. Anna salasana

   
   

Hyvä :

1. Siirry osoitteeseen test.com/login ja kirjaudu sisään millä tahansa tilillä

Emme jaa vaiheita asioihin, joita kehittäjä luonnollisesti tekee noudattaessaan normaalia kulkua. Aloittaessani ajattelin, että jokainen teko vaati oman askeleen, mutta se ei ole välttämätöntä.

Vältä epäselvyyttä

Täydennä aina vaiheita erityisellä tarkistuspyynnöllä kussakin vaiheessa ja kirjoita tietty painike, jota painetaan (varsinkin jos painikkeita on samannimisiä).

Sisällytä testitiedot

Anna kirjautumistiedot, jos virhe liittyy tiliisi, ja älä epäröi sisällyttää mukaan testihyötykuormia, jotka auttavat toistamaan virheen.

Tarkista vaiheesi uudelleen

Joskus kirjoitat vaiheet heti vian havaitsemisen jälkeen, mutta saattaa käydä niin, että olet unohtanut yhden vaiheen saadaksesi täydellisen ymmärryksen tai virhettä ei voida toistaa myöhemmin. Siinä tapauksessa voi olla tarpeen löytää tarkempia vaiheita.

Odotettu tulos

Erillinen osio on odotettu tulos, jossa kuvataan (ei yllättäen) tulos, joka on odotettavissa, kun vaiheita seurataan. Tässä ei ole monia erityissuosituksia, paitsi että tämän osion on oltava olemassa – kehittäjän on ymmärrettävä, mihin toimintaan toiminnon tulisi johtaa. Ilmaukset, kuten "kaiken pitäisi toimia hyvin", eivät leikkaa sitä – kirjoita tietty käyttäytyminen.

Todellinen tulos

Tässä kirjoitamme, mitä todella tapahtui, kun noudatimme vaiheita. Spesifisyys on tärkeää myös tässä. Älä kirjoita vain "kaikki meni rikki" (vaikka niin luultavasti tapahtui). Kuvaile indikaattorit, jotka osoittavat, että kaikki meni rikki. Esimerkiksi:

GET /accounts pyynnössä palautetaan 500-virhe , ja käyttöliittymä estetään. Käyttäjä ei voi poistua sivulta tai napsauttaa elementtejä.

Sivun päivittäminen käynnistää pyynnön uudelleen ja johtaa samaan virheeseen.

Toisin sanoen kuvaile todellista vaikutusta ja kuinka se vaikuttaa käyttäjän virtaukseen.

Lisätiedostot

Tämä on erillinen mainitsemisen arvoinen jakso. Liitä siihen lisätietoja, jotka kuvaavat virhettä. Tiedän joitain kehittäjiä, jotka eivät pidä kopiointivaiheiden lukemisesta ja menevät suoraan todelliseen tulokseen ja sen selittäviin lisämateriaaleihin.

Kuvakaappauksia virheestä

On parempi nähdä se kerran kuin kuulla siitä sata kertaa. Tämä on loistava tapa näyttää visuaalisesti, mitä tapahtuu ja missä. Yritä aina liittää kuvakaappaus.

Pyytää

Jos on pyyntö, jossa virhe tapahtui, se tulee aina sisällyttää lippuun. Pyynnöt sisältävät kuitenkin monia erilaisia parametreja. Korostan seuraavia tärkeitä sisällytettäväksi:

• Error URL – itse pyyntö, jonka saat selaimen Verkko-osiosta, jossa testaus suoritetaan.

• Menetelmä – GET , POST , TRACE , OPTION jne. On olemassa monia menetelmiä, aivan kuten on olemassa pyyntöjä, joilla on sama URL-osoite, mutta eri menetelmät. Muista mainita se lipussa.

• Virhekoodi – toinen tärkeä kohta. Et todennäköisesti unohda sitä, mutta älä unohda merkitä muistiin, mikä koodi palautettiin palvelimelta.

• Hyötykuorma – nämä tiedot lähetimme pyynnössämme palvelimelle. Tämä ei ole jokaisessa pyynnössä (esim. HEAD tai GET ei ole sitä), mutta se voi olla syy virheeseen.

• Response – palvelimen vastaus. Joskus se sisältää koko virheen ja näyttää jopa, missä se tapahtui, kun taas toisinaan se on vain oletuspaikkamerkki, joka on asetettu taustajärjestelmään tämän tyyppistä virhettä varten. Muista sisällyttää tämä - se säästää kehittäjän paljon aikaa.

Konsolin lokit

Joskus konsolista löytyy virheitä, jotka voidaan lisätä lippuun. Ehkä olet jo tehnyt tämän, mutta huomautan vain, että suuri tekstilohko voidaan aina tallentaa .log tiedostona ja lisätä lippuun. Tämä parantaa sekä lokien että itse lipun luettavuutta.

Tämä on kaikki hyvin, mutta...

Tämä on kaikki hyvin, mutta mistä löydämme aikaa saada kaikki näyttämään näin hyvältä? Määräajat uhkaavat, johtaja suuttuu, tuotannossa on esto, ja minua pyydetään istumaan ja kirjoittamaan kaikki? Laitan vain viestin suoraan kehittäjälle, ja siinä se.

Tämä on looginen argumentti, joka voi tulla esiin. Minulla ei ole illuusioita täydellisestä testaajan maailmasta, jossa testaamiseen on varattu runsaasti aikaa, kaikki sujuu prosessin mukaan ja huolellinen ja laadukas dokumentaatio ylläpidetään. Ymmärrän – usein se on ajan murskausta, palamista... no, silmät ja kilpailu saada kaikki tehtyä ajoissa.

Pienet virheet kasaantuvat, vievät enemmän aikaa kontekstin vaihtamisen vuoksi ja johtavat huonoihin käytäntöihin. Jos alamme vähitellen toteuttaa parannuksia ja seurata niiden toimintaa, voimme luoda prosessin, joka on vakaampi, standardoidumpi ja ennustettavampi kaikille osallistujille.

Projektipäällikkö ymmärtää, mitä tuotteelle tapahtuu ilman, että hänen tarvitsee hakea kaikilta päivityksiä, kehittäjän ei tarvitse pyytää testaajalta selvennyksiä lisääntymisolosuhteisiin eikä vetää heitä pois testauksesta, ja sidosryhmät puolestaan sinulla on selkeä näkemys tuotteen edistymisestä.

Tämä artikkeli on suunnattu enemmän aloittelijoille, jotka ovat aloittamassa tai ovat jo aloittaneet polun testaamisessa. Uskon, että pienet askeleet johtavat suuriin tuloksiin, ja tämän artikkelin suositukset johtavat laadukkaampiin vikailmoituksiin.

Jos sinulla on kysyttävää, ehdotuksia, erimielisyyksiä tai valituksia, jätä ne kommentteihin - olen kiinnostunut kuulemaan mielipiteesi!