برنامه‌ریزی تست

بلوغ فرآیند تست؛ راهنمای TMMi ۲.۰ از ارزیابی تا بهبود

انتشار در تاریخ توسط محمد عسکری

تیم QA یک بانک ممکن است Test Plan، ابزار مدیریت تست، CI و صدها تست خودکار داشته باشد؛ اما روز انتشار هنوز مشخص نباشد چه ریسکی پوشش داده شده، محیط چرا نامعتبر بوده و چه کسی دربارهٔ Evidence ناقص تصمیم می‌گیرد. از طرف دیگر، یک تیم کوچک ممکن است سندهای کمی داشته باشد اما زیر فشار هم برنامه‌ریزی، Evidence و یادگیری‌اش تکرارپذیر بماند. کدام‌یک بالغ‌تر است؟ پاسخ با شمارش سند و ابزار به دست نمی‌آید.

بلوغ فرایند تست یعنی توان تیم یا سازمان برای تولید Evidence معتبر و به‌موقع، کنترل ریسک و بهبود پایدار روش کار—حتی وقتی افراد، محصول یا فشار تحویل تغییر می‌کند. TMMi 2.0 یک Reference Model مرحله‌ای برای فهم و بهبود این قابلیت است؛ نه چک‌لیست خرید ابزار، نه مسابقهٔ رسیدن به Level ۵ و نه تضمین کیفیت محصول.

بلوغ فرایند تست چیست و چه چیزی نیست؟

فرایند بالغ الزاماً سنگین یا متمرکز نیست. یک Practice وقتی بالغ‌تر است که هدفش روشن، متناسب با Context، قابل‌اجرا، دارای Owner و ورودی/خروجی مشخص، قابل‌مشاهده با Evidence و قابل‌اصلاح با Feedback باشد. Template می‌تواند کمک کند، اما Template استفاده‌نشده Evidence بلوغ نیست.

شش مرز مهم

  • Process maturity ≠ Product quality: فرایند می‌تواند منظم باشد و Oracle یا Requirement اشتباه، محصول بدی بسازد.
  • Maturity ≠ Compliance: رعایت یک الزام قراردادی ممکن است لازم باشد، اما همهٔ قابلیت‌های تست را نشان نمی‌دهد.
  • Maturity ≠ Automation percentage: اتوماسیون زیاد با Suite ناپایدار و Evidence ضعیف، بلوغ نیست.
  • Standardization ≠ یکسان‌سازی کور: Core مشترک باید Tailoring متناسب با Risk، تیم و چرخهٔ عمر داشته باشد.
  • Measurement ≠ Dashboard: Level بالاتر با انبار دادهٔ بی‌هدف یا KPIهای بازی‌پذیر ساخته نمی‌شود.
  • Certification ≠ پایان بهبود: Rating یک Snapshot در Scope و زمان مشخص است؛ Outcome آینده را تضمین نمی‌کند.

خود مدل رسمی TMMi تلاش بهبود را تابع نیاز سازمان و محیط کسب‌وکار می‌داند. در Release Notes نسخهٔ ۲.۰ نیز صریحاً آمده که TMMi چک‌لیست نیست: Goals باید معنادار تفسیر شوند و Expected/Informative componentها را نباید صرفاً تیک زد.

چه زمانی سراغ برنامهٔ بهبود برویم؟

  • Critical defect یا Incident تکرار می‌شود اما اقدام پیشگیرانه بسته نمی‌شود.
  • نتیجهٔ تست دیر، نامعتبر یا غیرقابل‌توضیح است.
  • هر تیم تعریف متفاوتی از Done، Severity یا Test result دارد.
  • با رفتن یک فرد، روش کار یا دانش کلیدی از بین می‌رود.
  • محیط، داده و Dependency دائماً Release را Block می‌کنند.
  • اتوماسیون زیاد شده اما Feedback، اعتماد یا Outcome بهتر نشده است.
  • قرارداد یا مشتری به ارزیابی مستقل قابلیت فرایند نیاز دارد.

اگر هیچ Problem statement و Sponsorی وجود ندارد، «رسیدن به سطح بالاتر» به‌تنهایی Business driver کافی نیست.

TMMi ۲.۰ چیست؟ نسخهٔ جاری چه تغییری کرده است؟

TMMi یا Test Maturity Model integration یک مدل Stage-based برای بهبود فرایند تست است. صفحهٔ رسمی اسناد TMMi اکنون Reference Model Version 2.0 (2026)، Release Notes آن و TAMAR 1.3 را منتشر می‌کند. بسیاری از مقاله‌ها هنوز Release ۱.۳ سال ۲۰۲۲ را توضیح می‌دهند؛ برای Assessment یا برنامهٔ تازه، نسخه و Transition rule را با Assessor بررسی کنید.

تفاوت‌های کلیدی Version ۲.۰

  • Agile و DevOps در مثال‌ها و Guidance مدل ادغام و به‌روز شده‌اند.
  • Generic Goals/Practices قدیمی حذف شده‌اند تا مدل Leanتر و خواناتر شود.
  • Level ۲ حوزهٔ تازهٔ Implementation and Habit دارد تا «اجرا و عادت‌شدن» را صریح کند.
  • Level ۳، Test Lifecycle and Integration را به Test Process and Integration بازطراحی کرده است.
  • Level ۴ اکنون Test Measurement و Product Quality Evaluation را دارد؛ Advanced Reviews در ساختار قدیمی، دیگر Process Area جداگانهٔ Level ۴ نیست.
  • People–Process–Technology برای روشن‌کردن نقش Automation و AI تقویت شده است.
  • Annexهای Quality Engineering و AI اضافه یا گسترش یافته‌اند.

در مدل ۲.۰ فقط Goals الزام نتیجه‌ای هستند؛ Practices انتظارهای معمول برای رسیدن به Goal و Subpractice/Exampleها اطلاعات راهنما هستند. اگر Goal را با راه دیگری معتبر برآورده می‌کنید، نباید صرفاً برای شبیه‌شدن به مثال مدل Artifact اضافه تولید کنید.

پنج سطح TMMi ۲.۰ به زبان تصمیم

همهٔ سازمان‌ها از نظر Rating در Level ۱ شروع می‌شوند. Levelها cumulative هستند: Level ۳ بر هدف‌های Level ۲ بنا می‌شود و نمی‌توان با چند Practice پیشرفته، شکاف پایه را دور زد. بااین‌حال Improvement Backlog لازم نیست همیشه شماره‌محور باشد؛ Business pain می‌تواند ترتیب Experimentها را تعیین کند، مشروط به اینکه ادعای Rating رسمی نکنید.

Level 1 — Initial

روش‌ها عمدتاً Ad hoc و وابسته به افرادند؛ ممکن است تیم Practiceهای خوبی هم داشته باشد، اما اجرا زیر فشار پایدار و قابل‌تکرار نیست. Level ۱ به معنی «هیچ تستی انجام نمی‌شود» نیست و دامنهٔ بزرگی از سازمان‌ها را شامل می‌شود.

پرسش تشخیصی: اگر QA Lead مرخصی باشد یا Release اضطراری شود، آیا Risk، Environment، Result و Decision همان‌قدر قابل‌مشاهده می‌مانند؟

Level 2 — Managed

تست در Project/Team مدیریت می‌شود: Policy/Strategy، Planning، Monitoring/Control، Design/Execution، Environment و در Version ۲.۰، Implementation/Habit.

Process Area رفتار قابل‌مشاهده
2.1 Test Policy and Strategy جهت و Test levelها با Business و Risk هم‌راستا هستند.
2.2 Test Planning Approach، Exit، Resource و Commitment پیش از اجرا روشن‌اند.
2.3 Test Monitoring and Control انحراف و Product quality visible است و Control action رخ می‌دهد.
2.4 Test Design and Execution Condition به Script/Procedure/Charter و Result/Incident قابل‌ردیابی می‌شود.
2.5 Test Environment نیاز، آماده‌سازی، داده، دسترسی و وضعیت محیط مدیریت می‌شود.
2.6 Implementation and Habit Practice فقط تعریف نشده؛ منابع، آموزش، Owner و استفادهٔ پایدار دارد.

Level 3 — Defined

استاندارد سازمانی، Asset و Tailoring guideline وجود دارد؛ Test زود وارد Lifecycle می‌شود و Capability تخصصی/حرفه‌ای ساخته می‌شود.

  • ۳.۱ Test Organization؛
  • ۳.۲ Test Training Program؛
  • ۳.۳ Test Process and Integration؛
  • ۳.۴ Non-Functional Testing؛
  • 3.5 Peer Reviews.

«Test Organization» الزاماً دپارتمان مستقل بزرگ نیست. در Agile می‌تواند Competence center، Guild/Chapter یا ساختار دیگری باشد؛ شرط مهم، مسئولیت روشن برای Process asset، Capability و Improvement است.

Level 4 — Measured

فرایند Defined پیش‌نیاز Measurement معنادار است. دو حوزهٔ نسخهٔ ۲.۰ عبارت‌اند از:

  • 4.1 Test Measurement: Information need→Measurement objective→Measure→Collection/analysis→Decision؛
  • 4.2 Product Quality Evaluation: نیاز کیفیت و معیار کمی محصول برای تصمیم، نه صرفاً شمارش فعالیت.

داشتن ۳۰ نمودار با تعریف متفاوت میان تیم‌ها Level ۴ نیست. ابتدا مخرج، Cohort، Timestamp، Source، Owner و Decision use را استاندارد کنید. راهنمای ۱۲ متریک تست فرمول و Guardrailهای اندازه‌گیری را جداگانه پوشش می‌دهد.

Level 5 — Optimization

بهبود مستمر روی یک فرایند Defined و Measured انجام می‌شود:

  • ۵.۱ Defect Prevention؛
  • ۵.۲ Quality Control؛
  • 5.3 Test Process Optimization.

Root-cause analysis، Statistical control و ارزیابی فناوری تازه باید به تغییر پایدار منجر شوند. یک Postmortem خوب فقط متن نیست؛ Action باید Owner و Follow-up داشته باشد. فصل Postmortem Culture در Google SRE نیز مالکیت رسمی اقدام، Blameless learning و بازتنظیم فرایند را به هم وصل می‌کند.

Level هدف نیست؛ Outcome هدف است

یک برنامهٔ ضعیف می‌گوید: «تا پایان سال Level ۳ شویم.» برنامهٔ قابل‌دفاع می‌گوید:

Business driver:
  در Releaseهای پرداخت، 17% Runها Invalid است و Evidence بحرانی دیر می‌رسد.

Target outcome:
  Median time-to-actionable-evidence ≤ 40 min
  Invalid-run rate ≤ 8%
  Valid evidence for impacted Critical risks ≥ 90%

Guardrails:
  Critical escape بدتر نشود
  Quarantine age و manual toil افزایش نیابد
  تیم‌ها برای سبزکردن KPI، Not-run را حذف نکنند

Scope:
  Checkout value stream؛ چهار تیم؛ PR و release lanes؛ 90 روز

ممکن است Practiceهای TMMi برای رسیدن به این Outcome مفید باشند، اما Success با تغییر Outcome سنجیده می‌شود، نه تعداد Process Areaهای «بسته‌شده».

یک زنجیرهٔ Traceability بسازید

Business pain
  → observed failure / risk
  → weak capability or practice
  → improvement hypothesis
  → intervention
  → leading signal + outcome + guardrail
  → adoption decision
  → institutionalization evidence

این زنجیره جلوی Cargo cult را می‌گیرد. مثلاً «ابزار جدید Test Management» Intervention است، نه Outcome. اگر تصمیم، Evidence یا Flow بهتر نشود، Tool rollout بهبود فرایند محسوب نمی‌شود.

Self-check، Diagnostic، Informal و Formal Assessment یکسان نیستند

ابتدا Purpose را مشخص کنید: یادگیری داخلی، Prioritization، Benchmark، Supplier qualification یا Certification؟ نوع Evidence، Independence، هزینه و rigor بر اساس پاسخ تغییر می‌کند.

روش کاربرد Evidence/rigor خروجی مجاز
Self-check/Lightning scan زبان مشترک و Hypothesis اولیه Questionnaire؛ Bias بالا فهرست سؤال؛ نه Rating معتبر
Internal diagnostic Improvement Backlog Artifact + observation + outcome trace Strength/Gap/Hypothesis؛ بدون ادعای Certification
Informal TMMi assessment Indicative view و Recommendation روش/Assessor مطابق قواعد جاری؛ corroboration کمتر دید indicative؛ Formal maturity rating نمی‌دهد
Formal TMMi assessment Rating/Certification/contract روش Accredited، Lead Assessor، تیم و Evidence corroborated Rating قابل‌تأیید در Scope تعریف‌شده

صفحهٔ رسمی انواع Assessment Formal و Informal را تفکیک می‌کند. FAQ رسمی TMMi نیز توضیح می‌دهد TAMAR خودِ روش Assessment نیست؛ Requirementهای ساخت روش Accredited است. برای Version ۲.۰، سند جاری TAMAR ۱.۳ با ساختار تازه هم‌راستا شده است.

Scope را قبل از Rating قفل کنید

organization: Arvand Digital (fictional)
unit: Consumer Payments
locations: Tehran + remote Iran
products: Checkout API, payment web, settlement worker
teams: 4 product teams + shared SRE
lifecycle: trunk-based, daily release, weekly settlement release
period: 1405-Q2
excluded: lending platform, vendor-owned PSP internals
reason for exclusion: different governance and unavailable evidence

«شرکت ما Level ۳ است» بدون Organizational scope، تاریخ و Assessment reference ادعای دقیقی نیست. حتی Rating رسمی نیز دربارهٔ Scope ارزیابی‌شده است، نه همهٔ محصول‌ها و آیندهٔ سازمان.

Evidence سه‌لایهٔ تشخیص

  1. Claim: مصاحبه، Questionnaire یا گفتهٔ Owner؛ برای کشف مفید، مستعد Social desirability.
  2. Artifact: Strategy، Plan، Run، Dashboard، Ticket، Review record یا Environment manifest نسخه‌دار.
  3. Use/Outcome: مشاهدهٔ اجرا در Sample تیم‌ها و پیوند Practice به تصمیم یا نتیجه.

Artifact را فقط به‌دلیل وجود نپذیرید. تاریخ، Scope، Version، Author/Approver، مصرف‌کننده، نمونهٔ استفاده و Exception آن را بررسی کنید. Evidence باید PII، Secret و اطلاعات Incident را با دسترسی و Retention متناسب محافظت کند.

آزمایش ۱: چرا Self-assessment بلوغ را بیش‌برآورد می‌کند؟

برای نشان‌دادن شکاف Claim و Practice، ۱۲ Practice کاملاً ساختگی تعریف کردیم. Self-check فقط می‌پرسد «آیا این کار را انجام می‌دهید؟»؛ Diagnostic سخت‌گیرانه‌تر سه شرط دارد: Artifact جاری، مشاهده در حداقل سه تیم از چهار تیم و Trace به Outcome.

نمای ارزیابی نتیجه
پاسخ «بله» در Checklist ۱۰ از ۱۲ = ۸۳٫۳٪
دارای Artifact جاری ۷ از ۱۲
مشاهده‌شده در حداقل ۳ از ۴ تیم ۵ از ۱۲
دارای Outcome trace ۴ از ۱۲
Diagnostic-ready با هر سه شرط P01 تا P04؛ فقط ۴ از ۱۲

۸۳٫۳٪ یک Maturity score معتبر نیست؛ فقط نسبت پاسخ‌های مثبت در دادهٔ ساختگی است. این آزمایش عمداً Rating rules رسمی TMMi را پیاده نمی‌کند و حق تبدیل نتیجه به Level را ندارد. درس آن محدودتر است: پرسشنامهٔ تنها نمی‌تواند Adoption، Habit یا Outcome را ثابت کند.

نمونه‌برداری Evidence

  • سه Release عادی و یک Release پرفشار؛
  • یک Incident، یک Hotfix و یک Change کم‌ریسک؛
  • تیم باتجربه و تازه‌تشکیل؛
  • Artifact موفق و ناموفق؛
  • مصاحبهٔ Product، Dev، QA، SRE و Support—not QA only.

فقط Happy path را Sample نکنید. «Implementation and Habit» زمانی آشکار می‌شود که Practice در Sprint شلوغ، نیروی جایگزین و Failure هم دوام بیاورد.

از Finding به Improvement Backlog برسید

Assessment report ضخیم اگر به تصمیم و Experiment نرسد، موجودی Gap است. هر Finding را با این Schema ثبت کنید:

finding_id: IMP-014
scope: checkout release evidence
observation: 17% runs invalid; missing environment/config identity
evidence: runs R201-R260; incident INC-87; interviews Dev/QA/SRE
business_effect: release decision delayed; rerun toil; unknown critical risk
related_goal/practice: TMMi 2.3 / 2.5 / 2.6 (mapping for guidance)
hypothesis: versioned manifest + validity gate reduces invalid decisions
intervention: manifest schema, CI lint, owner, runbook, training
baseline: invalid 17%; actionable evidence mean 64 min
target: invalid ≤ 8%; median evidence ≤ 40 min
guardrail: no higher critical escape; quarantine age ≤ 14 days
owner: QE platform lead
pilot: one checkout value stream; four weeks
decision_date: 1405-07-15
status: ready-for-experiment

Prioritization بدون امتیاز جادویی

Impact، Urgency، Evidence confidence، Reach، Effort، Dependency و Reversibility را جدا نشان دهید. می‌توانید برای Sorting یک امتیاز کمکی داشته باشید، اما Critical regulatory gap یا Restore failure را پشت میانگین پنهان نکنید.

Candidate Outcome link Evidence confidence Effort تصمیم
Run/Environment manifest Invalid و diagnosis time بالا متوسط Pilot اکنون
Critical Risk→Evidence map Unknown release risk متوسط متوسط Pilot اکنون
خرید Test Management tool نامشخص پایین زیاد Defer؛ ابتدا Problem/PoC
بازنویسی همهٔ Templateها پیوند ضعیف پایین زیاد Reject
Restore rehearsal Critical recovery evidence بالا زیاد Hard priority؛ جدا از score

WIP را محدود کنید

هر Quarter دو یا سه Capability مهم را بهبود دهید. ده‌ها Workstream هم‌زمان، Attention و Evidence را رقیق می‌کند. هر Improvement باید Sponsor، Owner، ظرفیت، تاریخ تصمیم و Stop condition داشته باشد.

IDEAL را به حلقهٔ اجرایی تبدیل کنید

سرفصل جاری ISTQB CTAL Test Management 3.0، IDEAL را برای Test Process Improvement معرفی می‌کند:

  1. Initiating: Sponsor، Business driver، Context، Scope، Team و Infrastructure.
  2. Diagnosing: Current/desired state، Strength، Gap، Root cause و Baseline.
  3. Establishing: Priority، Strategy، Backlog، Resource، Communication و Measurement plan.
  4. Acting: Pilot، Training، Tool/Workflow، Data collection و Adaptation.
  5. Learning: Outcome/Guardrail، Retrospective، Institutionalize/Adjust/Stop و چرخهٔ بعد.

Initiating: قرارداد برنامهٔ بهبود

Sponsor باید مشکل، اختیار و ظرفیت بدهد. Improvement team شامل QA/QE، Product، Development، Operations و در صورت نیاز Security/Data است. اگر تیم بهبود فقط QA باشد، Dependencyهای Delivery را «مقاومت دیگران» می‌بیند.

Diagnosing: Symptom را با Cause اشتباه نگیرید

«باگ Production زیاد است» Finding قابل‌اقدام نیست. Escape را به Risk discovery، Requirement، Boundary، Oracle، Data، Environment، Selection، Result handling، Release decision یا Monitoring طبقه‌بندی کنید. سپس System cause را بررسی کنید.

Establishing: Theory of Change بنویسید

اگر [Run identity و validity gate] را
برای [Checkout CI] اجرا کنیم،
آنگاه [Invalid decision و diagnosis time] کم می‌شود،
زیرا [Build/Config/Data/Environment قابل‌بازتولید می‌شود].
این فرض را با [baseline + pilot + comparison + qualitative feedback] می‌آزماییم.
اگر [guardrail نقض یا adoption کم] شد، Adjust/Stop می‌کنیم.

Acting: Small batch و Shadow mode

راهنمای DORA دربارهٔ Small batches تغییر کوچک را برای Feedback سریع و اصلاح فرض مفید می‌داند. ابتدا Workflow تازه را در یک Value Stream یا Shadow mode اجرا کنید؛ Rollout سراسری را به نتیجهٔ Pilot وابسته کنید.

Learning: نتیجهٔ مجاز فقط Scale نیست

  • Adopt/Scale: Outcome بهتر، Guardrail سالم، Mechanism قابل‌دفاع.
  • Adapt: Signal مثبت اما Adoption، Context یا Implementation مشکل دارد.
  • Continue: داده کم یا Seasonality بالا؛ Timebox تازه با دلیل.
  • Stop/Rollback: Outcome بهتر نشده، Cost بالا یا Guardrail خراب شده.

آزمایش ۲: Before/After مسئولانه برای Improvement Pilot

در همان دادهٔ ساختگی، چهار مشاهدهٔ هفتگی قبل و چهار مشاهده بعد از سه Intervention داشتیم: Run/Environment manifest نسخه‌دار، Gate برای Report گمشده/نامعتبر و نگاشت Critical Risk→Evidence با Owner.

Metric قبل بعد تفسیر محدود
میانگین زمان تا Evidence قابل‌اقدام ۶۴ دقیقه ۳۵ دقیقه ۲۹ دقیقه کاهش خام
Median زمان تا Evidence ۶۳٫۵ ۳۵ کمتر تحت‌تأثیر Outlier
Invalid run rate ۱۷٪ ۶٫۵٪ مخرج ۴۰۰ Run در هر دوره
Critical risk با Evidence معتبر ۷۲٫۵٪ ۹۲٫۵٪ مخرج ۸۰ Risk-instance در هر دوره
Critical escape ۱ ۰ بسیار کم برای ادعای بهبود

یک Value Stream مقایسه‌ای که Intervention نگرفت نیز از میانگین ۶۰٫۵ به ۵۳٫۵ دقیقه رسید؛ ۷ دقیقه بهبود عمومی. اختلاف تغییرها در این مثال ۲۲ دقیقه است. بااین‌حال چهار هفته، دادهٔ ساختگی و گروه غیرتصادفی اثبات علیت نیستند. Release mix، Parallelism، تعطیلات، Seasonality و تغییر Team می‌توانند Confounder باشند.

قواعد Measurement plan

  • Metric definition و Inclusion/Exclusion را پیش از Pilot Freeze کنید.
  • Median/Percentile را کنار Mean و حجم نمونه بدهید.
  • Outcome، Leading signal و Guardrail را جدا کنید.
  • Trend را ببینید؛ از یک نقطه نتیجه نگیرید.
  • Team comparison را Ranking افراد نکنید.
  • Metric drift و data-quality را Audit کنید.
  • نتیجهٔ کیفی مصاحبه/Observation را کنار عدد نگه دارید.

برای Release-facing evidence، گزارش تست تصمیم‌محور را ببینید؛ Dashboard بهبود با Release memo یک Artifact نیست.

Institutionalization: چگونه Practice به عادت تبدیل می‌شود؟

بزرگ‌ترین شکاف برنامه‌های بهبود میان «تعریف‌شدن» و «ماندن» است. Version ۲.۰ با Process Area تازهٔ Implementation and Habit همین مسئله را پررنگ کرده است.

قرارداد عادت

عنصر Evidence
Policy/expectation چه چیزی، چرا و در چه Scopeای لازم است؟
Owner/authority چه کسی نگهداری، Exception و بهبود را تصمیم می‌گیرد؟
Workflow integration Practice در Backlog/PR/CI/Release رخ می‌دهد، نه در حافظه.
Resource/tool زمان، Skill، Environment و Tool لازم موجود است.
Training/coaching فرد تازه می‌تواند با Evidence کار را انجام دهد.
Tailoring شرایط سبک/سنگین و دلیل Exception تعریف شده است.
Monitoring استفاده، کیفیت و Outcome دیده می‌شود؛ نه صرفاً Completion.
Feedback/change Incident و Retrospective Asset را نسخه‌دار اصلاح می‌کنند.

Stress test بلوغ

Practice را در این شرایط Sample کنید:

  • Release اضطراری و Deadline نزدیک؛
  • عضو کلیدی غایب؛
  • Dependency خارجی یا PSP ناپایدار؛
  • تغییر Schema/Config/Feature flag؛
  • Incident هم‌زمان با Release؛
  • تیم تازه یا Product متفاوت.

اگر تیم در هر بحران Gate را خاموش و Artifact را دور می‌زند، مشکل فقط Compliance نیست؛ Practice در Operating model جا نیفتاده یا بیش از حد سنگین است.

TMMi در Agile و DevOps چگونه Tailor می‌شود؟

Agile/DevOps به معنی حذف Planning، Strategy و Evidence نیست؛ Artifact و Cadence تغییر می‌کند. Reference Model ۲.۰ Guidance این Contextها را در خود ادغام کرده و صفحهٔ اسناد TMMi راهنماهای اختصاصی نیز دارد.

نیاز مدل پیاده‌سازی سنگین Tailoring Agile/DevOps
Policy/Strategy سند سالانهٔ بلند Strategy core + product overlay + version control
Planning Plan جدا برای هر فاز Risk/Evidence در Refinement و Release plan
Monitoring گزارش هفتگی دستی Run manifest، Dashboard و exception workflow
Test design Test caseهای مفصل برای همه‌چیز Examples، charters، code و trace متناسب با Risk
Environment تیم مرکزی و محیط ثابت IaC، ephemeral/shared contract و semantic readiness
Organization QA department مستقل Embedded QE + Chapter/Enabling/Independent assurance
Training کلاس سالانه Skill matrix، pairing، guild و work-sample evidence
Improvement Program بزرگ Small experiment، telemetry و monthly learning review

برای تبدیل Strategy به Risk/Evidence/Gate از راهنمای سند استراتژی تست و برای RBT عملی از راهنمای استقرار تست مبتنی بر ریسک استفاده کنید.

Standard process و Tailoring guideline

Core باید زبان مشترک Result، Risk، Evidence، Exception و Minimum control را بدهد. Product overlay بر اساس Domain، Release cadence، Regulation و Architecture Depth/Fidelity را تعیین کند. هر Tailoring این فیلدها را داشته باشد:

context / trigger
standard practice
tailored practice
risk introduced
compensating control
approver
evidence
expiry / review date

People، Process و Technology را متوازن کنید

Tool بدون Skill و Workflow، Dashboard قبرستان داده می‌سازد. Process بدون Tool، Toil و Variation بالا می‌آورد. Training بدون فرصت استفاده، Capability پایدار نمی‌سازد.

People

  • Role و Decision authority؛
  • Capability matrix بر اساس Product risk؛
  • Primary/backup و Bus factor؛
  • Coaching، Pairing و Community of Practice؛
  • ظرفیت رسمی برای Improvement work.

راهنمای رهبری تیم QA ساخت Capability، Capacity و مسیر رشد را پوشش می‌دهد؛ TMMi checklist جای People system نیست.

Process

  • ورودی/خروجی، Owner و Consumer روشن؛
  • مسیر عادی، Exception و Escalation؛
  • Tailoring بر اساس Context؛
  • Evidence، Metric و Review trigger؛
  • Versioning و Retrospective change.

Technology، Automation و AI

TMMi ۲.۰ Technology را Enabler می‌داند. Automation یا AI می‌تواند Test design، execution، selection، analysis یا reporting را پشتیبانی کند، اما مسئول Goal و Decision نیست. برای هر PoC این موارد را بسنجید:

  • Problem و Process owner پیش از Tool؛
  • Integration و Exportability؛
  • Evidence identity و Audit trail؛
  • False positive/negative و Human review؛
  • Data residency، PII، Secret و Vendor access؛
  • Model/version/prompt trace برای AI؛
  • TCO، Skill، fallback و Exit plan؛
  • Outcome/guardrail پیش از Scale.

اگر مسئله فقط Automation Suite ناسالم است، کل برنامهٔ بلوغ را به بازنویسی ابزار تقلیل ندهید؛ از چارچوب تشخیص و نجات اتوماسیون استفاده کنید. اگر هدف تدوین Roadmap اتوماسیون است، استراتژی اتوماسیون از Pilot تا Scale مالک آن موضوع است.

مثال ایرانی: برنامهٔ بهبود Checkout و تسویه

«آروند دیجیتال» یک Marketplace ساختگی با چهار تیم Product در ایران است. Release روزانه دارد، دو PSP و یک Settlement worker دارد. مشکل: Runهای نامعتبر، تصمیم دیرهنگام و Risk ناشناخته در Timeout-after-commit و Restore.

Evidence تشخیص

  • ۶۰ Run نمونه: Config و Environment identity در ۱۷٪ نامعتبر؛
  • Incident INC-۸۷: Callback تکراری و Ledger mismatch؛
  • چهار Interview: Product، Dev، QA و SRE تعریف متفاوتی از Ready دارند؛
  • PSP Sandbox رفتار Timeout-after-commit واقعی را بازنمایی نمی‌کند؛
  • Backup موجود است اما Restore evidence تازه نیست؛
  • اعداد فارسی/عربی/لاتین و ریال/تومان در Test basis یکسان نیستند؛
  • Timestamp با UTC ذخیره اما Cut-off تسویه با Asia/Tehran تعریف نشده است.

سه Hypothesis بهبود

  1. Manifest + readiness: Build/Config/Data/Environment/Dependency identity و semantic health، Invalid و diagnosis time را کم می‌کند.
  2. Risk→Evidence: Duplicate charge، amount integrity، timeout state و restore با Critical gate نام‌دار Unknown را آشکار می‌کند.
  3. Incident→prevention: RCA با Action owner و regression/monitoring evidence از تکرار همان Mechanism جلوگیری می‌کند.

Pilot و Guardrail

چهار هفته Shadow، یک Checkout team، Full fallback، مقایسه با Value Stream مشابه و Review هفتگی. Guardrailها: Critical escape، Quarantine age، Manual toil، Team interruption و PII leakage بدتر نشوند. Scale فقط پس از Outcome و Adoption evidence.

Institutionalization

  • Manifest schema در Repository و CI lint؛
  • Definition و Runbook مشترک اما Product overlay برای PSP/Settlement؛
  • Owner در QE Platform و Backup در هر تیم؛
  • Onboarding exercise با یک Run نامعتبر واقعی؛
  • Monthly sample audit و Incident trigger؛
  • Exception با Expiry، Monitoring و rollback؛
  • Quarterly review برای حذف Practiceهای بی‌ارزش.

نقشهٔ راه ۹۰روزه

روزهای ۱ تا ۱۵ — Initiate

  • Business driver، Sponsor، Improvement lead و Decision rights؛
  • Organizational scope، Exclusion و Data/privacy boundary؛
  • Outcome، Leading metric، Guardrail و Baseline plan؛
  • Communication و ظرفیت رسمی تیم.

روزهای ۱۶ تا ۳۰ — Diagnose

  • مصاحبهٔ چندنقشی و Artifact inventory؛
  • نمونه‌برداری Release عادی/پرفشار/Incident؛
  • Strength/Gap/Root cause و Evidence confidence؛
  • عدم تبدیل Self-check به Rating.

روزهای ۳۱ تا ۴۵ — Establish

  • Improvement Backlog با Theory of Change؛
  • دو یا سه Pilot، Owner، Budget و Stop condition؛
  • Measurement contract و Comparison design؛
  • Training/Tool/Workflow plan.

روزهای ۴۶ تا ۷۵ — Act

  • Shadow mode و Small batches؛
  • هفتگی Outcome/Guardrail/qualitative feedback؛
  • ثبت Deviation، Exception و Confounder؛
  • اصلاح Hypothesis، نه دستکاری Baseline.

روزهای ۷۶ تا ۹۰ — Learn

  • Adopt/Adapt/Continue/Stop برای هر Pilot؛
  • Practice موفق با Owner، Workflow، Training و Audit؛
  • حذف Artifact/Meeting بی‌اثر؛
  • Backlog چرخهٔ بعد و تصمیم جداگانه دربارهٔ Informal/Formal assessment.

Dashboard برنامهٔ بهبود

Dashboard را چهارلایه بسازید تا Activity به‌جای Outcome ننشیند:

لایه نمونه Guardrail
Business/Product outcome Critical escaped impact، customer failure، availability Severity و cohort ثابت
Decision evidence Critical risk با Evidence معتبر/تازه؛ Unknown Invalid/Not-run را Pass نکنید
Flow/health Time-to-actionable-evidence، invalid، flake، diagnosis Percentile و مخرج
Adoption/habit نمونهٔ تیم‌های دارای Use evidence؛ exception age Completion count تنها نباشد

Metric dictionary حداقلی

name: valid-critical-evidence-rate
question: آیا برای Critical riskهای Impacted شواهد معتبر و تازه داریم؟
numerator: impacted critical risks with valid, non-expired evidence
denominator: all impacted critical risks in release cohort
exclusions: none; invalid/not-run remain in denominator
source: risk registry + immutable run manifests
cadence: per release; weekly trend
owner: test management lead
decision: hold/review improvement gap
anti-gaming: audit mapping and evidence age; no duplicate-risk inflation

Framework اندازه‌گیری را متناسب با Goal انتخاب کنید. راهنمای پژوهشی DORA دربارهٔ Measurement framework نیز از Information need و هدف سازمانی شروع می‌کند، نه از یک مجموعه KPI جهانی.

چه زمانی Assessment رسمی ارزش دارد؟

Formal assessment زمانی منطقی‌تر است که Customer/Supplier contract، Benchmark قابل‌تأیید، Governance بیرونی یا Certification Business case مشخصی دارد. برای کشف نخستین Improvementها، Diagnostic داخلی یا Informal assessment ممکن است کم‌هزینه‌تر و سریع‌تر باشد.

پیش از قرارداد با Assessor بپرسید

  • مدل و TAMAR کدام Version است و Transition rule چیست؟
  • Assessment formal است یا informal؛ خروجی مجاز دقیقاً چیست؟
  • Organizational scope و Exclusion چگونه نماینده بودن را ثابت می‌کند؟
  • Method Accredited و Lead/Assessor در رجیستری رسمی است؟
  • مصاحبه، Artifact، Corroboration و Sampling چگونه انجام می‌شود؟
  • Evidence حساس کجا ذخیره، چه‌قدر نگهداری و چگونه حذف می‌شود؟
  • Rating، Strength، Gap و Improvement recommendation چگونه گزارش می‌شوند؟
  • تعارض منافعِ Consulting و Assessment چگونه مدیریت می‌شود؟

Certification را با Training certificate افراد یا استفاده از مدل اشتباه نگیرید. ادعای لوگو/Level باید قابل‌ارجاع به Scope و رکورد رسمی باشد.

ضدالگوهای بهبود بلوغ تست

  1. Level chasing: شماره جای Outcome می‌نشیند.
  2. Checklist compliance: Practice بدون Goal و Context تیک می‌خورد.
  3. Document factory: Template تولید می‌شود اما کسی با آن تصمیم نمی‌گیرد.
  4. Tool-led maturity: خرید ابزار به‌عنوان بهبود اعلام می‌شود.
  5. QA-only program: Product/Dev/Ops خارج می‌مانند.
  6. Big-bang rollout: همهٔ تیم‌ها هم‌زمان تغییر می‌کنند و Attribution از بین می‌رود.
  7. No baseline: بعد از Rollout، هر حرکت Success تعبیر می‌شود.
  8. Activity KPI: تعداد Plan/Test/Training جای Outcome را می‌گیرد.
  9. Average-only: Tail، Sample size و cohort پنهان می‌شود.
  10. Invalid as pass: Evidence نامعتبر بلوغ ظاهری می‌سازد.
  11. One process fits all: Legacy، Mobile، Payment و Data یکسان Tailor می‌شوند.
  12. Heroic owner: با رفتن Champion، Improvement می‌میرد.
  13. Permanent exception: Bypass بدون Expiry عادت واقعی می‌شود.
  14. Assessment theater: Artifact فقط پیش از Assessor مرتب می‌شود.
  15. Certification endpoint: پس از Rating، Learning loop متوقف می‌شود.
  16. AI maturity washing: تولید Test با AI بدون Oracle، Audit یا Outcome بالغ اعلام می‌شود.

چک‌لیست شروع برنامه

  • □ Business pain و Target outcome نام دارند.
  • □ Sponsor اختیار و Capacity داده است.
  • □ Model/Assessment version ثبت شده است.
  • □ Scope، Exclusion، تاریخ و Lifecycle روشن‌اند.
  • □ Purpose تشخیص از Rating/Certification جداست.
  • □ Claim، Artifact و Use/Outcome evidence تفکیک می‌شوند.
  • □ نمونه شامل Stress/Incident/تیم متفاوت است.
  • □ Strengthها نیز ثبت می‌شوند تا شکسته نشوند.
  • □ Finding به Business effect و Root cause وصل است.
  • □ Backlog WIP محدود و Owner/Decision date دارد.
  • □ Theory of Change و Stop condition نوشته شده است.
  • □ Baseline، cohort، مخرج و data quality ثابت‌اند.
  • □ Outcome، Leading signal و Guardrail جدا هستند.
  • □ Pilot/Comparison محدود پیش از Scale وجود دارد.
  • □ Adoption با Use evidence سنجیده می‌شود، نه Training count.
  • □ Tailoring و Exception Owner/Expiry دارند.
  • □ Practice موفق به Workflow، Training و Audit وصل می‌شود.
  • □ Evidence حساس Access/Retention/Deletion دارد.
  • □ ابزار/AI Problem و Exit plan مشخص دارد.
  • □ چرخهٔ بعدی Learning از ابتدا زمان‌بندی شده است.

پرسش‌های متداول

مدل بلوغ TMMi چند سطح دارد؟

پنج سطح دارد: Initial، Managed، Defined، Measured و Optimization. همه از Level ۱ شروع می‌شوند و Rating سطوح بالاتر cumulative است. Version ۲.۰ در Level ۲ شش Process Area، Level ۳ پنج، Level ۴ دو و Level ۵ سه حوزه دارد.

آیا Self-assessment می‌تواند سطح رسمی TMMi بدهد؟

خیر. Self-check یا Lightning scan برای Hypothesis و زبان مشترک مفید است، اما Formal rating به Scope، روش Accredited، Assessor واجد شرایط و Evidence/Corroboration مطابق قواعد جاری نیاز دارد. Informal assessment نیز Rating رسمی تولید نمی‌کند.

آیا TMMi برای Agile و DevOps مناسب است؟

بله، اگر Goal را حفظ و Artifact/Cadence را Tailor کنید. Version ۲.۰ Agile و DevOps را در Guidance به‌روز کرده است. Planning می‌تواند در Refinement، Monitoring در Pipeline و Test Organization در Chapter/Enabling model پیاده شود؛ سند سنگین اجباری نیست.

از کدام Process Area شروع کنیم؟

برای بهبود، از Business pain و ضعیف‌ترین Capability مرتبط شروع کنید؛ پایه‌های Level ۲ معمولاً مهم‌اند، اما Pilot را با Outcome و Dependency اولویت دهید. برای ادعای Maturity level باید Rating rules cumulative و Scope رسمی رعایت شوند.

چقدر زمان لازم است تا بلوغ تست بهتر شود؟

عدد جهانی قابل‌دفاعی وجود ندارد. یک Pilot کوچک در ۳۰ تا ۹۰ روز می‌تواند Hypothesis را بیازماید، اما Institutionalization چند تیم، دادهٔ Level ۴ یا Certification به Scope، Baseline، Skill، Evidence و تغییر رفتاری بیشتری نیاز دارد. Deadline را پس از Diagnostic برآورد کنید.

جمع‌بندی

بلوغ فرایند تست با تعداد سند، ابزار یا Test case ثابت نمی‌شود. یک سازمان بالغ‌تر می‌تواند نشان دهد چرا Practice را انتخاب کرده، چگونه در Scope واقعی اجرا می‌شود، چه Evidence و Outcomeی دارد، زیر فشار چگونه دوام می‌آورد و با Failure چگونه تغییر می‌کند.

TMMi ۲.۰ نقشهٔ مرجع خوبی است، به‌شرط آنکه به Checklist تبدیل نشود. از Business driver و Diagnostic Evidence شروع کنید، Improvement را در Small batch بیازمایید، نتیجه و Guardrail را صادقانه بسنجید و فقط Practice مؤثر را Institutionalize کنید. Level می‌تواند خروجی Assessment باشد؛ یادگیری باید خروجی هر چرخه باشد.

منابع رسمی و مطالعهٔ بیشتر

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید