Retesting چیست؟ تفاوت تست مجدد و Regression Testing

پیدا کردن یک Bug همیشه پایان کار تستر نیست. پس از ثبت گزارش Bug، توسعه‌دهنده ممکن است مشکل را برطرف کند؛ اما سؤال مهم این است: از کجا مطمئن شویم که Bug واقعاً رفع شده است؟

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

Retesting یکی از فعالیت‌های رایج در فرآیند تست نرم‌افزار و چرخه رفع Bug است. با این حال، این مفهوم گاهی با Regression Testing اشتباه گرفته می‌شود؛ در حالی که هدف و محدوده این دو نوع تست یکسان نیست.

در این مقاله، ابتدا مفهوم Retesting را بررسی می‌کنیم، سپس نحوه انجام آن و تفاوت آن با Regression Testing را با مثال‌های ساده توضیح می‌دهیم.

Retesting چیست؟

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

در Retesting، تمرکز اصلی روی همان مشکلی است که قبلاً شناسایی و گزارش شده است. تستر معمولاً با استفاده از همان Steps to Reproduce و شرایط مشابه، سناریو را دوباره اجرا می‌کند و نتیجه جدید را با نتیجه مورد انتظار مقایسه می‌کند.

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

بنابراین می‌توان Retesting را به‌صورت ساده این‌گونه خلاصه کرد:

Bug → Fix → Retest → Verify یا Reopen

یک مثال ساده از Retesting

فرض کنید در یک فروشگاه اینترنتی، تستر متوجه می‌شود که با کلیک روی دکمه Add to Cart، محصول به سبد خرید اضافه نمی‌شود.

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

• وارد صفحه محصول می‌شود.
• روی Add to Cart کلیک می‌کند.
• سبد خرید را بررسی می‌کند.

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

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

Retesting معمولاً بعد از اعلام رفع یک Bug توسط توسعه‌دهنده انجام می‌شود. تستر برای اطمینان از رفع مشکل، سناریوی مربوط به Bug را دوباره اجرا می‌کند.

فرآیند را می‌توان به شکل زیر خلاصه کرد:

1. گزارش Bug: تستر مشکل را شناسایی و با اطلاعات لازم گزارش می‌کند.
2. رفع Bug: توسعه‌دهنده مشکل را بررسی و اصلاح می‌کند.
3. ارائه نسخه جدید: نسخه‌ای که اصلاحات در آن اعمال شده، برای تست در اختیار تستر قرار می‌گیرد.
4. اجرای مجدد تست: تستر همان سناریوی قبلی را دوباره اجرا می‌کند و تا حد امکان شرایط تست را مشابه قبل نگه می‌دارد.
5. ثبت نتیجه: نتیجه Retesting ثبت می‌شود و بر اساس آن Bug تأیید یا دوباره باز می‌شود.

اگر Bug رفع شده باشد چه می‌شود؟

اگر تستر نتواند مشکل قبلی را دوباره مشاهده کند و رفتار سیستم مطابق Expected Result باشد، Bug تأیید می‌شود و در فرآیند تیم به وضعیت مناسب مانند Verified یا Closed تغییر می‌کند.

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

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

اگر Bug فقط تا حدی رفع شده باشد چه می‌شود؟

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

تفاوت Retesting و Regression Testing

Retesting و Regression Testing هر دو ممکن است بعد از اعمال تغییرات در نرم‌افزار انجام شوند، اما هدف آن‌ها متفاوت است.

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

اما در Regression Testing هدف این است که بررسی کنیم تغییرات جدید باعث ایجاد مشکل در بخش‌هایی از نرم‌افزار که قبلاً درست کار می‌کرده‌اند نشده باشد.

آیا Retesting و Regression Testing می‌توانند با هم انجام شوند؟

بله. این دو تست رقیب یکدیگر نیستند و می‌توانند پشت سر هم انجام شوند.

برای مثال، فرض کنید یک Bug مربوط به Login برطرف شده است. تستر ابتدا با Retesting بررسی می‌کند که مشکل ورود برطرف شده است. سپس ممکن است با Regression Testing قابلیت‌های مرتبط مانند Logout، Password Reset و سایر بخش‌های مرتبط با احراز هویت را بررسی کند تا مطمئن شود تغییر ایجادشده مشکل جدیدی ایجاد نکرده است.

بنابراین:

Retesting → آیا Bug برطرف شده است؟

Regression Testing → آیا تغییرات باعث ایجاد مشکل دیگری نشده‌اند؟

Retesting در Bug Life Cycle

Retesting بخشی از فرآیند Bug Life Cycle است و معمولاً زمانی انجام می‌شود که توسعه‌دهنده اعلام می‌کند Bug برطرف شده است.

یک جریان ساده را می‌توان این‌طور در نظر گرفت:

Reported → Fixed → Retest → Verified / Closed

پس از اینکه Bug به وضعیت Fixed رسید، تستر آن را دوباره بررسی می‌کند.

• اگر مشکل برطرف شده باشد، Bug می‌تواند به وضعیت Verified یا Closed منتقل شود.
• اگر مشکل همچنان وجود داشته باشد، Bug معمولاً به وضعیت Reopened برمی‌گردد.
• اگر نتیجه تست به اطلاعات بیشتری نیاز داشته باشد، تستر می‌تواند جزئیات و شواهد جدید را در گزارش Bug ثبت کند.

البته نام و ترتیب وضعیت‌ها در ابزارهای مدیریت تست و Bug ممکن است بسته به فرآیند هر تیم متفاوت باشد.

نکته مهم این است که Fixed به معنی تأیید نهایی Bug نیست. این وضعیت معمولاً نشان می‌دهد که توسعه‌دهنده اصلاح را انجام داده است؛ اما تأیید اینکه مشکل واقعاً برطرف شده، بر عهده فرآیند تست و Retesting است.

بهترین روش‌ها برای Retesting

برای اینکه Retesting نتیجه قابل اعتمادی داشته باشد، بهتر است تستر چند نکته مهم را رعایت کند:

• Bug Report را دقیق بررسی کنید: قبل از شروع Retesting، Steps to Reproduce، Expected Result و شرایطی که Bug در آن مشاهده شده است را بررسی کنید.
• شرایط تست را تا حد امکان مشابه نگه دارید: استفاده از همان Environment و Test Data می‌تواند به بازتولید دقیق‌تر مشکل کمک کند.
• فقط به وضعیت Fixed اعتماد نکنید: تغییر وضعیت Bug به Fixed به این معنی نیست که مشکل حتماً برطرف شده است. نتیجه Retesting باید این موضوع را مشخص کند.
• نتیجه تست را ثبت کنید: در صورت موفقیت یا شکست، نتیجه Retesting و شواهد لازم مانند Screenshot یا Log را در گزارش ثبت کنید.
• در صورت نیاز Regression Testing انجام دهید: رفع یک Bug ممکن است روی بخش‌های دیگر سیستم تأثیر بگذارد؛ بنابراین در صورت وجود ریسک، انجام Regression Testing نیز ضروری است.

در نهایت، Retesting باید به یک سؤال مشخص پاسخ دهد:

آیا مشکلی که قبلاً گزارش شده بود، با تغییرات جدید واقعاً برطرف شده است؟

یک مثال کامل از Retesting

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

۱. گزارش Bug

• Steps to Reproduce: ورود به صفحه پرداخت، وارد کردن اطلاعات معتبر کارت و کلیک روی پرداخت
• Expected Result: پرداخت با موفقیت انجام شود.
• Actual Result: پیام خطا نمایش داده می‌شود و پرداخت انجام نمی‌شود.

۲. رفع Bug

توسعه‌دهنده مشکل را بررسی و اصلاح می‌کند و نسخه جدید را در اختیار تستر قرار می‌دهد.

۳. Retesting

تستر همان سناریو را دوباره اجرا می‌کند و اطلاعات معتبر کارت را وارد می‌کند.

این بار پرداخت با موفقیت انجام می‌شود و نتیجه با Expected Result مطابقت دارد.

۴. نتیجه

تستر نتیجه Retesting را ثبت کرده و Bug را در فرآیند تیم به وضعیت Verified یا Closed منتقل می‌کند.

اما اگر پرداخت همچنان با خطا مواجه شود، Bug باید دوباره Reopen شود و نتیجه جدید در گزارش ثبت شود.

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

سوالات متداول درباره Retesting

جمع‌بندی

Retesting یا تست مجدد فرآیندی است که در آن تستر پس از رفع یک Bug، همان مشکل را دوباره بررسی می‌کند تا مطمئن شود اصلاح انجام‌شده نتیجه مورد انتظار را ایجاد کرده است.

Retesting را نباید با Regression Testing یکسان دانست. Retesting روی رفع یک Bug مشخص تمرکز دارد، در حالی که Regression Testing بررسی می‌کند تغییرات ایجادشده باعث خراب شدن قابلیت‌های دیگر نشده باشند.

به‌طور خلاصه:

Bug → Fix → Retest → Verify یا Reopen

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