تست چابک چیست؟ اصول Agile Testing و نقش QA در اسپرینت

اگر ستون Story بعد از «توسعه» وارد ستون «QA» شود و دو روز آخر Sprint همه منتظر تستر بمانند، تیم فقط یک آبشار کوچک ساخته است. تست چابک به معنای سریع‌تر دویدن تیم QA نیست؛ یعنی کیفیت از کشف نیاز تا کدنویسی، بررسی، انتشار و بازخورد واقعی در کار کل تیم جریان داشته باشد.

در این راهنما می‌بینید Agile Testing دقیقاً چیست، تستر در Scrum چه جایگاهی دارد، Acceptance Criteria با Definition of Done چه تفاوتی دارد، چهار Quadrant چگونه به برنامه‌ریزی کمک می‌کنند و یک User Story از Refinement تا Production چگونه آزموده می‌شود. مرز این مقاله با Continuous Testing نیز روشن می‌ماند: اینجا مدل کار و مسئولیت کیفیت را می‌سازیم؛ آنجا Pipeline و اجرای پیوسته را عمیق می‌کنیم.

تست چابک یا Agile Testing چیست؟

Agile Testing مجموعه‌ای از ذهنیت‌ها و فعالیت‌های تست است که با توسعه تکاملی، همکاری نزدیک، تحویل کوچک و بازخورد سریع هماهنگ می‌شود. تست یک فاز پس از Coding نیست؛ از مثال‌سازی و تحلیل ریسک آغاز می‌شود، در ساخت و Integration ادامه دارد و با مشاهده رفتار محصول پس از انتشار کامل‌تر می‌شود.

ارزش‌های مانیفست Agile بر افراد و تعامل، نرم‌افزار در حال کار، همکاری با مشتری و پاسخ به تغییر تأکید دارند. این ارزش‌ها به معنای حذف Process، Documentation، Contract یا Plan نیستند؛ موارد سمت راست همچنان ارزش دارند، اما موارد سمت چپ در اولویت‌اند.

در تست چابک، خروجی مطلوب «تعداد Test Case اجراشده» نیست؛ اطلاعات سریع و قابل اعتماد درباره ریسک، ارزش و آمادگی Increment است.

تست در Agile چه تفاوتی با مدل فازی دارد؟

این مقایسه به معنای بی‌برنامگی نیست. تست چابک همچنان به Strategy، Risk، Environment، Data، Evidence و Traceability نیاز دارد؛ فقط آن‌ها را به‌اندازه تصمیم و به‌صورت تکاملی نگه می‌دارد.

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

در Scrum Guide 2020 سه Accountability تعریف شده است: Product Owner، Scrum Master و Developers. عنوان شغلی Tester ممنوع نیست؛ اما Scrum یک زیرتیم مستقل QA یا مرحله تحویل به Tester تعریف نمی‌کند. افرادی با تخصص تست بخشی از Developers هستند، یعنی کسانی که هر جنبه لازم برای Increment قابل استفاده را انجام می‌دهند.

راهنمای Scrum می‌گوید کل Scrum Team برای ساخت Increment ارزشمند و مفید پاسخ‌گوست و Developers باید با پایبندی به Definition of Done کیفیت را در کار وارد کنند. بنابراین:

• کیفیت فقط وظیفه تستر نیست؛
• داشتن تستر متخصص همچنان ارزشمند است؛
• توسعه‌دهنده نمی‌تواند کیفیت را «به QA تحویل دهد»؛
• تستر هم نباید تنها Gate یا مالک تمام تست‌ها باشد؛
• مهارت تخصصی امنیت، Performance یا Accessibility در صورت نیاز باید وارد تیم یا در دسترس آن باشد.

این همان Whole-Team Approach است که در ISTQB CTFL v4.0.1 نیز تشریح شده: هر عضو دارای دانش و مهارت لازم می‌تواند Task را انجام دهد و همه برای کیفیت مسئول‌اند.

نقش تستر در تیم Agile چیست؟

تستر چابک فقط آخرین اجراکننده سناریو نیست. بسته به Context، این مسئولیت‌ها را بر عهده می‌گیرد یا تسهیل می‌کند:

• پرسیدن سؤال‌های ریسک و Testability در Refinement؛
• تبدیل ابهام به Example و Acceptance Criteria قابل مشاهده؛
• طراحی Test Approach در لایه مناسب؛
• Pairing با Developer برای Component/API/UI Test؛
• اجرای Exploratory Testing و کشف Unknownها؛
• بررسی NFRها مانند امنیت، Performance و Usability؛
• بهبود Test Data، Environment و Observability؛
• تحلیل شکست CI و سلامت Suite؛
• بیان ریسک با شواهد برای تصمیم Product؛
• مربی‌گری کیفیت بدون تبدیل‌شدن به پلیس فرایند.

تخصص تستر در مدل‌سازی ریسک، طراحی تست، مشاهده رفتار و سؤال‌سازی است؛ Automation یکی از ابزارهای اوست، نه تعریف کامل نقش.

Acceptance Criteria و Definition of Done چه تفاوتی دارند؟

Definition of Done طبق Scrum، توصیف رسمی وضعیت Increment هنگام برآوردن معیارهای کیفیت محصول است. «QA Approved» به‌تنهایی DoD مفیدی نیست؛ باید معیار قابل مشاهده باشد. Acceptance Criteria نیز تمام Testing را جایگزین نمی‌کند؛ Tester هنوز Boundary، Failure Mode و ریسک‌های کشف‌نشده را بررسی می‌کند.

تست در چرخه یک User Story

قبل از Refinement

Product داده مشتری، هدف و محدودیت را آماده می‌کند. Tester شکایت‌ها، Incident، Analytics و ریسک‌های مشابه را مرور می‌کند. اگر Story بسیار بزرگ یا غیرقابل مشاهده است، قبل از Planning شکسته می‌شود.

در Refinement؛ گفت‌وگوی سه‌نفره

Product، Developer و Tester با Exampleهای مشخص رفتار را روشن می‌کنند. این الگو گاهی Three Amigos نامیده می‌شود؛ هدف جلسه رسمی ثابت نیست، بلکه ترکیب دید کسب‌وکار، ساخت و آزمون است. خروجی می‌تواند Example Map، Acceptance Criteria، سؤال باز و Test Note باشد.

در Sprint Planning

تیم فقط Coding را برآورد نمی‌کند. Data، Environment، Automation، Exploratory Session، NFR، Review و Deployment بخشی از کار Story هستند. Storyای که تست آن به Sprint بعد موکول شود هنوز Done نیست.

هنگام توسعه

Developer تست‌های Unit/Component را نزدیک کد می‌نویسد؛ Tester و Developer روی API یا UI Pair می‌کنند؛ Product Example مبهم را پاسخ می‌دهد. تغییر کوچک زود Merge و در CI ارزیابی می‌شود.

پس از Build؛ نقد محصول

Exploratory Testing، Usability، Compatibility و Failure Scenarioها فراتر از Checkهای ازپیش‌نوشته‌شده انجام می‌شوند. تستر به‌دنبال اطلاعات جدید است، نه فقط تأیید Exampleهای آشنا.

پیش از Done و انتشار

تیم Evidence را با Acceptance Criteria و DoD مقایسه می‌کند، ریسک باقی‌مانده را بیان و Rollout/Monitoring را آماده می‌کند. Sprint Review نباید به Gate اجباری انتشار تبدیل شود؛ Scrum Guide اجازه می‌دهد Increment قابل استفاده پیش از پایان Sprint نیز تحویل شود.

پس از انتشار

Metric، Log، Support Ticket، رفتار کاربر و Incident به Backlog و Strategy تست برمی‌گردند. این Shift-right جای تست پیش از انتشار را نمی‌گیرد؛ منبع بازخورد واقعی دیگری اضافه می‌کند.

مثال عملی؛ Story بازپرداخت در فروشگاه ایرانی

User Story: به‌عنوان کارشناس پشتیبانی می‌خواهم مبلغ سفارش پرداخت‌شده را کامل یا جزئی بازپرداخت کنم تا درخواست مشتری بدون عملیات دستی بانکی پیگیری شود.

سؤال‌های Refinement

• بازپرداخت چندمرحله‌ای مجاز است و مجموع آن چگونه کنترل می‌شود؟
• واحد مبلغ ریال است یا تومان و منبع حقیقت کدام است؟
• سفارش لغوشده، برگشت‌خورده یا دارای اختلاف پرداخت چه رفتاری دارد؟
• Retry پس از Timeout درگاه چگونه از بازپرداخت تکراری جلوگیری می‌کند؟
• چه Roleهایی مجازند و سقف اختیار هر نقش چیست؟
• کاربر چه وضعیت و زمان تقریبی می‌بیند؟
• Audit Log، Reconciliation و Alert چه نیازهایی دارند؟

Acceptance Criteria نمونه

Given سفارش 1,000,000 ریال پرداخت موفق دارد
And قبلاً 300,000 ریال بازپرداخت شده
When کارشناس مجاز درخواست 700,000 ریال ثبت می‌کند
Then درخواست یک‌بار پذیرفته می‌شود
And مجموع بازپرداخت از مبلغ پرداختی بیشتر نمی‌شود
And وضعیت قابل رهگیری و رویداد حسابرسی ثبت می‌شود

Given همان درخواست با همان Idempotency Key تکرار می‌شود
When پاسخ اول برای کاربر Timeout شده است
Then بازپرداخت دوم ساخته نمی‌شود
And نتیجه درخواست قبلی قابل بازیابی است

Test Approach در Sprint

• Unit Test برای محاسبه سقف و State Transition؛
• Component/API Test برای Authorization، Idempotency و DB؛
• Contract/Sandbox Test برای پاسخ‌های درگاه؛
• Exploratory Session برای Race، Retry و پیام‌های مبهم؛
• Security Review برای Role و مالکیت سفارش؛
• Performance Check برای Queue کمپین؛
• Monitoring و Reconciliation پس از Rollout محدود.

در این مدل، «تست» یک Task پایانی نیست؛ چند Feedback Loop متناسب با ریسک است.

چهار Quadrant تست چابک

Agile Testing Quadrants ابتدا توسط Brian Marick مطرح و بعد توسط Lisa Crispin و Janet Gregory گسترش یافت. این مدل یک ابزار گفت‌وگو برای دیدن نوع‌های مختلف Test است، نه چهار مرحله، نه ترتیب اجرا و نه چک‌لیست اجباری.

یک Test ممکن است مرز دو Quadrant را لمس کند. هدف مدل این است که تیم فقط به Unit یا Acceptance Check اکتفا نکند و هم «راهنمای ساخت» و هم «نقد نتیجه» را ببیند.

تست اکتشافی در Agile

Automation برای Regression شناخته‌شده عالی است؛ اما Unknownها را به‌تنهایی کشف نمی‌کند. Exploratory Testing یادگیری، طراحی و اجرا را هم‌زمان می‌کند و برای تغییرهای سریع، جریان‌های جدید و ریسک‌های ترکیبی مناسب است.

یک Session کوتاه با Charter مشخص، داده، Note و Debrief قابل برنامه‌ریزی است. مثال Charter: «بازپرداخت را زیر Timeout، Retry، تغییر Role و دو درخواست هم‌زمان بررسی کن؛ تمرکز بر تکرار عملیات و ابهام وضعیت.» برای ساختار کامل، مقاله تست اکتشافی ساختاریافته را ببینید.

نقش اتوماسیون در تست چابک

اتوماسیون هدف نیست؛ زیرساخت Feedback است. Test Suite باید در لایه‌ای نوشته شود که سریع، پایدار و قابل تشخیص باشد:

• Checkهای کوچک و نزدیک کد برای بازخورد Pull Request؛
• API/Component برای منطق و Integration بدون هزینه UI؛
• تعداد هدفمند UI برای سفرهای اصلی؛
• Contract برای تغییر سرویس‌ها؛
• NFRهای زمان‌بندی‌شده یا Gate متناسب با هزینه؛
• Production Check و Monitoring برای فرض‌های قابل مشاهده.

هر Story نباید الزاماً Test UI جدید بسازد. کاندیدا و لایه را با معیارهای انتخاب تست مناسب برای اتوماسیون تعیین کنید. Flaky Test که اعتماد تیم را کم کند برخلاف هدف Agile است، حتی اگر Coverage ظاهری را بالا ببرد.

Agile Testing و DevOps چه رابطه‌ای دارند؟

Agile Testing بیشتر روی همکاری تیم، ساخت تکاملی و بازخورد کیفیت تمرکز دارد. DevOps مرز توسعه، عملیات و تحویل را گسترش می‌دهد و Automation، Infrastructure، Observability و عملیات را وارد حلقه می‌کند. این دو هم‌پوشان‌اند اما مترادف نیستند.

در DevOps، Feedback Test در CI/CD، محیط تکرارپذیر، Feature Flag، Canary، Telemetry و Incident Learning جریان می‌یابد. جزئیات Pipeline و Gateها در مقاله Continuous Testing در DevOps بررسی می‌شود.

Shift-left و Shift-right بدون افراط

Shift-left

فعالیت کیفیت را زودتر می‌آورد: Review Example، Static Analysis، Unit/Component Test، Threat Modeling و Testability. معنای آن انتقال تمام کار QA به Developer یا حذف System Test نیست.

Shift-right

بازخورد پس از انتشار را اضافه می‌کند: Monitoring، Synthetic Check، Canary، Feature Experiment و Incident Analysis. معنای آن تست‌کردن بی‌ملاحظه روی کاربران یا جایگزینی Pre-release Testing نیست.

بهترین حلقه، داده راست را به تصمیم چپ برمی‌گرداند: Incident یک Failure Mode جدید می‌سازد، تست مناسب اضافه می‌شود و معماری یا DoD اصلاح می‌شود.

مدیریت تست در Sprint

برای جزئیات برنامه‌ریزی، ظرفیت، Board و گزارش‌دهی، مقاله مدیریت تست در Scrum را بخوانید. در سطح Story این قواعد ساده مفیدند:

• Test Task جدا برای کار نامرئی ولی واقعی بسازید؛
• WIP را محدود کنید تا Storyهای نیمه‌تست‌شده جمع نشوند؛
• Developer و Tester زود Pair کنند، نه پس از «Dev Done»؛
• Blocked Environment و Data روی Board قابل مشاهده باشند؛
• Bug جدید را با اثر بر Sprint Goal و ریسک اولویت دهید؛
• Story فقط با DoD مشترک Done شود؛
• Carry-over را با علت ریشه‌ای در Retrospective بررسی کنید.

متریک‌های مفید برای کیفیت چابک

Metric باید گفت‌وگو و تصمیم را بهتر کند، نه افراد را رتبه‌بندی کند:

• Feedback Time: زمان تغییر تا نتیجه قابل اعتماد؛
• Cycle Time تا Done: شامل انتظار برای Test و Fix؛
• Escaped Defect/Incident Impact: اثر نقص‌های گریخته، نه فقط تعداد؛
• Change Failure Rate: سهم تغییرهایی که به اختلال یا اصلاح فوری منجر می‌شوند؛
• Flaky Rate و Quarantine Age: سلامت Feedback خودکار؛
• Time to Detect/Restore: سرعت دیدن و بازیابی مشکل؛
• Reopen Rate: کیفیت تشخیص و اصلاح؛
• Customer/Task Outcome: نتیجه واقعی کاربر پس از تغییر.

Pass Rate خام، تعداد Bug و تعداد Test Case به‌تنهایی می‌توانند رفتار ناسالم ایجاد کنند. Story پیچیده با ده تست ممکن است پرریسک‌تر از Story دارای صد Check باشد.

ضدالگوهای رایج Agile Testing

• Mini-waterfall: Analysis، Dev و QA همچنان صف‌های جدا هستند.
• QA Sprint: تست Storyهای Sprint قبل در Sprint بعد انجام می‌شود.
• Automation Theater: درصد Automation بالا اما Suite کند و Flaky است.
• Acceptance Criteria به‌جای Testing: فقط Exampleهای نوشته‌شده اجرا می‌شوند و Exploration حذف می‌شود.
• No Documentation: تصمیم، Risk و Contract به نام Agile ثبت نمی‌شوند.
• Bug Count KPI: تستر برای یافتن عدد بیشتر و Developer برای پنهان‌کردن عدد انگیزه می‌گیرد.
• QA Gate: همه منتظر امضای یک نفرند و مسئولیت مشترک از بین می‌رود.
• Definition of Done مبهم: «تست شد» بدون نوع، Evidence یا معیار.
• Retest بدون Regression: Fix بررسی می‌شود ولی اثر جانبی نه.
• Shift-left شعاری: مسئولیت به چپ هل داده می‌شود اما Testability و زمان ساخته نمی‌شود.

چالش‌های تیم‌های ایرانی

• دسترسی ابزار و Cloud: Runner، Package و Artifact داخلی یا قابل بازیابی طراحی کنید.
• محیط مشترک: Data یکتا، Namespace و Environment-on-demand اصطکاک Sprint را کم می‌کند.
• درگاه و پیامک: Sandbox/Stub با Timeout، Retry و Callback واقعی‌نما بسازید.
• تیم دورکار: Example، Risk و تصمیم را در Artifact کوتاه و قابل جست‌وجو ثبت کنید.
• فارسی و Context: RTL، ریال/تومان، تقویم شمسی، عدد فارسی/لاتین و شبکه موبایل را در Refinement بیاورید.
• کمبود تخصص: Security، Performance و Accessibility را دیر به تیم بیرونی پرتاب نکنید؛ Review و Pairing دوره‌ای بگیرید.
• فشار Deadline: Scope را کاهش دهید، نه اینکه DoD را بی‌صدا دور بزنید؛ ریسک پذیرفته‌شده را ثبت کنید.

چک‌لیست Agile Testing برای هر Story

• ارزش، کاربر و Outcome Story روشن است.
• Exampleهای مثبت، منفی و مرزی با Product و Developer مرور شده‌اند.
• ریسک‌های Functional و Non-functional مشخص‌اند.
• Acceptance Criteria قابل مشاهده و بدون راه‌حل‌نویسی اضافی‌اند.
• Testability، Data، Environment و Dependency آماده‌اند.
• Test Approach در لایه مناسب انتخاب شده است.
• کار Unit/Component/API/UI/Exploratory در Sprint دیده می‌شود.
• Automation بر اساس ارزش و نگهداری انتخاب شده است.
• Failure Artifact و روش تشخیص آماده‌اند.
• Story به صف QA در انتهای Sprint منتقل نمی‌شود.
• DoD مشترک و معیار انتشار با هم اشتباه نشده‌اند.
• ریسک باقی‌مانده پیش از انتشار بیان شده است.
• Monitoring، Rollback و Feedback پس از انتشار تعریف شده‌اند.
• یادگیری Incident و Retrospective به Backlog برمی‌گردد.

جمع‌بندی

تست چابک یعنی کوتاه‌کردن فاصله میان سؤال، تغییر و بازخورد. مسئولیت مشترک کیفیت، تخصص تستر را حذف نمی‌کند؛ آن را از ایستگاه نهایی به سراسر جریان محصول می‌برد. Exampleهای خوب، Testability، Automation پایدار، Exploration و Observability هرکدام نوع متفاوتی از عدم قطعیت را کم می‌کنند.

برای شروع، یک Story جاری را انتخاب کنید و به‌جای تحویل به QA، پیش از Coding جلسه کوتاه Product/Developer/Tester برگزار کنید. Example، ریسک، DoD و Test Approach را روشن کنید؛ سپس زمان انتظار تا Feedback را اندازه بگیرید. همین حلقه کوچک، از تغییر نام Ceremonyها مؤثرتر است.

سوالات متداول درباره تست در Agile

تست چابک چیست؟

رویکردی به تست است که با توسعه تکاملی و تحویل کوچک هماهنگ می‌شود. فعالیت کیفیت از Refinement آغاز و در کدنویسی، Integration، Exploration، انتشار و بازخورد Production ادامه پیدا می‌کند.

آیا در Scrum نقش QA وجود ندارد؟

Scrum عنوان رسمی QA را به‌عنوان Accountability جدا تعریف نمی‌کند، اما افراد دارای تخصص تست می‌توانند عضو Developers باشند. کل Scrum Team برای Increment ارزشمند پاسخ‌گوست و تخصص تست همچنان برای تحلیل ریسک و کشف کیفیت ضروری است.

آیا در Agile همه تست‌ها باید خودکار شوند؟

خیر. Checkهای تکرارشونده و پایدار کاندیدای Automation هستند؛ Exploratory، Usability و ارزیابی‌های زمینه‌ای به قضاوت انسان نیاز دارند. هدف Feedback قابل اعتماد است، نه درصد Automation.

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

Acceptance Criteria رفتار و حدود یک Story را تعریف می‌کند. Definition of Done معیار کیفیت مشترک برای Increment است. یک Story ممکن است Criteria خود را پاس کند اما به‌دلیل نقص Security، Review یا Migration هنوز Done نباشد.

چهار Quadrant تست چابک چه کاربردی دارند؟

ابزار برنامه‌ریزی و گفت‌وگو هستند تا تیم Testهایی را ببیند که ساخت را هدایت می‌کنند و Testهایی که محصول را نقد می‌کنند، از دید کسب‌وکار و فناوری. Quadrantها ترتیب اجرا یا فرایند اجباری نیستند.

منابع فنی

• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• The Scrum Guide — November 2020
• ISTQB CTFL Syllabus v4.0.1 — Whole Team Approach
• Crispin & Gregory — Agile Testing Quadrants as a planning guide