فائدہ:
- بکھرے ہوئے مشاہدات کو ایک رپورٹ میں تبدیل کرنے کی صلاحیت جس میں واضح عنوان، تعییناتی پنروتپادن کے اقدامات، متوقع/حقیقی نتائج اور مصنوعی ذہانت کی مدد سے شواہد شامل ہوں۔
- مصنوعی ذہانت پر 'صرف جو معلومات میں دیتا ہوں اسے استعمال کریں، اسے نہ بنائیں' کا اصول نافذ کرنے کے قابل ہونا اور اپنے کنٹرول سے تولیدی صلاحیت کی ضمانت دینا
- شدت (تکنیکی اثر) اور ترجیح (کاروباری عجلت) کے درمیان فرق کرنے اور کاروباری سیاق و سباق کے ساتھ حتمی لیبل دینے کے قابل ہونا
ٹیسٹر کو جو بگ ملتا ہے وہ تب ہی قیمتی ہوتا ہے جب اسے ٹھیک کر دیا جاتا ہو۔ اسے ٹھیک کرنا بڑی حد تک بگ رپورٹ کے معیار پر منحصر ہوتا ہے—ایک ایسا ریکارڈ جو کسی خرابی کو اس طرح سے دستاویز کرتا ہے کہ ڈویلپر اسے سمجھ سکتا ہے، دوبارہ تیار کر سکتا ہے اور اسے ٹھیک کر سکتا ہے۔ خراب لکھی ہوئی بگ رپورٹ ("لاگ ان کام نہیں کر رہی") ڈویلپر کو گھنٹوں تک روک دے گی، آگے پیچھے خط و کتابت کا باعث بنے گی، اور اکثر "دوبارہ پیدا نہیں ہو سکتی" کے طور پر بند ہو جائے گی۔ ایک اچھی رپورٹ میں واضح اقدامات، متوقع اور حقیقی نتائج، سیاق و سباق کی معلومات اور شواہد شامل ہیں۔ مصنوعی ذہانت (AI) آپ کے بکھرے ہوئے مشاہدات کو پیشہ ورانہ، منظم رپورٹ میں تبدیل کرنے میں بہت اچھی ہے۔ لیکن مرکزی انتباہ یہاں بھی لاگو ہوتا ہے: AI وہ قدم نہیں بنا سکتا جو آپ کو نظر نہیں آتا ہے۔ گمشدہ معلومات کو "معقول نظر آنے والے" لیکن غلط اندازوں سے پُر کر سکتے ہیں۔ آپ کا کام اس بات کو یقینی بنانا ہے کہ رپورٹ کی ہر سطر اس بات پر مبنی ہے جو آپ نے دیکھا ہے۔
ایک اچھی بگ رپورٹ کی اناٹومی۔
ایک مؤثر رپورٹ میں یہ اجزاء شامل ہیں:
- عنوان: مختصر، مخصوص، قابل تلاش۔ نہیں "ایک غلطی ہے"؛ "کارٹ (کروم) میں 10 سے زیادہ آئٹمز کے ساتھ 'چیک آؤٹ' بٹن پر کلک کرنے سے قاصر"۔
- دوبارہ پیدا کرنے کے اقدامات: شمار شدہ، شروع سے ٹریس کیا جا سکتا ہے، تعین پسند۔ ڈویلپر کو ان اقدامات پر عمل کرنے کے بعد غلطی کو دیکھنے کے قابل ہونا چاہئے۔
- متوقع نتیجہ: قبولیت کے معیار کے مطابق کیا ہونا چاہیے تھا۔
- اصل نتیجہ: کیا ہوا (غلطی کا پیغام، اسکرین، برتاؤ)۔
- ماحول: براؤزر/ڈیوائس، ورژن، ماحول (ٹیسٹ/لائیو)، صارف کا کردار، ڈیٹا۔
- ثبوت: اسکرین شاٹ، ویڈیو، لاگ، ایرر ٹریس (اسٹیک ٹریس)۔
- شدت اور ترجیح: ذیل میں تفصیل۔
اشارہ: رپورٹ بھیجنے سے پہلے، پوچھیں "اگر میں یہ اقدامات کسی اور کو دوں، تو کیا وہ میری مدد کے بغیر غلطی دیکھ سکتے ہیں؟" پوچھنا اگر جواب "نہیں" ہے تو رپورٹ نامکمل ہے۔ AI رپورٹ کو خوبصورت بنا سکتا ہے، لیکن صرف آپ ہی تولیدی صلاحیت کی ضمانت دے سکتے ہیں۔
تشدد اور ترجیح: دو الجھے ہوئے تصورات
شدت غلطی کا تکنیکی اثر ہے: کیا سسٹم کریش ہو جاتا ہے، ڈیٹا ضائع ہو جاتا ہے، یا یہ ٹائپنگ کی غلطی ہے؟ ترجیح یہ ہے کہ اسے کس حد تک فوری طور پر طے کرنے کی ضرورت ہے۔ کاروباری اثرات کے بارے میں ہے. دونوں ہمیشہ ایک ہی سمت میں نہیں جاتے: ہوم پیج پر کمپنی کے نام کی غلط ہجے کم شدت لیکن اعلی ترجیح (شہرت) ہے۔ ایک نایاب کنارے کے معاملے میں، گرنا زیادہ شدت کا ہو سکتا ہے لیکن کم ترجیح کا۔ جب آپ مشاہدہ کرتے ہیں تو AI آپ کو یہ فرق کرنے میں مدد کرتا ہے۔ لیکن حتمی لیبل آپ کے ذریعہ دیا گیا ہے جو کاروباری سیاق و سباق کو جانتے ہیں۔
تشدد
مثال
ترجیح
مثال
تنقیدی (بلاکر)
ادائیگی مکمل نہیں ہو سکتی
ارجنٹ (P1)
لائیو میں آمدنی کا نقصان
اعلی (میجر)
رپورٹ غلط کل بتاتی ہے۔
ہائی (P2)
آنے والی ریلیز کے لیے ضروری ہے۔
درمیانہ (معمولی)
نایاب کنارے کیس کی خرابی۔
درمیانہ (P3)
ایک منصوبہ بند سپرنٹ میں
کم (معمولی)
بٹن کی سیدھ بند ہے۔
کم (P4)
جب موقع ملتا ہے۔
کمزور فوری / مضبوط اشارہ
کمزور: "اس غلطی کی اطلاع دیں: ادائیگی کام نہیں کر رہی ہے۔"
مضبوط: "نیچے میرے مشاہدات کا معیاری بگ رپورٹ فارمیٹ میں ترجمہ کریں: عنوان، تولیدی مراحل (نمبر شدہ)، متوقع نتیجہ، اصل نتیجہ، ماحول، شدت اور ترجیحی تجویز (جائز)۔ صرف میرے فراہم کردہ معلومات کا استعمال کریں؛ کوئی بھی گمشدہ فیلڈ بنائیں، نشان زد کریں 'INFORMATION MISSING:...'۔ مشاہدات: کروم آئٹمز میں کچھ بھی نہیں ہوتا ہے، کروم 12 میں جب کچھ بھی نہیں ہوتا ہے، I12 میں کنسول میں 'چیک آؤٹ' دبائیں، 'غیر متعینہ فنکشن نہیں ہے' غلطی، 11 پروڈکٹس کے ساتھ کوئی مسئلہ نہیں ہے۔
طاقتور فوری؛ فارمیٹ، "فٹنگ" اصول، اور گمشدہ معلومات کی نشان دہی کو نافذ کرتا ہے۔ اس طرح، رپورٹ درست اور ایماندار دونوں ہو جائے گا.
ڈپلیکیٹ غلطی کا پتہ لگانا
بڑی ٹیموں میں ایک ہی غلطی کو بار بار رپورٹ کیا جاتا ہے۔ AI آپ کی نئی رپورٹ کا موجودہ اوپن بگز سے موازنہ کر سکتا ہے اور ممکنہ ڈپلیکیٹس کو جھنڈا لگا سکتا ہے — یہ آپ کے بگ ٹریکنگ سسٹم (جیرا، ایزور ڈی او اوپس، گٹ ہب ایشوز) کو صاف رکھتا ہے۔ لیکن ہوشیار رہو: دو غلطیاں جو سطح پر ایک جیسی نظر آتی ہیں ان کی جڑیں مختلف ہو سکتی ہیں۔ AI کی "ڈپلیکیٹ" تجویز کو بند کرنے سے پہلے دونوں رپورٹس کے دہرائے جانے والے پیداواری مراحل اور ماحول کا موازنہ کریں۔ اتفاقی طور پر بند "ڈپلیکیٹ" میں اصل میں ایک الگ غلطی غائب ہے۔
بگ ٹریس سے جڑ تک: لاگز کو پڑھنے کے لیے AI کی طاقت
بگ رپورٹ کا سب سے زیادہ تکنیکی حصہ اکثر بگ ٹریس ہوتا ہے (اسٹیک ٹریس — کوڈ کی کس لائن کی خرابی، کس کال چین کے ساتھ، بگ کو متحرک کیا)۔ لمبے اور پیچیدہ لاگز ڈویلپر کو بھی تھکا سکتے ہیں۔ AI سینکڑوں لائنوں کا ایک لاگ پڑھتا ہے اور سیکنڈوں میں سب سے اہم لائنوں، ممکنہ بنیادی وجہ مفروضے، اور کوڈ پوائنٹ کا خلاصہ کرتا ہے جہاں غلطی کو متحرک کیا گیا تھا۔ یہ دونوں رپورٹ کو مختصر کرتا ہے اور ڈویلپر کو ایک براہ راست نقطہ آغاز فراہم کرتا ہے۔
اگرچہ دو حدود یاد رکھیں۔ سب سے پہلے، AI کی طرف سے دی گئی بنیادی وجہ ایک مفروضہ ہے، ثبوت نہیں۔ ڈویلپر کو اس کی تصدیق کیے بغیر اسے ٹھیک کرنے کی کوشش نہیں کرنی چاہیے۔ دوسرا، لاگز میں اکثر ذاتی ڈیٹا ہوتا ہے (ای میل، یوزر آئی ڈی، سیشن ٹوکن)؛ گاڑی پر لاگ لگانے سے پہلے ان علاقوں کو ماسک کریں۔ ایک اچھا عمل یہ ہے کہ پہلے AI کو کہا جائے کہ "ان فیلڈز کی فہرست بنائیں جنہیں اس لاگ میں ماسک کرنے کی ضرورت ہے" اور پھر صاف کیے گئے لاگ کا تجزیہ کریں۔
مشورہ: رپورٹ میں پورا لاگ چسپاں کرنے کے بجائے، سب سے اہم 3-5 لائنیں شامل کریں جن کا AI خلاصہ کرتا ہے اور مکمل لاگ کا لنک۔ اس طرح رپورٹ پڑھنے کے قابل رہتی ہے، اور جس ڈویلپر کو تفصیلات کی ضرورت ہے وہ مکمل لاگ تک رسائی حاصل کر سکتا ہے۔
چار کاپی کرنے کے قابل ٹیمپلیٹس
1) مشاہدے سے رپورٹ تک:
آپ کا کردار: سینئر QA۔ درج ذیل خام مشاہدات کا ایک معیاری بگ رپورٹ میں ترجمہ کریں: عنوان / تولیدی مراحل (نمبر) / متوقع / حقیقی / ماحولیات / ثبوت نوٹ / شدت + ترجیح (جائز)۔ اصول: صرف وہی معلومات استعمال کریں جو میں فراہم کرتا ہوں۔ گمشدہ فیلڈ کو بطور "غائب معلومات:..." نشان زد کریں مشاہدات: [کچے نوٹ]
2) تولیدی صلاحیت کنٹرول:
اس بگ رپورٹ کو ایک ڈویلپر کے نقطہ نظر سے پڑھیں جس نے کبھی بگ نہیں دیکھا۔ مراحل پر عمل کریں اور ان جگہوں کو نشان زد کریں جہاں یہ بگ پیدا نہیں کرے گا: مبہم قدم، لاپتہ شرط، گم شدہ ٹیسٹ ڈیٹا، چھوڑی گئی حالت۔ مجھے بتائیں کہ مجھے ہر فرق کے لیے کون سی معلومات شامل کرنی چاہیے۔ رپورٹ: [رپورٹ پیسٹ کریں]
3) شدت/ ترجیحی مشیر:
میں درج ذیل خرابی کی وضاحت کرتا ہوں: [غلطی + کاروباری سیاق و سباق]۔ شدت (تکنیکی اثر) اور ترجیح (کاروباری عجلت) کے لیے الگ الگ تجاویز اور جواز دیں۔ وضاحت کریں کہ دونوں کیوں مختلف ہو سکتے ہیں۔ حتمی فیصلہ میں کروں گا۔
4) لاگ/خرابی کا خلاصہ:
ذیل میں غلطی کے نشان/لاگ کی جانچ کریں۔ مجھے ایک خلاصہ دیں (1) بنیادی وجہ مفروضہ، (2) ممکنہ کوڈ پوائنٹ جہاں غلطی ہوئی، (3) رپورٹ میں شامل کرنے کے لیے 3 انتہائی اہم لائنیں۔ اگر ذاتی ڈیٹا ہو تو ماسک کریں۔ لاگ: [پیسٹ لاگ]
تین چھوٹے مقدمات
کیس 1 - "میں پیدا نہیں کر سکا" سے آزادی۔ ایک ٹیم میں، 30% کیڑے "دوبارہ پیدا نہیں ہو سکتے" کے طور پر بند کر دیے گئے تھے۔ رپورٹ کے عمل میں "ری پروڈیوسبلٹی چیک" ٹیمپلیٹ شامل کر دیا گیا ہے۔ ہر رپورٹ بھیجے جانے سے پہلے، AI نے گمشدہ اقدامات اور شرائط کو جھنڈا لگایا۔ تین ماہ بعد، "پیدا نہیں کر سکا" کی شرح 30% سے کم ہو کر 8% ہو گئی۔ فرق یہ تھا کہ قدم شروع سے بالکل درست تھے۔
کیس 2 - جعلی اقدامات کا خطرہ۔ ایک ٹیسٹر نے AI کو نامکمل مشاہدات کے ساتھ ایک رپورٹ لکھوائی۔ AI نے ایک ایسا قدم شامل کیا جو کبھی نہیں ہوا، جیسا کہ "صارف ترتیبات کے صفحے سے اطلاعات کو آن کرتا ہے"۔ جب ڈویلپر نے اس قدم پر عمل کیا، تو وہ غلطی تلاش نہیں کر سکا اور وقت ضائع ہو گیا۔ ٹیم نے "صرف وہ معلومات استعمال کریں جو میں دیتا ہوں، اسے نہ بنائیں" کا اصول نافذ کیا۔ بنائے گئے قدموں کو ختم کیا جاتا ہے۔
کیس 3 - شدت/ترجیحی امتیاز۔ ہوم پیج پر کمپنی کے نعرے میں ٹائپنگ کی غلطی تھی۔ ٹیسٹر اسے "کم" کے طور پر پاس کرے گا۔ AI کنسلٹنٹ نے یاد دلایا کہ تکنیکی تشدد کم ہے لیکن کاروباری ترجیح زیادہ ہے (ساکھ کا عنصر جو ہر آنے والے کو ملتا ہے)۔ بگ کو اسی دن "اعلی ترجیحی" ٹیگ کے ساتھ ٹھیک کر دیا گیا تھا۔
عام غلطیاں
- مبہم عنوان۔ ناقابل تلاش، غیر امتیازی سرخیاں جیسے "کام نہیں کرنا"۔
- غائب/چھوڑے گئے مراحل۔ وہ نہیں لکھنا جو آپ کے سیاق و سباق میں واضح ہے۔ تیار کرنے میں ڈویلپر کی ناکامی۔
- AI کو اسے بنانے دینا۔ گمشدہ معلومات کو "معقول تخمینہ" کے ساتھ بھرنا؛ غلط اقدامات.
- متوقع نتیجہ نہیں لکھنا۔ "غلط" کہنا لیکن صحیح کیا ہے اس کی وضاحت نہیں کرنا۔
- مبہم تشدد اور ترجیح۔ دونوں کو ایک لیبل سمجھنا؛ کاروباری اثرات کا غلط اندازہ لگانا۔
- ثبوت میں حساس ڈیٹا۔ اسکرین شاٹس/لاگز میں اصلی ذاتی ڈیٹا کو بغیر ماسک لگائے شیئر کرنا۔
خلاصہ میں
بگ رپورٹ کی اہمیت یہ ہے کہ ڈویلپر آپ کی مدد کے بغیر بگ کو دوبارہ تیار اور ٹھیک کر سکتا ہے۔ AI بکھرے ہوئے مشاہدات کو پیشہ ورانہ، منظم رپورٹ میں تبدیل کرنے میں بہت اچھا ہے۔ یہ عنوان، اقدامات، متوقع/حقیقی نتیجہ، ماحول اور شواہد کو منظم کرتا ہے، اور شدت اور ترجیح کے درمیان فرق پر مشاورت فراہم کرتا ہے۔ لیکن AI گمشدہ معلومات کو پورا کر سکتا ہے۔ "صرف وہ معلومات استعمال کریں جو میں دیتا ہوں، غائب کو نشان زد کریں" کے اصول کو نافذ کریں اور خود تولیدی صلاحیت کی ضمانت دیں۔ ثبوت میں ذاتی ڈیٹا کو ماسک کریں۔
درخواست کا کام
ایک بگ لیں جو آپ نے حال ہی میں پایا ہے اور اپنے خام مشاہدات کو "رپورٹ کرنے کے لیے مشاہدہ" پیٹرن ("فٹنگ" اصول کے ساتھ) کا استعمال کرتے ہوئے رپورٹ میں تبدیل کریں۔ پھر "پیداواری جانچ" انجام دیں اور نشان زدہ خالی جگہوں کو پُر کریں۔ رپورٹ کسی ساتھی کو دیں اور دیکھیں کہ آیا وہ آپ کی مدد کے بغیر غلطی پیدا کر سکتا ہے۔ آخر میں، "تشدد/ترجیحی مشیر" کے ساتھ لیبلز کا تعین کریں اور اسے اپنی صوابدید پر حتمی شکل دیں۔ کسی بھی معلومات کو نوٹ کریں جو AI اس عمل میں بنانے کی کوشش کرتا ہے۔
چیک لسٹ
- میرا عنوان مخصوص اور قابل تلاش ہے۔
- پنروتپادن کے مراحل شروع سے، تعییناتی اور مکمل ہیں۔
- میں نے متوقع اور حقیقی نتائج الگ الگ لکھے۔
- ترتیب اور ثبوت کی معلومات مکمل ہے؛ میں نے ذاتی ڈیٹا کو نقاب پوش کیا۔
- میں نے AI پر "میک اپ، مارک دی مسنگ" کا اصول نافذ کیا اور خود اس خلا کو پُر کیا۔
- میں نے شدت اور ترجیح کا الگ الگ جائزہ لیا اور حتمی فیصلہ کیا۔