مدیریت تست در Scrum؛ از Quality Flow تا Done

مدیریت تست در Scrum به معنای ساختن یک فاز تست کوچک در انتهای Sprint یا تعیین QA به‌عنوان نگهبان کیفیت نیست. هدف، شفاف‌کردن جریان رسیدن کار از مسئله و Product Backlog به یک Increment واقعاً Done است: چه ریسکی داریم، چه ادعایی باید آزموده شود، چه Evidenceای کافی است، چه چیزی مانع جریان شده و تیم بر پایهٔ مشاهده چه تغییری می‌دهد.

این راهنما یک Quality Flow Contract می‌سازد که با Scrum Guide سازگار است، اما Practiceهای تست را به‌صورت زمینه‌محور به آن اضافه می‌کند. تفاوت DoD، Acceptance Criteria و Test Charter، نقش متخصص QA در Developers، جریان Refinement تا Done، نقاط Inspect/Adapt در رویدادها، WIP و Aging، باگ، اتوماسیون، Evidence و Retrospective experiment را قدم‌به‌قدم می‌بینید.

خلاصهٔ اجرایی مدیریت تست در Scrum

• Scrum نقش یا فاز جداگانه‌ای به نام تست تعریف نمی‌کند؛ Verification جزو کار محصول است.
• تخصص QA می‌تواند در Developers حضور داشته باشد، اما مسئولیت Increment ارزشمند و مفید متعلق به کل Scrum Team است.
• Product Backlog item را برای رسیدن به Done برنامه‌ریزی کنید، نه برای رسیدن به صف تست.
• رویدادها Status gate نیستند؛ فرصت شفافیت، بازرسی و سازگاری‌اند.
• DoD کف مشترک Increment است؛ Acceptance Criteria به مورد خاص کمک می‌کند و Evidence نتیجه را قابل‌بررسی می‌سازد.
• به‌جای تعداد Test Case و Bug، Flow، Risk، Evidence freshness و Outcome را مشاهده کنید.

Quality flow:
Product Goal → Product Backlog → Sprint Goal → collaborative work → Done Increment → feedback → adaptation

مبنای رسمی: Scrum Guide جاری کدام است؟

صفحهٔ رسمی Scrum Guides اعلام می‌کند نسخهٔ رسمی جاری همچنان نوامبر ۲۰۲۰ است. خود Scrum Guide ۲۰۲۰ انگلیسی تعریف کامل چارچوب را ارائه می‌کند و عمداً سبک و ناکامل است؛ یعنی Test Strategy، Workflow، Tool یا Technique مشخصی تحمیل نمی‌کند. این Practiceها باید Contextمحور باشند و هستهٔ Scrum را مخدوش نکنند.

برای خواندن اصطلاحات به فارسی، ترجمهٔ فارسی Scrum Guide ۲۰۲۰ در همان مخزن رسمی در دسترس است. در قراردادهای تیم، واژهٔ انگلیسی و معادل فارسی را کنار هم ثبت کنید تا اختلاف ترجمه دربارهٔ Accountability، Commitment، Increment و Done به اختلاف تصمیم تبدیل نشود.

اصلاح واژگان قدیمی: نقش، تیم توسعه و مراسم

تاریخچهٔ رسمی تغییرات Scrum Guide توضیح می‌دهد که نسخهٔ ۲۰۲۰ از «یک Scrum Team» با سه Accountability استفاده می‌کند: Product Owner، Scrum Master و Developers. اصطلاح Development Team حذف شده و Self-managing جای Self-organizing را گرفته است. همچنین سه سؤال اجباری Daily حذف شده‌اند و Product Goal به Commitments افزوده شده است.

• «مراسم» تعبیر رایج است؛ متن رسمی از Event استفاده می‌کند.
• Sprint خودش یک Event و ظرف چهار Event دیگر است.
• Backlog Refinement فعالیتی پیوسته است، نه Event ششم.
• Tester عنوان تخصصی یا شغلی است، نه Accountability چهارم Scrum.
• Developers یعنی همهٔ افرادی که هر جنبه‌ای از Increment قابل‌استفاده را می‌سازند.

جایگاه QA: تخصص درون Developers، نه صف بیرونی

اگر متخصص QA عضو Scrum Team و مشغول ساخت Increment است، در زبان Guide جزو Developers محسوب می‌شود؛ همان‌طور که تحلیلگر، طراح یا مهندس عملیات ممکن است تخصص متفاوتی داشته باشد. این نام تخصص را حذف نمی‌کند، اما یک زیرتیم QA با Handoff و Sign-off جدا را قانون Scrum نمی‌سازد.

Accountability ≠ job title
Developer in Scrum = contributor to any aspect of a usable Increment
QA capability = shared work with explicit expertise and ownership

برای مبانی گسترده‌تر، راهنمای تست چابک و نقش QA در Sprint را بخوانید. این مقاله فقط Operating Model مدیریت جریان کیفیت را مالک است.

Test Manager در Scrum: عنوان یا Capability؟

Scrum Accountability جداگانه‌ای به نام Test Manager تعریف نمی‌کند. بااین‌حال سازمان ممکن است برای استخدام، توسعهٔ Capability، انطباق، آزمایشگاه یا هماهنگی چندتیمی مدیر QA داشته باشد. مرز مهم این است که او کار Sprint را به‌جای Developers تخصیص ندهد، Daily را Status meeting نکند و یک Sign-off پنهان بیرون DoD نسازد.

نیاز	Accountability/مالک	همکاری تخصصی
ارزش و Product Backlog	Product Owner	QA ریسک و تست‌پذیری را روشن می‌کند
Sprint Backlog و نحوهٔ کار	Developers	متخصصان با هم برنامهٔ رسیدن به Done می‌سازند
اثربخشی Scrum	Scrum Master	مانع، شفافیت و Self-management را Enable می‌کند
Increment ارزشمند و مفید	کل Scrum Team	Evidence و Feedback مشترک‌اند
Governance بیرونی	مالک سازمانی مصوب	باید با Sprint و DoD شفاف Interface شود

Quality Flow Contract چیست؟

Quality Flow Contract توافق قابل‌بازبینی تیم دربارهٔ حرکت Work و Evidence است، نه سندی سنگین برای امضا. این قرارداد مشخص می‌کند کدام Risk signal در چه مرحله‌ای آشکار می‌شود، چه Evidenceای به Done کمک می‌کند، صف‌ها چگونه دیده می‌شوند، Blocker چه Escalationی دارد و چه کسی دربارهٔ Product، Sprint، Risk یا Release اختیار دارد.

• Product/Sprint Goal و مرز Product
• Workflow states و Exit policy هر State
• Risk class، Quality scenario و Evidence expectation
• DoD clauses و Applicability
• Environment/Data/Tool readiness
• WIP policy، Aging alert و Swarming trigger
• Defect/Finding workflow و Retest
• Metric purpose، denominator و Review cadence
• Decision rights، Exception و Expiry

flow_contract_version: QF-SYN-v1
product_goal: fictional_checkout_learning
workflow_owner: Scrum Team
review_trigger: every Retrospective or material context change

از Product Goal به Quality Questions

Product Goal وضعیت آیندهٔ محصول است، نه فهرست Feature یا عدد Bug. تیم برای نزدیک‌شدن به آن باید Quality Question بسازد: کدام رفتار ارزش را ممکن یا نابود می‌کند؟ چه داده‌ای حساس است؟ Failure چه پیامدی دارد؟ چه چیز را هنوز نمی‌دانیم؟ این سؤال‌ها Product Backlog را غنی می‌کنند، اما اولویت نهایی آن همچنان Accountability مالک محصول است.

Goal: reduce fictional checkout uncertainty
Question: can duplicate submit create two business effects?
Claim: one accepted intent maps to at most one committed synthetic order
Unknown: provider boundary not included in this Sprint

Product Backlog را به Inventory ریسک وصل کنید

Product Backlog تنها منبع کار Scrum Team است؛ بنابراین کار Testing، Debt، Observability، Defect، Experiment و Enabler نباید در فهرستی نامرئی دفن شود. لازم نیست همه چیز یک قالب User Story داشته باشد. هر Item باید Outcome/مسئله، Context، Risk، Dependency و دلیل Order را تا حد لازم شفاف کند.

• Feature و تغییر رفتار
• Defect یا Security finding
• Quality enabler مانند Test seam یا Telemetry
• Technical debt با پیامد قابل‌بیان
• Discovery/Experiment برای کاهش Unknown
• Operational/Compliance work با Source و Authority

Refinement رویداد رسمی Scrum نیست

Product Backlog Refinement فعالیت مداوم شکستن و تعریف دقیق‌تر Itemهاست؛ زمان‌بندی و Technique آن را تیم انتخاب می‌کند. خروجی مطلوب «همهٔ پاسخ‌ها» نیست، بلکه Transparency کافی برای انتخاب آگاهانه است. Definition of Ready نیز عنصر رسمی Scrum نیست؛ اگر تیم Policy کمکی دارد، نباید Unknownهای ارزشمند را پنهان یا Discovery را از Sprint ممنوع کند.

1. Outcome و Actor را Clarify کنید.
2. Example، Counterexample و Rule جمع کنید.
3. Risk و Dependency را آشکار کنید.
4. Testability/Observability/Data need را بررسی کنید.
5. Item را کوچک کنید، اما Flow ارزش را تکه‌تکه نکنید.
6. سؤال باز، مالک پاسخ و موعد را ثبت کنید.

Acceptance Criteria، DoD و Test Charter یکی نیستند

Artifact	دامنه	کارکرد	ضدالگو
Acceptance Criteria	Item/Outcome خاص	مثال و مرز پذیرش مورد	کپی DoD در هر Story
Definition of Done	Increment/Product	کیفیت لازم برای Done و Transparency	تغییر موردی برای سبزشدن Sprint
Test Charter	Session/Question/Risk	Scope، روش، Oracle و Evidence	فهرست Click بدون سؤال
Test Case/Check	رفتار تکرارپذیر	بازخورد مشخص با Oracle	تعداد به‌عنوان ارزش
Evidence	Build/Run/Claim	امکان داوری نتیجه	Screenshot بی‌هویت و منقضی

برای ساخت Clauseهای قابل‌ممیزی، راهنمای Definition of Done از Clause تا Evidence مکمل مستقیم این بخش است.

DoD: کف مشترک، نه چک‌لیست نمایشی

DoD توصیف رسمی وضعیت Increment هنگام برآورده‌شدن معیارهای کیفیت محصول است. اگر استاندارد سازمانی وجود دارد، تیم آن را حداقل رعایت می‌کند؛ و چند Scrum Team روی یک Product باید DoD مشترک داشته باشند. Clause باید Applicability، Evidence، Owner و روش اصلاح داشته باشد؛ «همهٔ تست‌ها پاس» بدون تعریف مجموعه و Build شفاف نیست.

DoD clause:
All applicable critical claims for build B have fresh evidence.
Blocked/unknown/tool-failed ≠ pass.
Exception requires owner, reason, expiry and visible residual risk.

Undone Work را Done نام‌گذاری نکنید

طبق Scrum Guide، Itemای که DoD را برآورده نکرده نمی‌تواند Release شود یا در Sprint Review ارائه شود؛ برای بررسی آینده به Product Backlog بازمی‌گردد. درصد انجام‌شده، «Done مشروط» یا پنهان‌کردن تست باقی‌مانده در Sprint بعد Transparency را خراب می‌کند. Scope را می‌توان مذاکره کرد، اما معنای Done را برای رسیدن به Forecast ضعیف نکنید.

Sprint Planning: برنامهٔ رسیدن به Done

Planning سه موضوع Why، What و How دارد. Sprint Goal چرایی ارزشمند Sprint را می‌سازد؛ Developers بر اساس گذشته، Capacity و DoD مقدار قابل‌انجام را Forecast می‌کنند؛ و برنامهٔ Actionable می‌سازند. «زمان تست» یک ضریب ثابت روی Coding نیست. Data، Environment، Review، Automation، Exploration، Non-functional work و Retest بخشی از برنامهٔ Done هستند.

• ریسک‌های تهدیدکنندهٔ Sprint Goal
• Claimهای حیاتی و Oracle آن‌ها
• Dependency و زمان دسترسی به Evidence
• Work split عمودی و امکان Pair/Swarm
• Capacity واقعی، تعطیلی و On-call
• Unknownهای نیازمند Discovery
• Stop/renegotiation trigger

جزئیات این رویداد در راهنمای نقش تستر در Sprint Planning آمده است؛ اینجا فقط Interface آن با Flow Contract را نگه می‌داریم.

Story Point را بین Coding و Testing تقسیم نکنید

Sizing متعلق به Developersی است که کار را انجام می‌دهند و باید کل کار رسیدن Item به Done را منعکس کند. Point جدا برای QA یا مقایسهٔ Velocity افراد، Handoff و بازی عددی می‌سازد. Taskها می‌توانند برای شفافیت برنامه شکسته شوند، اما Forecast به Increment Done مربوط است، نه Utilization تخصص‌ها.

Bad forecast: dev done + QA later
Useful forecast: item reaches shared DoD within Sprint
Capacity is a constraint, not a performance score.

Workflow را برای Flow بسازید، نه Silos

ستون‌های Analysis/Coding/Testing به‌خودی‌خود مشکل نیستند؛ صف بی‌مالک و Push شدن Work مسئله است. Policy هر State، ورودی/خروجی، مالک کار جاری، Evidence و Blocked marker را آشکار کنید. تیم باید روی Finish کردن Itemهای قدیمی Swarm کند، نه اینکه هر تخصص برای پرماندن صف خودش Work تازه باز کند.

DISCOVER → SELECTED → IN_PROGRESS → EVIDENCE_REVIEW → DONE
Every state: entry, exit, WIP policy, blocked reason, age, owner-of-next-action
No hidden WAIT_FOR_QA queue.

WIP، Cycle Time، Throughput و Work Item Age

راهنمای Kanban برای تیم‌های Scrum چهار معیار Flow را معرفی می‌کند: Work in Progress، Cycle Time، Throughput و Work Item Age. این Practiceها Scrum را عوض نمی‌کنند؛ Transparency جریان را بیشتر می‌کنند. آن‌ها را برای گفت‌وگوی سیستم به کار ببرید، نه رتبه‌بندی فرد یا تعهد قراردادی بدون تحلیل توزیع.

WIP = started, not finished items now
Cycle Time = elapsed time from chosen start to finish
Throughput = finished items per observation window
Work Item Age = elapsed time of an unfinished item

Daily Scrum جلسهٔ گزارش وضعیت نیست

Daily Scrum یک Event پانزده‌دقیقه‌ای برای Developers است تا پیشرفت به Sprint Goal را بازرسی و Sprint Backlog را سازگار کنند. قالب سه سؤال اجباری نیست. گزارش «دیروز چند تست زدم» به مدیر، هدف Event را منحرف می‌کند. از راست‌ترین Work نزدیک Done شروع کنید، Age و Blocker را ببینید و برنامهٔ همکاری روز را تغییر دهید.

1. آیا Sprint Goal در خطر است؟
2. کدام Item قدیمی یا Blocked است؟
3. چه Evidence یا Dependency کم است؟
4. چه کسی می‌تواند برای Finish کردن Swarm کند؟
5. چه جزئیاتی را بعد از Timebox با افراد لازم حل می‌کنیم؟

برای الگوی Update و اقدام، راهنمای تستر در Daily Scrum را ببینید.

Collaboration در طول روز، نه فقط Eventها

Scrum Eventها حداقل فرصت‌های رسمی Inspect/Adapt هستند، نه تنها زمان مجاز گفت‌وگو. Example mapping، Pair testing، Three-way review، Debug، Triage و Replanning را هنگام نیاز انجام دهید. منتظر Daily یا Review ماندن، Feedback را کند می‌کند. در عین حال هر گفت‌وگو را Meeting دائمی نکنید؛ تصمیم و Next action را کوتاه ثبت کنید.

Test Design را Just Enough و ریسک‌محور کنید

همهٔ Itemها به سند Test Case یکسان نیاز ندارند. برای Rule پایدار و پرتکرار، Check خودکار مفید است؛ برای Unknown، Charter اکتشافی؛ برای NFR، Quality scenario و Measure؛ برای تغییر ساده، Example و Review ممکن است کافی باشد. سطح Artifact را Risk، تکرار، Audit need، دانش تیم و هزینهٔ نگهداری تعیین می‌کند.

• Claim و Counterexample
• Boundary/State/Permission/Data partition
• Exploratory charter و Timebox
• Automated check در سطح مناسب
• Observability و Production learning بدون دادهٔ حساس
• Known gap و دلیل عدم‌پوشش

اتوماسیون یک Activity است، نه هدف Sprint

«همهٔ Regression را خودکار کنیم» نه Scope دارد، نه Oracle و نه Exit. اتوماسیون برای Feedback سریع و تکرارپذیر مناسب است، اما Maintenance، Flake، Data، Environment و Diagnosis هزینه دارند. Check را در پایین‌ترین سطح معتبر اجرا کنید و Scenarioهای پیچیده، UX و Unknown را با Exploration و Review ترکیب کنید.

automation_candidate:
decision_question + stable_oracle + execution_frequency + failure_cost
+ maintenance_owner + retirement_trigger

CI سبز وقتی Pipeline سالم است

Timeout، skipped test، نبود Agent، خطای Dependency یا عدم‌بارگذاری Report نباید به Pass تبدیل شود. Run را به Commit/Build، Environment، Data revision و Tool version وصل کنید. Flaky check را با Owner و Expiry قرنطینه کنید و Coverage claim را متناسب کاهش دهید؛ Retry-to-green Evidence معتبر نیست.

run_verdict ∈ PASS | FAIL | INCONCLUSIVE | NOT_RUN
pipeline_health ∈ HEALTHY | DEGRADED | FAILED
release evidence requires both result and health context.

محیط و دادهٔ تست را در Flow مرئی کنید

Environment آماده‌نبودن یا Data collision «مشکل QA در آخر Sprint» نیست؛ Dependency جریان است. Build identity، Service version، Feature flag، Dataset lease، Reset، Synthetic-data rule و Availability owner را ثبت کنید. Work منتظر محیط باید Age داشته باشد و تیم دربارهٔ Stub، تغییر ترتیب، کاهش Scope یا Escalation تصمیم بگیرد.

Defect در Scrum: Work شفاف، نه جنگ Severity

Scrum قالب Bug یا Triage تحمیل نمی‌کند. تیم باید Defect را به Build، Expected/Observed، Impact، Evidence و Product Goal وصل کند. Product Owner Ordering را مدیریت می‌کند؛ Developers دربارهٔ کار فنی و Forecast گفت‌وگو می‌کنند؛ و Risk owner بیرونی در صورت نیاز تصمیم Compliance/Release می‌دهد. Reporter نباید به‌خاطر تعداد یا Severity امتیاز بگیرد.

NEW → TRIAGED → ORDERED → IN_PROGRESS → READY_FOR_RETEST → VERIFIED | REOPENED
Decision fields: impact, urgency, scope, owner, evidence, residual risk, expiry

Scope را بدون کاهش کیفیت مذاکره کنید

در طول Sprint، با آموخته‌های تازه Developers و Product Owner می‌توانند Scope دقیق Sprint Backlog را بدون لطمه به Sprint Goal مذاکره کنند. گزینه‌ها شامل کوچک‌کردن Slice، تعویق Variation کم‌ارزش یا انجام Discovery است. حذف آزمون ضروری، تغییر DoD یا نام‌گذاری کار ناقص به Done «انعطاف Agile» نیست.

• چه چیزی دربارهٔ Goal ثابت است؟
• کدام Scope قابل‌مذاکره است؟
• کدام Clause DoD حداقل سازمانی است؟
• چه Risk/Unknownی باقی می‌ماند؟
• چه کسی Decision و Expiry را ثبت می‌کند؟

Sprint Review فقط Demo یا Gate پذیرش نیست

Sprint Review یک Working session برای بازرسی Outcome Sprint و پیشرفت به Product Goal با Stakeholderها و سازگارکردن Product Backlog است. فقط Incrementهای Done ارائه می‌شوند، اما Review به نمایش Happy path یا تأیید QA محدود نیست. Outcome، تغییر محیط، Evidence، Known gap و گزینهٔ بعدی باید گفت‌وگو شوند.

Increment ممکن است پیش از پایان Sprint تحویل شود؛ Review مانع Release ارزش نیست. در سوی دیگر، «در Review پسندیده شد» جای DoD یا Governance انتشار را نمی‌گیرد. برای طراحی جلسه به راهنمای نقش تستر در Sprint Review رجوع کنید.

Sprint Retrospective: از شکایت به Experiment

هدف Retrospective برنامه‌ریزی راه‌های افزایش کیفیت و اثربخشی است. «تست دیر رسید» هنوز علت یا اقدام نیست. Flow data، Timeline و نمونهٔ Item را بررسی کنید؛ Constraint را فرضیه‌سازی کنید؛ یک تغییر کوچک با Owner، Window، Measure، Counter-signal و Exit تعریف کنید. اقدام اثرگذار می‌تواند در Sprint Backlog بعدی قرار گیرد.

Hypothesis: limiting active PBIs may reduce evidence waiting age.
Trial: one Sprint, synthetic board only.
Signals: age distribution + blocked reasons + Sprint Goal outcome.
Decision: KEEP | ADAPT | STOP; no causal claim from one Sprint.

قالب کامل آزمایش در راهنمای Sprint Retrospective از Action Item تا Experiment آمده است.

Release، Done و Sprint سه مفهوم متفاوت‌اند

Done دربارهٔ کیفیت و Usability Increment است؛ Sprint یک Cadence یادگیری؛ Release تصمیم عرضه در Context کسب‌وکار، عملیات و Governance. سازمان ممکن است Approvalهای امنیت، حقوقی یا عملیاتی لازم داشته باشد، ولی باید Interface، SLA و اختیارشان شفاف باشد. Scrum Review را به Change Advisory Board پنهان تبدیل نکنید.

تصمیم	پرسش	Evidence	مالک نمونه
Done	Increment معیار کیفیت را دارد؟	DoD clauses و Build-bound evidence	Developers مطابق DoD
Sprint adaptation	چگونه به Sprint Goal نزدیک شویم؟	Flow، Risk و آموخته	Developers با PO در Scope
Product ordering	بعد چه چیزی ارزشمندتر است؟	Outcome و Stakeholder feedback	Product Owner
Release	آیا اکنون عرضه کنیم؟	Done Increment + context/operations/risk	سیاست مصوب سازمان

Metrics را برای تصمیم طراحی کنید

تعداد Bug، Test Case، Automation percentage و Velocity بدون Construct و Denominator می‌توانند رفتار نامطلوب بسازند. Evidence-Based Management Guide 2024 بر Goal، Hypothesis، Experiment و ارزیابی نتیجه تأکید می‌کند. Metric را به پرسش تصمیم وصل کنید و Confounder و Window را ثبت کنید.

• Flow: WIP، Age، Cycle-time distribution و Blocked time
• Quality: claim coverage، escaped-risk class و reopen
• Feedback: commit-to-signal و finding-to-decision
• Evidence: freshness، inconclusive rate و pipeline health
• Outcome: رفتار/ارزش مورد نظر با Guardrailهای محصول
• People: برای یادگیری سیستم، نه رتبه‌بندی فرد

برای مهاجرت از معیارهای قدیمی، راهنمای معیارهای تست چابک را ببینید.

Evidence Pack سبک برای هر Increment

• Product/Sprint Goal و Item IDs
• Commit/Build/Config/Flag identity
• DoD version و Applicable clauses
• Claim/Scenario و Result چهارحالته
• Run/Review timestamp و Tool health
• Artifact لینک‌شده و Redaction/Retention
• Known gap، Exception، Owner و Expiry
• Review/Release decision receipt در صورت وجود

evidence_pack_id: EP-SYN-08
increment_build: B-SYN-014
dod_version: DOD-SYN-v3
verdict: INCONCLUSIVE
reason: environment fingerprint mismatch

سناریوی ایرانی: Checkout کاملاً مصنوعی

یک تیم خیالی روی Checkout فارسی کار می‌کند. Sprint Goal کاهش ابهام ثبت سفارش تکراری است. داده شامل نام‌های ساختگی، مبلغ فرضی canonical بر حسب IRR، نمایش صریح تومان با نسبت ۱:۱۰، ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیم‌فاصله، RTL/LTR/Bidi و زمان UTC/Asia-Tehran است. هیچ شخص، تیم، Product Backlog، حساب، پرداخت یا Production واقعی وارد آزمایش نمی‌شود.

• Item A: State model و Idempotency claim
• Item B: Unicode/RTL display checks
• Item C: synthetic evidence pipeline
• Dependency: fake local service only
• Unknown: Provider و Release خارج Scope

آزمایش آفلاین SYN-SCRUM-QFLOW-IR-۰۱

آزمایش فقط چهار ردیف ساختگی Board را تحلیل می‌کند. یک Checker سطحی با دیدن ستون QA، عدد ۱۰۰٪ Automation و شعار Zero Bug به‌اشتباه آماده اعلام می‌کند. Checker قراردادمحور Goal، Age، DoD، Evidence و Unknown را می‌سنجد و تا رفع ابهام تصمیم را Hold نگه می‌دارد.

lab_id: SYN-SCRUM-QFLOW-IR-01
network: disabled
people/products/backlogs: fictional
superficial: SCRUM_QA_GATEKEEPER_ZERO_BUG_TEST_PHASE_ALL_AUTOMATION_CEREMONY_READY
contract: HOLD-768

Oracle و Exit آزمایش آموزشی

1. هر Item به Sprint Goal یا دلیل شفاف خارج‌بودن وصل است.
2. State، Age، Blocker و Next action معلوم‌اند.
3. DoD version و Evidence برای Build یکسان‌اند.
4. Unknown، Not-run و Inconclusive به Pass تبدیل نشده‌اند.
5. Metric برای Person score یا تعمیم علّی استفاده نشده است.
6. نتیجه فقط آمادگی Review قرارداد است.

NO_REAL_TEAM_PRODUCT_BACKLOG_PERSON_PERFORMANCE_SCORE_PRODUCTION_RELEASE_OR_ORGANIZATIONAL_DECISION_PASS
READY_FOR_SCRUM_QUALITY_FLOW_REVIEW-0

ضدالگوهای مدیریت تست در Scrum

• QA gate و صف «Ready for Test» در روزهای آخر
• تعریف Done مشروط یا درصدی
• Daily به‌عنوان گزارش به Scrum Master
• Review به‌عنوان Demo و Sign-off
• Refinement به‌عنوان Event اجباری با خروجی بی‌ابهام
• Point جدا برای Coding و Testing
• Velocity یا Bug count برای رتبه‌بندی افراد
• Retry-to-green و پنهان‌کردن Tool failure
• اتوماسیون ۱۰۰٪ بدون Scope/Oracle/Owner
• تغییر DoD برای نجات Forecast
• انتقال Test debt به Sprint بعد بدون Product Backlog
• گفتن «Agile یعنی مستندات نداریم»

برنامهٔ ۳۰ روزه برای اصلاح Flow

1. هفتهٔ اول: Workflow واقعی، Queue، DoD و Decision rights را بدون آرایش ثبت کنید.
2. هفتهٔ دوم: یک Sprint Goal را به Quality questions، Risk و Evidence map وصل کنید.
3. هفتهٔ سوم: WIP/Age و Blocked reason را روی Board مصنوعی یا Pilot محدود مرئی کنید.
4. هفتهٔ چهارم: در Retrospective یک Experiment کوچک را با Baseline، Guardrail و Exit بازبینی کنید.

این Pilot مجوز تغییر ساختار سازمان، ارزیابی افراد یا تصمیم Release نیست. اگر می‌خواهید صرفاً وظایف متخصص QA در رویدادها را مرور کنید، راهنمای نقش QA در Planning، Daily، Review و Retro مقصد دقیق‌تری است.

چک‌لیست Owner برای بازبینی Quality Flow

• نسخهٔ Scrum Guide و اصطلاحات تیم ثبت شده‌اند.
• Accountability با Job title اشتباه نشده است.
• Product/Sprint Goal به Work و Risk وصل است.
• Product Backlog همهٔ کار محصول را شفاف می‌کند.
• DoD قابل‌داوری، نسخه‌دار و مشترک است.
• Undone work به Done یا Review وارد نمی‌شود.
• Workflow، WIP، Age و Blocker مرئی‌اند.
• Daily روی Sprint Goal و Replanning متمرکز است.
• Review Outcome و Adaptation می‌سازد.
• Retro Experiment با Owner/Window/Exit دارد.
• Automation/CI health و Evidence identity روشن‌اند.
• Metric برای تصمیم سیستم است، نه Person score.
• Release، Done و Sprint از هم تفکیک شده‌اند.

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

آیا Scrum نقش جداگانه‌ای به نام Tester یا Test Manager دارد؟

خیر. Scrum Team سه Accountability دارد. متخصص QA که Increment می‌سازد در اصطلاح Guide جزو Developers است. سازمان می‌تواند عنوان شغلی یا مدیر Capability داشته باشد، اما آن را نباید Accountability چهارم یا Gate اجباری Scrum معرفی کند.

Backlog Refinement یکی از پنج Event اسکرام است؟

خیر. پنج Event عبارت‌اند از Sprint، Sprint Planning، Daily Scrum، Sprint Review و Sprint Retrospective. Refinement فعالیتی ongoing برای شکستن و تعریف دقیق‌تر Product Backlog items است و تیم شکل و زمان آن را تعیین می‌کند.

تفاوت Acceptance Criteria و Definition of Done چیست؟

Acceptance Criteria معمولاً مرزها و مثال‌های یک Item خاص را روشن می‌کند؛ DoD معیار کیفیت مشترک Increment است. Criteria جای DoD را نمی‌گیرد و DoD نیز نباید همهٔ Ruleهای اختصاصی هر Item را تکرار کند.

اگر تست در پایان Sprint کامل نشد چه کنیم؟

اگر DoD برآورده نشده، Item Done نیست و وارد Increment/Review نمی‌شود. آن را با وضعیت واقعی به Product Backlog برگردانید، علت Flow را بررسی کنید و در Sprint بعد دوباره Order/Forecast کنید. معنای Done را برای سبزکردن Sprint تغییر ندهید.

بهترین معیار مدیریت تست در Scrum چیست؟

معیار واحدی وجود ندارد. برای سؤال Flow از WIP/Age/Cycle Time، برای کفایت از claim coverage و Evidence freshness، برای Pipeline از health/inconclusive rate و برای محصول از Outcome/Guardrail استفاده کنید. Purpose، denominator، window و محدودیت را ثبت کنید.

جمع‌بندی: کیفیت را در جریان مدیریت کنید

مدیریت تست در Scrum یک مدیر، ستون Board یا جلسهٔ بیشتر نیست؛ قابلیت مشترک دیدن ریسک و حرکت Work تا Increment Done است. Product/Sprint Goal را به Quality question وصل کنید، DoD و Evidence را شفاف نگه دارید، WIP و Age را برای Finish شدن ببینید، رویدادها را به Inspect/Adapt برگردانید و هر بهبود را به‌صورت Experiment محدود بیازمایید. نتیجه، ادعای Zero Bug نیست؛ تصمیمی دقیق‌تر بر پایهٔ واقعیت مشاهده‌شده است.