ကောင်းသော Bug Report ရေးနည်း (AI သို့မဟုတ် Developer အတွက်)
ကောင်းသော bug report သည် အခြားသူ — developer သို့မဟုတ် AI — က သင်မြင်ခဲ့သော ပြဿနာကိုပင် ဘာမှ ပြန်မေးစရာမလိုဘဲ မြင်နိုင်စေသည်။ တိကျသော ခေါင်းစီး၊ ပြန်ဖြစ်စေရန် အဆင့်အတိအကျများ၊ မျှော်လင့်ခဲ့သည့်အရာ၊ တကယ်ဖြစ်ခဲ့သည့်အရာ၊ စကားလုံးအတိုင်း ကူးထားသော error message နှင့် ဘယ်နေရာတွင် ဖြစ်ခဲ့သလဲ — ဘယ် page၊ browser၊ device နှင့် အသုံးပြုသူ — တို့ လိုအပ်သည်။ report တစ်ခုလျှင် bug တစ်ခု၊ အကူအညီဖြစ်လျှင် screenshot တစ်ခု ထည့်ပါ။
bug အများစုကို နားလည်ရန် ပြင်ရန်ထက် ပိုကြာသည်။ ရှင်းလင်းသော report သည် နားလည်ရမည့် အပိုင်းကို ဖယ်ရှားပေးသည်။ ဤအချက်သည် AI ကိရိယာများနှင့် ပို၍ အရေးကြီးသည်: AI သည် "checkout က ထူးဆန်းနေတယ်" ဟု သင်ဆိုလိုသည်ကို မေးခွန်းပြန်မေးနိုင်ခြင်း မရှိသဖြင့် ခန့်မှန်းရသည် — မှန်ကန်မှု မရှိသော ခန့်မှန်းချက်က အခြားအရာ တစ်ခုကို ပျက်စေနိုင်သည်။
Template
ဤအရာကို ကူးယူပြီး ဖြည့်ပါ:
ခေါင်းစီး: [ဘာမှားနေသလဲ၊ ဘယ်မှာ] — ဥပမာ "Booking form က ညနေ ၆ နာရီနောက်ပိုင်းအချိန်များကို ငြင်းပယ်သည်"
ပြန်ဖြစ်စေရန် အဆင့်များ:
1. ...
2. ...
3. ...
မျှော်လင့်ချက်: [ဘာဖြစ်သင့်သလဲ]
အမှန်တကယ်: [အစား ဘာဖြစ်ခဲ့သလဲ]
Error message: [စာသားအတိအကျ၊ ရှိလျှင်]
ဘယ်မှာ: [page/URL၊ browser၊ device၊ ဘယ်အသုံးပြုသူအဖြစ် login ဝင်ထားသလဲ]
မည်မျှ မကြာခဏ: [အမြဲ / တစ်ခါတစ်ရံ / တစ်ကြိမ်]
Screenshot သို့မဟုတ် recording: [ပူးတွဲထား]
ကျန်လမ်းညွှန်တွင် အပိုင်းတစ်ခုစီကို ရှင်းပြသည်။
အဆင့် ၁: ဦးစွာ ပြန်ဖြစ်အောင် လုပ်ပါ
ရေးမီ bug ကို ထပ်မံ ဖြစ်အောင် ကြိုးစားပါ။ မည်သည့် အဆင့်များ အရေးကြီးသလဲ၊ အမြဲ ဖြစ်သလား ဆိုသည်ကို သိရမည်။
- သန့်ရှင်းသော အခြေအနေမှ စပါ: refresh လုပ်ပါ သို့မဟုတ် logout ထွက်ပြီး ပြန်ဝင်ပါ။
- click တိုင်းနှင့် ရိုက်သည့်အရာတိုင်းကို မှတ်ပါ။
- ၎င်းကို ဖြစ်စေသော အတိုဆုံး လမ်းကြောင်းကို ရှာပါ။
- browser သို့မဟုတ် account ဒုတိယတစ်ခု စမ်းပါ။ အသုံးပြုသူတစ်ဦးတည်းအတွက်သာ ဖြစ်လျှင် ထိုသည်မှာ ကြီးမားသော အရိပ်အယောင် ဖြစ်သည်။
ဤအကြောင်း နောက်ထပ် သိရန် AI-built app ကို debug လုပ်နည်း ကို ကြည့်ပါ။
အဆင့် ၂: တိကျသော ခေါင်းစီး ရေးပါ
ခေါင်းစီးသည် ဘာမှားနေသလဲ၊ ဘယ်မှာလဲ ပြောရမည်၊ ထို့ကြောင့် စာရင်းကို ကြည့်သူသည် ဘယ် bug ဖြစ်သလဲ သိနိုင်သည်။
| အားနည်းသော | အားကောင်းသော |
|---|---|
| Checkout ပျက်နေသည် | Cart တွင် discount code ရှိသည့်အခါ Checkout ခလုတ် ဘာမှ မလုပ်ပါ |
| Mobile ပြဿနာ | 400px ထက်ငယ်သော ဖုန်းများတွင် pricing card များ မျက်နှာပြင်ထက် ကျော်နေသည် |
| Save တွင် error | Name တွင် emoji ပါသော profile ကို save လုပ်လျှင် "500 Internal Server Error" ပြသသည် |
အဆင့် ၃: တိကျသော အဆင့်များ စာရင်းပြုစုပါ
နံပါတ်တပ်ပါ။ စာသားအတိုင်း ရေးပါ: ဘယ် page၊ ဘယ်ခလုတ်၊ ဘာရိုက်ခဲ့သလဲ။
- customer အဖြစ် login ဝင်ပါ (test account: customer@example.com)။
- "Starter kit" ကို cart သို့ ထည့်ပါ။
- discount code
WELCOME10ကို ရိုက်ပြီး Apply ကို click လုပ်ပါ။ - Checkout ကို click လုပ်ပါ။
"code ဖြင့် checkout လုပ်ကြည့်ပါ" ဆိုသည်မှာ အသေးစိတ်များကို ချန်လှပ်ခြင်း ဖြစ်သည် — မည်သည့်အသုံးပြုသူ၊ မည်သည့်ထုတ်ကုန်၊ မည်သည့် code၊ အရင်ကပ်ထားခဲ့သလား — ဤအရာများက မကြာခဏ အရေးကြီးသည်။
အဆင့် ၄: မျှော်လင့်ထားသည် နှင့် အမှန်တကယ်
ဤသည်မှာ report ၏ အဓိက အပိုင်း ဖြစ်သည်။ နှစ်ခုလုံး ပြောပါ၊ ကွာခြားချက်သည် bug ဖြစ်သောကြောင့်။
- မျှော်လင့်ချက်: Checkout စာမျက်နှာ ပွင့်ပြီး စုစုပေါင်းတွင် 10% လျှော့စျေး ပြသသည်။
- အမှန်တကယ်: ခလုတ်က ခဏ spinner ပြပြီး ဘာမှ မဖြစ်ပါ။ code မပါဘဲ checkout အလုပ်လုပ်သည်။
"မျှော်လင့်ချက်" မရှိလျှင် ဖတ်သူက အပြုအမူ မှားနေကြောင်း မသိနိုင်ပါ။ "အမှန်တကယ်" မရှိလျှင် ဘာကို ကြည့်ရမည် မသိပါ။
အဆင့် ၅: error များကို အတိအကျ ကူးပါ
Error message များသည် အကြောင်းရင်းသို့ အမြန်ဆုံး လမ်းကြောင်း ဖြစ်သည်။ စာသားအဖြစ် စကားလုံးအတိုင်း ကူးပါ — အနက်ပြန်မပြောင်းပါနှင့်။
ရှာရမည့်နေရာများ:
- မျက်နှာပြင်ပေါ်: app ပြသသော message မှန်သမျှ။
- Browser console: developer tools (F12၊ သို့မဟုတ် right-click → Inspect) ဖွင့်ပြီး အနီရောင် စာကြောင်းများအတွက် Console tab ကို ကြည့်ပါ။
- Network tab: developer tools တွင် ပျက်ကွက်သော request ကို ရှာပြီး ၎င်း၏ URL နှင့် status code ကို မှတ်ပါ (ဥပမာ
POST /api/checkout → 500)။ - Server log များ၊ သင်ဝင်ရောက်နိုင်လျှင်။
TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 ကဲ့သို့ စာကြောင်းက ပြဿနာကို တိုက်ရိုက် ညွှန်ပြလေ့ရှိသည်။
အဆင့် ၆: ပတ်ဝန်းကျင် အချက်အလက် ထည့်ပါ
- ဘယ်မှာ: page URL၊ ပတ်ဝန်းကျင် (preview၊ staging သို့မဟုတ် live)။
- ဘယ်သူ: မည်သည့် အသုံးပြုသူ သို့မဟုတ် role — admin၊ member၊ logout ထွက်ထားသူ။
- Device နှင့် browser: "iPhone ပေါ် Safari" နှင့် "Windows ပေါ် Chrome" က အရေးကြီးနိုင်သည်။
- Data: record အကြောင်း ပုံမှန်မဟုတ်သော အရာ — စာသား အလွန်ရှည်ခြင်း၊ အထူး စာလုံးများ၊ item အရေအတွက် များခြင်း။
- စတင်ခဲ့သည့်အချိန်: "မနေ့က discount code ပြောင်းပြီးနောက်" ဆိုသည်မှာ ရွှေတွင်းဖြစ်သည်။
- မည်မျှ မကြာခဏ: အမြဲ၊ သို့မဟုတ် ကြိုးစား ၁၀ ကြိမ်တွင် တစ်ကြိမ်။
အဆင့် ၇: ပြပါ
ပြဿနာကို စက်ဝိုင်းဖြင့် ပတ်ထားသော screenshot သို့မဟုတ် တိုတို screen recording က ရှင်းလင်းမှုမရှိမှုကို ဖယ်ရှားပေးသည် — အထူးသဖြင့် layout bug များအတွက်။ သင့် AI ကိရိယာက ပုံများ လက်ခံလျှင် တစ်ခု ပူးတွဲပါ။ key များနှင့် အခြားသူ data အပါအဝင် ကိုယ်ရေးကိုယ်တာ အရာမှန်သမျှကို ဖြတ်ထုတ်ပါ။
AI builder အတွက် bug report ရေးခြင်း
ဖွဲ့စည်းပုံတူတူက prompt အဖြစ် အလုပ်လုပ်သည်။ နှစ်ခု ထပ်ထည့်ခြင်းက အကူအညီဖြစ်သည်:
- ဘာမပြောင်းရမလဲ ပြောပါ၊ ပြင်ဆင်မှုက အခြား ပြဿနာအသစ် မဖန်တီးစေရန်။
- ပြင်ဆင်မှုကို စစ်ဆေးရန် တောင်းဆိုပါ၊ ရေးရုံသာမဟုတ်ဘဲ။
ဖောက်သည်အဖြစ် login ဝင်ပြီး "Starter kit" ကို cart တွင် ထားကာ
WELCOME10code ကို အသုံးချထားသည်၊ Checkout ကို click လုပ်သော်လည်း ဘာမှ မဖြစ်ပါ။ မျှော်လင့်ချက်: checkout စာမျက်နှာ ပွင့်ပြီး စုစုပေါင်းမှ 10% လျှော့ထားသည်။ အမှန်တကယ်: ခဏ spinner ပြပြီး ဘာမှ မဖြစ်ပါ။ network tab တွင်POST /api/checkoutက 500 ပြန်ပေးသည်။ code မပါဘဲ checkout အလုပ်လုပ်သည်။ အကြောင်းရင်းကို ရှာပြီး code မပါသော order များအတွက် စျေးနှုန်းတွက်ချက်ပုံကို မပြောင်းဘဲ ပြင်ပါ။ ထို့နောက် ရာခိုင်နှုန်း code၊ ပမာဏသတ်မှတ် code နှင့် code မပါဘဲ checkout ကို စစ်ဆေးပါ။
အကြောင်းရင်း မသေချာလျှင် ရောဂါရှာဖွေမှုကို အရင်တောင်းပါ:
code ကို ယခုမပြောင်းပါနှင့်။ ဤ report အပေါ် မူတည်ပြီး ဖြစ်နိုင်သော အကြောင်းရင်းများ ဘာတွေလဲ၊ တစ်ခုစီကို ဘယ်လို အတည်ပြုမလဲ?
အဖြစ်များသော အမှားများ
- "ပျက်နေတယ်။" အဆင့် မရှိ၊ မျှော်လင့်ချက် မရှိ၊ လုပ်ဆောင်ရန် တစ်ခုမျှ မရှိ။
- bug အများအပြား report တစ်ခုတည်းတွင်။ အချို့ပြင်ပေးကြ၊ အချို့ ပျောက်ဆုံးကြ။
- စကားလုံး ပြန်ပြောင်းထားသော error များ။ "တစ်ခုခု undefined" က အသုံးဝင်သော အပိုင်းကို ဖုံးကွယ်သည်။
- အသုံးပြုသူ သို့မဟုတ် role ကို ချန်လှပ်ခြင်း။ bug အများအပြားက admin များ သို့မဟုတ် အသုံးပြုသူသစ်များကိုသာ သက်ရောက်သည်။
- ပြဿနာကို မဖော်ပြဘဲ လိုချင်သော ပြင်ဆင်ချက်ကိုသာ ဖော်ပြခြင်း ("null check ထည့်ပါ")။
- screenshot သို့မဟုတ် ကူးထည့်ထားသော log များတွင် လျှို့ဝှက်အချက်များ မျှဝေခြင်း။
စစ်ဆေးစာရင်း
- bug ကို ပြန်ဖြစ်အောင် လုပ်ပြီး အတိုဆုံး အဆင့်များ ရှာတွေ့ထားသည်။
- ခေါင်းစီးက ဘာမှားနေသလဲ ဘယ်မှာလဲ ပြောသည်။
- အဆင့်များ နံပါတ်တပ်ထားပြီး စာသားအတိုင်း ဖြစ်သည်။
- မျှော်လင့်ချက်နှင့် အမှန်တကယ် နှစ်ခုလုံး ဖော်ပြထားသည်။
- error message များကို အတိအကျ ကူးထားပြီး ပျက်ကွက်သော request နှင့် status code ပါသည်။
- page၊ ပတ်ဝန်းကျင်၊ အသုံးပြုသူ၊ device နှင့် browser ပါဝင်သည်။
- မည်မျှ မကြာခဏ ဖြစ်သည်နှင့် ဘယ်အချိန်မှ စတင်သည်ကို ပြောထားသည်။
- screenshot သို့မဟုတ် recording ပူးတွဲထားပြီး ကိုယ်ရေးကိုယ်တာ data ဖယ်ထားသည်။
- report တစ်ခုလျှင် bug တစ်ခု။
Mythex agent သို့ bug များ တင်ခြင်း
Mythex project တွင် report သည် prompt ပင် ဖြစ်သည်။ အင်္ဂါရပ်အချို့က အကူအညီဖြစ်သည်:
- preview သို့မဟုတ် error မျက်နှာပြင်၏ screenshot ပူးတွဲပါ — message တစ်ခုလျှင် ဖိုင် ၅ ခုအထိ။
/fixက agent ကို bug ပြင်ရန် အာရုံစိုက်စေသည်; Plan mode က တည်းဖြတ်မီ စုံစမ်းခွင့် ပေးသည်။/testက agent ကို preview ထဲတွင် flow များကို ပြန်ဖြစ်စေပြီး မြင်ရသည်ကို အစီရင်ခံစေသည်။- Revert to this point က အခြေအနေကို ပိုဆိုးစေသော ပြင်ဆင်ချက်ကို ပြန်ဖျက်သည်။
docs ၏ prompt ဖြင့် debugging စာမျက်နှာသည် အဆင့်များ / မျှော်လင့်ချက် / အမှန်တကယ် ဖွဲ့စည်းပုံကို သုံးသည်။ ၎င်းပတ်လည်ရှိ ပြင်ဆင်-စစ်ဆေး loop အတွက် AI-built app ကို ထပ်ခါထပ်ခါ ပြင်ဆင်နည်း ကို ကြည့်ပါ။
မေးခွန်းများ
bug report တွင် ဘာတွေ ပါသင့်သလဲ?
တိကျသော ခေါင်းစီး၊ ပြဿနာကို ပြန်ဖြစ်စေရန် အဆင့်အတိအကျများ၊ မျှော်လင့်ခဲ့သည့်အရာ၊ တကယ်ဖြစ်ခဲ့သည့်အရာ၊ error message ကို စကားလုံးအတိုင်း၊ ဘယ်နေရာတွင် ဖြစ်ခဲ့သလဲ (စာမျက်နှာ၊ browser၊ device၊ အသုံးပြုသူ) နှင့် အကူအညီဖြစ်လျှင် screenshot သို့မဟုတ် recording။
AI app builder အတွက် bug report ကို ဘယ်လို ရေးမလဲ?
developer အတွက် ရေးသလို ဖွဲ့စည်းပုံတူတူ သုံးပါ: အဆင့်များ၊ မျှော်လင့်ချက်၊ အမှန်တကယ် ရလဒ်နှင့် တိကျသော error။ မပြောင်းရန် အရာများကို ထည့်ပြီး ပြင်ပြီးနောက် စစ်ဆေးရန် တောင်းဆိုပါ။ "ပျက်နေတယ်" ကဲ့သို့ မရှင်းလင်းသော prompt များက ခန့်မှန်းချက်များသို့ ဦးတည်စေသည်။
bug ကို ပြန်ဖြစ်အောင် မလုပ်နိုင်ရင် ဘာလုပ်သင့်သလဲ?
ဘာပဲဖြစ်ဖြစ် တင်ပါ၊ သို့သော် ထိုသို့ မကြာခဏ မဖြစ်ကြောင်း ပြောပါ။ ဘာလုပ်နေခဲ့သလဲ၊ ဘယ်အချိန် ဖြစ်ခဲ့သလဲ၊ အသုံးပြုသူ အကောင့်နှင့် မြင်ခဲ့သော error ကို ထည့်ပါ။ ကြိမ်ဖန်မြောက်မှု ပုံစံ (ကြိုးစား ၁၀ ကြိမ်တွင် တစ်ကြိမ် ကဲ့သို့) ကို မှတ်ပါ၊ အကြောင်းမှာ ပေါ်လိုက်ပျောက်လိုက် bug များက အချိန် သို့မဟုတ် data ပြဿနာကို ညွှန်ပြလေ့ရှိသည်။
bug အများအပြားကို report တစ်ခုတည်းတွင် ထည့်သင့်သလား?
မထည့်ပါနှင့်။ report တစ်ခုလျှင် bug တစ်ခုသာ၊ ထို့ကြောင့် တစ်ခုစီကို သီးခြား ပြင်၊ စမ်း၊ ပိတ်နိုင်သည်။ ပြဿနာ နှစ်ခု ဆက်စပ်ကြောင်း ထင်လျှင် report တိုင်းတွင် ထိုသို့ ပြောပါ။