PRD چیست؟ راهنمای سند نیازمندی‌های محصول

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

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

یکی از مستنداتی که می‌تواند به ایجاد درک مشترک میان اعضای تیم کمک کند، PRD یا Product Requirements Document است.

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

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

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

در این مقاله بررسی می‌کنیم که PRD چیست، چه بخش‌هایی دارد، چه تفاوتی با BRD و SRS دارد و مهم‌تر از همه، یک تستر یا QA هنگام کار با PRD دقیقاً باید به چه مواردی توجه کند و چگونه می‌تواند از آن در فرآیند تست استفاده کند.

Table of Contents

PRD چیست؟

PRD مخفف Product Requirements Document و به معنی سند نیازمندی‌های محصول است.

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

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

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

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

مشکل فعلی کاربران چیست؟
چرا حل این مشکل اهمیت دارد؟
کاربران هدف چه کسانی هستند؟
قابلیت بازیابی رمز عبور باید چه کاری انجام دهد؟
چه مواردی در محدوده این Feature قرار دارند؟
چه مواردی فعلاً خارج از محدوده هستند؟
چه وابستگی‌ها یا محدودیت‌هایی وجود دارد؟
چگونه مشخص می‌کنیم که این Feature به هدف خود رسیده است؟

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

به این مثال توجه کنید:

«یک صفحه برای بازیابی رمز عبور ایجاد شود.»

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

حالا همین موضوع را در قالبی نزدیک‌تر به نگاه محصول ببینید:

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

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

PRD فقط یک سند ثابت نیست

با وجود نام Product Requirements Document، PRD همیشه به شکل یک فایل Word یا یک سند رسمی و طولانی وجود ندارد.

بسته به نوع سازمان و روش توسعه محصول، اطلاعات مربوط به PRD ممکن است:

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

بنابراین، مهم‌تر از قالب PRD، اطلاعاتی است که در اختیار تیم قرار می‌دهد.

سؤال اصلی این نیست که:

«آیا ما سندی با عنوان PRD داریم؟»

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

«آیا تیم درک روشنی از مسئله، کاربران، اهداف، محدوده و نیازمندی‌های محصول دارد؟»

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

PRD چه سطحی از جزئیات دارد؟

میزان جزئیات PRD در همه پروژه‌ها یکسان نیست.

یک PRD ممکن است در سطح محصول یا یک قابلیت بزرگ نوشته شود و اطلاعاتی مانند هدف، کاربران، Scope و معیارهای موفقیت را پوشش دهد. در مقابل، جزئیات دقیق‌تر ممکن است در User Storyها، Acceptance Criteria، SRS، مستندات فنی یا طراحی سیستم ثبت شوند.

به همین دلیل، نباید انتظار داشت PRD همیشه تمام پاسخ‌های موردنیاز تیم توسعه یا تست را در خود داشته باشد.

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

تستر ممکن است پس از مطالعه PRD، برای رسیدن به جزئیات بیشتر به مواردی مانند User Story، Acceptance Criteria، مستندات طراحی، SRS یا گفت‌وگو با اعضای تیم نیاز داشته باشد.

در بخش‌های بعدی مقاله، دقیق‌تر بررسی می‌کنیم که این ارتباط چگونه شکل می‌گیرد و یک تستر چگونه می‌تواند اطلاعات موجود در PRD را به Test Scenario و در نهایت Test Case تبدیل کند.

PRD چه هدفی دارد؟

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

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

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

این Feature چه ارزشی برای کاربر یا کسب‌وکار ایجاد می‌کند؟

توسعه‌دهنده ممکن است بپرسد:

دقیقاً چه چیزی باید ساخته شود و چه محدودیت‌هایی وجود دارد؟

طراح ممکن است به این موضوع فکر کند:

کاربر چگونه با این قابلیت تعامل خواهد داشت؟

و تستر ممکن است بپرسد:

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

PRD می‌تواند به این افراد کمک کند تا پیش از ورود به جزئیات تخصصی خود، تصویر مشترکی از Feature یا محصول داشته باشند.

ایجاد درک مشترک

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

فرض کنید در یک جلسه گفته شود:

«باید فرآیند ثبت سفارش را ساده‌تر کنیم.»

این جمله می‌تواند برای افراد مختلف معانی متفاوتی داشته باشد.

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

PRD می‌تواند مشخص کند که منظور دقیق‌تر چیست.

«هدف این تغییر، کاهش تعداد مراحلی است که کاربر برای تکمیل سفارش طی می‌کند. فرآیند ثبت سفارش باید از پنج مرحله به حداکثر سه مرحله کاهش پیدا کند، بدون اینکه اطلاعات ضروری سفارش حذف شوند.»

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

مشخص کردن مسئله قبل از تمرکز بر راه‌حل

یکی دیگر از اهداف مهم PRD این است که تیم ابتدا روی مسئله تمرکز کند.

گاهی یک نیازمندی مستقیماً به شکل یک راه‌حل مطرح می‌شود:

«یک دکمه جدید به صفحه اضافه کنیم.»

اما سؤال مهم‌تر این است:

«چه مسئله‌ای قرار است با اضافه کردن این دکمه حل شود؟»

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

تمرکز PRD بر مسئله کمک می‌کند تیم صرفاً اولین راه‌حلی را که به ذهنش می‌رسد پیاده‌سازی نکند.

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

«آیا دکمه درست کار می‌کند؟»

اما وقتی مسئله و هدف محصول را نیز بداند، می‌تواند سؤال گسترده‌تری مطرح کند:

«آیا این Feature واقعاً به حل مسئله‌ای که برای آن طراحی شده کمک می‌کند؟»

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

مشخص کردن محدوده محصول یا Feature

PRD همچنین می‌تواند مشخص کند که یک Feature چه چیزهایی را شامل می‌شود و چه چیزهایی فعلاً در محدوده آن نیستند.

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

برای مثال، در Feature بازیابی رمز عبور ممکن است مشخص شود:

در محدوده:

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

خارج از محدوده:

بازیابی از طریق پیامک.
ورود بدون رمز عبور.
احراز هویت چندمرحله‌ای.

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

البته Out of Scope بودن یک قابلیت به معنی نادیده گرفتن تأثیر آن نیست. برای مثال، اگر قابلیتی خارج از محدوده تغییر باشد اما تحت تأثیر تغییرات جدید قرار گیرد، ممکن است همچنان نیاز به بررسی یا Regression Testing داشته باشد.

ایجاد مبنایی برای تصمیم‌گیری

PRD می‌تواند به تیم کمک کند درباره Feature تصمیم‌های آگاهانه‌تری بگیرد.

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

برای مثال، اگر در میانه توسعه Feature بازیابی رمز عبور، پیشنهاد شود امکان ورود با اثر انگشت نیز اضافه شود، تیم می‌تواند بررسی کند:

آیا این قابلیت با هدف فعلی PRD ارتباط دارد؟
آیا بخشی از Scope اولیه است؟
آیا اضافه شدن آن در این مرحله ارزش و اولویت لازم را دارد؟
چه تأثیری بر زمان، ریسک و پیچیدگی پروژه خواهد داشت؟

بنابراین PRD فقط برای شروع توسعه نوشته نمی‌شود؛ بلکه می‌تواند در طول تصمیم‌گیری‌های مربوط به Feature نیز به‌عنوان یک نقطه مرجع مورد استفاده قرار گیرد.

ایجاد پایه‌ای برای طراحی، توسعه و تست

یکی دیگر از اهداف PRD این است که اطلاعات اولیه موردنیاز برای فعالیت‌های بعدی را فراهم کند.

برای مثال، براساس اطلاعات موجود در PRD ممکن است:

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

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

اما نکته مهم این است که PRD قرار نیست جایگزین تمام مستندات دیگر شود. هرچه پروژه پیچیده‌تر باشد، ممکن است برای رسیدن از هدف محصول به اجرای دقیق، به مستندات و توافق‌های بیشتری نیاز باشد.

در ادامه مقاله بررسی می‌کنیم PRD دقیقاً در کجای چرخه توسعه محصول و نرم‌افزار قرار می‌گیرد و چه تفاوتی با اسنادی مانند BRD و SRS دارد.

PRD در کجای چرخه توسعه محصول و نرم‌افزار قرار می‌گیرد؟

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

البته این جریان در همه سازمان‌ها دقیقاً یکسان نیست. ممکن است یک شرکت از BRD، PRD و SRS به‌صورت رسمی استفاده کند، در حالی که شرکت دیگر اطلاعات مشابه را در قالب Product Backlog، Epic، User Story و مستندات فنی مدیریت کند.

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

نیاز یا مسئله → تعریف هدف محصول → PRD → تحلیل و طراحی → User Story و Acceptance Criteria → توسعه → تست → انتشار → بررسی نتیجه

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

PRD معمولاً پیش از ورود به جزئیات توسعه و تست شکل می‌گیرد

وقتی یک نیاز جدید مطرح می‌شود، ابتدا باید مشخص شود:

چه مسئله‌ای وجود دارد؟
این مسئله برای چه کسانی اهمیت دارد؟
چرا باید برای آن راه‌حل ایجاد شود؟
هدف محصول چیست؟
محدوده کلی راه‌حل چیست؟

PRD می‌تواند این اطلاعات را در سطح محصول یا Feature مشخص کند.

پس از آن، بسته به فرآیند تیم، نیازمندی‌ها ممکن است به بخش‌های کوچک‌تر تقسیم شوند. برای مثال، یک Feature می‌تواند به چند Epic یا User Story تبدیل شود و برای هر بخش Acceptance Criteria تعریف شود. سپس طراحی، توسعه و تست انجام می‌شود.

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

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

شناسایی ابهام‌های موجود در نیازمندی‌ها.
بررسی قابل تست بودن نیازمندی‌ها.
شناسایی ریسک‌های احتمالی.
درک وابستگی‌های Feature.
مطرح کردن سؤال‌های مهم پیش از شروع توسعه.
آماده‌سازی اولیه Test Scenarioها.
پیش‌بینی Edge Caseها و حالت‌های استثنایی.

به همین دلیل، مشارکت تست و QA می‌تواند از مراحل ابتدایی‌تر شکل بگیرد و به اجرای Test Case پس از پایان توسعه محدود نشود.

PRD و نگاه Shift Left

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

برای مثال، فرض کنید در PRD نوشته شده است:

«کاربر باید بتواند سفارش خود را لغو کند.»

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

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

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

یکی از مزیت‌های مشارکت زودهنگام تست و QA همین است: شناسایی مشکلات احتمالی زمانی که هنوز به Bug تبدیل نشده‌اند.

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

PRD نقطه شروع اجرای تست نیست، اما می‌تواند نقطه شروع تفکر تست باشد

ممکن است یک تستر برای اجرای واقعی تست به محیط آماده، نسخه قابل اجرا، Test Data و Test Case نیاز داشته باشد. بنابراین اجرای تست معمولاً در مراحل بعدی انجام می‌شود.

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

هنگام خواندن PRD، تستر می‌تواند به سؤال‌هایی مانند این فکر کند:

کاربر اصلی این Feature چه کسی است؟

چه جریان اصلی باید بررسی شود؟

چه شرایطی ممکن است باعث شکست فرآیند شود؟

چه سیستم‌ها یا سرویس‌هایی به این قابلیت وابسته هستند؟

چه بخش‌هایی از محصول ممکن است تحت تأثیر قرار بگیرند؟

کدام نیازمندی‌ها هنوز مبهم یا غیرقابل تست هستند؟

در نتیجه، PRD الزاماً مستقیماً به Test Case تبدیل نمی‌شود، اما می‌تواند زمینه لازم برای شکل‌گیری Test Scenarioها و تحلیل تست را فراهم کند.

جایگاه PRD در Agile چگونه است؟

یکی از تصورهای رایج این است که PRD فقط متعلق به مدل‌های سنتی توسعه نرم‌افزار است و در Agile کاربردی ندارد.

در عمل، Agile بودن یک تیم لزوماً به معنی حذف مستندات محصول نیست.

در تیم‌های Agile ممکن است PRD:

کوتاه‌تر و سبک‌تر باشد.
به‌صورت تدریجی تکمیل شود.
برای یک محصول یا Feature بزرگ نوشته شود.
اطلاعات آن میان Epicها و ابزارهای مدیریت محصول توزیع شده باشد.
در طول توسعه و براساس بازخورد تغییر کند.

بنابراین ممکن است یک تیم هیچ فایل رسمی با عنوان PRD.docx نداشته باشد، اما همچنان اطلاعاتی مانند Problem، Goal، Users، Scope و Success Metrics را ثبت و مدیریت کند.

از دید تستر، نام و قالب سند اهمیت کمتری دارد. موضوع مهم این است که بتواند پاسخ سؤال‌های اصلی درباره Feature را پیدا کند.

اگر اطلاعات موردنیاز در یک PRD رسمی وجود نداشته باشد، ممکن است در منابع دیگری مانند User Story، جلسات Refinement، مستندات محصول یا گفت‌وگو با Product Manager قابل دسترسی باشد.

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

برای درک بهتر ارتباط PRD با مراحل بعدی، می‌توان این مسیر را در نظر گرفت:

مسئله یا نیاز
↓
هدف محصول
↓
PRD
↓
Feature / Epic
↓
User Story
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Case
↓
Test Execution

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

اما این مدل ذهنی یک نکته مهم را نشان می‌دهد:

Test Case معمولاً از هیچ‌جا شروع نمی‌شود؛ پشت هر تست، باید یک نیاز، هدف یا انتظار وجود داشته باشد.

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

تفاوت PRD با BRD و SRS چیست؟

PRD یکی از چند سند یا مفهوم مرتبط با نیازمندی‌ها است و به همین دلیل گاهی با BRD و SRS اشتباه گرفته می‌شود.

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

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

سند	سؤال اصلی
BRD	چرا کسب‌وکار به این محصول یا تغییر نیاز دارد؟
PRD	محصول یا Feature باید چه چیزی ارائه دهد؟
SRS	نرم‌افزار دقیقاً چه نیازمندی‌هایی باید برآورده کند؟

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

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

BRD؛ چرا این نیاز وجود دارد؟

BRD یا Business Requirements Document بیشتر بر نیازها و اهداف کسب‌وکار تمرکز دارد.

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

یک BRD ممکن است مسئله را از دید کسب‌وکار این‌گونه مطرح کند:

«فرآیند ثبت سفارش باعث رها کردن سبد خرید توسط بخشی از کاربران شده است و کسب‌وکار نیاز دارد نرخ تکمیل خرید را افزایش دهد.»

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

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

بنابراین BRD بیشتر به سؤال «چرا؟» نزدیک است.

PRD؛ محصول باید چه چیزی ارائه دهد؟

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

«برای کاهش پیچیدگی فرآیند ثبت سفارش، کاربران باید بتوانند اطلاعات خرید را در تعداد مراحل کمتری تکمیل کنند.»

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

کاربران هدف چه کسانی هستند؟
چه مسئله‌ای برای آن‌ها وجود دارد؟
محصول یا Feature باید چه قابلیت‌هایی ارائه دهد؟
محدوده Feature چیست؟
چه مواردی خارج از محدوده هستند؟
معیار موفقیت چیست؟

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

به زبان ساده، اگر BRD بگوید:

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

PRD می‌تواند مشخص کند:

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

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

SRS؛ نرم‌افزار دقیقاً چه نیازمندی‌هایی باید برآورده کند؟

SRS یا Software Requirements Specification معمولاً وارد سطح دقیق‌تر و ساختاریافته‌تری از نیازمندی‌های نرم‌افزار می‌شود.

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

کاربر چه اطلاعاتی باید وارد کند.
سیستم در شرایط مختلف چه رفتاری داشته باشد.
چه Functional Requirementهایی وجود دارند.
چه Non-Functional Requirementهایی باید رعایت شوند.
سیستم چه Interfaceهایی دارد.
چه Business Ruleهایی باید اعمال شوند.
چه محدودیت‌هایی وجود دارد.

برای مثال، اگر در PRD آمده باشد:

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

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

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

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

یک مثال برای مقایسه BRD، PRD و SRS

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

BRD:

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

PRD:

«کاربران ثبت‌نام‌شده باید بتوانند بدون نیاز به تماس با پشتیبانی، فرآیند بازیابی رمز عبور را انجام دهند.»

SRS:

«سیستم باید پس از دریافت درخواست بازیابی، یک لینک یک‌بارمصرف برای ایمیل ثبت‌شده کاربر ارسال کند. لینک باید پس از مدت مشخصی منقضی شود و پس از استفاده، دوباره قابل استفاده نباشد.»

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

BRD → نیاز و هدف کسب‌وکار
PRD → نیاز و قابلیت موردنیاز محصول
SRS → نیازمندی‌های دقیق‌تر نرم‌افزار

آیا همیشه باید BRD، PRD و SRS داشته باشیم؟

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

در یک سازمان ممکن است هر سه سند وجود داشته باشند. در سازمانی دیگر، بخشی از اطلاعات BRD و PRD در یک سند واحد ثبت شود. یک تیم Agile نیز ممکن است بسیاری از این اطلاعات را در Product Backlog، Epic، User Story و مستندات مرتبط مدیریت کند.

به همین دلیل، نباید صرفاً براساس نام سند تصور کنیم که محتوای آن دقیقاً چه سطحی از جزئیات را دارد.

یک PRD در یک سازمان ممکن است جزئیات بیشتری نسبت به PRD سازمان دیگر داشته باشد و حتی بخشی از اطلاعاتی را پوشش دهد که در جای دیگر در سندی مانند SRS ثبت می‌شوند.

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

PRD، BRD و SRS از نگاه تستر

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

از BRD می‌تواند هدف و اهمیت کسب‌وکاری یک تغییر را بهتر درک کند.

از PRD می‌تواند بفهمد محصول برای چه کاربرانی، با چه هدفی و در چه محدوده‌ای باید قابلیت موردنظر را ارائه دهد.

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

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

چه بخش‌هایی معمولاً در یک PRD وجود دارد؟

هیچ قالب واحد و اجباری برای نوشتن PRD وجود ندارد. ساختار یک Product Requirements Document می‌تواند براساس نوع محصول، اندازه تیم، روش توسعه و میزان پیچیدگی Feature متفاوت باشد.

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

با وجود این تفاوت‌ها، بسیاری از PRDها اطلاعاتی را ثبت می‌کنند که به تیم کمک می‌کنند به چند سؤال اصلی پاسخ دهد:

چه مسئله‌ای وجود دارد؟
چرا باید این مسئله حل شود؟
کاربران هدف چه کسانی هستند؟
محصول یا Feature باید چه چیزی ارائه دهد؟
چه مواردی در محدوده و خارج از محدوده هستند؟
چه وابستگی‌ها یا محدودیت‌هایی باید در نظر گرفته شوند؟
از کجا بفهمیم محصول یا Feature به هدف موردنظر نزدیک شده است؟

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

مسئله

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

گاهی تیم‌ها مستقیماً از راه‌حل شروع می‌کنند. برای مثال:

«یک قابلیت ارسال اعلان به کاربران اضافه شود.»

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

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

در این حالت، Problem Statement می‌تواند به شکل واضح‌تری نوشته شود:

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

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

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

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

بنابراین، یک Problem Statement مناسب باید تا حد امکان روشن کند:

چه کسی با مشکل روبه‌رو است؟
مشکل چیست؟
این مشکل در چه شرایطی رخ می‌دهد؟
چه تأثیری ایجاد می‌کند؟

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

اهداف محصول

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

برای مثال، اگر مسئله این باشد که کاربران برای بازیابی رمز عبور با پشتیبانی تماس می‌گیرند، هدف محصول می‌تواند این باشد:

«فراهم کردن امکان بازیابی مستقل رمز عبور برای کاربران ثبت‌نام‌شده و کاهش وابستگی آن‌ها به تیم پشتیبانی.»

هدف محصول با فهرست قابلیت‌ها تفاوت دارد.

برای مثال:

❌ «ایجاد صفحه بازیابی رمز عبور.»

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

اما:

✅ «کاهش نیاز کاربران به تماس با پشتیبانی برای بازیابی دسترسی به حساب.»

این جمله نتیجه‌ای را بیان می‌کند که Feature باید به آن کمک کند.

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

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

البته هدف محصول لزوماً یک Test Case نیست و همیشه نمی‌توان آن را مستقیماً Pass یا Fail کرد. هدف، جهت کلی Feature را مشخص می‌کند؛ در حالی که برای بررسی دقیق رفتار سیستم معمولاً به Acceptance Criteria و نیازمندی‌های مشخص‌تر نیاز است.

کاربران هدف

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

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

برای مثال، در یک سیستم مدیریت پروژه ممکن است یک قابلیت فقط برای کاربران با نقش Project Manager در دسترس باشد و اعضای عادی تیم امکان استفاده از آن را نداشته باشند.

بنابراین PRD باید تا حد امکان مشخص کند:

کاربران اصلی چه کسانی هستند؟
چه نقش‌هایی با Feature تعامل دارند؟
آیا گروه‌های مختلف رفتار متفاوتی دارند؟
چه نیاز یا مسئله‌ای برای هر گروه وجود دارد؟

برای تستر، بخش کاربران هدف اهمیت زیادی دارد؛ زیرا می‌تواند مستقیماً بر طراحی Test Scenario تأثیر بگذارد.

اگر یک Feature برای چند نقش کاربری طراحی شده باشد، تست آن فقط با یک نوع کاربر ممکن است پوشش کافی ایجاد نکند.

برای مثال، در یک سیستم فروش:

مشتری ممکن است سفارش را ثبت کند.
مدیر فروش ممکن است سفارش را تأیید کند.
اپراتور ممکن است وضعیت ارسال را تغییر دهد.

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

بنابراین تستر هنگام مطالعه PRD نباید فقط بپرسد:

«این Feature چه کاری انجام می‌دهد؟»

بلکه باید این سؤال را نیز مطرح کند:

«چه کسی از این Feature استفاده می‌کند و هر کاربر چه کاری می‌تواند یا نمی‌تواند انجام دهد؟»

Scope و Out of Scope

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

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

Out of Scope نیز مشخص می‌کند چه مواردی در نسخه یا محدوده فعلی قرار ندارند.

برای مثال، در PRD مربوط به بازیابی رمز عبور ممکن است موارد زیر در Scope قرار داشته باشند:

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

در مقابل، موارد زیر ممکن است Out of Scope باشند:

بازیابی رمز عبور از طریق پیامک.
ورود بدون رمز عبور.
احراز هویت بیومتریک.
تغییر شماره تلفن از طریق فرآیند بازیابی رمز عبور.

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

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

البته Out of Scope بودن یک مورد به این معنی نیست که تستر می‌تواند هرگونه اثر احتمالی آن را نادیده بگیرد.

برای مثال، ممکن است تغییر در فرآیند بازیابی رمز عبور مستقیماً شامل ورود به سیستم نباشد، اما تغییرات ایجادشده روی مکانیزم احراز هویت بر بخش ورود نیز تأثیر بگذارند. در چنین شرایطی، بررسی اثر تغییر و انجام تست‌های مرتبط، از جمله Regression Testing، ممکن است ضروری باشد.

قابلیت‌ها و نیازمندی‌های اصلی

در این بخش مشخص می‌شود محصول یا Feature به‌طور کلی چه قابلیت‌هایی باید ارائه دهد.

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

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

میزان جزئیات این بخش می‌تواند متفاوت باشد.

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

برای تستر، نکته مهم این است که بین قابلیت اصلی و رفتار دقیق مورد انتظار تفاوت قائل شود.

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

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

کاربر چگونه درخواست بازیابی ثبت می‌کند؟
چه اطلاعاتی باید وارد کند؟
لینک بازیابی چقدر اعتبار دارد؟
آیا لینک یک‌بارمصرف است؟
در صورت وارد کردن اطلاعات نامعتبر چه اتفاقی می‌افتد؟

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

User Story

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

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

«به‌عنوان یک [نوع کاربر]، می‌خواهم [کاری انجام دهم] تا [به نتیجه یا ارزش مشخصی برسم].»

برای مثال:

«به‌عنوان یک کاربر ثبت‌نام‌شده، می‌خواهم در صورت فراموش کردن رمز عبور بتوانم آن را بازیابی کنم تا دوباره به حساب کاربری خود دسترسی داشته باشم.»

User Story به تیم کمک می‌کند فقط روی پیاده‌سازی فنی تمرکز نکند و نیاز کاربر را نیز در نظر بگیرد.

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

برای مثال، از User Story بالا هنوز مشخص نیست:

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

به همین دلیل، User Story معمولاً با اطلاعات دیگری مانند Acceptance Criteria، Design یا گفت‌وگوهای تیم تکمیل می‌شود.

Acceptance Criteria

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

برای مثال، برای User Story بازیابی رمز عبور ممکن است معیارهای پذیرش شامل موارد زیر باشند:

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

Acceptance Criteria نقش مهمی در ایجاد درک مشترک میان Product Manager، Developer و Tester دارند.

از دید تستر، این معیارها می‌توانند مبنایی برای طراحی Test Scenario و بررسی رفتار مورد انتظار باشند.

اما یک نکته مهم وجود دارد: Acceptance Criteria جایگزین تمام تست‌ها نیست.

ممکن است Acceptance Criteria فقط مهم‌ترین شرایط پذیرش را مشخص کند، در حالی که تستر همچنان نیاز داشته باشد مواردی مانند Edge Caseها، حالت‌های خطا، ریسک‌ها، امنیت، عملکرد یا تأثیر تغییر روی بخش‌های دیگر سیستم را بررسی کند.

وابستگی‌ها و محدودیت‌ها

هیچ Featureی همیشه به‌صورت کاملاً مستقل توسعه داده نمی‌شود.

ممکن است اجرای یک قابلیت به موارد مختلفی وابسته باشد؛ برای مثال:

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

این موارد می‌توانند به‌عنوان Dependencies یا وابستگی‌ها ثبت شوند.

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

سرویس ارسال ایمیل.
سیستم مدیریت حساب‌های کاربری.
تولید و اعتبارسنجی Token.
طراحی و تأیید صفحه بازیابی رمز عبور.

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

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

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

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

معیارهای موفقیت

یکی از بخش‌هایی که گاهی با Acceptance Criteria اشتباه گرفته می‌شود، معیارهای موفقیت یا Success Metrics است.

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

اما معیار موفقیت بیشتر به این سؤال پاسخ می‌دهد:

«از کجا بفهمیم این Feature پس از ارائه، به هدف موردنظر نزدیک شده است؟»

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

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

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

یا برای یک Feature مربوط به ساده‌سازی فرآیند ثبت سفارش، معیارهای موفقیت می‌توانند شامل مواردی مانند این‌ها باشند:

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

نکته مهم این است که معیارهای موفقیت لزوماً معیار مستقیم Pass یا Fail شدن یک Test Case نیستند.

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

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

همه PRDها لازم نیست تمام این بخش‌ها را داشته باشند

فهرستی که بررسی کردیم، یک قالب اجباری نیست.

ممکن است یک Feature کوچک فقط به Problem، Goal، Scope، User Story و Acceptance Criteria نیاز داشته باشد. در مقابل، یک Feature پیچیده ممکن است نیازمند توضیح دقیق‌تر کاربران، وابستگی‌ها، محدودیت‌ها، ریسک‌ها و معیارهای موفقیت باشد.

بنابراین بهتر است PRD را یک قالب ثابت و غیرقابل تغییر در نظر نگیریم.

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

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

اجزای PRD را با یک مثال بررسی کنیم

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

برای این مثال، همان Feature بازیابی رمز عبور را در نظر می‌گیریم.

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

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

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

مسئله

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

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

هدف محصول

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

کاربران هدف

کاربران ثبت‌نام‌شده فروشگاه که:

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

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

Scope

موارد زیر بخشی از Feature هستند:

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

Out of Scope

موارد زیر در نسخه فعلی در نظر گرفته نشده‌اند:

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

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

قابلیت‌ها و نیازمندی‌های اصلی

سیستم باید امکان ثبت درخواست بازیابی رمز عبور را برای کاربران فراهم کند.

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

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

پس از تغییر موفق رمز عبور، کاربر باید بتواند با رمز جدید وارد حساب کاربری خود شود.

User Story

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

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

Acceptance Criteria

برای این Feature می‌توان معیارهای پذیرش زیر را در نظر گرفت:

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

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

برای مثال، به‌جای عبارت:

«لینک پس از مدت مشخصی منقضی شود.»

می‌توان نوشت:

«لینک بازیابی رمز عبور باید ۱۵ دقیقه پس از ایجاد منقضی شود.»

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

وابستگی‌ها

پیاده‌سازی این Feature ممکن است به چند سیستم یا بخش دیگر وابسته باشد:

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

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

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

محدودیت‌ها

فرض کنیم در نسخه اول این Feature، تصمیم گرفته شده است:

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

این محدودیت‌ها می‌توانند بر راه‌حل نهایی و نحوه پیاده‌سازی Feature تأثیر بگذارند.

معیارهای موفقیت

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

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

این موارد با Acceptance Criteria تفاوت دارند.

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

این مثال چه چیزی به تستر نشان می‌دهد؟

اگر تستر فقط Acceptance Criteria را دریافت کند، ممکن است تمرکز اصلی خود را روی بررسی مواردی مانند ارسال لینک، تغییر رمز عبور و منقضی شدن لینک قرار دهد.

اما با خواندن PRD، تصویر کامل‌تری در اختیار خواهد داشت و بهتر متوجه می‌شود:

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

در نتیجه، تستر می‌تواند هنگام تحلیل نیازمندی‌ها سؤال‌های دقیق‌تری مطرح کند.

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

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

تفاوت PRD با User Story و Acceptance Criteria چیست؟

PRD، User Story و Acceptance Criteria همگی با نیازمندی‌ها ارتباط دارند، اما نقش و سطح جزئیات آن‌ها یکسان نیست.

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

PRD تصویری گسترده‌تر از مسئله، هدف، کاربران و محدوده Feature یا محصول ارائه می‌دهد.

User Story یک نیاز مشخص را از دید کاربر بیان می‌کند.

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

PRD؛ تصویر کلی محصول یا Feature

PRD معمولاً اطلاعاتی مانند موارد زیر را در بر می‌گیرد:

مسئله چیست؟
چرا حل آن اهمیت دارد؟
کاربران چه کسانی هستند؟
هدف محصول چیست؟
Scope چیست؟
چه قابلیت‌هایی باید ارائه شوند؟
چه وابستگی‌ها و محدودیت‌هایی وجود دارند؟
موفقیت چگونه ارزیابی می‌شود؟

بنابراین PRD فقط روی یک رفتار کوچک تمرکز ندارد و تلاش می‌کند تصویر بزرگ‌تری از Feature یا محصول ارائه دهد.

User Story؛ نیاز از نگاه کاربر

User Story معمولاً یک نیاز مشخص را از دید کاربر بیان می‌کند.

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

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

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

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

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

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

Acceptance Criteria؛ شرایط قابل قبول بودن

Acceptance Criteria جزئیات قابل بررسی‌تری درباره رفتار مورد انتظار ارائه می‌دهد.

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

این معیارها به تیم کمک می‌کنند برداشت مشترک‌تری از شرایط قابل قبول بودن Feature داشته باشند.

از دید تستر، Acceptance Criteria می‌تواند نقطه شروع مناسبی برای طراحی برخی Test Scenarioها باشد.

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

هر Acceptance Criterion برابر با یک Test Case است.

یک معیار پذیرش ممکن است به چندین Test Scenario و Test Case نیاز داشته باشد. علاوه بر این، تستر باید مواردی فراتر از Acceptance Criteria، مانند حالت‌های استثنایی، Edge Caseها، ریسک‌ها و اثر تغییر بر سایر بخش‌های سیستم را نیز بررسی کند.

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

می‌توان رابطه PRD، User Story و Acceptance Criteria را به شکل ساده زیر در نظر گرفت:

PRD
تصویر کلی مسئله، هدف و Feature را مشخص می‌کند.

↓

User Story
یک نیاز مشخص را از دید کاربر بیان می‌کند.

↓

Acceptance Criteria
شرایط مورد انتظار برای پذیرفته شدن آن نیاز را مشخص می‌کند.

البته در پروژه‌های واقعی این جریان همیشه کاملاً خطی نیست. ممکن است هنگام تعریف User Story، اطلاعات جدیدی کشف شود که باعث تغییر PRD شود. همچنین Acceptance Criteria ممکن است در جلسات Refinement و با مشارکت اعضای مختلف تیم تکمیل شوند.

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

یک مقایسه سریع

مورد	PRD	User Story	Acceptance Criteria
تمرکز اصلی	محصول یا Feature	نیاز کاربر	شرایط قابل قبول بودن
سطح نگاه	کلی‌تر	مشخص‌تر	جزئی‌تر
سؤال اصلی	چه مسئله‌ای وجود دارد و محصول چه چیزی باید ارائه دهد؟	کاربر چه نیازی دارد؟	چه شرایطی باید برقرار باشد؟
کاربرد برای تستر	درک هدف، Scope و ریسک	درک نیاز کاربر	بررسی رفتار مورد انتظار
جایگزین Test Case است؟	خیر	خیر	خیر

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

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

PRD چه ارتباطی با تیم توسعه و تست دارد؟

PRD معمولاً فقط سندی برای Product Manager نیست. هرچند مسئولیت تهیه و مدیریت آن در بسیاری از تیم‌ها بر عهده Product Manager یا Product Owner است، اما اطلاعات موجود در PRD می‌تواند برای اعضای مختلف تیم محصول و توسعه نرم‌افزار کاربرد داشته باشد.

هر عضو تیم، PRD را با سؤال‌ها و دغدغه‌های متفاوتی بررسی می‌کند.

برای مثال، Product Manager ممکن است به این فکر کند:

آیا Feature تعریف‌شده واقعاً مسئله کاربر یا کسب‌وکار را حل می‌کند؟

Developer ممکن است بپرسد:

برای پیاده‌سازی این Feature چه رفتارها، وابستگی‌ها و محدودیت‌هایی باید در نظر گرفته شوند؟

و Tester ممکن است بپرسد:

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

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

PRD به Developer چه کمکی می‌کند؟

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

برای مثال، اگر Developer فقط این دستور را دریافت کند:

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

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

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

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

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

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

PRD به Tester چه کمکی می‌کند؟

تستر با مطالعه PRD می‌تواند پیش از ورود به جزئیات Test Case، درک کامل‌تری از Feature به دست آورد.

برای مثال، فرض کنید Acceptance Criteria فقط این موارد را مشخص کرده است:

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

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

اما PRD می‌تواند اطلاعات بیشتری در اختیار او قرار دهد، از جمله:

کاربران هدف چه کسانی هستند.
هدف اصلی Feature چیست.
چه مواردی خارج از محدوده هستند.
چه سیستم‌ها یا سرویس‌هایی به Feature وابسته‌اند.
چه محدودیت‌هایی وجود دارد.

این اطلاعات می‌توانند مستقیماً روی تحلیل و طراحی تست تأثیر بگذارند.

برای مثال، اگر هدف اصلی Feature کاهش تماس کاربران با پشتیبانی باشد، تستر ممکن است توجه بیشتری به سناریوهایی داشته باشد که مانع تکمیل مستقل فرآیند توسط کاربر می‌شوند.

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

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

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

به نگاه گسترده‌تری برسد:

این Feature چرا وجود دارد، برای چه کسی ساخته شده و چه چیزهایی ممکن است مانع رسیدن آن به هدفش شوند؟

PRD و همکاری بین تیم محصول، توسعه و تست

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

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

ممکن است Product Manager هدف و Scope را مشخص کرده باشد، اما Developer درباره نحوه مدیریت یک وابستگی سؤال داشته باشد و Tester نیز یک حالت استثنایی یا ابهام در رفتار مورد انتظار را مطرح کند.

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

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

به همین دلیل، PRD نباید صرفاً سندی باشد که یک نفر آن را تهیه کند و سایر اعضای تیم فقط دریافت‌کننده آن باشند. در یک همکاری مؤثر، PRD می‌تواند نقطه شروع گفت‌وگو، بررسی و ایجاد درک مشترک باشد.

چرا تستر نرم‌افزار باید PRD را بخواند؟ 🧪

گاهی تستر زمانی با یک Feature آشنا می‌شود که توسعه آن تقریباً تمام شده و نسخه‌ای برای تست در اختیار او قرار گرفته است. در چنین شرایطی ممکن است Acceptance Criteria یا Test Caseهای اولیه نیز آماده باشند و وظیفه تستر صرفاً بررسی تطابق سیستم با رفتار مورد انتظار به نظر برسد.

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

۱. درک «چرا» پشت Feature

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

برای مثال، فرض کنید هدف یک Feature کاهش تعداد مراحلی باشد که کاربر برای تکمیل فرآیند خرید طی می‌کند.

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

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

دانستن هدف محصول به این معنی نیست که تستر مسئولیت Product Manager را بر عهده می‌گیرد، بلکه کمک می‌کند Feature را در Context واقعی‌تری تحلیل و بررسی کند.

۲. شناسایی ابهام‌ها قبل از تبدیل شدن به مشکل

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

برای مثال، فرض کنید در PRD نوشته شده باشد:

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

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

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

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

۳. شناسایی ریسک‌ها و وابستگی‌ها

PRD می‌تواند اطلاعاتی درباره سیستم‌ها، سرویس‌ها و فرآیندهایی که یک Feature به آن‌ها وابسته است در اختیار تستر قرار دهد.

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

درگاه پرداخت.
سرویس سفارش.
سیستم مدیریت موجودی.
سرویس ارسال اعلان.

در چنین شرایطی، جریان اصلی Feature فقط به یک صفحه یا یک سرویس محدود نمی‌شود.

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

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

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

۴. طراحی بهتر Test Scenarioها

PRD معمولاً Test Case آماده در اختیار تستر قرار نمی‌دهد، اما اطلاعات آن می‌تواند به طراحی Test Scenarioهای دقیق‌تر و هدفمندتر کمک کند.

اطلاعات موجود در PRD	سؤال احتمالی تستر
کاربران هدف	آیا همه نقش‌ها و گروه‌های کاربری بررسی شده‌اند؟
هدف Feature	کدام جریان‌ها برای رسیدن به این هدف حیاتی هستند؟
Scope	چه رفتارهایی باید در نسخه فعلی پوشش داده شوند؟
Out of Scope	آیا تغییر جدید به‌صورت ناخواسته روی این بخش‌ها اثر گذاشته است؟
وابستگی‌ها	در صورت خطا، تأخیر یا عدم دسترسی چه اتفاقی می‌افتد؟
محدودیت‌ها	آیا سیستم در چارچوب محدودیت‌های تعیین‌شده رفتار می‌کند؟

بنابراین، PRD می‌تواند به تستر کمک کند پیش از نوشتن Test Case، تصویر بزرگ‌تری از جریان‌ها، شرایط و ریسک‌های احتمالی داشته باشد.

۵. مشارکت در کیفیت نیازمندی‌ها

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

برای مثال، فرض کنید در نیازمندی نوشته شده باشد:

صفحه باید سریع بارگذاری شود.

عبارت «سریع» قابل تفسیر است. ممکن است Developer زمان بارگذاری ۵ ثانیه را قابل قبول بداند، در حالی که انتظار تیم محصول کمتر از ۲ ثانیه باشد.

تستر یا QA می‌تواند با مشاهده چنین نیازمندی‌ای سؤال مهمی مطرح کند:

منظور از سریع چیست و چگونه باید آن را اندازه‌گیری کنیم؟

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

۶. جلوگیری از تمرکز صرف بر Happy Path

وقتی تستر فقط یک User Story کوتاه یا مجموعه محدودی از Acceptance Criteria را دریافت کند، احتمال دارد تمرکز بیش از حدی روی جریان اصلی یا Happy Path داشته باشد.

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

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

اگر کاربر شرایط مورد انتظار را نداشته باشد چه اتفاقی می‌افتد؟
اگر یکی از وابستگی‌ها در دسترس نباشد چه می‌شود؟
اگر کاربر فرآیند را نیمه‌کاره رها کند، سیستم چه رفتاری دارد؟
اگر درخواست تکراری ارسال شود چه اتفاقی می‌افتد؟
اگر Feature با بخش دیگری از سیستم تعامل داشته باشد، آیا وضعیت‌ها همچنان سازگار باقی می‌مانند؟

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

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

در پروژه‌های واقعی، گاهی اعضای تیم درباره رفتار مورد انتظار یک Feature برداشت‌های متفاوتی دارند.

ممکن است Developer بگوید:

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

و Tester معتقد باشد:

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

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

PRD همیشه پاسخ تمام اختلاف‌ها را در خود ندارد، اما مشخص بودن هدف، Scope و Context می‌تواند به تیم کمک کند بحث را از سطح برداشت شخصی به سطح نیاز و هدف محصول نزدیک‌تر کند.

نگاه Product Manager، Developer و Tester به PRD چه تفاوتی دارد؟

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

Product Manager؛ آیا مسئله و هدف درست تعریف شده‌اند؟

نگاه Product Manager معمولاً بیشتر بر ارزش محصول و نیاز کاربر تمرکز دارد.

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

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

تمرکز اصلی Product Manager بیشتر روی ارزش و جهت محصول است.

Developer؛ دقیقاً چه چیزی باید ساخته شود؟

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

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

تمرکز اصلی Developer بیشتر به سمت امکان‌پذیری و پیاده‌سازی حرکت می‌کند.

Tester؛ چه چیزی ممکن است اشتباه شود؟

تستر معمولاً PRD را با زاویه دیگری بررسی می‌کند و تلاش می‌کند علاوه بر درک رفتار مورد انتظار، ابهام‌ها، ریسک‌ها و شرایطی را که ممکن است باعث بروز مشکل شوند شناسایی کند.

سؤال‌هایی مانند این‌ها می‌توانند هنگام مطالعه PRD مطرح شوند:

آیا نیازمندی واضح و بدون ابهام است؟
آیا رفتار مورد انتظار قابل تست است؟
چه جریان‌هایی باید بررسی شوند؟
چه حالت‌های استثنایی وجود دارند؟
چه وابستگی‌هایی ممکن است باعث بروز مشکل شوند؟
کدام بخش‌ها ریسک بیشتری دارند؟
آیا Scope و Out of Scope به‌وضوح مشخص شده‌اند؟
این تغییر ممکن است روی کدام بخش‌های دیگر سیستم تأثیر بگذارد؟

تمرکز تستر فقط روی این سؤال نیست:

آیا چیزی برای تست وجود دارد؟

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

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

سه نگاه متفاوت، یک هدف مشترک

تفاوت در نگاه اعضای تیم به این معنی نیست که هر فرد باید فقط به حوزه تخصصی خود توجه کند.

در یک تیم مؤثر، Product Manager، Developer و Tester می‌توانند با استفاده از دیدگاه‌ها و تخصص‌های متفاوت خود، به کامل‌تر شدن نیازمندی‌ها کمک کنند.

Product Manager می‌تواند هدف و ارزش Feature را مشخص کند.
Developer می‌تواند محدودیت‌ها و پیچیدگی‌های فنی را شناسایی کند.
Tester می‌تواند ابهام‌ها، حالت‌های استثنایی و ریسک‌های قابل بررسی را مطرح کند.

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

تستر هنگام بررسی PRD باید دنبال چه چیزهایی باشد؟ 🔍

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

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

به بیان ساده، تستر هنگام بررسی PRD می‌تواند دائماً این سؤال را در ذهن داشته باشد:

«اگر قرار باشد این Feature را در شرایط واقعی بررسی کنم، چه چیزهایی باید بدانم و چه اطلاعاتی هنوز مشخص نیست؟»

در ادامه، مهم‌ترین مواردی را که تستر می‌تواند هنگام بررسی PRD به آن‌ها توجه کند بررسی می‌کنیم.

هدف و مسئله

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

این Feature دقیقاً برای حل چه مسئله‌ای ساخته می‌شود؟

اگر هدف Feature مشخص نباشد، طراحی تست نیز ممکن است بیش از حد به جزئیات ظاهری یا رفتارهای جداگانه محدود شود.

برای مثال، فرض کنید در PRD نوشته شده است:

«یک قابلیت ذخیره خودکار اطلاعات فرم اضافه شود.»

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

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

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

دانستن این مسئله می‌تواند نگاه تستر را تغییر دهد.

در این حالت، فقط بررسی اینکه «قابلیت ذخیره خودکار اجرا می‌شود» کافی نیست. ممکن است سناریوهایی مانند موارد زیر نیز اهمیت پیدا کنند:

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

هدف و مسئله به تستر کمک می‌کنند بفهمد کدام شکست‌ها می‌توانند باعث شوند Feature نتواند ارزش مورد انتظار را ایجاد کند.

کاربران

تستر باید مشخص کند Feature برای چه کسانی طراحی شده است و آیا گروه‌های مختلف کاربران ممکن است رفتار متفاوتی داشته باشند.

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

کاربر مهمان.
کاربر ثبت‌نام‌شده.
مدیر سیستم.
اپراتور.
کاربر دارای دسترسی محدود.

گاهی یک PRD فقط می‌گوید:

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

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

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

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

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

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

Scope و Out of Scope

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

تستر باید بداند:

دقیقاً چه چیزی قرار است تغییر کند؟
چه قابلیت‌هایی به این Feature اضافه می‌شوند؟
چه مواردی عمداً در این نسخه پیاده‌سازی نمی‌شوند؟
چه بخش‌هایی نباید تحت تأثیر تغییر قرار بگیرند؟

برای مثال، فرض کنید Feature جدید فقط مربوط به امکان تغییر آدرس ارسال سفارش است.

اگر Scope مشخص نباشد، ممکن است سؤال‌های زیادی ایجاد شود:

کاربر تا چه مرحله‌ای می‌تواند آدرس را تغییر دهد؟
آیا تغییر آدرس روی هزینه ارسال تأثیر می‌گذارد؟
آیا روش پرداخت نیز تحت تأثیر قرار می‌گیرد؟
آیا سفارش‌های قبلی تغییر می‌کنند؟
آیا آدرس پیش‌فرض حساب کاربری هم باید تغییر کند؟

همه این موارد الزاماً بخشی از Feature نیستند.

به همین دلیل، Scope و Out of Scope به تستر کمک می‌کنند بین دو موضوع تفاوت قائل شود:

رفتاری که باید در این Feature بررسی شود

رفتاری که فعلاً بخشی از نیازمندی نیست، اما ممکن است تحت تأثیر تغییر قرار بگیرد.

این تفاوت مهم است؛ زیرا Out of Scope بودن یک قابلیت، همیشه به معنی صفر بودن ریسک آن نیست.

ابهام‌ها

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

به این مثال توجه کنید:

«سیستم باید در صورت وارد کردن اطلاعات نامعتبر، پیام مناسب نمایش دهد.»

این نیازمندی چند سؤال ایجاد می‌کند:

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

یا عبارت زیر را در نظر بگیرید:

«صفحه باید به‌سرعت بارگذاری شود.»

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

منظور از «به‌سرعت» چیست و چگونه اندازه‌گیری می‌شود؟

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

سریع
مناسب
ساده
امن
کاربرپسند
در صورت نیاز
در شرایط خاص
در اکثر موارد
به‌صورت خودکار

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

وابستگی‌ها

تستر باید بررسی کند Feature برای عملکرد صحیح به چه چیزهایی وابسته است.

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

API یا سرویس داخلی.
سرویس شخص ثالث.
سیستم دیگر.
Feature دیگری که هنوز توسعه داده نشده است.
تنظیمات محیط.
داده‌های خاص.
نقش یا Permission کاربر.

برای مثال، فرض کنید PRD مربوط به ارسال اعلان است.

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

سؤال‌های دیگری نیز مطرح می‌شوند:

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

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

ریسک‌ها

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

تستر هنگام مطالعه PRD می‌تواند تلاش کند بخش‌هایی را شناسایی کند که:

خرابی آن‌ها تأثیر زیادی روی کاربر یا کسب‌وکار دارد.
احتمال بروز خطا در آن‌ها بیشتر است.
تغییر در آن‌ها ممکن است روی بخش‌های دیگر سیستم اثر بگذارد.
پیچیدگی بالایی دارند.
با داده‌های حساس سروکار دارند.
به سیستم‌های متعدد وابسته هستند.

برای مثال، در یک Feature مربوط به پرداخت، مواردی مانند ایجاد تراکنش تکراری، کسر مبلغ بدون ثبت سفارش یا ثبت سفارش بدون پرداخت موفق، معمولاً ریسک بالایی دارند.

در چنین شرایطی، تمام سناریوها نباید لزوماً با اولویت یکسان بررسی شوند.

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

کدام جریان‌ها حیاتی‌تر هستند؟
کدام بخش‌ها به تست عمیق‌تر نیاز دارند؟
چه سناریوهایی در صورت شکست، بیشترین آسیب را ایجاد می‌کنند؟

این موضوع در بخش مربوط به Risk-Based Testing با جزئیات بیشتری بررسی خواهد شد.

Testability

آخرین سؤال مهم این است:

آیا چیزی که در PRD نوشته شده واقعاً قابل تست است؟

برای مثال:

«کاربر باید تجربه خوبی از فرآیند پرداخت داشته باشد.»

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

تستر باید بداند «تجربه خوب» چگونه تعریف شده است.

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

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

در این حالت، رفتار مورد انتظار مشخص‌تر و قابل بررسی‌تر می‌شود.

Testability فقط به معنی داشتن Acceptance Criteria نیست.

ممکن است Acceptance Criteria وجود داشته باشد، اما همچنان:

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

به همین دلیل، تستر باید هنگام بررسی PRD فقط نپرسد:

«آیا چیزی برای تست نوشته شده است؟»

بلکه بهتر است بپرسد:

«آیا می‌توانم براساس اطلاعات موجود، مشخص کنم چه چیزی را، تحت چه شرایطی و با چه نتیجه مورد انتظاری باید بررسی کنم؟»

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

PRD و Testability؛ چگونه بفهمیم یک نیازمندی قابل تست است؟

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

برای مثال، این نیازمندی را در نظر بگیرید:

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

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

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

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

«۹۵ درصد درخواست‌های جست‌وجو باید در شرایط بار معمول، حداکثر ظرف ۲ ثانیه پاسخ داده شوند.»

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

چه چیزی اندازه‌گیری می‌شود: زمان پاسخ جست‌وجو.
چه شرایطی در نظر گرفته شده است: بار معمول.
چه معیاری وجود دارد: ۹۵ درصد درخواست‌ها.
مقدار قابل قبول چیست: حداکثر ۲ ثانیه.

در نتیجه، این نیازمندی قابل تست‌تر است.

ویژگی‌های یک نیازمندی قابل تست

یک نیازمندی لازم نیست حتماً همه جزئیات را در یک جمله داشته باشد، اما برای اینکه بتوان آن را به‌طور مؤثر بررسی کرد، معمولاً باید پاسخ مواردی مانند این‌ها مشخص باشد:

چه چیزی باید اتفاق بیفتد؟
رفتار یا نتیجه مورد انتظار چیست؟

تحت چه شرایطی؟
چه پیش‌شرط‌ها، ورودی‌ها یا وضعیت‌هایی وجود دارند؟

برای چه کسی؟
کدام کاربر، Role یا سیستم درگیر است؟

نتیجه مورد انتظار چیست؟
پس از انجام عملیات چه اتفاقی باید بیفتد؟

چگونه Pass یا Fail را تشخیص می‌دهیم؟
آیا معیار یا روش مشخصی برای بررسی وجود دارد؟

برای مثال:

«کاربر باید بتواند سفارش خود را لغو کند.»

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

سؤال‌های زیر می‌توانند آن را دقیق‌تر کنند:

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

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

Testability به معنی حذف تمام ابهام‌ها نیست

در عمل، نمی‌توان انتظار داشت یک PRD از ابتدا تمام جزئیات موردنیاز را داشته باشد.

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

بنابراین هدف تستر این نیست که تا زمانی که هیچ سؤال بدون پاسخی باقی نمانده، اجازه توسعه ندهد.

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

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

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

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

یک سؤال ساده برای بررسی Testability

هنگام خواندن یک نیازمندی، تستر می‌تواند این سؤال را مطرح کند:

«اگر فردا Feature آماده شود، دقیقاً چگونه تشخیص می‌دهم که این نیازمندی برآورده شده است یا نه؟»

اگر پاسخ مشخص باشد، احتمالاً نیازمندی از Testability مناسبی برخوردار است.

اما اگر پاسخ این باشد:

«بستگی دارد منظور Product Manager چه بوده باشد.»

یا:

«باید بعداً ببینیم چه چیزی پیاده‌سازی می‌شود.»

احتمالاً هنوز اطلاعات بیشتری لازم است.

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

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

پیدا کردن یک ابهام در PRD به‌تنهایی کافی نیست. بخش مهم‌تر این است که تستر بتواند آن ابهام را به سؤالی تبدیل کند که به تیم کمک کند رفتار مورد انتظار را شفاف‌تر مشخص کند.

برای مثال، فرض کنید در PRD نوشته شده است:

«کاربر می‌تواند در صورت نیاز سفارش خود را لغو کند.»

تستر می‌تواند فقط بگوید:

«این مورد مبهم است.»

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

رویکرد مفیدتر این است که سؤال‌های مشخصی مطرح شود:

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

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

به‌جای پرسیدن «منظورت چیست؟»، Context بدهید

یکی از اشتباهاتی که ممکن است هنگام بررسی نیازمندی رخ دهد، پرسیدن سؤال‌های بیش از حد کلی است.

برای مثال:

«منظور از سریع چیست؟»

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

«برای بررسی عملکرد صفحه جست‌وجو، آیا زمان پاسخ مشخصی داریم؟ برای مثال، آیا هدف این است که ۹۵ درصد درخواست‌ها در کمتر از ۲ ثانیه پاسخ داده شوند؟»

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

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

از Happy Path فراتر بروید

یکی از روش‌های ساده برای پیدا کردن سؤال‌های مناسب این است که ابتدا جریان اصلی را در ذهن مرور کنید و سپس بررسی کنید در شرایط دیگر چه اتفاقی می‌افتد.

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

«کاربر می‌تواند فایل را بارگذاری کند.»

Happy Path ممکن است به این شکل باشد:

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

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

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

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

از «اگر…» استفاده کنید

یک روش ساده و کاربردی برای کشف ابهام‌ها این است که جمله‌های PRD را با عبارت «اگر…» ادامه دهید.

برای مثال:

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

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

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

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

به مرزها و تغییر وضعیت‌ها توجه کنید

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

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

«کاربر می‌تواند تا ۵ فایل بارگذاری کند.»

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

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

یا فرض کنید:

«کاربر می‌تواند تا زمان تأیید سفارش، آن را ویرایش کند.»

در اینجا وضعیت‌های مختلف اهمیت پیدا می‌کنند:

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

تمرکز روی مرزها و تغییر وضعیت‌ها یکی از روش‌های مؤثر برای پیدا کردن جزئیاتی است که ممکن است در متن اولیه PRD دیده نشوند.

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

برای اینکه بررسی PRD ساختارمندتر شود، تستر می‌تواند برای هر قابلیت چند دسته سؤال ثابت در ذهن داشته باشد:

کاربر و دسترسی

چه کسی می‌تواند این کار را انجام دهد؟
چه کسی نباید بتواند آن را انجام دهد؟

ورودی

چه داده‌هایی معتبر هستند؟
چه داده‌هایی نامعتبر محسوب می‌شوند؟

خروجی

نتیجه موفق چیست؟
در صورت شکست چه اتفاقی می‌افتد؟

محدودیت‌ها

محدودیت زمانی، تعداد یا حجم چیست؟

وضعیت‌ها

این عملیات در چه وضعیت‌هایی مجاز یا غیرمجاز است؟

خطاها و وابستگی‌ها

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

تکرار

اگر کاربر یک عملیات را چند بار انجام دهد چه اتفاقی می‌افتد؟

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

سؤال خوب الزاماً سؤال پیچیده‌ای نیست

گاهی تستر تصور می‌کند برای مشارکت در بررسی PRD باید سؤال‌های بسیار فنی یا پیچیده مطرح کند.

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

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

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

چگونه از PRD به Test Scenario و Test Case برسیم؟

PRD معمولاً مستقیماً به شما نمی‌گوید:

«این ۲۰ Test Case را بنویس.»

نقش PRD بیشتر این است که Context و اطلاعات لازم برای تحلیل Feature را فراهم کند.

تستر می‌تواند این اطلاعات را به‌تدریج به Test Scenario و سپس، در صورت نیاز، به Test Case تبدیل کند.

مرحله اول: مسئله و هدف را درک کنید

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

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

هدف: جلوگیری از دست رفتن اطلاعات کاربران از طریق ذخیره خودکار.

این اطلاعات کمک می‌کنند بدانید کدام جریان‌ها برای Feature اهمیت بیشتری دارند.

در این مثال، سناریوهایی مانند قطع اتصال یا بستن ناخواسته صفحه اهمیت زیادی دارند؛ زیرا مستقیماً با مسئله اصلی ارتباط دارند.

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

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

برای Feature ذخیره خودکار، ممکن است جریان‌های اصلی شامل این موارد باشند:

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

این موارد هنوز Test Case نیستند؛ بلکه می‌توانند پایه‌ای برای طراحی Test Scenario باشند.

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

حالا بررسی کنید آیا Feature برای همه کاربران و شرایط به یک شکل عمل می‌کند یا خیر.

کاربر واردشده به سیستم.
کاربری که Session او منقضی شده است.
کاربر فعال در چند تب مرورگر.
کاربر با اتصال اینترنت ناپایدار.

هرکدام از این شرایط می‌توانند سناریوهای جدیدی ایجاد کنند.

مرحله چهارم: Acceptance Criteria را بررسی کنید

Acceptance Criteria معمولاً رفتارهای مشخصی را در اختیار تستر قرار می‌دهد.

«اطلاعات فرم باید هر ۳۰ ثانیه به‌صورت خودکار ذخیره شوند.»

این معیار می‌تواند به چندین بررسی منجر شود:

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

بنابراین، یک Acceptance Criterion لزوماً برابر با یک Test Case نیست.

مرحله پنجم: حالت‌های منفی و استثنایی را اضافه کنید

در این مرحله، تستر بررسی می‌کند که علاوه بر Happy Path، چه حالت‌های دیگری ممکن است رخ دهند.

Test Scenario	شرایط
ذخیره موفق اطلاعات	اتصال برقرار است
خطا هنگام ذخیره	سرویس ذخیره‌سازی پاسخ نمی‌دهد
قطع اتصال	اینترنت هنگام ذخیره قطع می‌شود
تغییر هم‌زمان	فرم در دو تب باز است
Session منقضی‌شده	کاربر مدت زیادی غیرفعال بوده است
بازگشت به فرم	کاربر پس از خروج دوباره فرم را باز می‌کند

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

مرحله ششم: Test Scenario را به Test Case تبدیل کنید

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

Test Scenario: بازیابی اطلاعات پس از خروج از صفحه.

Precondition:
کاربر وارد سیستم شده و یک فرم جدید را باز کرده است.

Steps:

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

Expected Result:
اطلاعاتی که قبل از خروج ذخیره شده‌اند باید مطابق انتظار نمایش داده شوند.

در یک پروژه واقعی، میزان جزئیات Test Case به روش کاری تیم، ابزار مدیریت تست و نوع محصول بستگی دارد.

در بعضی تیم‌ها Test Scenarioهای سطح بالا کافی هستند و در برخی پروژه‌ها، به‌ویژه پروژه‌های حساس یا دارای فرآیندهای رسمی، Test Caseهای دقیق‌تری موردنیاز است.

یک مسیر ساده از PRD تا تست

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

PRD
↓
درک مسئله، هدف، کاربران و Scope
↓
شناسایی قابلیت‌ها و جریان‌های اصلی
↓
بررسی User Story و Acceptance Criteria
↓
شناسایی شرایط، حالت‌ها و ریسک‌ها
↓
طراحی Test Scenario
↓
طراحی Test Case
↓
اجرای تست و ثبت نتایج

این مسیر همیشه کاملاً خطی نیست.

ممکن است هنگام طراحی Test Scenario به ابهامی برسید و دوباره به PRD یا Product Manager مراجعه کنید. همچنین ممکن است هنگام توسعه، جزئیات جدیدی مشخص شود که نیاز به به‌روزرسانی سناریوهای تست داشته باشد.

نکته مهم این است که PRD را فقط یک سند برای مطالعه اولیه در نظر نگیریم.

PRD می‌تواند یکی از منابع اصلی برای تحلیل تست، طراحی سناریو و درک ریسک‌های Feature باشد.

در بخش بعدی بررسی می‌کنیم PRD چگونه می‌تواند به تستر در اجرای Risk-Based Testing کمک کند و QA چه نقشی در مرحله بررسی PRD و قبل از شروع توسعه دارد.

PRD چه نقشی در Risk-Based Testing دارد؟

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

اینجاست که مفهوم Risk-Based Testing یا تست مبتنی بر ریسک اهمیت پیدا می‌کند.

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

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

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

فرض کنید در PRD یک Feature پرداخت نوشته شده است:

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

در نگاه اول، این Feature ممکن است ساده به نظر برسد.

اما هنگام بررسی PRD، تستر می‌تواند چند نقطه ریسک را شناسایی کند:

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

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

چه مواردی در PRD می‌توانند نشانه ریسک باشند؟

هنگام مطالعه PRD، برخی اطلاعات معمولاً ارزش بررسی بیشتری دارند.

جریان‌های حیاتی کسب‌وکار

اگر Feature مستقیماً روی درآمد، کاربران اصلی یا عملیات حیاتی کسب‌وکار تأثیر داشته باشد، شکست آن احتمالاً اهمیت بالایی دارد.

برای مثال:

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

این بخش‌ها معمولاً باید با دقت و عمق بیشتری بررسی شوند.

وابستگی به سیستم‌ها یا سرویس‌های دیگر

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

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

یک سرویس داخلی.
API شخص ثالث.
سیستم پرداخت.
سرویس ارسال پیامک یا ایمیل.

در چنین شرایطی، تستر نباید فقط به پاسخ موفق فکر کند.

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

تغییر در بخش‌های موجود

گاهی یک PRD مربوط به ساخت قابلیت جدید نیست، بلکه تغییری در یک فرآیند موجود را توصیف می‌کند.

در این شرایط، تستر باید بررسی کند:

این تغییر ممکن است روی چه بخش‌هایی اثر بگذارد؟

برای مثال، اضافه شدن یک روش جدید برای محاسبه تخفیف ممکن است روی بخش‌های زیر اثر بگذارد:

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

بنابراین Scope Feature ممکن است کوچک به نظر برسد، اما اثر تغییر گسترده باشد.

ابهام یا تصمیم‌های حل‌نشده

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

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

برای مثال:

«سیستم در صورت مشاهده فعالیت مشکوک، دسترسی کاربر را محدود کند.»

در اینجا مشخص نیست:

فعالیت مشکوک چگونه تشخیص داده می‌شود؟
محدودیت دقیقاً چیست؟
این محدودیت چه مدت ادامه دارد؟
کاربر چگونه می‌تواند دوباره دسترسی کامل داشته باشد؟

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

PRD چگونه به اولویت‌بندی تست کمک می‌کند؟

اطلاعات موجود در PRD می‌توانند به تستر کمک کنند برای سناریوهای مختلف اولویت تعیین کند.

برای مثال، در یک Feature پرداخت می‌توان سناریوها را به‌صورت ساده‌ای دسته‌بندی کرد:

اولویت بالا

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

اولویت متوسط

نمایش مناسب پیام‌های خطا.
Retry شدن برخی درخواست‌ها در شرایط مشخص.
بررسی تاریخچه پرداخت.

اولویت پایین‌تر

جزئیات ظاهری غیرحیاتی.
تغییرات کم‌اهمیت در متن پیام‌ها، در صورتی که اثر مهمی روی کاربر نداشته باشند.

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

اما PRD می‌تواند Context لازم برای تصمیم‌گیری بهتر را فراهم کند.

یک نگاه ساده به ریسک

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

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

و:

چقدر احتمال دارد این بخش با مشکل مواجه شود؟

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

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

به همین دلیل، Risk-Based Testing به معنی تست کردن فقط بخش‌های پیچیده نیست؛ بلکه به معنی تخصیص هوشمندانه‌تر زمان و تلاش تست براساس ریسک است.

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

نقش QA در مرحله بررسی PRD چیست؟

نقش QA در مرحله بررسی PRD لزوماً این نیست که سند را تأیید یا رد کند.

همچنین QA قرار نیست به‌جای Product Manager تصمیم بگیرد که چه Featureی باید ساخته شود.

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

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

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

شناسایی نیازمندی‌های مبهم

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

برای مثال:

«کاربر باید بتواند فایل‌های بزرگ را بارگذاری کند.»

QA می‌تواند سؤال کند:

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

هدف از این سؤال‌ها ایراد گرفتن از PRD نیست.

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

بررسی کامل بودن جریان‌های اصلی

گاهی PRD جریان اصلی را به‌خوبی توضیح می‌دهد، اما برخی مراحل یا وضعیت‌ها مشخص نشده‌اند.

برای مثال:

«کاربر درخواست پرداخت را ثبت می‌کند و پس از پرداخت موفق، سفارش تأیید می‌شود.»

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

اگر پرداخت ناموفق باشد چه می‌شود؟
اگر پاسخ درگاه دریافت نشود چه اتفاقی می‌افتد؟
اگر کاربر پس از پرداخت صفحه را ببندد چه می‌شود؟
اگر نتیجه پرداخت با تأخیر به سیستم برسد چه اتفاقی می‌افتد؟

در اینجا QA به طراحی راه‌حل نمی‌پردازد، بلکه تلاش می‌کند بخش‌های ناقص جریان را آشکار کند.

بررسی سازگاری نیازمندی‌ها

یک PRD ممکن است شامل بخش‌هایی باشد که با یکدیگر تناقض دارند.

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

«کاربر می‌تواند سفارش خود را تا قبل از ارسال لغو کند.»

اما در بخش دیگری آمده است:

«پس از تأیید سفارش، امکان تغییر یا لغو وجود ندارد.»

اگر مشخص نباشد «تأیید» و «ارسال» چه رابطه‌ای با یکدیگر دارند، تیم ممکن است رفتارهای متفاوتی پیاده‌سازی کند.

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

توجه به Testability

QA می‌تواند بررسی کند آیا نیازمندی‌ها به شکلی نوشته شده‌اند که امکان بررسی آن‌ها وجود داشته باشد یا خیر.

برای مثال:

«سیستم باید امنیت بالایی داشته باشد.»

این جمله یک هدف کلی است، اما مشخص نمی‌کند:

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

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

برای مثال:

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

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

شناسایی وابستگی‌ها و نقاط شکست

QA می‌تواند هنگام بررسی PRD، به نقاطی توجه کند که Feature از محدوده یک سیستم یا یک تیم خارج می‌شود.

برای مثال:

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

این موارد می‌توانند روی برنامه‌ریزی تست نیز اثر بگذارند.

برای مثال، اگر Feature به یک سرویس خارجی وابسته باشد، ممکن است نیاز به محیط تست مناسب، Mock یا روش دیگری برای شبیه‌سازی شرایط خطا وجود داشته باشد.

مشارکت زودهنگام QA به معنی پذیرش مسئولیت محصول نیست

نکته مهم این است که مشارکت QA در بررسی PRD به این معنی نیست که QA مسئول کیفیت تمام تصمیم‌های محصول است.

تصمیم درباره اینکه:

چه مسئله‌ای باید حل شود.
چه Featureی ساخته شود.
چه چیزی در Scope قرار بگیرد.
چه اولویتی وجود داشته باشد.

معمولاً در حوزه مسئولیت Product و Business قرار دارد.

اما QA می‌تواند با زاویه دید خود کمک کند مشخص شود:

آیا نیازمندی قابل فهم است؟
آیا ابهام مهمی وجود دارد؟
آیا جریان ناقصی وجود دارد؟
آیا رفتار مورد انتظار قابل تست است؟
آیا ریسک یا وابستگی مهمی نادیده گرفته شده است؟

این مشارکت زودهنگام باعث می‌شود کیفیت فقط در پایان چرخه توسعه بررسی نشود.

در واقع، یکی از ارزش‌های مهم QA می‌تواند این باشد که به تیم کمک کند مشکلات را قبل از تبدیل شدن به Bug پیدا کند.

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

PRD و Traceability؛ ارتباط نیازمندی‌ها با تست

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

اینجاست که مفهوم Traceability یا ردیابی‌پذیری اهمیت پیدا می‌کند.

به‌طور ساده، Traceability به ما کمک می‌کند مشخص کنیم:

هر نیازمندی چگونه بررسی شده است؟
کدام Test Scenario یا Test Case یک نیازمندی را پوشش می‌دهد؟
اگر یک نیازمندی تغییر کند، کدام تست‌ها ممکن است تحت تأثیر قرار بگیرند؟
آیا نیازمندی مهمی وجود دارد که هیچ تستی برای آن طراحی نشده باشد؟

PRD می‌تواند یکی از نقاط شروع این زنجیره باشد.

برای مثال، یک Feature ممکن است ابتدا در PRD تعریف شود و سپس به User Storyها و Acceptance Criteriaهای مختلف تقسیم شود. تستر نیز براساس این اطلاعات، Test Scenario و Test Case طراحی می‌کند.

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

PRD → User Story / Requirement → Acceptance Criteria → Test Scenario → Test Case

البته این مسیر در همه تیم‌ها دقیقاً به همین شکل نیست. ممکن است برخی تیم‌ها User Story را مستقیماً به Test Case متصل کنند یا از ساختار دیگری استفاده کنند.

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

یک مثال ساده از Traceability

فرض کنید در PRD مربوط به بازیابی رمز عبور، یکی از نیازمندی‌ها این باشد:

REQ-01: کاربر باید بتواند با استفاده از ایمیل ثبت‌شده خود، درخواست بازیابی رمز عبور ثبت کند.

برای این نیازمندی می‌توان چند Test Scenario تعریف کرد:

ثبت درخواست بازیابی با ایمیل معتبر.
ثبت درخواست با ایمیل نامعتبر.
ثبت درخواست با ایمیل خالی.
بررسی رفتار سیستم در صورت بروز خطا هنگام ثبت درخواست.

سپس هر Test Scenario می‌تواند شامل یک یا چند Test Case باشد.

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

بدون Traceability، ممکن است این تغییر در یک بخش اعمال شود، اما برخی Test Caseهای مرتبط همچنان براساس رفتار قبلی باقی بمانند.

Traceability فقط برای مستندسازی نیست

گاهی Traceability صرفاً به‌عنوان یک فعالیت مستندسازی دیده می‌شود؛ یعنی جدولی ساخته می‌شود که در آن شماره نیازمندی‌ها در کنار شماره Test Caseها قرار گرفته‌اند.

اما ارزش اصلی Traceability زمانی مشخص می‌شود که تغییری در نیازمندی رخ دهد.

فرض کنید یک Feature شامل ۳۰ User Story و ۱۵۰ Test Case است و حالا یکی از User Storyهای اصلی تغییر می‌کند.

اگر ارتباط بین نیازمندی و تست‌ها مشخص نباشد، تستر باید به‌صورت دستی بررسی کند که کدام Test Scenarioها و Test Caseها تحت تأثیر قرار گرفته‌اند.

اما اگر ارتباط مناسبی وجود داشته باشد، تحلیل اثر تغییر ساده‌تر می‌شود:

US-12 تغییر کرده است
↓
Acceptance Criteriaهای مرتبط بررسی می‌شوند
↓
Test Scenarioهای مرتبط شناسایی می‌شوند
↓
Test Caseهای تحت تأثیر به‌روزرسانی می‌شوند
↓
نیاز به اجرای Regression Test بررسی می‌شود

بنابراین Traceability می‌تواند در Change Impact Analysis یا تحلیل اثر تغییر نیز نقش مهمی داشته باشد.

آیا همه پروژه‌ها به Traceability Matrix نیاز دارند؟

نه لزوماً.

در پروژه‌های کوچک، ممکن است یک سیستم ساده مدیریت تست یا حتی ارتباط مستقیم بین User Story و Test Case کافی باشد.

در پروژه‌های بزرگ‌تر یا حساس‌تر، ممکن است از ابزارهای مدیریت تست، Issue Trackerها یا یک Requirements Traceability Matrix (RTM) استفاده شود.

نکته مهم، استفاده از یک قالب یا ابزار خاص نیست.

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

این نیازمندی چگونه تست شده است؟

و:

اگر این نیازمندی تغییر کند، چه چیزهایی ممکن است تحت تأثیر قرار بگیرند؟

اگر تیم بتواند به این سؤال‌ها پاسخ دهد، سطح مناسبی از Traceability ایجاد شده است؛ حتی اگر یک فایل جداگانه با عنوان RTM وجود نداشته باشد.

وقتی PRD تغییر می‌کند، تستر چه کاری باید انجام دهد؟

تغییر PRD یا نیازمندی در طول توسعه محصول اتفاق غیرعادی نیست.

ممکن است:

نیاز کاربر تغییر کند.
اطلاعات جدیدی به دست بیاید.
یک محدودیت فنی کشف شود.
اولویت‌های محصول تغییر کنند.
بخشی از Scope حذف یا اضافه شود.
رفتار Feature پس از گفت‌وگوهای تیم تغییر کند.

بنابراین هدف تستر این نیست که از هر تغییری جلوگیری کند.

موضوع مهم‌تر این است که تغییر چگونه مدیریت و تحلیل می‌شود.

۱. دقیقاً مشخص کنید چه چیزی تغییر کرده است

اولین قدم این نیست که بلافاصله Test Caseها را تغییر دهید.

ابتدا باید مشخص شود:

کدام بخش PRD تغییر کرده است؟
رفتار جدید چیست؟
رفتار قبلی چه بوده است؟
آیا Acceptance Criteria نیز تغییر کرده‌اند؟
آیا Scope تغییر کرده است؟

گاهی یک تغییر ظاهراً کوچک می‌تواند اثر بزرگی داشته باشد.

برای مثال، تغییر عبارت:

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

به:

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

می‌تواند چندین سناریوی تست را تحت تأثیر قرار دهد.

۲. Change Impact Analysis انجام دهید

پس از مشخص شدن تغییر، تستر باید بررسی کند که این تغییر چه چیزهایی را تحت تأثیر قرار می‌دهد.

کدام Test Scenarioها باید تغییر کنند؟
کدام Test Caseها دیگر معتبر نیستند؟
آیا Test Data تغییر می‌کند؟
آیا نیاز به تغییر محیط تست وجود دارد؟
آیا بخش‌های دیگری از سیستم تحت تأثیر قرار گرفته‌اند؟
آیا Regression Testing لازم است؟

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

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

۳. فقط تست‌های موجود را به‌روزرسانی نکنید؛ تست‌های جدید را هم بررسی کنید

یکی از اشتباهات رایج این است که تستر فقط Test Caseهایی را که قبلاً وجود داشته‌اند اصلاح کند.

اما هر تغییر ممکن است رفتارهای جدیدی ایجاد کند.

برای مثال، اگر قابلیت لغو سفارش فقط تا قبل از تأیید پرداخت محدود شود، ممکن است نیاز به سناریوهای جدیدی مانند این‌ها باشد:

لغو سفارش قبل از پرداخت.
تلاش برای لغو هنگام شروع فرآیند پرداخت.
تلاش برای لغو پس از تأیید پرداخت.
بررسی پیام مناسب برای کاربر.
بررسی تأثیر لغو روی موجودی یا وضعیت سفارش.

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

۴. بررسی کنید چه چیزهایی نباید تغییر کرده باشند

تحلیل اثر تغییر فقط مربوط به رفتارهای جدید نیست.

تستر باید بررسی کند:

چه قابلیت‌هایی باید همچنان مانند قبل کار کنند؟

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

یا تغییر در فرآیند ثبت‌نام نباید به‌طور ناخواسته فرآیند ورود کاربران موجود را خراب کند.

در چنین شرایطی، ممکن است نیاز به اجرای تست‌های Regression باشد.

اینکه دقیقاً چه میزان Regression Testing لازم است، به گستردگی تغییر و سطح ریسک آن بستگی دارد.

۵. با تیم درباره تغییر، هم‌فهمی ایجاد کنید

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

پس از تغییر نیازمندی، بهتر است مشخص شود:

Product Manager انتظار چه رفتاری دارد؟
Developer چه چیزی را باید تغییر دهد؟
Tester چه چیزهایی را باید بررسی کند؟

در Featureهای مهم یا تغییرات پیچیده، یک گفت‌وگوی کوتاه می‌تواند از ایجاد برداشت‌های متفاوت جلوگیری کند.

یک روال ساده برای مواجهه با تغییر PRD

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

PRD تغییر می‌کند
↓
تغییر دقیق شناسایی می‌شود
↓
Scope و رفتارهای تحت تأثیر بررسی می‌شوند
↓
Test Scenario و Test Caseهای مرتبط شناسایی می‌شوند
↓
تست‌های موجود به‌روزرسانی می‌شوند
↓
نیاز به تست‌های جدید بررسی می‌شود
↓
Regression Test موردنیاز مشخص می‌شود

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

یک PRD خوب از نگاه تستر چه ویژگی‌هایی دارد؟

یک PRD خوب لزوماً طولانی‌ترین PRD نیست.

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

از نگاه تستر، یک PRD مناسب باید به‌اندازه‌ای اطلاعات داشته باشد که بتواند درک مشترکی از مسئله و Feature ایجاد کند و مسیر تحلیل نیازمندی و طراحی تست را روشن‌تر سازد.

مسئله و هدف آن مشخص است

تستر باید بتواند متوجه شود:

چرا این Feature ساخته می‌شود؟
چه مسئله‌ای را حل می‌کند؟
چه نتیجه‌ای از آن انتظار می‌رود؟

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

کاربران و Context مشخص هستند

یک PRD خوب مشخص می‌کند Feature برای چه کسانی و در چه شرایطی طراحی شده است.

برای مثال، عبارت:

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

اطلاعات محدودی ارائه می‌دهد.

اما اگر مشخص شود:

مدیر فروش می‌تواند گزارش فروش ماهانه مربوط به شعبه‌های تحت مدیریت خود را مشاهده کند.

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

Scope و Out of Scope روشن هستند

تستر باید بداند:

چه چیزی بخشی از تغییر است؟
چه چیزی فعلاً قرار نیست پیاده‌سازی شود؟

این موضوع هم برای طراحی تست و هم برای تحلیل اثر تغییر اهمیت دارد.

رفتارهای مهم قابل درک هستند

نیازی نیست تمام جزئیات در متن اصلی PRD نوشته شوند، اما رفتارهای مهم نباید کاملاً به برداشت افراد واگذار شوند.

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

ابهام‌های مهم تا حد امکان کاهش یافته‌اند

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

سریع
مناسب
امن
ساده
در شرایط خاص

اگر روی رفتار قابل پیاده‌سازی یا قابل تست تأثیر دارند، باید تعریف دقیق‌تری داشته باشند.

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

وابستگی‌ها و محدودیت‌ها قابل مشاهده هستند

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

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

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

معیارهای پذیرش قابل بررسی هستند

Acceptance Criteria باید به تیم کمک کند تشخیص دهد رفتار مورد انتظار چیست.

اگر یک معیار فقط این باشد:

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

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

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

امکان ایجاد Traceability وجود دارد

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

نیازی نیست همه PRDها دارای شماره‌گذاری پیچیده باشند، اما در پروژه‌های بزرگ‌تر، شناسه‌گذاری مناسب می‌تواند مدیریت تغییر و تحلیل اثر را ساده‌تر کند.

یک PRD خوب از نگاه تستر، «قابل سؤال کردن» هم هست

شاید مهم‌ترین نکته این باشد که PRD خوب الزاماً سندی نیست که هیچ سؤالی درباره آن وجود نداشته باشد.

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

اگر تستر هنگام مطالعه PRD سؤالی دارد، این الزاماً نشانه ضعیف بودن سند نیست.

مشکل زمانی ایجاد می‌شود که:

ابهام‌های مهم نادیده گرفته شوند.
کسی مسئول پاسخ‌گویی نباشد.
تصمیم‌ها ثبت نشوند.
اعضای تیم با برداشت‌های متفاوت شروع به کار کنند.

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

چک‌لیست بررسی PRD برای تستر و QA ✅

تا اینجا بررسی کردیم که تستر و QA هنگام مطالعه PRD می‌توانند به چه مواردی توجه کنند. اما در عمل، به‌خصوص زمانی که چند Feature به‌صورت هم‌زمان در حال توسعه هستند، داشتن یک چک‌لیست می‌تواند کمک کند بررسی نیازمندی‌ها ساختارمندتر انجام شود.

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

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

درک مسئله و هدف

آیا مشخص است این Feature چه مسئله‌ای را حل می‌کند؟
آیا هدف محصول از ایجاد این قابلیت روشن است؟
آیا مشخص است موفقیت این Feature چگونه ارزیابی می‌شود؟
آیا هدف با قابلیت‌هایی که در PRD تعریف شده‌اند هم‌خوانی دارد؟

کاربران و ذی‌نفعان

کاربران هدف چه کسانی هستند؟
آیا نقش‌ها یا گروه‌های مختلف کاربران مشخص شده‌اند؟
آیا تفاوت رفتار Feature برای کاربران مختلف مشخص است؟
آیا دسترسی‌ها و محدودیت‌های کاربران روشن هستند؟
آیا ذی‌نفع یا سیستم دیگری وجود دارد که تحت تأثیر این Feature قرار بگیرد؟

Scope و Out of Scope

آیا مشخص است دقیقاً چه مواردی در Scope قرار دارند؟
آیا موارد خارج از Scope مشخص شده‌اند؟
آیا مرز Feature با قابلیت‌های موجود روشن است؟
آیا احتمال دارد این تغییر روی بخش‌های دیگری از سیستم تأثیر بگذارد؟
آیا چیزی وجود دارد که تیم تصور کند بخشی از Feature است، اما در PRD مشخص نشده باشد؟

قابلیت‌ها و رفتارهای اصلی

آیا جریان‌های اصلی مشخص شده‌اند؟
آیا مشخص است کاربر چه کاری می‌تواند انجام دهد؟
آیا نتیجه مورد انتظار هر عملیات مشخص است؟
آیا رفتار سیستم در وضعیت‌های مختلف قابل درک است؟
آیا بین بخش‌های مختلف PRD تناقضی وجود ندارد؟

User Story و Acceptance Criteria

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

ابهام‌ها و اطلاعات ناقص

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

وابستگی‌ها و محدودیت‌ها

آیا Feature به سرویس، API یا سیستم دیگری وابسته است؟
آیا وابستگی به تیم یا Feature دیگری وجود دارد؟
آیا محدودیت‌های فنی یا کسب‌وکاری مشخص شده‌اند؟
آیا رفتار سیستم در صورت در دسترس نبودن وابستگی‌های مهم مشخص است؟
آیا محیط یا داده خاصی برای تست موردنیاز است؟

ریسک‌ها

کدام جریان‌ها برای کسب‌وکار یا کاربر حیاتی هستند؟
کدام بخش‌ها پیچیدگی بیشتری دارند؟
کدام تغییرات ممکن است روی قابلیت‌های موجود اثر بگذارند؟
آیا Feature با داده‌های حساس یا عملیات مهم سروکار دارد؟
در صورت خرابی هر بخش، میزان تأثیر آن چقدر است؟

Testability

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

تغییر و Traceability

آیا نیازمندی‌ها یا قابلیت‌ها قابل شناسایی هستند؟
آیا می‌توان آن‌ها را به User Story و Acceptance Criteria مرتبط کرد؟
آیا در صورت تغییر نیازمندی، می‌توان تست‌های تحت تأثیر را شناسایی کرد؟
آیا تغییرات مهم PRD ثبت و به تیم اطلاع داده می‌شوند؟

لازم نیست تمام موارد چک‌لیست را برای هر PRD بررسی کنید

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

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

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

هدف این نیست که QA یا تستر برای هر PRD ده‌ها سؤال ایجاد کند.

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

PRD چه چیزهایی را به تستر نمی‌گوید؟

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

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

در واقع، PRD معمولاً بخشی از تصویر را ارائه می‌دهد، نه تمام آن را.

PRD معمولاً جایگزین مستندات فنی نیست

PRD ممکن است مشخص کند:

کاربر باید بتواند فایل خود را بارگذاری کند.

اما معمولاً قرار نیست تمام جزئیات فنی مانند موارد زیر را توضیح دهد:

API چگونه طراحی شده است؟
ساختار درخواست و پاسخ چیست؟
داده‌ها در کدام سیستم ذخیره می‌شوند؟
چه مکانیزمی برای مدیریت خطا وجود دارد؟
ارتباط بین سرویس‌ها چگونه انجام می‌شود؟

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

PRD لزوماً تمام Test Scenarioها را مشخص نمی‌کند

PRD هدف و رفتار مورد انتظار را توضیح می‌دهد، اما وظیفه اصلی آن نوشتن Test Case نیست.

برای مثال، اگر در PRD آمده باشد:

کاربر می‌تواند فایل PDF را بارگذاری کند.

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

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

فایل PDF معتبر.
فایل با حجم بیشتر از حد مجاز.
فایل خراب.
فایل با نام غیرمعمول.
قطع ارتباط هنگام بارگذاری.
تلاش هم‌زمان برای بارگذاری چند فایل.

برخی از این موارد ممکن است در Acceptance Criteria مشخص شده باشند و برخی دیگر براساس تحلیل تست و ریسک شناسایی شوند.

PRD همیشه تمام جزئیات مربوط به محیط تست را مشخص نمی‌کند

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

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

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

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

PRD جایگزین تحلیل ریسک تستر نیست

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

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

محاسبه مبلغ نهایی.
ثبت تراکنش.
وضعیت سفارش.
گزارش‌های مالی.

این ارتباطات همیشه به‌صورت کامل در PRD نوشته نمی‌شوند.

PRD پاسخ تمام سؤال‌ها را ندارد

ممکن است بعد از مطالعه PRD همچنان سؤال‌هایی باقی بمانند.

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

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

اگر یک موضوع روی توسعه یا تست تأثیر مهمی دارد، بهتر است درباره آن با فرد یا تیم مسئول گفت‌وگو شود.

به همین دلیل، بهتر است PRD را یکی از منابع اصلی برای درک Feature بدانیم، نه تنها منبع حقیقت در تمام شرایط.

اشتباهات رایج در نوشتن PRD ⚠️

یک PRD ضعیف لزوماً به این معنی نیست که Product Manager کار خود را به‌درستی انجام نداده است.

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

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

تمرکز فقط بر راه‌حل و نادیده گرفتن مسئله

گاهی PRD مستقیماً با این جمله شروع می‌شود:

یک دکمه جدید به صفحه اضافه شود.

اما مشخص نیست:

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

وقتی فقط راه‌حل مشخص باشد، درک Context برای Developer و Tester دشوارتر می‌شود.

مبهم بودن Scope

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

برای مثال:

امکان ویرایش پروفایل بهبود داده شود.

این جمله مشخص نمی‌کند:

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

PRD بهتر است مرز تغییر را تا حد ممکن روشن کند.

نادیده گرفتن Out of Scope

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

این موضوع می‌تواند باعث افزایش Scope و ایجاد انتظارهای متفاوت شود.

برای مثال، اضافه شدن امکان تغییر شماره تلفن ممکن است به معنی بازطراحی کامل فرآیند احراز هویت نباشد.

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

استفاده بیش از حد از عبارت‌های مبهم

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

سریع
ساده
مناسب
امن
کاربرپسند

برای مثال:

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

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

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

مشخص نکردن معیارهای موفقیت

گاهی PRD توضیح می‌دهد که چه Featureی باید ساخته شود، اما مشخص نمی‌کند چرا و چگونه متوجه می‌شویم این Feature موفق بوده است.

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

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

البته این معیارها با Acceptance Criteria یکسان نیستند.

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

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

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

برای مثال، تیم تست ممکن است برنامه تست را آماده کرده باشد، اما سرویس موردنیاز هنوز در محیط تست در دسترس نباشد.

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

تبدیل PRD به سند بیش از حد بزرگ و پیچیده

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

ممکن است اطلاعات مربوط به محصول، طراحی، معماری فنی و جزئیات اجرایی همگی در یک سند قرار بگیرند.

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

PRD خوب باید به‌اندازه نیاز، اطلاعات مفید ارائه دهد؛ نه اینکه تمام دانش پروژه را در یک فایل جمع کند.

فرض کردن اینکه PRD پس از انتشار اولیه تغییر نمی‌کند

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

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

در نتیجه، تیم ممکن است براساس اطلاعات قدیمی تصمیم بگیرد یا تست طراحی کند.

به همین دلیل، مدیریت تغییرات PRD نیز اهمیت دارد.

در بخش بعدی بررسی می‌کنیم که آیا واقعاً همه پروژه‌ها به PRD نیاز دارند یا خیر، سپس به چند سؤال متداول درباره PRD پاسخ می‌دهیم و در پایان مقاله را جمع‌بندی می‌کنیم.

آیا همه پروژه‌ها به PRD نیاز دارند؟

خیر. همه پروژه‌ها لزوماً به یک PRD رسمی، طولانی و چندین‌صفحه‌ای نیاز ندارند.

میزان مستندسازی باید با عواملی مانند اندازه پروژه، پیچیدگی محصول، تعداد اعضای تیم، میزان ریسک و نحوه همکاری تیم متناسب باشد.

برای یک تغییر کوچک، ممکن است یک توضیح کوتاه همراه با User Story و Acceptance Criteria کافی باشد. اما برای یک Feature جدید و پیچیده که چند تیم یا چند سیستم را درگیر می‌کند، داشتن یک PRD ساختارمند می‌تواند از بسیاری از سوءبرداشت‌ها جلوگیری کند.

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

آیا پروژه ما حتماً به PRD نیاز دارد؟

بلکه این است:

تیم برای ایجاد درک مشترک از مسئله، هدف، Scope و رفتار مورد انتظار به چه میزان مستندسازی نیاز دارد؟

چه زمانی یک PRD می‌تواند مفیدتر باشد؟

داشتن PRD معمولاً در شرایط زیر ارزش بیشتری دارد:

Feature نسبتاً پیچیده است.
مسئله یا هدف محصول نیاز به توضیح دارد.
چند تیم یا چند نقش مختلف روی Feature کار می‌کنند.
وابستگی به سیستم‌ها یا سرویس‌های دیگر وجود دارد.
Scope Feature ممکن است دچار سوءبرداشت شود.
تصمیم‌های مهم محصول باید مستند شوند.
Feature ریسک یا اهمیت بالایی دارد.
انتظار می‌رود نیازمندی‌ها در طول زمان توسط افراد مختلف بررسی شوند.

برای مثال، فرض کنید یک تیم قصد دارد سیستم جدیدی برای مدیریت اشتراک کاربران ایجاد کند.

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

خرید اشتراک.
تمدید اشتراک.
لغو اشتراک.
مدیریت پرداخت.
تغییر پلن.
محدودیت دسترسی کاربران.
ارتباط با سرویس پرداخت.

در چنین شرایطی، توضیح دادن تمام این موارد فقط در چند پیام یا یک User Story کوتاه احتمالاً کافی نیست. یک PRD می‌تواند به تیم کمک کند تصویر کلی Feature، هدف، Scope و وابستگی‌ها را بهتر درک کند.

چه زمانی ممکن است PRD مفصل ضروری نباشد؟

برای تغییرات کوچک، تهیه یک PRD طولانی ممکن است بیشتر از اینکه مفید باشد، زمان تیم را بگیرد.

برای مثال:

اصلاح یک متن در رابط کاربری.
تغییر رنگ یک دکمه.
اضافه کردن یک فیلتر ساده به صفحه‌ای که رفتار آن مشخص است.
اصلاح یک Bug با محدوده کاملاً مشخص.

در چنین شرایطی، ممکن است اطلاعات زیر کافی باشد:

توضیح کوتاه تغییر.
دلیل انجام تغییر.
Scope مشخص.
Acceptance Criteria.

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

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

PRD یک قالب ثابت برای همه تیم‌ها نیست

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

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

Problem
Goal
Users
Scope
Requirements
Success Metrics

در حالی که تیم دیگر، بخش‌های زیر را نیز اضافه کند:

User Journey
Dependencies
Risks
Open Questions
Rollout Plan

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

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

یک PRD کوتاه اما شفاف، بهتر از یک PRD طولانی اما مبهم است

طول PRD به‌تنهایی معیار کیفیت آن نیست.

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

از نگاه تستر، PRD زمانی ارزشمند است که بتواند به پاسخ دادن به سؤال‌هایی مانند این‌ها کمک کند:

چرا این Feature ساخته می‌شود؟
برای چه کسی است؟
چه چیزی باید ساخته شود؟
چه چیزی فعلاً خارج از محدوده است؟
رفتارهای مهم چیستند؟
چه وابستگی‌ها و محدودیت‌هایی وجود دارد؟
چه چیزهایی نیاز به شفاف‌سازی دارند؟

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

سوالات متداول

PRD چیست؟

PRD یا Product Requirements Document سندی است که نیازمندی‌ها و اطلاعات مهم یک محصول یا Feature را از نگاه محصول مشخص می‌کند. این سند معمولاً به تیم کمک می‌کند مسئله، هدف، کاربران هدف، Scope، قابلیت‌های اصلی و معیارهای موفقیت را درک کند.

PRD چه تفاوتی با BRD و SRS دارد؟

BRD بیشتر روی نیازها و اهداف کسب‌وکار تمرکز دارد، PRD مشخص می‌کند محصول یا Feature چه ارزشی باید ایجاد کند و چه قابلیت‌هایی در اختیار کاربر قرار دهد، و SRS معمولاً نیازمندی‌های نرم‌افزار را با جزئیات دقیق‌تر و قابل پیاده‌سازی و تست بیان می‌کند. در عمل، مرز این اسناد ممکن است بسته به سازمان و روش کاری تیم متفاوت باشد.

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

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

آیا PRD همان Acceptance Criteria است؟

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

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

در بسیاری از تیم‌ها، Product Manager یا Product Owner مسئول اصلی تهیه و مدیریت PRD است. با این حال، اطلاعات موردنیاز این سند ممکن است با مشارکت Designer، Developer، QA، ذی‌نفعان کسب‌وکار و سایر اعضای تیم تکمیل شود.

چرا تستر نرم‌افزار باید PRD را بخواند؟

مطالعه PRD به تستر کمک می‌کند فقط روی آنچه پیاده‌سازی شده تمرکز نکند، بلکه مسئله، هدف Feature، کاربران، Scope، وابستگی‌ها و ریسک‌ها را نیز درک کند. این اطلاعات می‌توانند در شناسایی ابهام‌ها، تحلیل ریسک و طراحی Test Scenario و Test Case مفید باشند.

آیا همه PRDها باید شامل User Story و Acceptance Criteria باشند؟

خیر. ساختار PRD در همه سازمان‌ها یکسان نیست. برخی تیم‌ها User Story و Acceptance Criteria را در خود PRD قرار می‌دهند و برخی دیگر آن‌ها را در ابزارهای مدیریت کار یا مستندات جداگانه نگهداری می‌کنند. مهم این است که ارتباط بین نیازمندی‌ها و معیارهای مورد انتظار برای تیم مشخص باشد.

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

تستر بهتر است ابهام را به یک سؤال مشخص تبدیل کند و آن را همراه با Context مطرح کند. به‌جای اینکه فقط بگوید «این مورد مبهم است»، می‌تواند مشخص کند چه شرایط، رفتار یا نتیجه‌ای نامشخص است و چرا این موضوع روی توسعه یا تست تأثیر می‌گذارد.

آیا برای پروژه‌های کوچک به PRD نیاز داریم؟

لزومی ندارد برای همه پروژه‌ها یک PRD رسمی و مفصل تهیه شود. برای تغییرات کوچک، ممکن است یک توضیح کوتاه همراه با Scope و Acceptance Criteria کافی باشد. میزان مستندسازی باید با پیچیدگی، ریسک و نیاز تیم به هماهنگی متناسب باشد.

جمع‌بندی

PRD یا Product Requirements Document سندی است که به تیم کمک می‌کند قبل از ورود به جزئیات پیاده‌سازی، درک مشترکی از محصول یا Feature ایجاد کند.

یک PRD می‌تواند مشخص کند:

چه مسئله‌ای قرار است حل شود.
هدف محصول چیست.
کاربران هدف چه کسانی هستند.
چه مواردی در Scope قرار دارند.
چه چیزهایی خارج از محدوده هستند.
قابلیت‌ها و نیازمندی‌های اصلی چه هستند.
چه وابستگی‌ها و محدودیت‌هایی وجود دارد.
موفقیت Feature چگونه ارزیابی می‌شود.

برای تستر و QA، ارزش PRD فقط در خواندن نیازمندی‌ها خلاصه نمی‌شود.

PRD می‌تواند نقطه شروعی برای موارد زیر باشد:

شناسایی ابهام‌ها.
مطرح کردن سؤال‌های درست.
بررسی Testability.
شناسایی وابستگی‌ها.
تحلیل ریسک.
طراحی Test Scenario و Test Case.
ایجاد Traceability.
تحلیل اثر تغییرات.

نکته مهم این است که تستر نباید PRD را صرفاً سندی بداند که Product Manager نوشته و پس از مطالعه آن باید منتظر نسخه قابل تست بماند.

هرچه تستر زودتر با مسئله، هدف و Context یک Feature آشنا شود، فرصت بیشتری دارد تا قبل از شروع یا در طول توسعه، ابهام‌ها و ریسک‌ها را شناسایی کند.

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

طبقه بندی شده در:

دسته‌بندی نشده,

اخرین بروزرسانی: شهریور 5, 1405

ESC را فشار دهید تا بسته شود

PRD چیست؟

PRD فقط یک سند ثابت نیست

PRD چه سطحی از جزئیات دارد؟

PRD چه هدفی دارد؟

ایجاد درک مشترک

مشخص کردن مسئله قبل از تمرکز بر راه‌حل

مشخص کردن محدوده محصول یا Feature

ایجاد مبنایی برای تصمیم‌گیری

ایجاد پایه‌ای برای طراحی، توسعه و تست

PRD در کجای چرخه توسعه محصول و نرم‌افزار قرار می‌گیرد؟

PRD معمولاً پیش از ورود به جزئیات توسعه و تست شکل می‌گیرد

PRD و نگاه Shift Left

PRD نقطه شروع اجرای تست نیست، اما می‌تواند نقطه شروع تفکر تست باشد

جایگاه PRD در Agile چگونه است؟

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

تفاوت PRD با BRD و SRS چیست؟

BRD؛ چرا این نیاز وجود دارد؟

PRD؛ محصول باید چه چیزی ارائه دهد؟

SRS؛ نرم‌افزار دقیقاً چه نیازمندی‌هایی باید برآورده کند؟

یک مثال برای مقایسه BRD، PRD و SRS

آیا همیشه باید BRD، PRD و SRS داشته باشیم؟

PRD، BRD و SRS از نگاه تستر

چه بخش‌هایی معمولاً در یک PRD وجود دارد؟

مسئله

اهداف محصول

کاربران هدف

Scope و Out of Scope

قابلیت‌ها و نیازمندی‌های اصلی

User Story

Acceptance Criteria

وابستگی‌ها و محدودیت‌ها

معیارهای موفقیت

همه PRDها لازم نیست تمام این بخش‌ها را داشته باشند

اجزای PRD را با یک مثال بررسی کنیم

مسئله

هدف محصول

کاربران هدف

Scope

Out of Scope

قابلیت‌ها و نیازمندی‌های اصلی

User Story

Acceptance Criteria

وابستگی‌ها

محدودیت‌ها

معیارهای موفقیت

این مثال چه چیزی به تستر نشان می‌دهد؟

تفاوت PRD با User Story و Acceptance Criteria چیست؟

PRD؛ تصویر کلی محصول یا Feature

User Story؛ نیاز از نگاه کاربر

Acceptance Criteria؛ شرایط قابل قبول بودن

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

یک مقایسه سریع

PRD چه ارتباطی با تیم توسعه و تست دارد؟

PRD به Developer چه کمکی می‌کند؟

PRD به Tester چه کمکی می‌کند؟

PRD و همکاری بین تیم محصول، توسعه و تست

چرا تستر نرم‌افزار باید PRD را بخواند؟ 🧪

۱. درک «چرا» پشت Feature

۲. شناسایی ابهام‌ها قبل از تبدیل شدن به مشکل

۳. شناسایی ریسک‌ها و وابستگی‌ها

۴. طراحی بهتر Test Scenarioها

۵. مشارکت در کیفیت نیازمندی‌ها

۶. جلوگیری از تمرکز صرف بر Happy Path

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

نگاه Product Manager، Developer و Tester به PRD چه تفاوتی دارد؟

Product Manager؛ آیا مسئله و هدف درست تعریف شده‌اند؟

Developer؛ دقیقاً چه چیزی باید ساخته شود؟

Tester؛ چه چیزی ممکن است اشتباه شود؟

سه نگاه متفاوت، یک هدف مشترک

تستر هنگام بررسی PRD باید دنبال چه چیزهایی باشد؟ 🔍

هدف و مسئله

کاربران

Scope و Out of Scope

ابهام‌ها

وابستگی‌ها

ریسک‌ها

Testability

PRD و Testability؛ چگونه بفهمیم یک نیازمندی قابل تست است؟

ویژگی‌های یک نیازمندی قابل تست