وقتی نسخه نرمافزار به تیم QA میرسد، برای شروع تست دیر نشده است؛ اما اگر تست تازه از همان لحظه آغاز شود، بخش بزرگی از فرصت پیشگیری از خطا از دست رفته است. چرخه حیات تست نرمافزار یا STLC کمک میکند فعالیتهای کیفیت از تحلیل نیازمندی تا گزارش اختتام، هدفمند، قابلردیابی و متناسب با ریسک پیش بروند.
در این راهنمای جامع میآموزید STLC چیست، چه تفاوتی با SDLC دارد، شش مرحله اصلی آن کداماند، در هر مرحله چه ورودی و خروجیای انتظار میرود و چگونه همین چرخه را در تیم Agile اجرا کنیم. یک مثال عملی از قابلیت پرداخت فروشگاه اینترنتی نیز نشان میدهد این مفاهیم در پروژه واقعی چگونه کنار هم قرار میگیرند.
فهرست مطالب
چرخه حیات تست نرمافزار (STLC) چیست؟
Software Testing Life Cycle یا STLC مجموعهای از فعالیتهای ساختاریافته برای برنامهریزی، طراحی، اجرا، ارزیابی و بهبود تست نرمافزار است. این چرخه مشخص میکند تیم کیفیت چه چیزی را، چرا، چگونه، در چه محیطی و با چه معیار پایان بررسی کند.
STLC یک نسخه ثابت و یکسان برای همه سازمانها ندارد. بعضی مدلها مدیریت عیب را مرحلهای جدا میدانند و بعضی آن را فعالیتی پیوسته در اجرای تست قرار میدهند. نام مرحلهها نیز ممکن است متفاوت باشد. مهم، منطق چرخه است: نیازمندی و ریسک را بفهمیم، رویکرد را برنامهریزی کنیم، پوشش بسازیم، شرایط اجرا را آماده کنیم، شواهد جمع کنیم و در پایان از نتیجهها یاد بگیریم.
این چرخه فقط متعلق به تیم QA نیست. Product Owner، تحلیلگر کسبوکار، توسعهدهنده، طراح، DevOps، امنیت و نماینده کسبوکار در نقاط مختلف آن نقش دارند. کیفیت زمانی بهتر میشود که این همکاری از ابتدا شکل بگیرد.
تفاوت STLC و SDLC چیست؟
SDLC چرخه کلی ساخت و نگهداری نرمافزار است؛ از ایده و تحلیل تا طراحی، توسعه، استقرار و عملیات. STLC بر فعالیتهای تست و اطلاعات کیفیت درون همین چرخه تمرکز دارد. STLC زیرمجموعه جداافتادهای پس از Coding نیست، بلکه در تمام SDLC جریان دارد.
| معیار | SDLC | STLC |
|---|---|---|
| هدف | ساخت و تحویل محصول نرمافزاری | ارزیابی کیفیت و کاهش ریسک محصول |
| شروع | ایده و نیاز کسبوکار | همزمان با نیازمندی و تحلیل ریسک |
| فعالیتهای نمونه | تحلیل، طراحی، کدنویسی، استقرار | برنامه تست، طراحی تست، اجرا و گزارش |
| خروجی | محصول و نسخههای آن | شواهد کیفیت، عیبها و ارزیابی ریسک |
| مسئولیت | کل تیم محصول و مهندسی | تیم کیفیت با مشارکت ذینفعان فنی و کسبوکار |
در رویکردهای مدرن، فعالیتهای تست به چپ منتقل میشوند (Shift Left) تا عیب نیازمندی و طراحی زود پیدا شود و به راست نیز ادامه مییابند (Shift Right) تا رفتار واقعی محصول با مشاهدهپذیری و بازخورد تولید بررسی شود.
مراحل اصلی STLC در یک نگاه
| مرحله | پرسش کلیدی | خروجیهای مهم |
|---|---|---|
| ۱. تحلیل نیازمندی | چه چیزی و با چه ریسکی باید تست شود؟ | ابهامها، فهرست ریسک، قابلیت تستپذیری، RTM اولیه |
| ۲. برنامهریزی تست | با چه رویکرد، منابع و معیارهایی؟ | Test Plan، برآورد، دامنه، معیار ورود/خروج |
| ۳. توسعه تستکیس | چگونه پوشش قابلردیابی بسازیم؟ | سناریو، تستکیس، چکلیست، داده تست، اسکریپت خودکار |
| ۴. محیط تست | کجا و با چه تنظیماتی اجرا کنیم؟ | محیط آماده، Build، دسترسی، داده و Smoke نتیجهدار |
| ۵. اجرای تست | رفتار واقعی با انتظار چه تفاوتی دارد؟ | نتایج اجرا، شواهد، گزارش عیب، Retest و Regression |
| ۶. اختتام | چه آموختیم و ریسک باقیمانده چیست؟ | Test Summary، تصمیم انتشار، درسآموخته و اقدام بهبود |
این مراحل در پروژه Waterfall ممکن است مرز زمانی مشخصتری داشته باشند. در Agile، بیشتر آنها در هر اسپرینت با ابعاد کوچکتر تکرار میشوند.
مرحله اول STLC: تحلیل نیازمندیها
هدف این مرحله فهم رفتار مورد انتظار، ریسک کسبوکار و قابلیت تستپذیری است. تیم QA سند، User Story، طرح رابط، قرارداد API، قواعد کسبوکار و وابستگیها را مرور میکند و سؤالهایی را که بر طراحی تست اثر میگذارند، پیش از توسعه مطرح میکند.
فعالیتهای اصلی
- تشخیص نیازمندیهای عملکردی و غیرکارکردی؛
- بررسی وضوح و اندازهپذیری معیارهای پذیرش؛
- شناسایی ریسکهای محصول، امنیت، داده و عملیات؛
- تعیین سطوح و انواع تست احتمالی؛
- بررسی نیاز به محیط، ابزار، Mock یا داده خاص؛
- ثبت ارتباط نیازمندیها با سناریوهای تست در RTM؛
- هماهنگی ابهامها با Product Owner، BA و تیم فنی.
معیار ورود و خروج نمونه
ورود: User Story یا نیازمندی اولیه، طراحی و ذینفع پاسخگو در دسترس است. خروج: ابهامهای بحرانی تعیینتکلیف شدهاند، رفتار قابل تست است و ریسکهای اصلی ثبت شدهاند.
برای پرسشها و خروجیهای این مرحله، راهنمای تحلیل نیازمندیها در STLC را بخوانید.
مرحله دوم STLC: برنامهریزی تست
در Test Planning، رویکرد تیم برای کنترل ریسک مشخص میشود. برنامه تست نباید فقط فهرست ابزارها یا جدول زمان باشد؛ باید توضیح دهد چه چیزی در دامنه است، چه چیزی نیست، کدام ریسکها اولویت دارند و برای توقف یا پایان تست چه معیارهایی داریم.
اجزای کلیدی Test Plan
- هدف، دامنه و فرضها؛
- ریسکها و اولویت تست؛
- سطوح و انواع تست؛
- رویکرد دستی و اتوماسیون؛
- نقشها، منابع و نیاز آموزشی؛
- محیط، داده، ابزار و وابستگی؛
- برآورد زمان و نقاط تحویل؛
- معیار ورود، تعلیق، ازسرگیری و خروج؛
- فرمت گزارش و مسیر Escalation؛
- برنامه مدیریت عیب و رگرسیون.
ورود: ریسک و دامنه اولیه شناخته شدهاند. خروج: برنامه مورد توافق است، مسئولیت و منابع روشناند و مانع بحرانی بدون مالک باقی نمانده است.
جزئیات عملی را در مقاله برنامهریزی تست جامع در فاز دوم STLC ببینید.
مرحله سوم STLC: توسعه تستکیس و داده تست
در این مرحله، نیازمندی و ریسک به پوشش قابلاجرا تبدیل میشوند. بسته به زمینه، خروجی میتواند تستکیس گامبهگام، Charter تست اکتشافی، Checklist، مجموعه تست API یا اسکریپت خودکار باشد.
فعالیتهای اصلی
- انتخاب تکنیک طراحی تست متناسب با منطق؛
- نوشتن سناریوهای مثبت، منفی، مرزی و خطا؛
- تعریف پیششرط، داده، اقدام و نتیجه مورد انتظار؛
- اولویتبندی تستها بر اساس ریسک؛
- بازبینی تستکیسها و حذف تکرار بیارزش؛
- ساخت یا Maskکردن داده تست؛
- طراحی Automation در سطح مناسب؛
- تکمیل Traceability میان نیازمندی، تست و ریسک.
تکنیکهایی مانند تقسیمبندی همارزی، مقدار مرزی، جدول تصمیم و انتقال حالت کمک میکنند تستها با تعداد کمتر، پوشش منطقی بهتری داشته باشند.
ورود: معیار پذیرش و رفتار هدف روشن است. خروج: پوشش بازبینی شده، داده قابلاستفاده و تستها برای اجرا آمادهاند.
در راهنمای توسعه تستکیس در فاز سوم STLC نمونهها و معیارهای تستکیس مؤثر را بخوانید.
مرحله چهارم STLC: آمادهسازی محیط تست
نتیجه تست فقط زمانی قابل اعتماد است که نسخه، تنظیمات، سرویسها و داده محیط شناختهشده باشند. محیط ناپایدار میتواند هم False Failure ایجاد کند و هم عیب واقعی را پنهان سازد.
فعالیتهای اصلی
- تعیین معماری و شباهت لازم با تولید؛
- استقرار Build و ثبت نسخه هر سرویس؛
- آمادهسازی پایگاه داده، حسابها، دسترسی و Secretها؛
- راهاندازی Mock، Stub یا Sandbox سرویس بیرونی؛
- فعالکردن Log، Metric، Trace و ابزار مشاهدهپذیری؛
- بررسی دستگاه، مرورگر و سیستمعامل هدف؛
- اجرای Smoke Test برای تأیید سلامت پایه؛
- ثبت محدودیتها و تفاوتهای محیط با Production.
ورود: نیازهای محیط و Build مشخصاند. خروج: Smoke پاس شده، دسترسی و داده آمادهاند و محدودیتهای محیط مستند شدهاند.
راهنمای راهاندازی محیط تست در فاز چهارم STLC چالشها و چکلیست کاملتری ارائه میکند.
مرحله پنجم STLC: اجرای تست و مدیریت عیب
تیم تست نسخه موردنظر را اجرا، نتیجه واقعی را با انتظار مقایسه و شواهد را ثبت میکند. اجرای تست فقط تغییر وضعیت به Pass یا Fail نیست؛ هر نتیجه باید به نسخه، محیط، داده و تست مرتبط باشد.
فعالیتهای اصلی
- اجرای Smoke و سپس مجموعههای اولویتدار؛
- ثبت نتیجه، لاگ، Screenshot، ویدئو یا Trace لازم؛
- گزارش عیب با مراحل بازتولید و اثر روشن؛
- Triage برای تعیین شدت، اولویت و مالک؛
- Retest اصلاح و Regression بخشهای متاثر؛
- اجرای تست اکتشافی برای ریسکهای ناشناخته؛
- بهروزرسانی پوشش، RTM و داشبورد وضعیت؛
- گزارش مانع و ریسک باقیمانده به ذینفعان.
گزارش باگ خوب چه دارد؟
عنوان دقیق، نسخه و محیط، پیششرط، داده، مراحل بازتولید، نتیجه واقعی، نتیجه مورد انتظار، شدت، نرخ وقوع و شواهد. در محصول ایرانی، مواردی مانند ارقام فارسی، RTL، تقویم و واحد تومان/ریال را نیز در داده و محیط ثبت کنید.
ورود: Build قابلتست، محیط سالم و داده آماده است. خروج: تستهای برنامهریزیشده اجرا شدهاند، عیبهای بحرانی تعیینتکلیف شدهاند و وضعیت ریسک روشن است.
برای اجرای عملی، مقاله اجرای تست و کشف نقصها در فاز پنجم STLC را ببینید.
مرحله ششم STLC: اختتام چرخه تست
Test Closure به معنی «دیگر هیچ باگی نداریم» نیست. این مرحله بررسی میکند آیا معیارهای خروج محقق شدهاند، چه ریسکهایی باقی مانده، چه تصمیمی برای انتشار گرفته شده و چه چیزی باید در چرخه بعد بهتر شود.
فعالیتهای اصلی
- جمعبندی پوشش و نتایج Pass/Fail/Blocked؛
- فهرست عیبهای باز و اثر آنها؛
- مقایسه برنامه با اجرای واقعی و تحلیل انحراف؛
- ارزیابی ریسک باقیمانده و توصیه انتشار؛
- آرشیو تستکیس، داده، اسکریپت و شواهد؛
- تحلیل علتهای پرتکرار عیب و Escape؛
- برگزاری Retrospective و تعیین اقدام بهبود با مالک و موعد؛
- تهیه Test Summary/Closure Report برای ذینفعان.
ورود: اجرای برنامهریزیشده پایان یافته یا تصمیم توقف گرفته شده است. خروج: وضعیت کیفیت و ریسک بهروشنی گزارش شده، تصمیم ثبت شده و اقدامهای یادگیری مالک دارند.
راهنمای بستهشدن چرخه تست و درسآموختهها ساختار گزارش اختتام را توضیح میدهد.
مدیریت عیب در کدام مرحله قرار میگیرد؟
Defect Management را نباید فقط یک مرحله پس از اجرا دید. عیب ممکن است در Review نیازمندی، طراحی، تحلیل استاتیک، اجرای تست یا محیط تولید کشف شود. چرخه عیب معمولاً شامل ثبت، بازبینی، اولویتبندی، تخصیص، اصلاح، Retest، بستن یا Deferredکردن است.
شدت (Severity) اثر فنی/کاربری عیب را بیان میکند؛ اولویت (Priority) فوریت کسبوکار برای رسیدگی را. یک غلط املایی روی کمپین فردا میتواند اولویت بالا ولی شدت پایین داشته باشد؛ یک خطای نادرِ تخریب داده، شدت بسیار بالا دارد حتی اگر بازتولید آن سخت باشد.
STLC در Agile و DevOps چگونه اجرا میشود؟
در Agile، STLC حذف نمیشود؛ کوتاه، تکرارشونده و پیوسته میشود:
- Refinement: تحلیل نیازمندی، ریسک و قابلیت تست؛
- Sprint Planning: برنامه تست، ظرفیت، داده و وابستگی؛
- Development: Review، تست واحد، API و ساخت Automation؛
- CI: تحلیل استاتیک، تست سریع و Quality Gate؛
- در طول اسپرینت: تست اکتشافی، یکپارچگی، UI و مدیریت عیب؛
- قبل از انتشار: رگرسیون مبتنی بر ریسک و بررسی معیار خروج؛
- پس از انتشار: Monitoring، تحلیل خطا و بازخورد کاربر؛
- Retrospective: اختتام سبک و اقدام بهبود چرخه بعد.
هدف، تحویل یک بسته بزرگ تست در انتهای اسپرینت نیست. تستر باید از آغاز Story همراه باشد و تیم با Pyramid یا مدل مناسب، بازخورد سریع را در سطح پایینتر ایجاد کند.
مثال عملی STLC: قابلیت پرداخت فروشگاه اینترنتی
فرض کنید تیم میخواهد پرداخت آنلاین و ثبت سفارش را توسعه دهد. این مثال فرضی نشان میدهد هر مرحله چه اثری دارد.
تحلیل نیازمندی
- وضعیت سفارش در پرداخت موفق، ناموفق، لغوشده و نامشخص چیست؟
- اگر Callback دوبار برسد، سفارش چند بار نهایی میشود؟
- مبلغ داخلی ریال است یا تومان و تبدیل کجا انجام میشود؟
- در Timeout، کاربر چگونه نتیجه نهایی را میبیند؟
- چه دادهای در Log مجاز است و چه دادهای باید Mask شود؟
برنامهریزی
مسیر پرداخت و یکپارچگی درگاه ریسک بالا دارد. تیم تست API و Integration را در اولویت میگذارد، Sandbox درگاه و حساب تست میخواهد، تست کارایی Callback را برنامهریزی میکند و معیار خروج را «نبود عیب باز با شدت بحرانی در ثبت یا مبلغ سفارش» تعریف میکند.
طراحی تست
سناریوهای موفق، ردشده، Timeout، Callback تکراری، مبلغ دستکاریشده، Refresh، بازگشت با Back و قطعی شبکه طراحی میشوند. داده برای سفارش با موجودی کافی/ناکافی و کد تخفیف آماده میشود.
محیط
نسخه Backend، Frontend و سرویس سفارش ثبت میشود؛ Sandbox درگاه متصل است؛ Log همبستگی درخواستها فعال و داده اولیه Reset میشود. Smoke ایجاد سفارش و ورود به درگاه پاس میشود.
اجرا
تیم مشاهده میکند Callback تکراری دو رکورد پرداخت میسازد. باگ با شناسه سفارش، زمان، Trace ID و نتیجه مورد انتظار گزارش میشود. پس از اصلاح Idempotency، Retest و رگرسیون مسیر پرداخت اجرا میشود.
اختتام
همه تستهای حیاتی پاس شدهاند؛ یک مشکل کمریسک در متن پیام باقی مانده و برای نسخه بعد پذیرفته شده است. گزارش، ریسک و تصمیم را ثبت میکند و اقدام بهبود «افزودن Contract Test برای Callback در CI» مالک و موعد میگیرد.
شاخصهای مفید در STLC
متریک باید به تصمیم کمک کند، نه فقط داشبورد را پر کند:
- پوشش نیازمندی و ریسک؛
- نرخ اجرای تست و وضعیت Blocked؛
- توزیع عیب بر اساس شدت و ماژول؛
- Defect Leakage یا عیب فراری به مرحله بعد/تولید؛
- زمان متوسط رفع و Retest عیب؛
- نرخ Flaky Test و پایداری محیط؛
- نسبت تستهای سریع در CI به تستهای End-to-End؛
- ریسکهای باز و تصمیم پذیرش آنها.
تعداد تستکیس یا باگ بهتنهایی شاخص کیفیت فرد یا محصول نیست. افزایش باگ ممکن است نتیجه پوشش بهتر باشد و کاهش آن شاید از نبود تست کافی ناشی شود.
اشتباهات رایج در اجرای STLC
- شروع فعالیت QA فقط پس از تحویل Build؛
- استفاده از یک Test Plan ثابت برای همه پروژهها؛
- نادیدهگرفتن نیازمندیهای غیرکارکردی و عملیات؛
- نوشتن تستکیس زیاد بدون اتصال به ریسک؛
- سپردن همه پوشش به تست UI و فراموشکردن Unit/API؛
- محیط نامشخص و داده غیرقابلتکرار؛
- گزارش وضعیت بدون ریسک باقیمانده؛
- بستن چرخه بدون Retrospective و اقدام قابلپیگیری؛
- فرض اینکه کیفیت فقط مسئولیت QA است.
چکلیست اجرای چرخه حیات تست
- هدف، دامنه و ریسکهای محصول ثبت شدهاند.
- معیار پذیرش روشن، قابل تست و قابل اندازهگیری است.
- رویکرد تست، سطحها، ابزار و مسئولیتها مشخصاند.
- تستها به نیازمندی و ریسک قابلردیابیاند.
- محیط، Build، داده و دسترسی نسخهدار و کنترلشدهاند.
- نتیجه اجرا همراه با شواهد و زمینه ثبت میشود.
- Retest و Regression بر اساس اثر تغییر انجام میشوند.
- معیار خروج و ریسک باقیمانده برای ذینفعان روشن است.
- درسآموخته به اقدام مشخص با مالک و موعد تبدیل میشود.
سوالات متداول
STLC مخفف چیست؟
مخفف Software Testing Life Cycle، یعنی چرخه حیات تست نرمافزار است؛ مجموعه فعالیتهایی که تست را از تحلیل تا اختتام سازماندهی میکند.
STLC چند مرحله دارد؟
مدل رایج شش مرحله اصلی دارد: تحلیل نیازمندی، برنامهریزی، توسعه تستکیس، آمادهسازی محیط، اجرا و اختتام. برخی منابع مدیریت عیب یا طراحی تست را جدا میکنند؛ مهمتر از تعداد، پوشش فعالیتهای ضروری است.
تفاوت STLC و SDLC چیست؟
SDLC چرخه کامل ساخت و نگهداری محصول است؛ STLC بر برنامهریزی و اجرای فعالیتهای ارزیابی کیفیت درون همان چرخه تمرکز دارد. این دو همپوشان و مکملاند.
آیا STLC فقط برای پروژه Waterfall است؟
خیر. در Agile، مرحلهها در هر Story و Sprint کوچکتر و تکرارشونده اجرا میشوند و در DevOps با CI/CD، تحلیل استاتیک، اتوماسیون و Monitoring پیوستگی بیشتری پیدا میکنند.
معیار پایان تست چیست؟
معیار خروج باید پیشاپیش تعریف شود؛ مانند پوشش ریسکهای حیاتی، اجرای تستهای اولویتدار، تعیینتکلیف عیبهای بحرانی، پایداری قابلقبول و گزارش ریسک باقیمانده. صفر باگ معیار واقعبینانهای نیست.
جمعبندی
STLC نقشه راهی برای تبدیل نیازمندی و ریسک به شواهد قابلاعتماد درباره کیفیت است. چرخه خوب با پرسش زودهنگام آغاز میشود، تست را در سطح مناسب طراحی میکند، محیط و داده را کنترل میکند و در پایان فقط نتیجه Pass/Fail نمیدهد؛ ریسک باقیمانده و درسآموخته را نیز روشن میسازد. این چرخه را متناسب با زمینه تیم سبک یا رسمی کنید، اما تحلیل، برنامه، پوشش، اجرا و یادگیری را حذف نکنید.
