STLC چیست؟ راهنمای کامل Software Testing Life Cycle از مبتدی تا حرفه‌ای

اگر قصد دارید وارد دنیای تست نرم‌افزار شوید یا برای آزمون ISTQB Foundation Level آماده می‌شوید، احتمالاً با اصطلاح STLC (Software Testing Life Cycle) روبه‌رو شده‌اید.

اما STLC دقیقاً چیست؟ چرا تقریباً در تمام تیم‌های حرفه‌ای توسعه نرم‌افزار از آن استفاده می‌شود؟ تفاوت آن با SDLC چیست و یک مهندس QA در هر مرحله چه مسئولیت‌هایی دارد؟

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

هدف STLC فقط پیدا کردن باگ نیست؛ بلکه مدیریت کیفیت نرم‌افزار از اولین مرحله توسعه تا تصمیم‌گیری برای انتشار محصول است.

STLC در یک نگاه

موضوع	توضیح
نام کامل	Software Testing Life Cycle
هدف	مدیریت فرآیند تست نرم‌افزار
شروع	تحلیل نیازمندی‌ها
پایان	گزارش نهایی تست و تصمیم برای انتشار
استاندارد مرجع	ISTQB Foundation Level v4.0

در این مقاله چه چیزهایی یاد می‌گیرید؟

• STLC چیست؟
• چرا STLC اهمیت دارد؟
• ۱۰ مرحله کامل STLC
• تفاوت STLC و SDLC
• STLC در Agile و Scrum
• دیدگاه ISTQB درباره STLC
• مثال واقعی با پروژه BlueShop
• Best Practices
• اشتباهات رایج
• سؤالات متداول

---

پروژه BlueShop

برای اینکه مفاهیم این مقاله صرفاً تئوری نباشند، تمام مراحل STLC را روی یک پروژه فرضی اما نزدیک به دنیای واقعی دنبال می‌کنیم.

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

شما در نقش یک QA Engineer به این تیم ملحق شده‌اید. از همین لحظه همراه تیم BlueShop خواهیم دید که STLC چگونه از اولین جلسه تحلیل نیازمندی‌ها آغاز می‌شود و تا انتشار نسخه نهایی ادامه پیدا می‌کند.

در پروژه‌های حرفه‌ای، تست نرم‌افزار از پایان برنامه‌نویسی شروع نمی‌شود؛ بلکه از همان روزی آغاز می‌شود که نیازمندی‌ها بررسی می‌شوند.

STLC چیست؟

Software Testing Life Cycle (STLC) یا چرخه حیات تست نرم‌افزار، مجموعه‌ای از فعالیت‌های ساختاریافته است که تیم تضمین کیفیت (QA) برای برنامه‌ریزی، طراحی، اجرا، کنترل و جمع‌بندی فعالیت‌های تست انجام می‌دهد.

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

در ادامه مقاله، هر یک از این مراحل را به‌صورت کامل، همراه با مثال‌های عملی از پروژه BlueShop و مطابق با دیدگاه ISTQB Foundation Level v4.0 بررسی خواهیم کرد.

---

مراحل STLC چیست؟

اگرچه ممکن است در برخی کتاب‌ها یا سازمان‌ها تعداد مراحل STLC کمی متفاوت باشد، اما در پروژه‌های مدرن و همچنین مطابق با رویکرد ISTQB Foundation Level v4.0 می‌توان فعالیت‌های اصلی تست را در قالب ۱۰ مرحله بررسی کرد.

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

مرحله	هدف
Requirement Analysis	تحلیل نیازمندی‌ها
Test Planning	برنامه‌ریزی تست
Test Monitoring & Control	پایش و کنترل تست
Test Analysis	تحلیل تست
Test Design	طراحی تست
Test Implementation	آماده‌سازی تست
Test Environment Setup	آماده‌سازی محیط تست
Test Execution	اجرای تست
Defect Management	مدیریت نقص‌ها
Test Completion	اتمام تست

نکته مهم این است که STLC یک فرآیند خطی و یک‌باره نیست. در پروژه‌های Agile این چرخه در هر Sprint بارها تکرار می‌شود.

---

مرحله اول STLC: تحلیل نیازمندی‌ها (Requirement Analysis)

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

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

اهداف مرحله Requirement Analysis

• درک دقیق نیازمندی‌های پروژه
• شناسایی موارد قابل تست (Testable Requirements)
• تشخیص ابهام‌ها و تناقض‌ها
• بررسی ریسک‌های اولیه پروژه
• آماده‌سازی برای طراحی تست

ورودی‌های این مرحله (Entry Criteria)

• Business Requirements
• User Stories
• Product Backlog
• Mockup یا Prototype
• Acceptance Criteria
• مستندات فنی در صورت وجود

فعالیت‌های اصلی QA

• مطالعه نیازمندی‌ها
• شرکت در جلسات تحلیل
• پرسیدن سؤال درباره ابهام‌ها
• شناسایی سناریوهای اصلی سیستم
• ثبت ریسک‌های احتمالی
• بررسی قابلیت تست نیازمندی‌ها

مثال از پروژه BlueShop

در اولین Sprint پروژه BlueShop، تیم محصول قابلیت ورود کاربران را معرفی می‌کند. در نگاه اول نیازمندی بسیار ساده به نظر می‌رسد:

«کاربر بتواند با ایمیل و رمز عبور وارد حساب کاربری خود شود.»

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

• اگر رمز عبور اشتباه باشد چه اتفاقی می‌افتد؟
• حداکثر تعداد تلاش ناموفق چقدر است؟
• آیا ورود با شماره موبایل هم پشتیبانی می‌شود؟
• آیا ایمیل به حروف بزرگ و کوچک حساس است؟
• اگر حساب کاربری غیرفعال باشد چه پیامی نمایش داده می‌شود؟
• رفتار سیستم هنگام قطعی اینترنت چیست؟

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

خروجی‌های مرحله Requirement Analysis

• فهرست نیازمندی‌های قابل تست (Testable Requirements)
• سؤال‌ها و ابهام‌های ثبت‌شده
• ریسک‌های اولیه پروژه
• شناخت بهتر محدوده تست (Scope)
• آمادگی برای ورود به مرحله Test Planning

روایت BlueShop

مریم (Product Owner):

کاربر باید بتواند وارد حساب خودش شود.

سارا (QA Engineer):

اگر رمز عبور را پنج بار اشتباه وارد کند چه اتفاقی می‌افتد؟

مریم:

در مستندات چیزی درباره آن ننوشته‌ایم.

سارا:

پس قبل از شروع توسعه بهتر است این موضوع مشخص شود؛ چون هم روی امنیت سیستم اثر دارد و هم روی طراحی تست‌ها.

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

از دیدگاه ISTQB

در ISTQB Foundation Level v4.0 تأکید می‌شود که فعالیت‌های تست باید تا حد امکان زود آغاز شوند. به این رویکرد Early Testing گفته می‌شود.

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

نکته ISTQB: تست مؤثر قبل از اجرای Test Case آغاز می‌شود؛ از همان زمانی که نیازمندی‌ها در حال تحلیل هستند.

اشتباهات رایج در این مرحله

• شروع طراحی Test Case بدون مطالعه کامل نیازمندی‌ها
• فرض کردن رفتار سیستم به جای پرسیدن سؤال
• بی‌توجهی به Acceptance Criteria
• ثبت نکردن ابهام‌ها
• حضور نداشتن QA در جلسات تحلیل

جمع‌بندی مرحله Requirement Analysis

مرحله تحلیل نیازمندی‌ها پایه تمام فعالیت‌های بعدی STLC است. اگر تیم QA در این مرحله نیازمندی‌ها را به‌درستی درک نکند، احتمال طراحی Test Caseهای ناقص، افزایش باگ‌های تولیدی و دوباره‌کاری در مراحل بعدی به‌شدت افزایش می‌یابد.

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

---

مرحله دوم STLC: برنامه‌ریزی تست (Test Planning)

اگر Requirement Analysis مشخص می‌کند چه چیزی باید تست شود، Test Planning مشخص می‌کند تست چگونه، توسط چه کسی، در چه زمانی و با چه منابعی انجام خواهد شد.

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

هدف مرحله Test Planning

هدف از Test Planning این است که تیم QA قبل از شروع فعالیت‌های تست، یک برنامه شفاف و قابل اجرا داشته باشد. این برنامه مشخص می‌کند چه فعالیت‌هایی انجام خواهند شد، چه منابعی موردنیاز است، چه ریسک‌هایی وجود دارد و معیار موفقیت تست چیست.

هرچه پروژه بزرگ‌تر باشد، اهمیت Test Planning نیز بیشتر می‌شود. یک برنامه‌ریزی مناسب باعث می‌شود اعضای تیم دید مشترکی نسبت به فرآیند تست داشته باشند و از دوباره‌کاری و اتلاف زمان جلوگیری شود.

ورودی‌های مرحله Test Planning (Entry Criteria)

• نیازمندی‌های تحلیل‌شده
• ریسک‌های اولیه پروژه
• محدوده پروژه (Project Scope)
• بودجه و زمان‌بندی پروژه
• منابع انسانی در دسترس
• الزامات کسب‌وکار

فعالیت‌های اصلی

• تعیین اهداف تست
• انتخاب انواع تست (Functional، Performance، Security و…)
• تعیین Strategy و Approach
• تخمین زمان و هزینه تست
• تخصیص وظایف به اعضای تیم
• شناسایی ریسک‌ها
• تعیین Entry Criteria و Exit Criteria
• انتخاب ابزارهای تست
• تعریف نحوه گزارش‌دهی

خروجی‌های این مرحله (Deliverables)

• Test Plan
• Test Estimation
• Risk List
• Resource Plan
• Schedule
• Test Strategy (در صورت تهیه به‌صورت جداگانه)

روایت BlueShop

پس از پایان تحلیل نیازمندی‌ها، اعضای تیم BlueShop برای برنامه‌ریزی فعالیت‌های تست جلسه‌ای برگزار می‌کنند.

امیر (QA Lead):

تا اینجا می‌دانیم چه قابلیت‌هایی باید تست شوند، اما هنوز مشخص نکرده‌ایم چگونه این تست‌ها را اجرا خواهیم کرد.

علی (Scrum Master):

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

سارا (QA Engineer):

به نظر من ابتدا روی Login، Registration و Checkout تمرکز کنیم؛ چون این سه قابلیت بیشترین ریسک را برای کسب‌وکار دارند.

پس از بررسی ریسک‌ها، تیم تصمیم می‌گیرد در Sprint اول تمرکز اصلی روی قابلیت‌های حیاتی باشد و تست‌های Performance و Compatibility را به Sprintهای بعدی منتقل کند.

نمونه تصمیم‌های Test Planning در BlueShop

موضوع	تصمیم تیم
اولویت تست	Login، Registration، Checkout
ابزار مدیریت وظایف	Jira
مدیریت Test Case	TestRail
Automation	Playwright
API Testing	Postman
Bug Tracking	Jira

از دیدگاه ISTQB

طبق ISTQB، برنامه‌ریزی تست تنها تهیه یک سند نیست؛ بلکه فرآیندی برای تعیین اهداف تست، انتخاب رویکرد مناسب، مدیریت ریسک‌ها، تخصیص منابع و تعریف معیارهای کنترل کیفیت است.

نکته ISTQB: یک Test Plan خوب باید متناسب با اندازه، پیچیدگی و ریسک پروژه باشد. همه پروژه‌ها به یک Test Plan با جزئیات یکسان نیاز ندارند.

اشتباهات رایج در Test Planning

• برنامه‌ریزی بدون تحلیل ریسک
• تخمین غیرواقع‌بینانه زمان تست
• نادیده گرفتن محدودیت منابع
• تلاش برای تست همه چیز با یک اولویت
• تعریف نکردن Exit Criteria
• به‌روزرسانی نکردن Test Plan پس از تغییر نیازمندی‌ها

جمع‌بندی مرحله Test Planning

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

اکنون تیم BlueShop آماده است تا علاوه بر برنامه‌ریزی، پیشرفت فعالیت‌های تست را نیز به‌صورت مستمر پایش کند. این موضوع در مرحله بعدی یعنی Test Monitoring & Control انجام می‌شود.

---

مرحله سوم STLC: پایش و کنترل تست (Test Monitoring & Control)

پس از اینکه برنامه تست تهیه شد، کار تیم QA فقط اجرای برنامه نیست. در طول پروژه باید به‌صورت مداوم بررسی شود که آیا فعالیت‌های تست مطابق برنامه پیش می‌روند یا خیر. این مسئولیت بر عهده مرحله Test Monitoring & Control است.

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

هدف مرحله Test Monitoring & Control

• بررسی پیشرفت فعالیت‌های تست
• مقایسه وضعیت واقعی با Test Plan
• شناسایی انحراف‌ها
• مدیریت ریسک‌های جدید
• کمک به تصمیم‌گیری مدیر پروژه و QA Lead

چه مواردی پایش می‌شوند؟

• تعداد Test Caseهای اجراشده
• تعداد Test Caseهای موفق و ناموفق
• تعداد Bugهای ثبت‌شده
• شدت (Severity) نقص‌ها
• اولویت (Priority) نقص‌ها
• میزان پوشش تست (Test Coverage)
• مصرف زمان نسبت به برنامه
• ریسک‌های جدید پروژه

شاخص‌های رایج (Test Metrics)

Metric	کاربرد
Executed Test Cases	تعداد تست‌های اجراشده
Passed Tests	تعداد تست‌های موفق
Failed Tests	تعداد تست‌های ناموفق
Blocked Tests	تست‌های متوقف‌شده
Defect Density	تراکم نقص‌ها
Test Coverage	میزان پوشش تست
Defect Leakage	باگ‌های عبور کرده به محیط Production

روایت BlueShop

یک هفته از Sprint اول گذشته است. تیم QA بخشی از تست‌ها را اجرا کرده اما QA Lead متوجه می‌شود روند پروژه با برنامه اولیه اختلاف دارد.

امیر (QA Lead):

طبق برنامه باید تا امروز ۷۰ درصد Test Caseها اجرا می‌شد، اما فقط ۴۵ درصد پیش رفته‌ایم.

علی (Scrum Master):

دلیل این اختلاف چیست؟

سارا (QA Engineer):

محیط تست دیروز چند ساعت در دسترس نبود و همچنین برای قابلیت Checkout چند تغییر جدید از سمت تیم توسعه دریافت کردیم.

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

نمونه داشبورد وضعیت تست

شاخص	برنامه	وضعیت فعلی
تست‌های اجراشده	۷۰٪	۴۵٪
باگ‌های بحرانی	۰	۲
پوشش تست	۸۰٪	۶۲٪
وضعیت پروژه	طبق برنامه	نیازمند اقدام اصلاحی

از دیدگاه ISTQB

در ISTQB، پایش (Monitoring) و کنترل (Control) دو مفهوم مرتبط اما متفاوت هستند. Monitoring به جمع‌آوری و تحلیل اطلاعات مربوط به وضعیت تست اشاره دارد، در حالی که Control شامل تصمیم‌گیری و انجام اقدامات اصلاحی بر اساس این اطلاعات است.

نکته ISTQB: بدون اندازه‌گیری، امکان مدیریت مؤثر تست وجود ندارد. تصمیم‌های QA باید بر اساس داده‌های واقعی و شاخص‌های قابل اندازه‌گیری گرفته شوند.

اشتباهات رایج در Test Monitoring & Control

• اندازه‌گیری شاخص‌های زیاد و غیرضروری
• تمرکز صرف بر تعداد باگ‌ها به‌جای کیفیت محصول
• به‌روزرسانی نکردن داشبورد پروژه
• نادیده گرفتن ریسک‌های جدید
• انجام ندادن اقدامات اصلاحی پس از مشاهده انحراف‌ها

جمع‌بندی مرحله Test Monitoring & Control

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

اکنون که تیم BlueShop بر روند اجرای پروژه نظارت دارد، زمان آن رسیده است که مشخص کند دقیقاً چه شرایطی باید تست شوند و چه سناریوهایی باید طراحی شوند. این فعالیت در مرحله بعدی یعنی Test Analysis انجام می‌شود.

---

مرحله چهارم STLC: تحلیل تست (Test Analysis)

پس از اینکه برنامه تست آماده شد و روند اجرای پروژه تحت پایش قرار گرفت، تیم QA باید مشخص کند دقیقاً چه چیزی باید تست شود. این فعالیت در مرحله Test Analysis انجام می‌شود.

در این مرحله، نیازمندی‌های پروژه از دیدگاه تست بررسی می‌شوند تا شرایط تست (Test Conditions) استخراج شوند. به عبارت دیگر، تیم QA تصمیم می‌گیرد چه رفتارها، قوانین، محدودیت‌ها و سناریوهایی باید مورد ارزیابی قرار گیرند.

خروجی Test Analysis هنوز Test Case نیست؛ بلکه فهرستی از مواردی است که باید در آینده تست شوند.

هدف مرحله Test Analysis

• استخراج Test Conditionها
• شناسایی سناریوهای قابل تست
• اولویت‌بندی شرایط تست
• بررسی ریسک هر قابلیت
• آماده‌سازی برای طراحی Test Caseها

ورودی‌های مرحله Test Analysis

• Business Requirements
• User Story
• Acceptance Criteria
• Risk Analysis
• Test Plan
• تجربیات پروژه‌های قبلی

فعالیت‌های اصلی

• مطالعه دقیق نیازمندی‌ها
• تقسیم قابلیت‌ها به Test Conditionهای مستقل
• شناسایی Positive و Negative Scenarioها
• بررسی Boundaryها
• شناسایی Business Ruleها
• اولویت‌بندی موارد تست

روایت BlueShop

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

سارا (QA Engineer):

قبل از اینکه Test Case بنویسم، باید تمام شرایط ممکن را استخراج کنم.

او نیازمندی را دوباره مطالعه می‌کند:

«کاربر با ایمیل و رمز عبور معتبر وارد سیستم شود.»

به‌جای نوشتن مستقیم Test Case، ابتدا شرایط تست را استخراج می‌کند.

Test Condition	اولویت
ورود با اطلاعات صحیح	زیاد
رمز عبور اشتباه	زیاد
ایمیل نامعتبر	زیاد
فیلد خالی	متوسط
حساب غیرفعال	زیاد
قفل شدن حساب	زیاد
کاراکترهای غیرمجاز	متوسط
SQL Injection	زیاد
XSS	متوسط

اکنون تیم QA تصویر بسیار واضح‌تری از دامنه تست دارد و می‌تواند وارد مرحله طراحی تست شود.

تفاوت Test Analysis و Test Design

Test Analysis	Test Design
چه چیزی باید تست شود؟	چگونه تست شود؟
استخراج Test Condition	طراحی Test Case
تمرکز بر نیازمندی	تمرکز بر اجرای تست
خروجی: Test Condition	خروجی: Test Case

از دیدگاه ISTQB

در ISTQB، Test Analysis فعالیتی است که طی آن اطلاعات موجود تحلیل می‌شوند تا ویژگی‌های قابل تست شناسایی شوند و شرایط تست (Test Conditions) استخراج شوند. این مرحله پایه طراحی Test Caseها محسوب می‌شود.

نکته ISTQB: بسیاری از داوطلبان آزمون، Test Analysis و Test Design را با یکدیگر اشتباه می‌گیرند. در حالی که Test Analysis به استخراج شرایط تست می‌پردازد و Test Design این شرایط را به Test Case تبدیل می‌کند.

اشتباهات رایج

• نوشتن مستقیم Test Case بدون استخراج Test Condition
• نادیده گرفتن سناریوهای منفی
• بی‌توجهی به Business Ruleها
• در نظر نگرفتن ریسک‌ها
• اولویت‌بندی نکردن شرایط تست

جمع‌بندی مرحله Test Analysis

در این مرحله، تیم QA مشخص می‌کند چه شرایطی باید مورد آزمایش قرار گیرند. خروجی این مرحله مجموعه‌ای از Test Conditionها است که در مرحله بعد به Test Caseهای واقعی تبدیل خواهند شد.

اکنون سارا می‌داند چه مواردی باید تست شوند. گام بعدی این است که برای هر یک از این شرایط، Test Caseهای دقیق، قابل تکرار و قابل اندازه‌گیری طراحی کند. این دقیقاً هدف مرحله Test Design است.

---

مرحله پنجم STLC: طراحی تست (Test Design)

پس از اینکه در مرحله Test Analysis مشخص شد چه شرایطی باید بررسی شوند، نوبت به طراحی تست می‌رسد. در این مرحله، تیم QA برای هر Test Condition یک یا چند Test Case طراحی می‌کند تا بتواند رفتار سیستم را به‌صورت ساختاریافته ارزیابی کند.

به بیان ساده، اگر Test Analysis به سؤال «چه چیزی باید تست شود؟» پاسخ دهد، Test Design پاسخ می‌دهد «چگونه باید آن را تست کنیم؟».

خروجی مرحله Test Design، مجموعه‌ای از Test Caseها، Test Dataها و در صورت نیاز Test Charterها است که در مرحله بعد برای اجرا آماده خواهند شد.

اهداف مرحله Test Design

• تبدیل Test Conditionها به Test Caseهای قابل اجرا
• طراحی سناریوهای مثبت، منفی و مرزی
• تعیین داده‌های تست (Test Data)
• افزایش پوشش تست (Test Coverage)
• کاهش تست‌های تکراری و غیرضروری

ورودی‌های مرحله Test Design

• Test Conditionها
• Acceptance Criteria
• User Storyها
• Business Ruleها
• Risk Analysis
• Test Plan

فعالیت‌های اصلی

• نوشتن Test Caseها
• طراحی Test Scenarioها
• تعیین Expected Result
• تهیه Test Data
• استفاده از تکنیک‌های طراحی تست
• بازبینی Test Caseها

نمونه طراحی تست در پروژه BlueShop

در مرحله قبل، سارا شرایط تست مربوط به قابلیت ورود کاربران را استخراج کرد. اکنون باید این شرایط را به Test Caseهای واقعی تبدیل کند.

Test Condition	نمونه Test Case
ورود موفق	ورود با ایمیل و رمز عبور معتبر
رمز اشتباه	نمایش پیام خطای مناسب
ایمیل نامعتبر	جلوگیری از ورود
فیلد خالی	اعتبارسنجی اجباری بودن فیلدها
حساب غیرفعال	نمایش پیام مناسب و جلوگیری از ورود

نمونه یک Test Case

Test Case ID	TC-LOGIN-001
عنوان	ورود موفق کاربر
پیش‌نیاز	کاربر قبلاً ثبت‌نام کرده باشد.
مراحل اجرا	۱. ورود به صفحه Login ۲. وارد کردن ایمیل معتبر ۳. وارد کردن رمز معتبر ۴. کلیک روی دکمه Login
Expected Result	کاربر وارد داشبورد شود.

استفاده از تکنیک‌های طراحی تست

در این مرحله، QA Engineer معمولاً از تکنیک‌های طراحی تست برای افزایش پوشش و کاهش تعداد Test Caseها استفاده می‌کند.

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Use Case Testing
• Pairwise Testing
• Error Guessing

طراحی تعداد زیاد Test Case به معنای کیفیت بیشتر نیست؛ طراحی هوشمندانه Test Caseها اهمیت بیشتری دارد.

روایت BlueShop

سارا (QA Engineer):

برای قابلیت Login فقط یک Test Case کافی نیست. باید شرایط مرزی، ورودی‌های نامعتبر، قوانین امنیتی و رفتار سیستم در شرایط غیرعادی را هم بررسی کنیم.

امیر (QA Lead):

دقیقاً. اگر فقط مسیر موفق را تست کنیم، احتمال دارد مهم‌ترین باگ‌های سیستم هرگز شناسایی نشوند.

به همین دلیل، تیم تصمیم می‌گیرد علاوه بر سناریوهای عادی، Test Caseهایی برای حملات SQL Injection، تلاش‌های ناموفق متوالی، ورود هم‌زمان از چند دستگاه و اعتبارسنجی فیلدها نیز طراحی کند.

از دیدگاه ISTQB

در ISTQB، Test Design فعالیتی است که طی آن Test Conditionها با استفاده از تکنیک‌های طراحی تست به Test Caseهای قابل اجرا تبدیل می‌شوند. انتخاب تکنیک مناسب به نوع سیستم، سطح ریسک و اهداف تست بستگی دارد.

نکته ISTQB: یکی از اهداف اصلی Test Design، دستیابی به بیشترین پوشش تست با کمترین تعداد Test Case است.

اشتباهات رایج در Test Design

• نوشتن Test Caseهای تکراری
• نداشتن Expected Result شفاف
• نادیده گرفتن سناریوهای منفی
• استفاده نکردن از تکنیک‌های طراحی تست
• وابستگی بیش از حد Test Caseها به یکدیگر
• تهیه نکردن Test Data مناسب

جمع‌بندی مرحله Test Design

در این مرحله، شرایط تست به Test Caseهای دقیق، قابل تکرار و قابل اندازه‌گیری تبدیل می‌شوند. این Test Caseها پایه اجرای تست در مراحل بعدی هستند و کیفیت آن‌ها تأثیر مستقیمی بر کیفیت کل فرآیند STLC دارد.

پس از آماده شدن Test Caseها، تیم باید آن‌ها را سازمان‌دهی کند، داده‌های تست را آماده سازد، Suiteهای تست را ایجاد کند و برای اجرای واقعی آماده شود. این فعالیت‌ها در مرحله بعد یعنی Test Implementation انجام می‌شوند.

---

مرحله ششم STLC: آماده‌سازی تست (Test Implementation)

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

در این مرحله، تیم QA Test Caseها را سازمان‌دهی می‌کند، داده‌های تست (Test Data) را آماده می‌کند، Test Suiteها را می‌سازد، در صورت نیاز اسکریپت‌های تست خودکار را ایجاد می‌کند و همه چیز را برای اجرای واقعی تست آماده می‌سازد.

اگر Test Design مرحله «طراحی نقشه» باشد، Test Implementation مرحله «آماده کردن تجهیزات برای اجرای نقشه» است.

اهداف مرحله Test Implementation

• سازمان‌دهی Test Caseها
• ایجاد Test Suiteها
• آماده‌سازی Test Data
• تهیه Scriptهای تست خودکار (در صورت نیاز)
• بررسی آمادگی برای اجرای تست

فعالیت‌های اصلی

• دسته‌بندی Test Caseها
• اولویت‌بندی Test Suiteها
• آماده کردن داده‌های تست
• بررسی پیش‌نیازهای هر Test Case
• ایجاد Automation Scriptها
• بازبینی نهایی Test Caseها

نمونه Test Suite در پروژه BlueShop

Test Suite	تعداد Test Case
Login	18
Registration	22
Search	15
Shopping Cart	27
Checkout	31

آماده‌سازی Test Data

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

نوع داده	نمونه
کاربر معتبر	کاربر فعال با رمز صحیح
کاربر غیرفعال	حساب تأییدنشده
رمز اشتباه	WrongPassword123
ایمیل نامعتبر	user@@mail
ورودی مخرب	‘ OR 1=1 —

روایت BlueShop

سارا (QA Engineer):

Test Caseها آماده هستند، اما هنوز نمی‌توانیم تست را شروع کنیم. ابتدا باید داده‌های تست را ایجاد کنیم.

رضا (Backend Developer):

برای شما چند حساب کاربری آزمایشی روی محیط Staging ایجاد می‌کنم تا بتوانید سناریوهای مختلف را اجرا کنید.

امیر (QA Lead):

همچنین Test Caseها را بر اساس اولویت در Test Suiteهای جداگانه قرار دهید تا اجرای Sprint ساده‌تر شود.

پس از آماده شدن داده‌ها، ساخت Test Suiteها و بازبینی Test Caseها، تیم BlueShop آماده ورود به مرحله اجرای تست می‌شود.

Test Implementation در تست خودکار

در پروژه‌هایی که از Automation Testing استفاده می‌شود، این مرحله شامل ایجاد یا به‌روزرسانی اسکریپت‌های تست نیز هست. برای مثال، تیم BlueShop بخشی از سناریوهای Login و Checkout را با Playwright خودکارسازی می‌کند تا در هر Build به‌صورت خودکار اجرا شوند.

از دیدگاه ISTQB

طبق ISTQB، Test Implementation شامل آماده‌سازی تمام دارایی‌های تست (Testware) برای اجرا است؛ از جمله سازمان‌دهی Test Caseها، آماده‌سازی Test Data، ایجاد Test Suiteها و آماده کردن اسکریپت‌های خودکار.

نکته ISTQB: طراحی تست و آماده‌سازی تست دو فعالیت متفاوت هستند. در Test Design تصمیم می‌گیریم چه تستی نوشته شود و در Test Implementation آن تست را برای اجرا آماده می‌کنیم.

اشتباهات رایج

• شروع اجرای تست بدون Test Data مناسب
• دسته‌بندی نکردن Test Caseها
• به‌روزرسانی نکردن Automation Scriptها
• استفاده از داده‌های واقعی کاربران در محیط تست
• نداشتن ساختار مناسب برای Test Suiteها

جمع‌بندی مرحله Test Implementation

در این مرحله، تمام دارایی‌های تست برای اجرا آماده می‌شوند. Test Caseها سازمان‌دهی می‌شوند، داده‌های تست تهیه می‌شوند و در صورت نیاز اسکریپت‌های خودکار نیز آماده خواهند شد. اکنون تیم BlueShop می‌تواند وارد مرحله اجرای واقعی تست شود.

اما پیش از اجرای Test Caseها، باید مطمئن شویم زیرساخت موردنیاز آماده است. پایگاه داده، سرورها، سرویس‌های جانبی و نسخه نرم‌افزار باید در وضعیت مناسبی قرار داشته باشند. این موضوع در مرحله بعد یعنی Test Environment Setup بررسی می‌شود.

---

مرحله هفتم STLC: آماده‌سازی محیط تست (Test Environment Setup)

حتی اگر بهترین Test Caseها را طراحی کرده باشید، بدون یک محیط تست مناسب نمی‌توان به نتایج قابل اعتماد رسید. به همین دلیل، قبل از شروع اجرای تست باید اطمینان حاصل شود که تمام اجزای محیط تست آماده هستند.

در مرحله Test Environment Setup، تیم QA و سایر اعضای فنی پروژه محیطی را آماده می‌کنند که تا حد امکان به محیط واقعی (Production) شباهت داشته باشد تا نتایج تست معتبر و قابل اعتماد باشند.

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

هدف مرحله Test Environment Setup

• آماده‌سازی زیرساخت تست
• نصب نسخه مناسب نرم‌افزار
• راه‌اندازی پایگاه داده
• اتصال به سرویس‌های موردنیاز
• اطمینان از آمادگی محیط برای اجرای Test Caseها

اجزای محیط تست

• Application Server
• Database Server
• Web Server
• API Services
• Third-party Services
• Browserها و سیستم‌عامل‌ها
• Mobile Deviceها (در صورت نیاز)
• Test Data

Entry Criteria

• اتمام Test Implementation
• آماده بودن Build جدید
• دسترسی به محیط تست
• آماده بودن Test Data
• در دسترس بودن سرویس‌های وابسته

فعالیت‌های اصلی

• استقرار نسخه جدید (Deployment)
• بررسی سلامت محیط (Smoke Check)
• بررسی اتصال Database
• بررسی APIها
• بررسی سرویس‌های جانبی
• تأیید نسخه نرم‌افزار
• ثبت مشکلات محیط

روایت BlueShop

تیم توسعه نسخه جدید BlueShop را روی محیط Staging منتشر کرده است. قبل از شروع اجرای Test Caseها، سارا وضعیت محیط را بررسی می‌کند.

سارا (QA Engineer):

قبل از اجرای تست، باید مطمئن شویم همه سرویس‌ها در دسترس هستند.

رضا (Backend Developer):

نسخه 2.4.0 روی محیط Staging مستقر شده و پایگاه داده نیز به‌روزرسانی شده است.

نرگس (Frontend Developer):

آخرین نسخه رابط کاربری نیز منتشر شده است. لطفاً ابتدا Smoke Test را اجرا کنید.

سارا ابتدا چند تست پایه انجام می‌دهد؛ صفحه اصلی باز می‌شود، ورود کاربران انجام می‌شود و ارتباط با API برقرار است. اکنون تیم مطمئن است که محیط برای اجرای تست آماده است.

چک‌لیست آماده بودن محیط تست

مورد بررسی	وضعیت
آخرین Build مستقر شده است.	✅
پایگاه داده به‌روز است.	✅
APIها در دسترس هستند.	✅
سرویس پرداخت آزمایشی فعال است.	✅
Test Data آماده است.	✅
دسترسی اعضای QA برقرار است.	✅
Smoke Test موفق بوده است.	✅

رابطه Test Environment و Smoke Testing

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

اگر Smoke Test با شکست مواجه شود، اجرای سایر Test Caseها متوقف می‌شود تا مشکلات محیط یا Build برطرف شوند.

از دیدگاه ISTQB

طبق ISTQB، محیط تست باید تمام سخت‌افزار، نرم‌افزار، شبکه، داده‌ها، ابزارها و تنظیماتی را که برای اجرای تست لازم هستند، در بر بگیرد. آماده بودن محیط یکی از مهم‌ترین Entry Criteria برای آغاز Test Execution محسوب می‌شود.

نکته ISTQB: بسیاری از شکست‌های تست ناشی از نقص در محیط تست هستند، نه وجود باگ در نرم‌افزار. بنابراین قبل از ثبت Bug، ابتدا باید از سلامت محیط اطمینان حاصل کرد.

اشتباهات رایج

• اجرای تست روی نسخه اشتباه نرم‌افزار
• استفاده از Test Data قدیمی
• بررسی نکردن سرویس‌های وابسته
• نادیده گرفتن Smoke Test
• ثبت Bugهایی که در واقع ناشی از خرابی محیط هستند.

جمع‌بندی مرحله Test Environment Setup

در این مرحله، تیم QA مطمئن می‌شود که تمام زیرساخت، داده‌ها و سرویس‌های موردنیاز برای اجرای تست آماده هستند. تنها پس از تأیید سلامت محیط، اجرای واقعی Test Caseها آغاز می‌شود.

اکنون همه چیز برای مهم‌ترین مرحله STLC آماده است؛ مرحله‌ای که Test Caseها اجرا می‌شوند، نتایج ثبت می‌شوند و کیفیت واقعی محصول ارزیابی می‌شود. این مرحله همان Test Execution است.

---

مرحله هشتم STLC: اجرای تست (Test Execution)

پس از آماده شدن Test Caseها، داده‌های تست و محیط اجرا، مهم‌ترین مرحله STLC آغاز می‌شود. در Test Execution، تیم QA سناریوهای طراحی‌شده را اجرا می‌کند، نتایج واقعی را با نتایج مورد انتظار مقایسه می‌کند و هرگونه مغایرت را ثبت می‌کند.

هدف این مرحله صرفاً پیدا کردن باگ نیست؛ بلکه ارزیابی میزان انطباق نرم‌افزار با نیازمندی‌های تعریف‌شده و ارائه تصویری واقعی از کیفیت محصول است.

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

اهداف مرحله Test Execution

• اجرای Test Caseها
• ثبت نتیجه هر تست
• مقایسه Actual Result با Expected Result
• شناسایی نقص‌های نرم‌افزار
• ثبت شواهد (Evidence) برای هر تست
• به‌روزرسانی وضعیت اجرای تست

ورودی‌های مرحله Test Execution

• Test Caseهای تأییدشده
• محیط تست آماده
• Test Data
• آخرین Build نرم‌افزار
• Entry Criteria تأییدشده

فعالیت‌های اصلی

• اجرای دستی یا خودکار Test Caseها
• ثبت وضعیت Passed، Failed، Blocked یا Not Executed
• ثبت شواهد مانند Screenshot و Log
• ثبت Bug در صورت مشاهده مغایرت
• اجرای مجدد تست پس از رفع نقص (Retest)
• اجرای Regression Test در صورت نیاز

نمونه اجرای تست در پروژه BlueShop

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

Test Case	Expected Result	Actual Result	Status
ورود با اطلاعات صحیح	ورود به داشبورد	مطابق انتظار	Passed
رمز عبور اشتباه	نمایش پیام خطا	مطابق انتظار	Passed
حساب غیرفعال	جلوگیری از ورود	ورود انجام شد	Failed

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

روایت BlueShop

سارا (QA Engineer):

کاربر غیرفعال بدون هیچ پیامی وارد حساب کاربری شد. این رفتار با Acceptance Criteria مطابقت ندارد.

رضا (Backend Developer):

لطفاً Screenshot، Log و مراحل بازتولید مشکل را برای من ارسال کن تا بتوانم علت را بررسی کنم.

امیر (QA Lead):

قبل از ادامه اجرای تست‌ها، این نقص را در Jira ثبت کنید تا قابل پیگیری باشد.

وضعیت‌های رایج Test Case

Status	توضیح
Passed	نتیجه واقعی با نتیجه مورد انتظار مطابقت دارد.
Failed	رفتار سیستم با انتظار تعریف‌شده متفاوت است.
Blocked	به دلیل وجود مانع، تست قابل اجرا نیست.
Not Executed	هنوز اجرا نشده است.
Skipped	بر اساس تصمیم تیم، اجرا نشده است.

Retest و Regression Test

پس از رفع یک نقص، QA ابتدا همان Test Case را دوباره اجرا می‌کند که به این فعالیت Retest گفته می‌شود. سپس برای اطمینان از اینکه تغییر جدید باعث ایجاد مشکل در سایر بخش‌های سیستم نشده است، مجموعه‌ای از تست‌های مرتبط اجرا می‌شود که به آن Regression Testing گفته می‌شود.

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

از دیدگاه ISTQB

ISTQB تأکید می‌کند که اجرای تست باید مطابق Test Procedureهای تعریف‌شده انجام شود و نتایج هر تست به‌همراه شواهد لازم ثبت شوند. همچنین در صورت مشاهده هرگونه رفتار غیرمنتظره، نقص باید به‌صورت قابل بازتولید مستندسازی شود.

نکته ISTQB: یک Test Case که به‌درستی اجرا شده اما نتیجه آن مستندسازی نشده باشد، از نظر فرآیند تست ارزشی ایجاد نمی‌کند.

اشتباهات رایج در Test Execution

• ثبت نکردن Actual Result
• گزارش نکردن شواهد کافی برای نقص‌ها
• اجرای تست روی Build اشتباه
• نادیده گرفتن Retest پس از رفع نقص
• عدم اجرای Regression Testing پس از تغییرات مهم
• ثبت Bug بدون امکان بازتولید (Reproduce)

جمع‌بندی مرحله Test Execution

در این مرحله، Test Caseها اجرا می‌شوند، نتایج ثبت می‌شوند و کیفیت واقعی نرم‌افزار ارزیابی می‌شود. خروجی این مرحله معمولاً مجموعه‌ای از Test Resultها، گزارش‌های اجرا و Bugهایی است که در مرحله بعد، یعنی Defect Management، مدیریت و پیگیری خواهند شد.

---

مرحله نهم STLC: مدیریت نقص‌ها (Defect Management)

پیدا کردن یک باگ پایان کار QA نیست؛ بلکه آغاز فرآیندی است که باید تا زمان رفع، بازآزمایی و بسته شدن نقص ادامه پیدا کند. این فرآیند با عنوان Defect Management شناخته می‌شود.

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

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

اهداف مرحله Defect Management

• ثبت دقیق نقص‌ها
• اولویت‌بندی و تعیین Severity
• ارجاع به تیم توسعه
• پیگیری وضعیت نقص
• تأیید رفع نقص (Retest)
• اطمینان از عدم ایجاد مشکل جدید (Regression Testing)

اطلاعات ضروری در گزارش Bug

• Bug ID
• عنوان (Summary)
• شرح مشکل
• مراحل بازتولید (Steps to Reproduce)
• Expected Result
• Actual Result
• Severity
• Priority
• محیط اجرا (Environment)
• نسخه نرم‌افزار (Build Version)
• پیوست‌ها مانند Screenshot یا Log

Severity و Priority چه تفاوتی دارند؟

دو مفهوم Severity و Priority معمولاً با یکدیگر اشتباه گرفته می‌شوند، در حالی که کاربرد متفاوتی دارند.

Severity	Priority
شدت اثر نقص بر سیستم	فوریت رفع نقص
بیشتر توسط QA تعیین می‌شود.	معمولاً با توافق QA، Product Owner و تیم توسعه تعیین می‌شود.
دیدگاه فنی	دیدگاه کسب‌وکار

روایت BlueShop

در مرحله Test Execution، سارا متوجه شد که کاربران غیرفعال می‌توانند وارد حساب کاربری خود شوند. اکنون باید این نقص به‌صورت استاندارد ثبت شود.

سارا (QA Engineer):

Bug جدید ثبت شد. کاربران غیرفعال بدون هیچ محدودیتی وارد سیستم می‌شوند.

رضا (Backend Developer):

لطفاً مراحل بازتولید، Screenshot و شماره Build را هم ضمیمه کن.

امیر (QA Lead):

این مشکل روی امنیت سیستم اثر می‌گذارد؛ بنابراین Severity آن را High و Priority را نیز High ثبت کنید.

نمونه Bug Report

Bug ID	BUG-245
عنوان	Inactive user can login successfully
Severity	High
Priority	High
Build	2.4.0
Expected Result	ورود کاربر غیرفعال باید مسدود شود.
Actual Result	کاربر غیرفعال وارد داشبورد می‌شود.

چرخه حیات یک Bug

• New
• Assigned
• In Progress
• Resolved
• Retest
• Closed

در برخی تیم‌ها وضعیت‌هایی مانند Reopened، Rejected، Duplicate یا Deferred نیز وجود دارند که بسته به فرآیند سازمان قابل استفاده هستند.

پایان داستان BlueShop

رضا مشکل را برطرف می‌کند و نسخه 2.4.1 روی محیط Staging منتشر می‌شود.

رضا (Backend Developer):

مشکل رفع شد. لطفاً Retest انجام دهید.

سارا همان Test Case را دوباره اجرا می‌کند. این بار ورود کاربر غیرفعال به‌درستی مسدود می‌شود. سپس Regression Testing روی سایر قابلیت‌های Login انجام می‌شود تا مطمئن شود تغییر جدید باعث ایجاد مشکل دیگری نشده است.

سارا:

Retest موفق بود و Regression Testing نیز مشکلی نشان نداد. وضعیت Bug به Closed تغییر می‌کند.

از دیدگاه ISTQB

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

نکته ISTQB: یک Bug Report خوب باید شفاف، قابل بازتولید، مستند و عاری از ابهام باشد.

اشتباهات رایج در Defect Management

• ثبت Bug بدون مراحل بازتولید
• تعیین نادرست Severity یا Priority
• نبود Screenshot یا Log
• بستن Bug بدون Retest
• انجام ندادن Regression Testing پس از رفع نقص
• استفاده از عنوان‌های مبهم مانند “Login Problem”

جمع‌بندی مرحله Defect Management

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

پس از اتمام تمام فعالیت‌های تست و بسته شدن نقص‌های مورد قبول تیم، نوبت به آخرین مرحله STLC یعنی Test Completion می‌رسد؛ مرحله‌ای که در آن کل فرآیند تست جمع‌بندی و ارزیابی می‌شود.

---

مرحله دهم STLC: اتمام تست (Test Completion)

پس از اجرای تمام Test Caseها، رفع نقص‌های مهم و انجام Retest و Regression Testing، فرآیند تست به پایان می‌رسد. اما پایان اجرای تست به معنای پایان کار تیم QA نیست.

در مرحله Test Completion، تیم QA فعالیت‌های انجام‌شده را جمع‌بندی می‌کند، نتایج را مستندسازی می‌کند، کیفیت محصول را ارزیابی می‌کند و تجربیات به‌دست‌آمده را برای پروژه‌های آینده ثبت می‌کند.

هدف Test Completion فقط اعلام پایان تست نیست؛ بلکه مستندسازی نتایج، ارزیابی کیفیت و انتقال دانش به پروژه‌های آینده است.

اهداف مرحله Test Completion

• بررسی تحقق اهداف Test Plan
• ارزیابی کیفیت نهایی محصول
• تهیه Test Summary Report
• ثبت Lessons Learned
• آرشیو Testware
• آزادسازی منابع پروژه

فعالیت‌های اصلی

• بررسی وضعیت تمام Test Caseها
• بررسی وضعیت نقص‌های باز
• تحلیل Test Metrics
• تهیه گزارش نهایی تست
• ثبت تجربیات و پیشنهادهای بهبود
• آرشیو مستندات تست

نمونه Test Summary Report

Build Version	2.4.1
Total Test Cases	215
Passed	208
Failed	2
Blocked	5
Critical Defects	0
High Defects	0
Medium Defects	2
Release Recommendation	Ready for Release

روایت پایانی BlueShop

پس از چند هفته تست، تمام قابلیت‌های اصلی فروشگاه اینترنتی BlueShop بررسی شده‌اند. نقص‌های بحرانی برطرف شده‌اند و تنها چند نقص کم‌اهمیت باقی مانده است که بر انتشار نسخه تأثیر نمی‌گذارند.

امیر (QA Lead):

تمام اهداف تعریف‌شده در Test Plan محقق شده‌اند و هیچ نقص بحرانی یا با اولویت بالا باقی نمانده است.

سارا (QA Engineer):

Test Summary Report آماده است و تمام Test Caseها، نتایج اجرا و گزارش نقص‌ها در مخزن پروژه آرشیو شده‌اند.

Product Owner:

با توجه به نتایج تست، نسخه 2.4.1 برای انتشار تأیید می‌شود.

Lessons Learned

یکی از مهم‌ترین خروجی‌های Test Completion، ثبت تجربیات پروژه است. این اطلاعات به تیم کمک می‌کنند در پروژه‌های بعدی از تکرار اشتباهات جلوگیری کند و فرآیند تست را بهبود دهد.

• نیازمندی‌های Login باید شفاف‌تر مستندسازی شوند.
• Smoke Testها بهتر است به‌صورت خودکار اجرا شوند.
• Test Dataها باید قبل از شروع Sprint آماده باشند.
• Regression Testهای پرکاربرد برای اجرای خودکار مناسب هستند.

خروجی‌های مرحله Test Completion

• Test Summary Report
• Test Metrics
• Bug Reportهای نهایی
• Lessons Learned
• نسخه آرشیوشده Test Caseها و Test Dataها
• تصمیم نهایی درباره انتشار محصول

از دیدگاه ISTQB

طبق ISTQB، Test Completion شامل اطمینان از تکمیل فعالیت‌های تست، ارزیابی معیارهای خروج (Exit Criteria)، مستندسازی نتایج، بستن فعالیت‌های تست و آرشیو Testware است. همچنین تجربیات پروژه باید ثبت شوند تا در پروژه‌های آینده مورد استفاده قرار گیرند.

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

اشتباهات رایج در Test Completion

• پایان دادن به پروژه بدون تهیه Test Summary Report
• آرشیو نکردن Test Caseها و Test Dataها
• ثبت نکردن Lessons Learned
• انتشار محصول بدون بررسی Exit Criteria
• نادیده گرفتن نقص‌های باز و ریسک‌های باقی‌مانده

جمع‌بندی مرحله Test Completion

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

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

---

اشتباهات رایج در اجرای STLC

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

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

۱. شروع تست بدون Test Plan

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

راهکار: پیش از شروع تست، یک Test Plan متناسب با اندازه و پیچیدگی پروژه تهیه کنید.

۲. تحلیل ناقص نیازمندی‌ها

اگر QA نیازمندی‌ها، قوانین کسب‌وکار یا Acceptance Criteria را به‌درستی تحلیل نکند، Test Conditionهای مهم شناسایی نخواهند شد و بخشی از نرم‌افزار بدون تست باقی می‌ماند.

راهکار: قبل از طراحی Test Case، نیازمندی‌ها را با ذی‌نفعان مرور و ابهام‌ها را برطرف کنید.

۳. تمرکز فقط بر سناریوهای مثبت

برخی تیم‌ها فقط مسیرهای موفق (Happy Path) را تست می‌کنند و سناریوهای منفی، ورودی‌های نامعتبر و شرایط مرزی را نادیده می‌گیرند. در نتیجه بسیاری از باگ‌های مهم تا زمان انتشار کشف نمی‌شوند.

راهکار: علاوه بر سناریوهای مثبت، تست‌های منفی، مرزی و امنیتی را نیز طراحی کنید.

۴. طراحی Test Caseهای تکراری

وجود Test Caseهای مشابه باعث افزایش زمان اجرا و نگهداری می‌شود، بدون اینکه پوشش تست بهبود پیدا کند.

راهکار: از تکنیک‌های طراحی تست مانند Boundary Value Analysis و Equivalence Partitioning استفاده کنید.

۵. استفاده از محیط تست نامناسب

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

راهکار: تا حد امکان محیط تست را از نظر نسخه نرم‌افزار، تنظیمات، پایگاه داده و سرویس‌های وابسته به محیط Production نزدیک کنید.

۶. ثبت ناقص Bug Report

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

راهکار: هر Bug Report باید شامل Summary، Steps to Reproduce، Expected Result، Actual Result، Severity، Priority و شواهد لازم باشد.

۷. حذف Regression Testing

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

راهکار: پس از هر تغییر مهم، علاوه بر Retest، مجموعه‌ای از Regression Testها نیز اجرا کنید.

۸. اندازه‌گیری نکردن شاخص‌های تست

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

راهکار: شاخص‌هایی مانند Test Coverage، Pass Rate، Defect Density و Defect Leakage را به‌طور منظم بررسی کنید.

۹. مستندسازی نکردن Lessons Learned

اگر تجربیات پروژه ثبت نشوند، تیم در پروژه‌های بعدی همان اشتباهات را دوباره تکرار خواهد کرد.

راهکار: در پایان هر پروژه جلسه مرور (Retrospective) برگزار کنید و مهم‌ترین درس‌آموخته‌ها را ثبت کنید.

۱۰. تصور اینکه STLC فقط وظیفه تیم QA است

کیفیت محصول مسئولیت مشترک تمام اعضای تیم است. توسعه‌دهندگان، تحلیلگران کسب‌وکار، Product Owner، DevOps و QA همگی در موفقیت STLC نقش دارند.

راهکار: فرهنگ «Quality is Everyone’s Responsibility» را در تیم تقویت کنید و همکاری میان اعضا را افزایش دهید.

خلاصه اشتباهات رایج

اشتباه	پیامد	راهکار
نداشتن Test Plan	تست‌های پراکنده	تهیه Test Plan
تحلیل ناقص نیازمندی‌ها	پوشش تست ضعیف	Review نیازمندی‌ها
تست فقط Happy Path	کشف دیرهنگام باگ‌ها	طراحی سناریوهای منفی
محیط تست نامناسب	نتایج غیرقابل اعتماد	محیط مشابه Production
Bug Report ناقص	رفع کند نقص‌ها	گزارش استاندارد
حذف Regression Testing	ایجاد باگ‌های جدید	اجرای تست رگرسیون
عدم استفاده از Metrics	تصمیم‌گیری ضعیف	پایش شاخص‌های تست

اجتناب از این اشتباهات باعث می‌شود STLC به یک فرآیند قابل پیش‌بینی، قابل اندازه‌گیری و مؤثر تبدیل شود. در بخش بعدی، بهترین روش‌ها (Best Practices) را بررسی می‌کنیم که توسط تیم‌های حرفه‌ای QA برای افزایش کیفیت و بهره‌وری استفاده می‌شوند.

---

Best Practices اجرای STLC

اجرای موفق STLC تنها به دنبال کردن مراحل آن محدود نمی‌شود. تیم‌های حرفه‌ای QA از مجموعه‌ای از بهترین روش‌ها (Best Practices) استفاده می‌کنند تا فرآیند تست کارآمدتر، قابل پیش‌بینی‌تر و باکیفیت‌تر باشد. رعایت این اصول علاوه بر کاهش هزینه‌های پروژه، احتمال کشف زودهنگام نقص‌ها را نیز افزایش می‌دهد.

۱. تست را از ابتدای پروژه آغاز کنید (Shift Left Testing)

بهترین زمان برای شروع تست، پس از اتمام توسعه نیست. تیم QA باید از همان مراحل تحلیل نیازمندی‌ها و طراحی سیستم در کنار تیم توسعه حضور داشته باشد تا ابهام‌ها و مشکلات احتمالی پیش از پیاده‌سازی شناسایی شوند.

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

۲. نیازمندی‌ها را قبل از طراحی Test Case مرور کنید

هرگونه ابهام در نیازمندی‌ها باید پیش از آغاز Test Analysis برطرف شود. مرور مشترک نیازمندی‌ها با Product Owner، تحلیلگر کسب‌وکار و توسعه‌دهندگان از ایجاد برداشت‌های متفاوت جلوگیری می‌کند.

۳. طراحی تست را بر اساس ریسک انجام دهید

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

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

۴. از تکنیک‌های طراحی تست استفاده کنید

استفاده از تکنیک‌های استاندارد باعث افزایش پوشش تست و کاهش تعداد Test Caseهای غیرضروری می‌شود.

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Pairwise Testing
• Error Guessing

۵. Test Caseها را ساده و قابل نگهداری بنویسید

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

۶. داده‌های تست را مدیریت کنید

Test Data باید واقعی، متنوع و به‌روز باشد. استفاده از داده‌های قدیمی یا ناسازگار می‌تواند باعث ایجاد نتایج گمراه‌کننده شود.

در صورت امکان، از داده‌های ناشناس‌سازی‌شده (Anonymized Data) استفاده کنید و از به‌کارگیری اطلاعات واقعی کاربران در محیط تست خودداری کنید.

۷. تست‌های تکراری را خودکار کنید

تمام تست‌ها برای خودکارسازی مناسب نیستند. اما تست‌هایی که به‌صورت مکرر اجرا می‌شوند، مانند Smoke Test، Regression Test و برخی API Testها، گزینه‌های مناسبی برای Automation Testing هستند.

نمونه ابزارها: Playwright، Selenium، Cypress و Appium.

۸. شاخص‌های تست (Metrics) را پایش کنید

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

• Test Coverage
• Pass Rate
• Defect Density
• Defect Leakage
• Execution Progress

۹. Bug Reportهای استاندارد بنویسید

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

۱۰. نتایج پروژه را مستندسازی کنید

در پایان هر پروژه، Test Summary Report، Test Metrics و Lessons Learned را ثبت کنید. این مستندات به بهبود فرآیند تست در پروژه‌های آینده کمک می‌کنند.

۱۱. همکاری مستمر بین اعضای تیم را حفظ کنید

کیفیت نرم‌افزار نتیجه همکاری تمام اعضای تیم است. QA، توسعه‌دهندگان، تحلیلگران کسب‌وکار، Product Owner و DevOps باید به‌صورت مستمر اطلاعات خود را به اشتراک بگذارند.

اصل مهم: Quality is Everyone’s Responsibility.

۱۲. STLC را متناسب با پروژه تنظیم کنید

STLC یک چارچوب است، نه یک فرآیند کاملاً ثابت. میزان مستندسازی، تعداد مراحل و ابزارهای مورد استفاده باید با اندازه تیم، نوع پروژه، سطح ریسک و مدل توسعه (Agile، Scrum، Kanban یا Waterfall) متناسب باشد.

خلاصه Best Practices

Best Practice	مزیت
Shift Left Testing	کشف زودهنگام نقص‌ها
Risk-Based Testing	استفاده بهینه از منابع
استفاده از Test Design Techniques	پوشش تست بهتر
Automation Testing	کاهش زمان اجرای تست
مدیریت صحیح Test Data	افزایش اعتبار نتایج
اندازه‌گیری Test Metrics	تصمیم‌گیری مبتنی بر داده
مستندسازی Lessons Learned	بهبود مستمر فرآیند تست
همکاری بین اعضای تیم	افزایش کیفیت محصول

رعایت این Best Practiceها باعث می‌شود STLC از یک فرآیند صرفاً مستنداتی به یک رویکرد عملی برای مدیریت کیفیت نرم‌افزار تبدیل شود. در بخش بعدی، به پرسش‌های متداول درباره STLC پاسخ می‌دهیم؛ سؤالاتی که هم در مصاحبه‌های استخدامی QA و هم در آزمون ISTQB Foundation به‌طور مکرر مطرح می‌شوند.

---

ابزارهای مورد استفاده در STLC

در پروژه‌های واقعی، اجرای STLC تنها با مستندات و Test Caseها انجام نمی‌شود. تیم‌های QA از ابزارهای مختلفی برای مدیریت نیازمندی‌ها، طراحی تست، اجرای تست، ثبت باگ، خودکارسازی و تهیه گزارش استفاده می‌کنند.

انتخاب ابزار مناسب به عواملی مانند اندازه پروژه، بودجه، فناوری‌های مورد استفاده و مدل توسعه (Agile یا Waterfall) بستگی دارد. با این حال، برخی ابزارها در صنعت نرم‌افزار به استانداردهای رایج تبدیل شده‌اند.

ابزارهای مدیریت پروژه و نیازمندی‌ها

ابزار	کاربرد	مرحله STLC
Jira	مدیریت User Story، Sprint و Bug	تقریباً تمام مراحل
Azure DevOps	مدیریت پروژه و تست	تقریباً تمام مراحل
Confluence	مستندسازی	Planning و Completion
Notion	مدیریت دانش تیم	Planning و Documentation

ابزارهای مدیریت تست

ابزار	کاربرد	مرحله STLC
TestRail	مدیریت Test Case و Test Run	Analysis تا Completion
Xray	مدیریت تست داخل Jira	Analysis تا Execution
Zephyr	مدیریت Test Case و گزارش تست	Analysis تا Completion
qTest	مدیریت تست سازمانی	تمام مراحل تست

ابزارهای تست خودکار

ابزار	کاربرد	مناسب برای
Playwright	تست UI، API و E2E	وب مدرن
Selenium	تست رابط کاربری	پروژه‌های مختلف
Cypress	تست Front-end	برنامه‌های JavaScript
Appium	تست موبایل	Android و iOS

ابزارهای تست API

ابزار	کاربرد
Postman	ارسال درخواست و تست API
SoapUI	تست SOAP و REST API
Insomnia	تست API
Bruno	API Client مبتنی بر فایل

ابزارهای CI/CD

ابزار	کاربرد
Jenkins	اجرای خودکار تست
GitHub Actions	CI/CD
GitLab CI/CD	Pipeline خودکار
Azure Pipelines	Build و Deployment

ابزارهای مدیریت محیط تست

ابزار	کاربرد
Docker	ایجاد محیط تست یکسان
Kubernetes	مدیریت Containerها
VirtualBox	ماشین مجازی
VMware	محیط تست مجازی

نمونه ابزارها در پروژه BlueShop

فعالیت	ابزار
مدیریت Sprint	Jira
نوشتن Test Case	TestRail
تست API	Postman
Automation Testing	Playwright
ثبت Bug	Jira
اجرای CI/CD	GitHub Actions
محیط تست	Docker

آیا باید همه این ابزارها را یاد بگیریم؟

خیر. هیچ QA Engineer تمام ابزارهای موجود را به‌صورت حرفه‌ای نمی‌شناسد. مهم‌تر از حفظ نام ابزارها، درک نقش آن‌ها در فرآیند STLC است.

برای بیشتر موقعیت‌های شغلی Junior یا Mid-Level، آشنایی با مجموعه زیر نقطه شروع مناسبی است:

• Jira
• TestRail یا Xray
• Postman
• Playwright یا Selenium
• Git و GitHub
• GitHub Actions یا Jenkins (در حد مقدماتی)

نکته: ابزارها به مرور زمان تغییر می‌کنند، اما مفاهیم STLC ثابت می‌مانند. اگر فرآیند تست را به‌خوبی درک کنید، یادگیری ابزارهای جدید بسیار ساده‌تر خواهد بود.

جمع‌بندی

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

اکنون که با مراحل STLC، خروجی هر مرحله، اشتباهات رایج، بهترین روش‌ها و ابزارهای متداول آشنا شدید، در بخش بعدی به پرسش‌های متداول (FAQ) پاسخ می‌دهیم؛ پرسش‌هایی که کاربران، داوطلبان آزمون ISTQB و مصاحبه‌کنندگان فنی بیش از همه مطرح می‌کنند.

---