داشبورد میگوید ۱۰۰ تستکیس داریم، ۹۵ مورد اجرا شده، ۲۰ باگ یافتهایم و اتوماسیون به ۸۰٪ رسیده است. بااینحال سه Build در یک محیط مشترک جابهجا میشوند، ۴۱ درخواست تست همزمان باز است، ۱۲ مورد بیش از موعد مانده، «Ready for Test» تعریف واحدی ندارد و هیچکس نمیتواند بگوید نتیجهٔ Pass به کدام Artifact مربوط است. این وضعیت با خرید ابزار یا نوشتن Test Case بیشتر کنترل نمیشود.
این راهنما یک Test Process Recovery Loop میسازد: Contain → Snapshot Actual Flow → Identify Demand/Decision → Define Workflow → Stabilize Intake/Identity → Control WIP/Blockers → Restore Minimum Evidence → Diagnose Constraint → Pilot One Change → Verify/Adapt/Correct. هدف ساختن فرایند «کامل» یا گرفتن نمرهٔ بلوغ نیست؛ هدف بازگرداندن قابلیت دیدن، انتخاب، تمامکردن و یادگرفتن در یک جریان محدود است.
پاسخ کوتاه: فرایند تست آشفته را از کجا سامان دهیم؟
در ۷۲ ساعت اول، تغییرهای غیرضروری فرایند و ورود کارِ بیهویت را متوقف کنید، کارهای باز را با Product/Change/Build/Environment/Decision شناسایی کنید و خطرهای فوری را به مسیر Incident یا Release ببرید. سپس Workflow واقعی را—نه چیزی که در سند نوشته شده—با صفها، بازگشتها و Blockerها رسم کنید. برای یک جریان Pilot، Intake و State/entry/exit را تعریف، WIP را کنترل، Work Item Age را روزانه مرور و حداقل Evidence لازم را برقرار کنید. فقط یک Constraint را با فرضیه، Baseline، Guardrail و Rollback تغییر دهید و نتیجه را Adopt، Adapt یا Stop کنید.
- Contain: جلوگیری از افزایش آسیب و ابهام، بدون بازطراحی عجولانهٔ کل سازمان.
- Actual Flow: مسیر واقعی کار، انتظار، برگشت و تصمیم؛ نه نمودار مطلوب.
- Flow Item: واحد قابلردیابیِ تقاضای تست با شناسه و Decision need.
- Minimum Control: هویت، ورودی، State، WIP، Blocker، Evidence و Authority کافی برای Pilot.
- Stabilized: جریان قابلمشاهده و تصمیمپذیر شده؛ نه اینکه محصول بینقص یا فرایند بالغ است.
«هرجومرج» را به نشانههای قابلبررسی تبدیل کنید
واژههایی مثل آشفته، نابالغ، تنبل یا بینظم تشخیص نیستند و بهسادگی به برچسب افراد تبدیل میشوند. نشانه را عملیاتی کنید: چند Flow item هویت Build ندارد؟ چند مورد بیش از SLE سن دارد؟ چه درصدی به دلیل Environment برگشته؟ چند Decision بدون Evidence مانده؟ چه مقدار کار از کانال خارج وارد میشود؟ اگر مخرج، بازه و منبع ندارید، فعلاً Observation کیفی بنویسید، نه درصد.
آشفتگی، Incident و بلوغ را جدا کنید
| مسئله | سؤال اصلی | مسیر مناسب |
|---|---|---|
| Incident فعال | چگونه اثر را مهار و خدمت را بازیابی کنیم؟ | Incident command؛ Recovery تست تابع آن است |
| Release با Risk نامعلوم | آیا Evidence برای تصمیم مشخص کافی است؟ | Release decision/exception |
| جریان تست بیثبات | چگونه intake، WIP، Evidence و Decision را قابل مشاهده کنیم؟ | Recovery loop همین مقاله |
| بهبود بلوغ سازمانی | قابلیتها در چند حوزه و سطح چگونهاند؟ | ارزیابی و بهبود TMMi |
| ساختار/Operating model | خدمت، ظرفیت و مسئولیت میان تیمها چگونه طراحی شود؟ | مدل عملیاتی QA |
کنترل به معنی بوروکراسی یا تمرکز نیست
کنترل یعنی وضعیت و قواعد تصمیم قابل مشاهدهاند، انحراف آشکار میشود و نقش صاحب اختیار میتواند عمل اصلاحی انجام دهد. تیم میتواند خودگردان، Context-driven و سبک باشد و درعینحال هویت Build، WIP، Evidence و Exception روشن داشته باشد. فرم طولانی، Gate مرکزی و امضای بیشتر ممکن است Queue را بدتر کنند بدون اینکه Risk را کاهش دهند.
اصل اول: اکنون چه چیزی باید مهار شود؟
Recovery را با Workshop چشمانداز شروع نکنید. ابتدا Harm فعال، Release نزدیک، دادهٔ حساس، محیط آلوده، Build ناشناس، یافتهٔ بحرانی بیمالک و Queueهای پنهان را شناسایی کنید. اقدام Containment میتواند Pause یک Release، جداکردن Environment، بستن ورودی غیررسمی، حفظ Evidence یا محدودکردن Scope باشد. این تصمیم باید مالک، دلیل، بازبینی و Exit داشته باشد تا Freeze دائمی نشود.
containment_id: TPR-CONT-042 as_of: 2026-08-13T09:00:00+03:30 scope: checkout-release-train trigger: build_identity_conflict_and_unbounded_test_queue actions: - pause production recommendation for unknown-build results - reject new requests without change/build/decision identity - preserve current run and environment evidence owner_role: test-flow-recovery-owner exceptions: emergency_security_fix_via_incident_authority review_at: 2026-08-14T09:00:00+03:30 exit: all active items identified_or_dispositioned
Recovery Charter دامنه را کوچک نگه میدارد
Charter باید جریان Pilot، مسئلهٔ مشاهدهشده، Decision، زمانبندی، اختیار، موارد خارج از دامنه و شرط توقف را ثبت کند. «تحول کل QA» Scope نیست. نمونه: «در ۳۰ روز، جریان درخواست تا Evidence برای Release train پرداخت را قابلردیابی کنیم و Work itemهای بیهویت را به صفر برسانیم؛ تغییر ساختار سازمان، خرید ابزار و خودکارسازی کل Regression خارج از Scope است.»
Actual Flow را از رویداد بسازید، نه از حافظه
از Ticket، chat، CI، Test run، deploy، Environment booking و Decision receipt نمونه بگیرید. هر State change باید timestamp، actor role، source و item ID داشته باشد. مصاحبه برای فهم Context ارزش دارد، اما «معمولاً اینطور است» را با Event log یکی نکنید. اختلاف میان Intended و Actual workflow خودش یک Finding است.
| مرحلهٔ مشاهدهشده | ورودی واقعی | خروجی واقعی | Queue/بازگشت |
|---|---|---|---|
| Request | Jira، chat، جلسه، پیام خصوصی | Ticket یا قول شفاهی | ورودی خارج کانال نامعلوم |
| Clarify | Change بدون Decision/Build | پرسش یا حدس تستر | انتظار محصول |
| Prepare | Test basis/data/env | Run-ready یا blocked | بازگشت محیط/داده |
| Execute | Build و Testware | Result/Observation | بازاجرای ناشی از Build drift |
| Investigate | Anomaly | Finding/invalid | انتظار log/developer |
| Decide | Evidence packet | recommendation/decision | انتظار Authority |
یک Flow Item چه چیزی است؟
«تست» واحد قابلاندازهگیری نیست. Flow item میتواند درخواست Evidence برای یک Change/Decision باشد، نه هر Test case یا Bug. Granularity را ثابت و Policy split/merge را ثبت کنید؛ در غیر این صورت Throughput با خردکردن Ticket افزایش مییابد. Test case، Run، Finding و Decision به Flow item متصلاند ولی الزاماً خودِ item نیستند.
flow_item_id: TFI-042 item_type: release_evidence_request product: marketplace-synthetic change_id: CH-IRR-042 artifact: build-b401 environment: stg-tehran-fixture-v7 decision_need: rollout_5_percent_or_hold risk_refs: [incorrect_total, duplicate_callback] requested_at: 2026-08-13T09:15:00+03:30 requester_role: product-owner service_class: fixed_date due_at: 2026-08-15T12:00:00+03:30 current_state: READY evidence_profile: EP-IRR-042-v2 owner_role: cross_functional_checkout_team
Demand را پیش از طراحی ظرفیت بشناسید
| Demand type | نمونه | Policy متفاوت |
|---|---|---|
| Planned change | Evidence برای Feature/Release | Risk-based scheduling |
| Failure demand | بازکاری ناشی از ورودی/محیط/Build غلط | علت بازگشت و حذف تکرار |
| Incident/emergency | تأیید Hotfix یا recovery | expedite محدود با Authority |
| Compliance/domain | Evidence الزام قابلاعمال | متخصص/Retention/approval |
| Maintenance | رفع Flaky، داده یا Testware | ظرفیت محافظتشده |
| Learning | Probe/experiment برای Unknown | Timebox و not-claimed |
اگر Failure demand را با Feature demand مخلوط کنید، تیم ظاهراً پرکار اما گرفتار بازکاری است. Arrival rate، source، class و invalid/duplicate را ثبت کنید؛ کاهش ورودی نامعتبر گاهی از افزایش Runner مؤثرتر است.
Intake Contract جلوی کار بیهویت را میگیرد
| فیلد حداقلی | چرا | اگر نامعلوم است |
|---|---|---|
| Product/Change/Artifact | اتصال Result به Subject | INTAKE_HOLD |
| Decision need و due | انتخاب Evidence/اولویت | برگشت برای Clarify |
| Risk/claim | تخصیص تست | Discovery timebox |
| Environment/data | Fidelity و Privacy | Dependency ثبت شود |
| Requester/owner roles | پاسخ و تصمیم | بدون مالک، شروع نشود |
| Service class | Queue policy | Standard پیشفرضِ مصوب |
Intake باید سبک، قابلاتوماسیون و دارای مسیر اضطراری باشد. «فرم کامل نشده» نباید مانع Incident واقعی شود؛ Emergency path باید Authority، ثبت پسینی و Review داشته باشد. فیلدهایی که هیچ تصمیمی را تغییر نمیدهند حذف کنید.
Definition of Workflow را صریح کنید
راهنمای رسمی Kanban Guide 2025 بر تعریف و مشاهدهٔ Workflow، مدیریت فعال itemها و بهبود Flow تأکید میکند. این مقاله از آن برای Recovery جریان تست استفاده میکند، نه اینکه هر تیم را ملزم به «Kanban transformation» بداند. Definition باید Flow item، start/finish، Stateها، کنترل WIP، Policy انتخاب، Service Level Expectation و Flow metrics را در Context شما روشن کند.
State فقط نام ستون نیست
| State | Entry | Exit | مالک عمل |
|---|---|---|---|
| INTAKE_HOLD | هویت/Decision ناقص | حداقل Contract یا disposition | requester + flow steward |
| READY | Evidence profile و dependencies معتبر | capacity pull | delivery team |
| ACTIVE | Artifact/env رزرو و کار شروع | evidence produced یا BLOCKED | item owner |
| BLOCKED | مانع خارجی با owner | مانع رفع و Evidence تازه | blocker owner |
| REVIEW | packet حداقلی موجود | finding resolved یا recommendation | reviewer role |
| DECISION_WAIT | recommendation تحویل شده | decision receipt | decision authority |
| DONE | Decision/evidence/remaining risk ثبت | — | flow steward verifies |
Blocked نباید فقط برچسب باشد؛ cause class، owner، since، next action و review time میخواهد. Waiting را پنهانکردن داخل Active، Cycle time و Constraint را تحریف میکند.
فعالیتهای تست را خط تولید اجباری نکنید
نسخهٔ رسمی ISTQB CTFL v4.0.1 Planning، Monitoring/Control، Analysis، Design، Implementation، Execution و Completion را توضیح میدهد و تصریح میکند اجرا به Context وابسته و فعالیتها اغلب iterative هستند. این واژگان برای دیدن Gap مفیدند؛ لازم نیست هر Flow item هفت Gate ترتیبی یا هفت سند جدا داشته باشد.
شروع و پایان Flow را ثابت کنید
Lead time از درخواست تا Decision با Cycle time از Pull به Active تا Decision فرق دارد. اگر نقطهٔ شروع با بهترشدن اعداد جابهجا شود، مقایسه بیمعناست. Discovery و Intake hold را حذف نکنید؛ جدا گزارش کنید. Finish را «اجرای Test» نگذارید اگر تصمیم هنوز در Queue است.
WIP را کنترل کنید، نه اینکه فقط بشمارید
WIP یعنی کار شروعشده اما تمامنشده. Limit باید Scope، Stateها، استثنا، واکنش هنگام رسیدن به سقف و Authority تغییر داشته باشد. وقتی سقف پر است، Pull تازه متوقف و ظرفیت روی پایاندادن، رفع Blocker یا همکاری میرود. عبور موقت ممکن است، اما reason/expiry/review لازم دارد؛ وگرنه Limit تزئینی است.
wip_policy_id: WIP-CHECKOUT-v1
scope: [ACTIVE, REVIEW]
limit: 6
counting_unit: release_evidence_request
split_merge_policy: preserve_parent_and_reason
when_full:
- no_standard_pull
- swarm_oldest_or_blocked
exceptions:
- class: expedite
authority_role: incident_commander
max_concurrent: 1
expires_in: 24h
review_cadence: weekly
change_requires: baseline_and_hypothesis
Expedite lane را به Queue عادی تبدیل نکنید
اگر هر Stakeholder کار خود را Critical بنامد، Queue رسمی بیاعتبار میشود. Expedite باید trigger، authority، WIP جدا/محدود، displaced item، expiry و post-review داشته باشد. هزینهٔ جابهجایی و Itemهای عقبافتاده را آشکار کنید. Severity و Priority را با قرارداد تریاژ نقص جدا تصمیم دهید.
Work Item Age سیگنال روزانهٔ Recovery است
Age زمان گذشته از شروع Item باز است. آن را با SLE و percentile تاریخی مقایسه کنید و پیرترین مورد را بپرسید: چه چیزی مانع جریان است؟ Age پیشبینی قطعی زمان پایان یا نمرهٔ فرد نیست. Item class، اندازه، rework و blocked time روی مقایسه اثر دارند.
Flow Metrics را با تعریف و Countermetric بخوانید
| Metric | تعریف نمونه | Countermetric/محدودیت |
|---|---|---|
| WIP | itemهای Started-not-Finished در cutoff | Scope و hidden work |
| Throughput | itemهای Finished در Window | split/gaming و Outcome |
| Cycle time | Start تا Finish برای Finished items | Open-item survivorship و percentile |
| Work item age | Start تا اکنون برای Open items | class/blocked/size |
| SLE | پیشبینی service برای درصدی از items | Forecast، نه SLA/ضمانت |
| Blocked time | مدت Stateهای Blocked با cause | پنهانکردن انتظار در Active |
| Rework loop | بازگشت به State قبل / itemهای eligible | اصلاح مفید در برابر failure demand |
سنجههای حداقلی Kanban برای Flow هستند؛ سلامت محصول، کفایت تست یا رضایت تیم را ثابت نمیکنند. Metricهای تست و KPI ضدبازی باید قرارداد، Countermetric و کنترل کیفیت دادهٔ جدا داشته باشند.
SLE را از دادهٔ مشابه بسازید
Service Level Expectation یک Forecast احتمالی است: مثلاً «۸۵٪ Flow itemهای Standard مشابه در ۹ روز یا کمتر تمام شدهاند». Start/Finish، Window، sample، item class و percentile باید مشخص باشند. SLE را وعدهٔ قطعی، SLA قراردادی یا Target فردی معرفی نکنید؛ تغییر Workflow یا mix، Freshness آن را از بین میبرد.
Baseline را پیش از مداخله Freeze کنید
baseline_id: FLOW-BL-042-v1 workflow_version: DOW-CHECKOUT-v1 window: 2026-07-01/2026-07-28 timezone: Asia/Tehran population: standard_release_evidence_requests start_event: ACTIVE_ENTERED finish_event: DECISION_RECORDED included: 28 open_at_cutoff: 11 invalid: 4 metrics: throughput: 17 cycle_time_p50_days: 7 cycle_time_p85_days: 16 oldest_open_age_days: 22 blocked_item_count: 9 limitations: [chat_intake_before_july_incomplete] source_manifest: EM-FLOW-042-v1
Finished-only Cycle time میتواند Openهای پیر را حذف کند؛ پس Age و Open count را کنار آن بگذارید. دادهٔ قدیمی ناقص را تخمین بیبرچسب نزنید. Baseline ابزار قضاوت افراد نیست؛ مبنای آزمون تغییر سیستم است.
Constraint را با Queue evidence پیدا کنید
بیشترین زمان یا موجودی لزوماً «تیم کند» نیست. Arrival/departure، Queue، blocked causes، rework paths، batching و dependency را ببینید. اگر Environment booking ۴۰٪ blocked time را میسازد، افزودن Test case یا فشار بر Execution Constraint را حل نمیکند. Constraint میتواند Policy، Decision authority، data access، Build stability یا handoff باشد.
Root cause واحد برای Process chaos نسازید
جریان بیثبات معمولاً حاصل تعامل Demand، WIP، هویت، dependency، incentive و capacity است. فرضیه بسازید: «ورودی خارج کانال Age را زیاد میکند»، «Build drift باعث rework است»، «Decision queue Finish را عقب میاندازد». برای هر فرضیه Evidence موافق، شاهد خلاف و آزمون کوچک بنویسید؛ از اعلام یک Root cause بدون آزمون Alternative خودداری کنید.
Minimum Viable Test Process چیست؟
نسخهٔ حداقلی فرایند، کمترین کنترل لازم برای یک جریان و Decision است: Item identity، Intake، State/entry/exit، WIP، blocker policy، Evidence profile، Finding route، Decision authority و correction. این اصطلاح استاندارد ISTQB یا TMMi نیست؛ یک الگوی عملی این مقاله برای Pilot است. «حداقلی» به معنی حذف Risk control یا دادهٔ ضروری نیست.
Minimum Evidence Profile را به Decision وصل کنید
| Decision/Claim | Evidence حداقلی | چیزی که ادعا نمیشود |
|---|---|---|
| Build قابل تشخیص است | artifact digest + deploy/config identity | کیفیت Build |
| مبلغ IRR برای Scope درست است | contract/property/boundary + reconciliation | همهٔ Pricing ruleها |
| Dependency failure مهار میشود | timeout/retry/fallback witness | تابآوری کل سامانه |
| Finding disposition شده | decision/owner/expiry/retest | Release permission |
| Rollout محدود قابل بازگشت است | cohort + stop + rollback rehearsal | Scale readiness |
برنامهٔ تست زنده و Risk-to-Evidence را میتوانید با قالب Living Test Plan بسازید. در Recovery، Template را تا حدی نگه دارید که تصمیم را بهبود دهد.
Evidence identity را پیش از Test volume اصلاح کنید
صد Run بدون Build/Environment/Data/Oracle identity ممکن است بیمصرف باشند. Result باید Testware revision، Artifact، config، environment، data set، time، executor، verdict semantics و evidence locator داشته باشد. Pass قدیمی پس از تغییر Subject Fresh نیست. از Screenshot بدون locator یا «روی Staging تست شد» بهعنوان هویت کافی استفاده نکنید.
Finding route را ساده و بسته طراحی کنید
Observation، Anomaly، Finding، Defect، Environment issue و Change request را یکی نکنید. هر Finding باید subject/build، evidence، severity rationale، owner، disposition، due، retest و closure/correction داشته باشد. گزارش خوب بدون مسیر تصمیم، Queue دیگری میسازد. مدیریت کامل چرخه در راهنمای مدیریت نقص آمده است.
گزارش روزانه باید Request تصمیم داشته باشد
بهجای «۹۵٪ تست شد»، Facts-as-of، WIP/Age، Blocker، Evidence produced، Unknown، Forecast و درخواست تصمیم را بنویسید. اگر Environment owner تا ساعت معین عمل نکند چه Escalationی رخ میدهد؟ پروتکل گزارش پیشرفت و مانع برای همین حلقه است.
Standardize semantics before tools
ابتدا معنای Item، State، Ready، Blocked، Done، Severity، Evidence و Decision را مشترک کنید؛ سپس ابزار را طوری پیکربندی کنید که همان Contract را اجرا کند. یک Template واحد برای همهٔ تیمها ممکن است Context را نابود کند. Semantic core ثابت و extensionهای نسخهدار برای جریانهای متفاوت بهتر از Form یکسان است.
ابزار جدید میتواند آشفتگی را دیجیتال کند
قبل از خرید، مسئله، workflow fit، API/export، identity mapping، permission، audit trail، data residency/access، migration، ایران/تحریم، هزینه، vendor lock-in و Exit را بسنجید. Tool نباید Source of truthهای موازی بسازد. Pilot را روی یک Flow و دادهٔ مصنوعی اجرا کنید؛ adoption و outcome را از Login count جدا نگه دارید.
Automation را پس از تثبیت Contract انتخاب کنید
فرایند دستی لازم نیست کامل باشد، اما Subject، Oracle، State و expected use باید قابلفهم باشند. خودکارکردن ورودی مبهم یا Test ناپایدار، Failure را سریعتر تکثیر میکند. گزینهها را بر feedback latency، repetition، risk, determinism، data/env cost، flaky، triage، maintenance و retirement بسنجید؛ درصد اتوماسیون هدف کیفیت نیست.
هرم تست نسخهٔ سازمانی ثابت نیست
Unit معمولاً سریع و محلی است و E2E معمولاً fidelity بیشتری با هزینهٔ بالاتر دارد، اما نوع معماری، Risk و Oracle تعیین میکند چه ترکیبی مناسب است. «بیشترین Unit، کمترین E2E» را بدون Test question و failure mode به quota تبدیل نکنید. راهنمای هرم تست نسبت جادویی را رد و سبد را Evidenceمحور طراحی میکند.
یک Improvement Experiment، نه ده Initiative
experiment_id: TPI-042 problem: 9_of_11_open_items_blocked_by_environment_or_build_drift hypothesis: immutable artifact reservation plus env lease reduces rework loops scope: checkout_release_evidence_requests baseline: FLOW-BL-042-v1 change: - artifact digest required at READY - environment lease bound to item/build duration: 21d primary: rework_loop_rate guardrails: [oldest_item_age, throughput, after_hours_load, invalid_results] stop: - active_incident - invalid_result_rate_increases rollback: allow previous lease workflow and preserve event log decision: ADOPT | ADAPT | STOP owner_role: test-flow-recovery-owner
با همزمانکردن Tool migration، Automation، training، WIP و Template نمیفهمید کدام تغییر چه اثری داشت. یک Constraint را هدف بگیرید؛ اگر شرایط عملی اجازهٔ مقایسهٔ علّی نمیدهد، محدودیت Attribution را صریح نگه دارید.
Pilot باید Unit و Comparison داشته باشد
Population itemها، Window، entry، exposure، exclusion، data delay و stopping را پیشاپیش بنویسید. Before/After میتواند با تغییر Demand mix، Release size یا تیم مخدوش شود. اگر کنترل همزمان ندارید، matched class، run chart و تحلیل حساسیت کمک میکند اما Cause را اثبات نمیکند. نتیجه را برای همان Flow محدود کنید.
Adoption را با استفادهٔ صحیح در فرصت واقعی بسنجید
حضور در آموزش، Login و نصب ابزار Adoption نیست. فرصتهای واقعی را به Correct use، Assisted، Workaround، Abandoned و Invalid تقسیم کنید. اگر Intake contract فقط هنگام Audit پر میشود یا WIP limit دائماً با Override رد میشود، فرایند Adopt نشده است. تغییر رفتار و سامانه را در راهنمای Change Adoption دنبال کنید.
فرهنگ مشترک، مالکیت مبهم نیست
«کیفیت مسئولیت همه است» بدون Decision rights باعث میشود هیچکس مالک Environment، Risk، Finding یا Rollback نباشد. نقشها را روشن کنید و مسئلهٔ سیستم را به نقص شخصیت تبدیل نکنید. فشار بعدازساعت، ترس از گزارش Blocker و تشویق تعداد Test/bug میتواند داده را منحرف کند. طراحی عمیقتر در راهنمای فرهنگ کیفیت آمده است.
Authority Map در Recovery
| نقش | اختیار | محدودیت |
|---|---|---|
| Recovery sponsor | Scope/capacity و رفع مانع سازمانی | تغییر Fact یا Result |
| Flow recovery owner | Containment، Policy و Pilot coordination | Risk acceptance خارج اختیار |
| Cross-functional team | Pull، Evidence و بهبود workflow | تعریف مخفی Priority |
| Product/decision owner | Decision need و Outcome priority | اعلام Evidence فنی |
| Domain risk owner | Risk acceptance در Scope | پذیرش Risk حوزهٔ دیگر |
| Evidence reviewer | کفایت/limitation packet | تضمین کیفیت محصول |
Metricهای Recovery و Countermetricها
| سؤال | Metric | Countermetric |
|---|---|---|
| ورودی قابلفهم شد؟ | valid intake / all arrivals | lead time to clarify و dropped demand |
| کار تمام میشود؟ | throughput و age percentile | Outcome/Evidence quality |
| انتظار کم شد؟ | blocked time by cause | پنهانکردن Blocked در Active |
| بازکاری کم شد؟ | rework loops / eligible items | missed correction و premature close |
| Evidence معتبرتر شد؟ | identity-complete results | finding/correction rate |
| Decision سریعتر شد؟ | evidence-ready تا receipt | risk/unknown at decision |
| تغییر قابلتحمل است؟ | correct independent use | support و after-hours load |
Defect count و Coverage سلامت فرایند نیستند
Bug بیشتر میتواند Detection بهتر، Change پرریسکتر یا taxonomy متفاوت باشد. Defect density به اندازه/واحد حساس است؛ Coverage به Universe و Oracle وابسته؛ MTTD نیازمند زمان ورود واقعی Defect است که اغلب نمیدانیم؛ Escape rate به Detection opportunity و reporting وابسته است. این Metricها فقط با قرارداد و کنار Countermetric معنا دارند.
Success Criteria بازیپذیر نباشد
«کاهش Cycle time ۳۰٪» میتواند با حذف Itemهای سخت، تغییر start یا بستن زودهنگام رخ دهد. Success را چندبعدی کنید: Age/Throughput بهتر، Evidence identity حفظ، rework/invalid/after-hours بالا نرفته و Outcome تصمیم بهتر شده باشد. Rule محاسبه را Freeze و Correction را append-only کنید.
آزمایش تکرارپذیر: ۸۰٪ اتوماسیون اما بدون کنترل
Fixture مصنوعی زیر ۱۰۰ Test case، ۹۵ اجرا، ۲۰ Bug و ۸۰٪ Automation را نشان میدهد و PROCESS_UNDER_CONTROL اعلام میکند. Auditor میسنجد آیا Flow، WIP، Evidence، Constraint، Pilot و Authority واقعاً تعریف شدهاند.
{
"recovery_id": "",
"scope": "",
"as_of": "",
"flow_item_contract": {},
"workflow": {"version": "", "start": "", "finish": "", "states": [], "wip_policy": ""},
"active_items": [
{"id": "T1", "change": "", "artifact": "", "environment": "", "state": "ACTIVE", "started_at": "", "evidence_profile": ""}
],
"blocked_policy": {"owner_required": false, "review_time_required": false},
"baseline": {"window": "", "population": "", "source": ""},
"constraint_hypothesis": {"statement": "", "evidence": [], "disconfirming_test": ""},
"experiment": {"id": "", "change": "", "primary": "", "guardrails": [], "stop": [], "rollback": ""},
"authorities": {"flow_owner": "", "decision_owner": "", "risk_owner": ""},
"dashboard": {"test_cases": 100, "executed": 95, "bugs": 20, "automation_percent": 80},
"declared": "PROCESS_UNDER_CONTROL"
}
const fs = require('node:fs');
const x = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const f = [];
const need = (ok, rule, path) => { if (!ok) f.push({ rule, path }); };
need(x.recovery_id, 'IDENTITY', 'recovery_id');
need(x.scope && x.as_of, 'SCOPE_SNAPSHOT', 'scope/as_of');
need(Object.keys(x.flow_item_contract || {}).length, 'FLOW_ITEM', 'flow_item_contract');
for (const key of ['version', 'start', 'finish', 'wip_policy'])
need(x.workflow?.[key], 'WORKFLOW', `workflow.${key}`);
need((x.workflow?.states || []).length, 'WORKFLOW_STATES', 'workflow.states');
for (const [i, item] of (x.active_items || []).entries()) {
for (const key of ['change', 'artifact', 'environment', 'started_at', 'evidence_profile'])
need(item[key], 'ITEM_IDENTITY', `active_items[${i}].${key}`);
}
need(x.blocked_policy?.owner_required, 'BLOCKER_POLICY', 'blocked_policy.owner_required');
need(x.blocked_policy?.review_time_required, 'BLOCKER_POLICY', 'blocked_policy.review_time_required');
for (const key of ['window', 'population', 'source'])
need(x.baseline?.[key], 'BASELINE', `baseline.${key}`);
need(x.constraint_hypothesis?.statement, 'HYPOTHESIS', 'constraint_hypothesis.statement');
need((x.constraint_hypothesis?.evidence || []).length, 'HYPOTHESIS', 'constraint_hypothesis.evidence');
need(x.constraint_hypothesis?.disconfirming_test, 'HYPOTHESIS', 'constraint_hypothesis.disconfirming_test');
for (const key of ['id', 'change', 'primary', 'rollback'])
need(x.experiment?.[key], 'EXPERIMENT', `experiment.${key}`);
need((x.experiment?.guardrails || []).length, 'EXPERIMENT', 'experiment.guardrails');
need((x.experiment?.stop || []).length, 'EXPERIMENT', 'experiment.stop');
for (const key of ['flow_owner', 'decision_owner', 'risk_owner'])
need(x.authorities?.[key], 'AUTHORITY', `authorities.${key}`);
const computed = f.length ? 'HOLD' : 'READY_FOR_PROCESS_RECOVERY_REVIEW';
if (x.declared !== computed) f.push({ rule: 'DECISION_MISMATCH', path: 'declared' });
console.log(JSON.stringify({ computed, count: f.length, findings: f }, null, 2));
process.exitCode = f.length ? 2 : 0;
نسخهٔ ناقص باید HOLD و ۳۱ Finding بدهد: Recovery identity، Scope/Snapshot، Flow contract، پنج Workflow gap، پنج Item identity gap، دو Blocker policy، سه Baseline، سه Hypothesis، شش Experiment، سه Authority و Decision mismatch. اعداد ۱۰۰/۹۵/۲۰/۸۰ حذف نمیشوند؛ فقط برای اعلام Control کافی نیستند.
پس از ثبت Recovery ID/Scope/as-of، قرارداد Flow item، Workflow/State/WIP، هویت کامل T1، Blocker policy، Baseline، فرضیهٔ Environment/Build drift، Experiment دارای Guardrail/Stop/Rollback و سه Authority، اجرای دوباره باید count=۰ و READY_FOR_PROCESS_RECOVERY_REVIEW بدهد. این نتیجه فقط ساختار Packet را بررسی میکند؛ صحت داده، Constraint واقعی، کفایت Evidence، بلوغ، کیفیت محصول یا موفقیت تحول را اثبات نمیکند.
آزمایشگاه فارسی و آفلاین Recovery
یک Lab بدون شبکه بسازید: ۴۱ درخواست ساختگی برای Checkout بازارگاه، سه Build، دو Environment و رخدادهای JSON. عمداً Request تکراری، Artifact گمشده، زمان UTC و Asia/Tehran، عدد فارسی/عربی/لاتین، ی/ی و ک/ک، مبلغ canonical IRR و نمایش تومانِ labelدار، callback دیر/تکراری و Decision بدون Evidence تزریق کنید. Parser باید identity gap، duplicate، age، blocked cause و stale result را گزارش کند.
تمام Tenant/Order/Change/Build/Run/Eventها مصنوعیاند. Lab نباید شبکه، Production، شرکت یا کاربر واقعی، PSP/بانک، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، log یا Screenshot واقعی داشته باشد و هیچ ادعای حقوقی، مالی، بانکی، امنیتی یا آماری دربارهٔ ایران نسازد.
AI در Recovery چه کار کند و چه کار نکند؟
AI میتواند Eventها را برای Flow-map پیشنهاد، Ticketهای احتمالاً Duplicate، missing identity، aging risk و recurring blocker را علامت و خلاصهٔ Evidence candidate بسازد. نباید Event گمشده جعل کند، فرد را علت chaos اعلام کند، Priority/Risk/Release را خودمختار تصمیم دهد یا محتوای محرمانه را به سرویس بدون قرارداد بفرستد. خروجی باید source locator، confidence، model/version و reviewer داشته باشد.
ضدالگوهای بازسازی فرایند تست
| ضدالگو | پیامد | اصلاح |
|---|---|---|
| Big-bang transformation | چند متغیر و اختلال زیاد | یک Flow/Constraint/Pilot |
| Tool first | دیجیتالشدن ابهام | Semantic/Workflow contract |
| Automate chaos | Failure سریعتر و Flaky queue | Identity/Oracle/use first |
| Template یکسان برای همه | کار تشریفاتی و bypass | Core + contextual extension |
| WIP limit بدون واکنش | عدد تزئینی | pull/exception/review policy |
| همهچیز Critical | Queue و trust فرومیریزد | service class/authority |
| Coverage/bugs=health | Goodhart و ادعای بیمخرج | Flow + Evidence + Outcome |
| فرهنگ مقصر است | پنهانشدن شرایط سیستم | behavior/context/incentive evidence |
| Done=tests executed | Decision queue پنهان | Finish at receipt/closure |
| Training=adoption | استفادهٔ واقعی نامعلوم | opportunity/correct-use evidence |
برنامهٔ ۷۲ ساعت نخست
| بازه | کار | خروجی |
|---|---|---|
| ۰–۴ ساعت | Harm/Release/Incident triage و Recovery owner | Containment record |
| ۴–۱۲ ساعت | Inventory item/build/env/decision/evidence | Active-item register |
| ۱۲–۲۴ ساعت | Disposition orphan/duplicate/unknown | Keep/Hold/Cancel/Clarify |
| روز دوم | رسم Actual flow و Queue/blocked | Flow snapshot + unknowns |
| روز سوم | Intake/State/WIP/minimum evidence Pilot | DoW v1 و daily review |
برنامهٔ ۳۰روزهٔ تثبیت
| بازه | کار | Decision |
|---|---|---|
| روز ۱–۳ | Contain، inventory و Actual flow | Scope/authority confirmed |
| روز ۴–۷ | DoW/Intake/WIP/Blocker/Evidence v1 | Pilot start یا revise |
| روز ۸–۱۲ | Baseline و oldest-item swarming | Constraint hypothesis |
| روز ۱۳–۲۱ | یک Improvement experiment | continue/stop per guardrail |
| روز ۲۲–۲۶ | Adoption/Outcome/Countermetric review | ADOPT/ADAPT/STOP |
| روز ۲۷–۳۰ | Correction، extension و next backlog | Stabilized/continue recovery |
چه زمانی از Recovery به بلوغ برویم؟
وقتی یک یا چند Flow حداقل چند Window با هویت، Workflow، WIP، Evidence و Decision قابل مشاهدهاند و آتش فعال مدیریت شده، میتوانید Assessment گستردهتر را آغاز کنید. TMMi Foundation مدل مرحلهای رسمی برای Test process improvement ارائه میکند؛ صفحهٔ مدل TMMi Scope آن را توضیح میدهد. Stabilized بودن Pilot به معنی سطح TMMi، Certification یا بلوغ سازمان نیست.
شرط خروج از Recovery
| Claim | Evidence | تصمیم مجاز |
|---|---|---|
| Active work identified | همه itemها identity یا disposition دارند | Containment relax |
| Flow visible | State events و age برای Pilot کاملاند | Baseline valid with limits |
| WIP governed | override/expedite tracked و reviewed | Policy adopt/adapt |
| Evidence usable | Resultهای decision-critical identity-complete | Recommendation allowed |
| Improvement tested | Outcome/guardrail/limitation reviewed | ADOPT/ADAPT/STOP |
| Ownership sustained | cadence/capacity/owners confirmed | STABILIZED یا ادامه Recovery |
STABILIZED یعنی آشفتگی برای Scope تعریفشده قابل مشاهده و مدیریت شده است. این Result کیفیت محصول، نبود Defect، رضایت مشتری، سلامت فرهنگ یا موفقیت کسبوکار را تضمین نمیکند. Unknown و Risk باقیمانده باید همراه Result باشند.
چکلیست Recovery Owner
- Incident/Harm فعال از بهبود فرایند جدا و مهار شده است.
- Recovery charter یک Flow، زمان، Authority و out-of-scope دارد.
- Actual flow از Event و نمونه ساخته شده، نه فقط Workshop.
- Flow item و split/merge policy تعریف شدهاند.
- Demand type، Arrival channel و failure demand قابل مشاهدهاند.
- Intake حداقل Product/Change/Build/Decision/Risk/Owner دارد.
- Stateها entry/exit/owner و Waiting/Blocked صریح دارند.
- Start/Finish و Flow metrics نسخهدارند.
- WIP limit واکنش، exception، expiry و review دارد.
- پیرترین Item و Blocker هر روز بازبینی میشود.
- Evidence به Artifact/Environment/Data/Testware/Time وصل است.
- Finding تا disposition/retest/closure مسیر دارد.
- Constraint فرضیه و آزمون خلاف دارد.
- فقط یک Improvement experiment با Guardrail/Stop اجرا میشود.
- Adoption با فرصت واقعی و Correct use سنجیده میشود.
- Result، limitation، correction و next decision ثبت میشوند.
جمعبندی
فرایند تست آشفته با سند جامع، ابزار مشهور یا Automation percentage درمان نمیشود. ابتدا کار فعال را مهار و شناسایی کنید؛ سپس جریان واقعی، Demand، Queue، WIP، Blocker، Evidence و Authority را در یک Scope کوچک قابل مشاهده سازید. Constraint را از داده حدس بزنید، یک تغییر را Pilot و با Outcome و Guardrail بررسی کنید. کنترل پایدار نتیجهٔ حلقهٔ مشاهده و اصلاح است، نه انباشت Template و Gate.
سؤالات متداول بهبود فرایند تست
اولین اقدام در فرایند تست کاملاً آشفته چیست؟
Harm و Release فوری را Triage کنید، Recovery owner تعیین و Active work را با Change/Build/Environment/Decision شناسایی کنید. پیش از Tool یا Strategy جامع، جلوی ورود کار بیهویت و استفاده از Result ناشناس را بگیرید.
آیا باید ابتدا همهٔ تستکیسها را استاندارد کنیم؟
خیر. ابتدا Semantic core، Flow و Evidence لازم برای Decision Pilot را ثابت کنید. بعضی سؤالها Case تفصیلی، بعضی Charter، Property یا Checklist میخواهند. Standardization سراسری میتواند کار بیارزش بسازد.
چه زمانی ابزار مدیریت تست بخریم؟
پس از اینکه مسئله، Workflow، identity، integration، access/export/exit و Success criteria روشن شد. یک Pilot محدود نشان دهد ابزار Queue یا Evidence را بهتر میکند، نه اینکه فقط Login و فرم بیشتری ساخته است.
آیا WIP کمتر همیشه Throughput را بیشتر میکند؟
خیر. WIP control برای تمرکز و آشکارکردن Constraint مفید است، اما Limit نامناسب، batch ناهمگون یا dependency میتواند Flow را بدتر کند. با Baseline، Age، Throughput، Blocked و Outcome Pilot کنید.
از کجا بفهمیم فرایند تست تثبیت شده است؟
در Scope مشخص، Active itemها هویت/Disposition دارند، Workflow و WIP قابل مشاهدهاند، Evidence تصمیمپذیر است، Blocker/Exception مسیر دارد و حداقل یک تغییر با Guardrail بررسی شده است. این وضعیت بلوغ یا کیفیت محصول را اثبات نمیکند.
