നല്ല bug റിപ്പോർട്ട് എങ്ങനെ എഴുതാം (AI-ക്കോ ഡെവലപ്പർക്കോ)

നല്ല bug റിപ്പോർട്ട് മറ്റൊരാൾക്ക് — ഒരു ഡെവലപ്പർക്കോ AI-ക്കോ — നിങ്ങൾ കണ്ട അതേ പ്രശ്നം, നിങ്ങളോട് ഒന്നും ചോദിക്കാതെ കാണാൻ അനുവദിക്കുന്നു. അതിന് വ്യക്തമായ ഒരു തലക്കെട്ട്, പുനഃസൃഷ്ടിക്കാനുള്ള കൃത്യമായ ഘട്ടങ്ങൾ, പ്രതീക്ഷിച്ചത്, യഥാർത്ഥത്തിൽ സംഭവിച്ചത്, വാക്കുകളിൽ തന്നെ പകർത്തിയ ഏതെങ്കിലും പിശക് സന്ദേശം, എവിടെയാണ് സംഭവിച്ചത് — ഏത് പേജ്, ബ്രൗസർ, ഉപകരണം, ഉപയോക്താവ് — ആവശ്യമെങ്കിൽ ഒരു സ്ക്രീൻഷോട്ടും വേണം. ഒരു റിപ്പോർട്ടിൽ ഒരു bug മാത്രം.

മിക്ക bug-കളും മനസ്സിലാക്കാൻ പരിഹരിക്കുന്നതിനെക്കാൾ സമയമെടുക്കും. നല്ല റിപ്പോർട്ട് ആ മനസ്സിലാക്കൽ ഭാഗം ഒഴിവാക്കുന്നു. AI ഉപകരണങ്ങളുമായി ഇത് കൂടുതൽ പ്രധാനമാണ്: “checkout വിചിത്രമാണ്” എന്നതിന്റെ അർത്ഥം എന്താണെന്ന് AI-ക്ക് തുടർചോദ്യം ചോദിക്കാൻ കഴിയില്ല, അതിനാൽ അത് ഊഹിക്കുന്നു — തെറ്റായ ഊഹം മറ്റെന്തെങ്കിലും തകർക്കാം.

ടെംപ്ലേറ്റ്

ഇത് പകർത്തി പൂരിപ്പിക്കുക:

തലക്കെട്ട്: [എന്താണ് തെറ്റ്, എവിടെ] — ഉദാ. “6 മണിക്ക് ശേഷമുള്ള സമയങ്ങൾ booking form നിരസിക്കുന്നു”

പുനഃസൃഷ്ടിക്കാനുള്ള ഘട്ടങ്ങൾ:
1. ...
2. ...
3. ...

പ്രതീക്ഷിച്ചത്: [എന്ത് സംഭവിക്കണം]
യഥാർത്ഥം: [പകരം എന്ത് സംഭവിച്ചു]

പിശക് സന്ദേശം: [കൃത്യമായ വാചകം, ഉണ്ടെങ്കിൽ]
എവിടെ: [പേജ്/URL, ബ്രൗസർ, ഉപകരണം, ഏത് ഉപയോക്താവായി ലോഗിൻ ചെയ്തിരുന്നു]
എത്ര തവണ: [എല്ലായ്പ്പോഴും / ചിലപ്പോൾ / ഒരിക്കൽ]
സ്ക്രീൻഷോട്ടോ റെക്കോർഡിംഗോ: [അറ്റാച്ച് ചെയ്തത്]

ഈ ഗൈഡിന്റെ ബാക്കി ഓരോ ഭാഗവും വിശദീകരിക്കുന്നു.

ഘട്ടം 1: ആദ്യം പുനഃസൃഷ്ടിക്കുക

എഴുതുന്നതിന് മുമ്പ്, bug വീണ്ടും സംഭവിപ്പിക്കാൻ ശ്രമിക്കുക. ഏത് ഘട്ടങ്ങൾ പ്രധാനമാണെന്നും എല്ലായ്പ്പോഴും സംഭവിക്കുന്നുണ്ടോ എന്നും നിങ്ങൾ അറിയും.

• വൃത്തിയുള്ള അവസ്ഥയിൽ തുടങ്ങുക: പേജ് refresh ചെയ്യുക, അല്ലെങ്കിൽ ലോഗ്ഔട്ട് ചെയ്ത് വീണ്ടും ലോഗിൻ ചെയ്യുക.
• ഓരോ ക്ലിക്കും ടൈപ്പ് ചെയ്യുന്ന ഓരോ കാര്യവും കുറിച്ചുവയ്ക്കുക.
• അത് ട്രിഗർ ചെയ്യുന്ന ഏറ്റവും ചെറിയ വഴി കണ്ടെത്താൻ ശ്രമിക്കുക.
• രണ്ടാമത്തെ ബ്രൗസറോ അക്കൗണ്ടോ പരീക്ഷിക്കുക. ഒരു ഉപയോക്താവിന് മാത്രമാണ് സംഭവിക്കുന്നതെങ്കിൽ, അത് വലിയ സൂചനയാണ്.

ഇതിനെക്കുറിച്ച് കൂടുതൽ അറിയാൻ, AI നിർമ്മിച്ച ആപ്പ് എങ്ങനെ debug ചെയ്യാം കാണുക.

ഘട്ടം 2: കൃത്യമായ തലക്കെട്ട് എഴുതുക

തലക്കെട്ട് എന്താണ് തെറ്റെന്നും എവിടെയെന്നും പറയണം, അങ്ങനെ പട്ടിക സ്കാൻ ചെയ്യുന്ന ആൾക്ക് ഏത് bug ആണെന്ന് അറിയാം.

ഘട്ടം 3: കൃത്യമായ ഘട്ടങ്ങൾ പട്ടികപ്പെടുത്തുക

അവ നമ്പർ ചെയ്യുക. വാക്കർത്ഥത്തിൽ കൃത്യമായിരിക്കുക: ഏത് പേജ്, ഏത് ബട്ടൺ, എന്ത് ടൈപ്പ് ചെയ്തു.

1. ഒരു ഉപഭോക്താവായി ലോഗിൻ ചെയ്യുക (ടെസ്റ്റ് അക്കൗണ്ട്: customer@example.com).
2. “Starter kit” കാർട്ടിൽ ചേർക്കുക.
3. discount കോഡ് WELCOME10 നൽകി Apply ക്ലിക്ക് ചെയ്യുക.
4. Checkout ക്ലിക്ക് ചെയ്യുക.

“കോഡ് ഉപയോഗിച്ച് checkout ചെയ്യാൻ ശ്രമിക്കുക” എന്നത് പലപ്പോഴും പ്രധാനമായ വിശദാംശങ്ങൾ ഒഴിവാക്കുന്നു: ഏത് ഉപയോക്താവ്, ഏത് ഉൽപ്പന്നം, ഏത് കോഡ്, കോഡ് ആദ്യം പ്രയോഗിച്ചോ എന്നത്.

ഘട്ടം 4: പ്രതീക്ഷിച്ചതും യഥാർത്ഥവും

ഇതാണ് റിപ്പോർട്ടിന്റെ കാതൽ. രണ്ടും പറയുക, കാരണം വ്യത്യാസമാണ് bug.

• പ്രതീക്ഷിച്ചത്: മൊത്തത്തിൽ 10% കിഴിവ് കാണിക്കുന്ന checkout പേജ് തുറക്കുന്നു.
• യഥാർത്ഥം: ബട്ടൺ ഒരു സെക്കൻഡ് സ്പിന്നർ കാണിക്കുന്നു, പിന്നെ ഒന്നും സംഭവിക്കുന്നില്ല. discount കോഡ് ഇല്ലാതെ checkout പ്രവർത്തിക്കുന്നു.

“പ്രതീക്ഷിച്ചത്” ഇല്ലെങ്കിൽ, പെരുമാറ്റം തെറ്റാണെന്ന് വായനക്കാരന് അറിയണമെന്നില്ല. “യഥാർത്ഥം” ഇല്ലെങ്കിൽ, എന്താണ് നോക്കേണ്ടതെന്ന് അവർക്കറിയില്ല.

ഘട്ടം 5: പിശകുകൾ കൃത്യമായി പകർത്തുക

പിശക് സന്ദേശങ്ങളാണ് കാരണത്തിലേക്കുള്ള ഏറ്റവും വേഗമുള്ള വഴി. അവ വാചകമായി, വാക്കുകൾ മാറ്റാതെ പകർത്തുക — ഒന്നും പുനരാവിഷ്കരിക്കരുത്.

അവ എവിടെ കണ്ടെത്താം:

• സ്ക്രീനിൽ: ആപ്പ് കാണിക്കുന്ന ഏത് സന്ദേശവും.
• ബ്രൗസർ console: ഡെവലപ്പർ ടൂളുകൾ തുറക്കുക (F12, അല്ലെങ്കിൽ വലത് ക്ലിക്ക് → Inspect), Console ടാബിലെ ചുവന്ന വരികൾ നോക്കുക.
• Network ടാബ്: ഡെവലപ്പർ ടൂളുകളിൽ പരാജയപ്പെട്ട അഭ്യർത്ഥന കണ്ടെത്തി അതിന്റെ URL-ഉം status കോഡും കുറിക്കുക (ഉദാഹരണത്തിന് POST /api/checkout → 500).
• സെർവർ ലോഗുകൾ, നിങ്ങൾക്ക് ആക്സസ് ഉണ്ടെങ്കിൽ.

TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 പോലുള്ള ഒരു വരി പലപ്പോഴും പ്രശ്നത്തിലേക്ക് നേരിട്ട് ചൂണ്ടുന്നു.

ഘട്ടം 6: സന്ദർഭം ചേർക്കുക

• എവിടെ: പേജ് URL, പരിസ്ഥിതി (പ്രിവ്യൂ, staging, അല്ലെങ്കിൽ live).
• ആര്: ഏത് ഉപയോക്താവ് അല്ലെങ്കിൽ റോൾ — അഡ്മിൻ, അംഗം, ലോഗ്ഔട്ട് ആയവർ.
• ഉപകരണവും ബ്രൗസറും: “iPhone-ലെ Safari” vs “Windows-ലെ Chrome” പ്രധാനമാകാം.
• ഡേറ്റ: റെക്കോർഡിനെക്കുറിച്ച് അസാധാരണമായ എന്തും — വളരെ നീളമുള്ള ടെക്സ്റ്റ്, പ്രത്യേക അക്ഷരങ്ങൾ, വലിയ എണ്ണം ഇനങ്ങൾ.
• എപ്പോൾ തുടങ്ങി: “ഇന്നലത്തെ discount കോഡ് മാറ്റത്തിന് ശേഷം” എന്നത് വിലപ്പെട്ടതാണ്.
• എത്ര തവണ: എല്ലായ്പ്പോഴും, അല്ലെങ്കിൽ പത്തിൽ ഒരിക്കൽ.

ഘട്ടം 7: കാണിക്കുക

പ്രശ്നം വൃത്തമിട്ട ഒരു സ്ക്രീൻഷോട്ടോ ഒരു ചെറിയ സ്ക്രീൻ റെക്കോർഡിംഗോ അവ്യക്തത ഇല്ലാതാക്കുന്നു — പ്രത്യേകിച്ച് layout bug-കൾക്ക്. നിങ്ങളുടെ AI ഉപകരണം ചിത്രങ്ങൾ സ്വീകരിക്കുമെങ്കിൽ, ഒന്ന് അറ്റാച്ച് ചെയ്യുക. കീകളും മറ്റുള്ളവരുടെ ഡേറ്റയും ഉൾപ്പെടെ സ്വകാര്യമായ എന്തും ക്രോപ്പ് ചെയ്ത് മാറ്റുക.

AI ബിൽഡറിനായി bug റിപ്പോർട്ടുകൾ എഴുതുന്നത്

അതേ ഘടന ഒരു prompt ആയും പ്രവർത്തിക്കും. രണ്ട് കൂട്ടിച്ചേർക്കലുകൾ സഹായിക്കും:

• മാറാൻ പാടില്ലാത്തത് എന്താണെന്ന് പറയുക, പരിഹാരം പുതിയ പ്രശ്നം ഉണ്ടാക്കാതിരിക്കാൻ.
• പരിഹാരം എഴുതുക മാത്രമല്ല, അത് പരിശോധിക്കാനും ആവശ്യപ്പെടുക.

ഒരു ഉപഭോക്താവായി ലോഗിൻ ചെയ്ത്, കാർട്ടിൽ “Starter kit”-ഉം പ്രയോഗിച്ച WELCOME10 കോഡും ഉള്ളപ്പോൾ Checkout ക്ലിക്ക് ചെയ്താൽ ഒന്നും സംഭവിക്കുന്നില്ല. പ്രതീക്ഷിച്ചത്: മൊത്തത്തിൽ 10% കിഴിവോടെ checkout പേജ് തുറക്കുന്നു. യഥാർത്ഥം: ഒരു ചെറിയ സ്പിന്നർ, പിന്നെ ഒന്നുമില്ല. Network ടാബിൽ POST /api/checkout 500 നൽകുന്നു. കോഡില്ലാതെ checkout പ്രവർത്തിക്കുന്നു. കാരണം കണ്ടെത്തി പരിഹരിക്കുക, കോഡ് ഇല്ലാത്ത ഓർഡറുകൾക്കുള്ള വില കണക്കാക്കൽ മാറ്റാതെ. പിന്നെ ശതമാനം കോഡ്, നിശ്ചിത തുക കോഡ്, കോഡ് ഇല്ലാതെ എന്നിവ ഉപയോഗിച്ച് checkout പരിശോധിക്കുക.

കാരണത്തെക്കുറിച്ച് ഉറപ്പില്ലെങ്കിൽ, ആദ്യം ഒരു രോഗനിർണ്ണയം ആവശ്യപ്പെടുക:

ഇപ്പോൾ കോഡ് മാറ്റരുത്. ഈ റിപ്പോർട്ടിന്റെ അടിസ്ഥാനത്തിൽ, സാധ്യതയുള്ള കാരണങ്ങൾ എന്തൊക്കെയാണ്, ഓരോന്നും സ്ഥിരീകരിക്കുന്നത് എന്താകും?

സാധാരണ തെറ്റുകൾ

• “അത് തകർന്നിരിക്കുന്നു.” ഘട്ടങ്ങളില്ല, പ്രതീക്ഷിച്ച ഫലമില്ല, പ്രവർത്തിക്കാൻ ഒന്നുമില്ല.
• ഒരു റിപ്പോർട്ടിൽ പല bug-കൾ. ചിലത് പരിഹരിക്കപ്പെടും, മറ്റുള്ളവ നഷ്ടപ്പെടും.
• പിശകുകൾ പുനരാവിഷ്കരിക്കുന്നത്. “എന്തോ undefined കാര്യം” ഉപയോഗപ്രദമായ ഭാഗം മറയ്ക്കുന്നു.
• ഉപയോക്താവിനെയോ റോളിനെയോ വിട്ടുപോകുന്നത്. പല bug-കളും അഡ്മിൻമാരെയോ പുതിയ ഉപയോക്താക്കളെയോ മാത്രമേ ബാധിക്കൂ.
• നിങ്ങൾക്ക് വേണ്ട പരിഹാരം മാത്രം വിവരിക്കുന്നത് (“ഒരു null check ചേർക്കുക”) പ്രശ്നം വിവരിക്കുന്നതിന് പകരം.
• സ്ക്രീൻഷോട്ടുകളിലോ ഒട്ടിച്ച ലോഗുകളിലോ രഹസ്യങ്ങൾ പങ്കിടുന്നത്.

Checklist

• ഞാൻ bug പുനഃസൃഷ്ടിച്ചു, ഏറ്റവും ചെറിയ ഘട്ടങ്ങൾ കണ്ടെത്തി.
• തലക്കെട്ട് എന്താണ് തെറ്റെന്നും എവിടെയെന്നും പറയുന്നു.
• ഘട്ടങ്ങൾ നമ്പർ ചെയ്തതും അക്ഷരാർത്ഥത്തിൽ കൃത്യവുമാണ്.
• പ്രതീക്ഷിച്ചതും യഥാർത്ഥവും രണ്ടും പറഞ്ഞിട്ടുണ്ട്.
• പിശക് സന്ദേശങ്ങൾ കൃത്യമായി പകർത്തി, പരാജയപ്പെട്ട അഭ്യർത്ഥനയും status കോഡും ഉൾപ്പെടെ.
• പേജ്, പരിസ്ഥിതി, ഉപയോക്താവ്, ഉപകരണം, ബ്രൗസർ എന്നിവ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.
• ഇത് എത്ര തവണ സംഭവിക്കുന്നു, എപ്പോൾ തുടങ്ങി എന്ന് പറഞ്ഞിട്ടുണ്ട്.
• സ്ക്രീൻഷോട്ടോ റെക്കോർഡിംഗോ അറ്റാച്ച് ചെയ്തു, സ്വകാര്യ ഡേറ്റ നീക്കം ചെയ്തു.
• ഒരു റിപ്പോർട്ടിൽ ഒരു bug.

Mythex ഏജന്റിനോട് bug റിപ്പോർട്ട് ചെയ്യുന്നത്

Mythex പ്രോജക്റ്റിൽ, റിപ്പോർട്ട് തന്നെയാണ് prompt. ചില സവിശേഷതകൾ സഹായിക്കും:

• ഒരു സ്ക്രീൻഷോട്ട് അറ്റാച്ച് ചെയ്യുക പ്രിവ്യൂവിന്റെയോ പിശക് സ്ക്രീനിന്റെയോ — ഓരോ സന്ദേശത്തിനും 5 ഫയലുകൾ വരെ.
• /fix bug പരിഹരിക്കുന്നതിൽ ഏജന്റിനെ കേന്ദ്രീകരിക്കുന്നു; Plan മോഡ് എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് അന്വേഷിക്കാൻ അനുവദിക്കുന്നു.
• /test പ്രിവ്യൂയിൽ തന്നെ flows പുനഃസൃഷ്ടിക്കാനും അത് കാണുന്നതെന്താണെന്ന് റിപ്പോർട്ട് ചെയ്യാനും ഏജന്റിനോട് ആവശ്യപ്പെടുന്നു.
• Revert to this point പരിഹാരം കാര്യങ്ങൾ മോശമാക്കിയാൽ അത് പഴയപടിയാക്കുന്നു.

Docs-ലെ prompt-കൾ ഉപയോഗിച്ച് debugging പേജ് അതേ ഘട്ടങ്ങൾ / പ്രതീക്ഷിച്ചത് / യഥാർത്ഥം ഘടന ഉപയോഗിക്കുന്നു. അതിന് ചുറ്റുമുള്ള പരിഹാര-പരിശോധനാ ലൂപ്പിന്, AI നിർമ്മിച്ച ആപ്പ് എങ്ങനെ ആവർത്തിച്ച് മെച്ചപ്പെടുത്താം കാണുക.

ചോദ്യങ്ങൾ