واحد 7 / 11

نوشتن و اولویت بندی گزارش خطا: سوابق پاک و قابل تکرار با هوش مصنوعی

سود:

  • توانایی تبدیل مشاهدات پراکنده به گزارشی حاوی عنوان واضح، مراحل بازتولید قطعی، نتایج مورد انتظار/واقعی و شواهد با پشتیبانی هوش مصنوعی
  • توانایی تحمیل قاعده "فقط از اطلاعاتی که من می دهم استفاده کنید، آن را جبران نکنید" به هوش مصنوعی و تضمین تکرارپذیری با کنترل خود
  • توانایی تمایز بین شدت (تأثیر فنی) و اولویت (فوریت تجاری) و دادن برچسب نهایی با زمینه کسب و کار

اشکالی که آزمایشگر پیدا می کند تنها در صورتی ارزشمند است که رفع شود. رفع آن تا حد زیادی به کیفیت گزارش اشکال بستگی دارد - رکوردی که یک نقص را به گونه‌ای مستند می‌کند که توسعه‌دهنده بتواند آن را درک، بازتولید و رفع کند. یک گزارش اشکال بد نوشته شده ("ورود به سیستم کار نمی کند") برنامه نویس را برای ساعت ها متوقف می کند، منجر به مکاتبات رفت و برگشتی می شود و اغلب به عنوان "نمی توان بازتولید کرد" بسته می شود. یک گزارش خوب شامل مراحل روشن، نتایج مورد انتظار و واقعی، اطلاعات زمینه و شواهد است. هوش مصنوعی (AI) در تبدیل مشاهدات پراکنده شما به یک گزارش حرفه ای و ساختارمند بسیار خوب است. اما اخطار اصلی در اینجا نیز صدق می کند: هوش مصنوعی نمی تواند مراحلی را که نمی بینید بسازد. می‌تواند اطلاعات گمشده را با حدس‌های «معقول» اما نادرست پر کند. وظیفه شما این است که مطمئن شوید هر خط گزارش بر اساس آنچه واقعا مشاهده کرده اید است.

آناتومی یک گزارش اشکال خوب

یک گزارش موثر شامل این اجزا است:

  • عنوان: کوتاه، خاص، قابل جستجو. نه "خطایی وجود دارد"؛ "نمی توان روی دکمه "تسویه حساب" با بیش از 10 مورد در سبد خرید (Chrome) کلیک کرد".
  • مراحل تکثیر: شماره گذاری شده، قابل ردیابی از ابتدا، قطعی. پس از انجام این مراحل، توسعه دهنده باید بتواند خطا را ببیند.
  • نتیجه مورد انتظار: آنچه باید طبق معیارهای پذیرش اتفاق می افتاد.
  • نتیجه واقعی: چه اتفاقی افتاد (پیام خطا، صفحه نمایش، رفتار).
  • محیط: مرورگر/دستگاه، نسخه، محیط (تست/زنده)، نقش کاربر، داده.
  • شواهد: اسکرین شات، ویدئو، گزارش، ردیابی خطا (ردیابی پشته).
  • شدت و اولویت: به تفصیل در زیر.
نکته: قبل از ارسال گزارش، بپرسید "اگر این مراحل را به شخص دیگری بدهم، آیا او می تواند بدون کمک من خطا را ببیند؟" بپرسید اگر پاسخ «نه» باشد، گزارش ناقص است. هوش مصنوعی می تواند گزارش را زیبا کند، اما فقط شما می توانید تکرارپذیری را تضمین کنید.

خشونت و اولویت: دو مفهوم مغشوش

شدت اثر فنی خطا است: آیا سیستم از کار می افتد، داده ها از بین می روند یا اشتباه تایپی است؟ اولویت این است که چقدر فوری باید رفع شود. در مورد تأثیر تجارت است. این دو همیشه در یک جهت نیستند: غلط املایی نام شرکت در صفحه اصلی با شدت کم اما اولویت (شهرت) بالاست. در یک مورد لبه نادر، سقوط ممکن است با شدت بالا اما اولویت پایین باشد. هوش مصنوعی به شما کمک می کند این تمایز را هنگام مشاهده انجام دهید. اما برچسب نهایی توسط شما که زمینه کسب و کار را می دانید داده می شود.

خشونت

مثال

اولویت

مثال

بحرانی (مسدود کننده)

پرداخت نمی تواند تکمیل شود

فوری (P1)

از دست دادن درآمد در زندگی

عالی (عالی)

گزارش مجموع نادرست را نشان می دهد

بالا (P2)

باید برای انتشار آینده

متوسط (مینور)

خطای نادر لبه

متوسط (P3)

در یک سرعت برنامه ریزی شده

کم (بی اهمیت)

تراز دکمه خاموش است

کم (P4)

وقتی فرصت هست

اعلان ضعیف / اعلان قوی

ضعیف: "این خطا را گزارش کنید: پرداخت کار نمی کند."
قوی: "مشاهدات من را در زیر به قالب گزارش اشکال استاندارد ترجمه کنید: عنوان، مراحل بازتولید (شماره‌گذاری شده)، نتیجه مورد انتظار، نتیجه واقعی، محیط، شدت و توصیه اولویت (قابل توجیه). فقط از اطلاعاتی که ارائه می‌دهم استفاده کنید؛ فیلدهای گمشده را ایجاد کنید، "INFORMATION MISSING: ..." را علامت بزنید. مشاهدات: "Chrome 112e هیچ اتفاقی نمی‌افتد، در محیط آزمایشی، I. خطای «تعریف نشده یک تابع نیست» در کنسول، مشکلی با 11 محصول وجود ندارد.

اعلان قدرتمند؛ قالب، قانون "برازندگی" و علامت گذاری اطلاعات از دست رفته را تحمیل می کند. به این ترتیب گزارش هم دقیق و هم صادق خواهد بود.

تشخیص خطای تکراری

در تیم های بزرگ، یک خطا بارها و بارها گزارش می شود. هوش مصنوعی می‌تواند گزارش جدید شما را با باگ‌های باز موجود مقایسه کند و موارد تکراری احتمالی را پرچم‌گذاری کند – این سیستم ردیابی اشکال شما (Jira، Azure DevOps، مسائل GitHub) را تمیز نگه می‌دارد. اما مراقب باشید: دو خطا که در ظاهر مشابه به نظر می رسند ممکن است دلایل ریشه ای متفاوتی داشته باشند. قبل از بستن پیشنهاد "تکراری" هوش مصنوعی، مراحل تولید تکرار و محیط هر دو گزارش را مقایسه کنید. یک "کپی" به طور تصادفی بسته شده در واقع یک خطای جداگانه ندارد.

از ردیابی اشکال تا علت اصلی: قدرت هوش مصنوعی در خواندن گزارش‌ها

فنی ترین بخش گزارش باگ اغلب ردیابی باگ است (ردیابی پشته - تفکیک کدام خط کد، با کدام زنجیره تماس، باعث ایجاد یک باگ شده است). لاگ های طولانی و پیچیده می توانند حتی توسعه دهنده را خسته کنند. هوش مصنوعی گزارشی متشکل از صدها خط را می خواند و بحرانی ترین خطوط، فرضیه احتمالی علت اصلی و نقطه کدی که خطا در آن ایجاد شده را در چند ثانیه خلاصه می کند. این هم گزارش را کوتاه می کند و هم یک نقطه شروع مستقیم به توسعه دهنده می دهد.

با این حال، دو محدودیت را به خاطر بسپارید. اول، علت اصلی ارائه شده توسط هوش مصنوعی یک فرضیه است، نه شواهد. توسعه‌دهنده نباید بدون تأیید این مشکل را برطرف کند. دوم، گزارش‌ها اغلب حاوی اطلاعات شخصی (ایمیل، شناسه کاربر، نشانه جلسه) هستند. قبل از قرار دادن کنده روی خودرو، این نواحی را بپوشانید. یک تمرین خوب این است که ابتدا از هوش مصنوعی بخواهید بگوید "فیلدهایی که باید در این گزارش ماسک شوند را فهرست کنید" و سپس گزارش تمیز شده را تجزیه و تحلیل کنید.

نکته: به جای چسباندن کل گزارش در گزارش، مهم ترین 3 تا 5 خطی را که هوش مصنوعی خلاصه می کند و پیوندی به گزارش کامل وارد کنید. به این ترتیب گزارش قابل خواندن باقی می ماند و توسعه دهنده ای که به جزئیات نیاز دارد می تواند به گزارش کامل دسترسی داشته باشد.

چهار قالب قابل کپی

1) از مشاهده تا گزارش:

نقش شما: ارشد QA. مشاهدات خام زیر را به یک گزارش اشکال استاندارد ترجمه کنید: عنوان / مراحل تولید مثل (شمرده شده) / مورد انتظار / واقعی / محیط / یادداشت شواهد / شدت + اولویت (موجه). قانون: فقط از اطلاعاتی که ارائه می کنم استفاده کنید. فیلد گم شده را به عنوان "اطلاعات گمشده:..." علامت گذاری کنید مشاهدات: [یادداشت های خام]

2) کنترل تکرارپذیری:

این گزارش باگ را از دیدگاه توسعه‌دهنده‌ای بخوانید که هرگز باگ را ندیده است. مراحل را دنبال کنید و مکان‌هایی را که اشکال ایجاد نمی‌کند علامت‌گذاری کنید: مرحله مبهم، پیش‌نیاز از دست رفته، داده‌های تست از دست رفته، شرایط رد شده. به من بگویید برای هر شکاف چه اطلاعاتی را اضافه کنم. گزارش: [چسب کردن گزارش]

3) مشاور شدت/اولویت:

من خطای زیر را شرح می دهم: [خطا + زمینه کسب و کار]. پیشنهادات و توجیهات را جداگانه برای شدت (تأثیر فنی) و اولویت (فوریت تجاری) ارائه دهید. توضیح دهید که چرا این دو ممکن است متفاوت باشند. من تصمیم نهایی را خواهم گرفت.

4) خلاصه ردیابی گزارش/خطا:

خطای trace/log زیر را بررسی کنید. خلاصه ای از (1) فرضیه علت اصلی، (2) نقطه کد احتمالی که در آن خطا رخ داده است، (3) 3 خط بسیار مهم را برای اضافه کردن به گزارش به من بدهید. اگر داده‌های شخصی وجود دارد، ماسک کنید. ورود به سیستم: [ثبت ثبت]

سه کیف کوچک

مورد 1 - رهایی از "من نتوانستم تولید کنم". در یک تیم، 30٪ از اشکالات به عنوان "نمی توان تولید مثل" بسته شد. الگوی "بررسی تکرارپذیری" به روند گزارش اضافه شده است. قبل از ارسال هر گزارش، هوش مصنوعی مراحل و پیش نیازهای گمشده را علامت گذاری می کرد. سه ماه بعد، نرخ «نتوانستم تولید کنم» از 30 درصد به 8 درصد کاهش یافت. تفاوت این بود که مراحل از ابتدا دقیق بود.

مورد 2 - خطر مراحل ساختگی. یک آزمایش‌کننده از هوش مصنوعی خواست گزارشی با مشاهدات ناقص بنویسد. هوش مصنوعی مرحله ای را اضافه کرد که هرگز اتفاق نیفتاد، مانند "کاربر اعلان ها را از صفحه تنظیمات روشن می کند". وقتی توسعه دهنده این مرحله را دنبال کرد، نتوانست خطا را پیدا کند و زمان را از دست داد. این تیم قانون «فقط از اطلاعاتی که من می‌دهم استفاده کنید، آن را ایجاد نکنید» را اجرا کرد. مراحل ساختگی حذف می شوند.

مورد 3 - تمایز شدت/اولویت. در شعار شرکت در صفحه اصلی اشتباه تایپی وجود داشت. تستر این را به عنوان "کم" ارسال می کند. مشاور هوش مصنوعی یادآور شد که خشونت فنی کم است اما اولویت کسب و کار زیاد است (عنصر شهرتی که هر بازدیدکننده دریافت می کند). این اشکال در همان روز با برچسب "اولویت بالا" برطرف شد.

اشتباهات رایج

  • عنوان مبهم عناوین غیر قابل جستجو و بدون تبعیض مانند "کار نمی کند".
  • مراحل از دست رفته/رد شده. ننوشتن آنچه در متن شما آشکار است. شکست توسعه دهنده در تولید
  • اجازه دادن به هوش مصنوعی آن را بسازد. داشتن اطلاعات گمشده با "برآورد معقول" پر شده است. مراحل اشتباه
  • ننوشتن نتیجه مورد انتظار گفتن "اشتباه" اما مشخص نکردن اینکه چه چیزی درست است.
  • خشونت و اولویت گیج کننده اشتباه گرفتن این دو به عنوان یک برچسب. ارزیابی نادرست تاثیر کسب و کار
  • داده های حساس در شواهد به اشتراک گذاری داده های شخصی واقعی در اسکرین شات ها / گزارش ها بدون پوشاندن آنها.

به طور خلاصه

ارزش گزارش اشکال این است که توسعه‌دهنده می‌تواند بدون کمک شما اشکال را بازتولید و برطرف کند. هوش مصنوعی در تبدیل مشاهدات پراکنده به یک گزارش حرفه ای و ساختارمند بسیار خوب است. عنوان، مراحل، نتیجه مورد انتظار/واقعی، محیط و شواهد را سازماندهی می کند و در مورد تمایز بین شدت و اولویت مشاوره ارائه می دهد. اما هوش مصنوعی می تواند اطلاعات از دست رفته را جبران کند. قانون «فقط از اطلاعاتی که من می‌دهم استفاده کنید، گمشده‌ها را علامت بزنید» را اجرا کنید و خودتان تکرارپذیری را تضمین کنید. اطلاعات شخصی را در شواهد پنهان کنید.

وظیفه کاربردی

اشکالی را که اخیراً پیدا کرده اید بردارید و مشاهدات خام خود را با استفاده از الگوی "مشاهده در گزارش" (با قانون "مناسب") به گزارش تبدیل کنید. سپس "بررسی تکرارپذیری" را انجام دهید و شکاف های مشخص شده را پر کنید. گزارش را به یک همکار بدهید و ببینید آیا او می تواند بدون کمک شما خطا را ایجاد کند یا خیر. در نهایت، برچسب‌ها را با «مشاور خشونت/اولویت» مشخص کنید و به صلاحدید خود نهایی کنید. هر اطلاعاتی را که هوش مصنوعی سعی می کند در این فرآیند ایجاد کند، یادداشت کنید.

چک لیست

  • [ ] عنوان من خاص و قابل جستجو است.
  • [ ] مراحل تولید مثل از ابتدا، قطعی و کامل هستند.
  • [ ] من نتایج مورد انتظار و واقعی را جداگانه نوشتم.
  • [ ] اطلاعات تنظیم و شواهد کامل است. من داده های شخصی را پنهان کردم.
  • [ ] من قانون «آن را بساز، گمشده را علامت بزن» را بر هوش مصنوعی تحمیل کردم و خودم شکاف ها را پر کردم.
  • [ ] شدت و اولویت را جداگانه ارزیابی کردم و تصمیم نهایی را گرفتم.