فهرست مطالب
«سلام، سایتتون کار نمی‌کنه.» این پیام را هر کسی که پشتیبانی یک محصول نرم‌افزاری را بر عهده داشته، بارها دیده است. بعدش یک رشته پیام رفت‌وبرگشتی شروع می‌شود: کدام صفحه؟ با گوشی یا کامپیوتر؟ چه پیامی دیدید؟ می‌شود عکس بفرستید؟ تا جواب برسد کاربر یا خسته شده، یا خودش صفحه را چند بار تازه کرده و دیگر مطمئن نیست دقیقاً چه دیده بود.
مشکل از کاربر نیست. کاربر وظیفه ندارد گزارش باگ استاندارد بنویسد. مشکل این است که ما راه گزارش دادن را طوری ساخته‌ایم که مهم‌ترین اطلاعات همان چیزهایی است که کاربر نمی‌داند یا یادش نمی‌ماند. در این نوشته می‌گوییم یک گزارش باگ کاربر چه چیزهایی باید داشته باشد، کدام‌ها را باید خودکار جمع کرد، و اسکرین‌شات را چطور بگیریم که حریم خصوصی کسی را زیر پا نگذارد.
گزارش بد چه شکلی است و چرا هزینه دارد
گزارش بد معمولاً یکی از این سه شکل را دارد: یک جملهٔ کلی («پرداخت خراب است»)، یک اسکرین‌شات بدون توضیح که نیمی از آن نوار وظیفهٔ ویندوز است، یا توضیحی طولانی از اینکه کاربر چه حسی داشت بدون اینکه بگوید چه کرد. هزینهٔ هر کدام فقط وقت پشتیبانی نیست. برنامه‌نویسی که کارت باگ را برمی‌دارد، ساعت اول را صرف حدس زدن شرایط می‌کند، و اگر نتواند بازتولیدش کند، کارت با برچسب «بازتولید نشد» بسته می‌شود؛ تا وقتی که کاربر بعدی همان را گزارش کند.
باگی که بازتولید نشود، معمولاً رفع نمی‌شود. یا اگر رفع شود، کسی مطمئن نیست که واقعاً رفع شده است. پس هدف گزارش باگ یک چیز است: اینکه برنامه‌نویس بتواند همان چیزی را که کاربر دید، دوباره ببیند.
اجزای یک گزارش باگ خوب
تیم‌های تست سال‌هاست قالب استانداردی برای گزارش باگ دارند. اجزای اصلی‌اش این‌هاست:
| جزء | کاربر می‌داند؟ | قابل جمع‌آوری خودکار؟ |
|---|---|---|
| چه کاری می‌خواست انجام دهد و چه انتظاری داشت | بله | خیر |
| چه چیزی دید (تصویر صفحه) | بله، ولی توصیفش سخت است | بله، با اسکرین‌شات |
| نشانی دقیق صفحه | معمولاً نه | بله |
| مرورگر، سیستم‌عامل و اندازهٔ صفحه | به‌ندرت | بله |
| زمان دقیق | تقریبی | بله |
| مراحل قبل از خطا | به‌طور ناقص | بله، با breadcrumbs |
| خطاهای کنسول و درخواست‌های ناموفق | خیر | بله |
| شناسهٔ کاربر و نسخهٔ برنامه | خیر | بله |
نتیجهٔ این جدول ساده است: از هشت جزء، فقط یکی واقعاً به کاربر نیاز دارد. بقیه را مرورگر خودش می‌داند. فرم گزارشی که از کاربر می‌خواهد مرورگر و نسخه‌اش را بنویسد، هم کاربر را خسته می‌کند و هم دادهٔ نادرست جمع می‌کند.
چرا اسکرین‌شات این‌قدر مهم است
کاربر برای توصیف مشکلات ظاهری واژه ندارد. «دکمه رفته زیر» یعنی چه؟ زیر هدر؟ زیر کیبورد گوشی؟ بیرون از کادر؟ یک تصویر این ابهام را در یک ثانیه حل می‌کند. از آن مهم‌تر، اسکرین‌شات وضعیتی را نشان می‌دهد که کاربر حتی متوجهش نیست: پیام خطای کوچکی گوشهٔ فرم، فیلدی که خالی مانده، یا زبانی که اشتباه انتخاب شده.
ولی اسکرین‌شاتی که کاربر خودش با گوشی از مانیتور می‌گیرد یا با ابزار ویندوز می‌برد، معمولاً یا ناقص است یا در پیام‌رسان فشرده و ناخوانا شده. بهتر است اسکرین‌شات همان لحظهٔ ثبت گزارش، از خود صفحه و در مرورگر کاربر گرفته شود و مستقیم به گزارش ضمیمه شود.
ویجت بازخورد: گزارش دادن را ارزان کنید
اگر گزارش دادن از ایمیل زدن یا تماس با پشتیبانی سخت‌تر باشد، کسی گزارش نمی‌دهد. یک ویجت بازخورد خوب این ویژگی‌ها را دارد:
- یک دکمه، در همان صفحه. کاربر نباید صفحه را ترک کند؛ زمینه همان‌جاست.
- یک فیلد متنی. فقط بپرسید «چه اتفاقی افتاد؟». نوع گزارش (باگ یا پیشنهاد) را با یک انتخاب ساده بگیرید.
- ضمیمهٔ خودکار. اسکرین‌شات، نشانی، مرورگر، breadcrumbs و خطاهای اخیر بی‌آنکه کاربر کاری کند پیوست شوند.
- ظاهر هماهنگ با سایت. دکمه‌ای که شبیه تبلیغ یا پاپ‌آپ بیگانه باشد، اعتماد کاربر را کم می‌کند. ویجت نباید با CSS سایت تداخل داشته باشد.
- کنترل اینکه چه کسی آن را ببیند. گاهی فقط کاربران واردشده یا یک گروه آزمایشی باید دکمه را ببینند، مثلاً در دورهٔ UAT.
گزارش کاربر با خطای خودکار فرق دارد ولی مکمل آن است. رصد خودکار، که در راهنمای رصد خطای جاوااسکریپت توضیح داده‌ایم، خطاهایی را می‌گیرد که کد می‌فهمد. گزارش کاربر چیزهایی را می‌گیرد که کد خطا نمی‌داند: محاسبهٔ غلط، متن اشتباه، دکمه‌ای که کار می‌کند ولی کار اشتباهی می‌کند.
ماسک کردن فیلدهای حساس
اسکرین‌شات از صفحه یعنی هر چیزی که روی صفحه است: رمز عبوری که در فیلد تایپ شده، شمارهٔ کارت، کد ملی، آدرس، موجودی حساب. اگر این‌ها در سیستم گزارش باگ ذخیره شوند، آن سیستم به یکی از حساس‌ترین انبارهای دادهٔ شما تبدیل می‌شود، بی‌آنکه کسی چنین قصدی داشته باشد. چند قاعده:
- ماسک باید در مرورگر و پیش از ارسال انجام شود، نه بعد از رسیدن تصویر به سرور.
- فیلدهای
type="password"همیشه و بدون استثنا ماسک شوند. - برای فیلدها و بخش‌های حساس دیگر یک نشانهٔ صریح در HTML بگذارید تا تیم بتواند تعیین کند چه چیزی محو شود.
- متن گزارش و دادهٔ همراه آن هم سمت سرور از داده‌های شخصی مثل ایمیل و موبایل پاک‌سازی شود.
- دسترسی به گزارش‌ها را محدود کنید و برای نگه‌داری‌شان مدت مشخص بگذارید.
از گزارش تا کارت باگ
گزارش خوب نیمی از کار است. نیم دیگر این است که گزارش‌ها در صندوقی رها نشوند. یک روال سبک کافی است: هر روز یک نفر گزارش‌های تازه را مرور کند، تکراری‌ها را با هم ادغام کند، آن‌هایی را که باگ واقعی‌اند به کارت تبدیل کند و به کاربر بگوید گزارشش دیده شده. کارتی که از گزارش کاربر ساخته می‌شود، لینک گزارش اصلی با اسکرین‌شات و breadcrumbs را داشته باشد تا برنامه‌نویس مجبور نشود دوباره بپرسد. اینکه این کارت بعد از آن چه مسیری را در لاگ، دیتابیس و اسپرینت طی می‌کند، در چرخهٔ عمر یک خطا آمده است.
باگ‌ماگ برای همین ساخته شده
باگ‌ماگ یک دکمهٔ بازخورد به سایت اضافه می‌کند که کاربر با آن باگ یا پیشنهاد می‌فرستد و اسکرین‌شات صفحه خودکار در مرورگر خودش گرفته و ضمیمه می‌شود. مسیر کلیک‌ها، ناوبری و لاگ‌های قبل از رخداد کنار گزارش ثبت می‌شود، فیلدهای حساس مثل رمز عبور در اسکرین‌شات خودکار ماسک می‌شوند و داده‌های شخصی سمت سرور پاک می‌شوند. ویجت در Shadow DOM ایزوله است و رنگ، لوگو، متن و موقعیت دکمه قابل تنظیم است.
می‌توانید ثبت گزارش را به کاربران واردشده، نقش‌های مشخص یا افراد مشخص محدود کنید، یا دکمه را کاملاً خاموش کنید و فقط رصد خودکار خطا را نگه دارید. این تنظیم سمت سرور هم اعمال می‌شود. در پلن رایگان ماهی ۳۰ گزارش کاربر روی یک سایت دارید؛ جزئیات پلن‌ها در سایت باگ‌ماگ است.
پرسش‌های پرتکرار
آیا دکمهٔ گزارش باگ تصویر سایت را خراب نمی‌کند؟
اگر کوچک، هم‌رنگ سایت و در گوشه‌ای ثابت باشد، نه. کاربرانی که مشکلی ندارند معمولاً اصلاً متوجهش نمی‌شوند و کسانی که مشکل دارند، دقیقاً همان را می‌خواهند. اگر نگرانید، اول آن را فقط به کاربران واردشده نشان دهید.
آیا اسکرین‌شات بدون اجازهٔ کاربر گرفته می‌شود؟
نباید. اسکرین‌شات فقط باید وقتی گرفته شود که کاربر خودش گزارش را ثبت می‌کند، و بهتر است پیش از ارسال آن را ببیند. ضبط مخفی صفحه، حتی با نیت خوب، اعتماد کاربر را از بین می‌برد.
برای محیط UAT هم مفید است؟
خیلی. آزمایش‌کنندگان کسب‌وکار در UAT دقیقاً همان مشکل کاربران را دارند: می‌دانند چیزی اشتباه است ولی نمی‌دانند چطور گزارشش کنند. ویجت با زمینهٔ خودکار، چرخهٔ UAT را کوتاه‌تر می‌کند.
جمع‌بندی
گزارش باگ کاربر وقتی ارزش دارد که برنامه‌نویس بتواند با آن مشکل را بازتولید کند. بیشتر اطلاعات لازم برای این کار را کاربر نمی‌داند ولی مرورگر می‌داند. پس از کاربر فقط بپرسید چه اتفاقی افتاد، بقیه را خودکار جمع کنید، اسکرین‌شات را در همان لحظه و با ماسک فیلدهای حساس بگیرید، و مطمئن شوید هر گزارش به کارتی با صاحب مشخص تبدیل می‌شود.