نحوه نوشتن گزارش اشکال خوب: توصیه ها

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

مدتی می گذرد و یک بلیط جدید ظاهر می شود، اما در داخل، فقط چند خط و یک اسکرین شات وجود دارد. با یک آه، سعی می کنید با استفاده از این اطلاعات اشکال را بازتولید کنید، اما هیچ خطایی وجود ندارد. چندین بار تلاش می‌کنید، اما در نهایت، به تستر می‌نویسید که باگ قابل تکرار نیست و دور جدیدی از شفاف‌سازی آغاز می‌شود.

زمانی را صرف می‌کنید که می‌توانست برای کار بر روی کارهای جدید، رفع اشکالات دیگر یا حتی تماشای انیمه‌ای که کد را بازسازی می‌کند، استفاده شود.

نام من Evgeny Domnin است. من یک QA هستم، و سعی خواهم کرد دیدگاه خود را در مورد آنچه که یک گزارش اشکال خوب را ایجاد می کند، به اشتراک بگذارم. با عرض پوزش برای طولانی شدن مقدمه - بیایید شروع کنیم.

عنوان

سعی کنید به سه سوال در عنوان بلیط پاسخ دهید:

1. کجا اتفاق می افتد؟
2. چه اتفاقی می افتد؟
3. تحت چه شرایطی؟

یک توسعه دهنده باتجربه فقط کافی است نگاهی به عنوان داشته باشد تا مشکل را درک کند. به عنوان مثال:

صفحه ورود: هنگام وارد کردن رمز عبور نادرست، فیلد برجسته نمی شود

محیط زیست

اغلب دیده‌ام که آزمایش‌کننده‌ها فراموش کرده‌اند که در بلیط مشخص کنند مشکل در کدام محیط رخ داده است. این موضوع به‌ویژه در بلیط‌های مربوط به رابط کاربری که آدرس وب‌سایت یا درخواست شبکه قابل مشاهده نیست، مرتبط است. همیشه این را مشخص کنید. اگر قسمت جداگانه ای در بلیط وجود دارد، عالی است، آن را در آنجا قرار دهید. اگر نه، آن را در مراحل تولید مثل ذکر کنید، به عنوان مثال:

با اکانت ادمین وارد محیط استیجینگ شوید.

صحبت از مراحل ...

مراحل تولید مثل

یکی از مهم ترین بخش ها دستورالعمل بازتولید اشکال است. من دو بخش را برای تمرکز بر روی آنها برجسته می کنم: قالب بندی مراحل (بصری) و محتوا (داده های داخل).

بخش بصری

ساختار را حفظ کنید

انواع مختلفی از گزارش های اشکال وجود دارد، اما به طور کلاسیک، آنها باید شامل بخش های زیر باشند:

1. مراحل
2. نتیجه مورد انتظار
3. نتیجه واقعی

از این ساختار استفاده کنید و همیشه به آن پایبند باشید. این یکی از مواردی است که یکنواختی به سازماندهی افکار شما در هنگام توصیف موضوع کمک می کند.

از یک لیست شماره دار استفاده کنید

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

در صورت امکان، بدون اشتباهات گرامری بنویسید.

حال به سراغ محتوای این مراحل می رویم.

عقل سلیم در توضیحات

اگر برای بازتولید باگ حیاتی نیست، لازم نیست هر اقدام را به یک مرحله جداگانه تقسیم کنید - خواندن و استفاده از این در عمل دشوار است. از گنجاندن چندین عمل در یک مرحله نترسید. منظورم چیست؟

بد :

1. به test.com/login بروید

2. روی فیلد ورود کلیک کنید

3. ورود را وارد کنید

4. روی قسمت رمز عبور کلیک کنید

5. رمز عبور را وارد کنید

   
   

خوب :

1. به test.com/login بروید و با هر حساب کاربری وارد شوید

ما مراحل را به کارهایی تقسیم نمی کنیم که توسعه دهنده به طور طبیعی همزمان با پیروی از جریان استاندارد انجام می دهد. زمانی که شروع به کار کردم، فکر می‌کردم که هر اقدامی به قدم خودش نیاز دارد، اما لازم نیست.

از ابهام بپرهیزید

همیشه مراحل را با درخواست خاصی برای بررسی در هر مرحله تکمیل کنید و دکمه خاص را برای فشار دادن بنویسید (مخصوصا اگر دکمه هایی با همین نام وجود دارد).

داده های آزمایش را درج کنید

اگر خطا مربوط به حساب شما است، داده‌های ورود به سیستم را ارائه دهید، و در گنجاندن بارهای آزمایشی که به بازتولید اشکال کمک می‌کنند، تردید نکنید.

دوباره مراحل خود را مرور کنید

گاهی اوقات، بلافاصله پس از مواجهه با باگ، مراحل را می نویسید، اما ممکن است مشخص شود که یک مرحله را برای درک کامل از دست داده اید یا این اشکال بعداً قابل تکرار نیست. در این صورت، ممکن است نیاز به یافتن مراحل دقیق تری باشد.

نتیجه مورد انتظار

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

نتیجه واقعی

در اینجا، می نویسیم که وقتی مراحل را دنبال کردیم واقعاً چه اتفاقی افتاد. ویژگی در اینجا نیز مهم است. فقط «همه چیز خراب شد» را ننویسید (حتی اگر احتمالاً این اتفاق افتاده است). شاخص هایی را که نشان می دهد همه چیز خراب است را توصیف کنید. به عنوان مثال:

در درخواست GET /accounts یک خطای 500 برگردانده می شود و رابط کاربری مسدود می شود. کاربر نمی تواند از صفحه خارج شود یا روی عناصر کلیک کند.

رفرش کردن صفحه دوباره درخواست را راه اندازی می کند و منجر به همان خطا می شود.

به عبارت دیگر، اثر واقعی و چگونگی تأثیر آن بر جریان کاربر را توصیف کنید.

فایل های اضافی

این یک بخش جداگانه است که قابل ذکر است. اینجا جایی است که شما اطلاعات اضافی را که اشکال را توصیف می کند، پیوست می کنید. من برخی از توسعه دهندگان را می شناسم که طرفدار خواندن مراحل بازتولید نیستند و مستقیماً به سراغ نتیجه واقعی و مطالب اضافی می روند.

اسکرین شات از خطا

یک بار دیدنش بهتر از صد بار شنیدن آن است. این یک راه عالی برای نشان دادن بصری آنچه اتفاق می افتد و کجاست. همیشه سعی کنید اسکرین شات را پیوست کنید.

درخواست کنید

اگر درخواستی وجود دارد که در آن خطا رخ داده است، باید همیشه در بلیط گنجانده شود. با این حال، درخواست ها شامل پارامترهای مختلفی هستند. من موارد زیر را به عنوان مهم برای گنجاندن برجسته می کنم:

• URL خطا – خود درخواست است که می توانید آن را از قسمت Network در مرورگری که آزمایش در آن انجام می شود دریافت کنید.

• روش - GET ، POST ، TRACE ، OPTION ، و غیره. روش‌های زیادی وجود دارد، درست مانند درخواست‌هایی با URL یکسان اما روش‌های متفاوت. فراموش نکنید که آن را در بلیط مشخص کنید.

• کد خطا - یک نکته مهم دیگر. احتمالاً آن را فراموش نخواهید کرد، اما فراموش نکنید که چه کدی از سرور بازگردانده شده است.

• Payload - این اطلاعاتی است که ما در درخواست خود به سرور ارسال کردیم. این در هر درخواستی وجود ندارد (به عنوان مثال، HEAD یا GET آن را ندارند)، اما ممکن است علت خطا باشد.

• پاسخ - پاسخ سرور. گاهی اوقات، حاوی خطای کامل است، حتی نشان می دهد که کجا رخ داده است، در حالی که گاهی اوقات این فقط یک مکان نگهدار پیش فرض است که در backend برای آن نوع خطا تنظیم شده است. مطمئن شوید که این مورد را لحاظ کنید—این باعث صرفه جویی در زمان توسعه دهنده می شود.

گزارش های کنسول

گاهی اوقات خطاهایی در کنسول پیدا می شود و می توان آنها را به بلیط اضافه کرد. شاید قبلاً این کار را انجام داده باشید، اما من فقط به این نکته اشاره می کنم که یک بلوک بزرگ از متن همیشه می تواند به عنوان یک فایل .log ذخیره شود و به بلیط اضافه شود. این خوانایی هر دو گزارش و خود بلیط را بهبود می بخشد.

این همه خوب است، اما ...

این همه خوب و خوب است، اما کجا می‌توانیم زمان پیدا کنیم تا همه چیز را به این زیبایی نشان دهیم؟ ضرب‌الاجل‌ها نزدیک است، مدیر عصبانی می‌شود، یک مسدودکننده در تولید وجود دارد، و از من می‌خواهند بنشینم و همه چیز را بنویسم؟ من فقط مستقیماً به توسعه دهنده پیام خواهم داد و تمام.

این یک استدلال منطقی است که ممکن است مطرح شود. من هیچ توهمی در مورد دنیای بی نقص یک تستر ندارم، جایی که زمان کافی برای آزمایش اختصاص داده می شود، همه چیز طبق روند پیش می رود و مستندات کامل و با کیفیت حفظ می شود. می‌دانم—اغلب وقت تنگی است، سوزش... خوب، چشم‌ها، و مسابقه‌ای برای انجام به موقع همه چیز.

خطاهای کوچک معمولاً روی هم انباشته می شوند، به دلیل تغییر زمینه زمان بیشتری می گیرند و منجر به اقدامات ضعیف می شوند. اگر شروع به اجرای تدریجی بهبودها و نظارت بر نحوه عملکرد آنها کنیم، می‌توانیم فرآیندی ایجاد کنیم که برای همه شرکت‌کنندگان پایدارتر، استانداردتر و قابل پیش‌بینی‌تر باشد.

مدیر پروژه متوجه خواهد شد که چه اتفاقی برای محصول می‌افتد بدون اینکه نیازی به جلب همه افراد برای به‌روزرسانی باشد، توسعه‌دهنده مجبور نیست از آزمایش‌کننده شفاف‌سازی در مورد شرایط تولید مثل بخواهد و آنها را از آزمایش دور نخواهد کرد، و ذینفعان نیز به نوبه خود، دید واضحی از پیشرفت محصول داشته باشید.

این مقاله بیشتر برای مبتدیانی است که راه خود را در آزمون شروع کرده اند یا قبلاً راه خود را آغاز کرده اند. من معتقدم که قدم‌های کوچک منجر به نتایج بزرگ می‌شوند و توصیه‌های این مقاله منجر به گزارش‌های باگ با کیفیت بالاتر می‌شود.

اگر سؤال، پیشنهاد، مخالفت یا شکایتی دارید، می‌توانید آن‌ها را در نظرات بنویسید - من علاقه مند به شنیدن نظر شما هستم!