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   -koodin muokkaamiseen. anime  Nimeni on   ; Olen   ja yritän jakaa näkemykseni siitä, mikä on hyvä virheraportti. Anteeksi pitkä esittely – aloitetaan. Evgeny Domnin laadunvalvoja   Otsikko  Yritä vastata kolmeen kysymykseen lipun otsikossa:   Missä se tapahtuu?   Mitä tapahtuu?   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:  Vaiheet  Odotettu tulos  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  Siirry osoitteeseen  test.com/login  Napsauta kirjautumiskenttää  Anna kirjautumistunnus  Napsauta salasanakenttää  Anna salasana    : Hyvä  Siirry osoitteeseen   ja kirjaudu sisään millä tahansa tilillä test.com/login  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:    – itse pyyntö, jonka saat selaimen Verkko-osiosta, jossa testaus suoritetaan. Error URL    –   ,   ,   ,   jne. On olemassa monia menetelmiä, aivan kuten on olemassa pyyntöjä, joilla on sama URL-osoite, mutta eri menetelmät. Muista mainita se lipussa. Menetelmä GET POST TRACE OPTION    – toinen tärkeä kohta. Et todennäköisesti unohda sitä, mutta älä unohda merkitä muistiin, mikä koodi palautettiin palvelimelta. Virhekoodi    – 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. Hyötykuorma    – 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. Response  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   tiedostona ja lisätä lippuun. Tämä parantaa sekä lokien että itse lipun luettavuutta. .log   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!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Hyvien virheraporttien kirjoittaminen: suosituksia

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

10x Research: How a FIL Backed USD Stablecoin By Secured Finance Would Boost The Filecoin Ecosystem

PENANCE

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

Spaghetti

10x Research: How a FIL Backed USD Stablecoin By Secured Finance Would Boost The Filecoin Ecosystem

PENANCE

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

Spaghetti

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps