Paano Sumulat ng Magandang Ulat sa Bug: Mga Rekomendasyon

Isipin na ikaw ay isang developer, at ang isang tester ay nagdadala sa iyo ng isang bug na natagpuan sa panahon ng pagbabalik. Gusto mong ayusin ang bug na ito, kaya humingi ka ng ticket na magawa. Iniisip mo na kung paano mo ito kukunin, i-link ang mga kahilingan sa paghila dito, at magdagdag ng mga pagtatantya para walang anumang tanong ang tagapamahala ng produkto.

Lumipas ang ilang oras, at lumilitaw ang isang bagong tiket, ngunit sa loob, mayroon lamang isang pares ng mga linya at isang screenshot. Sa isang buntong-hininga, sinubukan mong kopyahin ang bug gamit ang impormasyong ito, ngunit walang error. Sinubukan mo nang maraming beses, ngunit sa huli, sumulat ka sa tester na hindi maaaring kopyahin ang bug, at magsisimula ang isang bagong yugto ng paglilinaw.

Gumugugol ka ng oras na maaaring ginamit sa paggawa sa mga bagong gawain, pag-aayos ng iba pang mga bug, o kahit panoorin ang anime refactor ang code.

Ang pangalan ko ay Evgeny Domnin ; Isa akong QA , at susubukan kong ibahagi ang aking pananaw sa kung ano ang gumagawa ng magandang ulat ng bug. Paumanhin sa mahabang pagpapakilala—magsimula na tayo.

Pamagat

Subukang sagutin ang tatlong tanong sa pamagat ng tiket:

1. Saan ito nangyayari?
2. Ano ang mangyayari?
3. Sa ilalim ng anong mga pangyayari?

Kakailanganin lamang ng isang makaranasang developer na sumulyap sa pamagat para maunawaan ang isyu. Halimbawa:

Pahina sa Pag-login: Hindi naka-highlight ang field kapag nagpasok ng maling password

Kapaligiran

Madalas kong nakikita ang mga tester na nakalimutang tukuyin sa ticket kung saang kapaligiran naganap ang isyu. Ito ay partikular na nauugnay sa mga ticket na nauugnay sa UI, kung saan ang address ng website o kahilingan sa network ay hindi nakikita. Palaging tukuyin ito. Kung mayroong isang hiwalay na field sa tiket, mahusay, ilagay ito doon. Kung hindi, banggitin ito sa mga hakbang sa pagpaparami, halimbawa:

Mag-log in sa kapaligiran ng pagtatanghal ng dula gamit ang isang admin account.

Nagsasalita ng mga hakbang...

Mga Hakbang sa Pagpaparami

Ang isa sa pinakamahalagang seksyon ay ang mga tagubilin sa pagpaparami ng bug. Iha-highlight ko ang dalawang bahaging pagtutuunan ng pansin: ang pag-format ng mga hakbang (visual) at ang nilalaman (data sa loob).

Visual na Bahagi

Panatilihin ang istraktura

Mayroong iba't ibang mga pagkakaiba-iba ng mga ulat ng bug, ngunit sa klasikal na paraan, dapat silang maglaman ng mga sumusunod na seksyon:

1. Mga hakbang
2. Inaasahang resulta
3. Aktwal na resulta

Gamitin ang istrakturang ito, at manatili dito palagi. Ito ay isa sa mga kaso kung saan ang pagkakapareho ay makakatulong na ayusin ang iyong mga iniisip kapag inilalarawan ang isyu.

Gumamit ng isang numerong listahan

Hatiin ang mga hakbang gamit ang isang numerong listahan. Minsan, sumusulat ang mga tester ng mga detalyadong paglalarawan, ngunit bilang tuluy-tuloy na bloke ng text. Huwag gawin ito. Magiging mas madali para sa lahat na magbasa kung ang mga hakbang ay pinaghihiwalay.

Hangga't maaari, sumulat nang walang mga pagkakamali sa gramatika.

Ngayon, lumipat tayo sa nilalaman ng mga hakbang na ito.

Common Sense sa Mga Paglalarawan

Hindi mo kailangang hatiin ang bawat pagkilos sa isang hiwalay na hakbang kung hindi ito mahalaga para sa pagpaparami ng bug—mahirap itong basahin at gamitin sa pagsasanay. Huwag matakot na magsama ng maraming pagkilos sa isang hakbang. Ano ang ibig kong sabihin?

Masama :

1. Pumunta sa test.com/login

2. Mag-click sa field sa pag-login

3. Ipasok ang login

4. Mag-click sa field ng password

5. Ipasok ang password

   
   

Mabuti :

1. Pumunta sa test.com/login at mag-log in gamit ang anumang account

Hindi namin pinaghiwa-hiwalay ang mga hakbang sa mga bagay na natural na gagawin ng developer habang sumusunod sa karaniwang daloy. Noong nagsisimula ako, iniisip ko noon na ang bawat aksyon ay nangangailangan ng sarili nitong hakbang, ngunit hindi ito kinakailangan.

Iwasan ang kalabuan

Palaging dagdagan ang mga hakbang ng partikular na kahilingang suriin sa bawat hakbang, at isulat ang partikular na button na pipindutin (lalo na kung may mga button na may parehong pangalan).

Isama ang data ng pagsubok

Magbigay ng data sa pag-log in kung ang error ay nauugnay sa iyong account, at huwag mag-atubiling isama ang mga pansubok na payload na makakatulong sa pagpaparami ng bug.

Suriin muli ang iyong mga hakbang

Minsan, isusulat mo kaagad ang mga hakbang pagkatapos na makaharap ang bug, ngunit maaaring lumabas na napalampas mo ang isang hakbang para sa ganap na pag-unawa o ang bug ay hindi maaaring kopyahin sa ibang pagkakataon. Sa kasong iyon, maaaring kailanganin ang mas tumpak na mga hakbang.

Inaasahang Resulta

Ang isang hiwalay na seksyon ay ang inaasahang resulta, kung saan inilalarawan namin (hindi nakakagulat) ang resulta na inaasahan kapag sinunod ang mga hakbang. Walang maraming espesyal na rekomendasyon dito maliban sa dapat na umiiral ang seksyong ito—kailangan ng developer na maunawaan kung anong gawi ang dapat humantong sa functionality. Ang mga pariralang tulad ng "dapat gumana nang maayos ang lahat" ay hindi pinuputol ito-isulat ang partikular na pag-uugali.

Aktwal na Resulta

Dito, isinusulat namin kung ano talaga ang nangyari noong sinunod namin ang mga hakbang. Mahalaga rin dito ang pagtitiyak. Huwag basta-basta isulat ang “everything broke” (kahit marahil iyon ang nangyari). Ilarawan ang mga tagapagpahiwatig na nagpapakita na ang lahat ay nasira. Halimbawa:

Ang isang 500 error ay ibinalik sa kahilingan ng GET /accounts , at ang UI ay na-block. Ang gumagamit ay hindi maaaring lumabas sa pahina o mag-click sa mga elemento.

Ang pag-refresh ng page ay magti-trigger muli sa kahilingan at humahantong sa parehong error.

Sa madaling salita, ilarawan ang aktwal na epekto at kung paano ito nakakaapekto sa daloy ng user.

Mga Karagdagang File

Ito ay isang hiwalay na seksyon na nagkakahalaga ng pagbanggit. Dito ka maglalagay ng karagdagang impormasyon na naglalarawan sa bug. May kilala akong ilang developer na hindi tagahanga ng pagbabasa ng mga hakbang sa pagpaparami at dumiretso sa aktwal na resulta at mga karagdagang materyales na nagpapaliwanag nito.

Mga screenshot ng Error

Mas mabuting makita ito ng isang beses kaysa marinig ito ng isang daang beses. Ito ay isang mahusay na paraan upang biswal na ipakita kung ano ang nangyayari at kung saan. Palaging subukang mag-attach ng screenshot.

Kahilingan

Kung may kahilingan kung saan nangyari ang error, dapat itong palaging kasama sa ticket. Gayunpaman, ang mga kahilingan ay naglalaman ng maraming iba't ibang mga parameter. Itinatampok ko ang sumusunod bilang mahalagang isama:

• Error URL – ang mismong kahilingan, na makukuha mo mula sa seksyong Network sa browser kung saan ginagawa ang pagsubok.

• Paraan – GET , POST , TRACE , OPTION , atbp. Maraming pamamaraan, tulad ng may mga kahilingan na may parehong URL ngunit magkaibang pamamaraan. Huwag kalimutang tukuyin ito sa tiket.

• Error code – isa pang mahalagang punto. Malamang na hindi mo ito malilimutan, ngunit huwag kalimutang tandaan kung anong code ang ibinalik mula sa server.

• Payload – ito ang data na ipinadala namin sa aming kahilingan sa server. Wala ito sa bawat kahilingan (hal., HEAD o GET ay wala nito), ngunit maaaring ito ang sanhi ng error.

• Tugon – tugon ng server. Minsan, naglalaman ito ng buong error, kahit na ipinapakita kung saan ito nangyari, habang sa ibang pagkakataon, isa lang itong default na placeholder na naka-set up sa backend para sa ganoong uri ng error. Tiyaking isama ito—makakatipid ito ng maraming oras sa developer.

Mga Log ng Console

Minsan, may mga error na makikita sa console, at maaaring idagdag ang mga ito sa ticket. Marahil ay ginagawa mo na ito, ngunit mapapansin ko lang na ang isang malaking bloke ng teksto ay maaaring palaging i-save bilang isang .log file at idagdag sa tiket. Pinapabuti nito ang pagiging madaling mabasa ng parehong mga log at ang tiket mismo.

Ito ay Mabuti at Mabuti, Ngunit...

Mabuti at mabuti ang lahat, ngunit saan tayo makakahanap ng oras para gawing ganito kaganda ang lahat? Malapit na ang mga deadline, nagagalit ang manager, may blocker sa production, at pinapaupo ako at isulat ang lahat? Direkta ko lang imensahe ang developer, at iyon na.

Ito ay isang lohikal na argumento na maaaring lumabas. Hindi ako nagtatago ng anumang mga ilusyon tungkol sa perpektong mundo ng isang tester, kung saan inilalaan ang sapat na oras para sa pagsubok, lahat ay dumadaan sa proseso, at pinapanatili ang masinsinan at mataas na kalidad na dokumentasyon. Naiintindihan ko—kadalasan, ito ay isang oras na langutngot, nasusunog... mabuti, mga mata, at isang karera upang magawa ang lahat sa oras.

Ang maliliit na error ay madalas na natambak, tumatagal ng mas maraming oras dahil sa paglipat ng konteksto, at humahantong sa hindi magandang kasanayan. Kung unti-unti nating sisimulan ang pagpapatupad ng mga pagpapahusay at pagsubaybay kung paano gumagana ang mga ito, makakagawa tayo ng prosesong mas matatag, na-standardize, at mahuhulaan para sa lahat ng kalahok.

Mauunawaan ng manager ng proyekto kung ano ang nangyayari sa produkto nang hindi kinakailangang hilahin ang lahat para sa mga update, hindi na kailangang humingi ng linaw sa tester ang developer sa mga kundisyon ng reproduction at hindi niya ito aalisin sa pagsubok, at ang mga stakeholder ay, sa turn, magkaroon ng isang malinaw na pagtingin sa pag-unlad ng produkto.

Ang artikulong ito ay mas nakatuon sa mga nagsisimula na nagsisimula o nagsimula na sa kanilang landas sa pagsubok. Naniniwala ako na ang maliliit na hakbang ay humahantong sa malalaking resulta, at ang mga rekomendasyon sa artikulong ito ay hahantong sa mas mataas na kalidad na mga ulat sa bug.

Kung mayroon kang anumang mga tanong, mungkahi, hindi pagkakasundo, o reklamo, huwag mag-atubiling iwanan ang mga ito sa mga komento—interesado akong marinig ang iyong opinyon!