گفتن «STLC شش مرحله دارد» ساده است؛ اجرای آن وقتی پرداخت، تخفیف، داده تست، درگاه بیرونی و مهلت Release همزمان تغییر میکنند دشوار میشود. اگر خروجی هر مرحله به تصمیم بعدی وصل نباشد، STLC فقط یک نمودار آموزشی میماند.
در این راهنمای پروژهمحور، یک Release فروشگاهی را از تحلیل نیازمندی تا Test Closure اجرا میکنیم. Risk register، برنامه یکصفحهای، مدل پوشش، چکلیست محیط، گزارش اجرا و خلاصه تصمیم انتشار همگی قابلکپیاند. برای تعریف مفاهیم و تفاوت STLC/SDLC، ابتدا مقاله Pillar چرخه حیات تست نرمافزار را ببینید؛ این صفحه روی «چگونه اجرا کنیم» تمرکز دارد.
برای واژگان و اصول رسمیِ فعالیتها و فرایند تست نیز به سرفصل ISTQB CTFL v4.۰.۱ مراجعه کنید. این منبع، «شش مرحله STLC» را بهعنوان تنها توالی جهانی تجویز نمیکند؛ مدل این مقاله یک روش عملی برای سازماندهی خروجیهاست.
اصل مهم: مراحل STLC الزاماً صف Waterfall نیستند. در یک Sprint میتوان نیاز را تحلیل کرد، تست را طراحی کرد، Build کوچک را اجرا کرد و با یادگیری تازه به Plan برگشت. خروجی هر مرحله باید ریسک و تصمیم بعدی را روشنتر کند.
سناریوی نمونه: Release تخفیف و پرداخت فروشگاه
تیم میخواهد در یک Sprint دهروزه این تغییرها را منتشر کند:
- کد تخفیف درصدی با حداقل مبلغ و سقف تخفیف؛
- امکان استفاده یکباره برای هر کاربر؛
- انتقال به درگاه پرداخت آزمایشی؛
- پردازش callback موفق، ناموفق، تکراری و دیررس؛
- نمایش وضعیت سفارش و امکان Retry پرداخت.
هدف Release
کاربر واجد شرایط باید مبلغ صحیح را بپردازد و Order پس از هر پاسخ درگاه دقیقاً یک وضعیت معتبر داشته باشد. هیچ callback تکراری نباید اثر مالی یا تغییر State دوباره ایجاد کند.
محدودیتها
- دسترسی به Sandbox درگاه در بعضی ساعتها ناپایدار است؛
- پرداخت واقعی خارج از Scope است؛
- دو مرورگر اصلی و Android داخل Scope، iOS خارج Scope این Release؛
- داده Production یا شماره تلفن واقعی مجاز نیست؛
- Feature flag برای Rollout محدود وجود دارد.
نقشه شش مرحله و خروجی تصمیمپذیر
| مرحله | پرسش اصلی | خروجی حداقلی | تصمیم بعدی |
|---|---|---|---|
| ۱. تحلیل نیازمندی | چه چیزی و با چه ریسکی باید درست باشد؟ | سؤال، Rule، Risk register و Testability need | Scope و فرضهای Plan |
| ۲. برنامهریزی | با چه رویکرد، ظرفیت و معیار تصمیم؟ | Test plan یکصفحهای | اولویت طراحی و محیط |
| ۳. طراحی تست | کدام مدل، داده و Oracle؟ | Coverage model، Cases/Charters و Trace | نیاز داده و ابزار |
| ۴. آمادگی محیط | آیا Build، Config، Data و Signal قابلاعتمادند؟ | Readiness evidence | Go/No-go اجرای رسمی |
| ۵. اجرا | چه چیزی آموختیم و Risk چه تغییری کرد؟ | Result، Bug، Blocker و Risk update | Fix/Retest/Regression/Release |
| ۶. خاتمه | شواهد چه تصمیمی را پشتیبانی میکنند؟ | Test summary، ریسک باقیمانده و Archive | Release و بهبود بعدی |
مرحله ۱: تحلیل نیازمندی و ریسک
قواعد کسبوکار را به مثال تبدیل کنید
Requirement اولیه میگوید: «کاربر میتواند از کد تخفیف استفاده کند.» این جمله برای تست کافی نیست. سؤالهای زیر آن را قابلآزمون میکنند:
- حداقل مبلغ قبل یا بعد از هزینه ارسال محاسبه میشود؟
- سقف تخفیف چگونه Round میشود؟
- کد به کاربر، سفارش، کالا یا گروه محصول محدود است؟
- استفاده یکباره در چه لحظهای مصرف میشود: Apply یا پرداخت موفق؟
- اگر پرداخت Fail شود، امکان Retry با همان تخفیف وجود دارد؟
- تغییر قیمت در Tab دیگر چه اثری دارد؟
- منبع حقیقت مبلغ، Cart، Order یا Payment request است؟
روش تبدیل ابهام به سؤال در راهنمای تحلیل نیازمندی توضیح داده شده است.
Risk register نمونه
| ID | ریسک | اثر | نشانه/کنترل پیشنهادی | مالک |
|---|---|---|---|---|
| R1 | مبلغ Order و درگاه متفاوت است | زیاد؛ شکست مالی/پشتیبانی | Assert سرور، Contract و Reconciliation | Backend + QA |
| R2 | callback تکراری دوباره اعمال میشود | بحرانی | Idempotency و State invariant | Backend |
| R3 | مصرف کد با Fail پرداخت از بین میرود | متوسط/زیاد | State model و Retry scenarios | Product |
| R4 | داده یا Sandbox اجرای تست را مسدود میکند | متوسط؛ تأخیر Signal | Stub + health check + data factory | Platform |
| R5 | پیام خطا اطلاعات حساب را افشا میکند | زیاد؛ Privacy/Security | Message review و authorization tests | Security/Product |
خروجی و Exit این مرحله
- Ruleهای مصوب و سؤالهای باز صاحب تصمیم دارند؛
- ریسکهای اصلی و فرضها ثبت شدهاند؛
- نیازهای Testability مانند Stub، Clock و Correlation ID مشخصاند؛
- Scope اولیه برای Planning قابلدفاع است.
Exit به معنی بستهشدن ابدی تحلیل نیست. اگر در اجرا Rule تازه کشف شد، Risk register و Plan باید باز شوند.
مرحله ۲: برنامه تست یکصفحهای
هدف و Scope
هدف: ساخت شواهد برای درستی مبلغ، مجوز، State و تابآوری callback
داخل Scope: API تخفیف/پرداخت، UI وب/Android، State سفارش، Retry
خارج Scope: پرداخت واقعی، تست ظرفیت Production، iOS، تسویه بانکی انتهابهانتها
فرض: Sandbox و Stub هر دو رفتار قراردادی مصوب دارند
رویکرد و لایهها
- Unit/Component: محاسبه، Round، سقف، Idempotency و Transition؛
- API/Integration: قرارداد درگاه، Authorization، Timeout و callback؛
- UI: Journey حیاتی، نمایش مبلغ/پیام و Retry؛
- Exploratory: دو Tab، Refresh، تغییر زمان و اختلال شبکه؛
- Non-functional: Threshold محدود API، امنیت پایه و دسترسپذیری پیام.
نقش و تصمیم
| کار | Responsible | Decision/Approval | همکار |
|---|---|---|---|
| Rule تخفیف | Product | Product owner | QA/Backend |
| Stub و Environment | Platform/Backend | Tech lead | QA |
| Test design و اجرا | QA + Developers | QA lead برای شواهد | Product |
| پذیرش ریسک Release | Release owner | صاحب مجاز کسبوکار | QA/Tech/Ops |
QA بهتنهایی مالک کیفیت یا تصمیم تجاری نیست. قالب جامع Test Plan را میتوان برای پروژه بزرگتر گسترش داد.
Entry و Exit معیارمحور
Entry اجرای رسمی: Build شناسهدار، Ruleهای حیاتی مصوب، محیط سالم، داده قابلساخت، Log/Correlation و Unit/Component suite حیاتی سبز.
Exit پیشنهادی: تمام ریسکهای بحرانی شواهد معتبر یا پذیرش مستند دارند؛ مسیر حیاتی روی Scope هدف اجرا شده؛ هیچ Blocker بدون مالک نیست؛ نتیجه Invalid/Blocked شفاف است؛ Rollback/Monitoring آماده است.
«۱۰۰٪ Pass» یا «صفر Defect» بهتنهایی Exit قابلاعتماد نیست.
مرحله ۳: طراحی تست، داده و Traceability
مدل قواعد تخفیف
| قانون | کاربر واجد شرایط | حداقل مبلغ | زمان معتبر | نتیجه |
|---|---|---|---|---|
| D1 | بله | رسیده | بله | اعمال تا سقف |
| D2 | خیر | — | — | رد بدون تغییر مبلغ |
| D3 | بله | نرسیده | بله | رد با پیام حداقل |
| D4 | بله | رسیده | خیر | رد/حذف طبق Rule |
برای هر Rule، مقدار «حداقل −۱، برابر، +۱» و سقف تخفیف را تست کنید. جدول واقعی باید قواعد ترکیبی مانند کالای مستثنا و مصرف قبلی را نیز داشته باشد.
State model سفارش/پرداخت
Created → AwaitingPayment → PaymentPending → Paid و شاخههای Failed، Cancelled و Expired را مشخص کنید. Invariantها:
- Paid نباید دوباره اثر مالی بگیرد؛
- callback متعلق به Order دیگر رد میشود؛
- مبلغ callback با مبلغ قابلپرداخت تطبیق دارد؛
- Transition نامعتبر Log و پاسخ کنترلشده دارد؛
- Retry از State مجاز آغاز میشود.
Traceability سبک
| Risk/Rule | تست Component | تست API | Journey/UI | Signal |
|---|---|---|---|---|
| R1 مبلغ | C-01..06 | A-03, A-08 | J-01 | Order/Payment amounts |
| R2 Idempotency | C-10 | A-11 duplicate callback | — | effect count + trace |
| R3 Retry | C-14 states | A-15 | J-03 | state history |
Traceability برای یافتن Gap است، نه تولید ماتریس بزرگ. الگوی فیلدها و تکنیکهای کمینهسازی در راهنمای طراحی Test Case آمده است.
Test data plan
- حساب مصنوعی: جدید، قبلاً استفادهکرده، غیرفعال و Role غیرمجاز؛
- Order: زیر مرز، روی مرز، بالای مرز، کالای مستثنا و چندکالایی؛
- کد: معتبر، منقضی، آینده، استفادهشده، حروف/فاصله متفاوت؛
- callback: موفق، ناموفق، Timeout، تکراری، دیررس و مبلغ ناهماهنگ؛
- Cleanup: لغو/حذف امن و تکرارپذیر بدون داده شخصی.
مرحله ۴: آمادهسازی محیط و Readiness gate
چکلیست Build و Configuration
- Commit/Artifact و نسخه DB migration ثبت شده است.
- Feature flag و Endpoint درگاه برای محیط تست تأیید شدهاند.
- Secret در Vault/CI است و در Ticket یا Repository نیست.
- Timezone، Locale و Currency شناخته شدهاند.
- نسخه Web/Android و Browser/Device داخل Scope مشخصاند.
چکلیست داده و وابستگی
- Data factory حساب و Order را مستقل میسازد.
- Stub سناریوهای Delay، Duplicate و Error را کنترل میکند.
- Sandbox با Health check جدا از آزمون کسبوکار بررسی میشود.
- Clock برای انقضا قابلکنترل است یا روش جایگزین امن داریم.
- Cleanup پس از Fail نیز اجرا میشود.
چکلیست Observability
- Correlation ID در Request، callback و Log قابلردیابی است.
- تغییر State و اثر مالی Audit event دارد.
- خطای محصول از خطای محیط/Stub قابلتفکیک است.
- PII، Token و اطلاعات بانکی در Log Mask شدهاند.
راهاندازی با مدیریت مستمر محیط یکسان نیست؛ مالکیت، Drift و دسترسی باید در طول چرخه ادامه یابد. جزئیات در راهنمای آمادهسازی محیط تست آمده است.
تصمیم Readiness
اگر Sandbox قطع است اما Stub برای ریسکهای داخلی معتبر است، میتوان Component/API داخلی را اجرا و تست قرارداد واقعی را Blocked گزارش کرد. شروع بخشی مجاز است، به شرط اینکه Gap در گزارش Release پنهان نشود.
مرحله ۵: اجرای تست و بهروزرسانی ریسک
ترتیب پیشنهادی اجرا
- Health check محیط و Build؛
- Smoke مسیر حیاتی؛
- تست Component/API بر اساس ریسک؛
- Integration با Sandbox؛
- Journeyهای UI و پلتفرم؛
- Session اکتشافی تغییر و Failure mode؛
- Retest و Regression مبتنی بر Impact.
وضعیت نتیجهها
- Pass: Oracle معتبر و Evidence کافی؛
- Fail: ناسازگاری مشاهدهشده، نیازمند Triage؛
- Blocked: پیششرط/محیط مانع اجرا؛
- Invalid: تست، داده یا Setup نتیجه معتبر نمیدهد؛
- Not Run: اجرا نشده؛ با دلیل و Risk؛
- Accepted risk: تصمیم مجاز و زماندار، نه Pass.
Fail الزاماً Defect محصول نیست. ابتدا Product/Test/Data/Environment را Triage کنید. Workflow اجرایی در راهنمای اجرای تست و Stateهای Defect در چرخه عمر باگ توضیح داده شدهاند.
نمونه گزارش روزانه کوتاه
Build: checkout-4.2.17 / Env: staging-ir-2
ریسکهای معتبرشده: R1 مبلغ، بخش اصلی R3 Retry
یافته مهم: callback دیررس بعد از Expired، Order را Paid میکند (B-204)
Blocked: سناریوی Sandbox بانک از 14:20؛ تست قرارداد نهایی اجرا نشده
Flaky/Invalid: 2 مورد داده؛ از Pass Rate حذف و مالک تعیین شد
تصمیم بعدی: Fix B-204، Retest Stateها، حفظ Release flag روی 5%
Triage یافته B-۲۰۴
اثر: سفارش منقضی پس از callback دیررس Paid میشود و احتمال مغایرت عملیات دارد. تیم Rule را تأیید میکند، Fix را روی Transition guard میزند، Retest همان نقص و Regression Stateهای Paid/Cancelled/Expired اجرا میشود. شدت و اولویت با اثر و زمان Release تعیین میشوند، نه صرفاً برچسب Tester.
مرحله ۶: Test Closure و تصمیم انتشار
خلاصه شواهد
| بخش | وضعیت | Evidence/Gap |
|---|---|---|
| مبلغ و سقف تخفیف | معتبر | Component + API + یک Journey |
| Idempotency callback | معتبر پس از Fix | Duplicate/late/race tests |
| Retry پرداخت | معتبر با محدودیت | Web/Android؛ iOS خارج Scope |
| قرارداد Sandbox | بخشی Blocked | Health outage؛ Stub pass، اجرای واقعی ناقص |
| Performance محدود | در Threshold محیط | Production capacity test نشده |
ریسک باقیمانده
Integration نهایی با Sandbox کامل نشده است. Mitigation: Rollout پنجدرصدی، مانیتورینگ نرخ callback نامعتبر، Alert مغایرت مبلغ، امکان خاموشکردن Feature flag و مالک On-call مشخص.
گزینههای تصمیم
- No-go: تا اجرای قرارداد واقعی؛
- Release محدود: با Flag، Monitoring و Rollback؛
- Accept: صاحب مجاز ریسک با تاریخ بازبینی میپذیرد.
QA شواهد و Recommendation میدهد؛ مالک مجاز Release تصمیم را ثبت میکند. قالب کامل گزارش خاتمه تست برای Archive و Sign-off مناسب است.
Archive و یادگیری
- Plan، Risk register، Cases/Charters و Resultها؛
- Build/Config و Dataset نسخهبندیشده؛
- Bugها، تصمیم پذیرش ریسک و Evidence؛
- Runbook، Monitoring و Rollback؛
- درس آموخته و اقدام دارای مالک/موعد.
درس این Release: Stub داخلی کافی بود تا نقص State کشف شود، اما Sandbox تنها مسیر تأیید قرارداد بیرونی است. Health check و پنجره جایگزین باید پیش از Sprint بعد برنامهریزی شوند.
Timeline نمونه برای Sprint دهروزه
| روز | فعالیتهای همپوشان STLC | خروجی |
|---|---|---|
| ۱ | Refinement، Rule و Risk | سؤال، Risk register، Testability |
| ۲ | Plan و طراحی مدل همزمان با Development | Scope، State/Decision models |
| ۳–۴ | Component tests، Data factory، Stub | Feedback زودهنگام و Readiness |
| ۵ | Build یکپارچه، API و Contract | Result و Gap محیط |
| ۶–۷ | UI، Mobile و Exploratory | Bug/Risk update |
| ۸ | Fix، Retest و Regression | Evidence جدید |
| ۹ | Closure draft، Monitoring/Rollback | Recommendation |
| ۱۰ | Decision و Archive؛ ادامه پایش | Release record |
این Timeline نسخه تجویزی Scrum نیست. Sprint با Release یکی نیست و بعضی تستها یا پایشها بیرون مرز Sprint ادامه دارند.
حداقل متریکهای مفید برای این نمونه
- ریسکهای بحرانی با شواهد معتبر / کل ریسکهای بحرانی داخل Scope؛
- p50/p95 زمان از Build تا Signal قابلاقدام؛
- Blocked/Invalid rate با علت؛
- Flaky rate بدون پنهانکردن Rerun؛
- زمان تا Triage برای Severityهای بالا؛
- رخداد و اثر مشتری پس از Rollout.
تعداد Test Case، درصد Pass یا تعداد Bug بهتنهایی اثربخشی STLC را نشان نمیدهد. Metric باید یک تصمیم را تغییر دهد.
Anti-patternهای اجرای STLC
- تبدیل شش مرحله به Gateهای خطی و Handoff سنگین؛
- کپی Test plan بدون پیوند با Risk و Release؛
- نوشتن Case پیش از روشنشدن Rule و Oracle؛
- اعلام Ready محیط فقط چون URL باز میشود؛
- محاسبه Pass Rate بدون Blocked و Not Run؛
- یکیگرفتن هر Fail با Defect محصول؛
- توقف Closure در «درصد تست اجراشده»؛
- مالککردن QA برای تمام کیفیت و پذیرش ریسک؛
- بستن Cycle بدون بازگرداندن Incident و درس آموخته؛
- ثبت داده واقعی یا Secret در Artifact تست.
چکلیست قابلکپی STLC
تحلیل
- هدف، کاربر، Rule، Risk و Unknown روشناند.
- Testability و Observability نیازها ثبت شدهاند.
برنامهریزی
- داخل/خارج Scope، رویکرد، نقش و Entry/Exit تعریف شدهاند.
- ریسک زمان/محیط و Contingency داریم.
طراحی
- مدل پوشش، داده، Oracle و Traceability سبک آمادهاند.
- تست در لایه مناسب و قابلتکرار است.
محیط
- Build/Config/Data/Dependency/Signal تأیید شدهاند.
- Secret و PII محافظت و Cleanup تست شده است.
اجرا
- همه Statusها با Evidence و علت معتبر ثبت میشوند.
- Risk، Bug، Blocker و تصمیم روزانه بهروزند.
خاتمه
- شواهد، Gap، ریسک باقیمانده و Recommendation روشناند.
- Decision، Monitoring، Rollback و Archive مالک دارند.
پرسشهای متداول
آیا مراحل STLC باید به ترتیب کامل شوند؟
خیر. وابستگی منطقی دارند، اما در Agile و Continuous delivery همپوشان و تکرارشوندهاند. یافته اجرا میتواند Requirement، Plan و Test design را تغییر دهد.
Entry و Exit criteria برای هر مرحله لازم است؟
برای کنترل آمادگی مفیدند، اما باید سبک و ریسکمحور باشند. Criterion نباید Handoff یا انتظار بیارزش بسازد؛ استثنا و تصمیم شروع بخشی نیز میتواند مستند شود.
آیا صد درصد Pass شرط خاتمه STLC است؟
خیر. Scope، اعتبار نتیجه، Blocked/Not Run، شدت نقص، Risk باقیمانده و Mitigation مهماند. ممکن است با پذیرش ریسک منتشر یا با Pass بالا متوقف شوید.
در تیم کوچک چه Artifactهایی حداقلیاند؟
Risk/Scope، چند مدل یا Charter، Result قابلردیابی، Bugهای مهم و خلاصه ریسک انتشار. میتوان آنها را در یک صفحه و Tracker نگه داشت؛ هدف تصمیم و حافظه تیم است، نه حجم سند.
STLC با Scrum تناقض دارد؟
خیر، اگر آن را چرخه فعالیت و بازخورد بدانیم، نه فازهای Waterfall. تحلیل، طراحی، اجرا و یادگیری میتوانند داخل یک Story و Sprint چندبار تکرار شوند.
جمعبندی
نمونه عملی STLC نشان میدهد ارزش شش مرحله در نام آنها نیست؛ در اتصال خروجیهاست. سؤال نیازمندی Risk میسازد، Risk Plan و Test design را هدایت میکند، محیط Signal معتبر میدهد، اجرا مدل را اصلاح میکند و Closure شواهد را به تصمیم انتشار و یادگیری بعدی تبدیل میکند. از قالبها شروع کنید، اما آنها را به اندازه تیم و ریسک محصول سبک نگه دارید.
