Pipeline سبز است، اما نسخه منتشرشده سفارش تکراری می‌سازد. یا برعکس، Pipeline سه ساعت طول می‌کشد و تیم برای تحویل فوری آن را دور می‌زند. هر دو وضعیت نشان می‌دهند «داشتن تست در CI» الزاماً تست مداوم نیست. Continuous Testing باید سریع‌ترین بازخورد قابل اعتماد درباره ریسک همان تغییر را در مناسب‌ترین نقطه تحویل بدهد.
این راهنما Continuous Testing را از شعار به طراحی اجرایی تبدیل می‌کند: چه تستی در Pull Request اجرا شود، کدام Check بعد از استقرار بیاید، Quality Gate چگونه Fail کند، با Flaky Test چه کنیم و چگونه داده Production بدون افشای اطلاعات حساس وارد حلقه یادگیری شود. یک Pipeline نمونه برای Checkout فروشگاه ایرانی نیز ارائه می‌شود.
Continuous Testing یا تست مداوم چیست؟
Continuous Testing رویکردی برای تولید پیوسته اطلاعات کیفیت و ریسک در سراسر جریان تحویل نرم‌افزار است. تست‌های خودکار، تحلیل‌های ایستا، Contract Check، Deployment Verification، Monitoring و بازخورد کاربر در نقاط مناسب قرار می‌گیرند تا تیم بتواند درباره Merge، Deploy، Rollout یا Rollback تصمیم بگیرد.
این رویکرد فقط Automation نیست و فقط CI هم نیست:
- Test Automation: اجرای ماشینی Check مشخص؛
- Continuous Integration: ادغام مکرر تغییرها با Build و Feedback خودکار؛
- Continuous Delivery: نگه‌داشتن نرم‌افزار در وضعیت قابل انتشار؛
- Continuous Deployment: استقرار خودکار تغییر پذیرفته‌شده در Production؛
- Continuous Testing: طراحی Feedbackهای کیفیت و ریسک در تمام این جریان.
مقاله تست چابک مسئولیت و جریان کیفیت در تیم را توضیح می‌دهد؛ این مقاله معماری اجرایی Feedback در Delivery Pipeline را عمیق می‌کند.
Continuous Testing چه چیزی نیست؟
- اجرای کل Regression Suite با هر Commit نیست.
- هدف «۱۰۰٪ اتوماسیون» یا «۱۰۰٪ Coverage» نیست.
- یک Stage با نام QA در انتهای Pipeline نیست.
- جایگزین Exploratory Testing، Usability Research یا قضاوت ریسک نیست.
- معادل سبزشدن همه Jobها بدون بررسی صحت Business نیست.
- مجوز تست بی‌محافظ روی کاربران Production نیست.
- مجموعه‌ای از Toolها بدون Owner، Policy و اقدام نیست.
Continuous یعنی Feedback به‌صورت تکرارشونده و متصل به تغییر جریان دارد؛ نه اینکه هر Test در هر لحظه اجرا شود.
اصول طراحی یک Pipeline کیفیت
۱. Feedback متناسب با هزینه تغییر
Checkهای سریع و محلی باید خطای رایج را پیش از ساخت Artifact بگیرند. Testهای کندتر و محیط‌محور بعد از عبور Change از Gateهای ارزان اجرا می‌شوند. هدف، کم‌کردن زمان تا اطلاعات قابل اقدام است.
۲. ریسک‌محور، نه تعدادمحور
تغییر متن Footer و تغییر منطق پرداخت Risk یکسان ندارند. Path، Dependency، Feature Flag و Business Criticality می‌توانند Suite و Gate متفاوت فعال کنند.
۳. Build once, promote the same artifact
Artifactی که در Staging آزموده می‌شود باید همان Artifact قابل ترفیع به Production باشد؛ Rebuild در هر محیط می‌تواند متغیر جدیدی وارد کند. Configuration و Secret محیط جدا می‌مانند، اما Binary/Image قابل ردیابی است.
۴. Testability و Observability جزو محصول‌اند
Health Check، Trace ID، API ایجاد داده، Clock قابل کنترل، Feature Flag و Telemetry اجرای تست را قابل اعتماد می‌کنند. Pipeline نمی‌تواند محصول غیرقابل مشاهده را با Wrapper بیشتر درمان کند.
۵. شکست باید اقدام مشخص داشته باشد
هر Gate Owner، Severity، Evidence و مسیر رفع دارد. هشدار بدون تصمیم به نویز تبدیل می‌شود. اگر نتیجه نمی‌تواند Merge، Deploy، Rollout یا Backlog را تغییر دهد، ارزش جایگاهش را بازبینی کنید.
معماری لایه‌ای Continuous Testing
| نقطه | Feedback مناسب | هدف زمانی | تصمیم |
|---|---|---|---|
| Local/Pre-commit | Lint، Format، Unit هدفمند، Secret Check | ثانیه تا چند دقیقه | آیا Change آماده Push است؟ |
| Pull/Merge Request | Build، Unit/Component، Static Analysis، Contract و API سریع | چند دقیقه | آیا Merge امن است؟ |
| Main/Artifact | Integration، Migration، Image Scan و Smoke | دقیقه تا ده‌ها دقیقه | آیا Artifact قابل ترفیع است؟ |
| Ephemeral/Staging | E2E حیاتی، Accessibility Check، Security/Performance Smoke و Exploratory | متناسب با Release Risk | آیا Deploy/Release مجاز است؟ |
| Post-deploy | Deployment Verification، Synthetic و Check داده/Queue | دقایق اول | ادامه Rollout یا Rollback؟ |
| Production | SLI/SLO، Error Budget، Log/Trace، Canary و Customer Signal | پیوسته | ادامه، توقف، Rollback یا یادگیری؟ |
«هدف زمانی» عدد جهانی نیست. یک تیم ممکن است Feedback Pull Request را زیر ده دقیقه هدف بگیرد؛ تیم دیگر با Build سنگین Budget متفاوت دارد. Budget را با رفتار تیم و هزینه انتظار تعیین کنید.
Fast Lane و Slow Lane
Fast Lane
تست‌هایی با Signal بالا، Runtime کوتاه و Flakiness نزدیک صفر که هر Change را محافظت می‌کنند: Unit، Component، Contract، APIهای حیاتی و Static Check. این Lane باید توسعه‌دهنده را سریع به علت شکست برساند.
Slow Lane
تست‌های پرهزینه مانند Full E2E Matrix، Performance عمیق، DAST، Soak و Compatibility گسترده. آن‌ها می‌توانند روی Main، Nightly، Release Candidate یا Schedule اجرا شوند، اما Failureشان نباید در داشبورد دفن شود.
Event-driven Lane
بر اساس Change یا Event فعال می‌شود: Migration Test هنگام تغییر Schema، Mobile Matrix هنگام تغییر UI مشترک، Contract Suite هنگام تغییر OpenAPI و Load Smoke هنگام تغییر Query حساس. این انتخاب باید شفاف و قابل Audit باشد تا Test مهم ناخواسته Skip نشود.
Quality Gate چیست و چگونه طراحی می‌شود؟
Quality Gate یک شرط تصمیم است، نه صرفاً نمودار. Gate خوب این اجزا را دارد:
- Scope: کدام Artifact، Environment و Change؛
- Signal: Test، Metric یا Policy؛
- Threshold: حد Pass/Fail و بازه اندازه‌گیری؛
- Owner: چه کسی Failure را بررسی می‌کند؛
- Evidence: Report، Log، Trace و Diff؛
- Action: Block، Rollback، Alert یا Risk Acceptance؛
- Exception: چه کسی، تا چه زمان و با چه Riskی می‌تواند Override کند.
نمونه Gateهای خوب
- Unit/Component حیاتی: هر Failure، Merge را Block کند.
- Contract: Breaking Change تأییدنشده، Artifact را Block کند.
- Migration: Forward و Rollback روی Snapshot تستی Pass شوند.
- Security: Secret آشکار یا آسیب‌پذیری بحرانی تأییدشده Block شود.
- Performance Smoke: Regression مشخص نسبت به Baseline با Margin توافق‌شده Block شود.
- Canary: عبور Error/Latency از Guardrail، Rollout را متوقف یا Rollback کند.
Gate بر Percentage خام Coverage یا تعداد Bug بدون Context، رفتار قابل بازی تولید می‌کند. Threshold را از ریسک و هدف محصول بسازید.
چه تستی در کدام مرحله اجرا شود؟
| نوع | بهترین نقطه رایج | دلیل |
|---|---|---|
| Unit/Static | Local و Pull Request | سریع و نزدیک علت |
| Component | Pull Request | منطق با وابستگی کنترل‌شده |
| Contract | Pull Request Provider/Consumer | کشف Breaking Change پیش از Deploy |
| Integration | Artifact/Ephemeral Environment | مرز DB، Queue و Service |
| API Regression | Pull Request هدفمند + Main کامل‌تر | Signal بالا با هزینه کمتر از UI |
| UI Critical Path | Main/Staging | تأیید سفر نهایی با تعداد محدود |
| Performance | Smoke در PR/Main؛ Load/Soak زمان‌بندی‌شده | تفکیک Regression سریع از ظرفیت عمیق |
| Security | SAST/Dependency زود؛ DAST/Pen Test در نقاط مناسب | هزینه و Scope متفاوت |
| Exploratory/Usability | هم‌زمان با توسعه و Preview/Staging | کشف Unknown؛ نه Job ماشینی |
| Synthetic/SLO | پس از Deploy و Production | رفتار واقعی Environment و Release |
برای مرزهای سرویس، تست یکپارچه‌سازی و برای طراحی Request/Assertion، تست API را مبنا قرار دهید.
Pipeline نمونه Checkout فروشگاه ایرانی
مرحله Pull Request
- Lint، Type Check و Secret Scan؛
- Unit برای مبلغ، تخفیف، ریال/تومان و State؛
- Component برای سبد و رزرو موجودی؛
- Contract درگاه و سرویس سفارش؛
- API Check برای Authorization و Idempotency؛
- ساخت Image و SBOM/Dependency Scan طبق سیاست تیم.
مرحله Artifact/Main
- Deploy همان Image به Environment موقت؛
- Migration Forward و Rollback با Dataset نماینده؛
- Integration با DB، Queue و Stub/Sandbox درگاه؛
- Smoke ثبت سفارش و Callback؛
- Publish Report، Trace و Artifact با Masking.
مرحله Staging/Release Candidate
- E2E خرید موفق، شکست پرداخت و Retry؛
- Exploratory Charter برای درخواست هم‌زمان و وضعیت نامشخص؛
- Accessibility و RTL/عدد فارسی-لاتین؛
- Performance Smoke روی Checkout؛
- Security Check Role، Object Access و داده حساس.
تست‌های Performance عمیق طبق راهنمای تست عملکرد و Security تخصصی طبق راهنمای تست امنیت در Lane مناسب اجرا می‌شوند؛ آن‌ها را به یک Scanner سریع تقلیل ندهید.
پس از Deploy
- Deployment Verification برای Health و مسیر کوچک Synthetic؛
- Canary روی درصد محدود با Guardrail Error/Latency؛
- بررسی Queue، Duplicate Order، Callback و Reconciliation؛
- Rollback خودکار یا توقف Rollout در عبور از Threshold؛
- تبدیل Incident یا رفتار ناشناخته به Test/Monitor مناسب.
نمونه Pipeline مفهومی
change
├─ validate: lint + unit + static + secret
├─ build: immutable artifact
├─ verify-fast: component + contract + api
├─ deploy-preview
├─ verify-system: integration + smoke + critical-e2e
├─ assess-risk: security/performance/accessibility signals
├─ promote
├─ verify-deployment
└─ progressive-rollout: SLI guardrails + rollbackترتیب دقیق به معماری و Risk بستگی دارد. برای پیاده‌سازی پایه در Jenkins یا GitLab CI، مقاله راه‌اندازی Pipeline تست خودکار را ببینید.
Test Data در Continuous Testing
داده مشترک و دستی، Pipeline را غیرقابل تکرار می‌کند. Strategy داده باید این قابلیت‌ها را داشته باشد:
- Factory/Seed نسخه‌بندی‌شده؛
- شناسه یکتا برای Parallel Run؛
- State آغازین و Cleanup قابل پیش‌بینی؛
- Subset نماینده از توزیع Production بدون داده شخصی؛
- Scenarioهای Boundary، Fraud، Timeout و Long-tail؛
- Masking و Retention برای Report/Artifact؛
- مالک Schema و سازگاری Migration؛
- Clock و Timezone قابل کنترل برای تاریخ شمسی و Job زمان‌بندی‌شده.
کپی Database Production بدون ناشناس‌سازی، راه‌حل TDM نیست. داده تست باید حداقل لازم، قابل حذف و تحت سیاست دسترسی باشد.
Environment و Service Virtualization
Environment باید سریع ساخته، قابل ردیابی و تا حد نیاز شبیه Production باشد. Container و Infrastructure as Code کمک می‌کنند، اما تفاوت Network، Managed Service، CDN، Autoscaling و حجم داده همچنان باید ثبت شود.
- Preview Environment برای Changeهای UI/Service؛
- Database یا Schema Namespace مستقل؛
- Stub برای Failureهای سخت‌تولید؛
- Contract Test برای جلوگیری از Drift Stub؛
- Sandbox برای Integration تأییدشده سرویس ثالث؛
- Test Double با Latency، Rate Limit و Error واقعی‌نما؛
- Cleanup خودکار و TTL برای کنترل هزینه.
یک Stub همیشه سبز می‌تواند Integration شکسته را پنهان کند. Virtualization را با Contract و تست دوره‌ای Sandbox/واقعی متعادل کنید.
Flaky Test Policy
Flaky Test شکست و عبور بدون تغییر مرتبط در SUT است. Retry خام آن را حل نمی‌کند؛ فقط Signal را مبهم می‌کند. Policy پیشنهادی:
- نتیجه تلاش اول حفظ و Flaky علامت‌گذاری شود.
- Retry محدود فقط برای جمع‌آوری Evidence باشد.
- مالک و Issue خودکار ساخته شود.
- تست بحرانی Flaky بی‌صدا از Gate حذف نشود.
- Quarantine زمان‌دار با Risk و جایگزین Monitor/Check داشته باشد.
- علت در دسته Data، Environment، Synchronization، Product یا Test ثبت شود.
- Quarantine Age و Flaky Rate به‌عنوان بدهی Pipeline گزارش شوند.
اگر Suite اعتماد تیم را از دست بدهد، سریع‌ترین Pipeline هم Continuous Testing موفقی ندارد. معیارهای انتخاب و سلامت Framework در راهنمای فریم‌ورک اتوماسیون آمده‌اند.
گزارش و Artifact قابل اقدام
Job قرمز باید بدون جست‌وجوی طولانی این اطلاعات را بدهد:
- Commit، Artifact Digest، Environment و Feature Flag؛
- Test/Rule و مرحله‌ای که شکست رخ داده؛
- Expected و Actual؛
- Log/Trace/Network/Screenshot مرتبط؛
- Data ID غیرحساس و Correlation ID؛
- تفاوت با Baseline یا اجرای قبلی؛
- مالک و Runbook اقدام.
طبق مستندات GitLab Unit Test Reports، Reportهای JUnit می‌توانند شکست‌ها را در Merge Request نشان دهند؛ اما صرف Upload Report لزوماً Job را Fail نمی‌کند و Script باید Exit Status درست بدهد. همیشه رفتار واقعی Gate را با یک شکست عمدی آزمون کنید.
Production Feedback، SLO و Error Budget
Monitoring جای Test نیست؛ داده‌ای است که فرض‌های تست را در Environment واقعی ارزیابی می‌کند. Google SRE درباره SLO پیشنهاد می‌کند Indicator از چیزی شروع شود که برای کاربر مهم است، مانند Availability، Latency، Throughput و Correctness.
در Progressive Delivery، Guardrail می‌تواند شامل این موارد باشد:
- نرخ موفقیت Checkout از دید کاربر؛
- p95/p99 Latency نسخه جدید در برابر Control؛
- Error و Timeout درگاه؛
- Duplicate Order یا Reconciliation Gap؛
- Crash/Client Error و Support Signal؛
- مصرف Error Budget.
Error Budget مجوز بی‌ملاحظه نیست؛ زبان مشترکی برای تعادل Reliability و سرعت تغییر است. Policy سازمان باید مشخص کند مصرف سریع Budget چه اثری بر Rollout و اولویت Reliability دارد.
متریک‌های سلامت Continuous Testing
| متریک | پرسش | هشدار تفسیر |
|---|---|---|
| Feedback Time | تغییر تا نتیجه قابل اقدام چقدر طول می‌کشد؟ | Queue و Runtime را جدا کنید |
| Pipeline Success | چه سهمی بدون Failure زیرساخت/تست عبور می‌کند؟ | سبز بودن می‌تواند ناشی از Gate ضعیف باشد |
| Flaky Rate | چه سهمی بدون Change مرتبط نتیجه عوض می‌کند؟ | Retry نباید آن را پنهان کند |
| Change Failure Rate | چه سهمی از تغییرها به اختلال یا Fix فوری منجر می‌شود؟ | تعریف Change/Failure ثابت باشد |
| Recovery Time | پس از شکست تحویل چقدر تا Restore طول می‌کشد؟ | Median و Tail را ببینید |
| Escaped Impact | چه ریسک مهمی از Gate عبور کرده؟ | Severity بهتر از Count خام است |
| Gate Yield | هر Gate چند Failure واقعی و قابل اقدام گرفته؟ | Gate پرنویز ارزش کمی دارد |
| Quarantine Age | تست خارج‌شده چند روز بدون حل مانده؟ | تست بحرانی را جدا کنید |
راهنمای DORA درباره Value Stream پیشنهاد می‌کند Flow و Bottleneckها را در کنار شاخص‌های تحویل و پایداری ببینید. متریک را برای بهبود سیستم به کار ببرید، نه رتبه‌بندی فرد.
نقشه راه پیاده‌سازی در چهار مرحله
مرحله ۱: Baseline
Value Stream فعلی، زمان انتظار، Suiteها، Incidentها و Gateهای دستی را ترسیم کنید. یک سفر حیاتی و یک Repository را انتخاب کنید.
مرحله ۲: Fast Feedback
Build تکرارپذیر، Unit/Component/API حیاتی، Report و Failure Ownership را در Pull Request پایدار کنید. Flakyهای موجود را اندازه بگیرید.
مرحله ۳: Environment و Promotion
Artifact واحد، Preview Environment، Data Factory، Integration/Contract و Deployment Verification را اضافه کنید. Gateها را با Failure عمدی بیازمایید.
مرحله ۴: Progressive Delivery و Learning
Canary/Feature Flag، SLO Guardrail، Rollback، Production Feedback و Incident-to-Test را وارد حلقه کنید. Slow Laneهای Performance/Security را بر Risk زمان‌بندی کنید.
از خرید چند Tool هم‌زمان شروع نکنید. کوچک‌ترین حلقه‌ای را بسازید که Feedback Time و Change Risk را قابل مشاهده بهتر کند، سپس گسترش دهید.
خطاهای رایج در Continuous Testing
- همه تست‌ها در PR: Pipeline کند و قابل دورزدن می‌شود.
- Test Pyramid به‌عنوان سهمیه: تعداد لایه‌ها بدون توجه به معماری و Risk تعیین می‌شود.
- Rebuild بین محیط‌ها: چیزی غیر از Artifact آزموده‌شده منتشر می‌شود.
- Gate روی Coverage خام: Check کم‌ارزش برای عبور عدد ساخته می‌شود.
- Retry تا سبز: Flakiness و Failure واقعی پنهان می‌شوند.
- Shared Data: Parallel Run همدیگر را خراب می‌کنند.
- Stub بدون Contract: Environment همیشه سبز اما Integration واقعی شکسته است.
- Artifact ناکافی: تیم Pipeline را دوباره اجرا می‌کند چون علت معلوم نیست.
- Manual Approval عمومی: کلیک انسانی بدون اطلاعات Risk فقط Queue می‌سازد.
- Production به‌عنوان آزمایشگاه: Guardrail، Consent و Blast Radius نادیده گرفته می‌شود.
- Dashboard بدون Action: Metric زیاد اما Owner و Runbook وجود ندارد.
ملاحظات تیم‌های ایرانی
- Runner، Package Registry، Container Registry و Artifact Storage را با دسترسی پایدار طراحی کنید.
- Dependency خارجی را Cache و نسخه‌گذاری کنید؛ Build نباید به دانلود لحظه‌ای شکننده وابسته باشد.
- درگاه و پیامک را بدون هماهنگی در Pipeline عمومی صدا نزنید؛ Stub، Contract و Sandbox Lane جدا بسازید.
- Secret و داده کارت/تلفن/کد ملی را از Log، Video و Report Mask کنید.
- تاریخ شمسی، ریال/تومان، RTL و عدد فارسی/لاتین را در Suite و Data Factory وارد کنید.
- Latency و قطعی شبکه داخلی/بین‌المللی را از Failure محصول تفکیک کنید.
- Cloud Dashboard پولی را تنها محل Evidence نکنید؛ Export و نگهداری داخلی داشته باشید.
- Override Gate باید Audit، Expiry و Risk Acceptance روشن داشته باشد.
چک‌لیست Continuous Testing
- هر Stage سؤال و تصمیم مشخص دارد.
- Fast Lane کوتاه، پایدار و نزدیک علت است.
- Slow Lane Owner و اقدام دارد و فراموش نمی‌شود.
- Test Selection بر Risk و Change شفاف است.
- یک Artifact بین Environmentها Promote می‌شود.
- Quality Gate دارای Threshold، Owner، Evidence و Exception Policy است.
- Test Data مستقل، ناشناس و قابل Cleanup است.
- Environment و Service Double با Contract کنترل می‌شوند.
- Flaky نتیجه تلاش اول، Issue و Quarantine زمان‌دار دارد.
- Report حتی در Failure منتشر و Secretها Mask می‌شوند.
- Post-deploy Verification و Rollback آزموده شده‌اند.
- SLO/Guardrail از دید کاربر تعریف شده است.
- Production Feedback به Backlog و Test برمی‌گردد.
- Feedback Time، Change Failure و Gate Noise بازبینی می‌شوند.
جمع‌بندی
Continuous Testing یعنی معماری بازخورد، نه انباشت Job. Check سریع نزدیک Change، تست سیستم روی Artifact واقعی، Gate مبتنی بر Risk و Guardrail پس از Deploy باید یک زنجیره قابل ردیابی بسازند. کیفیت این زنجیره با سرعت و اعتماد سنجیده می‌شود.
برای شروع، یک Pipeline و یک سفر حیاتی را انتخاب کنید. زمان انتظار، Failure Noise و ریسک‌های گریخته را Baseline بگیرید؛ سپس Fast Lane، Artifact واحد و Deployment Verification را پایدار کنید. پس از آن سراغ Progressive Delivery و Test Selection هوشمند بروید.
سوالات متداول درباره تست مداوم
Continuous Testing چیست؟
طراحی و اجرای مداوم Feedbackهای کیفیت و ریسک در سراسر جریان تحویل است؛ از Local و Pull Request تا Staging، Deployment و Production. هدف تصمیم سریع‌تر و قابل اعتمادتر درباره Change است.
آیا همه تست‌ها باید با هر Commit اجرا شوند؟
خیر. تست‌های سریع و با Signal بالا در Fast Lane اجرا می‌شوند؛ Suiteهای پرهزینه در Main، Nightly، Release یا Event مناسب. Test Selection باید بر Risk و Change شفاف باشد.
Quality Gate چه تفاوتی با Report دارد؟
Report اطلاعات نشان می‌دهد؛ Gate آن اطلاعات را به تصمیم Block، Promote، Rollout یا Rollback متصل می‌کند. Gate باید Threshold، Owner، Evidence و Exception Policy داشته باشد.
با Flaky Test در CI چه کنیم؟
نتیجه اول را حفظ کنید، Retry محدود را فقط برای Evidence به کار ببرید، Owner و Issue بسازید و Quarantine را زمان‌دار کنید. Flaky بحرانی نباید بی‌صدا از حفاظت Release حذف شود.
آیا Monitoring بخشی از Continuous Testing است؟
Monitoring بازخورد Production و Guardrail انتشار را فراهم می‌کند، اما جای Test پیش از انتشار نیست. SLI/SLO، Synthetic، Canary و Incident Learning حلقه را با واقعیت کاربر کامل می‌کنند.
