مستندات نرم‌افزار چیست؟ انواع مستندسازی فنی در توسعه نرم‌افزار

تصور کنید به‌عنوان یک تستر وارد یک پروژه جدید شده‌اید. قرار است قابلیت «انتقال وجه» را تست کنید. یک User Story در اختیار شماست و چند Acceptance Criteria هم نوشته شده است. اما هنوز یک سؤال مهم وجود دارد:

سیستم دقیقاً چگونه این کار را انجام می‌دهد؟

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

برای پاسخ به این سؤال‌ها، فقط User Story و رابط کاربری کافی نیستند.

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

به این مجموعه، مستندات نرم‌افزار (Software Documentation) گفته می‌شود.

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

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

Table of Contents

۱. مستندات نرم‌افزار چیست؟

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

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

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

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

مستندات نرم‌افزار چه چیزهایی را پوشش می‌دهند؟

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

مستندات نرم‌افزار │ ├── مستندات نیازمندی‌ها │ ├── مستندات طراحی و معماری │ ├── HLD │ ├── LLD │ ├── Architecture Diagram │ └── Sequence Diagram │ ├── مستندات API و یکپارچه‌سازی │ ├── مستندات پایگاه داده │ ├── مستندات تست │ ├── مستندات استقرار و عملیات │ └── مستندات کاربری

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

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

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

۱.۱. چرا مستندات نرم‌افزار اهمیت دارند؟

یک نرم‌افزار معمولاً حاصل همکاری چند گروه مختلف است؛ از Product Manager و Business Analyst گرفته تا Developer، QA، DevOps و تیم پشتیبانی.

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

Product Manager می‌خواهد بداند:

این قابلیت چه مسئله‌ای را برای کاربر حل می‌کند؟

Developer می‌خواهد بداند:

این قابلیت چگونه باید پیاده‌سازی شود؟

QA می‌خواهد بداند:

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

DevOps می‌خواهد بداند:

این سرویس چگونه باید Deploy و اجرا شود؟

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

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

برای مثال، اگر فقط رابط کاربری انتقال وجه را ببینیم، ممکن است چند Test Case معمولی طراحی کنیم. اما وقتی معماری، API و جریان ارتباط بین سرویس‌ها را بررسی کنیم، ممکن است به سناریوهایی مانند Timeout، Retry، Duplicate Request، خطای سرویس خارجی و سایر Failureهای بین سرویس‌ها برسیم.

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

۲. چرا مستندات نرم‌افزار مهم هستند؟

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

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

ممکن است نداند:

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

مستندات مناسب می‌توانند پاسخ بسیاری از این سؤال‌ها را در اختیار او قرار دهند.

۲.۱. ایجاد درک مشترک از سیستم

در یک پروژه نرم‌افزاری، افراد مختلف با نیازها و دیدگاه‌های متفاوت روی یک محصول کار می‌کنند. Business Analyst روی نیازمندی تمرکز دارد، Developer روی پیاده‌سازی، QA روی کیفیت و رفتار سیستم و DevOps روی استقرار و اجرای آن.

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

برای مثال، یک User Story مشخص می‌کند:

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

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

Web Application ↓ API Gateway ↓ Account Service ↓ Database

در نتیجه QA فقط می‌داند چه چیزی باید اتفاق بیفتد نیست؛ بلکه دید بهتری نسبت به چگونگی کار سیستم نیز پیدا می‌کند.

۲.۲. کاهش وابستگی به افراد

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

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

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

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

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

۲.۳. کمک به توسعه و تغییر سیستم

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

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

Login ↓ Authentication Service ↓ User Service ↓ Database

در چنین شرایطی، مستندات معماری، API و وابستگی‌های سیستم می‌توانند به تیم کمک کنند Impact Analysis انجام دهد؛ یعنی بررسی کند یک تغییر چه بخش‌هایی از سیستم را تحت تأثیر قرار خواهد داد.

۲.۴. کمک به تیم QA

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

مستندات ↓ درک سیستم ↓ شناسایی ریسک ↓ تعیین Test Condition ↓ طراحی Test Scenario ↓ طراحی Test Case ↓ اجرای تست

برای مثال، اگر در مستندات معماری مشخص شود که انتقال وجه به یک سرویس بانکی خارجی وابسته است، QA می‌تواند علاوه بر Happy Path، سناریوهای Failure را نیز بررسی کند:

سرویس خارجی در دسترس است ↓ Success سرویس خارجی Timeout می‌شود ↓ Retry؟ سرویس خارجی خطا می‌دهد ↓ Rollback؟ درخواست دوباره ارسال می‌شود ↓ Duplicate؟

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

اما آیا هر پروژه‌ای باید تمام این مستندات را داشته باشد؟ پاسخ لزوماً خیر است.

۳. آیا هر پروژه نرم‌افزاری به همه این مستندات نیاز دارد؟

خیر. یکی از برداشت‌های اشتباه درباره مستندات نرم‌افزار این است که تصور کنیم هر پروژه باید مجموعه‌ای ثابت از اسناد مانند HLD، LLD، SRS، ERD، Test Plan و موارد دیگر داشته باشد.

در واقع، نوع، تعداد و میزان جزئیات مستندات به شرایط پروژه بستگی دارد.

یک پروژه کوچک ممکن است فقط چند User Story، مستندات API و چند Test Case داشته باشد؛ در حالی که یک سیستم بانکی بزرگ ممکن است ده‌ها نوع مستندات معماری، امنیت، یکپارچه‌سازی، پایگاه داده، تست، استقرار و عملیات داشته باشد.

۳.۱. چه عواملی تعیین می‌کنند چه مستنداتی لازم است؟

چند عامل مهم در این تصمیم نقش دارند:

اندازه و پیچیدگی سیستم

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

تعداد اعضای تیم

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

ریسک سیستم

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

الزامات قانونی و استانداردها

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

روش توسعه و فرهنگ تیم

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

۳.۲. مستندات زیاد همیشه بهتر نیستند

داشتن مستندات بیشتر لزوماً به معنی پروژه بهتر نیست.

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

سیستم واقعی ≠ مستندات

مثلاً مستندات API می‌گویند:

POST /api/transfer

اما API واقعی تغییر کرده و حالا Endpoint دیگری استفاده می‌شود.

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

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

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

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

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

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

Jira ├── User Story └── Acceptance Criteria Confluence ├── Architecture ├── Technical Specification └── Decisions Swagger / OpenAPI └── API Documentation Git ├── README └── Code Documentation Test Management Tool ├── Test Cases ├── Test Execution └── Test Reports

بنابراین وقتی می‌گوییم «مستندات نرم‌افزار»، نباید تصور کنیم الزاماً یک پوشه پر از فایل PDF یا Word داریم.

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

در ادامه، انواع اصلی مستندات نرم‌افزار را بررسی می‌کنیم و می‌بینیم هرکدام چه چیزی را توضیح می‌دهند و برای QA چه کاربردی دارند.

۴. انواع مستندات نرم‌افزار

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

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

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

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

۴.۱. مستندات نیازمندی‌ها

این مستندات مشخص می‌کنند نرم‌افزار چه کاری باید انجام دهد و چه انتظاری از آن وجود دارد.

برای مثال در BlueBank ممکن است یک نیازمندی چنین باشد:

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

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

SRS (Software Requirements Specification)
PRD (Product Requirements Document)
User Story
Acceptance Criteria
نیازمندی‌های Functional و Non-functional

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

مثلاً از Acceptance Criteria زیر:

انتقال وجه فقط زمانی موفق است که موجودی حساب مبدأ کافی باشد.

QA می‌تواند سناریوهایی مانند این موارد را استخراج کند:

موجودی بیشتر از مبلغ انتقال موجودی برابر با مبلغ انتقال موجودی کمتر از مبلغ انتقال موجودی صفر

بنابراین مستندات نیازمندی‌ها بیشتر به سؤال «چه چیزی باید اتفاق بیفتد؟» پاسخ می‌دهند.

۴.۲. مستندات طراحی و معماری

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

Web / Mobile ↓ API Gateway ↓ Transfer Service ↓ Payment Service ↓ External Bank

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

Architecture Documentation
HLD
LLD
Architecture Diagram
Component Diagram
Sequence Diagram

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

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

۴.۳. مستندات API و یکپارچه‌سازی

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

برای مثال:

POST /api/transfers

ممکن است مستندات API موارد زیر را مشخص کنند:

Request
Response
HTTP Status Codes
Authentication
Required Fields
Validation Rules
Error Messages

ابزارهایی مانند Swagger / OpenAPI نیز می‌توانند برای ثبت و ارائه این اطلاعات استفاده شوند.

این بخش برای QA اهمیت ویژه‌ای دارد، زیرا مستندات API مستقیماً می‌توانند مبنای API Testing قرار بگیرند.

۴.۴. مستندات پایگاه داده

این مستندات توضیح می‌دهند داده‌های نرم‌افزار چگونه ذخیره و با یکدیگر مرتبط هستند.

Customer │ ├── Account │ │ │ └── Transaction │ └── Card

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

ERD
Database Schema
Table Definitions
Data Dictionary
Database Relationships

برای QA، این اطلاعات به‌خصوص هنگام Database Testing و بررسی صحت داده‌ها مفید هستند.

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

Account Balance ↓ Transaction Record ↓ Transaction Status

آیا تمام داده‌ها مطابق انتظار تغییر کرده‌اند یا خیر.

۴.۵. مستندات تست نرم‌افزار

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

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

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

مهم‌ترین مستندات تست

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

Test Strategy — رویکرد کلی تیم برای تست
Test Plan — برنامه و محدوده تست یک پروژه یا نسخه
Test Scenario — سناریو یا وضعیت کلی که باید بررسی شود
Test Case — مراحل دقیق اجرای یک تست
Test Data — داده‌هایی که برای اجرای تست نیاز داریم
RTM (Requirements Traceability Matrix) — ارتباط بین نیازمندی‌ها و تست‌ها
Test Report — گزارش نتایج تست

این موارد الزاماً در همه پروژه‌ها به‌صورت اسناد جداگانه وجود ندارند. برای مثال، در یک تیم ممکن است Test Strategy و Test Plan در یک سند قرار بگیرند یا Test Scenario و Test Case در یک ابزار مدیریت تست ثبت شوند.

یک مثال در BlueBank

فرض کنیم نیازمندی این است:

کاربر باید بتواند در صورت کافی بودن موجودی حساب، مبلغی را به حساب دیگری انتقال دهد.

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

Test Scenario: انتقال وجه با موجودی کافی Test Case: انتقال 500,000 تومان از حسابی با موجودی 2,000,000 تومان Test Data: Source Account = 123456 Destination Account = 789012 Amount = 500,000

سپس Test Case می‌تواند جزئیات بیشتری داشته باشد:

Precondition: حساب مبدأ فعال است و موجودی کافی دارد. Steps: 1. ورود به حساب 2. انتخاب انتقال وجه 3. وارد کردن حساب مقصد 4. وارد کردن مبلغ 500,000 5. تأیید انتقال Expected Result: انتقال با موفقیت انجام شود. موجودی حساب مبدأ کاهش پیدا کند. تراکنش در سوابق ثبت شود. وضعیت تراکنش SUCCESS باشد.

اینجا ارتباط مستندات مختلف با یکدیگر مشخص می‌شود:

Requirement ↓ Acceptance Criteria ↓ Test Scenario ↓ Test Case ↓ Test Execution ↓ Test Result

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

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

External Service │ ├── Success ├── Timeout ├── Error └── Unavailable

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

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

۴.۶. مستندات استقرار و عملیات

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

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

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

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

Development ↓ Staging ↓ Production

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

هر محیط از چه سرویس‌هایی تشکیل شده است؟
چه تنظیماتی باید انجام شود؟
متغیرهای محیطی چگونه تنظیم می‌شوند؟
Database چگونه متصل می‌شود؟
سرویس‌ها چگونه اجرا می‌شوند؟
Deployment چگونه انجام می‌شود؟
در صورت بروز خطا چه اقداماتی باید انجام شود؟

برخی مستندات رایج در این حوزه عبارت‌اند از:

Deployment Documentation — راهنمای استقرار نرم‌افزار
Configuration Documentation — اطلاعات مربوط به تنظیمات سیستم
Environment Documentation — مشخصات محیط‌های مختلف
Runbook — دستورالعمل انجام عملیات مشخص یا برخورد با خطاها
Troubleshooting Documentation — راهنمای عیب‌یابی

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

ممکن است در نگاه اول تصور شود این مستندات فقط برای DevOps هستند، اما QA نیز در بسیاری از پروژه‌ها با آن‌ها سروکار دارد.

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

API Gateway ↓ Transfer Service ↓ Payment Service ↓ Notification Service

همچنین اگر مستندات مشخص کنند که برای شبیه‌سازی سرویس بانکی خارجی از یک Mock Service استفاده می‌شود، تستر می‌تواند سناریوهای مختلف پاسخ سرویس خارجی را بررسی کند:

Mock Payment Service │ ├── Success ├── 400 Error ├── 500 Error ├── Timeout └── Connection Failure

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

۴.۷. مستندات کاربری

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

برای مثال:

User Guide — راهنمای استفاده از نرم‌افزار
Installation Guide — راهنمای نصب
Help Documentation — راهنمای بخش‌های مختلف سیستم
FAQ — سؤالات متداول

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

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

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

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

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

تا اینجا با چند گروه اصلی از مستندات نرم‌افزار آشنا شدیم:

مستندات نرم‌افزار │ ├── نیازمندی‌ها │ ├── طراحی و معماری │ ├── API و یکپارچه‌سازی │ ├── پایگاه داده │ ├── تست │ ├── استقرار و عملیات │ └── کاربری

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

در بخش بعد، یک مثال جامع را دنبال می‌کنیم و می‌بینیم HLD، LLD، API Documentation و Sequence Diagram دقیقاً چه اطلاعاتی درباره قابلیت انتقال وجه به QA می‌دهند.

۵. مثال جامع: مستندات قابلیت انتقال وجه در BlueBank

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

فرض کنیم تیم BlueBank قرار است قابلیت جدیدی به نام انتقال وجه به سیستم اضافه کند. این قابلیت در ظاهر ممکن است ساده به نظر برسد، اما برای پیاده‌سازی و تست آن، اطلاعات مختلفی درباره نیازمندی، معماری، منطق داخلی، API، جریان تعاملات و داده‌های سیستم موردنیاز است.

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

۵.۱ Requirement؛ قابلیت انتقال وجه در BlueBank

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

سیستم دقیقاً چه رفتاری باید داشته باشد؟

این اطلاعات در مستندات نیازمندی‌ها (Requirements Documentation) ثبت می‌شود.

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

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

اما همین جمله برای توسعه و تست کافی نیست. QA باید بتواند از روی نیازمندی بفهمد:

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

بنابراین یک Requirement خوب باید تا حد امکان رفتار مورد انتظار سیستم و محدودیت‌های مهم آن را مشخص کند.

Requirement فقط یک سند خاص نیست

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

PRD (Product Requirements Document)
SRS (Software Requirements Specification)
User Story
Acceptance Criteria
یا ترکیبی از این موارد در ابزارهایی مانند Jira و Confluence

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

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

QA چگونه از Requirement استفاده می‌کند؟

QA از Requirement به‌عنوان یکی از منابع اصلی برای تعیین Test Condition استفاده می‌کند.

مثلاً اگر Requirement بگوید:

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

QA می‌تواند شرایطی مانند این‌ها را استخراج کند:

Test Condition	نمونه
وضعیت حساب مبدأ	فعال
وضعیت حساب مبدأ	غیرفعال
موجودی	بیشتر از مبلغ انتقال
موجودی	برابر مبلغ انتقال
موجودی	کمتر از مبلغ انتقال
مبلغ انتقال	مقدار معتبر
مبلغ انتقال	صفر
مبلغ انتقال	مقدار منفی

در نتیجه، Requirement نقطه شروع مسیر تست است:

Requirement
     ↓
Test Conditions
     ↓
Test Scenarios
     ↓
Test Cases

اما QA نباید فقط Requirement را بخواند و بلافاصله Test Case بنویسد.

برای قابلیت پیچیده‌ای مثل انتقال وجه، اطلاعات موجود در Requirement معمولاً باید در کنار Acceptance Criteria، معماری، API Documentation، Database Documentation و سایر مستندات بررسی شود.

QA Note: اگر QA نتواند از روی Requirement تشخیص دهد «چه چیزی باید درست باشد»، احتمالاً نیازمندی هنوز به اندازه کافی شفاف نیست یا اطلاعات لازم در بخش دیگری از مستندات قرار دارد.

۵.۲ User Story و Acceptance Criteria در قابلیت انتقال وجه

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

User Story

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

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

مثلاً از خود User Story نمی‌توانیم بفهمیم:

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

اینجاست که Acceptance Criteria (معیارهای پذیرش) اهمیت پیدا می‌کند.

Acceptance Criteria

برای مثال، معیارهای پذیرش قابلیت می‌تواند شامل این موارد باشد:

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

حالا QA اطلاعات بسیار دقیق‌تری برای شروع طراحی تست دارد.

تبدیل Acceptance Criteria به Test Condition

مثلاً از این معیار:

حساب مبدأ باید موجودی کافی برای انتقال داشته باشد.

می‌توان شرایط مختلفی استخراج کرد:

Acceptance Criteria	Test Condition
موجودی کافی باشد	موجودی بیشتر از مبلغ انتقال
موجودی کافی باشد	موجودی برابر مبلغ انتقال
موجودی کافی نباشد	موجودی کمتر از مبلغ انتقال

یا از این معیار:

مبلغ انتقال باید بیشتر از صفر باشد.

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

Test Condition	Test Data
مبلغ معتبر	500,000
مبلغ صفر	0
مبلغ منفی	-100
مقدار بسیار کوچک	1

بنابراین در یک جریان ساده:

User Story
     ↓
Acceptance Criteria
     ↓
Test Conditions
     ↓
Test Scenarios
     ↓
Test Cases

تفاوت Requirement، User Story و Acceptance Criteria

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

مفهوم	سؤال اصلی
Requirement	سیستم چه نیازی را باید برآورده کند؟
User Story	کاربر چه چیزی می‌خواهد و چرا؟
Acceptance Criteria	چه شرایطی باید برقرار باشد تا قابلیت پذیرفته شود؟

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

Project Insight: برای QA، Acceptance Criteria یکی از مهم‌ترین پل‌ها بین «نیازمندی» و «تست قابل اجرا» است. هرچه AC دقیق‌تر باشد، استخراج Test Condition و طراحی تست نیز ساده‌تر می‌شود.

در مرحله بعد، از همین Requirement و Acceptance Criteria عبور می‌کنیم و می‌بینیم HLD چه چیزی درباره ساختار فنی قابلیت انتقال وجه به QA نشان می‌دهد.

۵.۳ HLD؛ سیستم چگونه قابلیت انتقال وجه را پیاده می‌کند؟

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

اینجا HLD (High-Level Design) وارد می‌شود.

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

برای قابلیت انتقال وجه در BlueBank، می‌توانیم چنین ساختاری داشته باشیم:

                    BlueBank
                       │
                       ▼
                 Web / Mobile
                       │
                       ▼
                  API Gateway
                       │
                       ▼
                Transfer Service
                  /          \
                 ▼            ▼
        Account Service   Payment Service
                              │
                              ▼
                       External Bank

هر بخش چه نقشی دارد؟

Web / Mobile: رابطی است که کاربر از طریق آن درخواست انتقال وجه را ایجاد می‌کند.
API Gateway: درخواست را دریافت و به سرویس مناسب هدایت می‌کند و ممکن است وظایفی مانند Authentication، Authorization، Rate Limiting و Logging را نیز بر عهده داشته باشد.
Transfer Service: سرویس اصلی مدیریت فرآیند انتقال وجه است.
Account Service: اطلاعات حساب، وضعیت حساب و موجودی را در اختیار سیستم قرار می‌دهد.
Payment Service: مسئول ارتباط با سرویس یا سیستم پرداخت است.
External Bank: سیستم خارجی‌ای است که در ادامه فرآیند پرداخت یا انتقال با آن ارتباط برقرار می‌شود.

HLD چه چیزی به QA می‌گوید؟

نکته مهم این است که QA با دیدن HLD فقط نمی‌فهمد «سیستم چه شکلی است»؛ بلکه می‌تواند از روی همین ساختار، Dependencyها و Integration Pointهای مهم را شناسایی کند.

Transfer Service
      │
      ├──── Account Service
      │
      └──── Payment Service
                    │
                    └──── External Bank

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

اگر Account Service در دسترس نباشد چه اتفاقی می‌افتد؟
اگر Payment Service خطای 500 برگرداند چه می‌شود؟
اگر External Bank پاسخ ندهد چه می‌شود؟
اگر پاسخ External Bank با تأخیر برسد چه اتفاقی برای Transaction می‌افتد؟
آیا درخواست انتقال ممکن است دوبار پردازش شود؟
اگر Payment موفق شود اما ثبت Transaction در سیستم داخلی شکست بخورد چه می‌شود؟

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

HLD مستقیماً Test Case تولید نمی‌کند

یک نکته مهم:

HLD معمولاً مستقیماً Test Case به ما نمی‌دهد؛ بلکه ساختار سیستم، وابستگی‌ها و نقاط ریسک را برای QA آشکار می‌کند.

HLD
 ↓
Components
 ↓
Dependencies
 ↓
Integration Points
 ↓
Potential Failure Points
 ↓
Test Conditions

بعد QA می‌تواند این Test Conditionها را با اطلاعات Requirement، Acceptance Criteria و سایر مستندات ترکیب کند.

HLD چه چیزهایی را معمولاً نشان می‌دهد؟

اجزای اصلی سیستم
سرویس‌ها و ماژول‌ها
سیستم‌های خارجی
ارتباط بین Components
جریان کلی داده
وابستگی‌های مهم
مرزهای سیستم
تصمیم‌های مهم معماری

اما معمولاً وارد جزئیاتی مثل نام دقیق متدهای یک کلاس، الگوریتم داخلی یا منطق خط‌به‌خط نمی‌شود. این جزئیات بیشتر در LLD (Low-Level Design) قرار می‌گیرند که در بخش بعدی همین مثال BlueBank به آن می‌رسیم.

QA Note: برای Junior QA لازم نیست HLD را در سطح یک Software Architect طراحی کند. چیزی که اهمیت دارد این است که بتواند از روی معماری، اجزای سیستم، وابستگی‌ها، نقاط ارتباط و نقاط احتمالی شکست را تشخیص دهد.

۵.۴ LLD؛ داخل Transfer Service چه اتفاقی می‌افتد؟

در HLD دیدیم که قابلیت انتقال وجه از چه اجزای اصلی تشکیل شده و این اجزا چگونه با یکدیگر ارتباط دارند.

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

داخل Transfer Service دقیقاً چه اتفاقی می‌افتد؟

اینجا به LLD (Low-Level Design) نزدیک می‌شویم.

LLD نسبت به HLD جزئیات بیشتری درباره ساختار داخلی یک Component یا Service ارائه می‌دهد. بسته به روش مستندسازی تیم، ممکن است شامل کلاس‌ها، ماژول‌ها، Interfaceها، متدها، منطق کسب‌وکار، Validationها، Error Handling و نحوه تعامل با Database یا سرویس‌های دیگر باشد.

برای مثال، ساختار داخلی Transfer Service در BlueBank می‌تواند به شکل ساده زیر باشد:

                 Transfer Service
                        │
                        ▼
              TransferController
                        │
                        ▼
                TransferService
                 /      |       \
                ▼       ▼        ▼
          Validator  PaymentClient  TransactionRepository
                │       │        │
                │       ▼        ▼
                │   Payment API  Transaction DB
                │
                ▼
          Business Rules

جریان داخلی انتقال وجه

فرض کنیم LLD مشخص کرده است که فرآیند انتقال به این ترتیب انجام می‌شود:

Transfer Request
       ↓
Validate Request
       ↓
Validate Source Account
       ↓
Validate Destination Account
       ↓
Check Balance
       ↓
Create Transaction
       ↓
Call Payment Service
       ↓
Update Transaction Status
       ↓
Return Response

حالا QA اطلاعات بسیار دقیق‌تری نسبت به HLD در اختیار دارد.

مثلاً اگر در منطق سیستم مشخص شده باشد:

amount <= 0          → Reject
amount > balance     → Reject
source = destination → Reject

QA می‌تواند Test Conditionهای مشخصی استخراج کند:

قانون	شرایط قابل تست
`amount > 0`	مبلغ مثبت، صفر، منفی
`amount <= balance`	کمتر، برابر و بیشتر از موجودی
`source ≠ destination`	حساب متفاوت و حساب یکسان

LLD چه چیزی به QA اضافه می‌کند؟

HLD	LLD
سیستم از چه اجزایی تشکیل شده؟	هر جزء چگونه کار می‌کند؟
Serviceها چگونه ارتباط دارند؟	داخل Service چه منطقی اجرا می‌شود؟
وابستگی‌ها چیست؟	Validationها و Business Ruleها چیست؟
نقاط Integration کجاست؟	نقاط تصمیم‌گیری و خطای داخلی کجاست؟
دید کلان	دید جزئی‌تر

بنابراین:

HLD
 ↓
System-level risks
 ↓
Integration / Dependency Conditions

LLD
 ↓
Internal logic
 ↓
Validation / Boundary / State Conditions

البته مرز دقیق HLD و LLD در همه تیم‌ها یکسان نیست و ممکن است بعضی جزئیات در یک پروژه در HLD و در پروژه‌ای دیگر در LLD یا مستندات جداگانه قرار بگیرند.

QA Note: QA لازم نیست LLD را مثل Developer طراحی کند. اما اگر بتواند منطق داخلی یک قابلیت، Validationها، Stateها و Error Handling آن را بفهمد، می‌تواند تست‌هایی طراحی کند که صرفاً با استفاده از UI یا Requirement قابل کشف نیستند.

۵.۵ API Documentation؛ قرارداد ارتباطی بین اجزای سیستم

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

اینجا API Documentation اهمیت پیدا می‌کند.

اگر HLD به ما می‌گوید:

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

و LLD تا حدی توضیح می‌دهد:

داخل هر سرویس چه منطقی اجرا می‌شود؟

API Documentation به سؤال دیگری پاسخ می‌دهد:

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

یک نمونه API در BlueBank

POST /api/transfers

نمونه Request:

{
  "sourceAccount": "ACC-1001",
  "destinationAccount": "ACC-2045",
  "amount": 500000
}

و در صورت موفقیت:

{
  "transactionId": "TRX-1001",
  "status": "SUCCESS"
}

مستندات API می‌تواند اطلاعاتی مانند این موارد را مشخص کند:

اطلاعات	مثال
HTTP Method	POST
Endpoint	`/api/transfers`
Authentication	Bearer Token
Request Body	sourceAccount, destinationAccount, amount
Required Fields	هر سه فیلد
Data Type	String / Number
Response	transactionId, status
Status Code	200
Error Codes	400, 401, 403, 409, 500
Validation Rules	`amount > 0`

این اطلاعات برای API Testing بسیار مهم هستند.

QA از API Documentation چه استفاده‌ای می‌کند؟

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

amount باید عددی بزرگ‌تر از صفر باشد.

QA می‌تواند Test Conditionهایی مانند این‌ها ایجاد کند:

مقدار معتبر: 500000
مقدار صفر: 0
مقدار منفی: -100
مقدار خالی
مقدار Null
مقدار غیرعددی
مقدار بسیار بزرگ

یا اگر Documentation مشخص کرده باشد:

destinationAccount باید متعلق به یک حساب فعال باشد.

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

حساب معتبر و فعال
حساب معتبر ولی غیرفعال
حساب نامعتبر
حساب وجود ندارد
فیلد خالی
انتقال به همان حساب مبدأ

بنابراین API Documentation فقط یک راهنمای Developer نیست؛ برای QA یک منبع مهم برای طراحی و اجرای تست است.

API Documentation و Swagger / OpenAPI

در بسیاری از پروژه‌ها، مستندات API با استفاده از OpenAPI تهیه می‌شود و ابزارهایی مانند Swagger UI می‌توانند این APIها را به شکل قابل مشاهده و قابل تعامل نمایش دهند.

POST /api/transfers

Request:
  sourceAccount       string   required
  destinationAccount  string   required
  amount              number   required

Responses:
  200 → Success
  400 → Invalid Request
  401 → Unauthorized
  409 → Conflict
  500 → Internal Server Error

حالا QA علاوه بر Happy Path، می‌تواند Error Pathها را نیز بررسی کند.

یک نکته مهم: API Contract

API Documentation می‌تواند نقش یک قرارداد (Contract) بین مصرف‌کننده و ارائه‌دهنده API داشته باشد؛ البته میزان رسمی‌بودن این قرارداد به پروژه و نحوه استفاده تیم از مستندات بستگی دارد.

مثلاً اگر Documentation می‌گوید:

200 → SUCCESS
400 → Invalid Request
401 → Unauthorized
409 → Duplicate Transaction

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

پس تست API فقط این نیست که:

«آیا API جواب می‌دهد؟»

بلکه باید بررسی شود:

آیا API مطابق قراردادی که برای آن تعریف شده رفتار می‌کند؟

Project Insight: هرچه API Documentation دقیق‌تر باشد، QA کمتر مجبور است رفتار API را از روی حدس، کد یا آزمون‌وخطای تصادفی کشف کند.

مقاله‌های مرتبط آینده: API چیست؟ → API Testing چیست؟ → REST API چیست؟ → Swagger چیست؟ → OpenAPI چیست؟

در بخش بعدی، سراغ Sequence Diagram می‌رویم؛ جایی که همین API و سرویس‌ها را از نظر ترتیب زمانی تعاملات بررسی می‌کنیم.

۵.۶ Sequence Diagram؛ ترتیب تعامل اجزای سیستم

تا اینجا در مثال انتقال وجه BlueBank، چند سؤال مختلف را پاسخ داده‌ایم:

Requirement: چه چیزی باید اتفاق بیفتد؟
User Story و Acceptance Criteria: کاربر چه می‌خواهد و چه شرایطی باید برقرار باشد؟
HLD: سیستم از چه اجزایی تشکیل شده است؟
LLD: داخل اجزای مهم چه منطق و ساختاری وجود دارد؟
API Documentation: اجزای سیستم با چه قراردادی با یکدیگر ارتباط برقرار می‌کنند؟

حالا یک سؤال دیگر مطرح می‌شود:

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

اینجا Sequence Diagram می‌تواند بسیار مفید باشد.

Sequence Diagram چیست؟

Sequence Diagram نحوه تعامل چند Actor یا Component را در طول زمان نشان می‌دهد.

در مثال BlueBank، یک انتقال وجه می‌تواند چنین جریانی داشته باشد:

User
 │
 │  Transfer Request
 ▼
API Gateway
 │
 │  Forward Request
 ▼
Transfer Service
 │
 │  Check Balance
 ▼
Account Service
 │
 │  Balance OK
 ◄────────────────
 │
 │  Process Payment
 ▼
Payment Service
 │
 │  Payment Request
 ▼
External Bank
 │
 │  Payment Result
 ◄────────────────
 │
 │  Update Transaction
 ▼
Transaction DB
 │
 │
 ◄────────────────
Transfer Service
 │
 │  Success Response
 ▼
API Gateway
 │
 ▼
User

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

Sequence Diagram چه چیزی به QA نشان می‌دهد؟

فرض کنیم مسیر موفق به این شکل است:

Check Balance
      ↓
Create Transaction
      ↓
Process Payment
      ↓
Update Status = SUCCESS

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

اگر Check Balance موفق باشد ولی Payment شکست بخورد چه اتفاقی می‌افتد؟
اگر Payment موفق شود ولی Update Transaction شکست بخورد چه می‌شود؟
اگر External Bank پاسخ ندهد، آیا سیستم دوباره درخواست را ارسال می‌کند؟

این سؤال‌ها به ترتیب عملیات و وابستگی بین آن‌ها مربوط هستند.

Sequence Diagram برای پیدا کردن Failure Scenarioها مفید است

Transfer Service
      │
      ▼
Payment Service
      │
      ▼
External Bank
      │
      X
   Timeout

حالا QA باید بداند:

Transaction چه Statusی می‌گیرد؟
آیا Retry انجام می‌شود؟
چند بار Retry؟
آیا ممکن است انتقال دوبار انجام شود؟
آیا مبلغ Hold می‌شود؟
کاربر چه پیامی دریافت می‌کند؟

بعضی از این پاسخ‌ها در خود Sequence Diagram وجود ندارند و باید از Requirement، LLD، API Documentation یا سایر مستندات به دست بیایند.

بنابراین Sequence Diagram به‌تنهایی Test Oracle نیست؛ بلکه دید بهتری از جریان سیستم در اختیار QA قرار می‌دهد.

تفاوت HLD و Sequence Diagram

HLD	Sequence Diagram
ساختار کلی سیستم	ترتیب تعاملات
چه اجزایی وجود دارند؟	چه کسی با چه کسی و چه زمانی ارتباط دارد؟
دید ساختاری	دید رفتاری/زمانی
تمرکز روی Components و Dependencies	تمرکز روی Messages و Flow

برای مثال:

HLD می‌گوید:

Transfer Service → Payment Service → External Bank

اما Sequence Diagram می‌تواند بگوید:

1. Transfer Service درخواست می‌فرستد
2. Payment Service درخواست را دریافت می‌کند
3. Payment Service به External Bank درخواست می‌فرستد
4. External Bank پاسخ می‌دهد
5. Payment Service نتیجه را برمی‌گرداند
6. Transfer Service وضعیت Transaction را تغییر می‌دهد

QA Note: Sequence Diagram به‌خصوص برای تست Integration، API، Error Handling، Timeout، Retry و State Transition می‌تواند بسیار ارزشمند باشد.

مقاله مرتبط آینده: Sequence Diagram چیست؟ → انواع UML Diagram و کاربرد آن‌ها برای QA

در مرحله بعد، همین انتقال وجه را از زاویه Database Documentation بررسی می‌کنیم؛ یعنی ببینیم QA برای اطمینان از ثبت صحیح اطلاعات تراکنش، چه اطلاعاتی درباره Database نیاز دارد.

۵.۷ Database Documentation؛ داده‌های انتقال وجه کجا و چگونه ذخیره می‌شوند؟

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

اما یک سؤال مهم دیگر باقی می‌ماند:

بعد از انجام عملیات، چه داده‌ای در Database ایجاد یا تغییر می‌کند؟

اینجا Database Documentation اهمیت پیدا می‌کند.

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

یک ساختار ساده در BlueBank

Customer
   │
   └── Account
          │
          ├── source_account
          │
          └── Transaction
                 │
                 ├── transaction_id
                 ├── destination_account
                 ├── amount
                 ├── status
                 └── created_at

برای مثال، یک Transaction می‌تواند چنین اطلاعاتی داشته باشد:

Field	Example
`transaction_id`	TRX-1001
`source_account`	ACC-1001
`destination_account`	ACC-2045
`amount`	500000
`status`	SUCCESS
`created_at`	2026-09-10 14:20

البته ساختار واقعی Database به طراحی پروژه بستگی دارد و ممکن است بسیار متفاوت باشد.

QA از Database Documentation چه استفاده‌ای می‌کند؟

فرض کنیم کاربر یک انتقال موفق ۵۰۰ هزار تومانی انجام داده است.

QA فقط نباید بررسی کند که UI پیام «انتقال با موفقیت انجام شد» را نمایش می‌دهد.

در صورت نیاز به بررسی Backend، می‌توان بررسی کرد که آیا:

Transaction واقعاً ایجاد شده است؟
amount درست ذخیره شده است؟
حساب مبدأ و مقصد درست ثبت شده‌اند؟
status مقدار صحیح دارد؟
Transaction دوبار ایجاد نشده است؟
Timestamp صحیح ثبت شده است؟
ارتباط Transaction با Account صحیح است؟

API Response
    ↓
transactionId = TRX-1001
    ↓
Database
    ↓
TRX-1001
amount = 500000
status = SUCCESS

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

ERD چه نقشی دارد؟

یکی از مستندات رایج برای نمایش ساختار و ارتباط داده‌ها، ERD (Entity Relationship Diagram) است.

CUSTOMER
   │
   │ 1:N
   ▼
ACCOUNT
   │
   │ 1:N
   ▼
TRANSACTION

این نمودار به QA کمک می‌کند بفهمد چه Entityهایی وجود دارند و چه رابطه‌ای میان آن‌ها برقرار است.

برای مثال اگر هر Account بتواند چند Transaction داشته باشد، QA می‌تواند مواردی مانند این را بررسی کند:

Transaction به Account درست متصل شده است؟
آیا Transaction بدون Account معتبر ایجاد شده؟
آیا حذف یا غیرفعال شدن Account روی Transactionهای قبلی تأثیر می‌گذارد؟

Database Documentation فقط برای Database Testing نیست

یک نکته مهم برای QA:

دانستن ساختار Database فقط زمانی مفید نیست که بخواهیم مستقیماً SQL Query بنویسیم.

حتی در تست API یا Integration نیز دانستن اینکه داده‌ها کجا و چگونه ذخیره می‌شوند، می‌تواند به درک رفتار سیستم کمک کند.

API Response
{
  "transactionId": "TRX-1001",
  "status": "SUCCESS"
}

QA ممکن است بخواهد بررسی کند که TRX-1001 واقعاً در Database ثبت شده و وضعیت آن با Response مطابقت دارد.

Project Insight: یک Test Case خوب معمولاً حاصل خواندن یک مستند واحد نیست؛ بلکه می‌تواند نتیجه کنار هم گذاشتن اطلاعات چند مستند مختلف باشد.

مقاله‌های مرتبط آینده: Database Testing چیست؟ → ERD چیست؟ → Database Schema چیست؟ → SQL برای QA → Data Dictionary چیست؟

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

۵.۸ Test Documentation؛ تبدیل مستندات به Test Scenario و Test Case

تا اینجا برای قابلیت انتقال وجه BlueBank تقریباً تمام اطلاعات موردنیاز را از زوایای مختلف بررسی کرده‌ایم:

Requirement مشخص می‌کند چه چیزی باید وجود داشته باشد.
Acceptance Criteria مشخص می‌کند چه شرایطی باید برقرار باشد.
HLD ساختار کلی سیستم را نشان می‌دهد.
LLD منطق داخلی را روشن‌تر می‌کند.
API Documentation قرارداد ارتباطی را مشخص می‌کند.
Sequence Diagram ترتیب تعاملات را نشان می‌دهد.
Database Documentation ساختار و محل ذخیره داده‌ها را مشخص می‌کند.

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

از مستندات تا Test Condition

فرض کنیم از مستندات BlueBank این اطلاعات را داریم:

مبلغ انتقال باید بیشتر از صفر باشد.

حساب مبدأ باید موجودی کافی داشته باشد.

حساب مقصد باید فعال باشد.

در صورت موفقیت پرداخت، وضعیت Transaction باید SUCCESS شود.

از این اطلاعات می‌توان Test Conditionهای مختلفی استخراج کرد:

منبع	Test Condition
Requirement	انتقال با مبلغ معتبر
Requirement	انتقال با مبلغ نامعتبر
Acceptance Criteria	موجودی کافی
Acceptance Criteria	موجودی ناکافی
LLD	مبلغ صفر
LLD	مبلغ منفی
API Documentation	نبودن فیلد `amount`
API Documentation	نوع داده نامعتبر
Database Documentation	ثبت صحیح Transaction
Sequence Diagram	Timeout در External Bank

بنابراین Test Condition الزاماً از یک مستند خاص نمی‌آید.

تبدیل Test Condition به Test Scenario

حالا مثلاً این Test Condition را داریم:

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

یک Test Scenario می‌تواند چنین باشد:

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

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

نمونه Test Case در BlueBank

فیلد	مقدار
ID	TC-TR-001
Requirement / User Story	انتقال وجه
Scenario	انتقال با موجودی کافی
Title	انتقال موفق ۵۰۰ هزار تومان
Preconditions	حساب مبدأ و مقصد فعال هستند
Steps	ورود به حساب → انتخاب انتقال وجه → وارد کردن حساب مقصد → وارد کردن مبلغ → تأیید
Expected Results	انتقال با موفقیت انجام شود و Transaction با وضعیت `SUCCESS` ثبت شود
Test Data	مبلغ: 500,000 تومان
Priority	High
Status	Not Run
Automation Status	Not Automated
Scenario Type	Positive
Test Design Technique	Equivalence Partitioning
Layer	API / Integration / UI

اما تست موفق کافی نیست

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

برای همان قابلیت، QA باید حالت‌های مختلف را نیز بررسی کند:

سناریوهای مربوط به مبلغ

مبلغ معتبر
مبلغ صفر
مبلغ منفی
مبلغ کمتر از حداقل مجاز
مبلغ بیشتر از حداکثر مجاز
مبلغ برابر با حداقل
مبلغ برابر با حداکثر

سناریوهای مربوط به موجودی

موجودی بیشتر از مبلغ انتقال
موجودی دقیقاً برابر مبلغ انتقال
موجودی کمتر از مبلغ انتقال

سناریوهای مربوط به حساب

حساب مبدأ فعال
حساب مبدأ غیرفعال
حساب مقصد فعال
حساب مقصد غیرفعال
حساب مقصد نامعتبر
حساب مبدأ و مقصد یکسان

سناریوهای مربوط به API

Authentication نامعتبر
فیلد اجباری حذف شده
Data Type نامعتبر
Request تکراری
Response نامعتبر

سناریوهای مربوط به Integration

Account Service در دسترس نیست
Payment Service خطا می‌دهد
External Bank Timeout می‌شود
Payment موفق است ولی پاسخ با تأخیر می‌رسد

سناریوهای مربوط به Database

Transaction ثبت نمی‌شود
Transaction دوبار ثبت می‌شود
Amount اشتباه ذخیره می‌شود
Status اشتباه ذخیره می‌شود

Test Documentation در اینجا به چه معناست؟

در این مثال، Test Documentation فقط Test Case نیست.

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

Test Strategy
      ↓
Test Plan
      ↓
Test Conditions / Scenarios
      ↓
Test Cases
      ↓
Test Data
      ↓
Test Execution
      ↓
Test Results / Test Report

همه این موارد لزوماً در هر پروژه به‌صورت سند جداگانه وجود ندارند.

مثلاً در یک تیم Agile کوچک ممکن است بخش زیادی از اطلاعات Test Case و Execution در یک Test Management Tool ثبت شود و Test Plan رسمی جداگانه‌ای وجود نداشته باشد.

بنابراین همان اصل قبلی را باید اینجا هم در نظر گرفت:

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

ارتباط تمام مستندات با Test Case

حالا می‌توانیم کل مثال BlueBank را یک‌جا ببینیم:

Requirement
     ↓
User Story
     ↓
Acceptance Criteria
     ↓
HLD
     ↓
LLD
     ↓
API Documentation
     ↓
Sequence Diagram
     ↓
Database Documentation
     ↓
Test Conditions
     ↓
Test Scenarios
     ↓
Test Cases
     ↓
Test Execution
     ↓
Test Report

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

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

و در اینجا مفهوم Traceability نیز اهمیت پیدا می‌کند؛ یعنی بتوانیم ارتباط بین نیازمندی و تست‌های مربوط به آن را دنبال کنیم.

مقالات مرتبط آینده: Test Scenario چیست؟ → Test Case چیست؟ → Test Plan چیست؟ → Test Strategy چیست؟ → RTM چیست؟ → Test Report چیست؟ → Test Design Techniques چیست؟

در بخش بعدی، آخرین قسمت مثال BlueBank را بررسی می‌کنیم: Failure Scenarios؛ یعنی وقتی یکی از اجزای سیستم درست کار نمی‌کند، QA چگونه با استفاده از مستندات مختلف سناریوهای خطا را پیدا می‌کند.

۵.۹ Failure Scenarios؛ وقتی سیستم طبق انتظار کار نمی‌کند

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

در یک سیستم واقعی، کافی نیست بدانیم:

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

باید بدانیم:

اگر هر بخش از سیستم شکست بخورد، چه رفتاری باید اتفاق بیفتد؟

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

یک مثال: Timeout بانک خارجی

فرض کنیم در HLD می‌دانیم:

Transfer Service
       ↓
Payment Service
       ↓
External Bank

و در Sequence Diagram مشخص شده که Payment Service منتظر پاسخ بانک خارجی می‌ماند.

حالا External Bank پاسخ نمی‌دهد:

Payment Service
       │
       │ Request
       ▼
External Bank
       │
       X
    Timeout

QA باید بررسی کند:

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

پاسخ این سؤال‌ها الزاماً در یک مستند واحد قرار ندارد.

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

Failure	مستندات مفید
مبلغ نامعتبر	Requirement / Acceptance Criteria / LLD
موجودی ناکافی	Requirement / Acceptance Criteria
API Request نامعتبر	API Documentation
Authentication نامعتبر	API Documentation / Security Requirements
Account Service در دسترس نیست	HLD / Sequence Diagram
Payment Service خطا می‌دهد	HLD / LLD / API Documentation
External Bank Timeout	HLD / Sequence Diagram / LLD
Request دوبار ارسال می‌شود	LLD / API Documentation
Transaction دوبار ایجاد می‌شود	LLD / Database Documentation
Status اشتباه ذخیره می‌شود	LLD / Database Documentation

این دقیقاً نشان می‌دهد چرا QA در پروژه‌های پیچیده نمی‌تواند فقط به صفحه UI یا حتی فقط به Requirement وابسته باشد.

یک Failure Scenario کامل

فرض کنیم کاربر ۵۰۰ هزار تومان انتقال می‌دهد، اما External Bank Timeout می‌شود.

Scenario: بررسی رفتار سیستم در صورت Timeout بانک مقصد

Expected Behavior:

سیستم نباید انتقال را به‌صورت موفق گزارش کند مگر اینکه موفقیت آن طبق Business Rule تأیید شده باشد.
وضعیت Transaction باید مطابق Business Rule تعریف‌شده باشد.
در صورت وجود Retry، نباید باعث ایجاد تراکنش تکراری شود.
کاربر باید پیام متناسب با وضعیت دریافت کند.
اطلاعات Transaction باید مطابق وضعیت واقعی در Database ثبت شود.

توجه کنیم که این Expected Behavior باید از مستندات و قوانین واقعی پروژه به دست بیاید. QA نباید صرفاً بر اساس حدس خودش تصمیم بگیرد که مثلاً Status باید PENDING باشد.

از یک قابلیت ساده تا مجموعه‌ای از تست‌ها

حالا می‌توانیم ببینیم یک Requirement نسبتاً ساده چگونه به مجموعه‌ای از تست‌ها تبدیل می‌شود:

                    Requirement
                         ↓
                Acceptance Criteria
                         ↓
              ┌──────────┼──────────┐
              ↓          ↓          ↓
             HLD        LLD         API
              ↓          ↓          ↓
          Dependencies  Logic    Contract
              │          │          │
              └──────────┼──────────┘
                         ↓
                 Sequence / DB
                         ↓
                 Failure Scenarios
                         ↓
                  Test Scenarios
                         ↓
                    Test Cases

نکته کلیدی فصل ۵

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

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

به بیان ساده:

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

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

مقالات مرتبط آینده: Failure Testing → Negative Testing → Error Handling → API Testing → Integration Testing → Database Testing → Test Case

جمع‌بندی فصل ۵: در مثال BlueBank دیدیم که QA برای درک و تست یک قابلیت واقعی، معمولاً به یک سند واحد تکیه نمی‌کند. نیازمندی‌ها رفتار مورد انتظار را مشخص می‌کنند، HLD ساختار و وابستگی‌های سیستم را روشن می‌کند، LLD منطق داخلی را نشان می‌دهد، API Documentation قرارداد ارتباطی را مشخص می‌کند، Sequence Diagram ترتیب تعاملات را آشکار می‌کند و Database Documentation وضعیت داده‌ها را قابل بررسی می‌کند. QA این اطلاعات را کنار هم قرار می‌دهد تا Test Condition، Test Scenario و Test Case ایجاد کند و در نهایت Failure Scenarioها را نیز بررسی کند.

در فصل بعد، یک سؤال مهم را بررسی می‌کنیم: آیا QA واقعاً باید HLD و LLD را بلد باشد؟ در آنجا سطح دانشی موردنیاز یک Junior QA را از دانش تخصصی Developer یا Software Architect جدا می‌کنیم.

۶. آیا QA باید HLD و LLD را بلد باشد؟

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

آیا یک QA واقعاً باید HLD و LLD را بلد باشد؟

پاسخ کوتاه این است:

QA لازم نیست HLD یا LLD را در سطح Developer یا Software Architect بلد باشد، اما باید بتواند اطلاعات مهم آن‌ها را برای درک سیستم و طراحی تست استفاده کند.

میزان این دانش نیز به نقش QA، نوع محصول و پیچیدگی سیستم بستگی دارد.

۶.۱ Junior QA تا چه حد باید HLD را بشناسد؟

برای یک Junior QA معمولاً مهم نیست که بتواند یک معماری پیچیده را از صفر طراحی کند.

اما بهتر است بتواند مفاهیم پایه‌ای مانند این موارد را بفهمد:

Service چیست؟
API Gateway چه نقشی دارد؟
یک سرویس چگونه با سرویس دیگر ارتباط برقرار می‌کند؟
سیستم خارجی چیست؟
Database در کجای معماری قرار دارد؟
Dependency چیست؟
یک درخواست کاربر چه مسیر کلی‌ای را طی می‌کند؟

مثلاً اگر HLD پروژه چنین ساختاری را نشان دهد:

Client
  ↓
API Gateway
  ↓
Order Service
  ↓
Payment Service
  ↓
External Payment Provider

Junior QA باید بتواند بفهمد که Payment Service و سیستم پرداخت خارجی، وابستگی‌هایی هستند که می‌توانند روی رفتار Order Service تأثیر بگذارند.

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

Payment Service در دسترس نباشد.
Payment Provider با Timeout مواجه شود.
Payment Provider خطای 500 برگرداند.
ارتباط بین دو سرویس قطع شود.
پاسخ سرویس با تأخیر دریافت شود.

لازم نیست QA بداند این سرویس‌ها دقیقاً با چه Framework یا زبان برنامه‌نویسی ساخته شده‌اند.

هدف، فهم معماری برای تست است؛ نه تبدیل شدن QA به Architect.

۶.۲ Junior QA تا چه حد باید LLD را بشناسد؟

LLD معمولاً جزئیات بیشتری درباره نحوه پیاده‌سازی داخلی یک Component یا Service ارائه می‌دهد.

برای QA، دانستن همه جزئیات LLD ضروری نیست؛ اما آشنایی با بخش‌هایی که روی رفتار قابل تست سیستم تأثیر می‌گذارند بسیار مفید است.

مثلاً اگر LLD برای Transfer Service چنین جریان داخلی‌ای را نشان دهد:

Validate Request
       ↓
Check Balance
       ↓
Create Transaction
       ↓
Process Payment
       ↓
Update Status

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

اگر Validation شکست بخورد، آیا Transaction ایجاد می‌شود؟
اگر Balance Check شکست بخورد، چه اتفاقی می‌افتد؟
اگر Payment موفق شود ولی Update Status شکست بخورد، وضعیت سیستم چه خواهد بود؟
اگر درخواست دوبار ارسال شود، چه اتفاقی می‌افتد؟

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

بنابراین برای QA، ارزش LLD بیشتر در این است که بتواند بخش‌های قابل‌تست زیر را بهتر درک کند:

Business Logic
Validation
State
Error Handling

۶.۳ HLD و LLD را حفظ نکنید؛ ارتباط آن‌ها را بفهمید

یکی از اشتباهات رایج در یادگیری QA این است که فرد تلاش می‌کند تعداد زیادی اصطلاح را حفظ کند:

HLD چیست؟ LLD چیست؟ Component Diagram چیست؟ Sequence Diagram چیست؟ Class Diagram چیست؟

اما هدف اصلی QA حفظ کردن تعریف این اصطلاحات نیست.

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

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

HLD
 ↓
Components
 ↓
Dependencies
 ↓
Integration Points
 ↓
Failure Points

LLD
 ↓
Internal Logic
 ↓
Business Rules
 ↓
Validation
 ↓
State Changes
 ↓
Error Handling

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

۶.۴ آیا همه QAها به یک اندازه به HLD و LLD نیاز دارند؟

خیر.

نیاز QA به این دانش تا حد زیادی به نوع نقش، محصول و پیچیدگی سیستم بستگی دارد.

نقش / محیط	اهمیت HLD/LLD
Manual QA مبتنی بر UI	متوسط
API Tester	زیاد
Integration Tester	زیاد
Automation QA	زیاد
Backend QA	زیاد
Performance Tester	زیاد
Security Tester	بسته به حوزه، معمولاً زیاد
QA در سیستم‌های Distributed	بسیار زیاد

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

اما در یک سیستم Microservices، دانستن اینکه سرویس‌ها چگونه با یکدیگر ارتباط دارند، چه Dependencyهایی دارند و Failure در یک سرویس چه اثری روی سرویس دیگر می‌گذارد، اهمیت بسیار بیشتری پیدا می‌کند.

۶.۵ HLD و LLD در کنار سایر مستندات

در یک پروژه واقعی، QA معمولاً HLD و LLD را جدا از سایر مستندات بررسی نمی‌کند.

برای یک قابلیت ممکن است اطلاعات موردنیاز QA از ترکیب چند منبع به دست بیاید:

Requirement
      ↓
Acceptance Criteria
      ↓
HLD
      ↓
LLD
      ↓
API Documentation
      ↓
Sequence Diagram
      ↓
Database Documentation
      ↓
Test Scenarios

هر مستند یک تکه از تصویر را در اختیار QA قرار می‌دهد:

Requirement می‌گوید چه رفتار یا نیازی مورد انتظار است.
HLD نشان می‌دهد چه اجزا و وابستگی‌هایی درگیر هستند.
LLD جزئیات بیشتری از منطق داخلی را روشن می‌کند.
API Documentation قرارداد ارتباط را مشخص می‌کند.
Sequence Diagram ترتیب تعاملات را نشان می‌دهد.
Database Documentation ساختار و روابط داده را مشخص می‌کند.
Test Documentation فعالیت‌ها و خروجی‌های مرتبط با تست را پوشش می‌دهد.

در نهایت QA این اطلاعات را برای طراحی و اجرای تست کنار هم قرار می‌دهد.

Project Insight: مهارت مهم QA این نیست که همه مستندات فنی را مثل یک Developer تولید کند؛ بلکه این است که بتواند از هر مستند، اطلاعاتی را که برای ارزیابی کیفیت سیستم لازم دارد استخراج کند.

یک نکته برای مسیر یادگیری QA

اگر تازه وارد QA شده‌اید، لازم نیست HLD و LLD را به‌صورت عمیق و مستقل مطالعه کنید و بعد سراغ تست بروید.

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

Software Testing Fundamentals
          ↓
Requirements
          ↓
Test Design
          ↓
API / Database Basics
          ↓
HLD / LLD Fundamentals
          ↓
Automation / Advanced Testing

در این مسیر، HLD و LLD بخشی از درک فنی QA هستند، نه هدف نهایی یادگیری QA.

QA Note: اگر بتوانید یک معماری را بخوانید، وابستگی‌های مهم را پیدا کنید و بفهمید یک تغییر در یک Component چه بخش‌هایی را ممکن است تحت تأثیر قرار دهد، برای بسیاری از موقعیت‌های QA همین درک بسیار ارزشمندتر از حفظ کردن جزئیات تئوری معماری است.

۷. مستندات نرم‌افزار در Agile

وقتی صحبت از مستندات نرم‌افزار می‌شود، ممکن است این تصور ایجاد شود که یک پروژه حرفه‌ای حتماً باید تعداد زیادی سند رسمی مانند SRS، HLD، LLD و Test Plan داشته باشد.

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

Agile به معنی «بدون مستندات» نیست. تفاوت اصلی این است که مستندات باید به اندازه‌ای باشند که برای توسعه، تست، نگهداری و همکاری تیم ارزش ایجاد کنند؛ نه اینکه صرفاً برای کامل کردن یک پوشه مستندات تولید شوند.

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

                 Product Backlog
                       │
                       ▼
                    Epic
                       │
                       ▼
                 User Story
                       │
                       ▼
             Acceptance Criteria
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Jira         Confluence    API Docs
                                      │
                                      ▼
                               OpenAPI / Swagger
          │
          ▼
    Test Management
          │
          ▼
     Test Cases

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

۷.۱ آیا Agile مستندات دارد؟

بله.

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

Agile = مستندات کم یا بدون مستندات

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

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

برای مثال، به‌جای اینکه یک SRS بسیار مفصل تهیه شود و بعد از چند Sprint دیگر کسی آن را به‌روز نکند، ممکن است نیازمندی یک قابلیت در قالب:

User Story + Acceptance Criteria + Technical Notes

نگهداری شود.

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

۷.۲ Jira و Confluence چه نقشی دارند؟

در بسیاری از تیم‌های Agile، ابزارهایی مانند Jira و Confluence بخشی از محل نگهداری اطلاعات پروژه هستند.

مثلاً در Jira ممکن است یک User Story چنین اطلاعاتی داشته باشد:

Story:

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

Acceptance Criteria:

حساب مبدأ باید فعال باشد.
موجودی باید کافی باشد.
مبلغ باید بیشتر از صفر باشد.
پس از انتقال موفق، Transaction باید طبق Business Rule با وضعیت صحیح ثبت شود.

در Confluence نیز ممکن است اطلاعات فنی قابلیت قرار گرفته باشد:

Transfer Service
        ↓
Payment Service
        ↓
External Bank

در کنار آن، API Documentation نیز ممکن است با استفاده از OpenAPI و ابزارهایی مانند Swagger UI در دسترس باشد.

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

Project Insight: در Agile، «مستندات نرم‌افزار» الزاماً به معنی یک مجموعه فایل رسمی نیست. ممکن است اطلاعات واقعی پروژه در Jira، Confluence، API Documentation، Git، Test Management Tool و سایر منابع توزیع شده باشند.

۷.۳ User Story و Acceptance Criteria چه ارتباطی با تست دارند؟

برای QA، یکی از مهم‌ترین جریان‌ها در Agile این است:

User Story
     ↓
Acceptance Criteria
     ↓
Test Conditions
     ↓
Test Scenarios
     ↓
Test Cases

مثلاً:

User Story:

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

Acceptance Criteria:

اگر موجودی حساب کمتر از مبلغ انتقال باشد، انتقال نباید انجام شود.

QA می‌تواند از این معیار، Test Conditionهایی مانند موارد زیر استخراج کند:

موجودی کمتر از مبلغ انتقال
موجودی برابر مبلغ انتقال
موجودی بیشتر از مبلغ انتقال

و سپس آن‌ها را به Test Scenario و Test Case تبدیل کند.

این ارتباط یکی از دلایلی است که Acceptance Criteria برای QA اهمیت زیادی دارد.

۷.۴ مستندات Agile باید به‌روز باشند

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

فرض کنیم Requirement اولیه BlueBank می‌گفت:

حداکثر مبلغ انتقال ۵ میلیون تومان است.

اما چند Sprint بعد این محدودیت به ۱۰ میلیون تومان تغییر کرده و اطلاعات مرتبط در Requirement فعلی و سیستم به‌روزرسانی شده‌اند، در حالی که یک سند قدیمی هنوز مقدار ۵ میلیون را نشان می‌دهد.

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

Current Requirement
Max = 10M
      │
      ├──── API Documentation → Max = 10M
      │
      ├──── Test Case → Max = 10M
      │
      └──── Old Document → Max = 5M  ← Conflict

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

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

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

مستندات Agile در نهایت باید به یک سؤال پاسخ دهند

مهم نیست اطلاعات پروژه در یک SRS رسمی باشد یا در Jira، Confluence، OpenAPI و Git پراکنده شده باشد.

برای QA سؤال اصلی این است:

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

اگر پاسخ مثبت باشد، نبودن یک سند رسمی لزوماً مشکل نیست.

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

QA Note: در یک پروژه Agile، یاد گرفتن محل پیدا کردن اطلاعات به اندازه یاد گرفتن خود اطلاعات اهمیت دارد. QA باید بداند Requirement کجاست، Acceptance Criteria کجاست، مستندات API کجاست، اطلاعات فنی را از کجا باید پیدا کند و در صورت تناقض بین منابع، از چه مرجعی باید وضعیت صحیح را مشخص کند.

۸. اشتباهات رایج در مستندات نرم‌افزار

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

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

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

۸.۱ مستندسازی بیش از حد

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

مثلاً تیمی ممکن است برای یک قابلیت ساده چندین سند ایجاد کند:

Requirement
PRD
SRS
Functional Specification
Technical Specification
Design Document
Test Plan
...

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

اصل مهم: مستندات باید به اندازه‌ای باشند که به درک، توسعه، تست و نگهداری سیستم کمک کنند؛ نه صرفاً برای اینکه «مستندات داشته باشیم».

۸.۲ مستندات قدیمی

مستندات قدیمی یکی از خطرناک‌ترین مشکلات Documentation هستند.

فرض کنیم محدودیت انتقال وجه در ابتدا این بوده:

حداکثر مبلغ انتقال: ۵ میلیون تومان

اما بعداً این مقدار به ۱۰ میلیون تومان تغییر کرده و اطلاعات مرتبط با Version جدید به‌روزرسانی شده‌اند، در حالی که یک Test Case قدیمی هنوز بر اساس سقف ۵ میلیون نوشته شده است.

در این شرایط، مستندات ممکن است QA را به سمت تست اشتباه هدایت کنند.

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

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

۸.۳ تناقض بین مستندات

گاهی مشکل فقط قدیمی بودن یک سند نیست؛ بلکه چند منبع اطلاعات متفاوتی ارائه می‌کنند.

Requirement   → Maximum = 10M
API Docs      → Maximum = 10M
Test Case     → Maximum = 5M
Database Doc  → Maximum = 10M

در این شرایط QA نباید صرفاً یکی از مقادیر را انتخاب کند و تست را ادامه دهد.

باید مشخص شود:

کدام منبع برای این اطلاعات، مرجع معتبر فعلی است؟

در صورت نیاز، تناقض باید با Product Owner، Business Analyst، Developer یا فرد مسئول Requirement برطرف شود.

نکته مهم این است که Source of Truth می‌تواند به نوع اطلاعات و ساختار پروژه وابسته باشد. بنابراین QA نباید صرفاً به نام یک سند تکیه کند؛ بلکه باید وضعیت فعلی Requirement و تصمیم مورد تأیید تیم را مشخص کند.

۸.۴ مستندات جدا از واقعیت سیستم

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

مثلاً مستندات API می‌گویند:

Invalid amount → 400 Bad Request

اما API در واقع 200 OK برمی‌گرداند.

در این شرایط QA باید این اختلاف را شناسایی و گزارش کند.

اما یک سؤال مهم وجود دارد:

آیا Documentation اشتباه است یا Implementation؟

پاسخ را نباید QA حدس بزند. باید Requirement، Acceptance Criteria یا تصمیم مورد تأیید تیم مشخص کند رفتار مورد انتظار واقعی چیست.

این موضوع یکی از دلایلی است که QA باید مستندات را صرفاً به‌عنوان «چیزی که باید حفظ شود» نبیند، بلکه آن‌ها را با رفتار واقعی سیستم مقایسه کند.

۸.۵ مستندسازی بدون ارتباط با فرآیند توسعه و تست

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

Requirement
     ↓
Documentation
     ↓
      ❌
Development
     ↓
Testing

در چنین حالتی Documentation به یک آرشیو تبدیل می‌شود.

ساختار مفیدتر این است:

Requirement
     ↓
Development
     ↕
Documentation
     ↕
Testing
     ↓
Feedback / Change
     ↓
Updated Documentation

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

۸.۶ نادیده گرفتن مستندات فنی توسط QA

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

مثلاً فقط می‌بیند:

کاربر روی دکمه Transfer کلیک کرد و پیام Success گرفت.

اما نمی‌داند پشت این عملیات در معماری موردنظر پروژه چه اتفاقی می‌افتد:

API Gateway
     ↓
Transfer Service
     ↓
Payment Service
     ↓
External Bank
     ↓
Transaction DB

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

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

۸.۷ مستندات به‌عنوان هدف، نه ابزار

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

گاهی تیم به‌جای اینکه بپرسد:

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

می‌پرسد:

«چه سندهایی باید داشته باشیم؟»

این دو سؤال یکسان نیستند.

ممکن است یک پروژه به سند رسمی SRS نیاز نداشته باشد، اما به User Story، Acceptance Criteria و Technical Documentation نیاز داشته باشد.

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

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

Project Insight: مستندات خوب الزاماً مستندات زیاد نیستند؛ مستندات خوب اطلاعات درست را، در زمان درست، در اختیار فرد درست قرار می‌دهند.

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

مستندات زیاد
      ≠
مستندات خوب

مستندات کم
      ≠
مستندات بد

آنچه اهمیت دارد این است که اطلاعات مستندات تا حد امکان:

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

به بیان ساده، می‌توان کیفیت Documentation را با پنج مفهوم مهم بررسی کرد:

Accuracy + Completeness + Consistency + Maintainability + Accessibility

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

۹. چک‌لیست مستندات نرم‌افزار برای QA

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

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

۹.۱ چک‌لیست نیازمندی‌ها

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

Requirement مشخص و قابل فهم است؟
User Story در صورت استفاده وجود دارد؟
Acceptance Criteria مشخص هستند؟
قوانین کسب‌وکار (Business Rules) مشخص‌اند؟
محدودیت‌ها و Validation Rules مشخص‌اند؟
رفتار سیستم در حالت‌های غیرعادی مشخص است؟
مواردی مثل حداقل، حداکثر، مقدار صفر و مقادیر نامعتبر مشخص شده‌اند؟
Requirement مربوط به Version یا Release فعلی است؟

مثلاً برای انتقال وجه BlueBank:

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

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

۹.۲ چک‌لیست طراحی و معماری

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

سرویس یا ماژول اصلی مشخص است؟
Dependencyهای مهم مشخص هستند؟
سرویس‌های خارجی مشخص‌اند؟
مسیر کلی Request مشخص است؟
نقاط Integration مشخص‌اند؟
Failure Pointهای مهم قابل شناسایی هستند؟
در صورت وجود HLD، نسخه یا وضعیت آن با سیستم فعلی مطابقت دارد؟

برای مثال:

Client
  ↓
API Gateway
  ↓
Transfer Service
  ↓
Payment Service
  ↓
External Bank

از همین تصویر می‌توان سؤال‌هایی درباره Timeout، Service Failure، Retry و Dependency Failure مطرح کرد.

۹.۳ چک‌لیست LLD و منطق داخلی

برای قابلیت‌هایی که Business Logic پیچیده‌تری دارند، بررسی بخش‌های مرتبط LLD می‌تواند به QA کمک کند.

Validationهای اصلی مشخص‌اند؟
Business Ruleهای مهم مشخص‌اند؟
Stateهای مختلف مشخص‌اند؟
Error Handling مشخص است؟
رفتار سیستم بعد از Failure مشخص است؟
Retry یا Rollback در صورت نیاز مشخص شده است؟
رفتار Duplicate Request مشخص است؟

مثلاً اگر Payment موفق شود ولی ثبت Transaction در Database با خطا مواجه شود، QA باید بداند طبق Business Rule و طراحی سیستم، وضعیت مورد انتظار چیست.

لازم نیست QA تمام جزئیات پیاده‌سازی را بداند؛ باید منطق قابل‌تست سیستم را بفهمد.

۹.۴ چک‌لیست API Documentation

اگر قابلیت API دارد، QA باید بتواند قرارداد API را بررسی کند:

HTTP Method مشخص است؟
Endpoint مشخص است؟
Authentication و Authorization مشخص است؟
Request Parameters مشخص‌اند؟
Required و Optional بودن فیلدها مشخص است؟
Data Typeها مشخص‌اند؟
Response Structure مشخص است؟
HTTP Status Codeهای مورد انتظار مشخص‌اند؟
Error Code و Error Messageهای مهم مشخص‌اند؟
Validation Rules مشخص‌اند؟

مثلاً:

POST /api/transfers

Request
{
  sourceAccount,
  destinationAccount,
  amount
}

Success
→ HTTP Status Code
→ transactionId
→ status = SUCCESS

مقدار دقیق Status Code و سایر جزئیات باید مطابق قرارداد واقعی API باشد. این اطلاعات می‌توانند مستقیماً وارد طراحی API Test شوند.

۹.۵ چک‌لیست Database

اگر بررسی وضعیت Backend یا Data Validation برای قابلیت مهم است، QA باید اطلاعات مرتبط با داده را نیز بررسی کند.

Tableهای مرتبط مشخص‌اند؟
Fieldهای مهم مشخص‌اند؟
Relationshipها مشخص‌اند؟
وضعیت Transaction در Database مشخص است؟
داده جدید کجا ایجاد می‌شود؟
داده موجود چه زمانی Update می‌شود؟
رفتار Duplicate مشخص است؟

در BlueBank مثلاً QA می‌تواند بعد از یک انتقال موفق، اطلاعات مرتبط با Transaction را بررسی کند:

Transaction
├── transaction_id
├── source_account
├── destination_account
├── amount
├── status
└── created_at

بنابراین تست فقط به پیام UI محدود نمی‌شود و می‌توان بررسی کرد آیا State واقعی سیستم و داده‌های مرتبط نیز مطابق رفتار مورد انتظار هستند یا نه.

۹.۶ چک‌لیست Test Documentation

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

Test Strategy در صورت نیاز مشخص است؟
Test Plan در صورت نیاز وجود دارد؟
Test Scenarioها مشخص‌اند؟
Test Caseها نوشته شده‌اند؟
Test Data مشخص است؟
Traceability موردنیاز وجود دارد؟
Execution Result ثبت می‌شود؟
Defectها در صورت نیاز به Test Case یا Requirement مرتبط هستند؟
Regression Testهای لازم مشخص شده‌اند؟

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

۹.۷ چک‌لیست نهایی QA

می‌توان تمام این موارد را در یک نگاه خلاصه کرد:

حوزه	سؤال اصلی QA
Requirement	سیستم چه کاری باید انجام دهد؟
User Story	کاربر چه چیزی می‌خواهد و چرا؟
Acceptance Criteria	چه شرایطی برای پذیرش قابلیت وجود دارد؟
HLD	چه اجزایی درگیر هستند؟
LLD	منطق داخلی و رفتارهای قابل‌تست چگونه تعریف شده‌اند؟
API Documentation	اجزا از طریق چه قراردادی با یکدیگر ارتباط دارند؟
Sequence Diagram	تعامل اجزا با چه ترتیبی انجام می‌شود؟
Database Documentation	چه داده‌ای ایجاد یا تغییر می‌کند؟
Test Documentation	چگونه این قابلیت را ارزیابی و نتایج را ثبت کنیم؟

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

Requirement
     ↓
Understand
     ↓
Identify Risks
     ↓
Define Test Conditions
     ↓
Test Scenarios
     ↓
Test Cases
     ↓
Execute
     ↓
Verify Results
     ↓
Report Defects

QA Note

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

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

برای تست این قابلیت، چه اطلاعاتی را ندارم و باید از کجا به دست بیاورم؟

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

۱۰. جمع‌بندی

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

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

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

برای QA، اهمیت این مستندات در کنار هم است. Requirement رفتار مورد انتظار را روشن می‌کند؛ مستندات طراحی و معماری ساختار و وابستگی‌های سیستم را نشان می‌دهند؛ API و Database Documentation جزئیات فنی مهم را مشخص می‌کنند و مستندات تست، نحوه ارزیابی و ثبت نتایج را سازمان‌دهی می‌کنند.

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

در پروژه‌های Agile نیز مستندات حذف نمی‌شوند؛ بلکه ممکن است اطلاعات به‌جای یک مجموعه اسناد رسمی و یکپارچه، در ابزارها و منابع مختلفی مانند Jira، Confluence، OpenAPI و Test Management Tool توزیع شده باشند.

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

Project Insight: مستندات نرم‌افزار برای QA مانند نقشه‌ای از سیستم هستند؛ اما QA قرار نیست فقط نقشه را بخواند. باید بتواند از روی آن نقاط حساس، وابستگی‌ها، حالت‌های خطا و شرایط قابل‌تست را پیدا کند.

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

مستندات به QA کمک می‌کنند سیستم را بفهمد؛ QA از این فهم برای پیدا کردن ریسک‌ها، طراحی تست‌های مناسب و بررسی رفتار واقعی سیستم استفاده می‌کند.

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

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

منابع

ISO/IEC/IEEE 15289:2019 — Systems and software engineering — Content of life-cycle information items (documentation) — استانداردی درباره هدف، محتوا و انواع Information Itemهای مستندات در چرخه عمر سیستم و نرم‌افزار.
ISO/IEC/IEEE 29119-3:2021 — Software testing — Part 3: Test documentation — استاندارد مرتبط با مستندات تست نرم‌افزار و قالب‌های مستندات آزمون.
ISO/IEC TR 9294:2005 — Guidelines for the management of software documentation — راهنمای مدیریت مستندات نرم‌افزار در مراحل مختلف چرخه عمر.

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

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

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

مستندات نرم‌افزار مجموعه‌ای از اطلاعاتی است که برای توضیح نیازمندی‌ها، طراحی، معماری، پیاده‌سازی، تست، استقرار، نگهداری یا استفاده از یک نرم‌افزار ایجاد می‌شود. این اطلاعات می‌تواند در قالب اسناد رسمی یا در ابزارهایی مانند Jira، Confluence، Git و Swagger/OpenAPI نگهداری شود.

مهم‌ترین انواع مستندات نرم‌افزار کدام‌اند؟

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

آیا هر پروژه نرم‌افزاری باید تمام این مستندات را داشته باشد؟

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

HLD و LLD چه تفاوتی دارند؟

HLD یا High-Level Design ساختار کلی سیستم، اجزای اصلی و ارتباط آن‌ها را نشان می‌دهد؛ در حالی که LLD یا Low-Level Design جزئیات داخلی اجزا، منطق، تعاملات و نحوه پیاده‌سازی آن‌ها را مشخص می‌کند.

آیا QA باید HLD و LLD را بلد باشد؟

QA لازم نیست HLD و LLD را در سطح یک Developer طراحی کند، اما آشنایی با آن‌ها به درک معماری، وابستگی‌ها، منطق داخلی و نقاط شکست سیستم کمک می‌کند و می‌تواند باعث شود تست‌های دقیق‌تر و مبتنی بر ریسک طراحی شود.

QA چگونه از مستندات نرم‌افزار استفاده می‌کند؟

QA از مستندات نیازمندی برای فهم رفتار مورد انتظار، از HLD و LLD برای درک ساختار و منطق سیستم، از API Documentation برای تست API، از مستندات پایگاه داده برای بررسی داده‌ها و از مستندات تست برای برنامه‌ریزی و اجرای فعالیت‌های تست استفاده می‌کند.

آیا مستندات نرم‌افزار فقط فایل‌های Word و PDF هستند؟

خیر. مستندات می‌توانند در قالب صفحات Confluence، آیتم‌های Jira، فایل‌های Markdown، مستندات OpenAPI/Swagger، نمودارهای معماری، ERD، README، Test Management Tools و سایر repositoryهای اطلاعاتی نگهداری شوند.

آیا مستندات در پروژه‌های Agile حذف می‌شوند؟

خیر. Agile به معنی حذف مستندات نیست؛ بلکه معمولاً بر مستندات مفید و به‌اندازه نیاز تأکید می‌کند. اطلاعات موردنیاز ممکن است به‌جای یک سند سنگین، در User Story، Acceptance Criteria، Jira، Confluence، API Documentation و سایر ابزارها توزیع شده باشد.

مستندات نرم‌افزار چه ارتباطی با Test Case دارند؟

Test Case معمولاً نتیجه مستقیم یا غیرمستقیم تحلیل اطلاعات موجود در مستندات مختلف است. QA می‌تواند از Requirement و Acceptance Criteria رفتار مورد انتظار را مشخص کند و با کمک مستندات طراحی، API، پایگاه داده و معماری، شرایط و سناریوهای بیشتری برای تست شناسایی کند.

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

این اختلاف باید بررسی و شفاف شود. QA نباید صرفاً بر اساس یکی از منابع فرض کند کدام مورد درست است. بسته به فرآیند تیم، می‌توان اختلاف را با Product Owner، Developer یا سایر افراد مسئول بررسی کرد و پس از مشخص شدن رفتار مورد انتظار، مستندات و تست‌ها را به‌روزرسانی کرد.

طبقه بندی شده در:

دسته‌بندی نشده,

اخرین بروزرسانی: شهریور 21, 1405

ESC را فشار دهید تا بسته شود

۱. مستندات نرم‌افزار چیست؟

مستندات نرم‌افزار چه چیزهایی را پوشش می‌دهند؟

۱.۱. چرا مستندات نرم‌افزار اهمیت دارند؟

۲. چرا مستندات نرم‌افزار مهم هستند؟

۲.۱. ایجاد درک مشترک از سیستم

۲.۲. کاهش وابستگی به افراد

۲.۳. کمک به توسعه و تغییر سیستم

۲.۴. کمک به تیم QA

۳. آیا هر پروژه نرم‌افزاری به همه این مستندات نیاز دارد؟

۳.۱. چه عواملی تعیین می‌کنند چه مستنداتی لازم است؟

۳.۲. مستندات زیاد همیشه بهتر نیستند

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

۴. انواع مستندات نرم‌افزار

۴.۱. مستندات نیازمندی‌ها

۴.۲. مستندات طراحی و معماری

۴.۳. مستندات API و یکپارچه‌سازی

۴.۴. مستندات پایگاه داده

۴.۵. مستندات تست نرم‌افزار

مهم‌ترین مستندات تست

یک مثال در BlueBank

۴.۶. مستندات استقرار و عملیات

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

۴.۷. مستندات کاربری

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

۵. مثال جامع: مستندات قابلیت انتقال وجه در BlueBank

۵.۱ Requirement؛ قابلیت انتقال وجه در BlueBank

Requirement فقط یک سند خاص نیست

QA چگونه از Requirement استفاده می‌کند؟

۵.۲ User Story و Acceptance Criteria در قابلیت انتقال وجه

User Story

Acceptance Criteria

تبدیل Acceptance Criteria به Test Condition

تفاوت Requirement، User Story و Acceptance Criteria

۵.۳ HLD؛ سیستم چگونه قابلیت انتقال وجه را پیاده می‌کند؟

هر بخش چه نقشی دارد؟

HLD چه چیزی به QA می‌گوید؟

HLD مستقیماً Test Case تولید نمی‌کند

HLD چه چیزهایی را معمولاً نشان می‌دهد؟

۵.۴ LLD؛ داخل Transfer Service چه اتفاقی می‌افتد؟

جریان داخلی انتقال وجه

LLD چه چیزی به QA اضافه می‌کند؟

۵.۵ API Documentation؛ قرارداد ارتباطی بین اجزای سیستم

یک نمونه API در BlueBank

QA از API Documentation چه استفاده‌ای می‌کند؟

API Documentation و Swagger / OpenAPI

یک نکته مهم: API Contract

۵.۶ Sequence Diagram؛ ترتیب تعامل اجزای سیستم

Sequence Diagram چیست؟

Sequence Diagram چه چیزی به QA نشان می‌دهد؟

Sequence Diagram برای پیدا کردن Failure Scenarioها مفید است

تفاوت HLD و Sequence Diagram

۵.۷ Database Documentation؛ داده‌های انتقال وجه کجا و چگونه ذخیره می‌شوند؟

یک ساختار ساده در BlueBank

QA از Database Documentation چه استفاده‌ای می‌کند؟

ERD چه نقشی دارد؟

Database Documentation فقط برای Database Testing نیست

۵.۸ Test Documentation؛ تبدیل مستندات به Test Scenario و Test Case

از مستندات تا Test Condition

تبدیل Test Condition به Test Scenario

نمونه Test Case در BlueBank

اما تست موفق کافی نیست

سناریوهای مربوط به مبلغ

سناریوهای مربوط به موجودی

سناریوهای مربوط به حساب

سناریوهای مربوط به API

سناریوهای مربوط به Integration

سناریوهای مربوط به Database

Test Documentation در اینجا به چه معناست؟

ارتباط تمام مستندات با Test Case

۵.۹ Failure Scenarios؛ وقتی سیستم طبق انتظار کار نمی‌کند

یک مثال: Timeout بانک خارجی

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

یک Failure Scenario کامل

از یک قابلیت ساده تا مجموعه‌ای از تست‌ها

نکته کلیدی فصل ۵

۶. آیا QA باید HLD و LLD را بلد باشد؟

۶.۱ Junior QA تا چه حد باید HLD را بشناسد؟

۶.۲ Junior QA تا چه حد باید LLD را بشناسد؟

۶.۳ HLD و LLD را حفظ نکنید؛ ارتباط آن‌ها را بفهمید