Shift-left وقتی به شعار تبدیل میشود که تستر در جلسههای بیشتری حاضر باشد، چند Check زودتر اجرا شود و تیم نتیجه بگیرد «کیفیت از ابتدا ساخته شد». حضور زودهنگام، تعداد تست، Code Coverage یا سبزی CI نشان نمیدهد سؤال درست در زمان مناسب پرسیده شده، Source جاری بوده، Evidence محدودیتهایش را حفظ کرده یا Risk در مرحلهٔ دیرتر و واقعیتر دوباره بررسی شده است.
این راهنما نقش تستر را به مربی، معمار یا قهرمان کیفیت ارتقا نمیدهد. قابلیت تست کمک میکند برای هر Risk یک Quality Interface بسازیم: Source و سؤال قابلبررسی، earliest economical feedback point، Artifact و Owner، Evidence و Unknown، موعد بازخورد و Countercheck دیرتر. Shift-left در این مدل «چپبردن همهٔ تستها» نیست؛ طراحی جریان Evidence از Discovery تا Production است.
مسیر کوتاه: Shift-left قابلردیابی در هفت گام
| گام | پرسش | خروجی |
|---|---|---|
| Context | کدام Goal/Basis/Architecture/DoD/Risk جاری است؟ | Baseline نسخهدار |
| Question | چه ادعایی باید شکسته یا پشتیبانی شود؟ | Quality Question |
| Earliest | ارزانترین نقطهٔ معنادار بازخورد کجاست؟ | Feedback point + rationale |
| Artifact | چه Example/Model/Contract/Fixture لازم است؟ | Versioned artifact |
| Evidence | چه چیزی و با چه محدودیتی مشاهده شد؟ | Evidence/Unknown |
| Countercheck | کدام Risk فقط دیرتر دیده میشود؟ | Later/right-side check |
| Decision | چه کسی تا چه زمانی چه اقدامی میکند؟ | Disposition/Owner/Due |
Shift-left چیست و چه چیزی نیست؟
در ISTQB CTFL 4.0.1، Shift-left نمونهای از اصل Early testing است: تست زودتر در SDLC انجام میشود، بیآنکه تست دیرتر نادیده گرفته شود. Review مشخصات، Test-first، CI/CD با Component tests، Static analysis پیش از Dynamic testing و شروع زودتر برخی تستهای Non-functional مثالاند. همان منبع میگوید effort، آموزش یا هزینهٔ اولیه ممکن است بیشتر شود؛ پس «زودتر» مساوی «رایگانتر» یا «همیشه بهتر» نیست.
| Shift-left هست | Shift-left نیست |
|---|---|
| بازخورد معنادار پیش از قفلشدن تصمیم | اجرای همهٔ Suiteها روی هر Commit |
| بازبینی Basis/Example/Model/Contract | جلسهنشینی اجباری تستر |
| طراحی Testability و Observability | انتقال همهٔ تست به Developer |
| کاهش فاصلهٔ Signal تا Owner | حذف System/UAT/Exploration/Production feedback |
| توزیع Risk evidence در چرخه | Tool list یا Automation-first |
| انتخاب earliest economical point | چپترین نقطه به هر قیمت |
برای تعریف عمومی، مثالها و نقشهٔ Discovery تا CI، راهنمای جامع تست Shift-left را بخوانید. این مقاله بهطور متمایز Interface نقش قابلیت تست و اتصال Early evidence به Countercheckهای بعدی را مالک است.
اصل طراحی: earliest economical feedback، نه earliest possible
ممکنبودن یک Check به معنی ارزشمندبودن آن نیست. سؤال باید در نقطهای پرسیده شود که Artifact کافی برای پاسخ محدود وجود دارد، هزینهٔ تغییر هنوز قابلقبول است و false confidence یا نگهداری کنترل از ارزش Feedback بیشتر نیست. Security configuration واقعی، رفتار multi-service، تجربهٔ کاربر و Capacity گاهی فقط در مراحل دیرتر معنا دارند.
| سؤال | Early signal | چرا کافی نیست؟ | Countercheck |
|---|---|---|---|
| Rule مبلغ درست است؟ | Example/decision table | Implementation/state ناشناخته | property/integration |
| Authorization طراحی شده؟ | Role matrix/threat review | Policy/config/runtime drift | negative system/runtime detection |
| API compatible است؟ | schema/contract fixture | deployment/data/version skew | consumer/integration |
| Latency محلی Regression ندارد؟ | component benchmark | network/dependency/workload fidelity | system load/SLI observation |
| Journey قابلفهم است؟ | prototype/example review | واقعیت استفاده نماینده نیست | usability/UAT/feedback |
مالکیت این مقاله: Early Quality Interface Contract
Goal / Test Basis / Architecture / DoD / Risk -> Bounded Quality Question -> Earliest Economical Feedback Point -> Versioned Artifact / Model / Fixture -> Capability Owner + Feedback Due -> Evidence + Limitation + Unknown -> Disposition / Decision / Change -> Later Countercheck / Production Feedback -> Correction / Learning / Updated Risk
Quality Interface یک Handoff تازه به QA نیست. Record مشترکی است که میگوید کدام سؤال چرا در کدام نقطه بررسی میشود و کدام ادعا هنوز باز است. Owner مسئول ساخت یا پیگیری Evidence است؛ مالک انحصاری کیفیت یا مقصر Failure نیست.
Baseline نقش و کار را پیش از Shift قفل کنید
| هویت | نمونه | خطر Drift |
|---|---|---|
| Initiative/Product Goal | INIT-17/PG-9 | سؤال برای هدف قدیمی |
| Sprint Goal | SG-17 | کار زودهنگام بیربط |
| Test Basis | BASIS-v4 | Review Requirement منسوخ |
| Architecture | ARCH-v3 | Contract روی interface قدیمی |
| Definition of Done | DOD-v4 | Evidence ناقص |
| Risk Registry | RISK-v5 | coverage نمایشی |
| Pipeline/Policy | PIPE-v4 | Checkهای stale |
| Facts cutoff | ISO instant | ادعای تازگی مبهم |
qualityInterfaceBaseline: initiative: INIT-17 productGoal: PG-9 sprintGoal: SG-17 testBasis: BASIS-v4 architecture: ARCH-v3 definitionOfDone: DOD-v4 riskRegistry: RISK-v5 pipeline: PIPE-v4 factsCutoff: 2026-08-12T13:30:00Z participants/perspectives: declared
از Risk به سؤال قابلشکستن برسید
| سؤال مبهم | سؤال محدود |
|---|---|
| آیا کار میکند؟ | Callback تکراری با Event ID یکسان فقط یک Ledger effect میسازد؟ |
| آیا امن است؟ | Support role خارج Tenant برای Order خواندن/نوشتن را deny میشود؟ |
| آیا سریع است؟ | B17 نسبت به B16 در Workload/Environment یکسان، p95 policy را نقض میکند؟ |
| آیا کاربر راضی است؟ | کاربر نماینده میتواند Reference بازگشت وجه را بدون کمک پیدا کند؟ |
| آیا تستپذیر است؟ | Attempt/Event/Build/Run identity در Evidence قابل correlation است؟ |
هر سؤال باید Subject، Condition، Behavior/quality characteristic، Oracle direction و forbidden inference داشته باشد. سؤال خوب الزاماً Test case نیست؛ میتواند Review question، Example، Model query، Experiment یا Observability obligation باشد.
قالب Quality Interface
qualityInterface: id: QI-2 riskRef: RISK-v5#R2 sourceRef: BASIS-v4#AUTHZ-7 question: support role outside tenant is denied read/write? earliestPoint: contract/component economics: role matrix + fake are cheap; runtime config remains artifact: AUTHZ-MATRIX-v2 owner: whole-team/ST17 evidence: EV-AUTHZ-COMP-17 limitation: component policy; no deployed overlay unknowns: production identity/config drift feedbackDue: before merge C17 disposition: PARTIAL_EVIDENCE laterCountercheck: system negative suite + production detection
Discovery: Example برای یادگیری، نه Acceptance صوری
در Discovery یا Refinement، تستر میتواند Rule، Example، Counterexample، boundary، actor، state transition و Unknown را آشکار کند. نتیجه باید Test Basis یا Decision record را تغییر دهد؛ صرف نوشتن سناریو در تخته Evidence نیست. اگر stakeholder یا Source لازم غایب است، سؤال `OPEN` میماند.
| Artifact | کارکرد | خروجی | Countercheck |
|---|---|---|---|
| Example map | Rule/example/question | Basis decision | executable/example test |
| Journey map | actor/context/handoff | risk/questions | usability/production feedback |
| State model | transition/invariant | model obligations | property/system test |
| Threat/abuse model | asset/boundary/actor | security controls | dynamic/runtime checks |
| Prototype | interaction hypothesis | observations/unknown | representative-user evidence |
روش تحلیل Basis، Source hierarchy و پرسشهای تستر در تحلیل Test Basis از نیازمندی تا Risk آمده است.
Architecture: Testability یک ویژگی قابلطراحی است
- Controllability: state، time، dependency و failure چگونه کنترل میشوند؟
- Observability: outcome، identity، trace و invariant چگونه دیده میشوند؟
- Isolability: component/tenant/test چگونه از دیگران جدا میشود؟
- Determinism/Reproducibility: seed، clock، ordering و replay چگونه ثبت میشوند؟
- Diagnosability: Failure به Build/Run/Input/Dependency وصل میشود؟
- Safety: test hook/fake/debug path در Production چه سطح حملهای میسازد؟
Testability به معنی اضافهکردن endpoint مخفی یا bypass امنیتی نیست. Hook باید scope، authentication، environment policy، build flag، audit و removal داشته باشد. طراحی برای تست اگر سطح حمله یا رفتار Production را تغییر دهد، Risk تازه میسازد.
Contract-first: Schema فقط Syntax را میبیند
| کنترل زودهنگام | میبیند | نمیبیند |
|---|---|---|
| Schema validation | type/required/format | business meaning/state |
| Consumer contract | example interaction compatibility | all consumers/deployment skew |
| Fake/stub | declared behavior | real dependency quirks |
| Model/property | invariant over generated cases | oracle/model omissions |
| Static analysis | known source pattern | runtime/config/business path |
Test-first و Example-first ابزارند، نه مذهب
نوشتن Test پیش از Code میتواند Interface، behavior و design feedback بسازد. اما Test بد یا Example ناقص، Implementation را به برداشت غلط قفل میکند. TDD، BDD، ATDD، Example Mapping و Three Amigos اختیاریاند؛ هیچکدام تعریف Scrum یا تضمین کیفیت نیستند. خروجی و Context را بسنجید، نه نام Technique را.
Static feedback و Dynamic evidence مکملاند
Review، lint، type check و Static analysis میتوانند پیش از اجرا Signal دهند، اما Execution، configuration، data، concurrency و dependency behavior را کامل نمیبینند. Dynamic test نیز Sourceهای اجرانشده یا pathهای دستنیافتنی را نمیبیند. Risk باید ترکیب کنترل و residual Unknown داشته باشد؛ سبزی یک لایه جای دیگری نیست.
CI: سریعترین Suite همیشه مفیدترین Suite نیست
| Trigger | Feedback هدف | Control | Later check |
|---|---|---|---|
| local | syntax/unit/example | focused | integration |
| PR | changed risk/contracts | selective stable suite | merge/nightly |
| merge | integrated behavior | broader component/API | system |
| nightly | matrix/longer interactions | risk suite | release/runtime |
| release candidate | bounded system evidence | fuller environment | canary/monitor |
`run everything on every commit` هزینه، queue، flakiness و feedback latency میسازد. Selection باید change graph، Risk، historical evidence و mandatory obligation داشته باشد و آنچه اجرا نشده شفاف بماند. برای طراحی عمومی Pipeline، Continuous Testing در CI/CD را ببینید.
Non-functional را زود سؤال کنید، نه زود کامل اثبات
| ویژگی | Early interface | Later evidence |
|---|---|---|
| Performance | budget/model/component benchmark | system workload/SLI |
| Security | threat/design/static/component | deployed config/dynamic/runtime |
| Accessibility | design semantics/component checks | integrated UI/manual/AT |
| Reliability | failure model/fake/property | recovery/soak/production incident |
| Compatibility | contract/matrix selection | real browser/device/integration |
| Usability | prototype/task hypothesis | representative participant/context |
برای نمونهٔ دقیق Performance، Performance Evidence Ladder در CI/CD و برای Security، Security Control Contract در DevSecOps نشان میدهند Early signal چگونه باید به Subject و Countercheck متصل شود.
Whole-team approach تخصص را حذف نمیکند
Whole-team یعنی کیفیت و فعالیتهای تست در همکاری تیم توزیع میشوند؛ نه اینکه همه مهارت یکسان دارند یا استقلال تخصصی همیشه حذف میشود. متخصص تست میتواند questioning، modeling، oracle، risk، exploration و evidence را عمیقتر کند؛ Developer طراحی/کد/verification را میسازد؛ Product/Business value و rule context میآورد؛ Operations runtime constraints را آشکار میکند.
در Scrum Guide 2020 فقط یک Scrum Team با Product Owner، Scrum Master و Developers وجود دارد؛ زیرتیم یا نقش خاص Tester/QA تعریف نشده است. متخصص تستی که Increment میسازد در معنای گستردهٔ Developers قرار میگیرد. Scrum همچنین Coach/Architect/Champion کیفیت یا QA Release gate تعیین نمیکند.
نقش تستر: Capability contribution، نه ترفیع عنوان
| قابلیت | مشارکت | مرز |
|---|---|---|
| Questioning | فرض/ابهام/Counterexample | صاحب حقیقت نیست |
| Test modeling | state/risk/condition/oracle | مدل کامل نیست |
| Evidence literacy | Subject/source/limitation | Result را quality verdict نکند |
| Exploration | یادگیری تطبیقی | با Automation حذف نشود |
| Testability | control/observe/isolate/diagnose | امنیت/معماری را یکنفره تصمیم نگیرد |
| Facilitation | دیدگاهها را متصل کند | Coach اجباری یا مدیر کیفیت نیست |
مرز مالکیت همگانی و Decision right در راهنمای رهبری تضمین کیفیت بدون ابهام آمده است.
تستر نباید برای ارزشآفرینی به هر جلسه دعوت شود
دعوت اجباری به Discovery، Design، Refinement، Planning و همهٔ Pairها هزینهٔ opportunity دارد و میتواند QA bottleneck تازه بسازد. Participant را بر اساس سؤال و capability انتخاب کنید. ورودی Async، office hour، review-on-demand، نمونهٔ ثبتشده یا pairing زماندار گاهی بهتر از حضور دائم است.
| شرط دعوت | نمونه | خروجی لازم |
|---|---|---|
| Risk/Rule تازه | callback idempotency | Question/Example/Decision |
| Testability decision | clock/correlation hook | architecture obligation |
| Evidence conflict | contract pass/system fail | hypothesis/next check |
| Capability gap | accessibility/security/performance | bounded contribution |
| Routine low-risk | copy change | async/applicability may suffice |
Planning: Early work باید در Plan دیده شود
Example workshop، fake، contract harness، data fixture، observability و countercheck کار واقعیاند. آنها را «رایگان» یا QA overhead پنهان نکنید. Whole Done work و dependency/unknown را در Sprint Planning مبتنی بر Goal/Risk/Evidence مرئی کنید؛ بدون ساخت QA point یا تبدیل Story point به ساعت.
Shift-left نباید استقلال لازم را حذف کند
نزدیکی همکاری Feedback را سریع میکند، اما Confirmation bias و shared blind spot ممکن است بالا رود. Contextهای safety/security/regulatory یا Risk بالا میتوانند review، penetration، audit یا acceptance مستقل بخواهند. استقلال یک طیف و control design است؛ نه دشمن Agile و نه جایگزین همکاری.
Shift-right دشمن Shift-left نیست
Production traffic، real configuration، scale، geography، device، dependency و user behavior در Early fixture کامل نیستند. Observability، canary، feature exposure، incident learning و authorized production test مدل Early را اصلاح میکنند. Shift-right امن Countercheck لازم است؛ نه جبران بیقید تست زودهنگام ضعیف.
Evidence Ladder برای یک Risk
| پله | Artifact/Evidence | Claim | Unknown |
|---|---|---|---|
| Basis | Rule/example decision | intended behavior clarified | implementation |
| Design | state/threat/contract model | design obligation represented | model omission |
| Component | property/example/static | local behavior evidence | integration/config |
| Integration | real protocol/data/failure | interface behavior | system/scale |
| System | journey/environment | bounded end-to-end evidence | production context |
| Production | SLI/incident/feedback | observed operational behavior | counterfactual/future |
Early PASS یک Claim محدود است
evidenceClaim: question: QI-2 subject: AUTHZ component C17 source: BASIS-v4#AUTHZ-7 environment/data: COMP-ENV-4 / DATA-AUTHZ-SYN method: role-matrix generated negative cases result: PARTIAL_EVIDENCE supports: declared component policy denied modeled cross-tenant cases doesNotSupport: deployed overlay, identity provider, production authorization unknowns: U1 runtime config drift laterCountercheck: SYS-AUTHZ-17 + DET-AUTHZ-v2 factsAsOf: ISO instant
آزمایش تکرارپذیر: چهار جلسه و چهار Check کافی است؟
Fixture کاملاً ساختگی SYN-SHIFT-LEFT-QUALITY-INTERFACE-01 حضور تستر در Discovery/Refinement/Design/Planning و چهار Early check دارد؛ کنترل سطحی `PASS` میدهد. Validator سپس Baseline، سؤال، Source، economics، Artifact، Evidence، Countercheck، نقش، Automation، improvement claim و governance را بررسی میکند.
Fixture معیوب در برابر Contract
| بعد | Contract | Draft |
|---|---|---|
| Baseline | INIT17/PG9/SG17/BASIS4/ARCH3/DoD4/RISK5/PIPE4 | همه stale |
| QI-1 | Source/سؤال محدود/rationale/artifact/evidence | «کار میکند؟»/notes/approved |
| QI-2 | Risk current/Countercheck/Due | «امن است؟»/۸۵% coverage |
| Duplicate/Unknown | Unique Risk refs | QI-۲ تکراری و R99 |
| Roles | shared + explicit authority | QA quality/release owner |
| Automation | risk-triggered ladder | همهچیز روی هر Commit |
| Right side | Exploration/runtime feedback | حذفشده |
| Improvement | Hypothesis/baseline/measure/guardrail | 100×/better/faster guarantee |
خروجی Validator: ۴۴ Finding
fixture: SYN-SHIFT-LEFT-QUALITY-INTERFACE-01 runtime: Node.js v26.7.0 superficial: PASS | meetings=4 | earlyChecks=4 auditedDraft: HOLD findings (44): 1 stale-initiative:INIT-16->INIT-17 2 stale-productGoal:PG-8->PG-9 3 stale-sprintGoal:SG-16->SG-17 4 stale-basis:BASIS-v2->BASIS-v4 5 stale-architecture:ARCH-v1->ARCH-v3 6 stale-dod:DOD-v3->DOD-v4 7 stale-riskRegistry:RISK-v2->RISK-v5 8 stale-pipeline:PIPE-v2->PIPE-v4 9 QI-1-missing-source 10 QI-1-question-not-bounded 11 QI-1-earliest-point-not-justified 12 QI-1-artifact-not-versioned 13 QI-1-approval-not-evidence 14 QI-1-later-countercheck-missing 15 QI-1-feedback-due-missing 16 QI-1-disposition-missing 17 QI-2-stale-source 18 QI-2-security-question-unbounded 19 QI-2-earliest-point-not-justified 20 QI-2-coverage-overclaimed 21 QI-2-later-countercheck-missing 22 QI-2-feedback-due-missing 23 duplicate-interface:QI-2 24 duplicate-QI-2-missing-source 25 duplicate-QI-2-average-overclaimed 26 duplicate-QI-2-later-countercheck-missing 27 unknown-risk:R99 28 QI-99-opinion-overclaimed 29 QI-99-later-countercheck-missing 30 qa-exclusive-quality-ownership 31 qa-self-assigned-release-authority 32 developer-capability-silo 33 product-capability-silo 34 all-tests-every-commit 35 later-exploration-removed 36 right-side-feedback-missing 37 cost-quality-speed-guarantee 38 improvement-baseline-missing 39 improvement-measure-missing 40 improvement-guardrail-missing 41 evidence-registry-missing 42 unknowns-omitted 43 exceptions-interface-missing 44 correction-path-missing corrected: READY_FOR_INTERFACE_REVIEW | findings=0
نسخهٔ اصلاحی چه کرد؟
نسخهٔ اصلاحی تمام Baselineها را جاری کرد؛ سه Interface یکتا برای idempotency، authorization و performance ساخت؛ هرکدام را به Risk/Source/سؤال محدود/early economics/Artifact/Owner/Evidence/Due/Disposition/Countercheck بست؛ QA ownership و Release authority خودخوانده را حذف کرد؛ Exploration و Production feedback را حفظ کرد؛ و improvement را Hypothesis با baseline، measure و guardrail نگه داشت.
دو false positive در خود Validator—فرض وجود record چهارم در Fixture سالم و تفسیر واژهٔ `HYPOTHESIS` بهعنوان guarantee—پیش از اجرای نهایی اصلاح شدند. `READY_FOR_INTERFACE_REVIEW` فقط کاملبودن ساختار را میگوید؛ صحت Source/Evidence، کفایت Risk، جلوگیری از Defect، کاهش هزینه/زمان، افزایش کیفیت، موفقیت تیم یا Release را ثابت نمیکند.
آزمایشگاه فارسی و آفلاین Shift-left
Lab یک Checkout خیالی و بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation. Riskهای timeout پیش/پس از commit ساختگی، retry، callback تکراری/دیر/جابجا و اختلاف state فقط برای تمرین Interfaceها هستند. هیچ شرکت، کاربر، پرداخت، بانک، PSP یا Production واقعی در کار نیست.
| مرحله | Artifact | سؤال | Countercheck |
|---|---|---|---|
| Discovery | Rule/Example | تومان view به IRR canonical چگونه تبدیل میشود؟ | property/integration |
| Design | State model | duplicate event invariant چیست؟ | replay/system |
| Contract | PSP fake schema | late/reordered callback چگونه نمایش مییابد؟ | stub-vs-adapter comparison |
| Component | clock/seed fixture | timeout boundary deterministic است؟ | integration time behavior |
| System | offline journey | Ledger/Order reconcile میشوند؟ | runtime detection model |
- IRR کاملاً خیالی Canonical است؛ تومان فقط View صریح.
- رقم فارسی/عربی/لاتین، Unicode و RTL/LTR در Fixture کنترل میشوند.
- زمان به UTC instant و Asia/Tehran view؛ جلالی فقط Presentation است.
- Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence identity جداست.
- هیچ نام/موبایل/ایمیل/IP/PAN/CVV2/OTP/cookie/token/credential/log واقعی وجود ندارد.
- هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی یا حریم خصوصی ایران ساخته نمیشود.
مهارتهای لازم Contextualاند، نه فهرست اجباری
| Capability | تمرین | Evidence انتقال |
|---|---|---|
| Questioning | بازنویسی ۱۰ سؤال مبهم | reviewed QI records |
| Modeling | state/decision/risk model | counterexamples found |
| Technical literacy | read contract/log/code diff | correct subject trace |
| Automation | small reliable fixture | maintained feedback |
| Exploration | charter/debrief/adaptation | new learning |
| Facilitation | bring competing perspectives | decisions/unknowns |
یادگیری Python/JavaScript، Selenium یا CI ممکن است برای یک Context مفید باشد، اما اولین قدم جهانی نیست. ابتدا Work واقعی، capability gap و feedback delay را مشاهده کنید؛ سپس تمرین کوچک با معیار انتقال به کار بسازید. عنوان «تستر مدرن» یا تعداد ابزار، شایستگی را ثابت نمیکند.
اندازهگیری Shift-left بدون Goodhart
| متریک | تعریف | Countermetric |
|---|---|---|
| Feedback age | decision/change→reviewable evidence | weak evidence |
| Question closure | dispositioned / due eligible | premature PASS |
| Source freshness | current refs / required | documentation burden |
| Countercheck linkage | later checks / partial claims | duplicate waste |
| Evidence reuse | valid consumers / evidence | stale propagation |
| Escape learning | late signals updating early model | blame/underreporting |
| Early-work WIP | open QIs/experiments | discovery bottleneck |
Defect count by phase، درصد Automation، Code Coverage، تعداد جلسه و تعداد تست زودهنگام KPI موفقیت نیستند. تغییر detection opportunity، Risk mix، reporting و denominator آنها را جابهجا میکند. افراد یا تیمها را با این اعداد رتبهبندی نکنید.
AI در Early feedback: تولید candidate، نه حقیقت
AI میتواند Example، Counterexample، question، test skeleton، contract diff یا missing-field پیشنهاد دهد. Source/version، prompt/template، model/version، input classification، output digest و reviewer را ثبت کنید. مدل نباید Requirement را اختراع، PII/Secret را دریافت، Acceptance/Quality/Release را تأیید یا Evidence ساختگی تولید کند. اصلاح انسانی باید قابلردیابی باشد.
Remote/Async و دسترسیپذیری
- Question/Source/decision deadline را پیش از Workshop بدهید.
- ورودی text، keyboard، caption و زمان فکر مستقل فراهم کنید.
- تختهٔ رنگی را با Outline/Table و label متنی همراه کنید.
- غیبت perspective را Unknown نگه دارید، نه consent.
- Decision و Correction را از chat خصوصی به Registry منتقل کنید.
- Source/Prototype/Log حساس را به ابزار بیرونی مجازنشده نفرستید.
۲۸ ضدالگوی Shift-left برای تستر
- تست سنتی همیشه منسوخ/بد
- Shift-left انقلاب یا ضرورت جهانی
- ۱۰۰× هزینهٔ Defect بدون Context
- حضور تستر در همهٔ جلسهها
- تستر بهعنوان Coach/Architect/Champion
- QA مالک کیفیت
- QA صاحب Release
- Developer فقط Code/Unit
- Product فقط Requirement
- سؤال «کار میکند؟»
- Source stale
- Approval برابر Evidence
- Coverage برابر Security/Quality
- Average برابر Performance
- Prototype opinion برابر رضایت
- چپترین نقطه به هر هزینه
- همهٔ Testها روی هر Commit
- Automation برابر Shift-left
- UI automation محور اصلی
- حذف Exploration
- حذف UAT/System/Independent checks
- نبود Production feedback
- Fake برابر dependency واقعی
- Static pass برابر runtime pass
- Early PASS بدون limitation
- کار Early پنهان از Plan
- مهارت با Tool count
- وعدهٔ cost/quality/speed guarantee
Pilot سیروزهٔ Quality Interface
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | Goal/Basis/Risk/feedback delay | Baseline |
| روز ۴–۷ | سه Quality Question | bounded/traceable |
| روز ۸–۱۰ | earliest economics/Artifact/Owner | QI contracts |
| روز ۱۱–۱۸ | Evidence/Unknown/Disposition | reviewable records |
| روز ۱۹–۲۴ | later counterchecks | ladder links |
| روز ۲۵–۲۷ | feedback age/guardrail | hypothesis review |
| روز ۲۸–۳۰ | adopt/adapt/stop | learning/correction |
Pilot موفق یعنی سه سؤال زودتر به Evidence محدود و Countercheck وصل شدهاند؛ نه اینکه Defect، هزینه یا زمان حتماً کم شده باشد. اگر Workshop یا Automation صف تازه میسازد، scope را کم یا روش را Adapt کنید.
چکلیست Audit نقش تستر در Shift-left
- Initiative/Goal/Basis/Architecture/DoD/Risk/Pipeline/Cutoff جاریاند.
- هر Interface ID یکتا و Risk/Source معتبر دارد.
- Question Subject/Condition/Behavior/Oracle/forbidden inference دارد.
- earliest point با economics و fidelity توجیه شده است.
- Artifact نسخهدار و Owner capability-based است.
- Feedback due و destination روشن است.
- Evidence Subject/source/method/result/limitation/unknown دارد.
- Approval، Coverage، Average و opinion بیشادعا نشدهاند.
- Countercheck دیرتر برای هر partial evidence وجود دارد.
- System/Exploration/UAT/independence/runtime برحسب Risk حفظاند.
- Whole-team به ownership مبهم یا QA gate تبدیل نشده است.
- Release/Risk/Product/technical decision rights جدا هستند.
- کار Early در Plan/DoD/Backlog قابلمشاهده است.
- Automation trigger از Risk و feedback budget میآید.
- Evidence registry، Correction، Exception و expiry وجود دارد.
- Metrics baseline/measure/guardrail و منع رتبهبندی دارند.
- AI/Async/Accessibility/Privacy controls روشناند.
- نتیجه cost/time/defect/quality/success guarantee نمیسازد.
پرسشهای متداول
Shift-left یعنی تستر باید از روز اول در همهٔ جلسهها باشد؟
خیر. مشارکت را بر اساس Risk، سؤال و capability انتخاب کنید. گاهی Workshop یا Pair لازم است؛ گاهی review Async یا Artifact self-service کافی است. حضور بدون خروجی میتواند bottleneck بسازد. Quality Interface باید Source، سؤال، Artifact، Evidence و موعد را روشن کند.
آیا Shift-left تستهای System، UAT یا Production را حذف میکند؟
خیر. منبع رسمی ISTQB نیز صریحاً میگوید تست دیرتر نباید نادیده گرفته شود. Early model/fake/component محدودیت دارد؛ integration، system، exploratory، independent، UAT و runtime evidence برحسب Risk لازم میمانند. هر Early claim باید Countercheck و forbidden inference داشته باشد.
آیا نقش تستر به مربی یا معمار کیفیت تبدیل میشود؟
ممکن است فرد در Context خاص coaching یا architecture contribution داشته باشد، اما Shift-left چنین عنوان یا authorityای ایجاد نمیکند. نقش را با capability و Decision right تعریف کنید. تستر میتواند questioning/modeling/evidence/testability را عمیق کند، بدون مالکیت انحصاری کیفیت یا Release.
آیا Code Coverage بالا نشانهٔ موفقیت Shift-left است؟
بهتنهایی نه. Coverage میگوید چه چیزی طبق تعریف ابزار اجرا یا پوشش داده شده، نه قدرت Oracle، Risk adequacy، behavior درست یا نبود Defect. آن را با Population/tool/exclusions و Risk/Evidence obligations تفسیر کنید و Countercheckهای integration/system/exploration را حذف نکنید.
چگونه بفهمیم Feedback را بیش از حد به چپ بردهایم؟
وقتی Artifact کافی نیست، false confidence زیاد است، نگهداری/صف از ارزش Signal بیشتر است، سؤال فقط در Context دیرتر معنا دارد یا حضور متخصص گلوگاه میسازد. feedback age را همراه weak-evidence، queue، escaped unknown و later mismatch بسنجید؛ سپس نقطه یا Control را Adapt کنید.
جمعبندی: نقش تستر، ساختن Interface یادگیری است
Shift-left مؤثر با ترفیع تستر به قهرمان کیفیت یا انتقال همهٔ Testها به Commit ساخته نمیشود. Baseline جاری را قفل کنید؛ Risk را به سؤال محدود وصل کنید؛ earliest economical feedback point را با Artifact و Owner انتخاب کنید؛ Evidence و Unknown را نگه دارید؛ کار را در Plan مرئی کنید؛ و هر Early claim را با Countercheck دیرتر و Production learning ببندید. این Interface میتواند Feedback را قابلاقدامتر کند، اما جلوگیری از Defect، کاهش هزینه، افزایش سرعت یا کیفیت محصول را تضمین نمیکند.
