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

یک باگ ممکن است در طول این مسیر وضعیت‌های مختلفی داشته باشد؛ برای مثال ابتدا در وضعیت New قرار بگیرد، سپس به فرد یا تیم مسئول اختصاص داده شود، در مرحله Fixed اصلاح‌شده اعلام شود و بعد توسط تستر در مرحله Retest بررسی شود. در نهایت، در صورت تأیید رفع مشکل، Bug می‌تواند Verified و سپس Closed شود.

به مجموعه این مراحل و تغییر وضعیت‌ها، چرخه عمر باگ (Bug Life Cycle) یا چرخه حیات باگ گفته می‌شود.

شناخت چرخه عمر باگ برای یک تستر اهمیت زیادی دارد؛ زیرا مسئولیت تستر فقط به پیدا کردن و ثبت باگ محدود نمی‌شود. تستر باید بتواند باگ را به‌درستی گزارش کند، وضعیت آن را پیگیری کند و پس از دریافت Fix، با انجام Retest و در صورت نیاز Regression Testing مشخص کند که مشکل واقعاً برطرف شده است یا خیر.

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

چرخه عمر باگ چیست؟

چرخه عمر باگ (Bug Life Cycle) به مجموعه مراحلی گفته می‌شود که یک باگ از زمان شناسایی و ثبت شدن تا بررسی، رفع، تست مجدد و تعیین تکلیف نهایی طی می‌کند.

اصطلاح Defect Life Cycle نیز برای همین مفهوم استفاده می‌شود و در بسیاری از منابع حرفه‌ای و استانداردهای تست نرم‌افزار، واژه Defect ترجیح داده می‌شود.

وقتی یک تستر باگی را پیدا می‌کند، این باگ معمولاً مستقیماً از مرحله «پیدا شدن» به «حل شدن» نمی‌رسد. ابتدا باید گزارش آن بررسی شود، مسئول رسیدگی به آن مشخص شود، Developer مشکل را تحلیل و اصلاح کند و سپس تستر بررسی کند که آیا مشکل واقعاً برطرف شده است یا خیر.

به همین دلیل، باگ در طول این فرآیند وضعیت‌های مختلفی (Bug Status) پیدا می‌کند.

یک مسیر رایج برای چرخه عمر باگ می‌تواند به شکل زیر باشد:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed

البته این مسیر در همه تیم‌ها دقیقاً یکسان نیست. بسته به فرآیند کاری تیم، ابزار مدیریت پروژه و Bug Workflow ممکن است Statusهای متفاوتی وجود داشته باشد یا بعضی از مراحل با یکدیگر ترکیب شوند.

چرا Bug Life Cycle اهمیت دارد؟

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

بنابراین، Bug Life Cycle فقط مجموعه‌ای از Statusها نیست؛ بلکه روشی برای پیگیری و مدیریت یک مشکل نرم‌افزاری از زمان شناسایی تا تعیین تکلیف نهایی آن است.

مراحل چرخه عمر باگ

New؛ ثبت باگ

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

وضعیت New به این معناست که باگ تازه گزارش شده و هنوز توسط فرد یا تیم مسئول بررسی و تعیین تکلیف نشده است.

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

تستر این مشکل را به‌عنوان یک Bug Report ثبت می‌کند و Bug در ابتدا در وضعیت New قرار می‌گیرد.

تستر هنگام ثبت Bug چه اطلاعاتی ارائه می‌کند؟

یک Bug Report مناسب باید اطلاعات کافی برای درک و بازتولید مشکل (Reproduce) در اختیار تیم قرار دهد. بسته به ابزار و فرآیند تیم، معمولاً اطلاعاتی مانند موارد زیر ثبت می‌شود:

  • Title: عنوان کوتاه و دقیق Bug
  • Description: توضیح مشکل
  • Steps to Reproduce: مراحل بازتولید مشکل
  • Expected Result: نتیجه مورد انتظار
  • Actual Result: نتیجه واقعی
  • Environment: محیطی که Bug در آن مشاهده شده است
  • Severity: میزان شدت و تأثیر Bug
  • Priority: میزان اولویت رسیدگی به Bug
  • Attachment: در صورت نیاز، Screenshot، Video، Log یا سایر شواهد

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

آیا هر چیزی که تستر گزارش می‌کند حتماً Bug است؟

خیر. بعد از ثبت Bug، تیم باید آن را بررسی کند تا مشخص شود گزارش واقعاً یک Bug معتبر است یا خیر. ممکن است مشخص شود مشکل قبلاً گزارش شده، رفتار مشاهده‌شده مطابق Requirement بوده یا اطلاعات کافی برای بازتولید مشکل وجود ندارد.

بنابراین New صرفاً نشان می‌دهد که یک گزارش جدید ثبت شده است؛ هنوز درباره معتبر بودن یا نحوه رسیدگی به آن تصمیم نهایی گرفته نشده است.

Assigned؛ واگذاری باگ

بعد از اینکه یک باگ ثبت و بررسی اولیه شد، باید مشخص شود چه فرد یا تیمی مسئول بررسی و رفع آن است. در این مرحله، Bug معمولاً به یک Developer یا تیم توسعه اختصاص داده می‌شود و وضعیت آن به Assigned تغییر می‌کند.

Assigned یعنی مسئول رسیدگی به Bug مشخص شده است؛ اما این وضعیت لزوماً به این معنی نیست که Developer کار روی Bug را شروع کرده است.

برای مثال، اگر مشخص شود یک مشکل مربوط به بخش Frontend است، Bug می‌تواند به Developer مربوطه Assign شود:

New → Assigned

از این مرحله، مسئول پیگیری Bug مشخص است و Developer می‌تواند بررسی آن را آغاز کند.

آیا هر Bug باید مستقیماً به Developer Assign شود؟

الزاماً نه. نحوه Assign کردن Bug به Workflow و ساختار تیم بستگی دارد. در بعضی تیم‌ها Bug ابتدا به QA Lead، Team Lead یا Product Owner اختصاص داده می‌شود تا بررسی و اولویت‌بندی شود و سپس به Developer مربوطه واگذار شود.

همچنین ممکن است یک Bug ابتدا وارد وضعیت Open یا In Progress شود و سپس فرد مسئول آن مشخص شود.

بنابراین نباید تصور کرد که Assigned یک مرحله کاملاً ثابت و اجباری در تمام تیم‌هاست. نام Statusها و ترتیب آن‌ها می‌تواند بین تیم‌ها و ابزارهای مختلف متفاوت باشد.

پس از مشخص شدن مسئول Bug، معمولاً فرآیند بررسی و کار روی آن آغاز می‌شود و Bug وارد مرحله Open / In Progress خواهد شد.

Open / In Progress؛ بررسی و رفع باگ

بعد از اینکه Bug به فرد یا تیم مسئول واگذار شد، Developer بررسی مشکل را آغاز می‌کند. در بسیاری از تیم‌ها در این مرحله وضعیت Bug به Open یا In Progress تغییر می‌کند.

این دو Status در همه تیم‌ها دقیقاً یک معنی ندارند، اما معمولاً نشان می‌دهند که Bug دیگر صرفاً منتظر رسیدگی نیست و فرآیند بررسی یا کار روی آن آغاز شده است.

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

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

اگر Bug قابل بازتولید باشد و نیاز به اصلاح داشته باشد، Developer تغییرات لازم را در نرم‌افزار اعمال می‌کند.

آیا ممکن است Bug در این مرحله رد شود؟

بله. بررسی Developer یا تیم مسئول ممکن است نشان دهد که گزارش اولیه نیاز به تغییر وضعیت دیگری دارد. برای مثال:

  • Duplicate: این Bug قبلاً گزارش شده است.
  • Not a Bug: رفتار مشاهده‌شده مطابق Requirement یا طراحی سیستم است.
  • Cannot Reproduce: تیم نمی‌تواند مشکل را با اطلاعات موجود بازتولید کند.
  • Won’t Fix: تیم تصمیم گرفته است در شرایط فعلی Bug را برطرف نکند.

بنابراین مسیر Bug همیشه خطی نیست و ممکن است در طول فرآیند، بر اساس نتیجه بررسی‌ها به وضعیت دیگری منتقل شود.

چه زمانی Bug به Fixed می‌رسد؟

اگر Developer علت مشکل را پیدا کند و تغییرات لازم را برای رفع آن انجام دهد، معمولاً Bug به وضعیت Fixed یا Resolved منتقل می‌شود.

اما یک نکته مهم وجود دارد: Fixed به معنی بسته‌شدن Bug نیست.

در این مرحله Developer اعلام کرده است که اصلاح لازم را انجام داده و انتظار دارد مشکل برطرف شده باشد. حالا تستر باید این Fix را بررسی کند.

بنابراین مسیر می‌تواند به شکل زیر ادامه پیدا کند:

In Progress → Fixed → Retest

در بخش بعدی، مفهوم Fixed / Resolved و سپس مرحله Retest را دقیق‌تر بررسی می‌کنیم.

Fixed / Resolved؛ اعلام رفع باگ

بعد از اینکه Developer علت مشکل را پیدا کرد و تغییرات لازم را در نرم‌افزار اعمال کرد، معمولاً وضعیت Bug به Fixed یا Resolved تغییر می‌کند.

این وضعیت نشان می‌دهد که از دید Developer، اصلاح لازم انجام شده و انتظار می‌رود مشکل برطرف شده باشد.

برای مثال، در Bug مربوط به سبد خرید، Developer ممکن است کد مربوط به به‌روزرسانی تعداد محصولات را اصلاح کند و سپس وضعیت Bug را به Fixed تغییر دهد.

مسیر تا این مرحله می‌تواند به شکل زیر باشد:

New → Assigned → In Progress → Fixed

اما نکته مهم این است که Fixed به معنی تأیید نهایی Bug نیست.

Developer با تغییر وضعیت به Fixed در واقع اعلام می‌کند که تغییرات لازم را انجام داده و انتظار دارد مشکل برطرف شده باشد. حالا تستر باید این موضوع را با انجام Retest بررسی کند.

آیا بعد از Fixed باید Bug را ببندیم؟

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

اگر تستر مشکل را دیگر مشاهده نکند، Bug می‌تواند به مرحله بعدی مانند Verified منتقل شود. اگر مشکل همچنان وجود داشته باشد، Bug معمولاً Reopened می‌شود.

بنابراین دو مسیر اصلی ممکن است ایجاد شود:

Fixed → Retest → Verified

یا:

Fixed → Retest → Reopened

Fixed و Resolved چه تفاوتی دارند؟

در برخی ابزارها و Workflowها به جای Fixed از Resolved استفاده می‌شود. همچنین ممکن است این دو Status در یک تیم معنای متفاوتی داشته باشند.

بنابراین نباید فقط بر اساس نام Status قضاوت کرد؛ باید Workflow تعریف‌شده در همان تیم یا پروژه را در نظر گرفت.

نکته اصلی این است که در این مرحله، Developer اعلام می‌کند مشکل برطرف شده و تأیید نهایی رفع Bug هنوز انجام نشده است. این موضوع در مرحله Retest توسط تستر بررسی می‌شود.

Retest؛ تست مجدد باگ

بعد از اینکه Developer وضعیت Bug را به Fixed یا Resolved تغییر داد، نوبت تستر است که اصلاح انجام‌شده را بررسی کند. این مرحله معمولاً با عنوان Retest یا تست مجدد شناخته می‌شود.

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

Retest چگونه انجام می‌شود؟

تستر معمولاً بر اساس Steps to Reproduce که در Bug Report ثبت شده است، مراحل ایجاد مشکل را دوباره اجرا می‌کند و نتیجه را با وضعیت قبلی مقایسه می‌کند.

برای مثال، فرض کنید تستر گزارش کرده است که با کلیک روی دکمه پرداخت، هیچ اتفاقی رخ نمی‌دهد. Developer این مشکل را اصلاح کرده و Bug را به وضعیت Fixed منتقل می‌کند.

در Retest، تستر دوباره همان مراحل را انجام می‌دهد:

  • ورود به حساب کاربری
  • اضافه کردن محصول به سبد خرید
  • رفتن به صفحه پرداخت
  • کلیک روی دکمه پرداخت
  • بررسی نتیجه

اگر این بار فرآیند پرداخت به‌درستی انجام شود، تستر می‌تواند Fix را تأیید کند.

اگر Bug همچنان وجود داشته باشد چه می‌شود؟

اگر تستر در Retest متوجه شود که مشکل همچنان وجود دارد، Bug معمولاً به وضعیت Reopened تغییر می‌کند و دوباره برای بررسی و رفع به Developer یا تیم مسئول برمی‌گردد.

در این حالت، مسیر می‌تواند به شکل زیر باشد:

Fixed → Retest → Reopened → In Progress → Fixed → Retest

این چرخه ممکن است تا زمانی ادامه پیدا کند که Bug به‌درستی برطرف و توسط تستر تأیید شود.

Retest با Regression Testing یکی نیست

یکی از اشتباهات رایج این است که Retest و Regression Testing را یکسان در نظر بگیریم.

در Retest، تمرکز اصلی روی همان Bug گزارش‌شده و بررسی Fix آن است؛ اما Regression Testing با هدف بررسی این موضوع انجام می‌شود که تغییرات جدید باعث ایجاد مشکل در بخش‌های دیگری از نرم‌افزار نشده باشند.

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

اگر Retest موفق باشد، Bug می‌تواند وارد مرحله Verified شود.

Verified؛ تأیید رفع باگ

اگر Retest با موفقیت انجام شود و تستر تأیید کند که Bug گزارش‌شده برطرف شده است، در برخی Workflowها وضعیت Bug به Verified تغییر می‌کند.

در این مرحله، تفاوت مهمی میان Fixed و Verified وجود دارد. در Fixed، Developer اعلام می‌کند که مشکل را برطرف کرده است؛ اما در Verified، تستر این Fix را بررسی کرده و برطرف‌شدن مشکل را تأیید کرده است.

بنابراین می‌توان این دو مرحله را به شکل زیر در نظر گرفت:

Developer: Fixed → Tester: Verified

Verified به چه معناست؟

Verified یعنی تستر با اجرای Retest به این نتیجه رسیده است که مشکل گزارش‌شده دیگر در شرایط مورد بررسی مشاهده نمی‌شود و Fix انجام‌شده مورد تأیید قرار گرفته است.

البته وجود Status با نام Verified در همه تیم‌ها الزامی نیست. در بعضی Workflowها، بعد از Retest موفق، Bug مستقیماً به Closed منتقل می‌شود.

Closed؛ بسته شدن باگ

وقتی Fix توسط تستر تأیید شد و دیگر نیازی به اقدام دیگری روی Bug وجود نداشت، Bug می‌تواند به وضعیت Closed منتقل شود.

Closed معمولاً به این معناست که Bug از نظر Workflow تیم به پایان رسیده و دیگر در حالت فعال قرار ندارد.

بنابراین یک مسیر معمول برای Bug می‌تواند به شکل زیر باشد:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed

با این حال، این مسیر یک الگوی رایج است و نباید آن را یک Workflow اجباری و یکسان برای تمام تیم‌ها در نظر گرفت. نام Statusها و ترتیب آن‌ها ممکن است بر اساس فرآیند تیم و ابزار مدیریت پروژه متفاوت باشد.

اگر بعد از Closed دوباره مشکل مشاهده شود چه؟

اگر همان مشکل پس از بسته‌شدن Bug دوباره مشاهده شود، بسته به Workflow تیم ممکن است Bug دوباره Reopened شود یا برای آن یک Bug جدید ثبت شود. تصمیم‌گیری در این مورد به این بستگی دارد که آیا با همان مشکل قبلی مواجه هستیم یا با یک مشکل جدید.

در ادامه، وضعیت‌هایی را بررسی می‌کنیم که باعث می‌شوند چرخه عمر Bug از مسیر معمول خود خارج شود؛ مانند Reopened، Duplicate، Not a Bug و Cannot Reproduce.

وضعیت‌های غیرخطی در چرخه عمر باگ

چرخه عمر Bug همیشه از مسیر مستقیم New → Assigned → In Progress → Fixed → Retest → Verified → Closed عبور نمی‌کند. در طول بررسی یا Retest ممکن است مشخص شود که شرایط Bug با چیزی که در ابتدا تصور می‌شد متفاوت است و در نتیجه، وضعیت آن تغییر کند.

Reopened؛ بازگشایی باگ

اگر تستر در مرحله Retest متوجه شود که مشکل هنوز وجود دارد یا Fix انجام‌شده مشکل را به‌طور کامل برطرف نکرده است، Bug می‌تواند به وضعیت Reopened منتقل شود.

برای مثال، اگر Bug مربوط به دکمه پرداخت پس از Fix همچنان قابل مشاهده باشد، تستر نباید صرفاً Bug را ببندد؛ بلکه باید آن را Reopen کند تا دوباره بررسی و اصلاح شود.

مسیر در این حالت می‌تواند به شکل زیر باشد:

Fixed → Retest → Reopened → In Progress → Fixed → Retest

Duplicate؛ باگ تکراری

گاهی تستر یا تیم بررسی متوجه می‌شود که مشکل گزارش‌شده قبلاً در سیستم ثبت شده است. در این شرایط، Bug جدید ممکن است به عنوان Duplicate علامت‌گذاری شود.

هدف از این کار جلوگیری از ایجاد چند گزارش برای یک مشکل و متمرکز نگه‌داشتن پیگیری Bug در یک گزارش اصلی است.

Not a Bug؛ رفتار مورد انتظار سیستم

ممکن است چیزی که تستر به عنوان Bug گزارش کرده است، در واقع مطابق Requirement، طراحی یا رفتار مورد انتظار سیستم باشد. در این حالت Bug ممکن است با وضعیتی مانند Not a Bug بسته یا از چرخه رفع خارج شود.

برای جلوگیری از چنین وضعیتی، تستر باید هنگام گزارش Bug، رفتار مشاهده‌شده را با Requirement، Acceptance Criteria یا سایر منابع معتبر مقایسه کند.

Cannot Reproduce؛ عدم امکان بازتولید باگ

گاهی تیم نمی‌تواند مشکلی را که تستر گزارش کرده است با اطلاعات و شرایط موجود دوباره ایجاد کند. در این حالت ممکن است Bug به وضعیت Cannot Reproduce منتقل شود.

در چنین شرایطی، اطلاعات دقیق موجود در Bug Report اهمیت زیادی پیدا می‌کند؛ زیرا مواردی مانند Steps to Reproduce، نسخه نرم‌افزار، Browser، Operating System، Environment و شواهدی مانند Screenshot یا Video می‌توانند به بازتولید مشکل کمک کنند.

اگر بعداً اطلاعات جدیدی به دست آید و Bug قابل بازتولید شود، بسته به Workflow تیم ممکن است دوباره بررسی و فعال شود.

بنابراین Bug Life Cycle را بهتر است یک Workflow قابل تغییر در نظر بگیریم، نه یک مسیر کاملاً خطی و ثابت.

مثال کامل از چرخه عمر یک باگ

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

1. New؛ ثبت باگ

تستر مشکل را بررسی می‌کند، مطمئن می‌شود که رفتار مشاهده‌شده با Requirement یا رفتار مورد انتظار سیستم مطابقت ندارد و سپس Bug Report را در ابزار مدیریت پروژه ثبت می‌کند.

Bug در این مرحله معمولاً در وضعیت New قرار دارد.

2. Assigned؛ واگذاری باگ

پس از بررسی اولیه، Bug به Developer یا تیم مسئول مربوطه واگذار می‌شود و وضعیت آن به Assigned تغییر می‌کند.

3. In Progress؛ بررسی و رفع مشکل

Developer مراحل بازتولید مشکل را اجرا می‌کند، علت آن را بررسی می‌کند و تغییرات لازم را برای رفع Bug انجام می‌دهد. در این مرحله وضعیت Bug می‌تواند In Progress باشد.

4. Fixed؛ اعلام رفع باگ

بعد از اعمال تغییرات، Developer اعلام می‌کند که مشکل برطرف شده است و Bug را به وضعیت Fixed منتقل می‌کند.

5. Retest؛ تست مجدد

تستر دوباره همان سناریویی را که باعث ایجاد Bug شده بود اجرا می‌کند. در این مثال، محصول را به سبد خرید اضافه می‌کند و بررسی می‌کند که آیا محصول اکنون به‌درستی به سبد اضافه می‌شود یا خیر.

6. Verified؛ تأیید Fix

اگر تستر تأیید کند که مشکل برطرف شده است، Bug در Workflowهایی که این Status را دارند به Verified منتقل می‌شود.

7. Closed؛ بسته شدن باگ

در نهایت، اگر اقدام دیگری لازم نباشد، Bug به وضعیت Closed منتقل می‌شود و چرخه آن به پایان می‌رسد.

اگر Fix موفق نباشد چه اتفاقی می‌افتد؟

فرض کنید تستر در مرحله Retest متوجه شود که محصول همچنان به سبد خرید اضافه نمی‌شود. در این حالت Bug تأیید نمی‌شود و معمولاً به وضعیت Reopened برمی‌گردد.

در نتیجه، چرخه می‌تواند دوباره ادامه پیدا کند:

Reopened → In Progress → Fixed → Retest

این چرخه تا زمانی ادامه پیدا می‌کند که مشکل به‌درستی برطرف و توسط تستر تأیید شود.

در نتیجه، یک نمونه کامل از مسیر معمول Bug را می‌توان به شکل زیر خلاصه کرد:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed

تفاوت Bug Status، Severity و Priority

یکی از نکات مهم در مدیریت Bug این است که Status، Severity و Priority سه مفهوم متفاوت هستند و نباید آن‌ها را با یکدیگر اشتباه گرفت.

Bug Status؛ وضعیت باگ

Status نشان می‌دهد Bug در چه مرحله‌ای از Workflow قرار دارد و در حال حاضر چه اتفاقی برای آن در حال انجام است.

برای مثال:

  • New
  • Assigned
  • In Progress
  • Fixed
  • Retest
  • Verified
  • Closed
  • Reopened

بنابراین Status درباره مرحله و وضعیت فعلی Bug صحبت می‌کند.

Severity؛ شدت یا میزان تأثیر باگ

Severity نشان می‌دهد Bug تا چه اندازه روی عملکرد سیستم یا تجربه کاربر تأثیر دارد.

برای مثال، یک Bug که باعث Crash شدن کل سیستم می‌شود، معمولاً Severity بالاتری نسبت به مشکلی دارد که فقط ظاهر یک دکمه را کمی به‌هم ریخته است.

بنابراین Severity بیشتر به Impact یا میزان اثرگذاری مشکل مربوط است.

Priority؛ اولویت رسیدگی

Priority مشخص می‌کند که Bug با چه میزان اولویتی باید بررسی و برطرف شود.

Priority می‌تواند بر اساس عواملی مانند اهمیت قابلیت برای کسب‌وکار، تعداد کاربران تحت تأثیر، زمان انتشار نسخه و سایر نیازهای پروژه تعیین شود.

یک مثال ساده برای تفاوت این سه مفهوم

فرض کنید یک Bug باعث شده دکمه پرداخت در صفحه Checkout کار نکند.

  • Status: Fixed؛ Developer اعلام کرده مشکل برطرف شده و منتظر Retest است.
  • Severity: بالا؛ چون کاربران نمی‌توانند خرید خود را کامل کنند.
  • Priority: بالا؛ چون این مشکل مستقیماً روی فرآیند خرید و درآمد کسب‌وکار تأثیر می‌گذارد.

همان Bug می‌تواند در طول چرخه عمر خود Statusهای مختلفی داشته باشد، در حالی که Severity و Priority آن لزوماً با هر تغییر Status تغییر نمی‌کنند.

به زبان ساده:

  • Status: الان Bug در چه مرحله‌ای است؟
  • Severity: Bug چقدر جدی و تأثیرگذار است؟
  • Priority: رسیدگی به Bug چقدر باید در اولویت باشد؟

نقش تستر در چرخه عمر باگ

تستر در Bug Life Cycle فقط وظیفه پیدا کردن و گزارش کردن Bug را ندارد. از زمان شناسایی مشکل تا Retest و تأیید Fix، تستر در بخش‌های مختلف این فرآیند نقش مهمی دارد.

1. شناسایی و بررسی اولیه Bug

اولین قدم این است که تستر بررسی کند آیا رفتار مشاهده‌شده واقعاً یک Bug است یا خیر. برای این کار، باید رفتار سیستم را با Requirement، Acceptance Criteria، طراحی یا سایر منابع معتبر مقایسه کند.

2. ثبت Bug Report با اطلاعات کافی

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

یک Bug Report مناسب معمولاً شامل عنوان واضح، توضیح مشکل، Steps to Reproduce، Expected Result، Actual Result، Environment و شواهدی مانند Screenshot یا Video است.

3. همکاری در بررسی و رفع Bug

پس از ثبت Bug، ممکن است Developer یا سایر اعضای تیم درباره شرایط ایجاد مشکل، Requirement یا شواهد ارائه‌شده سؤال‌هایی داشته باشند. تستر باید اطلاعات لازم را در اختیار تیم قرار دهد و در صورت نیاز در بررسی مشکل همکاری کند.

4. انجام Retest

پس از اعلام Fix توسط Developer، تستر باید Bug را Retest کند و بررسی کند که آیا همان مشکل واقعاً برطرف شده است یا خیر.

5. تصمیم‌گیری درباره نتیجه Fix

اگر Retest موفق باشد، تستر Fix را تأیید می‌کند و Bug می‌تواند به مرحله بعدی Workflow مانند Verified یا Closed منتقل شود.

اگر مشکل همچنان وجود داشته باشد، تستر باید نتیجه را مستند کند و بسته به Workflow تیم، Bug را Reopened کند یا آن را برای بررسی بیشتر به تیم مربوطه برگرداند.

6. بررسی اثر تغییرات بر بخش‌های مرتبط

رفع یک Bug ممکن است روی بخش‌های دیگری از نرم‌افزار تأثیر بگذارد. به همین دلیل، در صورت نیاز تستر باید علاوه بر Retest، تست‌های مرتبط یا Regression Testing را نیز انجام دهد.

در نتیجه، نقش تستر در Bug Life Cycle را می‌توان به شکل زیر خلاصه کرد:

  • شناسایی و بررسی Bug
  • ثبت Bug Report دقیق و قابل بازتولید
  • همکاری با تیم در بررسی مشکل
  • انجام Retest پس از Fix
  • تأیید یا Reopen کردن Bug بر اساس نتیجه تست
  • انجام تست‌های مرتبط و Regression Testing در صورت نیاز

چرخه عمر باگ در ابزارهای مدیریت پروژه

در پروژه‌های واقعی، Bug Life Cycle معمولاً داخل ابزارهای مدیریت پروژه و Issue Tracking مانند Jira، Azure DevOps یا سایر ابزارهای مشابه مدیریت می‌شود. در این ابزارها، هر Bug دارای یک Workflow است که مشخص می‌کند چه Statusهایی دارد و از چه مسیری می‌تواند عبور کند.

Workflow باگ چگونه تعریف می‌شود؟

Workflow مشخص می‌کند که یک Bug از زمان ثبت تا پایان فرآیند چه وضعیت‌هایی را می‌تواند تجربه کند و چه کسی یا چه رویدادی باعث تغییر Status آن می‌شود.

برای مثال، یک تیم ممکن است Workflow زیر را داشته باشد:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed

تیم دیگری ممکن است Statusهایی مانند Open، Resolved یا Ready for Test را نیز در Workflow خود استفاده کند.

بنابراین نام Statusها و ترتیب آن‌ها در همه پروژه‌ها یکسان نیست و تستر باید Workflow تعریف‌شده در همان پروژه را بشناسد.

تغییر Status با چه چیزی انجام می‌شود؟

تغییر Status معمولاً بر اساس اتفاقی که برای Bug رخ داده است انجام می‌شود. برای مثال:

  • تستر Bug جدیدی ثبت می‌کند → New
  • Bug به Developer واگذار می‌شود → Assigned
  • Developer کار روی Bug را شروع می‌کند → In Progress
  • Developer اعلام می‌کند مشکل برطرف شده است → Fixed
  • تستر Fix را بررسی می‌کند → Retest
  • تستر Fix را تأیید می‌کند → Verified
  • فرآیند Bug به پایان می‌رسد → Closed

آیا Workflow همه تیم‌ها یکسان است؟

خیر. Bug Life Cycle یک مفهوم عمومی است، اما Workflow دقیق آن می‌تواند بین تیم‌ها و پروژه‌های مختلف متفاوت باشد.

برای مثال، یک تیم ممکن است مرحله Verified را نداشته باشد و بعد از Retest موفق، Bug مستقیماً به Closed منتقل شود. تیم دیگری ممکن است مراحل بیشتری مانند Ready for Test یا Reopened داشته باشد.

بنابراین مهم‌تر از حفظ کردن نام Statusها، درک منطق پشت Workflow است؛ یعنی بدانیم Bug در هر مرحله چه وضعیتی دارد، چه کسی مسئول اقدام بعدی است و چه شرایطی باعث انتقال آن به مرحله بعد می‌شود.

اشتباهات رایج در مدیریت چرخه عمر باگ

شناخت Bug Life Cycle فقط به حفظ کردن نام Statusها محدود نمی‌شود. در عمل، برخی اشتباهات در ثبت، پیگیری و Retest باگ‌ها می‌توانند باعث اتلاف زمان و ایجاد ابهام در تیم شوند.

1. بستن باگ بدون انجام Retest

یکی از اشتباهات رایج این است که بعد از اعلام Fixed توسط Developer، Bug بدون بررسی تستر مستقیماً بسته شود.

تستر باید در صورت نیاز Retest انجام دهد و قبل از Close شدن Bug، برطرف‌شدن مشکل را بررسی کند.

2. Reopen کردن باگ برای یک مشکل کاملاً جدید

هر مشکلی که بعد از Fix مشاهده می‌شود الزاماً همان Bug قبلی نیست. اگر مشکل جدیدی ایجاد شده باشد، بهتر است در صورت نیاز یک Bug جدید برای آن ثبت شود، نه اینکه صرفاً Bug قبلی Reopen شود.

3. گزارش Bug بدون اطلاعات کافی

اگر Bug Report فاقد اطلاعاتی مانند Steps to Reproduce، Expected Result، Actual Result، Environment یا شواهد کافی باشد، بازتولید و بررسی مشکل برای سایر اعضای تیم دشوارتر می‌شود.

4. اشتباه گرفتن Severity و Priority

Severity و Priority دو مفهوم متفاوت هستند. Severity میزان تأثیر یا شدت Bug را توصیف می‌کند، در حالی که Priority نشان می‌دهد رسیدگی به آن با چه اولویتی باید انجام شود.

5. در نظر گرفتن Bug Life Cycle به عنوان یک مسیر کاملاً ثابت

ممکن است Workflow یک تیم با تیم دیگر متفاوت باشد. بنابراین نباید تصور کرد که همه پروژه‌ها دقیقاً از Statusهای یکسان و با همان ترتیب استفاده می‌کنند.

مهم این است که تستر منطق Workflow پروژه را بداند و تشخیص دهد در هر مرحله چه اقدامی باید انجام شود.

6. انجام Retest بدون بررسی شرایط Fix

تستر باید بداند چه چیزی تغییر کرده و در چه شرایطی Fix شده است. Retest باید تا حد امکان با شرایط مناسب و قابل مقایسه با شرایط ایجاد Bug انجام شود تا نتیجه قابل اعتماد باشد.

در نهایت، یک Bug Report خوب، Workflow مشخص و ارتباط مناسب بین Tester و Developer می‌تواند بخش زیادی از مشکلات مربوط به مدیریت Bugها را کاهش دهد.

جمع‌بندی چرخه عمر باگ

Bug Life Cycle مسیر و فرآیندی است که یک Bug از زمان شناسایی و ثبت تا بررسی، رفع، Retest و در نهایت بسته‌شدن طی می‌کند.

یک مسیر رایج برای چرخه عمر Bug می‌تواند به شکل زیر باشد:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed

با این حال، این مسیر یک استاندارد اجباری و یکسان برای تمام تیم‌ها نیست. هر تیم ممکن است بر اساس فرآیند کاری و ابزار مورد استفاده، Statusها و Workflow متفاوتی داشته باشد.

همچنین چرخه عمر Bug همیشه خطی نیست. ممکن است Bug در طول فرآیند به وضعیت‌هایی مانند Reopened، Duplicate، Not a Bug یا Cannot Reproduce منتقل شود.

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

در نهایت، هدف Bug Life Cycle این نیست که فقط یک Bug را از یک Status به Status دیگر منتقل کنیم؛ بلکه هدف اصلی، پیگیری مؤثر مشکل تا رسیدن به یک نتیجه قابل اعتماد برای تیم و محصول است.

منابع و مراجع

سؤالات متداول درباره چرخه عمر باگ

چرخه عمر باگ یا Bug Life Cycle چیست؟

Bug Life Cycle به مسیر و فرآیندی گفته می‌شود که یک Bug از زمان شناسایی و ثبت تا بررسی، رفع، Retest، تأیید و در نهایت بسته‌شدن طی می‌کند.

مراحل اصلی Bug Life Cycle چیست؟

یک مسیر رایج شامل New → Assigned → In Progress → Fixed → Retest → Verified → Closed است. البته Workflow دقیق می‌تواند در تیم‌ها و پروژه‌های مختلف متفاوت باشد.

آیا Bug Life Cycle یک استاندارد ثابت است؟

خیر. Bug Life Cycle یک مفهوم عمومی در Software Testing و مدیریت Defect است، اما Statusها و ترتیب آن‌ها می‌تواند بر اساس فرآیند هر تیم، پروژه و ابزار مدیریت Bug متفاوت باشد.

تفاوت Fixed و Verified چیست؟

Fixed معمولاً یعنی Developer اعلام کرده است که مشکل را برطرف کرده است؛ در حالی که Verified یعنی تستر Fix انجام‌شده را بررسی کرده و برطرف‌شدن Bug را تأیید کرده است.

اگر Bug بعد از Retest همچنان وجود داشته باشد چه می‌شود؟

اگر همان مشکل همچنان وجود داشته باشد، Bug معمولاً به وضعیت Reopened منتقل می‌شود تا دوباره بررسی و اصلاح شود.

تفاوت Retest و Regression Testing چیست؟

Retest برای بررسی همان Bug و تأیید Fix آن انجام می‌شود؛ اما Regression Testing با هدف بررسی این موضوع انجام می‌شود که تغییرات جدید باعث ایجاد مشکل در بخش‌های دیگر نرم‌افزار نشده باشند.

تفاوت Bug Status، Severity و Priority چیست؟

Status مرحله فعلی Bug در Workflow را نشان می‌دهد، Severity میزان شدت یا تأثیر مشکل را بیان می‌کند و Priority میزان اولویت رسیدگی به آن را مشخص می‌کند.

آیا تستر مسئول بستن Bug است؟

این موضوع به Workflow تیم بستگی دارد. در برخی تیم‌ها تستر پس از Retest موفق Bug را به Verified یا Closed منتقل می‌کند؛ در برخی دیگر، بسته‌شدن نهایی توسط فرد یا نقش دیگری انجام می‌شود.

طبقه بندی شده در:

دسته‌بندی نشده,

اخرین بروزرسانی: شهریور 22, 1405