اولویتبندی یک مشکل¶
BeeWare بهطور منظم گزارشهای مشکل را از کاربرانی که با مشکل مواجه هستند دریافت میکند. وقتی یک مشکل جدید گزارش میشود، آن گزارش نیاز به تriage دارد – یعنی باید کسی گزارش را بخواند، اطلاعات ارائهشده توسط گزارشدهنده را جمعآوری کند و تلاش کند تا مشکل توصیفشده را بازتولید کند.
متأسفانه، در حالی که گزارشهای مشکل معمولاً با نیت خیر تهیه میشوند، اغلب ناقص یا گیجکننده هستند. هدف از فرایند تریاژ پر کردن شکافهای گزارش اصلی است. این بدان معناست که یا باید جزئیات کافی ارائه دهیم تا بتوانیم تأیید کنیم مشکل چگونه قابل بازتولید است؛ یا باید تأیید کنیم که گزارشدهندهٔ اصلی در گزارش خود اشتباه کرده است.
اولویتبندی یک مشکل به این معنا نیست که انتظار میرود آن را رفع کنید. بسته به مشکل، ممکن است در فرایند اولویتبندی حتی نیازی به نوشتن کد نباشد. شما میتوانید یک مشکل را با دانش بسیار اندک از BeeWare اولویتبندی کنید، زیرا باید بتوانید مراحل ذکرشده در گزارش را دنبال کرده و مشکلی را که توصیف شده است بازتولید کنید.
اولویتبندی مسائل مشارکتشده¶
مشکل را بازتولید کنید
اگر در وهلهٔ اول مشکلی نداشته باشید، نمیتوانید آن را رفع کنید. بنابراین، بازتولید مشکل پیشنیاز رفع آن است. در نرمافزار، به مشکلات معمولاً «باگ» گفته میشود و به مسائل اغلب «گزارش باگ» گفته میشود.
کسی یک گزارش باگ ارائه کرده است. شما باید تأیید کنید که مراحلی که گزارشدهنده شرح داده است، واقعاً منجر به بروز باگ گزارششده میشود. آیا میتوانید با انجام دقیق آنچه در گزارش آمده است، همان نتیجه را بازتولید کنید؟ اگر نمیتوانید، باید بفهمید چرا.
باگها در کد¶
در یک وضعیت ایدهآل، شما همان پیکربندی را خواهید داشت که فرد گزارشدهنده باگ داشته است، مراحل را دنبال میکنید و قادر خواهید بود باگ را همانطور که توصیف شده بازتولید کنید. با این حال، در بسیاری از موارد، این کار آنقدرها هم ساده نخواهد بود. بسیاری از گزارشهای باگ تنها شامل توضیحات مبهم و مجموعهای مبهم از شرایط هستند. مشکل اینجاست که بسیاری از باگها بسته به مجموعهای از شرایط دخیل، از جمله نحوه تعامل با آنها، پیشنیازهای مختلف، سیستمعامل، نسخه سیستمعامل، معماری پردازنده، یا اینکه دستگاه کاربر قدیمی و کند است یا جدید و سریع، متفاوت هستند. هرچه اطلاعات بیشتری در مورد شرایط پیرامون باگ داشته باشیم، بهتر است. سعی کنید مجموعه شرایطی را که گزارشدهنده ارائه کرده است، بازتولید کنید. اگر نتوانستید این کار را انجام دهید، گام بعدی شما ممکن است درخواست اطلاعات بیشتر از شخصی باشد که باگ را گزارش کرده است.
بهترین روش برای بازتولید یک باگ، استفاده از کوچکترین مثالی است که همچنان مشکل را نشان دهد. در بیشتر موارد، گزارشدهندگان مثال حداقلی قابل قبولی ارائه نمیدهند؛ اگر هم هر مثالی ارائه کنند، مستقیماً از برنامهٔ «دنیای واقعی» خود کپی میکنند. هدف شما این است که گزارش را تا سادهترین شکلی که مشکل را نشان میدهد، کاهش دهید. بهترین مورد بازتولید، کوچکترین برنامه ممکن است. این کاهش خود به خود مفید است زیرا مشخص میکند که مشکل واقعی چیست. هر کسی میتواند مثال حداقلی را اجرا کند و باگی را که توصیف شده است مشاهده خواهد کرد.
اشتباهها در مستندات¶
باگها در مستندات میتوانند به روشهای مختلفی بروز کنند. مشکلات قالببندی وجود دارد که منجر به مشکلات نمایش میشود. گاهی حتی یک باگ هم نیست؛ ممکن است فرد مستندات را اشتباه خوانده باشد یا یک اشتباه واقعی مرتکب شده باشد. این لزوماً به معنای عدم وجود مشکل در مستندات نیست. ممکن است محتوا نامشخص یا مبهم باشد و جای سردرگمی یا سوءتعبیر را باز کند. ممکن است مفهومی که باید مورد بحث قرار گیرد، به دلیل عدم مستندسازی کامل، مطرح نشده باشد.
وقتی برای یک مشکل مستندسازی باگ ثبت میشود، باید بررسی کنید که مشکلی که گزارش شده هنوز وجود دارد یا خیر. در مورد مشکلات رندرینگ، باید مستندسازی را کامپایل کنید تا ببینید آیا میتوانید مشکل را بازتولید کنید یا خیر. مشکلات محتوا صرفاً با خواندن بررسی میشوند تا مطمئن شوید هیچکس بهروزرسانی ارسال نکرده است.
مسئله را بهروزرسانی کنید¶
آخرین مرحله در فرایند تریاژ، مستندسازی یافتههای شما با گذاشتن یک نظر در مورد مشکل است.
اگر میتوانید مشکل را دقیقاً همانطور که توضیح داده شده بازتولید کنید، همین کافی است. یک نظر بگذارید و بگویید که تأیید کردهاید دقیقاً همان مشکل را همانطور که گزارشدهندهٔ اصلی توضیح داده است مشاهده میکنید.
اگر میتوانید هرگونه زمینهٔ اضافی را ارائه دهید، جزئیات آن را درج کنید. این ممکن است شامل توانایی بازتولید مشکل در یک سیستمعامل دیگر، یا با نسخهٔ متفاوتی از برخی نرمافزارهای درگیر، یا هر چیز دیگری باشد که با گزارش اولیه متفاوت است.
اگر گزارش اصلی جزئیاتی را که برای بازتولید گزارش نیاز داشتید نداشت، آن جزئیات را اضافه کنید. این ممکن است شامل ارائه جزئیات سیستمعامل یا نسخه آن، لاگها یا ردپای استک کاملتر، یا دستورالعملهای واضحتر درباره توالی دقیق عملیات لازم برای بازتولید مشکل باشد. اگر راه سادهتری برای بازتولید مشکل پیدا کردهاید (یا گزارشدهنده اصلی مورد بازتولید را ارائه نکرده)، میتوانید جزئیات روش بازتولید را نیز درج کنید.
اگر نمیتوانید مشکل را بازتولید کنید، باز هم یک نظر بگذارید و توضیح دهید چه کارهایی انجام دادهاید. دانستن اینکه یک مشکل کجا وجود ندارد تقریباً به اندازه دانستن اینکه کجا وجود دارد مهم است، زیرا این به محدود کردن علل احتمالی کمک میکند. اگر نظریهای در مورد چرا نمیتوانید مشکل را بازتولید کنید دارید - برای مثال، اگر فکر میکنید این یک خطای کاربری است، یا اینکه مشکل با یک بهروزرسانی اخیر سیستمعامل حل شده است - آن گمانهزنی را به عنوان بخشی از نظرتان ذکر کنید.
در نهایت میتوانید هر پیشنهادی که دارید به تیم اصلی ارائه دهید. اگر فکر میکنید گزارش اصلی اشتباه است، پیشنهاد دهید که موضوع بسته شود؛ اگر نظریهای درباره علت مشکل دارید، میتوانید آن را نیز مطرح کنید. نظرات شما به تیم اصلی کمک میکند تا بفهمند چگونه موضوع را به مرحله بعدی برسانند.