داستان کاربر (User Story) چیست؟ راهنمای کامل برای تستر نرم‌افزار

در توسعه نرم‌افزار، پیش از آنکه یک قابلیت ساخته و تست شود، باید مشخص باشد کاربر چه نیازی دارد و سیستم قرار است چه ارزشی برای او ایجاد کند. یکی از روش‌های رایج برای بیان این نیاز، به‌ویژه در تیم‌های چابک، استفاده از داستان کاربر (User Story) است.

User Story معمولاً به زبان ساده و از دید کاربر نوشته می‌شود و به تیم کمک می‌کند پیش از ورود به جزئیات فنی، ابتدا نیاز، هدف و ارزش مورد انتظار کاربر را درک کند.

اما داستان کاربر فقط برای Product Owner یا تیم توسعه اهمیت ندارد. برای تستر نرم‌افزار نیز User Story یکی از ورودی‌های مهم برای تحلیل نیاز، شناسایی ابهام‌ها و آماده‌سازی تست است. یک تستر می‌تواند حتی پیش از شروع توسعه، با بررسی User Story سؤال‌هایی مطرح کند، ریسک‌ها را شناسایی کند و به شفاف‌تر شدن رفتار مورد انتظار سیستم کمک کند.

در این مقاله ابتدا بررسی می‌کنیم که User Story چیست و چگونه نوشته می‌شود؛ سپس از دید تست نرم‌افزار به آن نگاه می‌کنیم: تستر چگونه یک User Story را تحلیل می‌کند، چگونه از آن به سناریوهای تست می‌رسد و چگونه Testability و آمادگی آن برای توسعه و تست را بررسی می‌کند.

داستان کاربر (User Story) چیست؟

داستان کاربر یا User Story، توصیفی کوتاه و ساده از یک نیاز یا قابلیت نرم‌افزاری است که از دید یک کاربر بیان می‌شود.

هدف User Story این نیست که تمام جزئیات فنی یک قابلیت را مستند کند؛ بلکه باید مشخص کند:

• چه کسی به این قابلیت نیاز دارد؟
• چه چیزی می‌خواهد انجام دهد؟
• چرا این قابلیت برای او ارزشمند است؟

به بیان ساده، User Story به تیم کمک می‌کند نیاز نرم‌افزار را از دید کاربر و ارزشی که انتظار دارد دریافت کند درک کند.

برای مثال، فرض کنید یک فروشگاه اینترنتی امکان بازیابی رمز عبور را در اختیار کاربران قرار می‌دهد. یک User Story می‌تواند به این شکل نوشته شود:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

در این مثال، به‌جای اینکه مستقیماً درباره API، پایگاه داده یا نحوه ارسال ایمیل صحبت کنیم، ابتدا نیاز و هدف کاربر بیان شده است. این همان نقطه‌ای است که User Story را از توضیحات فنی مربوط به پیاده‌سازی جدا می‌کند.

برای تستر نرم‌افزار نیز همین جمله می‌تواند نقطه شروع تحلیل باشد. برای مثال، تستر ممکن است سؤال‌هایی مانند این‌ها را مطرح کند:

• اگر کاربر ایمیل نامعتبر وارد کند چه اتفاقی باید بیفتد؟
• اگر ایمیل واردشده مربوط به هیچ حسابی نباشد چه می‌شود؟
• لینک بازیابی تا چه مدت معتبر است؟
• آیا کاربر می‌تواند از یک لینک بازیابی چند بار استفاده کند؟
• پس از تغییر رمز عبور، آیا لینک قبلی همچنان معتبر است؟

نکته مهم این است که پاسخ همه این سؤال‌ها لزوماً در خود User Story وجود ندارد. اما Story می‌تواند نقطه شروع گفت‌وگو و تحلیل برای روشن شدن رفتار مورد انتظار سیستم باشد.

بنابراین، برای یک تستر، User Story فقط یک جمله برای ثبت یک قابلیت در Product Backlog نیست؛ بلکه یکی از ورودی‌های اولیه برای درک نیاز، شناسایی ابهام‌ها و شروع تحلیل رفتارهای قابل تست محسوب می‌شود.

ساختار و قالب User Story چگونه است؟

یک User Story معمولاً با یک قالب ساده و شناخته‌شده نوشته می‌شود:

به‌عنوان [نوع کاربر]، می‌خواهم [هدف یا قابلیت] را داشته باشم تا [ارزش یا دلیل].

معادل رایج انگلیسی این قالب:

As a [user], I want [goal], so that [benefit].

این ساختار کمک می‌کند User Story به‌جای تمرکز بر جزئیات فنی، روی سه موضوع اصلی تمرکز داشته باشد: کاربر، هدف او و ارزشی که از قابلیت دریافت می‌کند.

نقش کاربر؛ As a

در بخش اول مشخص می‌شود چه کسی به این قابلیت نیاز دارد.

برای مثال:

به‌عنوان یک مشتری…

یا:

به‌عنوان یک مدیر فروش…

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

از دید تستر نیز نقش کاربر اهمیت ویژه‌ای دارد. تستر باید بررسی کند قابلیت موردنظر برای چه نوع کاربری طراحی شده و آیا کاربران یا نقش‌های دیگر محدودیت‌ها و رفتار متفاوتی دارند یا خیر.

هدف یا قابلیت؛ I want

در این بخش مشخص می‌شود کاربر چه کاری می‌خواهد انجام دهد یا به چه قابلیتی نیاز دارد.

برای مثال:

می‌خواهم بتوانم رمز عبور خود را بازیابی کنم…

این قسمت باید روی نیاز یا هدف کاربر تمرکز داشته باشد، نه روی راه‌حل فنی.

برای مثال، عبارت زیر بیشتر یک تصمیم فنی را توصیف می‌کند:

می‌خواهم سیستم از API مربوط به سرویس X برای ارسال درخواست بازیابی رمز استفاده کند.

در حالی که در User Story بهتر است ابتدا نیاز واقعی کاربر بیان شود:

می‌خواهم بتوانم رمز عبور خود را بازیابی کنم.

جزئیات فنی موردنیاز برای پیاده‌سازی می‌توانند در بخش‌های دیگر فرآیند تحلیل و توسعه مشخص شوند.

ارزش یا دلیل؛ So that

در بخش سوم مشخص می‌شود چرا این قابلیت برای کاربر ارزشمند است.

برای مثال:

تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

این بخش کمک می‌کند تیم فقط روی این سؤال تمرکز نکند که «چه چیزی باید ساخته شود؟»، بلکه دلیل و ارزش ایجاد قابلیت را نیز درک کند.

از دید تستر، دانستن هدف کاربر می‌تواند در تحلیل رفتار سیستم مفید باشد. تست فقط نباید به بررسی اجرای یک مسیر مشخص محدود شود؛ بلکه باید بررسی شود که آیا قابلیت طراحی‌شده واقعاً نیاز موردنظر کاربر را پوشش می‌دهد یا خیر.

یک User Story کامل

با کنار هم قرار دادن این سه بخش، مثال ما به این شکل کامل می‌شود:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

در این مثال:

• کاربر: مشتری
• هدف: بازیابی رمز عبور
• ارزش: دسترسی دوباره به حساب کاربری

اما نکته مهم این است که این جمله به‌تنهایی تمام جزئیات رفتار سیستم را مشخص نمی‌کند. برای مثال، هنوز نمی‌دانیم لینک بازیابی چگونه ارسال می‌شود، چه مدت اعتبار دارد یا هنگام وارد کردن اطلاعات نامعتبر چه رفتاری باید رخ دهد.

این موضوع طبیعی است. User Story قرار نیست به‌تنهایی تمام جزئیات یک قابلیت را مشخص کند؛ بلکه می‌تواند نقطه شروعی برای گفت‌وگو، تحلیل و تکمیل اطلاعات موردنیاز باشد. برای تستر نیز همین موضوع اهمیت زیادی دارد، زیرا ابهام‌ها و سؤال‌های باقی‌مانده می‌توانند به شناسایی سناریوهای تست و بررسی Testability کمک کنند.

یک مثال واقعی از User Story

برای درک بهتر داستان کاربر (User Story)، می‌توان آن را در یک سناریوی واقعی بررسی کرد. در این بخش، همان مثال بازیابی رمز عبور را ادامه می‌دهیم تا مشخص شود یک تستر چگونه از یک User Story ساده به تحلیل سؤال‌ها و رفتارهای قابل بررسی می‌رسد.

فرض کنید یک فروشگاه اینترنتی می‌خواهد قابلیتی برای بازیابی رمز عبور کاربران ایجاد کند.

ممکن است این نیاز در ابتدا به شکل ساده‌ای بیان شود:

کاربر باید بتواند رمز عبور خود را بازیابی کند و رمز جدیدی تعیین کند.

اما در قالب User Story می‌توان آن را به این شکل نوشت:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

در این User Story سه بخش اصلی مشخص شده است:

بخش	مقدار
کاربر	مشتری
هدف	بازیابی رمز عبور
ارزش	دسترسی دوباره به حساب کاربری

تستر از این User Story چه چیزی متوجه می‌شود؟

تستر نرم‌افزار با خواندن این User Story می‌تواند درک اولیه‌ای از قابلیت موردنظر به دست آورد:

• کاربر در صورت از دست دادن رمز عبور باید بتواند دوباره به حساب خود دسترسی پیدا کند.
• قابلیت بازیابی رمز عبور باید نیاز کاربر را برطرف کند.
• رفتار اصلی سیستم حول فرایند بازیابی و دسترسی مجدد به حساب شکل می‌گیرد.

اما این اطلاعات برای طراحی کامل تست کافی نیست. تستر احتمالاً سؤال‌های بیشتری خواهد داشت، مانند:

• کاربر چگونه درخواست بازیابی رمز عبور را ثبت می‌کند؟
• بازیابی رمز عبور از طریق ایمیل انجام می‌شود یا شماره موبایل؟
• اگر اطلاعات واردشده معتبر نباشند، چه اتفاقی باید بیفتد؟
• اگر اطلاعات واردشده متعلق به هیچ حسابی نباشند، سیستم چه رفتاری دارد؟
• لینک یا کد بازیابی تا چه مدت معتبر است؟
• آیا کاربر می‌تواند از یک لینک یا کد بازیابی چند بار استفاده کند؟
• پس از تعیین رمز جدید، آیا رمز قبلی دیگر معتبر نیست؟
• اگر کاربر چند بار پشت سر هم درخواست بازیابی رمز عبور ارسال کند، چه اتفاقی باید بیفتد؟

این سؤال‌ها نشان می‌دهند که User Story نقطه پایان تحلیل نیست؛ بلکه نقطه شروعی برای گفت‌وگو و شفاف‌سازی رفتار مورد انتظار سیستم است.

آیا تستر باید همه این موارد را خودش حدس بزند؟

خیر.

یکی از اشتباهات رایج این است که تستر هنگام مشاهده یک User Story، رفتارهای نامشخص سیستم را خودش فرض کند و سپس بر اساس این فرض‌ها Test Case بنویسد.

برای مثال، اگر فقط مشخص شده باشد:

کاربر می‌تواند رمز عبور خود را بازیابی کند.

تستر نباید خودش تصمیم بگیرد که:

• لینک بازیابی دقیقاً 24 ساعت اعتبار دارد.
• کاربر فقط یک بار می‌تواند از لینک استفاده کند.
• بازیابی فقط از طریق ایمیل انجام می‌شود.
• پس از چند درخواست، سیستم باید کاربر را محدود کند.

این موارد ممکن است در منابع دیگری مانند Acceptance Criteria، Requirement، قوانین کسب‌وکار یا گفت‌وگوهای تیمی مشخص شوند. اگر اطلاعات موردنیاز هنوز وجود نداشته باشند، نقش تستر این است که ابهام را شناسایی و سؤال مناسب را مطرح کند، نه اینکه رفتار سیستم را از طرف خود تعریف کند.

این بخش یکی از مهم‌ترین تفاوت‌های نگاه یک تستر حرفه‌ای به User Story است: تستر فقط به دنبال پیدا کردن چیزهایی برای تست کردن نیست؛ بلکه بررسی می‌کند آیا اطلاعات لازم برای طراحی تست واقعاً وجود دارد یا خیر.

یک نکته مهم: تستر نباید رفتارهای نامشخص را حدس بزند

همان‌طور که در مثال بازیابی رمز عبور دیدیم، یک User Story ممکن است اطلاعات کافی برای درک نیاز اصلی کاربر را ارائه دهد، اما هنوز بسیاری از جزئیات رفتار سیستم مشخص نباشند. در چنین شرایطی، یکی از اشتباهات رایج این است که تستر خودش رفتارهای نامشخص را فرض کند و بر اساس آن Test Case بنویسد.

برای مثال، اگر در User Story فقط گفته شده باشد:

کاربر می‌تواند رمز عبور خود را بازیابی کند.

تستر نباید بدون هماهنگی فرض کند که:

لینک بازیابی باید ۳۰ دقیقه اعتبار داشته باشد.

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

بنابراین، نقش تستر این نیست که برای بخش‌های نامشخص User Story خودش تصمیم‌گیری کند. وظیفه او این است که بتواند ابهام‌ها را شناسایی کند و اطلاعات موردنیاز برای تحلیل و طراحی تست را از تیم دریافت کند.

این موضوع اهمیت زیادی دارد؛ زیرا فعالیت تستر فقط به پیدا کردن Bug پس از پیاده‌سازی محدود نمی‌شود. شناسایی ابهام‌ها و ریسک‌های احتمالی قبل از شروع یا تکمیل توسعه نیز می‌تواند بخشی از فعالیت حرفه‌ای تستر باشد.

یک User Story خوب قرار نیست همه جزئیات را در خود داشته باشد

در مقابل، راه‌حل این نیست که تمام جزئیات مربوط به یک قابلیت را داخل خود User Story قرار دهیم.

اگر برای قابلیت بازیابی رمز عبور، تمام اطلاعات مربوط به رابط کاربری، API، پایگاه داده، پیام‌های خطا، قوانین امنیتی و جزئیات دیگر را در یک Story قرار دهیم، ممکن است دیگر با یک داستان کاربر ساده و قابل فهم روبه‌رو نباشیم.

هدف اصلی User Story این است که نیاز و هدف کاربر را به شکلی روشن و قابل فهم برای تیم بیان کند. جزئیات موردنیاز برای مشخص شدن رفتار سیستم می‌توانند در ادامه فرآیند تحلیل و توسعه تکمیل شوند.

از دید تستر، نکته کلیدی این است که بتواند تشخیص دهد:

• چه اطلاعاتی در User Story مشخص شده است؟
• چه بخش‌هایی هنوز مبهم هستند؟
• برای تحلیل قابلیت به چه اطلاعات بیشتری نیاز است؟
• کدام ابهام‌ها ممکن است روی تست و کیفیت نرم‌افزار تأثیر بگذارند؟

این نگاه باعث می‌شود تستر User Story را صرفاً به‌عنوان یک توضیح برای اجرای تست نبیند، بلکه از همان ابتدا آن را برای شناسایی ابهام‌ها، پرسیدن سؤال‌های مناسب و آماده‌سازی تحلیل تست بررسی کند.

یک User Story خوب چه ویژگی‌هایی دارد؟

هر جمله‌ای که با قالب «به‌عنوان یک کاربر…» نوشته شود، لزوماً یک User Story خوب نیست. یک داستان کاربر باید به اندازه‌ای شفاف، ارزشمند و قابل بررسی باشد که اعضای تیم بتوانند درباره آن گفت‌وگو کنند، آن را برآورد کنند و در نهایت پیاده‌سازی و تست کنند.

یکی از چارچوب‌های شناخته‌شده برای بررسی کیفیت User Story، مدل INVEST است. این مدل شش ویژگی مهم را برای یک User Story مناسب مطرح می‌کند:

• I — Independent: مستقل
• N — Negotiable: قابل مذاکره
• V — Valuable: ارزشمند
• E — Estimable: قابل برآورد
• S — Small: کوچک
• T — Testable: قابل تست

در ادامه، هر ویژگی را به‌صورت کوتاه بررسی می‌کنیم و در مواردی که به تحلیل و تست مربوط است، نگاه تستر را نیز در نظر می‌گیریم.

Independent؛ مستقل

یک User Story بهتر است تا حد امکان مستقل از Storyهای دیگر باشد و بتوان آن را بدون وابستگی‌های غیرضروری توسعه داد.

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

از دید تستر، وابستگی زیاد بین Storyها می‌تواند تحلیل و اجرای تست را نیز پیچیده‌تر کند. ممکن است تست یک قابلیت تا زمانی که قابلیت دیگری آماده نشده امکان‌پذیر نباشد یا تغییر در یک Story روی رفتار Storyهای دیگر تأثیر بگذارد.

بنابراین، تستر هنگام بررسی User Story می‌تواند وابستگی‌های مهم را شناسایی کند و بررسی کند که آیا این وابستگی‌ها:

• روی طراحی تست تأثیر دارند؟
• ترتیب اجرای تست‌ها را تغییر می‌دهند؟
• به محیط یا داده تست خاصی نیاز دارند؟
• ممکن است باعث ایجاد ریسک در یکپارچه‌سازی شوند؟

استقلال کامل همیشه ممکن نیست، اما وابستگی‌های مهم باید برای تیم قابل شناسایی و مدیریت باشند.

Negotiable؛ قابل مذاکره

User Story نباید به یک مشخصات فنی کاملاً ثابت و غیرقابل تغییر تبدیل شود. هدف آن این است که نیاز و ارزش مورد انتظار کاربر را بیان کند و درباره جزئیات راه‌حل، امکان گفت‌وگو و تصمیم‌گیری وجود داشته باشد.

برای مثال، اگر User Story می‌گوید:

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

این Story لزوماً مشخص نمی‌کند که وضعیت سفارش باید:

• در قالب جدول نمایش داده شود،
• به‌صورت Timeline باشد،
• یا با روش دیگری به کاربر نمایش داده شود.

این جزئیات می‌توانند در جریان تحلیل و گفت‌وگو بین اعضای تیم مشخص شوند.

از دید تستر نیز قابل مذاکره بودن User Story اهمیت دارد؛ زیرا اگر جزئیات هنوز قطعی نشده باشند، تستر باید آن‌ها را به‌عنوان ابهام یا موضوع قابل بررسی شناسایی کند، نه اینکه آن‌ها را به‌عنوان رفتار نهایی سیستم فرض کند.

Valuable؛ ارزشمند

هر User Story باید برای کاربر، مشتری یا کسب‌وکار ارزش مشخصی ایجاد کند.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم بتوانم وضعیت سفارش خود را مشاهده کنم تا بدانم سفارش من در چه مرحله‌ای قرار دارد.

در اینجا ارزش Story مشخص است: کاربر می‌خواهد از وضعیت سفارش خود آگاه شود.

اگر یک Story نتواند ارزش یا هدف مشخصی را توضیح دهد، ممکن است لازم باشد دوباره بررسی شود.

برای تستر، درک ارزش User Story کمک می‌کند فقط روی اجرای یک قابلیت تمرکز نکند، بلکه هدف اصلی آن را نیز در نظر بگیرد. برای مثال، اگر قابلیت نمایش وضعیت سفارش از نظر فنی کار کند اما اطلاعاتی که نمایش می‌دهد نیاز واقعی کاربر را برطرف نکند، ممکن است همچنان مسئله‌ای در کیفیت محصول وجود داشته باشد.

Estimable؛ قابل برآورد

تیم باید بتواند با اطلاعات موجود، اندازه یا میزان تلاش موردنیاز برای اجرای User Story را تا حد قابل قبولی تخمین بزند.

اگر یک Story بیش از حد مبهم یا بزرگ باشد، برآورد آن دشوار می‌شود.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم یک سیستم فروشگاه اینترنتی بهتر داشته باشم.

چنین Storyای بسیار کلی است و مشخص نیست دقیقاً چه چیزی باید تغییر کند یا چه میزان کار برای آن لازم است.

از دید تستر نیز مبهم بودن Story معمولاً فقط روی برآورد توسعه تأثیر نمی‌گذارد؛ بلکه می‌تواند باعث شود:

• محدوده تست مشخص نباشد،
• سناریوهای موردنیاز نامشخص باشند،
• داده یا محیط تست قابل پیش‌بینی نباشد،
• و ریسک‌های تست دیرتر شناسایی شوند.

Small؛ کوچک

User Story بهتر است به اندازه‌ای کوچک باشد که بتوان آن را در یک بازه توسعه منطقی، معمولاً در چارچوب یک Sprint، پیاده‌سازی و تست کرد.

برای مثال، به‌جای قرار دادن تمام قابلیت‌های حساب کاربری در یک Story بزرگ، می‌توان آن را به Storyهای کوچک‌تر تقسیم کرد:

• ورود به حساب کاربری
• بازیابی رمز عبور
• تغییر رمز عبور
• مشاهده اطلاعات حساب

کوچک بودن Story برای تستر نیز اهمیت دارد؛ زیرا محدوده تست، سناریوهای موردنیاز و رفتارهای مورد انتظار واضح‌تر می‌شوند.

البته کوچک بودن به این معنا نیست که هر فعالیت بسیار ریز را به یک User Story مستقل تبدیل کنیم. هدف این است که Story به اندازه‌ای قابل مدیریت باشد که تیم بتواند درباره آن صحبت کند، آن را توسعه دهد و رفتار آن را بررسی کند.

Testable؛ قابل تست

ویژگی Testable برای تستر نرم‌افزار اهمیت ویژه‌ای دارد.

یک User Story باید به شکلی نوشته یا تکمیل شود که بتوان مشخص کرد آیا قابلیت موردنظر به‌درستی پیاده‌سازی شده است یا خیر.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را پیگیری کنم تا از وضعیت آن مطلع باشم.

نسبت به جمله زیر قابل بررسی‌تر است:

به‌عنوان یک مشتری، می‌خواهم تجربه بهتری هنگام پیگیری سفارش داشته باشم.

در جمله دوم مشخص نیست «تجربه بهتر» دقیقاً به چه معناست و تستر بر اساس چه معیار یا رفتار قابل مشاهده‌ای باید آن را ارزیابی کند.

Testable بودن لزوماً به این معنا نیست که تمام Test Caseها باید از ابتدا آماده باشند؛ بلکه یعنی تیم بتواند به سطحی از شفافیت برسد که رفتار مورد انتظار قابلیت قابل بررسی باشد.

INVEST چه کمکی به تستر می‌کند؟

INVEST فقط ابزاری برای Product Owner یا تیم توسعه نیست. تستر نیز می‌تواند هنگام بررسی User Story از این ویژگی‌ها برای شناسایی مشکلات اولیه استفاده کند.

برای مثال، تستر می‌تواند سؤال‌هایی مانند این مطرح کند:

• آیا Story آن‌قدر بزرگ نیست که محدوده تست را نامشخص کند؟
• آیا هدف کاربر مشخص است؟
• آیا Story ارزش مشخصی دارد؟
• آیا وابستگی مهمی به قابلیت‌ها یا Storyهای دیگر وجود دارد؟
• آیا می‌توان رفتار مورد انتظار را به‌صورت قابل بررسی مشخص کرد؟
• آیا ابهامی وجود دارد که طراحی تست را دشوار کند؟

بنابراین، INVEST را می‌توان یک ابزار ذهنی برای بررسی کیفیت اولیه User Story دانست؛ نه یک چک‌لیست سخت‌گیرانه که هر Story باید بدون استثنا تمام شش ویژگی را به‌طور کامل داشته باشد.

تستر نرم‌افزار با User Story چه کاری انجام می‌دهد؟

User Story فقط یک ورودی برای تیم توسعه نیست. برای تستر نرم‌افزار نیز یکی از منابع مهم برای درک نیاز کاربر، شناسایی ابهام‌ها و آماده‌سازی تحلیل تست محسوب می‌شود.

تستر بهتر است منتظر نماند تا قابلیت کاملاً توسعه پیدا کند و سپس برای اولین بار User Story را بررسی کند. از زمانی که Story برای بررسی تیم آماده می‌شود، تستر می‌تواند آن را از دید رفتار مورد انتظار، قابلیت تست و ریسک‌های احتمالی بررسی کند.

۱. درک هدف User Story

اولین قدم این است که تستر مطمئن شود هدف اصلی Story را درک کرده است:

• چه کاربری قرار است از این قابلیت استفاده کند؟
• کاربر چه کاری می‌خواهد انجام دهد؟
• این قابلیت چه مشکلی را برای کاربر یا کسب‌وکار حل می‌کند؟

برای مثال:

به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، هزینه‌ای برای سفارشی که دیگر به آن نیاز ندارم پرداخت نکنم.

در اینجا تستر ابتدا باید هدف اصلی را درک کند: امکان لغو سفارش توسط مشتری در شرایط مجاز.

این درک اولیه کمک می‌کند تستر هنگام تحلیل، فقط روی یک مسیر ساده تمرکز نکند و شرایط مختلف استفاده از قابلیت را نیز در نظر بگیرد.

۲. شناسایی ابهام‌ها

یکی از مهم‌ترین فعالیت‌های تستر هنگام بررسی User Story، شناسایی مواردی است که رفتار سیستم درباره آن‌ها مشخص نیست.

فرض کنید Story فقط می‌گوید:

مشتری می‌تواند سفارش خود را لغو کند.

اما مشخص نکرده است:

• آیا همه سفارش‌ها قابل لغو هستند؟
• آیا سفارش ارسال‌شده را هم می‌توان لغو کرد؟
• تا چه زمانی امکان لغو وجود دارد؟
• اگر پرداخت انجام شده باشد، چه اتفاقی می‌افتد؟
• مبلغ پرداخت‌شده چگونه بازگردانده می‌شود؟

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

این کار می‌تواند از سوءتفاهم بین نیاز کسب‌وکار، پیاده‌سازی و تست جلوگیری کند.

۳. بررسی Testability

تستر باید بررسی کند که آیا اطلاعات موجود به اندازه کافی مشخص هستند که بتوان رفتار قابلیت را بررسی کرد یا خیر.

برای مثال:

به‌عنوان مشتری، می‌خواهم تجربه بهتری هنگام پرداخت داشته باشم.

مشکل این Story این است که «تجربه بهتر» معیار مشخصی ندارد. در نتیجه، تعیین اینکه چه نتیجه‌ای باید Pass یا Fail محسوب شود دشوار است.

در مقابل:

به‌عنوان مشتری، می‌خواهم بتوانم پرداخت سفارش را با کارت بانکی انجام دهم تا سفارش خود را نهایی کنم.

رفتار قابل بررسی‌تری را بیان می‌کند، هرچند برای طراحی تست همچنان ممکن است به اطلاعات بیشتری نیاز باشد.

بنابراین، Testability فقط به معنی داشتن Test Case نیست؛ بلکه یعنی بتوان رفتار مورد انتظار را به شکلی قابل بررسی مشخص کرد.

۴. شناسایی سناریوهای مثبت و منفی

تستر نباید User Story را فقط از مسیر موفقیت‌آمیز بررسی کند.

برای مثال، اگر Story مربوط به ورود کاربر باشد، مسیر اصلی می‌تواند این باشد:

کاربر نام کاربری و رمز عبور صحیح را وارد می‌کند و وارد حساب خود می‌شود.

اما تستر باید به حالت‌های دیگر نیز فکر کند:

• رمز عبور اشتباه
• نام کاربری اشتباه
• هر دو مقدار اشتباه
• فیلدهای خالی
• کاربر غیرفعال
• تعداد زیاد تلاش‌های ناموفق
• اطلاعات با فرمت نامعتبر

البته همه این رفتارها لزوماً فقط از خود User Story استخراج نمی‌شوند. بخشی از آن‌ها ممکن است به قوانین کسب‌وکار، Requirementها یا اطلاعات تکمیلی دیگر وابسته باشند.

نکته مهم این است:

User Story نقطه شروع تحلیل تست است، نه تنها منبع اطلاعات برای تست.

۵. بررسی شرایط مرزی

تستر همچنین باید به شرایطی توجه کند که در مرز رفتار سیستم قرار دارند.

برای مثال، اگر قابلیتی امکان آپلود فایل را فراهم کند و محدودیت حجم فایل وجود داشته باشد، مواردی مانند این‌ها اهمیت پیدا می‌کنند:

• فایل دقیقاً در حد مجاز
• فایل کمی بیشتر از حد مجاز
• فایل خالی
• فرمت غیرمجاز

اگر محدودیت دقیق در User Story یا اطلاعات تکمیلی مشخص نشده باشد، تستر نباید مقدار آن را خودش تعیین کند؛ بلکه باید این موضوع را به‌عنوان یک ابهام مطرح کند تا رفتار مورد انتظار مشخص شود.

۶. بررسی وابستگی‌ها و ریسک‌ها

گاهی اجرای یک User Story به سرویس، قابلیت یا تیم دیگری وابسته است.

برای مثال، یک Story مربوط به ارسال کد تأیید ممکن است به یک سرویس پیامک خارجی وابسته باشد.

تستر باید چنین وابستگی‌هایی را شناسایی کند؛ زیرا ممکن است روی موارد زیر تأثیر بگذارند:

• محیط تست
• داده‌های تست
• اجرای سناریوها
• پایداری تست
• زمان‌بندی تست

همچنین Storyهایی که با موضوعاتی مانند پرداخت، احراز هویت، اطلاعات حساس یا عملیات مالی مرتبط هستند، معمولاً ریسک بیشتری دارند و ممکن است به توجه و تست بیشتری نیاز داشته باشند.

تستر قرار نیست User Story را به‌تنهایی کامل کند

یک نکته مهم این است که مسئولیت User Story فقط بر عهده تستر نیست.

تستر می‌تواند ابهام‌ها، ریسک‌ها و مشکلات مربوط به Testability را شناسایی کند، اما تصمیم‌گیری درباره نیاز واقعی کسب‌وکار و رفتار مورد انتظار محصول معمولاً با نقش‌هایی مانند Product Owner، Business Analyst و سایر ذی‌نفعان مرتبط انجام می‌شود.

بنابراین، نقش تستر در این مرحله بیشتر این است که:

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

نه اینکه خودش پاسخ رفتارهای نامشخص سیستم را تعیین کند.

در نتیجه، یک تستر حرفه‌ای User Story را فقط برای پیدا کردن Bug در آینده نمی‌خواند؛ بلکه از همان ابتدا بررسی می‌کند:

چه چیزی باید ساخته شود، چه چیزهایی هنوز نامشخص هستند و آیا اطلاعات موجود برای تحلیل و طراحی تست کافی هستند یا خیر.

چگونه از User Story سناریوهای تست استخراج کنیم؟

یکی از مهارت‌های مهم تستر نرم‌افزار این است که بتواند از User Story، رفتارها و حالت‌های مختلفی را که باید بررسی شوند شناسایی کند.

البته User Story همیشه به‌تنهایی اطلاعات کافی برای طراحی Test Case را فراهم نمی‌کند. تستر معمولاً باید در کنار آن، اطلاعات دیگری مانند قوانین کسب‌وکار، رفتار مورد انتظار سیستم و اطلاعات تکمیلی موجود را نیز بررسی کند.

به‌صورت ساده می‌توان این مسیر را این‌گونه در نظر گرفت:

User Story → درک نیاز → شناسایی حالت‌های مختلف → Test Scenario → Test Case

این مسیر به این معنا نیست که هر User Story مستقیماً و به‌صورت مکانیکی به چند Test Case تبدیل می‌شود. نقش تستر ابتدا درک قابلیت و شناسایی رفتارهایی است که باید بررسی شوند.

یک مثال ساده

فرض کنیم User Story زیر را داریم:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

در نگاه اول ممکن است یک سناریوی ساده به ذهن برسد:

کاربر رمز عبور خود را با موفقیت بازیابی می‌کند.

اما تستر نباید فقط به همین مسیر موفق توجه کند. با تحلیل User Story و اطلاعات تکمیلی، می‌توان حالت‌های مختلفی را شناسایی کرد.

سناریوهای مثبت

ابتدا می‌توان مسیرهای اصلی و موفق قابلیت را بررسی کرد:

• کاربر با اطلاعات معتبر درخواست بازیابی رمز عبور می‌دهد.
• پیام یا لینک بازیابی با موفقیت دریافت می‌شود.
• کاربر از لینک معتبر استفاده می‌کند.
• کاربر رمز عبور جدید را مطابق قوانین تعیین‌شده ثبت می‌کند.
• کاربر پس از تغییر رمز عبور می‌تواند با رمز جدید وارد حساب خود شود.

این سناریوها مسیر عادی و موفق استفاده از قابلیت را پوشش می‌دهند.

سناریوهای منفی

در مرحله بعد، تستر باید به شرایطی فکر کند که ممکن است سیستم با ورودی نامعتبر، خطا یا وضعیت غیرعادی مواجه شود:

• کاربر ایمیل با فرمت نامعتبر وارد می‌کند.
• کاربر اطلاعات مربوط به حسابی را وارد می‌کند که وجود ندارد.
• کاربر از لینک بازیابی منقضی‌شده استفاده می‌کند.
• کاربر لینک بازیابی نامعتبر را باز می‌کند.
• کاربر رمز عبوری وارد می‌کند که قوانین تعیین‌شده را رعایت نمی‌کند.
• کاربر تلاش می‌کند یک لینک بازیابی را بیش از تعداد مجاز استفاده کند.

در اینجا هدف فقط پیدا کردن Bug نیست؛ بلکه باید بررسی شود که سیستم در شرایط مختلف، رفتار مورد انتظار را دارد یا خیر.

شرایط مرزی

تستر باید به حالت‌های مرزی نیز توجه کند.

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

• استفاده از لینک دقیقاً در آخرین لحظه اعتبار
• استفاده کمی بعد از پایان اعتبار
• ارسال چند درخواست بازیابی در فاصله زمانی کوتاه
• استفاده هم‌زمان از چند لینک بازیابی

البته رفتار دقیق سیستم در این شرایط باید بر اساس قوانین و اطلاعات مشخص‌شده برای محصول تعیین شود. تستر نباید خودش رفتار مورد انتظار را فرض کند.

چه چیزی از User Story می‌آید و چه چیزی از اطلاعات تکمیلی؟

این تفکیک برای تستر اهمیت زیادی دارد.

خود User Story به ما می‌گوید:

کاربر باید بتواند رمز عبور خود را بازیابی کند.

اما مواردی مانند این ممکن است در خود User Story مشخص نشده باشند:

• لینک بازیابی چه مدت اعتبار دارد؟
• کاربر چند بار می‌تواند درخواست بازیابی ارسال کند؟
• رمز عبور جدید باید چه شرایطی داشته باشد؟
• در صورت وارد کردن ایمیل نامعتبر، سیستم چه رفتاری باید داشته باشد؟

اگر پاسخ این سؤال‌ها در User Story وجود نداشته باشد، تستر نباید آن‌ها را بدون مبنا فرض کند. باید اطلاعات موجود را بررسی کند، سؤال‌های مناسب را مطرح کند و برای شفاف شدن رفتار مورد انتظار با افراد مرتبط همکاری کند.

بنابراین، طراحی تست صرفاً به معنی تبدیل مستقیم هر جمله User Story به یک Test Case نیست.

از Test Scenario تا Test Case

پس از اینکه رفتارها و سناریوهای مهم مشخص شدند، تستر می‌تواند برای هر سناریو یک یا چند Test Case طراحی کند.

برای مثال:

Test Scenario:

بازیابی موفق رمز عبور با اطلاعات معتبر

این سناریو می‌تواند به یک یا چند Test Case تبدیل شود که در آن جزئیاتی مانند:

• داده‌های ورودی
• پیش‌نیازها
• مراحل اجرا
• نتیجه مورد انتظار

مشخص می‌شوند.

به همین ترتیب:

Test Scenario:

استفاده از لینک بازیابی منقضی‌شده

نیز می‌تواند به Test Caseهای مشخصی تبدیل شود.

به‌طور خلاصه:

Test Scenario مشخص می‌کند چه چیزی را باید بررسی کنیم، در حالی که Test Case مشخص می‌کند چگونه آن را بررسی کنیم و چه نتیجه‌ای انتظار داریم.

این تفکیک کمک می‌کند تستر ابتدا پوشش رفتارها و سناریوها را بررسی کند و سپس وارد جزئیات طراحی Test Case شود.

نکته مهم: همه تست‌ها مستقیماً از User Story استخراج نمی‌شوند

User Story یک نقطه شروع مهم برای طراحی تست است، اما تنها منبع اطلاعات تست نیست.

بسته به پروژه، تستر ممکن است به منابع دیگری نیز نیاز داشته باشد، مانند:

• قوانین کسب‌وکار
• مستندات محصول
• رفتار مورد انتظار سیستم
• اطلاعات مربوط به رابط‌ها و وابستگی‌ها
• Requirementهای مرتبط

بنابراین، بهتر است بگوییم:

User Story به تستر کمک می‌کند هدف و محدوده قابلیت را درک کند و نقطه شروع مناسبی برای شناسایی Test Scenarioها فراهم می‌کند.

نه اینکه:

تمام Test Caseها مستقیماً از User Story استخراج می‌شوند.

این تفاوت در پروژه‌های واقعی اهمیت زیادی دارد.

ارتباط User Story با Test Case چیست؟

User Story و Test Case دو مفهوم متفاوت هستند، اما در فرآیند توسعه و تست نرم‌افزار ارتباط نزدیکی با یکدیگر دارند.

به‌طور ساده:

User Story نیاز و هدف کاربر را بیان می‌کند، در حالی که Test Case نحوه بررسی یک رفتار مشخص سیستم را تعریف می‌کند.

در بخش قبل مسیر کلی را بررسی کردیم:

User Story → Test Scenario → Test Case

این رابطه معمولاً یک‌به‌یک نیست. یک User Story می‌تواند چند سناریوی تست داشته باشد و هر سناریو نیز ممکن است به یک یا چند Test Case تبدیل شود.

User Story چه چیزی را مشخص می‌کند؟

فرض کنیم User Story این باشد:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا بتوانم دوباره به حساب کاربری خود دسترسی داشته باشم.

این User Story هدف کلی قابلیت را مشخص می‌کند:

کاربر باید بتواند رمز عبور خود را بازیابی کند.

اما هنوز جزئیاتی مانند مراحل اجرای تست، داده‌های ورودی و نتیجه مورد انتظار هر حالت مشخص نشده‌اند.

Test Case چه چیزی را مشخص می‌کند؟

Test Case یک رفتار یا سناریوی مشخص را به شکلی قابل اجرا بررسی می‌کند.

برای مثال، برای سناریوی بازیابی موفق رمز عبور، یک Test Case می‌تواند شامل مواردی مانند این باشد:

• پیش‌شرط: یک حساب کاربری فعال وجود دارد.
• داده ورودی: ایمیل معتبر کاربر
• مراحل: ثبت درخواست بازیابی و استفاده از لینک معتبر
• نتیجه مورد انتظار: کاربر بتواند رمز جدید تعیین کند و با آن وارد حساب شود.

بنابراین، Test Case نسبت به User Story جزئیات بیشتری درباره شرایط اجرا، داده‌ها، مراحل و نتیجه مورد انتظار ارائه می‌دهد.

یک User Story می‌تواند چند Test Case داشته باشد

برای User Story بازیابی رمز عبور، ممکن است سناریوها و Test Caseهای مختلفی وجود داشته باشند:

سناریو	نمونه بررسی
بازیابی موفق	استفاده از اطلاعات معتبر
ورودی نامعتبر	وارد کردن ایمیل با فرمت نامعتبر
کاربر ناموجود	وارد کردن ایمیلی که حسابی با آن وجود ندارد
لینک منقضی	استفاده از لینک پس از پایان اعتبار
رمز جدید نامعتبر	وارد کردن رمزی که قوانین تعیین‌شده را رعایت نمی‌کند
استفاده مجدد	تلاش برای استفاده دوباره از لینک مصرف‌شده

بنابراین، این تصور درست نیست که:

یک User Story = یک Test Case

رابطه معمولاً به شکل زیر است:

یک User Story → چند Test Scenario → یک یا چند Test Case برای هر سناریوی مهم

آیا تستر باید User Story را مستقیماً به Test Case تبدیل کند؟

همیشه نه.

اگر تستر خیلی سریع از User Story وارد نوشتن Test Case شود، ممکن است پیش از شناسایی کامل رفتارها و حالت‌های مهم، وارد جزئیات اجرایی شود.

رویکرد مناسب‌تر این است:

User Story
↓
درک هدف و رفتار مورد انتظار
↓
شناسایی سناریوهای مختلف
↓
طراحی Test Case

این روش کمک می‌کند تستر ابتدا درباره پوشش تست فکر کند و سپس وارد جزئیات اجرای هر تست شود.

چرا این ارتباط برای تستر مهم است؟

شناخت رابطه User Story و Test Case به تستر کمک می‌کند:

• محدوده تست را بهتر مشخص کند.
• سناریوهای مثبت و منفی را شناسایی کند.
• شرایط مرزی را در نظر بگیرد.
• Test Caseهای مرتبط را سازمان‌دهی کند.
• هنگام تغییر User Story، تست‌های مرتبط را راحت‌تر پیدا کند.

در ابزارهای مدیریت تست نیز ممکن است ارتباط بین User Story و Test Case ثبت شود. این ارتباط می‌تواند برای ردیابی پوشش تست و تحلیل تأثیر تغییرات مفید باشد. جزئیات این موضوع بهتر است در مقاله تخصصی Traceability بررسی شود.

یک نکته مهم درباره پوشش تست

داشتن تعداد زیادی Test Case برای یک User Story، به‌تنهایی نشان نمی‌دهد که آن Story به‌خوبی تست شده است.

ممکن است یک User Story ده Test Case داشته باشد، اما همه آن‌ها فقط مسیر موفق را بررسی کنند. در مقابل، تعداد کمتری Test Case ممکن است سناریوهای مهم، خطاها، شرایط مرزی و ریسک‌های اصلی را بهتر پوشش دهند.

بنابراین، هدف تستر صرفاً افزایش تعداد Test Caseها نیست؛ بلکه باید بررسی شود که رفتارها و ریسک‌های مهم مرتبط با User Story به شکل مناسبی پوشش داده شده‌اند.

آیا هر User Story باید قابل تست باشد؟

بله، قابل تست بودن (Testable بودن) یکی از ویژگی‌های مهم یک User Story خوب است و در مدل INVEST نیز حرف T به همین موضوع اشاره دارد.

اما Testable بودن به این معنا نیست که User Story باید تمام جزئیات Test Case را در خود داشته باشد. منظور این است که تیم بتواند با اطلاعات موجود و اطلاعات تکمیلی مرتبط، مشخص کند:

• چه رفتاری باید بررسی شود؟
• چه نتیجه‌ای قابل قبول است؟
• چه زمانی می‌توان گفت قابلیت به‌درستی کار می‌کند؟

یک User Story قابل تست یعنی چه؟

فرض کنید User Story زیر را داریم:

به‌عنوان یک مشتری، می‌خواهم تجربه بهتری هنگام پرداخت داشته باشم تا بتوانم سفارش خود را راحت‌تر نهایی کنم.

مشکل این Story این است که عباراتی مانند «تجربه بهتر» و «راحت‌تر» معیار مشخصی ندارند.

تستر نمی‌تواند به‌سادگی مشخص کند:

• دقیقاً چه چیزی باید بررسی شود؟
• چه نتیجه‌ای Pass محسوب می‌شود؟
• چه نتیجه‌ای Fail محسوب می‌شود؟
• منظور از «بهتر» یا «راحت‌تر» دقیقاً چیست؟

در مقابل:

به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را با کارت بانکی پرداخت کنم تا سفارش خود را نهایی کنم.

هدف و رفتار موردنظر مشخص‌تر است و می‌توان با استفاده از اطلاعات تکمیلی، سناریوهای قابل تست برای آن طراحی کرد. البته این Story نیز ممکن است برای طراحی Test Case نهایی به جزئیات بیشتری نیاز داشته باشد.

تستر چگونه Testability را بررسی می‌کند؟

هنگام بررسی User Story، تستر می‌تواند چند سؤال مهم مطرح کند:

آیا مشخص است چه رفتاری باید بررسی شود؟

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

آیا می‌توان نتیجه مورد انتظار را مشخص کرد؟

اگر ندانیم چه نتیجه‌ای درست و چه نتیجه‌ای نادرست است، طراحی و ارزیابی تست دشوار خواهد بود.

آیا محدوده Story مشخص است؟

اگر Story بیش از حد گسترده باشد، ممکن است مشخص نباشد چه بخش‌هایی باید در محدوده تست قرار بگیرند.

آیا اصطلاحات مبهم وجود دارد؟

کلماتی مانند موارد زیر بدون تعریف مشخص می‌توانند Testability را کاهش دهند:

• سریع
• راحت
• مناسب
• بهتر
• ساده
• امن

برای مثال، اگر گفته شود یک سیستم باید «سریع» باشد، هنوز مشخص نیست منظور از سریع دقیقاً چیست و چگونه باید اندازه‌گیری یا بررسی شود.

آیا وجود ابهام به معنی بد بودن User Story است؟

لزوماً نه.

User Story قرار نیست از همان ابتدا تمام جزئیات را مشخص کند. بخشی از فرآیند کار تیمی روی Story این است که ابهام‌ها در جریان گفت‌وگو شناسایی و برطرف شوند.

برای مثال، اگر Story بگوید:

به‌عنوان یک مشتری، می‌خواهم بتوانم فایل خود را آپلود کنم.

تستر ممکن است سؤال‌هایی مانند این مطرح کند:

• چه فرمت‌هایی مجاز هستند؟
• حداکثر حجم فایل چقدر است؟
• اگر فایل نامعتبر باشد چه اتفاقی باید بیفتد؟
• آیا آپلود چند فایل هم‌زمان مجاز است؟

مطرح کردن این سؤال‌ها به معنی رد کردن User Story نیست؛ بلکه به تیم کمک می‌کند قبل از پیاده‌سازی، رفتار مورد انتظار را شفاف‌تر کند.

Testability چه ارتباطی با Acceptance Criteria دارد؟

در بسیاری از پروژه‌ها، جزئیات قابل بررسی یک User Story با استفاده از Acceptance Criteria شفاف‌تر می‌شوند.

User Story معمولاً نیاز و هدف کلی را بیان می‌کند، اما برای تستر لازم است مشخص شود سیستم در شرایط مختلف چه رفتارهایی باید داشته باشد و چه نتایجی قابل قبول هستند. Acceptance Criteria می‌تواند به روشن‌تر شدن همین رفتارهای قابل بررسی کمک کند.

برای آشنایی بیشتر با این مفهوم می‌توانید مقاله Acceptance Criteria چیست؟ را مطالعه کنید.

Testable بودن با «داشتن Test Case» فرق دارد

یک اشتباه رایج این است که تصور کنیم اگر برای یک User Story، Test Case نوشته شده باشد، پس آن Story حتماً قابل تست است.

ممکن است تستر برای یک Story مبهم، بر اساس فرضیات شخصی خودش Test Case بنویسد. این کار لزوماً به معنی Testable بودن واقعی Story نیست.

Testable بودن یعنی رفتار و معیارهای موردنیاز آن‌قدر روشن باشند که بتوان درباره نتیجه تست قضاوت قابل اتکایی داشت.

به همین دلیل، تستر نباید ابهام‌های موجود را با حدس و فرض شخصی پر کند.

یک تستر حرفه‌ای چه زمانی سؤال می‌پرسد؟

یک نشانه ساده می‌تواند این باشد:

اگر تستر برای ادامه تحلیل یا طراحی تست مجبور شود رفتاری را حدس بزند، احتمالاً باید سؤال بپرسد.

برای مثال:

«اگر کاربر بعد از منقضی شدن لینک بازیابی روی آن کلیک کند، انتظار داریم چه اتفاقی بیفتد؟»

این سؤال ارزشمندتر از آن است که تستر خودش تصمیم بگیرد چه رفتاری درست است و سپس بر اساس همان فرض، Test Case طراحی کند.

در نتیجه، Testability فقط یک ویژگی فنی نیست؛ بلکه به شفافیت ارتباط بین نیاز، رفتار مورد انتظار و نتیجه قابل بررسی مربوط می‌شود.

چه زمانی یک User Story برای شروع توسعه و تست آماده نیست؟

هر User Story که در Product Backlog قرار دارد، لزوماً به این معنا نیست که همان لحظه برای شروع توسعه و تست آماده است.

گاهی Story هنوز آن‌قدر ابهام دارد که اعضای تیم ممکن است برداشت‌های متفاوتی از آن داشته باشند. در چنین شرایطی، بررسی User Story توسط تستر می‌تواند به شناسایی مشکلات قبل از شروع توسعه کمک کند.

هدف این نیست که تستر صرفاً Story را «تأیید» یا «رد» کند؛ بلکه باید بررسی شود:

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

۱. هدف کاربر مشخص نیست

اگر مشخص نباشد کاربر دقیقاً چه چیزی می‌خواهد و چرا به آن نیاز دارد، Story ممکن است بیش از حد کلی باشد.

برای مثال:

به‌عنوان یک کاربر، می‌خواهم سیستم بهتر شود.

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

۲. User Story بیش از حد بزرگ است

گاهی یک User Story آن‌قدر گسترده است که در عمل چند قابلیت مختلف را در خود جای داده است.

برای مثال:

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

این Story ممکن است شامل قابلیت‌هایی مانند موارد زیر باشد:

• ثبت‌نام
• ورود
• تغییر رمز عبور
• ویرایش اطلاعات
• مدیریت آدرس‌ها
• مشاهده سفارش‌ها
• مدیریت روش‌های پرداخت

در چنین شرایطی، ممکن است لازم باشد Story به بخش‌های کوچک‌تر و قابل مدیریت‌تر تقسیم شود.

برای تستر نیز کوچک‌تر بودن محدوده معمولاً کمک می‌کند دامنه تست و سناریوهای موردنیاز واضح‌تر شوند.

۳. رفتار مورد انتظار مشخص نیست

ممکن است هدف کلی Story مشخص باشد، اما معلوم نباشد سیستم در شرایط مختلف چه رفتاری باید داشته باشد.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را لغو کنم.

اما هنوز سؤال‌هایی مانند این وجود دارند:

• سفارش در چه وضعیتی قابل لغو است؟
• اگر سفارش ارسال شده باشد چه اتفاقی می‌افتد؟
• اگر پرداخت انجام شده باشد چه می‌شود؟
• آیا مبلغ به کاربر بازگردانده می‌شود؟

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

۴. Story شامل عبارت‌های مبهم است

کلماتی مانند موارد زیر ممکن است در گفت‌وگوی روزمره قابل فهم باشند، اما بدون تعریف مشخص، برای تست کافی نیستند:

• سریع
• راحت
• بهتر
• ساده
• امن

برای مثال:

سیستم باید سریع باشد.

سؤال طبیعی تستر این است:

سریع یعنی چقدر؟

اگر معیار مشخصی وجود نداشته باشد، ارزیابی نتیجه تست به شکل قابل اتکا دشوار خواهد بود.

البته همه این جزئیات لزوماً نباید داخل خود User Story نوشته شوند؛ مهم این است که اطلاعات موردنیاز در منابع مرتبط یا تصمیم‌های تیمی قابل دسترس باشند.

۵. وابستگی‌های مهم مشخص نشده‌اند

فرض کنید یک User Story مربوط به ارسال کد تأیید از طریق پیامک است، اما این قابلیت به یک سرویس خارجی وابسته است.

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

تستر می‌تواند درباره مواردی مانند این سؤال کند:

• محیط تست چگونه به سرویس وابسته دسترسی دارد؟
• آیا داده یا حساب تست ویژه‌ای نیاز است؟
• اگر سرویس خارجی در دسترس نباشد چه اتفاقی می‌افتد؟
• آیا وابستگی روی اجرای تست‌ها تأثیر می‌گذارد؟

شناسایی این موارد می‌تواند بخشی از تحلیل ریسک قبل از شروع تست باشد.

۶. محدوده Story مشخص نیست

گاهی مشخص نیست چه چیزی داخل محدوده User Story و چه چیزی خارج از آن است.

برای مثال، اگر Story درباره «ویرایش پروفایل کاربر» باشد، آیا تغییر رمز عبور نیز بخشی از آن است؟

اگر Scope مشخص نباشد، ممکن است Product، Development و QA برداشت‌های متفاوتی داشته باشند.

شفاف بودن محدوده کمک می‌کند تیم بداند دقیقاً چه چیزی باید توسعه داده و تست شود.

۷. Story از نظر تست قابل بررسی نیست

اگر تستر نتواند مشخص کند:

• چه چیزی باید تست شود؟
• چه نتیجه‌ای مورد انتظار است؟
• چه شرایطی نشان‌دهنده موفقیت قابلیت است؟

احتمالاً Story هنوز به شفاف‌سازی بیشتری نیاز دارد.

این موضوع مستقیماً با مفهوم Testable در مدل INVEST مرتبط است.

آیا این یعنی User Story باید قبل از توسعه کاملاً کامل باشد؟

خیر.

User Story قرار نیست از همان ابتدا به یک سند طولانی، ثابت و پر از جزئیات تبدیل شود. مهم این است که برای شروع کار، اطلاعات کافی برای درک هدف، محدوده و رفتار مورد انتظار وجود داشته باشد و ابهام‌های مهم شناسایی شده باشند.

یکی از مزایای بررسی Story توسط اعضای تیم این است که مشکلات احتمالی قبل از تبدیل شدن به کد و سپس Bug شناسایی شوند.

نقش تستر در این مرحله چیست؟

تستر می‌تواند با پرسیدن سؤال‌های درست به شفاف‌تر شدن Story کمک کند:

«این قابلیت دقیقاً برای چه کاربری است؟»

«اگر این حالت رخ دهد، رفتار مورد انتظار چیست؟»

«این سناریو داخل محدوده این Story است یا خارج از آن؟»

«چطور می‌توانیم تشخیص دهیم که این Story به‌درستی پیاده‌سازی شده است؟»

این نوع پرسش‌ها بخشی از تفکر تحلیلی تستر هستند و می‌توانند به بهبود کیفیت User Story و در نهایت کیفیت محصول کمک کنند.

اشتباهات رایج در نوشتن User Story

یک User Story ضعیف می‌تواند پیش از اینکه حتی یک خط کد نوشته شود، برای تیم مشکل ایجاد کند. ابهام یا ضعف در Story ممکن است باعث شود Product، Development و QA برداشت‌های متفاوتی از یک قابلیت داشته باشند و بخشی از این اختلاف‌ها در ادامه به شکل Rework، تأخیر یا Bug ظاهر شوند.

در ادامه، مهم‌ترین اشتباهاتی را بررسی می‌کنیم که هنگام نوشتن یا بررسی داستان کاربر ممکن است رخ دهند.

۱. نوشتن User Story از دید سیستم به‌جای کاربر

یکی از رایج‌ترین اشتباهات این است که Story به‌جای بیان نیاز کاربر، مستقیماً راه‌حل فنی را توصیف کند.

سیستم باید یک API برای ارسال درخواست بازیابی رمز عبور ایجاد کند.

این جمله ممکن است یک نیاز فنی معتبر باشد، اما یک User Story نیست.

بهتر است ابتدا نیاز کاربر بیان شود:

به‌عنوان یک مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا دوباره به حسابم دسترسی داشته باشم.

جزئیات فنی می‌توانند در بخش‌های دیگر فرآیند تحلیل و توسعه مشخص شوند.

۲. تمرکز روی راه‌حل به‌جای مسئله کاربر

گاهی Story از همان ابتدا یک راه‌حل مشخص را تحمیل می‌کند.

به‌عنوان مشتری، می‌خواهم یک دکمه آبی در بالای صفحه داشته باشم تا سفارش خود را لغو کنم.

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

تمرکز بیش از حد روی راه‌حل می‌تواند گفت‌وگو درباره بهترین روش پیاده‌سازی را محدود کند.

۳. قرار دادن چند قابلیت در یک User Story

برای مثال:

به‌عنوان مشتری، می‌خواهم ثبت‌نام کنم، وارد حساب شوم، پروفایلم را ویرایش کنم و سفارش‌هایم را مدیریت کنم.

این Story چند قابلیت متفاوت را با هم ترکیب کرده و احتمالاً بیش از حد بزرگ است.

در صورت امکان، بهتر است چنین قابلیت‌هایی به Storyهای کوچک‌تر تقسیم شوند. برای تستر نیز این تقسیم‌بندی معمولاً باعث می‌شود محدوده تست و مدیریت سناریوها ساده‌تر شود.

۴. استفاده از عبارت‌های مبهم

عبارت‌هایی مانند:

سیستم باید سریع باشد.

یا:

کاربر باید تجربه خوبی داشته باشد.

بدون معیار مشخص، برای تست کافی نیستند.

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

۵. مشخص نکردن ارزش یا هدف

یک User Story خوب فقط نمی‌گوید کاربر چه کاری انجام می‌دهد؛ بهتر است مشخص باشد چرا انجام آن کار برای کاربر یا کسب‌وکار اهمیت دارد.

به‌عنوان مشتری، می‌خواهم وضعیت سفارش خود را مشاهده کنم تا بدانم سفارش من چه زمانی به دستم می‌رسد.

در این مثال، هدف کاربر روشن‌تر است.

البته نبود بخش «تا اینکه…» همیشه به‌تنهایی به معنی بی‌ارزش بودن Story نیست، اما مشخص بودن هدف یا ارزش می‌تواند به درک بهتر نیاز کمک کند.

۶. فرض کردن رفتارهای نامشخص

این اشتباه برای تسترها اهمیت ویژه‌ای دارد.

فرض کنید Story می‌گوید:

کاربر می‌تواند رمز عبور خود را بازیابی کند.

اما اطلاعاتی درباره مدت اعتبار لینک بازیابی وجود ندارد.

تستر نباید تصمیم بگیرد:

«پس لینک باید ۳۰ دقیقه اعتبار داشته باشد.»

این یک فرض است، نه الزام سیستم.

راه درست این است که تستر سؤال را مطرح کند و به شفاف شدن رفتار مورد انتظار کمک کند.

۷. نادیده گرفتن سناریوهای خطا

گاهی User Story مسیر اصلی را به‌خوبی بیان می‌کند، اما تیم فقط روی Happy Path تمرکز می‌کند.

برای مثال:

کاربر می‌تواند فایل خود را آپلود کند.

تستر باید بررسی کند که درباره شرایطی مانند موارد زیر چه رفتاری انتظار می‌رود:

• فایل نامعتبر
• فایل بزرگ‌تر از حد مجاز
• فایل خراب

البته پاسخ این موارد باید از رفتار مورد انتظار محصول و قوانین مرتبط به دست بیاید، نه از حدس تستر.

۸. بیش از حد بزرگ بودن User Story

این مورد با «قرار دادن چند قابلیت در یک Story» ارتباط دارد، اما دقیقاً یکسان نیست.

گاهی Story یک نیاز واقعی را بیان می‌کند، اما آن‌قدر گسترده است که توسعه و تست آن در یک محدوده منطقی دشوار می‌شود.

به‌عنوان مدیر، می‌خواهم تمام گزارش‌های کسب‌وکار را مدیریت کنم.

چنین Storyای احتمالاً شامل قابلیت‌ها و سناریوهای متعددی است و ممکن است لازم باشد به بخش‌های کوچک‌تر و قابل مدیریت‌تر تقسیم شود.

۹. تصور اینکه User Story باید تمام جزئیات را در خود داشته باشد

برای حل مشکل ابهام، گاهی تیم تمام جزئیات UI، API، Database، قوانین فنی و سناریوهای مختلف را داخل یک Story قرار می‌دهد.

در نتیجه، Story ممکن است دیگر ساده و قابل گفت‌وگو نباشد.

User Story باید نیاز و هدف کاربر را روشن کند و اطلاعات تکمیلی می‌توانند در منابع مرتبط با Story قرار بگیرند.

۱۰. نادیده گرفتن نقش تستر هنگام بررسی Story

اگر تستر فقط زمانی User Story را ببیند که توسعه تمام شده باشد، بخشی از فرصت شناسایی مشکلات زودهنگام از دست می‌رود.

حضور تستر در بررسی Story می‌تواند کمک کند:

• ابهام‌ها زودتر شناسایی شوند.
• سناریوهای مهم از ابتدا مورد توجه قرار گیرند.
• Testability بررسی شود.
• ریسک‌های مهم پیش از توسعه مطرح شوند.

به همین دلیل، بررسی User Story نباید صرفاً فعالیتی مربوط به Product Owner یا Developer در نظر گرفته شود.

جمع‌بندی اشتباهات رایج

در یک User Story خوب باید ارتباط منطقی بین کاربر، هدف و ارزش قابل درک باشد و در عین حال، اطلاعات لازم برای تحلیل و تست قابلیت نیز فراهم باشد.

از طرف دیگر، نباید برای رفع هر ابهامی، User Story را به یک سند فنی بسیار طولانی تبدیل کرد.

برای تستر، یک سؤال کلیدی این است:

«آیا از روی این Story و اطلاعات مرتبط با آن می‌توانم بفهمم چه چیزی باید بررسی شود و چه ابهام‌هایی هنوز باید برطرف شوند؟»

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

User Story در Agile و Scrum چه جایگاهی دارد؟

User Story یکی از روش‌های رایج برای بیان نیازهای محصول در تیم‌های چابک است. در محیط‌های Agile، نیازها می‌توانند به بخش‌های کوچک‌تر تقسیم شوند و در طول فرآیند توسعه، با گفت‌وگو و همکاری تیم به‌تدریج شفاف‌تر شوند.

در Scrum نیز User Story معمولاً یکی از روش‌های رایج برای بیان آیتم‌های Product Backlog است. البته مهم است که User Story را با Scrum یکی ندانیم؛ User Story یک روش برای بیان نیاز است، در حالی که Scrum یک چارچوب کاری است.

User Story در Product Backlog

Product Backlog مجموعه‌ای مرتب‌شده از کارهایی است که برای توسعه و بهبود محصول در نظر گرفته شده‌اند و User Story می‌تواند یکی از آیتم‌های آن باشد.

برای مثال، در یک فروشگاه اینترنتی ممکن است Storyهایی مانند این وجود داشته باشند:

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

این Storyها می‌توانند در Product Backlog قرار بگیرند و بر اساس اولویت محصول مرتب شوند.

User Story در Backlog Refinement

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

در این مرحله ممکن است موضوعاتی مانند موارد زیر بررسی شوند:

• هدف Story
• محدوده کار
• ابهام‌های موجود
• وابستگی‌ها
• اندازه و پیچیدگی
• قابلیت تست

اینجا یکی از مهم‌ترین نقاط حضور تستر در چرخه User Story است.

برای مثال، درباره یک Story مربوط به پرداخت، تستر ممکن است بپرسد:

اگر پرداخت ناموفق باشد، سفارش در چه وضعیتی قرار می‌گیرد؟

یا:

اگر تراکنش بانکی موفق شود اما پاسخ آن به سیستم ما نرسد، انتظار داریم چه اتفاقی بیفتد؟

این سؤال‌ها می‌توانند قبل از شروع توسعه، ابهام‌ها و ریسک‌های مهم را آشکار کنند.

User Story در Sprint

در Scrum، Storyهایی که برای یک Sprint انتخاب می‌شوند باید به اندازه کافی برای تیم قابل فهم باشند تا بتوان روی آن‌ها کار کرد.

در جریان Sprint، توسعه و تست لزوماً دو مرحله کاملاً جدا و پشت‌سرهم نیستند. با این حال، می‌توان مسیر کلی یک Story را به شکل ساده این‌گونه تصور کرد:

Product Backlog → Refinement → Sprint Planning → Development → Testing → Done

در عمل، فرآیند واقعی هر تیم ممکن است متفاوت باشد و فعالیت‌های تست و توسعه نیز می‌توانند هم‌زمان یا به‌صورت تکرارشونده انجام شوند.

User Story و Definition of Done

یکی از مفاهیم مرتبط در Scrum، Definition of Done یا DoD است.

DoD مجموعه‌ای از معیارهای مورد توافق تیم است که مشخص می‌کند چه زمانی یک آیتم واقعاً می‌تواند «Done» در نظر گرفته شود.

برای مثال، ممکن است یک تیم در DoD خود مواردی مانند این داشته باشد:

• توسعه قابلیت انجام شده باشد.
• Code Review انجام شده باشد.
• تست‌های لازم اجرا شده باشند.
• مشکلات مهم برطرف شده باشند.
• قابلیت در محیط موردنظر قابل استفاده باشد.

بنابراین، صرف اینکه Developer کدنویسی یک User Story را تمام کرده باشد، لزوماً به این معنا نیست که آن Story آماده یا Done است.

از دید تستر، این موضوع اهمیت زیادی دارد؛ زیرا Testing می‌تواند بخشی از شرایط لازم برای رسیدن یک Story به وضعیت Done باشد.

نقش تستر در چرخه User Story

اگر چرخه User Story را از دید یک تستر نگاه کنیم، نقش او می‌تواند از مراحل ابتدایی شروع شود:

بررسی Story
شناسایی ابهام‌ها، ریسک‌ها و مشکلات Testability

↓

Refinement
مطرح کردن سؤال‌های مرتبط با رفتار مورد انتظار و قابلیت تست

↓

آماده‌سازی تست
شناسایی Test Scenarioها و طراحی Test Caseهای موردنیاز

↓

اجرای تست
مقایسه رفتار واقعی سیستم با رفتار مورد انتظار

↓

بازخورد
انتقال نتایج تست، مشکلات و ابهام‌های جدید به تیم

این چرخه نشان می‌دهد که نقش تستر در ارتباط با User Story فقط نوشتن Test Case پس از پایان توسعه نیست. تستر می‌تواند از مراحل اولیه، روی شفافیت نیاز و Testability قابلیت تأثیر بگذارد.

نکته مهم: User Story فقط مخصوص Scrum نیست

User Story را نباید یک مفهوم انحصاری Scrum دانست.

به‌طور خلاصه:

User Story ≠ Scrum

User Story روشی برای بیان نیاز کاربر است و می‌تواند در محیط‌ها و روش‌های مختلف توسعه چابک استفاده شود.

چه کسی User Story را می‌نویسد و آیا تستر هم می‌تواند در آن نقش داشته باشد؟

یکی از سؤال‌های رایج درباره User Story این است که چه کسی مسئول نوشتن آن است؟

پاسخ به ساختار و فرآیند هر تیم بستگی دارد. در یک تیم ممکن است Product Owner نقش پررنگ‌تری داشته باشد، در تیم دیگر Business Analyst بیشتر در تحلیل و شکل‌گیری Story مشارکت کند و در برخی تیم‌ها نیز User Story با همکاری چند نفر از اعضای تیم شکل بگیرد.

بنابراین، بهتر است User Story را فقط یک متن نوشته‌شده توسط یک نفر ندانیم؛ بلکه در بسیاری از تیم‌ها، شکل‌گیری یک Story خوب نتیجه همکاری و گفت‌وگو بین افراد مختلف است.

نقش Product Owner

در Scrum، Product Owner مسئول بیشینه کردن ارزش محصول و مدیریت Product Backlog است. به همین دلیل، معمولاً نقش مهمی در تعریف و اولویت‌بندی نیازهایی دارد که ممکن است به شکل User Story در Backlog قرار بگیرند.

برای مثال، Product Owner ممکن است نیاز زیر را مطرح کند:

به‌عنوان مشتری، می‌خواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، بتوانم خرید خود را متوقف کنم.

اما این به این معنا نیست که تمام جزئیات Story باید توسط یک نفر و بدون گفت‌وگو با سایر اعضای تیم مشخص شود. گفت‌وگو با تیم توسعه و تست می‌تواند به شفاف‌تر شدن نیاز کمک کند.

نقش Business Analyst

در برخی سازمان‌ها، Business Analyst نقش مهمی در تحلیل نیازها و تبدیل آن‌ها به User Story دارد.

Business Analyst می‌تواند با بررسی نیازهای کسب‌وکار و گفت‌وگو با ذی‌نفعان، به روشن شدن مواردی مانند این کمک کند:

• کاربر چه مشکلی دارد؟
• هدف موردنظر چیست؟
• چه فرآیندی باید پشتیبانی شود؟
• چه محدودیت‌ها یا قوانین کسب‌وکاری وجود دارند؟

در چنین شرایطی، User Story می‌تواند یکی از خروجی‌های فعالیت تحلیل نیاز باشد.

نقش تستر نرم‌افزار

تستر معمولاً مالک اصلی Product Backlog یا User Story نیست، اما می‌تواند نقش مهمی در بررسی، شفاف‌سازی و قابل تست شدن آن داشته باشد.

برای مثال، تستر ممکن است هنگام بررسی Story سؤال‌هایی مانند این مطرح کند:

اگر کاربر اطلاعات نامعتبر وارد کند، چه اتفاقی باید بیفتد؟

آیا این قابلیت برای تمام نقش‌های کاربری در دسترس است؟

اگر سرویس وابسته در دسترس نباشد، رفتار مورد انتظار چیست؟

این سؤال‌ها می‌توانند باعث شوند User Story یا اطلاعات مرتبط با آن شفاف‌تر شوند.

بنابراین، نقش تستر فقط دریافت یک Story و تبدیل آن به Test Case نیست. تستر می‌تواند با شناسایی ابهام‌ها، سناریوهای احتمالی، ریسک‌ها و مشکلات Testability، به بهبود کیفیت Story کمک کند.

آیا تستر می‌تواند User Story بنویسد؟

بله. هیچ قانون عمومی وجود ندارد که بگوید تستر نباید در نوشتن یا اصلاح User Story مشارکت کند.

بسته به ساختار تیم، ممکن است Tester، QA، Business Analyst، Product Owner یا سایر اعضای تیم در نوشتن و اصلاح Story مشارکت داشته باشند.

اما یک نکته مهم وجود دارد:

مشارکت در نوشتن User Story با تصمیم‌گیری درباره نیاز محصول یکسان نیست.

برای مثال، تستر می‌تواند بگوید:

«این Story درباره لغو سفارش است، اما مشخص نیست سفارش ارسال‌شده قابل لغو هست یا خیر.»

اما نباید بدون هماهنگی خودش تصمیم بگیرد:

«پس سفارش ارسال‌شده نباید قابل لغو باشد.»

نقش تستر این است که ابهام را شناسایی و مطرح کند. تصمیم درباره رفتار مورد انتظار محصول باید توسط افراد و نقش‌های مسئول محصول و ذی‌نفعان مرتبط مشخص شود.

همکاری Product، Development و QA

یک User Story زمانی ارزش بیشتری پیدا می‌کند که اعضای مختلف تیم درباره آن به درک مشترک برسند.

1. Product: نیاز و ارزش مورد انتظار را توضیح می‌دهد.
2. Development: درباره امکان پیاده‌سازی و پیچیدگی فنی بازخورد می‌دهد.
3. QA / Tester: ابهام‌ها، سناریوهای مختلف، ریسک‌ها و Testability را بررسی می‌کند.
4. Team: به درک مشترکی از چیزی که باید ساخته و بررسی شود می‌رسد.

این همکاری یکی از مزیت‌های مهم استفاده از User Story در تیم‌های Agile است.

پس چه کسی «مالک» User Story است؟

بهتر است بین مشارکت در نوشتن Story و مالکیت نیاز محصول تفاوت قائل شویم.

ممکن است چند نفر در نوشتن و اصلاح یک User Story مشارکت داشته باشند، اما مسئولیت محصول و اولویت‌بندی Backlog معمولاً با نقش مسئول محصول، مانند Product Owner، مرتبط است.

به همین دلیل، شاید سؤال دقیق‌تر این نباشد که:

چه کسی User Story را می‌نویسد؟

بلکه بهتر باشد بپرسیم:

چه کسانی باید برای شکل‌گیری یک User Story خوب با یکدیگر همکاری کنند؟

در یک تیم، پاسخ می‌تواند شامل Product، تحلیل کسب‌وکار، Development و QA باشد؛ هرچند ساختار و مسئولیت‌ها در سازمان‌های مختلف متفاوت هستند.

تفاوت User Story و Use Case چیست؟

User Story و Use Case هر دو می‌توانند برای بیان نیازها و تعامل کاربر با سیستم استفاده شوند، اما هدف و میزان جزئیات آن‌ها یکسان نیست.

به‌صورت ساده:

User Story معمولاً نیاز و هدف کاربر را به‌صورت کوتاه بیان می‌کند، در حالی که Use Case تعامل کاربر با سیستم را با جزئیات بیشتری توصیف می‌کند.

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

User Story کوتاه و متمرکز بر ارزش کاربر است

برای مثال:

به‌عنوان مشتری، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا دوباره به حساب کاربری خود دسترسی داشته باشم.

این User Story به‌طور خلاصه مشخص می‌کند:

• چه کسی؟
• چه چیزی؟
• چرا؟

اما جزئیات تعامل کاربر با سیستم را توضیح نمی‌دهد.

Use Case جزئیات تعامل را بیان می‌کند

برای همین قابلیت، یک Use Case می‌تواند اطلاعات بیشتری ارائه دهد:

در نتیجه، Use Case می‌تواند جزئیات بیشتری از تعامل Actor با سیستم و مسیرهای مختلف اجرا ارائه دهد.

مقایسه User Story و Use Case

ویژگی	User Story	Use Case
تمرکز اصلی	نیاز و هدف کاربر	تعامل کاربر با سیستم
میزان جزئیات	معمولاً کم	معمولاً بیشتر
قالب	معمولاً As a / I want / So that	Actor، پیش‌شرط، Flow و…
تمرکز بر ارزش	زیاد	معمولاً کمتر
جریان‌های جایگزین	معمولاً در خود Story نمی‌آیند	معمولاً قابل ثبت هستند
کاربرد برای تست	نقطه شروع تحلیل	منبع جزئی‌تر برای استخراج سناریو

این جدول یک مقایسه کلی است و در پروژه‌های مختلف ممکن است نحوه استفاده از این دو مفهوم متفاوت باشد.

آیا User Story جایگزین Use Case است؟

لزوماً نه. این دو می‌توانند مکمل یکدیگر باشند.

برای مثال، User Story می‌تواند نیاز را در سطح بالا بیان کند:

به‌عنوان مشتری، می‌خواهم بتوانم سفارش خود را لغو کنم تا در صورت نیاز خرید خود را متوقف کنم.

سپس Use Case می‌تواند جزئیات تعامل کاربر و سیستم را برای همین قابلیت مشخص کند.

این موضوع برای تستر مفید است؛ زیرا User Story به او کمک می‌کند هدف و ارزش قابلیت را درک کند و Use Case، در صورت وجود، می‌تواند اطلاعات بیشتری درباره جریان‌ها و حالت‌های مختلف تعامل ارائه دهد.

از دید تستر، کدام‌یک مهم‌تر است؟

نمی‌توان گفت همیشه یکی از این دو مهم‌تر است.

اگر تیم فقط User Story داشته باشد، تستر می‌تواند از آن به‌عنوان نقطه شروع تحلیل استفاده کند و برای جزئیات بیشتر سؤال مطرح کند.

اگر Use Case نیز وجود داشته باشد، ممکن است اطلاعات بیشتری درباره موارد زیر در اختیار تستر قرار گیرد:

• جریان اصلی
• جریان‌های جایگزین
• شرایط خطا
• Actorها
• پیش‌شرط‌ها

در نهایت، تستر باید از تمام منابع معتبر اطلاعاتی موجود برای درک رفتار مورد انتظار سیستم استفاده کند.

تفاوت اصلی را چگونه به خاطر بسپاریم؟

می‌توان تفاوت این دو را به شکل ساده این‌گونه در نظر گرفت:

User Story بیشتر می‌گوید: کاربر چه می‌خواهد و چرا؟

در حالی که:

Use Case بیشتر توضیح می‌دهد: کاربر چگونه با سیستم تعامل می‌کند تا به هدف خود برسد؟

البته این مرزبندی مطلق نیست و نحوه استفاده از این مفاهیم در تیم‌ها و روش‌های کاری مختلف می‌تواند متفاوت باشد.

برای یک تستر، مهم‌تر از حفظ کردن تعریف‌ها این است که بداند هر کدام چه اطلاعاتی برای تحلیل و طراحی تست در اختیار او قرار می‌دهند.

مثال کامل؛ بررسی یک User Story از دید تستر

تا اینجا دیدیم که User Story نیاز و هدف کاربر را بیان می‌کند و تستر می‌تواند از آن به‌عنوان نقطه شروع تحلیل تست استفاده کند. حالا یک مثال را از ابتدا تا انتها بررسی کنیم تا ببینیم این تحلیل در عمل چگونه انجام می‌شود.

فرض کنید یک فروشگاه اینترنتی قابلیتی برای لغو سفارش توسط مشتری در نظر گرفته است.

مرحله اول: User Story

User Story می‌تواند به این شکل نوشته شود:

به‌عنوان مشتری، می‌خواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، بتوانم خرید خود را متوقف کنم.

در این مرحله تستر می‌داند:

• کاربر موردنظر مشتری است.
• قابلیت موردنظر لغو سفارش است.
• هدف کاربر متوقف کردن خرید در صورت تغییر تصمیم است.

اما هنوز مشخص نیست سیستم در همه شرایط چگونه باید رفتار کند.

مرحله دوم: بررسی اولیه توسط تستر

تستر هنگام بررسی Story ممکن است سؤال‌هایی مانند این مطرح کند:

• آیا هر سفارشی قابل لغو است؟
• آیا سفارش ارسال‌شده را هم می‌توان لغو کرد؟
• آیا لغو سفارش فقط تا قبل از ارسال امکان‌پذیر است؟
• اگر سفارش شامل چند کالا باشد، امکان لغو بخشی از سفارش وجود دارد؟
• پس از لغو، وضعیت سفارش چه خواهد شد؟
• مبلغ پرداخت‌شده چگونه بازگردانده می‌شود؟
• اگر فرآیند بازگشت وجه با خطا مواجه شود، چه اتفاقی می‌افتد؟

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

مرحله سوم: مشخص شدن رفتار مورد انتظار

فرض کنیم پس از گفت‌وگو با افراد مرتبط مشخص شود:

• سفارش فقط تا قبل از ارسال قابل لغو است.
• سفارش ارسال‌شده قابل لغو نیست.
• پس از لغو، وضعیت سفارش به «لغوشده» تغییر می‌کند.
• اگر مبلغ سفارش قبلاً پرداخت شده باشد، فرآیند بازگشت وجه آغاز می‌شود.

اکنون تستر اطلاعات بیشتری برای تحلیل و طراحی سناریوهای تست دارد.

مرحله چهارم: استخراج Test Scenario

بر اساس اطلاعات موجود، می‌توان سناریوهایی مانند این را شناسایی کرد:

سناریوی موفق

لغو سفارش پرداخت‌نشده قبل از ارسال

سناریوی موفق دیگر

لغو سفارش پرداخت‌شده قبل از ارسال

سناریوی ناموفق

تلاش برای لغو سفارش پس از ارسال

سناریوی دیگر

تلاش برای لغو سفارشی که قبلاً لغو شده است

سناریوی مرتبط با بازگشت وجه

بررسی وضعیت سفارش پس از لغو سفارش پرداخت‌شده

این‌ها هنوز Test Case کامل نیستند؛ بلکه مشخص می‌کنند چه حالت‌هایی باید بررسی شوند.

مرحله پنجم: تبدیل سناریو به Test Case

فرض کنیم این سناریو را انتخاب کرده‌ایم:

لغو سفارش پرداخت‌شده قبل از ارسال

یک Test Case می‌تواند شامل جزئیاتی مانند موارد زیر باشد:

پیش‌شرط:

یک مشتری دارای سفارش پرداخت‌شده‌ای باشد که هنوز ارسال نشده است.

مراحل کلی:

1. ورود به حساب کاربری
2. باز کردن سفارش موردنظر
3. انتخاب گزینه لغو سفارش
4. تأیید لغو

نتیجه مورد انتظار:

• سفارش با موفقیت لغو شود.
• وضعیت سفارش به «لغوشده» تغییر کند.
• در صورت وجود پرداخت، فرآیند بازگشت وجه طبق رفتار تعریف‌شده آغاز شود.

در این مرحله، سناریوی کلی به یک تست مشخص و قابل اجرا تبدیل شده است.

مرحله ششم: بررسی حالت‌های منفی

حالا تستر باید بررسی کند که سیستم در شرایط نامعتبر نیز رفتار مورد انتظار را دارد یا خیر.

برای مثال:

مشتری تلاش می‌کند یک سفارش ارسال‌شده را لغو کند.

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

مرحله هفتم: پیدا کردن یک ابهام جدید

تحلیل User Story همیشه یک مسیر کاملاً خطی نیست. ممکن است هنگام بررسی سناریوها، سؤال‌های جدیدی پیدا شوند.

برای مثال:

اگر دو درخواست به‌صورت هم‌زمان برای لغو یک سفارش ارسال شوند، رفتار مورد انتظار سیستم چیست؟

این سؤال ممکن است در ابتدا مطرح نشده باشد، اما هنگام تحلیل عمیق‌تر قابلیت ظاهر شود.

در این شرایط نیز تستر نباید خودش پاسخ را تعیین کند. این موضوع باید بر اساس رفتار مورد انتظار محصول مشخص شود.

چیزی که از این مثال باید یاد بگیریم

مسیر تحلیل در این مثال به شکل زیر بود:

User Story
↓
شناسایی ابهام‌ها
↓
شفاف شدن رفتار مورد انتظار
↓
استخراج Test Scenario
↓
طراحی Test Case
↓
اجرای تست

این مثال نشان می‌دهد که User Story برای تستر فقط یک متن در Product Backlog نیست. تستر می‌تواند با تحلیل آن، قبل از شروع اجرای تست، ابهام‌ها، سناریوهای مهم و برخی ریسک‌های احتمالی را شناسایی کند.

در عین حال، نباید انتظار داشته باشیم تمام Test Caseها فقط از یک جمله User Story استخراج شوند. تستر باید در کنار User Story، اطلاعات معتبر دیگری را نیز بررسی کند و هرجا اطلاعات کافی وجود ندارد، سؤال مناسب را مطرح کند.

چک‌لیست بررسی User Story برای تستر نرم‌افزار

تستر می‌تواند قبل از شروع تحلیل و طراحی تست، User Story را با یک چک‌لیست ساده بررسی کند. هدف این چک‌لیست این نیست که تستر صرفاً Story را «تأیید» یا «رد» کند؛ بلکه کمک می‌کند ابهام‌ها، ریسک‌ها و مشکلات مربوط به Testability زودتر شناسایی شوند.

چک‌لیست تحلیل User Story

هنگام بررسی یک User Story، تستر می‌تواند این سؤال‌ها را مطرح کند:

• آیا نقش یا نوع کاربر مشخص است؟
• آیا هدف کاربر به‌وضوح بیان شده است؟
• آیا ارزش یا دلیل ایجاد قابلیت مشخص است؟
• آیا محدوده User Story مشخص است؟
• آیا Story بیش از حد بزرگ یا پیچیده نیست؟
• آیا وابستگی مهمی وجود دارد؟
• آیا رفتار مورد انتظار سیستم در حالت‌های مهم مشخص است؟
• آیا عبارت یا مفهوم مبهمی در Story وجود دارد؟
• آیا می‌توان بر اساس اطلاعات موجود، سناریوهای تست را شناسایی کرد؟
• آیا نتیجه مورد انتظار در سناریوهای اصلی قابل تشخیص است؟
• آیا سناریوهای منفی یا خطاهای مهم نیاز به بررسی دارند؟
• آیا شرایط مرزی مهمی وجود دارد؟
• آیا محدودیت یا قانون کسب‌وکاری مهمی وجود دارد که باید مشخص شود؟
• آیا اطلاعات موردنیاز برای طراحی تست در دسترس است؟
• آیا موردی وجود دارد که تستر مجبور باشد برای ادامه کار آن را حدس بزند؟

اگر پاسخ بعضی از سؤال‌ها «خیر» باشد، چه کنیم؟

منفی بودن پاسخ به یکی از موارد چک‌لیست، لزوماً به این معنا نیست که User Story بد است.

ممکن است خود Story کوتاه باشد، اما اطلاعات موردنیاز در منابع دیگری وجود داشته باشند. مسئله زمانی جدی می‌شود که نبود اطلاعات باعث شود اعضای تیم برداشت‌های متفاوتی از رفتار مورد انتظار سیستم داشته باشند یا تستر برای طراحی تست مجبور به حدس زدن شود.

در چنین شرایطی، تستر باید ابهام را مطرح کند و برای مشخص شدن رفتار مورد انتظار با افراد مرتبط همکاری کند.

چک‌لیست نباید به یک فرآیند مکانیکی تبدیل شود

هدف این نیست که برای هر User Story، بدون فکر کردن، ده‌ها مورد را تیک بزنیم.

هدف اصلی چک‌لیست، ایجاد یک نگاه تحلیلی در تستر است.

در عمل، هنگام خواندن User Story می‌توان چهار سؤال اصلی را در ذهن داشت:

چه چیزی مشخص است؟

چه چیزی مشخص نیست؟

چه چیزی باید تست شود؟

برای طراحی تست به چه اطلاعات بیشتری نیاز دارم؟

اگر تستر بتواند به این چهار سؤال پاسخ مناسبی بدهد، چک‌لیست عملاً وظیفه اصلی خود را انجام داده است.

این چک‌لیست را چه زمانی استفاده کنیم؟

بررسی User Story می‌تواند در زمان‌هایی مانند موارد زیر انجام شود:

• Backlog Refinement
• قبل از Sprint Planning
• پیش از شروع تحلیل و طراحی تست

هرچه ابهام‌ها زودتر شناسایی شوند، احتمال اینکه تیم بعداً مجبور به تغییر کد، بازنویسی تست‌ها یا اصلاح برداشت خود از نیاز شود کمتر خواهد بود.

به همین دلیل، بررسی User Story را می‌توان بخشی از یک رویکرد پیشگیرانه در تست نرم‌افزار دانست؛ یعنی تستر فقط منتظر آماده شدن نرم‌افزار برای اجرا نمی‌ماند، بلکه از مراحل اولیه نیز در بهبود کیفیت نقش دارد.

جمع‌بندی

داستان کاربر یا User Story روشی ساده برای بیان نیاز، هدف و ارزش مورد انتظار کاربر است. قالب رایج آن با عباراتی مانند «به‌عنوان… می‌خواهم… تا…» نوشته می‌شود تا نیاز محصول از دید کاربر بیان شود.

اما برای تستر نرم‌افزار، User Story فقط یک جمله در Product Backlog نیست.

تستر می‌تواند از همان مرحله بررسی Story به دنبال پاسخ این سؤال‌ها باشد:

• کاربر چه کسی است؟
• چه هدفی دارد؟
• این قابلیت چه ارزشی ایجاد می‌کند؟
• محدوده Story چیست؟
• چه رفتارهایی باید بررسی شوند؟
• چه سناریوهای مثبت و منفی وجود دارند؟
• آیا شرایط مرزی مهمی وجود دارد؟
• چه ابهام‌هایی هنوز باقی مانده‌اند؟
• آیا Story قابل تست است؟

یک User Story معمولاً مستقیماً به یک Test Case تبدیل نمی‌شود. مسیر منطقی‌تر می‌تواند این باشد:

User Story → تحلیل نیاز → شناسایی سناریوها → Test Scenario → Test Case → Test Execution

در این مسیر، نقش تستر فقط اجرای تست نیست. تستر می‌تواند با پرسیدن سؤال‌های درست، شناسایی ابهام‌ها و بررسی Testability به تیم کمک کند قبل از پیاده‌سازی، درک مشترک بهتری از قابلیت داشته باشد.

از طرف دیگر، User Story به‌تنهایی تمام اطلاعات لازم برای تست را در اختیار تستر قرار نمی‌دهد. بنابراین، تستر باید در کنار آن، سایر منابع معتبر اطلاعاتی را نیز بررسی کند و هرجا رفتار مورد انتظار مشخص نیست، به‌جای حدس زدن، موضوع را با تیم مطرح کند.

مهم‌ترین نکته

اگر بخواهیم کل مقاله را در یک جمله خلاصه کنیم:

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

منابع و مراجع

برای مطالعه بیشتر درباره User Story، Agile، Scrum و مفاهیم مرتبط، می‌توانید از منابع زیر استفاده کنید:

• Scrum.org – What is a User Story?
• The Scrum Guide
• Agile Alliance – User Stories
• Bill Wake – INVEST in Good Stories, and SMART Tasks
• ISTQB – International Software Testing Qualifications Board

سؤالات متداول درباره User Story در تست نرم‌افزار

آیا User Story همان Requirement است؟

خیر. User Story یکی از روش‌های بیان نیاز است و معمولاً نیاز و هدف کاربر را به‌صورت کوتاه و قابل گفت‌وگو بیان می‌کند. Requirement مفهوم گسترده‌تری دارد و ممکن است شامل قوانین کسب‌وکار، نیازهای عملکردی و غیرعملکردی، محدودیت‌ها و جزئیات دیگری نیز باشد.

آیا هر User Story باید Acceptance Criteria داشته باشد؟

در بسیاری از پروژه‌ها، Acceptance Criteria به شفاف شدن رفتار مورد انتظار و شرایط قابل قبول کمک می‌کند. User Story ممکن است هدف کلی کاربر را بیان کند، اما Acceptance Criteria می‌تواند مشخص کند قابلیت در شرایط مختلف چه رفتاری باید داشته باشد و چه زمانی قابل قبول محسوب می‌شود.

آیا تستر باید User Story را بنویسد؟

تستر معمولاً مالک Product Backlog یا مسئول اصلی تصمیم‌گیری درباره نیاز محصول نیست، اما می‌تواند در نوشتن، بررسی و اصلاح User Story مشارکت داشته باشد. نقش مهم تستر شناسایی ابهام‌ها، بررسی Testability، مطرح کردن سناریوهای مهم و کمک به شفاف شدن رفتار مورد انتظار است.

آیا یک User Story برابر با یک Test Case است؟

خیر. یک User Story می‌تواند چند رفتار و سناریوی مختلف داشته باشد و هر Test Scenario نیز ممکن است به یک یا چند Test Case تبدیل شود. معمولاً مسیر به شکل User Story، تحلیل نیاز، شناسایی سناریوها و سپس طراحی Test Case است.

تستر چگونه از User Story سناریوی تست استخراج می‌کند؟

تستر ابتدا هدف و رفتار مورد انتظار را درک می‌کند، سپس مسیرهای اصلی، حالت‌های منفی، شرایط مرزی، وابستگی‌ها و ریسک‌های احتمالی را بررسی می‌کند. User Story نقطه شروع تحلیل است و تستر ممکن است برای تکمیل تحلیل خود به قوانین کسب‌وکار، Acceptance Criteria و سایر اطلاعات مرتبط نیز نیاز داشته باشد.

Testable بودن User Story به چه معناست؟

Testable بودن یعنی رفتار و معیارهای موردنیاز آن‌قدر روشن باشند که تیم بتواند مشخص کند چه چیزی باید بررسی شود و چه نتیجه‌ای قابل قبول است. این موضوع به معنی وجود تمام Test Caseها در خود User Story نیست.

اگر User Story مبهم باشد، تستر چه کاری باید انجام دهد؟

تستر نباید رفتار نامشخص سیستم را بر اساس فرض شخصی تعیین کند. بهتر است ابهام را شناسایی کرده و سؤال‌های مناسب را با Product Owner، Business Analyst، Developer یا سایر افراد مرتبط مطرح کند تا رفتار مورد انتظار مشخص شود.

آیا User Story فقط در Scrum استفاده می‌شود؟

خیر. User Story یک روش برای بیان نیاز کاربر است و فقط به Scrum محدود نمی‌شود. اگرچه در بسیاری از تیم‌های Scrum، User Story به‌عنوان یکی از روش‌های رایج برای بیان آیتم‌های Product Backlog استفاده می‌شود، اما خود Scrum الزام نمی‌کند که تمام نیازها حتماً به شکل User Story نوشته شوند.

تفاوت اصلی User Story و Use Case چیست؟

User Story معمولاً به‌صورت کوتاه بیان می‌کند کاربر چه چیزی می‌خواهد و چرا آن را می‌خواهد. Use Case معمولاً جزئیات بیشتری درباره تعامل Actor با سیستم، جریان اصلی، پیش‌شرط‌ها و جریان‌های جایگزین ارائه می‌دهد. هر دو می‌توانند برای تحلیل و طراحی تست مفید باشند.