ساعت ۱۶:۳۰ است. چهلودو تغییر پشت ستون «منتظر QA» مانده، تنها تستر تیم مرخصی است و Release متوقف شده است. روی داشبورد ماه قبل نوشتهاند: «۴۲ از ۴۲ تغییر تأیید QA؛ صفر Incident». آیا مشکل کمبود تستر است، ضعف توسعهدهنده است یا خودِ سیستم تحویل؟ پاسخ بدون دیدن جریان کار، Controlها، اختیار تصمیم و Backup قابلاعتماد نیست.
این راهنما مسئلهٔ تستر بهعنوان تنها شبکه ایمنی را از بحث شعاری «کیفیت مسئولیت همه است» به یک طراحی قابلممیزی تبدیل میکند: Protection Control Map برای Prevention، Detection، Containment، Recovery و Learning؛ همراه با Handoff Contract، Queue Policy، سطح استقلال، Evidence و Correction. هدف حذف تستر یا حذف تست مستقل نیست؛ هدف حذف وابستگی پنهان به یک فرد، صف یا Approval مبهم است.
خلاصه اجرایی: شبکه ایمنی واقعی یک سیستم است، نه یک نفر
- اگر همهٔ تغییرها فقط در انتهای کار به یک صف QA میرسند، سازمان یک Control مستقل ندارد؛ یک نقطهٔ وابستگی ساخته است.
- مسئولیت مشترک کیفیت یعنی مشارکت قابلیتهای مختلف با Owner و Decision Right روشن؛ نه اینکه «همه مسئولاند» و در عمل هیچکس پاسخگو نباشد.
- تست مستقل میتواند ارزشمند و در بعضی Contextها ضروری باشد. استقلال با جداسازی اطلاعات، تأخیر یا خصومت یکی نیست.
- Shift-left یعنی Feedback را در اولین نقطهٔ توانمند قرار دهید؛ نه اینکه همهٔ تستها، همهٔ تسترها یا تمام Approvalها را به ابتدای جریان منتقل کنید.
- Controlها باید پنج نیاز را پوشش دهند: پیشگیری، کشف، مهار، بازیابی و یادگیری. Automation یا QA Approval فقط بخشی از این نقشهاند.
- هر Handoff باید ورودی، Readiness، Accept/Reject، Return reason، Resume condition، WIP، Service target و Escalation داشته باشد.
- بهبود را با کاهش انتظار و Unknown، حفظ استقلال و Evidence و نبودِ Single Point of Failure بسنجید؛ نه صرفاً سرعت یا صفر Incident.
هدف جستوجو و مرز این مقاله
کاربر معمولاً میپرسد: «چرا QA گلوگاه شده؟»، «آیا کیفیت مسئولیت تستر است؟»، «چطور وابستگی تیم به تستر را کم کنیم؟»، «Shared Quality یعنی چه؟» و «آیا Shift-left تست مستقل را حذف میکند؟». Intent اطلاعاتی و اجرایی است؛ بنابراین خروجی این صفحه یک مدل تشخیص و قرارداد پیادهسازی است، نه توصیهٔ کلی برای تغییر فرهنگ.
فرهنگ کیفیت در نرمافزار مالک رفتار، Incentive و Learning system است؛ رهبری QA و مالکیت همگانی Decision Right و پاسخگویی را پوشش میدهد؛ نقش تستر در Shift-left مالک Quality Interface زودهنگام است؛ و همکاری تستر و توسعهدهنده Request و Joint Evidence را توضیح میدهد. این مقاله فقط مالک وابستگی Safety-net و توزیع Control در سراسر Flow است.
«تستر شبکه ایمنی» دقیقاً چه مسئلهای است؟
شبکهٔ ایمنی استعارهای برای آخرین Catch-all است: Work بدون Evidence کافی حرکت میکند و انتظار میرود یک Tester یا تیم QA در انتها همهٔ نقصهای مهم را پیدا، تفسیر و متوقف کند. سه نشانهٔ اصلی آن عبارتاند از Concentration، Ambiguity و Late feedback:
| نشانه | مشاهدهٔ عملی | ریسک |
|---|---|---|
| Concentration | یک فرد/صف همهٔ Checkها و Approvalها را انجام میدهد | Single point of failure و صف |
| Ambiguity | «بده QA تست کند» بدون Question، Scope و Evidence | انتظار نامحدود و اختلاف Verdict |
| Late feedback | ابهام Basis یا Contract پس از Build کشف میشود | Rework و Feedback age بیشتر |
| Authority mismatch | تستر باید Release را تأیید کند ولی اختیار Risk ندارد | Approval نمایشی یا فشار غیرایمن |
| Capability gap | Control فقط با دانش یا Tool یک نفر اجرا میشود | تعطیلی در غیبت و Bus factor پایین |
چه چیزی Safety-net Dependency نیست؟
- وجود Tester متخصص یا تیم مستقل بهخودیخود مشکل نیست.
- Handoff نسخهدار برای حفظ استقلال، جداسازی وظایف یا کنترل Safety میتواند عمدی و مفید باشد.
- توقف Release بهعلت Evidence معتبرِ FAIL یک Bottleneck ناسالم نیست؛ ممکن است Control درست کار کند.
- نیاز به دانش تخصصی Accessibility، Security، Performance یا Domain الزاماً «Silo» نیست؛ نبود Interface و Backup مسئله است.
- تأخیر کوتاه و هدفمند برای Representative environment میتواند از Feedback سریع اما نامعتبر بهتر باشد.
Shared Quality یعنی چه و یعنی چه نیست؟
Shared Quality یعنی افراد مختلف در Outcome کیفیت اثر دارند و Control مناسب را در نقطهٔ توانمند اجرا میکنند. این عبارت Owner را حذف نمیکند. هر سؤال باید Producer، Executor، Reviewer، Decision authority و Escalation داشته باشد. «همه مسئول کیفیتاند» بدون این پنج نقش، معمولاً مسئولیت را پخش و پاسخگویی را محو میکند.
| قابلیت | سهم نمونه | ادعای نامجاز |
|---|---|---|
| Product/Business | Outcome، Constraint، acceptance و Risk authority | مالک همهٔ Testهاست |
| Development | Designability، component evidence، observability و repair | فقط کد مینویسد |
| Testing | Question، مدل، investigation، independent challenge و Evidence | همهٔ نقصها را پیدا میکند |
| Platform/Operations | Pipeline، environment، telemetry، containment و recovery | فقط Deploy میکند |
| Risk/Security/Domain | Policy، specialized review و acceptance authority | QA Approval را جایگزین میکند |
منابع رسمی چه میگویند؟ Whole-team و استقلال با هم
ISTQB CTFL 4.0.1 در Whole-team approach میگوید هر عضو دارای دانش و مهارت لازم میتواند Task را انجام دهد و همه نسبت به کیفیت مسئولاند؛ همزمان توضیح میدهد این رویکرد همیشه مناسب نیست و در Contextهایی مانند Safety-critical ممکن است استقلال بالاتر لازم باشد. همچنین چند سطح استقلال را مکمل میداند: نویسنده، Peer، Tester خارج از تیم و طرف بیرونی. پس «Shared» مترادف «بدون استقلال» نیست.
Scrum Guide 2020 Scrum Team را cross-functional و مسئول فعالیتهای مرتبط با محصول، از verification تا operation، معرفی میکند؛ Developers نیز برای instilling quality از طریق Definition of Done پاسخگو هستند. این متن نقش اجباری Tester، Approval نهایی QA یا حضور Tester در همهٔ Eventها تجویز نمیکند. برای کاربرد DoD، راهنمای Definition of Done و Increment Evidence را ببینید.
Protection System: جایگزین یک Catch-all مبهم
Protection System مجموعهٔ Controlهای نسخهدار در سراسر جریان است که یک Protection objective را دنبال میکنند. هیچ لایهای کامل نیست و Controlهای بیشتر الزاماً بهتر نیستند. نقشه باید نشان دهد هر Control چه چیزی را Prevent، Detect، Contain، Recover یا به Learning تبدیل میکند و کدام Unknown بیرون میماند.
| Mode | سؤال | مثال محدود |
|---|---|---|
| PREVENT | چطور احتمال ایجاد خطای مشخص را کم کنیم؟ | Type/constraint، design rule، example refinement |
| DETECT | چطور Failure/Risk signal را ببینیم؟ | review، static check، test، probe، monitoring |
| CONTAIN | چطور blast radius را محدود کنیم؟ | feature flag، limit، isolation، circuit breaker |
| RECOVER | چطور حالت درست را بازگردانیم؟ | rollback، replay، reconciliation، restore |
| LEARN | چطور مدل و Control را اصلاح کنیم؟ | incident review، escaped-risk analysis، experiment |
Protection Control Map: قرارداد مرکزی
protectionControlMap:
id: PCM-CHECKOUT-25
version: 4
purpose: "کاهش وابستگی به Catch-all انتهای Flow"
decision: "انتخاب Control/Backup و Pilot؛ نه Release verdict"
scope: checkout-change-flow@CUT-25
objective: "حفظ idempotency و recoverability در جریان مصنوعی"
claimLimit: "ساختار Control؛ نه کیفیت یا نبود نقص"
controls:
- id: CTRL-PREVENT-25
mode: PREVENT
flowPoint: design
- id: CTRL-DETECT-25
mode: DETECT
flowPoint: component-and-contract-run
- id: CTRL-CONTAIN-25
mode: CONTAIN
flowPoint: deployment
- id: CTRL-RECOVER-25
mode: RECOVER
flowPoint: operation
- id: CTRL-LEARN-25
mode: LEARN
flowPoint: feedback-loop
owner: protection-system-owner
unknowns: [real-psp-behavior]
status: READY_FOR_PROTECTION_SYSTEM_REVIEW
فیلدهای هر Control
| بخش | فیلدها | سؤال ممیزی |
|---|---|---|
| Identity | ID/version، Risk، Question، Objective | Control برای چه مشکلی است؟ |
| Placement | Mode، Flow point، Trigger، Subject | در اولین نقطهٔ توانمند اجرا میشود؟ |
| Execution | Method، Producer/Executor capability، Tool | چه کسی با چه قابلیت و روشی اجرا میکند؟ |
| Authority | Decision right، Reviewer، Independence | چه کسی چه تصمیمی مجاز است بگیرد؟ |
| Continuity | Backup capability، Capacity، Access، Support | غیبت یک فرد Flow را متوقف میکند؟ |
| Evidence | Rule، Freshness، Vocabulary، Failure outcome | Verdict به Subject همان Work متصل است؟ |
| Flow | Service target، Escalation، Queue/WIP | انتظار و Backpressure قابلمشاهدهاند؟ |
| Learning | Measure، Countermeasure، Cost، Lifecycle | Control مفید است یا فقط Ceremony؟ |
قالب آماده Control Record
control: id: CTRL-DETECT-25 version: 3 riskId: RISK-IDEMP-7 qualityQuestion: "Callback تکراری Ledger را دوبار تغییر میدهد؟" objective: "کشف نقض idempotency در BUILD-SYN-25" mode: DETECT flowPoint: component-contract trigger: change-touches-callback-or-ledger subject: checkout-api@C25/BUILD-SYN-25 method: idempotency-contract-suite/v6 producerCapability: development executorCapability: contract-testing reviewerCapability: independent-test-analysis decisionAuthority: risk-owner backupCapability: cross-capability-reviewer independenceLevel: peer-plus-specialist evidenceRule: same-build-signed-manifest freshnessRule: current-change-only resultVocabulary: [PASS, FAIL, ERROR, INCONCLUSIVE] failureOutcome: return-with-finding-and-resume-rule serviceTarget: 2h lifecycleStatus: PILOT
Control Coverage با Test Coverage یکی نیست
Control Coverage یعنی آیا Protection objectiveهای ثبتشده حداقل Control معتبر در Mode و نقطهٔ لازم دارند؛ نه اینکه چند خط کد اجرا شده است. یک Risk ممکن است Detection خوب ولی Containment و Recovery نداشته باشد. درصد کلی میتواند این شکاف را پنهان کند؛ پس Critical objectiveها را بهصورت hard constraint نگه دارید.
| Objective | Prevent | Detect | Contain | Recover | Learn |
|---|---|---|---|---|---|
| Duplicate callback | idempotency contract | stateful check | unique key | reconcile | escape review |
| Money display mismatch | canonical IRR type | format examples | display-only boundary | correct presentation | model update |
| Collector unavailable | pinned config | health check | do not publish stale PASS | rerun | incident correction |
Handoff همیشه اتلاف نیست؛ Handoff مبهم اتلاف میسازد
یک Handoff میتواند استقلال شناختی، جداسازی وظیفه، دسترسی تخصصی یا نمایندگی Stakeholder را حفظ کند. حذف مکانیکی آن ممکن است Evidence را ضعیف کند. مسئله وقتی شروع میشود که Work با پیام «لطفاً QA کنید» وارد صف شود و Scope، Build، Risk، Readiness، موعد و Rule بازگشت معلوم نباشد.
Handoff Contract: قالب آماده
handoff:
id: HO-CHECKOUT-25
version: 2
fromCapability: development
toCapability: independent-test-analysis
workItemId: CHANGE-25
subjectId: BUILD-SYN-25
requiredInputs:
- risk-delta/RD-25
- change-manifest/CM-25
- component-evidence/CE-25
- environment/ENV-SYN-25
readinessRule: all-inputs-valid-and-same-build
acceptRule: scope-capacity-access-confirmed
rejectRule: missing-or-foreign-evidence
returnReason: structured-finding-only
resumeCondition: corrected-build-plus-targeted-evidence
queueId: Q-INDEP-TEST
wipLimit: 3
serviceTarget: 4h
feedbackChannel: work-item-thread
escalation: capability-owner-after-2h-risk
status: ACCEPTED
Readiness؛ QA نباید بستهٔ ناشناخته را Reverse-engineer کند
- Work item و تغییر قابلردیابیاند.
- Subject، Commit، Build، Artifact و Environment یکساناند.
- Risk delta و Quality question نوشته شدهاند.
- Evidence قبلی و Unknownها ضمیمهاند.
- Data، access، Tool و Cleanup آمادهاند.
- Scope، Not-in-scope، موعد و Decision consumer مشخصاند.
Readiness یک Gate برای پنهانکردن کار نیست. اگر Input ناقص است، Return reason باید ساختاری و Resume condition روشن باشد. تکرار Returnها یک Signal دربارهٔ Interface یا Capability است، نه بهانهای برای سرزنش Producer.
Result Vocabulary؛ «QA Approved» چه چیزی را پنهان میکند؟
| Result | معنا | Outcome نمونه |
|---|---|---|
| PASS | Question محدود طبق Evidence پاسخ موافق گرفته | مصرف در Decision؛ نه تضمین |
| FAIL_PRODUCT | رفتار Subject با Oracle ناسازگار است | Finding و repair |
| FAIL_TESTWARE | روش/Oracle/Check معیوب است | تعمیر Testware و rerun |
| ERROR_ENV | Environment مانع Observation معتبر است | repair environment |
| BLOCKED_INPUT | ورودی یا Access حاضر نیست | Return با resume condition |
| INCONCLUSIVE | Evidence برای Verdict کافی نیست | Unknown و follow-up |
| NOT_APPLICABLE | Trigger برای این Change صدق نمیکند | rationale ثبت شود |
Approval کلی، Failure attribution و محدودیت Evidence را پاک میکند. QA ممکن است Evidence تولید یا Challenge کند، اما تصمیم Release باید در مدل اختیار سازمان و با Risk/Evidenceهای لازم باشد. گزارش تست و تصمیم انتشار این مرز را عملی میکند.
صف QA را قبل از افزایش نفر تشخیص دهید
صف میتواند از Demand بیشتر از Capacity، Batch بزرگ، ورودی ناقص، اولویت مبهم، Environment مشترک، rerun، انتظار تصمیم یا تخصص تکنفره ساخته شود. افزودن Tester فقط یکی از گزینههاست و اگر علت Work arrival یا Rework باشد، صف دوباره رشد میکند.
| Signal | تعریف لازم | پرسش |
|---|---|---|
| Arrival rate | Work item واجد Readiness در window | تقاضا چه الگوی زمانی دارد؟ |
| Throughput | Work item با Outcome معتبر در window | خروجی واقعی چقدر است؟ |
| Queue age | اکنون منهای readyAt | کدام Item پیر شده؟ |
| Wait time | acceptedAt منهای readyAt | قبل از شروع چقدر منتظر است؟ |
| Service time | finishedAt منهای acceptedAt با policy pause | اجرای قابلیت چقدر زمان میبرد؟ |
| Return rate | Returned/accepted با reason | Interface مشکل دارد؟ |
| Blocked age | زمان در stateهای Blocked | وابستگی بیرونی کجاست؟ |
| Demand mix | Risk/type/size/urgency | میانگین، کار پیچیده را پنهان کرده؟ |
Little’s Law را فقط با تعریف پایدار استفاده کنید
Average WIP ≈ Average Throughput × Average Flow Time
این رابطه برای مشاهدهٔ یک سیستم نسبتاً پایدار مفید است؛ نسخهٔ جادویی برای پیشبینی نیست. Entry/Exit boundary، window، rework، cancellation، priority class و pause policy باید ثابت باشند. در Burst، Expedite یا تغییر ظرفیت، Median و percentile و نمودار Age از یک میانگین تنها مفیدترند.
Single Point of Failure را در Capability پیدا کنید، نه در عنوان شغلی
ممکن است سه Tester داشته باشید اما فقط یک نفر Certificate، Access، Domain model یا توان Repair داشته باشد. Backup با «یک نفر دیگر هم هست» ثابت نمیشود؛ باید Trial نماینده و recoverable انجام شود و Evidence نشان دهد Capability دوم میتواند Control را در Service target اجرا و Failure را Escalate کند.
| وابستگی | آزمون Continuity | راهحل نمونه |
|---|---|---|
| دانش Domain | Backup یک Question را مستقل تحلیل کند | model + pairing + review |
| Access | دسترسی زماندار در Sandbox | role-based access و expiry |
| Tool/Framework | Backup یک Run و repair امن انجام دهد | runbook + restore |
| Decision | Escalation در غیبت Owner تمرین شود | delegation policy |
| Environment | Namespace دوم provision شود | IaC/lease/cleanup |
Independence Contract؛ استقلال را درجهبندی کنید
| سطح | نمونه | مزیت | محدودیت |
|---|---|---|---|
| Self | Author component check | Feedback سریع و Context بالا | Bias مشترک |
| Peer | همتیمی غیرنویسنده | نگاه دوم با Context | مدل مشترک |
| Specialist in product team | Tester/Domain/Security capability | Challenge تخصصی | ممکن است Authority مبهم باشد |
| Organizational independent | تیم جدا با charter | استقلال بیشتر | Feedback و Handoff cost |
| External | طرف مستقل در Scope لازم | استقلال بالا | هزینه و Context کمتر |
سطح را از Risk، Policy و نوع Bias انتخاب کنید؛ نه از مد سازمانی. چند سطح میتوانند مکمل باشند. استقلال نباید دسترسی به Basis، گفتگو یا Evidence را قطع کند و Whole-team نیز نباید Challenge مستقل را حذف کند.
Shift-left؛ انتقال سؤال، نه انتقال همهٔ کارها
برای هر Quality question، «earliest capable point» را پیدا کنید. ابهام واحد پول در مثال و Type بهتر از E2E دیده میشود؛ رفتار واقعی مرورگر یا بازیابی پس از Failure ممکن است به نقطهٔ نمایندهتر در سمت راست نیاز داشته باشد. Shift-left و Shift-right مکملاند. ادغام این Signalها در یک Loop در راهنمای تست در SDLC آمده است.
| Question | Earliest capable | Later representative |
|---|---|---|
| فرمول fee | example/property/component | ledger reconciliation |
| API contract | schema/consumer contract | deployed integration |
| RTL rendering | component visual | browser/device matrix |
| recovery | state model | fault injection/restore drill |
| user outcome | example/journey hypothesis | representative observation |
Automation یک Control است، نه انتقال مسئولیت
CI میتواند Check را اجرا و Evidence بسازد؛ اما Question، Oracle، candidate، maintenance، failure attribution و retirement همچنان Owner میخواهند. Pipeline سبز همهٔ نقصهای جدید را دفع نمیکند. برای Lifecycle کامل، راهنمای اتوماسیون تست از Check تا Evidence و Retirement را بخوانید.
RACI کافی نیست؛ Decision Rights را بنویسید
RACI میتواند مشارکت را نشان دهد، ولی اگر نوع تصمیم روشن نباشد، حرف A یا R مبهم میماند. فرق دارد چه کسی Method را انتخاب میکند، چه کسی Evidence را معتبر میداند، چه کسی Risk را میپذیرد، چه کسی Deployment را اجرا میکند و چه کسی Incident را اعلام میکند.
| تصمیم | Authority نمونه | ورودی لازم |
|---|---|---|
| Control design | capability owner با Risk input | Question، constraint، cost |
| Evidence verdict | Executor/Reviewer طبق charter | same-subject manifest |
| Risk acceptance | Risk owner مجاز | impact، alternatives، expiry |
| Release decision | Release authority | چند Evidence و Unknown |
| Emergency containment | incident authority | trigger و rollback boundary |
Evidence Manifest برای هر Control
evidenceManifest: id: EVID-CTRL-25 subjectId: checkout-api@C25 buildId: BUILD-SYN-25 changeId: CHANGE-25 controlId: CTRL-DETECT-25 methodVersion: idempotency-contract-suite/v6 artifact: artifacts/RUN-25/result.json digest: sha256:... startedAt: 2026-08-13T08:12:00Z finishedAt: 2026-08-13T08:15:00Z producer: pipeline/SYN-25 reviewer: independent-reviewer unknowns: [real-psp-reordering] redaction: synthetic-only retention: 90d
Exception؛ وقتی Control فعلاً قابلاجرا نیست
Exception مجوز دائمی عبور نیست. باید Risk، دلیل، Scope، compensating control، Authority، effective time، expiry، affected changes و revalidation داشته باشد. نبود ظرفیت QA بهتنهایی دلیل پذیرش کیفیت نیست؛ یک Constraint است که صاحب تصمیم باید آن را همراه با گزینهها ببیند.
exception: id: EX-CTRL-25 controlId: CTRL-DETECT-25 reason: "sandbox unavailable" affectedSubject: BUILD-SYN-25 compensatingControl: limit-feature-flag-plus-reconcile riskOwner: authorized-risk-owner effectiveFrom: 2026-08-13T08:00:00Z expiresAt: 2026-08-13T14:00:00Z revalidation: run-control-after-sandbox-restore status: ACTIVE
Correction؛ اگر QA Approval به Build اشتباه وصل شد
correction: id: CORR-CTRL-25 detectedAt: 2026-08-13T10:00:00Z cause: "EVID-24 برای BUILD-SYN-25 مصرف شده بود" invalidEvidence: EVID-24 affectedDecisions: [REVIEW-25, RELEASE-CANDIDATE-25] containment: "Approval INVALID و downstream متوقف" revalidation: RUN-25R1 correctedResult: INCONCLUSIVE republishStatus: COMPLETE notified: [evidence-owner, decision-owner] prevention: build-digest-equality-rule status: CLOSED
Correction فقط اصلاح تیک روی Board نیست. هر تصمیم مصرفکننده باید پیدا، وضعیت قبلی باطل، Evidence جدید تولید و نتیجه بازنشر شود. اگر هیچکس نمیداند QA Approval کجا مصرف شده، Approval یک Control قابلحسابرسی نیست.
آزمایشگاه مصنوعی Checkout فارسی
مثال این مقاله کاملاً جدا و ساختگی است: `SYN-CHECKOUT` با Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation جعلی. Scenarioها شامل timeout قبل/بعد از fake commit، Callback تکراری/دیر/جابجا، retry و restore هستند. هیچ شبکه، Production، شرکت، تیم، کاربر، پرداخت، بانک یا PSP واقعی در آزمایش وجود ندارد.
| بعد | طراحی مصنوعی | Control question |
|---|---|---|
| Money | IRR خیالی canonical؛ تومان فقط نمایشی و برچسبدار | نوع/تبدیل/ledger کجا Prevent و Detect میشود؟ |
| Digits | فارسی، عربی و لاتین | parsing در کدام Layer Evidence دارد؟ |
| Unicode/RTL | NFC، RTL/LTR و stable ID | Contract و Browser observation چگونه مکملاند؟ |
| Time | UTC، Asia/Tehran و جلالی صرفاً نمایشی | Cutoff و display از هم جدا هستند؟ |
| State | duplicate/late/reordered callback | Prevention، detection، containment و recovery موجودند؟ |
| Identity | Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا | Evidence به Subject همان Build وصل است؟ |
هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی استفاده نشده است. این Lab هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا انطباق دربارهٔ ایران ندارد.
آزمایش اجرایی SYN-QUALITY-SAFETY-NET-DEPENDENCY-۰۱
یک Validator مستقل، قطعی و بدون dependency با Node.js v26.۷.۰ اجرا شد. Dashboard سطحی ۴۲/۴۲ تغییر با QA Approval، صفر Incident و میانهٔ انتظار شش ساعت داشت و PASS میداد. Validator قرارداد را با ۱۴۷ قاعده ارزیابی کرد.
| گروه | تعداد قاعده | نمونه |
|---|---|---|
| Identity | ۱۸ | Product، Risk، Strategy، DoD، Commit، Build، Change |
| Model | ۱۵ | Purpose، Decision، Scope، Objective، Claim limit، Unknown |
| Control | ۲۸ | Mode، Trigger، Capability، Authority، Backup، Evidence، Capacity |
| Handoff | ۲۰ | Inputs، Readiness، Accept/Reject، Queue، WIP، times، Escalation |
| Evidence | ۱۵ | Subject/Build/Control binding، Artifact/digest، time، retention |
| Governance | ۱۸ | Rights، independence، continuity، baseline، guardrail، Correction |
| ادعاهای ممنوع | ۲۷ | QA=quality/release، نقش اجباری، تضمین، حذف استقلال/تست دیرهنگام |
| روابط بینفیلدی | ۶ | پنج Mode، Backup، same-Build، service target، resume، authority |
نسخهٔ سطحی با ۱۴۶ Finding به HOLD رفت: همهٔ ۱۱۴ فیلد قرارداد غایب، هر ۲۷ ادعای مطلق فعال و پنج رابطهٔ بینفیلدی نقض شده بود. رابطهٔ ششم عمداً Finding نداد، چون Rule مخصوص Work با وضعیت RETURNED بود و رکورد سطحی اصلاً وضعیت RETURNED نداشت؛ شمارش برای رسیدن به عدد زیباتر دستکاری نشد.
fixture: SYN-QUALITY-SAFETY-NET-DEPENDENCY-01 rules: 147 superficial dashboard: qaApproved: 42/42 productionIncidents: 0 medianQaWaitHours: 6 dashboardVerdict: PASS contractStatus: HOLD findings: 146 corrected system: controls: PREVENT + DETECT + CONTAIN + RECOVER + LEARN build: BUILD-SYN-25 executorCapability: explicit backupCapability: exercised decisionAuthority: governed handoffStatus: ACCEPTED structuralFindings: 0 status: READY_FOR_PROTECTION_SYSTEM_REVIEW
در نسخهٔ اصلاحشده، هویتها Pin، Protection objective و Claim limit تعریف، پنج Mode با مجری/Backup و Evidence همان Build ساخته، Handoff و Decision right کامل و Correction فعال شد. خروجی با صفر Finding به `READY_FOR_PROTECTION_SYSTEM_REVIEW` رسید؛ عمداً نه صدق Method/Evidence، نه کاملبودن Controlها، نه نبود نقص یا Incident، نه Product quality، نه سرعت بهتر و نه آمادگی Release را اثبات میکند.
چه چیزی را توزیع کنیم و چه چیزی را مستقل نگه داریم؟
| قابلیت | قابلتوزیع نمونه | استقلال محتمل |
|---|---|---|
| Example refinement | Product، Dev، Test مشترک | Challenge مستقل در Risk بالا |
| Component checks | نزدیک Author با Peer review | Sample مستقل |
| System investigation | Tester/Domain capability | Reviewer غیرنویسنده |
| Security/Safety evidence | ابزار/تیمهای مختلف | طبق Policy و Context |
| Risk acceptance | اطلاعات مشترک | Authority مستقل از Evidence producer |
| Release execution | Platform automation | Separation of duties در صورت نیاز |
نقش Tester را از عنوان ثابت به Capability تبدیل کنید
Tester میتواند Test design، Investigation، Risk analysis، Automation، facilitation یا independent challenge انجام دهد؛ اما هیچ مسیر جهانی وجود ندارد که هر Tester باید Coach، Automation specialist یا «صدای کاربر» شود. Role charter باید با Work demand، مهارت، علاقه، اختیار، حمایت و استقلال متناسب باشد. کاربر واقعی و نمایندهٔ کسبوکار نیز قابلجایگزینی با حدس Tester نیستند.
توانمندسازی بدون انتقال کار نامرئی
- Teaching، Pairing و Review را Work ظرفیتدار و جبرانشده حساب کنید.
- انتقال Capability باید Practice امن، Feedback و Trial داشته باشد؛ نه فقط سند.
- تستر نباید علاوه بر صف قبلی، مسئول آموزش همه و نگهداشت همهٔ Toolها شود.
- توسعهدهنده نیز نباید بدون زمان، Access و پشتیبانی مالک Control تازه اعلام شود.
- Accessibility، timezone، زبان، remote work و accommodation را در طراحی Support لحاظ کنید.
شاخصهای سیستم؛ نه KPI برای رتبهبندی آدمها
| Measure | Countermeasure | محدودیت |
|---|---|---|
| Queue age percentile | Risk/demand mix | سرعت بهتنهایی کیفیت نیست |
| Ready-first-time rate | Question complexity | Reject کمتر همیشه بهتر نیست |
| Feedback age | Evidence validity | Feedback سریعِ غلط مضر است |
| Control-mode gaps | Control cost/maintenance | Control بیشتر همیشه بهتر نیست |
| Backup trial coverage | independence level | Cross-training استقلال را حذف نکند |
| Return/rework rate | escaped-risk sample | کاهش Return با Approval سطحی ممکن است |
| Exception age | compensating evidence | Expiry بدون Risk review کافی نیست |
| Correction closure | affected-decision completeness | Close اداری با repair فرق دارد |
Automation و AI در توزیع Control
Automation میتواند Routing، Readiness validation، Evidence binding، queue age، escalation و backup notification را اجرا کند. AI میتواند Work را خوشهبندی، Control gap یا Return reason پیشنهادی تولید و Runbook را بازیابی کند؛ اما نباید بهتنهایی PASS، Exclusion، Risk acceptance، independence waiver، performance evaluation یا Release را تصویب کند.
- Prompt، مدل، Policy و Sourceهای مجاز نسخهدار باشند.
- دادهٔ Production، شخصی یا Credential وارد ابزار تأییدنشده نشود.
- Confidence و Unknown نمایش و Human reviewer ثبت شود.
- حق اعتراض و مسیر دستی برای Work routing و ارزیابی حفظ شود.
- AI output Evidence محسوب نشود مگر با Method و validation مستقل.
۳۲ ضدالگوی شبکه ایمنی QA
| ضدالگو | خطر | اصلاح |
|---|---|---|
| QA مالک همهٔ کیفیت | Authority نامتناسب | Control/decision map |
| Dev فقط کد مینویسد | Feedback دیر | capability contribution |
| QA همهٔ Bugها را مییابد | Expectation ناممکن | bounded claim |
| QA Approved=کیفیت | Evidence مبهم | question/result manifest |
| QA Approved=Release | اختلاط Authority | release decision model |
| صفر Incident=صفر Risk | absence-of-evidence | exposure/unknown |
| Waterfall همیشه جداست | کاریکاتور فرآیند | flow evidence |
| Agile استقلال را حذف میکند | Challenge ضعیف | contextual independence |
| Shift-left=همهچیز زودتر | Fidelity پایین | earliest capable + representative |
| تست دیرهنگام حذف شود | Risk نماینده دیده نمیشود | shift-right complement |
| Prevention=بدون Defect | تضمین کاذب | detect/contain/recover |
| CI همهٔ Regressionها را میگیرد | Oracle/coverage gap | claim limit |
| Unit test فقط کار Dev | تقسیم عنوانی | capability/context |
| Tester در همهٔ جلسهها | بار و حضور نمایشی | Question-triggered interface |
| هر Tester باید Coach شود | مسیر اجباری | role charter/consent |
| هر Tester متخصص Automation | نادیدهگرفتن Work demand | portfolio of capabilities |
| Tester بهترین نمایندهٔ کاربر | جانشینی Stakeholder | real representation |
| Automation جای Manual | دوگانهٔ کاذب | question/method fit |
| Shared=بدون Owner | پاسخگویی محو | explicit authority |
| Independence=Isolation | Context قطع | access + cognitive independence |
| هر Handoff اتلاف است | حذف separation | handoff contract |
| «لطفاً QA کنید» | Scope نامحدود | question/readiness |
| Approval بدون Build | Evidence foreign | subject digest |
| صف با نفر حل میشود | علت پنهان | demand/rework diagnosis |
| Average wait تنها | Tail پنهان | age percentile/mix |
| Backup روی کاغذ | Continuity کاذب | representative trial |
| Access دائمی برای Backup | ریسک دسترسی | time-bound role |
| Control بیشتر=کیفیت بیشتر | هزینه و تضاد | objective/cost review |
| سرعت بیشتر=کیفیت بهتر | Goodhart | guardrail/evidence |
| Exception بدون Expiry | دورزدن دائمی | owner/revalidation |
| AI تصمیمگیر Risk | واگذاری Authority | human accountable review |
| اصلاح تیک بدون Impact | تصمیم آلوده | affected-decision correction |
چکلیست ممیزی Protection System
- Program/Product/Goal/Risk/Strategy/Policy نسخهدارند؟
- Repository، Commit، Build، Deployment، Environment و Change قفلاند؟
- Model ID/version، Purpose، Decision و Scope روشناند؟
- Protection objective و Claim limit نوشته شدهاند؟
- هر Risk/Question به Control مشخص وصل است؟
- PREVENT، DETECT، CONTAIN، RECOVER و LEARN بررسی شدهاند؟
- Mode و Flow point هر Control قابلدفاع است؟
- Trigger و Subject دقیقاند؟
- Method/Tool/version معلوماند؟
- Producer، Executor و Reviewer capability روشناند؟
- Decision authority با Governance سازگار است؟
- Independence level از Risk انتخاب شده است؟
- Backup capability در Trial آزموده شده است؟
- Access، Capacity و Support تعریف شدهاند؟
- Evidence rule و Freshness همان Build را الزام میکنند؟
- Result vocabulary و Failure outcome تشخیصیاند؟
- Handoff ورودی و Readiness rule دارد؟
- Accept/Reject و Return reason استانداردند؟
- Resume condition برای Returned Work وجود دارد؟
- Queue، WIP، arrival/accepted/due times ثبت میشوند؟
- Service target و Escalation Risk-aware هستند؟
- Manifest Artifact/digest/time/producer/reviewer دارد؟
- Unknown، redaction و retention ثبتاند؟
- RACI با Decision rights تکمیل شده است؟
- Separation of duties و minimum independence حفظاند؟
- Exception Owner/Expiry/compensating Control دارد؟
- Baseline، Measure، Countermeasure و Cost guardrail دارید؟
- Correction affected decisions و revalidation را پوشش میدهد؟
- Measureها برای رتبهبندی افراد استفاده نمیشوند؟
- AI اختیار Approval، Risk یا Release ندارد؟
برنامه ۳۰ روزه برای حذف وابستگی تکنقطهای
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | یک Flow/Protection objective و دادهٔ صف را Baseline کنید | Current-state map و Unknown |
| روز ۶–۱۰ | Controlها، Mode، Authority و Handoffها را ثبت کنید | Control Map v1 |
| روز ۱۱–۱۵ | یک Missing mode و یک ambiguous handoff را اصلاح کنید | Contract و Evidence rule |
| روز ۱۶–۲۰ | Backup Trial و independence review انجام دهید | Continuity evidence |
| روز ۲۱–۲۵ | Queue/WIP/service target و Correction drill اجرا کنید | Flow signal و affected-decision path |
| روز ۲۶–۳۰ | Pilot را با Guardrail بازبینی کنید | Keep/Adapt/Stop و Backlog محدود |
Pilot را با «QA دیگر گلوگاه نیست» اعلام نکنید. بررسی کنید آیا Feedback معتبر زودتر شد، Tail صف و Return علتدار کم شد، Backup بدون حذف استقلال کار کرد، Unknown دیده شد و هیچ Control حیاتی بیOwner نماند. کاهش زمان همراه با Evidence ضعیف شکست است.
جمعبندی: تستر را حذف نکنید؛ وابستگی مبهم را طراحی کنید
مشکل «تستر بهعنوان شبکه ایمنی» وجود تخصص تست نیست؛ این است که سازمان تمام Protection را به یک Catch-all دیرهنگام، بدون Contract، ظرفیت، Backup یا اختیار روشن سپرده باشد. پاسخ نیز شعار، Automation کامل یا انتقال همهٔ کارها به Developer نیست. Protection Control Map نشان میدهد کجا باید Prevent، Detect، Contain، Recover و Learn کرد؛ Handoff Contract استقلال را بدون صف مبهم حفظ میکند؛ و Evidence/Correction اجازه میدهد تصمیمها بازبینی و اصلاح شوند.
سوالات متداول درباره تستر بهعنوان شبکه ایمنی
آیا کیفیت فقط مسئولیت تیم QA است؟
خیر. قابلیتهای Product، Development، Testing، Platform و Risk در کیفیت اثر دارند. اما Shared responsibility به معنی بیمالکبودن نیست؛ هر Control باید Executor، Reviewer، Decision authority، Backup و Escalation روشن داشته باشد.
آیا Whole-team approach تست مستقل را حذف میکند؟
خیر. سطح استقلال به Context و Risk بستگی دارد. Self-test، Peer، Specialist، تیم مستقل و طرف بیرونی میتوانند مکمل باشند. Whole-team همکاری و دسترسی را تقویت میکند؛ Independence تفاوت دید و جداسازی لازم را حفظ میکند.
چطور بفهمیم QA واقعاً گلوگاه است؟
Arrival، Throughput، Queue age percentile، Wait، Service time، Blocked age، Return reason و Demand mix را با مرز ثابت اندازه بگیرید. سپس علت را میان ظرفیت، Batch، ورودی ناقص، Environment، Rework، Authority و تخصص تکنفره تفکیک کنید.
آیا Shift-left یعنی همه تستها را زودتر انجام دهیم؟
خیر. هر Quality question را در اولین نقطهٔ واقعاً توانمند بررسی کنید و Evidence نمایندهتر را در نقطهٔ لازم نگه دارید. سؤال فرمول را میتوان زود دید؛ رفتار مرورگر، یکپارچگی یا Recovery ممکن است later-stage observation بخواهد.
اولین اقدام برای کاهش وابستگی به یک تستر چیست؟
یک Flow و یک Protection objective را انتخاب کنید؛ Controlها، Handoffها، Authority، Evidence و Backup را روی نقشه بیاورید. سپس فقط یک Missing mode یا Handoff مبهم را در Pilot اصلاح و با Queue age، Evidence validity و Guardrail ارزیابی کنید.
