نقش QA در Scrum؛ راهنمای Planning، Daily، Review و Retro

Story در ستون «Ready for QA» مانده و دو روز تا پایان Sprint باقی است. توسعه‌دهنده کار را تمام‌شده می‌داند، تستر تازه Requirement را می‌بیند و Daily Scrum به گزارش «دیروز/امروز» تبدیل شده است. این مشکل با حضور بیشتر QA در جلسه‌ها حل نمی‌شود؛ جریان کار هنوز Handoff دارد.

نقش QA در Scrum یک Gate یا Sub-team جدا نیست. Scrum اصلاً Accountability مستقلی به نام QA تعریف نمی‌کند. اگر متخصص تست عضو Scrum Team باشد، در واژگان راهنمای Scrum بخشی از Developers است و همراه دیگران برای Increment قابل‌استفاده و مطابق Definition of Done پاسخ‌گوست.

در این راهنما، contribution تخصص تست را در Sprint Planning، Daily Scrum، Sprint Review، Sprint Retrospective و Backlog Refinement با مثال پرداخت فروشگاه بررسی می‌کنیم؛ بدون تحریف هدف رویدادها.

مبنای Scrum: راهنمای رسمی نوامبر ۲۰۲۰، نسخه جاری در تاریخ ۶ اوت ۲۰۲۶.

اصل Whole-team quality: متخصص QA عمق تست، ریسک و مشاهده‌پذیری می‌آورد؛ اما Product Owner، Scrum Master یا Developers دیگر مسئولیت کیفیت را به او واگذار نمی‌کنند. تیم باید همه مهارت‌های لازم برای خلق ارزش در هر Sprint را داشته یا کسب کند.

Scrum درباره نقش QA چه می‌گوید؟

Scrum Guide رسمی سه Accountability را در Scrum Team تعریف می‌کند:

• Product Owner: بیشینه‌کردن ارزش و مدیریت مؤثر Product Backlog؛
• Scrum Master: استقرار Scrum و اثربخشی Scrum Team؛
• Developers: افراد متعهد به ساخت هر جنبه از Increment قابل‌استفاده.

در این راهنما، «Developers» فقط برنامه‌نویس نیست؛ متخصصان لازم برای انجام کار را شامل می‌شود. Tester، Designer، Analyst یا Data specialist اگر عضو Scrum Team باشند زیرعنوان شغلی خود کار می‌کنند، اما Accountability چهارمی در Scrum نمی‌سازند.

مسئولیت کیفیت کجاست؟

کل Scrum Team برای ایجاد Increment ارزشمند و مفید پاسخ‌گوست. Developers باید با رعایت Definition of Done کیفیت را در Increment نهادینه کنند. متخصص QA می‌تواند روش، Coaching و کار تست را عمیق کند؛ نمی‌تواند به‌تنهایی کیفیت را «تضمین» یا نبود باگ را تأیید کند.

رویداد، نه مراسم

Scrum Guide از Events استفاده می‌کند. Sprint رویداد دربرگیرنده است و Sprint Planning، Daily Scrum، Sprint Review و Sprint Retrospective فرصت‌های رسمی Inspection و Adaptation داخل آن‌اند. واژه «مراسم» رایج است، اما هدف رویدادها تکرار تشریفات نیست.

Definition of Done و Acceptance Criteria

مفهوم	دامنه	مثال	مالکیت
Acceptance Criteria	رفتار/شرط یک Product Backlog Item	callback تکراری اثر مالی دوم نسازد	درک مشترک با Product Owner و Team
Definition of Done	توصیف رسمی وضعیت Increment وقتی معیارهای کیفی محصول را برآورده می‌کند	Review، تست لازم، امنیت پایه، Telemetry و Artifact قابل‌انتشار	اگر استاندارد سازمانی نیست، Scrum Team می‌سازد؛ Developers ملزم به رعایت‌اند

Acceptance Criteria جای DoD را نمی‌گیرد و DoD نباید برای هر Story فهرست متفاوتی شود. «Definition of Ready» نیز جزء رسمی Scrum نیست؛ اگر تیم از Checklist آمادگی استفاده می‌کند، نباید به Gate سنگین یا بهانه نیاوردن ابهام به Sprint تبدیل شود.

پیش از Sprint Planning: نقش QA در Backlog Refinement

Backlog Refinement فعالیت مداوم برای شکستن و روشن‌کردن آیتم‌هاست، نه یکی از رویدادهای رسمی Scrum. حضور تخصص تست در این فعالیت از غافلگیری Planning کم می‌کند.

Contribution متخصص QA

• هدف کاربر، Rule، مثال و Counter-example را استخراج کند؛
• Permission، State، Boundary، Dependency و Failure mode را بپرسد؛
• NFR و Testability/Observability لازم را آشکار کند؛
• نیاز Data، Environment، Stub و دسترسی را زود بگوید؛
• ریسک را به کوچک‌سازی یا ترتیب Product Backlog وصل کند؛
• مثال‌های قابل‌اجرا برای Automation/Contract test بسازد.

جلسه «Three Amigos» با Product/Development/Testing یک Practice مفید است، اما Scrum requirement نیست و لازم نیست همیشه سه عنوان شغلی یا جلسه مستقل باشد. هدف، فهم مشترک است. پرسش‌های دقیق را از راهنمای تحلیل نیازمندی بردارید.

قالب Refinement یک Story

هدف کاربر:
Ruleهای مصوب:
مثال‌های موفق/ناموفق:
Risk و اثر:
State/Permission/Data:
NFR:
Dependency:
Testability/Telemetry:
سؤال باز + Decision owner:
کوچک‌سازی پیشنهادی:

نقش QA در Sprint Planning

Sprint Planning برای آغاز Sprint و ساخت Sprint Backlog است. راهنمای Scrum سه موضوع را پوشش می‌دهد: چرا Sprint ارزشمند است، چه کاری می‌تواند انجام شود و کار انتخاب‌شده چگونه انجام خواهد شد. QA گزارش تلاش تست جدا تحویل نمی‌دهد؛ همراه Developers Plan می‌سازد.

موضوع ۱: چرا این Sprint ارزشمند است؟

تخصص تست کمک می‌کند Sprint Goal پیامد و Risk را نیز ببیند. مثال ضعیف: «پیاده‌سازی درگاه جدید». مثال بهتر: «کاربر واجد شرایط بتواند پرداخت را بدون ایجاد Order تکراری کامل کند و تیم امکان Rollback کنترل‌شده داشته باشد.»

موضوع ۲: چه کاری قابل انجام است؟

• ابهام و Dependency مهم را شفاف کنید؛
• ظرفیت کار تست/داده/محیط/Automation را داخل کار ببینید؛
• Story بسیار بزرگ یا غیرقابل‌آزمون را کوچک کنید؛
• Risk پراثر را جلوتر یا با Spike کاهش دهید؛
• کار غیرکارکردی را نامرئی نگذارید.

موضوع ۳: چگونه انجام می‌شود؟

Developers به‌اندازه لازم Plan می‌کنند: Example review، Unit/Component/API/UI، Test data، Pairing، Feature flag، Monitoring و Rollback. همه جزئیات آینده قابل‌پیش‌بینی نیست؛ Sprint Backlog در طول Sprint تطبیق می‌یابد.

خروجی کیفیت در Planning

• Sprint Goal با معیار مشاهده‌پذیر؛
• Riskهای اصلی و Unknownها؛
• Taskهای Testability، Data و Environment؛
• Test approach در لایه مناسب؛
• Dependency و Owner پیگیری؛
• DoD مشترک و Exceptionهای ممنوع.

یک Test Plan سبک می‌تواند داخل Sprint Backlog یا Story باشد؛ قالب تصمیم‌محور در راهنمای برنامه تست آمده است.

مثال Planning: پرداخت و callback

Risk	Slice/کار	Evidence	DoD-related
callback تکراری	Idempotency guard + component tests	یک اثر مالی و State invariant	تست خودکار و Review
Sandbox ناپایدار	Contract stub + health check	Stub scenarios و یک Sandbox run	Dependency evidence
مبلغ ناهماهنگ	Server-side validation	API negative tests و audit log	Security/observability
Rollout خطرناک	Feature flag + monitoring	Dashboard و kill procedure	Operational readiness

اگر تیم فقط «توسعه» را Estimation کند و تست/Telemetry را بعداً اضافه کند، Forecast واقعی نیست. Story زمانی Done است که DoD را برآورده کند، نه وقتی وارد ستون QA شد.

نقش QA در Daily Scrum

Daily Scrum رویداد ۱۵دقیقه‌ای برای Developers است تا پیشرفت به‌سوی Sprint Goal را بررسی و Sprint Backlog را در صورت نیاز تطبیق دهند. سه سؤال «دیروز/امروز/مانع» در نسخه جاری Scrum اجباری نیستند و Daily جلسه گزارش وضعیت به Scrum Master نیست.

به‌جای گزارش فعالیت، جریان و هدف را مطرح کنید

گزارش کم‌ارزش: «دیروز ۱۲ Test Case اجرا کردم، امروز بقیه را می‌زنم.»

گزارش تصمیم‌پذیر: «Risk callback تکراری هنوز Evidence ندارد چون Stub فقط پاسخ موفق می‌دهد. این کار Sprint Goal را تهدید می‌کند. امروز با Backend حالت duplicate را اضافه می‌کنیم؛ اگر تا ظهر آماده نشد، Scope Review و Flag rollout را تطبیق می‌دهیم.»

موضوع‌های مناسب

• آیا Sprint Goal از Risk یا Blocker تهدید می‌شود؟
• کدام PBI WIP مانده و چگونه Pair/Swarm کنیم؟
• آیا Fail از Product، Test، Data یا Environment است؟
• چه Planی امروز باید تغییر کند؟
• کدام گفت‌وگوی عمیق را بعد از Daily با افراد لازم ادامه دهیم؟

موضوع‌های نامناسب برای طولانی‌کردن Daily

• Triage کامل همه Bugها؛
• Debug فنی جزئی؛
• گزارش فردی برای مدیر؛
• حل تمام اختلاف Requirement؛
• خواندن Dashboard بدون تصمیم.

Daily مشکل را شفاف و Coordination را تحریک می‌کند؛ خودش محل حل همه مشکل نیست.

بین رویدادها؛ جایی که کیفیت واقعاً ساخته می‌شود

• QA و Developer روی Example/Code/Test Pair کنند؛
• تست نزدیک کد و API هم‌زمان با Feature ساخته شود؛
• Product owner سؤال Rule را سریع پاسخ دهد؛
• Test data و Environment مالک مشترک داشته باشند؛
• CI بازخورد کوچک و قابل‌تشخیص بدهد؛
• تست اکتشافی روی Risk تازه انجام شود؛
• Telemetry و Rollback پیش از پایان آماده شوند.

Scrum Events جای همکاری روزانه را نمی‌گیرند. جریان فنی را با اصول تست چابک و Laneهای تست مستمر پیوند دهید.

نقش QA در Sprint Review

Sprint Review برای بررسی Outcome Sprint و تعیین Adaptationهای آینده با Stakeholderهاست. این رویداد فقط Demo یا ارائه PowerPoint نیست و نباید Release gate یا جلسه «تأیید QA» باشد.

Contribution متخصص QA

• Scenario واقعی و محدودیت را در Increment نشان دهد؛
• شواهد کیفیت، Risk و رفتار تحت اختلال را قابل‌فهم کند؛
• Scope تست‌نشده و Unknownها را پنهان نکند؛
• Feedback Stakeholder را به Risk/Backlog idea تبدیل کند؛
• داده Production/experiment مرتبط را در Context قرار دهد.

چه چیزی ارائه نشود؟

کاری که Definition of Done را برآورده نکرده Increment نیست. آن را برای ساخت تصویر غلط از «کار تمام‌شده» ارائه نکنید. می‌توان درباره یادگیری، Prototype یا کار ناتمام شفاف گفت‌وگو کرد، اما برچسب Increment Done نباید تحریف شود.

نمونه Evidence برای Review پرداخت

• Journey پرداخت موفق با داده مصنوعی؛
• نمایش callback duplicate و یک اثر مالی؛
• رفتار Slow network و Retry؛
• Trend محدود Latency و Error در محیط شناخته‌شده؛
• Feature flag، Monitoring و Risk خارج Scope؛
• سؤال برای Stakeholder: اولویت Wallet guest یا بهبود Recovery؟

Pass Rate یا Test count «اطمینان خاطر» عمومی نمی‌سازد. شواهد باید به Outcome، Risk و تصمیم Product Backlog وصل باشد.

Release و Sprint Review یک چیز نیستند

در Scrum می‌توان چند Increment در Sprint ساخت و Increment ممکن است پیش از پایان Sprint تحویل شود. Sprint Review Gate انتشار نیست. Release policy، ریسک، Compliance، Operations و بازار می‌توانند cadence متفاوت داشته باشند.

اگر سازمان به Sign-off یا Change approval نیاز دارد، آن را شفاف با Scrum هماهنگ کنید؛ QA را به امضای نمادین آخر Sprint تبدیل نکنید.

نقش QA در Sprint Retrospective

هدف Retrospective برنامه‌ریزی راه‌هایی برای افزایش کیفیت و اثربخشی است. Scrum Team بررسی می‌کند Sprint از نظر افراد، تعامل‌ها، فرایندها، ابزارها و DoD چگونه پیش رفت و مفیدترین تغییرها را انتخاب می‌کند.

داده‌ای که به یادگیری کمک می‌کند

• p50/p95 زمان تا Feedback؛
• Blocked/Invalid و علت؛
• Flaky trend و زمان بازیابی؛
• Defect aging و زمان Triage؛
• Incident/escape با Timeline و Impact؛
• WIP و زمان انتظار ستون Ready for QA؛
• Riskهایی که دیر دیده شدند.

تعداد Bug به‌ازای Tester یا Developer برای رتبه‌بندی مناسب نیست. اصول متریک منصفانه در راهنمای متریک‌های QA آمده است.

از مشکل به آزمایش

مشاهده: سه Story در دو روز آخر وارد QA شدند.
فرضیه: Batch و Handoff باعث Feedback دیر شده است.
آزمایش Sprint بعد: Story به Slice کوچک‌تر؛ Pair روی اولین Slice؛ WIP limit یک آیتم در Ready-for-test.
Signal: p95 زمان از first commit تا first reliable feedback.
Guardrail: پوشش Risk حیاتی و زمان Pairing.

Action باید مالک، موعد و نقطه بازبینی داشته باشد. فهرست ده اقدام بدون پیگیری، یادگیری نیست.

مثال End-to-end یک Story در رویدادهای Scrum

نقطه	Inspection	Adaptation	Contribution تست
Refinement	Rule callback و Risk	Story split + Stub need	مثال، State، NFR
Planning	Sprint Goal و ظرفیت	کار Idempotency جلوتر	Test approach/DoD
Daily	Stub مانع Evidence	Swarm Backend+QA	Risk signal
Review	Outcome و feedback ذی‌نفع	Recovery UX وارد Backlog	Scenario و limitations
Retro	Feedback دیر روی Slow network	Network profile در CI smoke	آزمایش و Guardrail

Anti-patternهای QA در Scrum

ستون «Ready for QA» به‌عنوان صف پایان

یک State کوتاه برای Visibility ممکن است مفید باشد؛ اما اگر Storyها روزها منتظر یک نفر بمانند، Sub-team و Bottleneck ساخته‌اید. Pair، WIP limit، Skill sharing و Slice کوچک‌تر را امتحان کنید.

QA Gatekeeper کیفیت

متخصص تست شواهد و Risk می‌دهد؛ کل تیم DoD را رعایت می‌کند. Gatekeeper باعث می‌شود دیگران Testability و Quality را کار «بعدی» بدانند.

Daily به گزارش تعداد تست تبدیل می‌شود

Activity count به Sprint Goal وصل نیست. تهدید هدف، Plan adaptation و کمک لازم را مطرح کنید.

Sprint Review به Demo سبز تبدیل می‌شود

فقط Happy path و اسلاید Pass rate، Transparency را کم می‌کند. Risk، محدودیت و feedback واقعی را وارد Working session کنید.

Retrospective به مقصریابی Bug فراری تبدیل می‌شود

Timeline و Decision context را بررسی کنید. «خطای انسانی» نقطه پایان علت نیست. اقدام سیستمی با Owner بسازید.

DoD با ۱۰۰٪ Pass یا Zero bug

این اعداد بدون Scope و Risk معنا ندارند و قابل‌بازی‌اند. DoD باید کیفیت لازم برای Increment و Product را توصیف کند، نه وعده بی‌نقصی.

Automation یک Backlog جدا و همیشگی

اگر Automation لازم برای Done بودن رفتار است، داخل Plan همان کار بیاید. Platform improvement بزرگ می‌تواند PBI جدا داشته باشد، اما نباید همیشه پشت Feature delivery بماند.

الگوهای سیستمی بیشتر در ۱۲ اشتباه رایج تست نرم‌افزار آمده‌اند.

تیم توزیع‌شده و ملاحظات ایران

• زمان رویدادها با منطقه زمانی، تعطیلی و ساعات انرژی/اینترنت تیم سازگار باشد؛
• Decision و Risk به‌صورت Async و مکتوب نیز ثبت شوند؛
• اصطلاح فارسی/انگلیسی Requirement یک Glossary مشترک داشته باشد؛
• Demo با حساب و شماره مصنوعی و Sandbox انجام شود؛
• برای ابزار خارجی، Export و کانال جایگزین داشته باشید؛
• قطعی سرویس/درگاه به‌عنوان Risk و Dependency دیده شود، نه «تنبلی QA»؛
• رویدادها برای کنترل حضور استفاده نشوند؛ Outcome و Adaptation مهم‌اند.

چک‌لیست Contribution متخصص QA

Refinement

• مثال، Counter-example، Risk، NFR و Testability روشن‌اند.
• سؤال باز Decision owner دارد.

Planning

• Sprint Goal اثر/ریسک قابل‌مشاهده دارد.
• Data، Environment، Automation و Monitoring در Plan هستند.
• DoD فهم مشترک دارد.

Daily Scrum

• گزارش به Sprint Goal و Adaptation وصل است.
• Blocker کیفیت صاحب کمک و گفت‌وگوی بعدی دارد.

Sprint Review

• Increment Done، Outcome، Evidence و Limitation شفاف‌اند.
• Feedback به Adaptation Product Backlog کمک می‌کند.

Retrospective

• داده برای یادگیری تیمی است، نه رتبه‌بندی فرد.
• یک یا دو آزمایش دارای Owner/Signal/Guardrail انتخاب شده‌اند.

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

آیا Scrum نقش رسمی QA یا Tester دارد؟

خیر. Scrum سه Accountability دارد: Developers، Product Owner و Scrum Master. متخصص تست می‌تواند عضو Developers باشد و تخصص QA ارائه کند؛ کیفیت مسئولیت یک Sub-team جدا نیست.

آیا QA باید در همه رویدادهای Scrum شرکت کند؟

اگر عضو Scrum Team/Developers است، در رویدادهای مرتبط تیم مشارکت می‌کند و Daily Scrum مشخصاً برای Developers است. هدف حضور، Inspection/Adaptation است؛ جلسه‌ای که هیچ تصمیم یا همکاری نمی‌سازد باید از نظر اجرا اصلاح شود.

QA در Daily Scrum چه گزارشی بدهد؟

تهدید Sprint Goal، وضعیت Evidence، Blocker و تغییر Plan لازم را مطرح کند؛ نه گزارش تعداد Test Case به مدیر. Debug یا Triage طولانی بعد از Daily با افراد لازم ادامه یابد.

آیا Sprint Review محل تأیید QA برای Release است؟

خیر. Review برای بررسی Outcome و Adaptation آینده با Stakeholderهاست. Increment باید DoD را برآورده کند، اما Review Release gate نیست و QA مالک یگانه پذیرش ریسک نیست.

فرق Sprint Review و Retrospective چیست؟

Review روی Outcome محصول، شرایط و Adaptation آینده Product Backlog تمرکز دارد و Stakeholderها مشارکت می‌کنند. Retrospective روی کیفیت و اثربخشی روش کار Scrum Team و بهبود Sprint بعدی تمرکز دارد.

جمع‌بندی

نقش QA در Scrum با «حضور در همه مراسم» تعریف نمی‌شود؛ با بهترکردن Transparency، Inspection و Adaptation تعریف می‌شود. در Refinement ریسک و مثال را روشن کنید، در Planning کیفیت را داخل Plan بیاورید، در Daily به Sprint Goal کمک کنید، در Review شواهد و محدودیت را با Outcome پیوند دهید و در Retro یک آزمایش قابل‌پیگیری بسازید. تخصص تست عمیق است، اما پاسخ‌گویی برای Increment Done متعلق به تیم است.