Dashboard میگوید هر ۹ مرحلهٔ چرخهٔ توسعه سبز است، چرخه فقط ۱۱ دقیقه طول کشیده و هیچ مورد حلنشدهای نداریم؛ آیا حلقهٔ کیفیت بسته شده است؟ نه. شاید Review انجام شده اما کسی نتیجه را نگرفته، Pipeline سبز است اما روی Build دیگری اجرا شده، Canary هشدار داده ولی Owner ندارد، یا Action ثبت شده اما هرگز Verification نشده است. «فعالیت انجام شد» با «بازخورد به تصمیم و اصلاح رسید» یکی نیست.
ادغام تست در چرخه حیات توسعه نرمافزار یعنی برای Risk و Decisionهای مهم، حلقههای بازخورد نسخهدار بسازیم: Event/Trigger → Quality Question → مناسبترین Control در زودترین نقطهٔ توانمند → Observation/Evidence → Delivery/Acknowledgement → Action/Decision → Verification → Correction؛ سپس در نقطهای دیرتر و نمایندهتر، Blind spotهای کنترل زودهنگام را دوباره بسنجیم.
این راهنما تعریف عمومی تست نرمافزار، فهرست مراحل STLC یا دستور «تستر را زودتر به جلسه ببرید» نیست. واحد طراحی این صفحه Quality Feedback Loop است: کدام Signal، برای چه مصرفکنندهای، در چه زمان و با چه Evidence باید به Action برسد؟
پاسخ کوتاه: تست چگونه در SDLC ادغام میشود؟
ابتدا Flow تغییر و Decisionهای آن را رسم کنید، نه فقط نام فازها را. برای هر Risk، پرسش و Consequence دیررسبودن Signal را بنویسید. سپس زودترین نقطهای را انتخاب کنید که آن پرسش را واقعاً میتواند پاسخ دهد؛ Control، Oracle، Subject و Evidence را تعریف کنید؛ Signal را به Owner و Decision authority برسانید؛ Action را Verify کنید؛ و در سطحی با Fidelity بیشتر دوباره Observation بگیرید. تست زودهنگام مکمل تست دیرتر است، نه جایگزین آن.
- Earlier بدون قابلیت مشاهده، Oracle و مصرفکننده فقط Activity زودتر است.
- Continuous به معنای اجرای همهٔ تستها با هر Commit نیست؛ یعنی بازخورد مناسب در Event مناسب.
- Shared quality مالکیت را حذف نمیکند؛ هر Loop به Response owner و Decision authority نیاز دارد.
- Green stage وضعیت Loop نیست؛ Delivered، Acknowledged، Actioned و Verified باید جدا باشند.
- Late feedback همیشه بد یا حذفشدنی نیست؛ بعضی رفتارها فقط در System، Canary یا Operation نمایندهاند.
مرز این مقاله با Shift-left، Continuous Testing و Shift-right
| موضوع | پرسش اصلی | مالک محتوایی |
|---|---|---|
| نقش تستر در فعالیت زودهنگام | تستر چگونه Quality Question را به Interface و Evidence تبدیل کند؟ | نقش تستر در Shift-left |
| Feedback Lane در تحویل | کدام Control در PR، Merge، Nightly یا Release اجرا شود؟ | Continuous Testing در CI/CD |
| Observation پس از استقرار | Canary، Synthetic، Feature Flag و Rollback چگونه ایمن باشند؟ | Shift-right و Testing in Production |
| اتصال کل جریان | Signal در نقاط SDLC چگونه تا Action، Verification و Correction بسته شود؟ | همین راهنما |
چرا مدل «تست در انتها» ناکافی است؟
اگر تنها Control معنادار پس از تکمیل یک Batch بزرگ ظاهر شود، ابهامهای Basis، تصمیمهای Architecture، خطاهای Interface و نبود Testability مدت زیادی بدون Signal میمانند. هنگام Failure نیز Change set، Owner و Cause candidateها زیادند؛ Fix ممکن است Rework چند Artifact و Dependency بخواهد. مشکل اصلی «سمت راست نمودار» نیست؛ بزرگی فاصلهٔ Event تا Observation و Observation تا Action است.
بااینحال تشبیههای «فونداسیون ساختمان» را قانون اقتصادی نرمافزار ندانید. بعضی Findingهای دیرهنگام گرانترند، بعضی نه؛ Detection زودهنگام نیز هزینه، Skill، Environment و False signal دارد. Baseline محلی و نوع Failure مهمتر از ضریبهای ثابت صد یا هزار برابر است.
چرا مدل «همهچیز را زودتر تست کن» هم ناکافی است؟
Control زودهنگام معمولاً سریعتر و ارزانتر است چون Subject کوچک و Dependency محدود دارد؛ ولی Fidelity کمتر و Blind spot بیشتری هم دارد. Review طراحی، رفتار Browser واقعی را مشاهده نمیکند؛ Component fake، Contract واقعی Vendor را ثابت نمیکند؛ Load model، رفتار Traffic ناشناخته را تضمین نمیکند. اگر همهٔ Evidence را چپ ببریم، خطر فقط از «کشف دیر» به «اطمینان زودرس» تبدیل میشود.
قاعدهٔ بهتر: earliest capable observation + later representative confirmation. هر پرسش را در اولین نقطهای بسنجید که Control و Oracle معتبر دارد، سپس ادعا را در نقطهای با Integration/Fidelity/Population مناسب دوباره محدود و تأیید کنید.
Quality Feedback Loop چیست؟
Feedback Loop یک زنجیرهٔ قابل ردیابی از رخداد تا تغییر تأییدشده است. گزارش یا Fail بهتنهایی Loop نیست. اگر Signal تولید شود ولی به فرد توانمند نرسد، اگر Ack شود ولی Action نداشته باشد، یا Fix انجام شود ولی Verification نشود، Loop باز مانده است.
QualityFeedbackLoop
loopId / version / supersedes / status
flow / product / goal / outcome / risk
decision / boundedQuestion / claimLimit
trigger / eventAt
earliestCapablePoint / laterRepresentativePoint
control / immutableSubject / population
environment / data / oracle
observation / observedAt / evidence / unknowns
emittedAt / receivedAt / acknowledgedAt / latencySLO
responseOwner / action / dueAt / decisionAuthority
verification / correction / affectedDecision
blindSpots / retention / redaction
costBaseline / missedFeedbackConsequence
measure / guardrail / reviewDueStage Checklist با Feedback Loop فرق دارد
| Stage checklist | Feedback Loop | خطر تفاوت |
|---|---|---|
| Requirement review انجام شد | ابهام R-۱۷ مشاهده، به Owner رسید، تصمیم شد و متن اصلاحشده Verify شد | Done بدون اثر |
| Unit test سبز است | Claim محدود روی Commit/Build مشخص با Evidence و Blind spot | سبزی بیهویت |
| Security scan اجرا شد | Finding معتبر Triage، مالک و SLA دارد و Fix/Exception Verify شده | Artifact انبارشده |
| Canary خوب است | Population/Window/Guardrail معلوم و Decision/rollback authority پاسخ داده است | نمونهٔ ناکافی |
| Retro برگزار شد | فرضیهٔ Process به Experiment و نتیجهٔ سنجیده رسید | گفتوگوی بیتغییر |
مرحله ۱: Flow و Decisionها را پیش از فازها رسم کنید
نام فازهای Analysis/Design/Code/Test/Deploy ممکن است واقعیت Flow را پنهان کند. از Event واقعی شروع کنید: ایده، تغییر Rule، Pull Request، Build، Deployment، Incident یا Feedback کاربر. سپس Decisionهایی را که باید گرفته شوند مشخص کنید: ادامهٔ Discovery، انتخاب Design، Merge، Promote، Rollout، Pause، Rollback، Fix یا Retire.
Flow: FLOW-CHECKOUT-21
Event: تغییر قرارداد idempotency در C21
Decision chain:
clarify rule → accept design → merge → promote build
→ canary continue/pause → retain/adapt control
Decision authority: capability-based per decision
No claim: Flow map proves process quality or delivery successمرحله ۲: Product Outcome و Risk را پین کنید
«بهبود کیفیت» برای انتخاب Loop کافی نیست. Product، Product Goal/Outcome، Risk registry snapshot و Test Strategy/Quality policy نسخهدار لازماند. Risk باید Condition، consequence، affected subject و uncertainty داشته باشد. Loop برای Risk نامدار ساخته میشود؛ نه برای پرکردن همهٔ خانههای یک نمودار.
| فیلد | نمونهٔ ضعیف | نمونهٔ قابل ممیزی |
|---|---|---|
| Product | فروشگاه | SYN-CHECKOUT |
| Outcome | رضایت بیشتر | OUTCOME-۷: duplicate-effect rate در دامنهٔ مصنوعی |
| Risk | ممکن است خراب شود | RISK-v10:R-IDEMP-۵ با condition/consequence |
| Policy | کیفیت مهم است | QUALITY-POL-v4 و decision threshold نسخهدار |
مرحله ۳: Quality Question و Claim limit بسازید
Question باید آنقدر محدود باشد که Control بتواند Observation مرتبط بسازد. «آیا سیستم کیفیت دارد؟» پاسخپذیر نیست. «آیا duplicate Callback با Event ID ثابت برای Attempt مشخص بیش از یک Ledger effect میسازد؟» Subject، رفتار و Observation را روشن میکند. Claim limit باید بنویسد PASS چه چیزهایی را نمیگوید.
question: duplicate Callback چه اثر قابل مشاهدهای میسازد؟
expected bounded claim:
exactly one Ledger effect for tenant+attempt+event
claimLimit:
- سایر modeهای event loss پوشش داده نشدهاند
- رفتار PSP واقعی یا Production نتیجه نمیشود
- نبود باگ، کیفیت مالی و Release اثبات نمیشودمرحله ۴: زودترین نقطهٔ توانمند را انتخاب کنید
زودترین نقطه با «اولین جلسه» یکی نیست. نقطه باید Subject قابل بررسی، Source، Oracle، Observer و امکان Action داشته باشد. ابهام Rule را شاید در Example review بتوان یافت؛ Race condition را شاید Model/Component harness؛ ناسازگاری واقعی Browser را فقط در محیط دارای Browser؛ و رفتار under-load را در Workload نماینده.
| پرسش | نقطهٔ زودهنگام توانمند | چرا زودتر از آن نامعتبر است؟ |
|---|---|---|
| ابهام Business rule | Example/requirement review | بدون Basis هنوز Rule موضوع ندارد |
| Dependency cycle | Architecture model/static check | در Idea خام ساختار وجود ندارد |
| Branch logic | Component/unit level | Design prose Observation runtime نمیدهد |
| Contract compatibility | Consumer/provider contract | Unit fake ممکن است Interface واقعی را مدل نکند |
| Cross-service behavior | Integration environment | Component isolation Interaction را حذف میکند |
| User/browser behavior | System/UI representative config | API check rendering/input را نمیبیند |
| Operational emergent behavior | Canary/monitoring controlled | Pre-production population واقعی ندارد |
مرحله ۵: نقطهٔ دیرتر و نمایندهتر را عمداً نگه دارید
هر Control زودهنگام یک مدل و Blind spot دارد. برای Risk مهم، confirmation point را از قبل تعیین کنید: Contract check با Integration sample، Component performance با system load، Design accessibility review با Keyboard/AT observation، یا synthetic pre-production با Canary guardrail. نتیجهٔ دیرتر باید به Loop اولیه Link شود تا Model calibration ممکن باشد.
اگر late confirmation با early Evidence ناسازگار بود، فقط Product را متهم نکنید؛ Model، Test data، Oracle، Environment و Sampling را هم Candidate cause بدانید. هدف حذف بازخورد دیر نیست؛ کاهش Surprise و کوتاهکردن پاسخ است.
مرحله ۶: Control را با Question جفت کنید
Control میتواند Review، Example mapping، Static analysis، Unit/Component/Contract/System test، Simulation، Scan، Monitoring یا Manual observation باشد. محبوبیت ابزار یا عنوان فاز انتخاب را تعیین نمیکند. Control باید همان Failure mode را تحریک/مشاهده کند و هزینه/Latency آن با Consequence متناسب باشد.
برای خطاهای بدون اجرای کد، تست استاتیک و Review میتواند Signal زودهنگام بسازد؛ اما Dynamic behavior را اثبات نمیکند. Dynamic testing هم تناقضهای Basis را لزوماً پیدا نمیکند. این دو مکملاند.
مرحله ۷: Subject، Build، Environment و Data را ثابت کنید
Signal بدون Subject تغییرناپذیر قابل مصرف نیست. «آخرین Requirement»، «main»، «nightly»، «staging» و «دادهٔ تست» بعداً معنای دیگری دارند. Document/version، Repository/Commit، Build/digest، Deployment، Environment/config، Dependency، Feature flag، Data pack/seed/namespace و Time window را ثبت کنید.
| Artifact | Identity لازم | Drift نمونه |
|---|---|---|
| Requirement/Example | BASIS-v8:R-IDEMP-5 | متن بعد از Review اصلاح شده |
| Source | checkout-api/C21 | main جلو رفته |
| Build | BUILD-R21 + digest | nightly بازساخته شده |
| Deployment | DEPLOY-R21 + config snapshot | Feature flag تغییر کرده |
| Data | DATA-SYN-21 + seed/namespace | State مشترک مصرف شده |
مرحله ۸: Oracle و Evidence را جدا تعریف کنید
Oracle قاعدهٔ تفسیر Observation است؛ Evidence Artifact قابل بررسی همان Observation. «Review شد» Oracle نیست و Screenshot بیهویت Evidence کافی نیست. Source/Rule/Tolerance/Window/Method را بنویسید؛ سپس Evidence را با Loop/Subject/Build/Run/time/provenance/digest پیوند دهید.
در تحلیل Basis، پرسشهای Scope، مثال، Constraint، Risk و Testability را میتوان با راهنمای تحلیل نیازمندیها در STLC عمیق کرد. خروجی Review باید Finding و Disposition داشته باشد، نه فقط حضور در جلسه.
Verification و Validation را در Loopهای متفاوت ببینید
Verification میپرسد Artifact/Implementation با مشخصات و قاعدهٔ انتخابشده سازگار است؛ Validation میپرسد راهحل در Context مصرف، نیاز واقعی را برآورده میکند. این دو را به «قبل و بعد» یا «QA و کاربر» تقلیل ندهید. هر دو میتوانند در نقاط مختلف و با شواهد متفاوت رخ دهند.
جداسازی دقیق مفاهیم و مثالهای عملی در راهنمای Verification و Validation آمده است. یک Loop ممکن است Verification زودهنگام داشته باشد و برای Validation به Observation دیرتر نیاز داشته باشد.
مرحله ۹: زمانهای بازخورد را به یک Timestamp تقلیل ندهید
| زمان | معنا | Latency قابل محاسبه |
|---|---|---|
| eventAt | رخداد یا تغییر موضوع | تا Observation |
| observedAt | Control Signal را مشاهده کرد | Detection latency |
| emittedAt | Evidence/پیام منتشر شد | Processing latency |
| receivedAt | کانال به Consumer رساند | Delivery latency |
| acknowledgedAt | Owner دریافت و مسئولیت پاسخ را پذیرفت | Acknowledgement latency |
| actionedAt | Action/Decision انجام شد | Response latency |
| verifiedAt | اثر Action دوباره مشاهده شد | Closure latency |
Pipeline سه دقیقهای ممکن است Signal را دو روز بدون Owner رها کند. Dashboard «Test duration» چنین Bottleneckی را نشان نمیدهد. SLO را بر اساس Consequence برای Event→Observation، Observation→Ack و Ack→Verified جدا کنید.
مرحله ۱۰: وضعیت Loop را از سبز و قرمز جدا کنید
| Status | معنای عملیاتی | شرط انتقال |
|---|---|---|
| OBSERVED | Signal با Evidence ساخته شد | manifest معتبر |
| DELIVERED | به Consumer نامدار رسید | delivery receipt |
| ACKNOWLEDGED | Response owner پاسخ را پذیرفت | ack + next step |
| ACTIONED | Action/Decision ثبت شد | action evidence |
| VERIFIED | اثر Action با Observation تازه سنجیده شد | verification evidence |
| CORRECTED | Signal/تفسیر قبلی با سابقه اصلاح شد | correction/supersession |
| UNKNOWN | Evidence برای State معتبر کافی نیست | explicit unknown + owner |
PASS/FAIL Outcome یک Control است؛ OBSERVED/VERIFIED وضعیت Loop. ممکن است Test PASS باشد اما Loop هنوز DELIVERED نشده، یا Finding درست ACTIONED شده ولی Verification باقی باشد.
مرحله ۱۱: Delivery، Acknowledgement و Action را ثبت کنید
ارسال پیام در Chat یا درج Comment به معنای دریافت نیست. Canonical record باید Consumer، Channel، receipt، Ack، Response owner، Next action و Due را نگه دارد. کانال بر اساس فوریت و نیاز تصمیم انتخاب میشود: Inline review برای Diff، alert برای Gate بحرانی، Issue برای پیگیری و Decision record برای Trade-off.
FeedbackPacket
feedbackId / loopId / evidenceRef
observedFact / boundedInterpretation / unknowns
riskAndConsequence / urgency
responseOwner / decisionAuthority
requestedAction / alternatives / dueAt
deliveredAt / acknowledgedAt / nextCheckAt
correctionLink / accessClassificationمرحله ۱۲: «کیفیت مسئولیت همگانی است» را عملیاتی کنید
Whole-team approach یعنی قابلیتهای مختلف در ساخت کیفیت و Evidence مشارکت کنند؛ نه اینکه هیچکس پاسخگو نباشد. نقش رسمی سازمان را از Capability لازم جدا کنید. کسی باید Question/Oracle را Review کند، کسی Environment را نگه دارد، کسی Failure را Triage کند و فردی با اختیار Business/Risk تصمیم بگیرد.
الگوی تصمیمگیری و مرز پاسخگویی در رهبری تضمین کیفیت و مالکیت همگانی آمده است. عنوان Tester، QA Coach، Developer یا Product Owner بهتنهایی اختیار یا شایستگی را ثابت نمیکند.
مرحله ۱۳: Action را بدون Verification نبندید
Mergeشدن Fix، تغییر Requirement، افزودن Test یا خاموشکردن Alert Closure نیست. Verification باید روی Subject جدید، با Oracle مناسب و Evidence تازه انجام شود. اگر Action پذیرش Risk یا Defer است، Verification میتواند بررسی Guardrail، Expiry و شرط بازگشت باشد؛ نه جعل PASS.
Closure باید بگوید کدام Claim اکنون پشتیبانی میشود، چه Unknownهایی باقیاند و کدام Decision تحت تأثیر است. Defect closed، Loop closed و Risk closed سه وضعیت مستقلاند.
مرحله ۱۴: Correction و Supersession را طراحی کنید
اگر Signal به Build اشتباه متعلق بود، Oracle ناقص بود یا Dashboard Population را غلط محاسبه کرد، Record را بیصدا ویرایش نکنید. Correction باید Previous statement، Reason، corrected interpretation، affected Decision، notification و timestamp را ثبت کند. نسخهٔ جدید Loop یا Control با supersedes به قبلی وصل شود.
Correction
correctionId: CORR-LOOP-21-2
corrects: FEEDBACK-21-7
reason: Evidence manifest belonged to BUILD-R20
oldInterpretation: control verified on BUILD-R21
newInterpretation: UNKNOWN for BUILD-R21
affectedDecisions: [CANARY-DR-21]
notifiedAt / owner / supersedingEvidenceنقشهٔ Loop در Discovery و تحلیل
در Discovery، Subject میتواند Problem statement، Outcome hypothesis، Persona assumption یا Business rule باشد. Controls شامل Example review، counterexample، prototype observation، data feasibility و risk workshopاند. Signal باید به تغییر Basis، Experiment، Scope یا Decision برسد. تعداد جلسه و سند، Outcome نیست.
| Event | Question/Control | Action نمونه | Confirmation دیرتر |
|---|---|---|---|
| Rule جدید | Example/counterexample review | رفع ambiguity | behavior check روی Build |
| فرض Outcome | prototype/usability observation | adapt flow | bounded production experiment |
| وابستگی داده | schema/data feasibility | change requirement | integration observation |
نقشهٔ Loop در Design و Architecture
در Design، Quality attribute scenario و Failure mode را به Architecture decision پیوند دهید. Review، Model، threat analysis، capacity estimate، interface contract و testability probe میتوانند Signal بسازند. «Architecture approved» نتیجه نیست؛ Finding/Trade-off/Decision/Assumption و confirmation point لازم است.
برای مثال، idempotency design با Event key و state transition Review میشود؛ Component harness کنترل زودهنگام است؛ Integration با duplicate/reordered event و Canary synthetic confirmation دیرتر. هر سطح Claim محدود خودش را دارد.
نقشهٔ Loop در Implementation و Review
Commit/PR Event است. Static check، Unit/Component test، peer review و security/lint scan Observation میسازند. Gate باید Finding را به خط/Rule/Subject وصل کند و Override/Exception را با authority و expiry ثبت کند. Comment حلشده بدون Diff و Re-run Evidence Loop را نمیبندد.
همهٔ Controlها نباید Blocker باشند. Severity، confidence، cost of delay و reversible بودن تغییر تعیین میکند Signal advisory، required-action یا hard gate باشد. Noise زیاد موجب bypass میشود؛ Silence هم Blind spot را پنهان میکند.
نقشهٔ Loop در Build و Integration
Build باید Subject دقیق، Dependency graph، Config و Artifact digest داشته باشد. Contract/Integration/Component/System Controls بر اساس Change impact و Risk در Lane مناسب اجرا میشوند. Fail Product را از ERROR محیط/Runner و INCONCLUSIVE جدا کنید. Rerun نباید Failure اول را حذف کند.
Pipeline سبز فقط Evidence همان Gateهاست. Missing/Skipped/Quarantined، foreign Build، stale Evidence و unavailable Environment باید در Aggregation دیده شوند. «همهٔ Testها در CI» به اندازهٔ «هیچ Test تا آخر» میتواند ضدبازخورد باشد.
نقشهٔ Loop در System و Non-functional Testing
برخی Quality characteristicها را میتوان زودتر در Component سنجید، اما System behavior و Interactionهای واقعیتر به Environment، Workload و Configuration نماینده نیاز دارند. Performance، Security، Reliability، Accessibility و Compatibility یک «فاز آخر» مشترک نیستند؛ هرکدام Question، Model و observation pointهای چندگانه دارند.
Result باید به Baseline و Population خود محدود بماند. Load lab سلامت Production را تضمین نمیکند؛ accessibility scanner جای Keyboard/AT و user observation را نمیگیرد؛ DAST جای threat/design/static/control verification را نمیگیرد.
نقشهٔ Loop در Release و Deployment
Release decision یک جمعبندی چند Evidence و Unknown تحت Policy و Authority است. Deployment event نیز Loopهای جدا برای health، config، migration، guardrail و rollback دارد. Test team نباید صرفاً با PASS rate مجوز Business بدهد؛ Decision authority باید Residual risk و reversibility را بپذیرد.
Progressive delivery میتواند Blast radius و response time را محدود کند، اما Canary بدون Population، Window، Guardrail، Owner و Rollback readiness فقط انتشار کوچکتر است. Pre-release Evidence را به Deploy/Canary Subject دوباره نسبت دهید.
نقشهٔ Loop در Operation، Incident و Maintenance
Log/metric/trace، synthetic transaction، support signal، incident و user feedback میتوانند Blind spotهای قبل از انتشار را آشکار کنند. Production را Test environment بیقید نکنید؛ safety budget، data minimization، tenant isolation، rate limit، consent و rollback لازماند. Signal عملیاتی باید به Risk/Test Basis/Control قبلی بازگردد.
Maintenance فقط Fix کد نیست. Requirement، Test, Oracle، Monitoring rule، Runbook، Dashboard و Training ممکن است نیاز به Adapt/Retire داشته باشند. Incident count را Success metric تست ندانید؛ Exposure و detection opportunity تغییر میکند.
مدل توسعه مهم است، اما Loop به Agile محدود نیست
| Context | شکل Loop | کنترل ویژه |
|---|---|---|
| Sequential/contractual | review/approval baseline با feedback window کوتاه و trace | change control و formal evidence |
| Iterative/Agile | Example→implementation→review→increment→outcome | small batch و frequent adaptation |
| DevOps/continuous delivery | commit→pipeline→deploy→operate→learning | automation، observability و rollback |
| Regulated/safety-critical | independent review، evidence chain و authority gate | separation/trace/retention مطابق Policy |
| Legacy/low deploy frequency | characterization، change impact و representative rehearsal | limited testability و recovery |
Agile و DevOps ابزارهای ممکن برای کوتاهکردن و خودکارکردن Loopها هستند، نه پیششرط ادغام تست. حتی یک Flow ترتیبی میتواند Review زودهنگام، Feedback SLA و confirmation دیرتر داشته باشد.
هزینهٔ Finding دیرهنگام را چگونه صادقانه بسنجیم؟
بهجای ضریب ثابت، Cost of feedback را به اجزا بشکنید: Detection/triage، rework Artifactها، تغییر Interface، migration، retest، deploy/rollback، support، exposure و opportunity cost. سپس هزینهٔ Control زودهنگام، False signal و نگهداشت آن را نیز وارد کنید. Counterfactual را بنویسید: بدون این Loop چه میشد و این فرض چگونه آزموده میشود؟
feedbackEconomics
eventPopulation / baselineWindow
detectionLatency / responseLatency / closureLatency
controlBuildAndRunCost / triageAndMaintenanceCost
observedRework / avoidedWorkHypothesis
exposureAndConsequence / uncertaintyRange
guardrails: falseSignal, interruptionLoad, escapedBlindSpots
claimLimit: association is not causal proofمبنای رسمی و محدودیت تفسیر Shift-left
ISTQB CTFL v4.0.1 Shift-left را انجام زودتر تست تعریف میکند و مثالهایی مانند Review specification، نوشتن Test پیش از کد، CI/CD، Static analysis و شروع زودتر تست غیرعملکردی ارائه میدهد. همان متن صریحاً میگوید تست دیرتر نباید نادیده گرفته شود و Shift-left ممکن است Training، effort و cost اولیهٔ بیشتری بخواهد.
این منبع آموزشی نسخهٔ سازمان، نقش اجباری، ROI، Tool stack یا نتیجهٔ پروژهٔ شما را تعیین نمیکند. «expected to save effort/cost later» تضمین نیست؛ Baseline و Evidence محلی لازم است.
اصل Agile چه میگوید و چه نمیگوید؟
اصول رسمی Agile Manifesto به تحویل زود و پیوسته، همکاری روزانه، توجه مستمر به تعالی فنی، سادگی و بازاندیشی منظم اشاره میکنند. این اصول با Loop کوتاه سازگارند؛ اما نقش Tester/QA، فهرست ابزار، درصد Automation، Test Pyramid، Pipeline stage، «همهٔ تستها با هر Commit» یا تضمین Quality/Speed را تجویز نمیکنند.
Automation در Loop: حمل Signal، نه جایگزین تصمیم
Automation میتواند Trigger، Control، Evidence collection، routing، SLA alert و re-check را سریع کند. اما اگر Question، Oracle، Subject یا Owner غلط باشد، فقط Signal غلط را سریعتر پخش میکند. هر اتوماسیون باید Failure mode و fallback داشته باشد: missed event، duplicate event، stale cache، foreign Build، delayed queue، unavailable owner و corrupted evidence.
- Schema/identity/time/freshness را پیش از انتشار Signal validate کنید.
- Dedup و idempotency را برای Event routing تعریف کنید.
- ERROR/UNKNOWN را به PASS تبدیل نکنید.
- Alert aggregation نباید رخداد بحرانی یا Population را پنهان کند.
- Automated action پرخطر به Authority، guardrail، audit و rollback نیاز دارد.
AI در حلقهٔ بازخورد: Draft و Triage محدود
AI میتواند Findingها را خوشهبندی، Summary را Draft، Candidate owner را پیشنهاد یا تغییرهای مشابه را پیدا کند. Prompt/model/version، Source refs، transformation و Reviewer باید ثبت شوند. Summary احتمالی جای Evidence خام، Rule deterministic یا Decision authority را نمیگیرد.
AI نباید Observation را جعل، Unknown را پر، Cause را بدون Evidence تأیید، Finding را بیردپا suppress، Risk را قبول یا Release را تصویب کند. دادهٔ حساس، Source access، retention و احتمال Prompt injection در Log/Issue نیز باید کنترل شوند.
آزمایش بازتولیدپذیر: ۹ مرحلهٔ سبز در برابر ۷۷ Finding
برای آزمون ادعا، Fixture کاملاً مصنوعی و آفلاین SYN-QUALITY-FEEDBACK-LOOP-01 با Node.js v24.۱۸.۰ ساخته شد. Dashboard سطحی فقط دید ۹ مرحله از ۹ مرحله سبز است، چرخه ۱۱ دقیقه طول کشیده و unresolved برابر صفر است؛ بنابراین PASS داد.
{
"superficial": {
"status": "PASS",
"message": "9/9 lifecycle stages green; 11-minute cycle; zero unresolved"
},
"contractAudit": {
"status": "HOLD",
"findingCount": 77
}
}ممیزی دقیق ۷۷ Failure یافت: دوازده Flow/Product/Goal/Outcome/Risk/Strategy/Policy/Basis/Repository/Commit/Build/Deployment identity کهنه یا متحرک؛ Loop ID تکراری و version/supersedes/Decision/Question/Risk/Trigger ناقص؛ نبود earliest capable و later representative point؛ Control/Subject/Population/Environment/Data/Oracle/Observation/Evidence/Unknown؛ هفت زمان و Latency SLO؛ Owner/Action/Due/Authority/Verification/Correction/Claim limit/Blind spot/Retention/Redaction/Cost/Consequence/Measure/Guardrail/Review/status؛ Vocabulary و Stage map؛ و ۲۳ ادعای مطلق دربارهٔ فقط-زودهنگام، حذف تست دیرتر، انتقال همهچیز به ابتدا/CI، Full suite، هزینهٔ نمایی/هزاربرابر، پیشگیری/تضمین، مالکیت مبهم، نقشهای ثابت، ابزار/Automation، Agile/DevOps و نتیجهٔ Release/Trust/Speed/Wellbeing.
خطای طراحی آزمایش و اصلاح صادقانهٔ آن
اجرای اول نشان داد Rule set فقط ۷۶ Finding دارد، نه عدد ۷۷ مورد انتظار. هیچ عددی منتشر نشد و Counter دستکاری نشد. یک نقص واقعی در Model پیدا شد: اعتبار وضعیت lifecycle خود Loop کنترل نمیشد. Rule مستقل OBSERVED/DELIVERED/ACKNOWLEDGED/ACTIONED/VERIFIED/CORRECTED/UNKNOWN افزوده و کل Fixture دوباره اجرا شد؛ سپس دقیقاً ۷۷ Finding حاصل شد.
نسخهٔ اصلاحشدهٔ آزمایش
نسخهٔ اصلاحشده FLOW-CHECKOUT-۲۱/SYN-CHECKOUT/PG-۱۴/OUTCOME-۷/RISK-v10/TEST-STRAT-v6/QUALITY-POL-v4/BASIS-v8/checkout-api/C21/BUILD-R21/DEPLOY-R21 را پین کرد. Loop idempotency نسخهٔ ۴، Decision/Question/Trigger، earliest component observation و later canary confirmation، Control/Subject/Population/Environment/Data/Oracle، Observation/Evidence/Unknown، زمانها/SLO، Owner/Action/Authority/Verification/Correction، Blind spot/Retention/Cost/Measure/Guardrail و Review را کامل کرد.
Stage map سه نقطهٔ Discovery/Design، Component/Build و Canary/Operate را به همان Loop وصل کرد و همهٔ ادعاهای مطلق حذف شدند. Validator با صفر Finding وضعیت READY_FOR_LOOP_REVIEW داد. این نتیجه عمداً حقیقت یا کفایت Source/Oracle/Evidence، Coverage، رابطهٔ علّی، نبود باگ، کیفیت Product یا Release را ثابت نمیکند.
آزمایشگاه Checkout فارسی و ایرانی
دامنه یک Checkout کاملاً جدا از شبکه با Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger Stub و Reconciliation مصنوعی است. Loop روی timeout پیش/پس از fake commit، duplicate/late/reordered Callback، retry و Tenant isolation تمرکز دارد. همهٔ Entity، زمان، پول و Evidence ساختگیاند.
| بعد | قرارداد آزمایشگاهی | محدودیت |
|---|---|---|
| پول | مقدار canonical ساختگی بر حسب IRR؛ تومان فقط view برچسبدار | نه ادعای مالی/بانکی ایران |
| متن و رقم | ارقام فارسی/عربی/لاتین، Unicode normalization، RTL/LTR و stable Latin ID | نه پوشش کامل locale |
| زمان | ISO instant/UTC؛ view در Asia/Tehran؛ جلالی فقط presentation | نه قاعدهٔ حقوقی/تسویه |
| هویت | Tenant/Order/Attempt/Event/Ledger/Run/Build/Deploy/Evidence جدا | نه تراکنش یا مشتری واقعی |
هیچ Network، Production، شرکت، کاربر، پرداخت، بانک، PSP، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی وجود ندارد. این Lab توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا Compliance ایران نیست.
امنیت، حریم خصوصی و ایمنی Feedback
- فقط دادهٔ لازم برای Decision را جمع کنید و Purpose/Access/Retention داشته باشید.
- Secret/PII را پیش از Log، Trace، Screenshot، Issue و AI prompt حذف یا Redact کنید.
- Feedback کانال عمومی نباید Vulnerability یا دادهٔ مشتری را افشا کند.
- Webhook/Event را authenticate، deduplicate و replay-safe کنید.
- Automated rollback/flag change به scope، rate limit، authority و recovery test نیاز دارد.
- Correction و access audit را نگه دارید؛ حذف بیردپا اعتماد را از بین میبرد.
متریکهای Loop با Countermetric
| Measure | تعریف لازم | Countermetric |
|---|---|---|
| Detection latency | eventAt تا observedAt برای Population واجد شرایط | False signal و Blind spot |
| Acknowledgement latency | receivedAt تا ack با Owner واقعی | interrupt load و meaningless ack |
| Closure latency | Event تا Verification، نه صرفاً Fix merge | Reopen و verification quality |
| Loop completion | Verified/Corrected بر eligible Loopها | Unknown، risk acceptance و premature close |
| Evidence freshness | Evidence معتبر برای Subject/Decision در SLA | run/storage cost |
| Late-surprise rate | Finding دیرتر که early model ندیده، با taxonomy | Fidelity و opportunity تفاوت دارد |
| Action effectiveness | اثر Action در Verification بعدی | causal uncertainty و side effect |
| Feedback cost | build/run/review/triage/response/maintenance | consequence و value of information |
تعداد Test، Bug، Alert، Meeting یا Stage سبز را برای رتبهبندی فرد/تیم بهکار نبرید. سرعت Loop بدون Signal quality تیم را به Ack صوری، حذف Unknown و بستن زودهنگام تشویق میکند.
Pilot سیروزهٔ Quality Feedback Loop
| بازه | کار | خروجی/گیت |
|---|---|---|
| روز ۱–۵ | یک Flow/Decision/Risk پرمصرف و Baseline latency/cost را انتخاب کنید | Loop brief و non-goals |
| روز ۶–۱۰ | Question، Claim limit، earliest capable و later representative point را طراحی کنید | Design review با Blind spot |
| روز ۱۱–۱۵ | Subject/Data/Oracle/Evidence و Event routing را پیاده کنید | آزمایش duplicate/delay/foreign-subject |
| روز ۱۶–۲۰ | Owner/SLO/Ack/Action/Authority/Verification را تمرین کنید | Game day و failure report |
| روز ۲۱–۲۵ | Correction، retention، redaction و recovery را آزمون کنید | Corrected record بدون silent edit |
| روز ۲۶–۳۰ | Latency/Signal quality/cost/guardrail و late surprise را Review کنید | Keep/Adapt/Stop/Scale decision |
موفقیت Pilot یعنی یک Signal مرتبط، قابل ردیابی و بهموقع به Action تأییدشده رسیده است؛ نه اینکه Pipeline، Dashboard یا تعداد Automation بیشتر شده باشد.
۳۰ ضدالگوی ادغام تست در SDLC
- تست=فاز آخر؛ Shift-left=حذف تست آخر؛ همهچیز را در Discovery تست کن؛ Late feedback همیشه بیارزش.
- همهٔ Testها با هر Commit؛ Full suite=Continuous؛ Automation شاهکلید؛ Tool list بهجای Loop design.
- Stage سبز=Loop بسته؛ پیام ارسال شد=Ack؛ Fix merge=Verified؛ unresolved صفر با حذف Unknown.
- latest/main/staging بهجای Subject؛ Evidence خارجی/کهنه؛ Dashboard بدون cutoff؛ Screenshot بدون identity.
- Question کلی؛ Control بیRisk؛ Oracle از همان SUT؛ Claim بدون limit؛ Blind spot پنهان.
- فقط یک timestamp؛ Test duration بهجای Event-to-action؛ SLO بدون consequence؛ Avg بدون distribution.
- shared responsibility بدون Owner؛ QA Coach اجباری؛ Unit فقط Developer؛ E2E فقط QA؛ Authority از عنوان.
- همهٔ Findingها hard gate؛ Retry و suppress برای سبزی؛ Quarantine بیExpiry؛ alert بدون runbook.
- هزینهٔ ثابت صد/هزاربرابر؛ early always cheaper؛ ROI/quality/speed/trust/wellbeing تضمینی.
- Agile/DevOps بهعنوان پیششرط؛ یک Loop برای همهٔ Contextها؛ Production observation غیرضروری.
- PII/Secret در Artifact؛ webhook بیauth/dedup؛ Retention همیشگی؛ correction بیتاریخچه.
- AI summary=Evidence؛ Cause احتمالی=واقعیت؛ Risk/Release خودکار؛ Ranking فرد با Bug/Test/Latency.
چکلیست ۲۴ نقطهای ممیزی Loop
- Flow/Product/Goal/Outcome/Risk/Strategy/Policy/Basis نسخهدار است.
- Repository/Commit/Build/Deployment/Environment/Data تغییرناپذیرند.
- Loop ID/version/supersedes و lifecycle status معتبر است.
- Decision، bounded Question و Claim limit روشناند.
- Trigger و Consequence تأخیر/فقدان Signal ثبت شدهاند.
- Earliest capable point با Control/Oracle واقعی انتخاب شده است.
- Later representative point و Blind spotهای کنترل زودهنگام معلوماند.
- Control با Failure mode و Risk همان پرسش متناسب است.
- Subject، Population/Sample، Environment و Data contract ثبت شدهاند.
- Oracle Source/Rule/Method/Tolerance/Window دارد.
- Observation و Evidence دارای provenance، identity، time و integrityاند.
- Unknown و INCONCLUSIVE به PASS/سبز تبدیل نشدهاند.
- event/observed/emitted/received/ack/action/verified time جدا هستند.
- SLO برای Detection/Ack/Response/Closure با Consequence تعریف شده است.
- Delivery receipt و Acknowledgement واقعی ثبت میشوند.
- Response owner، Action، Due و Decision authority نامدارند.
- Action با Observation تازه Verify میشود.
- Correction/Supersession و affected Decision پیوند دارند.
- Automation failure، duplicate، delay و foreign Subject آزموده شدهاند.
- Access/Retention/Redaction و Secret/PII policy اعمال میشوند.
- Cost baseline، Measure، Guardrail و causal limitation وجود دارند.
- Stage activity بهجای Loop outcome گزارش نمیشود.
- Shared quality مالکیت و اختیار را حذف نکرده است.
- هیچ تضمین Quality، absence of defects، ROI، Speed یا Release استنتاج نشده است.
جمعبندی: تست را پخش نکنید؛ Loop را ببندید
ادغام کیفیت در SDLC با افزودن QA به همهٔ جلسهها، اجرای ابزار در همهٔ Stageها یا سبزکردن Dashboard حاصل نمیشود. از یک Decision و Risk شروع کنید، Question محدود بسازید، در زودترین نقطهٔ توانمند Signal بگیرید، Blind spot را در نقطهٔ نمایندهتر بسنجید و مسیر Evidence تا Owner، Action، Verification و Correction را قابل ردیابی کنید.
هدف «حذف تست در انتها» نیست؛ هدف این است که هیچ Decision مهمی تا انتها بدون Signal مناسب نماند و هیچ Signal مهمی بدون پاسخ و یادگیری رها نشود. اگر فقط Stage را سبز کردهاید، هنوز باید Loop را پیدا کنید.
سوالات متداول تست در چرخه حیات توسعه نرمافزار
آیا Shift-left یعنی تستهای انتهای چرخه را حذف کنیم؟
خیر. Shift-left یعنی پرسش را در زودترین نقطهای مطرح کنیم که Control و Oracle معتبر دارد. System، acceptance، non-functional یا production observation ممکن است Fidelity و Population منحصربهفرد داشته باشند. کنترل زودهنگام باید با confirmation دیرترِ نماینده تکمیل شود.
آیا Continuous Testing یعنی اجرای همه تستها با هر Commit؟
نه. Control باید بر اساس Risk، Change impact، سرعت، هزینه، Environment و Consequence در Trigger/Lane مناسب اجرا شود. Full suite در هر Commit میتواند Queue و Noise بسازد. Continuous یعنی Feedback مناسب و قابل مصرف در سراسر Flow، نه تکرار بیهدف همهچیز.
از کجا بفهمیم یک حلقه بازخورد واقعاً بسته شده است؟
Evidence به Subject درست متصل است، Consumer آن را دریافت کرده، Owner پاسخ را Ack کرده، Action/Decision با Authority و Due ثبت شده و اثر Action با Observation تازه Verify شده است. در صورت خطا نیز Correction/Supersession وجود دارد. ارسال Report یا Merge Fix بهتنهایی Closure نیست.
آیا کشف زودتر باگ همیشه ارزانتر است؟
نه بهصورت قانون قطعی. هزینه به نوع Failure، Artifactهای درگیر، Exposure، Rework، Migration و Context بستگی دارد؛ Control زودهنگام نیز Build/Training/False-signal/Maintenance cost دارد. هزینهها و Counterfactual را با Baseline محلی و بازهٔ عدم قطعیت بسنجید، نه ضریب ثابت.
مسئول کیفیت در SDLC چه کسی است؟
کیفیت از مشارکت چند Capability ساخته میشود، اما هر Loop و Decision مالک روشن میخواهد. Question/Oracle reviewer، Control/Environment owner، Response owner و Decision authority ممکن است افراد متفاوتی باشند. «همه مسئولاند» نباید به «هیچکس پاسخگو نیست» تبدیل شود.
