Verification و Validation چیست؟ تفاوت تأیید و اعتبارسنجی در تست نرم‌افزار

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

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

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

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

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

لزوماً نه.

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

اینجاست که دو مفهوم مهم وارد می‌شوند:

🔍 Verification (تأیید / صحت‌سنجی)
🧪 Validation (اعتبارسنجی)

این دو مفهوم از مفاهیم مهم در مهندسی نرم‌افزار، تضمین کیفیت و تست نرم‌افزار هستند. درک تفاوت آن‌ها به تستر کمک می‌کند بفهمد چه چیزی را باید بررسی کند، در چه مرحله‌ای آن را بررسی کند و چرا صرفاً اجرای Test Case برای ارزیابی کیفیت نرم‌افزار کافی نیست.

Verification و Validation چیست؟

اگر بخواهیم این دو مفهوم را خیلی ساده بیان کنیم:

Verification: آیا محصول را درست می‌سازیم؟

Validation: آیا محصول درست را می‌سازیم؟

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

Verification چیست؟

Verification را می‌توان به تأیید یا صحت‌سنجی ترجمه کرد.

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

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

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

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

• آیا Requirement به‌درستی نوشته شده است؟
• آیا Requirement ابهام دارد؟
• آیا طراحی با Requirement مطابقت دارد؟
• آیا Test Caseها Requirement را پوشش می‌دهند؟
• آیا کد مطابق طراحی و مشخصات فنی نوشته شده است؟

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

Validation چیست؟

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

در Validation سؤال اصلی این است:

آیا محصول واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند؟

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

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

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

در اینجا دیگر فقط نمی‌پرسیم «آیا نرم‌افزار مطابق مشخصات ساخته شده است؟» بلکه می‌پرسیم:

«آیا چیزی که ساخته‌ایم واقعاً نیاز کاربر و کسب‌وکار را برطرف می‌کند؟»

یک مثال ساده برای تفاوت Verification و Validation

فرض کنید قرار است برای یک رستوران، یک اپلیکیشن سفارش آنلاین غذا بسازیم.

در Requirement نوشته شده است:

«کاربر باید بتواند غذای موردنظر خود را انتخاب کرده و سفارش دهد.»

در Verification 🔍

بررسی می‌کنیم:

• آیا Requirement واضح است؟
• آیا طراحی سیستم با Requirement مطابقت دارد؟
• آیا Developer قابلیت سفارش غذا را مطابق طراحی پیاده کرده است؟
• آیا Test Caseها تمام بخش‌های Requirement را پوشش می‌دهند؟

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

در Validation 🧪

حالا اپلیکیشن را در اختیار کاربر قرار می‌دهیم.

کاربر می‌گوید:

«من می‌توانم غذا سفارش بدهم، اما نمی‌توانم زمان تحویل را انتخاب کنم؛ در حالی که این قابلیت برای کسب‌وکار ما ضروری است.»

اینجا ممکن است سیستم طبق Requirement موجود کاملاً درست کار کند، اما یک مشکل مهم وجود داشته باشد:

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

این همان جایی است که تفاوت Verification و Validation خودش را نشان می‌دهد.

چرا تستر باید Verification و Validation را یاد بگیرد؟

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

Requirement → Test Case → Execute → Pass/Fail

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

تستر باید بتواند قبل از اجرای تست نیز درباره کیفیت Requirement، Acceptance Criteria و Test Scenarioها سؤال بپرسد.

مثلاً اگر در Requirement نوشته شده باشد:

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

یک تستر باتجربه احتمالاً بلافاصله می‌پرسد:

«سریع یعنی چند ثانیه؟»

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

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

بنابراین یادگیری Verification و Validation به تستر کمک می‌کند از یک Test Executor صرف، به فردی تبدیل شود که نگاه عمیق‌تری به کیفیت محصول و نیاز کسب‌وکار دارد. 🎯

خلاصه تفاوت Verification و Validation

مورد	Verification	Validation
معادل فارسی	تأیید / صحت‌سنجی	اعتبارسنجی
سؤال اصلی	آیا محصول را درست می‌سازیم؟	آیا محصول درست را می‌سازیم؟
تمرکز	مشخصات، نیازمندی‌ها و Work Productها	محصول و نیاز واقعی کاربر و کسب‌وکار
اجرای نرم‌افزار	همیشه لازم نیست	معمولاً اهمیت زیادی دارد
نمونه فعالیت	Review، Inspection، بررسی Requirement	Functional Testing، System Testing، UAT
هدف	بررسی تطابق خروجی با مشخصات و معیارهای تعریف‌شده	اطمینان از برآورده شدن نیاز واقعی کاربر و کسب‌وکار

Verification چیست؟ 🔍

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

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

به زبان ساده:

Verification می‌پرسد: آیا محصول را مطابق چیزی که قرار بود بسازیم، ساخته‌ایم؟

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

Verification چه چیزی را بررسی می‌کند؟

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

• بررسی Requirementها
• بررسی Acceptance Criteria
• بررسی طراحی نرم‌افزار
• بررسی معماری سیستم
• بررسی کد
• بررسی Test Caseها
• بررسی مستندات
• بررسی Traceability بین نیازمندی‌ها و تست‌ها

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

یک مثال واقعی از Verification

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

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

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

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

تستر یا تحلیلگر Requirement را بررسی می‌کند و چند سؤال مطرح می‌کند:

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

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

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

این دقیقاً یکی از ارزش‌های مهم Verification است: شناسایی مشکلات پیش از آنکه به مراحل بعدی توسعه منتقل شوند. 🔍

Verification و Static Testing چه ارتباطی دارند؟

یکی از مهم‌ترین ارتباطات Verification با Static Testing است.

در Static Testing، بدون اجرای نرم‌افزار، Work Productهای مختلف را بررسی می‌کنیم. برای مثال:

• Requirement Review
• Design Review
• Code Review
• Inspection
• Walkthrough

فرض کنید یک Developer کدی نوشته است و در Code Review مشخص می‌شود که منطق محاسبه تخفیف با Requirement مطابقت ندارد.

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

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

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

آیا Verification فقط وظیفه تستر است؟

خیر. ❌

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

• Business Analyst
• Product Owner
• Software Architect
• Developer
• Software Tester
• QA

برای مثال:

• Business Analyst می‌تواند Requirement را بررسی کند.
• Developer می‌تواند Code Review انجام دهد.
• Tester می‌تواند Requirement و Test Caseها را Review کند.
• Product Owner می‌تواند بررسی کند که Requirement با نیاز کسب‌وکار همخوانی دارد.

بنابراین Verification فقط به این معنی نیست که «تستر نرم‌افزار چیزی را تست کند»؛ بلکه مجموعه‌ای از فعالیت‌های بررسی و ارزیابی در طول فرایند توسعه است.

مهم‌ترین فعالیت‌های Verification

برای اینکه مفهوم Verification بهتر در ذهن بماند، چند فعالیت رایج آن را مرور کنیم.

1. Requirements Review

در Requirements Review بررسی می‌کنیم که Requirementها:

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

2. Design Review

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

3. Code Review

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

4. Test Case Review

تسترها یا اعضای تیم QA بررسی می‌کنند که Test Caseها:

• Requirementها را پوشش دهند.
• Expected Result مناسب و قابل ارزیابی داشته باشند.
• سناریوهای مهم را از قلم نینداخته باشند.
• در صورت نیاز، شرایط منفی و مرزی را نیز پوشش دهند.

5. Document Review

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

یک نکته مهم: Verification به معنی «تأیید نهایی محصول» نیست

گاهی واژه Verification باعث این سوءتفاهم می‌شود که باید در پایان پروژه فقط بررسی کنیم:

«خب، محصول آماده است؛ آیا آن را تأیید کنیم؟»

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

برای مثال:

• Requirement → Verification
• Design → Verification
• Code → Verification
• Test Case → Verification

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

جمع‌بندی Verification

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

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

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

اگر محصول دقیقاً مطابق Requirement ساخته شده باشد، آیا حتماً نیاز واقعی کاربر و کسب‌وکار را برآورده می‌کند؟

اینجاست که باید سراغ مفهوم دوم برویم:

حالا به نیمه دوم ماجرا می‌رسیم: Validation یا اعتبارسنجی.

اگر در Verification می‌پرسیدیم:

«آیا محصول را درست می‌سازیم؟»

در Validation سؤال کمی متفاوت است:

«آیا محصول درست را می‌سازیم؟»

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

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

Validation دقیقاً چه چیزی را بررسی می‌کند؟

در Validation تمرکز اصلی روی محصول واقعی و رفتار آن است.

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

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

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

اینجا دیگر فقط به مستندات نگاه نمی‌کنیم؛ بلکه رفتار واقعی نرم‌افزار و میزان تناسب آن با نیاز مورد انتظار را بررسی می‌کنیم. 🔎

یک مثال ساده از Validation

به داستان فروشگاه اینترنتی برگردیم.

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

«کاربر باید بتواند محصول را خریداری کند.»

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

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

1. ورود به حساب کاربری
2. انتخاب محصول
3. افزودن به سبد خرید
4. وارد کردن اطلاعات ارسال
5. انتخاب روش پرداخت
6. پرداخت
7. ثبت سفارش

همه Test Caseها Pass می‌شوند. ✅

در نگاه اول همه چیز عالی است.

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

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

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

این همان جایی است که Validation اهمیت پیدا می‌کند.

Validation فقط به معنی Functional Testing نیست

این نکته برای تسترها بسیار مهم است.

ممکن است تصور کنیم:

Validation = Functional Testing

اما این برابری دقیق نیست.

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

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

• Functional Testing
• System Testing
• End-to-End Testing
• Acceptance Testing
• User Acceptance Testing (UAT)
• بررسی سناریوهای واقعی کاربر

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

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

Validation و UAT چه ارتباطی دارند؟

در اینجا ارتباط Validation با تست پذیرش کاربر(UAT) بسیار جالب است.

در UAT، کاربران واقعی یا نمایندگان کسب‌وکار بررسی می‌کنند که آیا سیستم برای استفاده موردنظر آن‌ها مناسب است یا خیر.

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

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

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

اما باید دقت کنیم:

Validation مساوی UAT نیست.

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

آیا Validation فقط در پایان پروژه انجام می‌شود؟

خیر. ❌

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

در روش‌های مدرن توسعه نرم‌افزار، Validation می‌تواند به‌صورت مستمر و Iterative انجام شود.

مثلاً در Agile، یک قابلیت در یک Sprint توسعه پیدا می‌کند و همان قابلیت می‌تواند در همان چرخه مورد بررسی، بازخورد و اعتبارسنجی قرار گیرد:

Develop → Test → Validate → Feedback → Improve

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

نقش تستر در Validation چیست؟

تستر در Validation نقش مهمی دارد؛ اما نقش او فقط اجرای Test Case نیست.

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

«اگر من جای کاربر بودم، آیا این سیستم واقعاً کاری را که برای آن ساخته شده انجام می‌داد؟»

برای پاسخ به این سؤال، تستر می‌تواند:

• سناریوهای واقعی کاربر را بررسی کند.
• Happy Path و Alternative Flowها را پوشش دهد.
• رفتار سیستم را در شرایط مختلف بررسی کند.
• Acceptance Criteria را بررسی کند.
• با Business Analyst یا Product Owner درباره رفتار مورد انتظار گفت‌وگو کند.
• نتایج تست را با نیاز واقعی کسب‌وکار مقایسه کند.

اینجاست که تفاوت بین یک تستر صرفاً Test Executor و یک تستر با نگاه Quality-Oriented مشخص می‌شود. 🎯

Validation در چه مراحلی اتفاق می‌افتد؟

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

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

این چرخه ممکن است چندین بار در طول پروژه تکرار شود.

تفاوت مهم Validation با Verification

حالا می‌توانیم تفاوت این دو مفهوم را بهتر ببینیم.

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

«صفحه پرداخت باید امکان پرداخت آنلاین را فراهم کند.»

در Verification می‌پرسیم:

آیا طراحی، کد و Test Caseها مطابق این Requirement هستند؟

در Validation می‌پرسیم:

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

بنابراین:

• Verification بیشتر به «ساخت صحیح مطابق مشخصات» نگاه می‌کند.
• Validation بیشتر به «درست بودن محصول برای نیاز واقعی» نگاه می‌کند.

یک نکته ظریف اما مهم

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

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

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

Verification کمک می‌کند محصول را درست بسازیم؛ Validation کمک می‌کند مطمئن شویم محصولی را ساخته‌ایم که واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند. ✅

تفاوت Verification و Validation چیست؟ 🔍🧪

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

تفاوت Verification و Validation دقیقاً در چیست؟

اگر بخواهیم خیلی خلاصه بگوییم:

Verification بررسی می‌کند که آیا محصول را درست می‌سازیم؛ Validation بررسی می‌کند که آیا محصول درست را می‌سازیم.

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

Verification در برابر Validation

معیار	Verification	Validation
معادل فارسی	تأیید / صحت‌سنجی	اعتبارسنجی
سؤال اصلی	آیا محصول را درست می‌سازیم؟	آیا محصول درست را می‌سازیم؟
تمرکز اصلی	مشخصات، Requirement و Work Product	محصول واقعی و نیاز کاربر و کسب‌وکار
اجرای نرم‌افزار	همیشه ضروری نیست	معمولاً نقش مهمی دارد
نمونه فعالیت	Review، Inspection، Walkthrough	Functional Testing، System Testing، UAT
زمان انجام	در مراحل مختلف توسعه	در مراحل مختلف توسعه و هنگام ارزیابی محصول
هدف	بررسی انطباق با Specification و معیارهای تعریف‌شده	بررسی مناسب بودن محصول برای نیاز واقعی

یک مثال که تفاوت را کاملاً روشن می‌کند

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

در Requirement نوشته شده است:

«کارمند باید بتواند ورود و خروج خود را در سیستم ثبت کند.»

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

مرحله اول: Verification 🔍

تستر و سایر اعضای تیم Requirement و Work Productهای مرتبط را بررسی می‌کنند.

مثلاً می‌پرسند:

• آیا قابلیت ورود و خروج مطابق Requirement ساخته شده است؟
• آیا طراحی با Requirement مطابقت دارد؟
• آیا رابط کاربری، امکان موردنیاز را در اختیار کاربر قرار می‌دهد؟
• آیا Test Caseها Requirement را پوشش می‌دهند؟
• آیا کد مطابق Design و Specification پیاده‌سازی شده است؟

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

Verification در این بخش شواهد مناسبی از انطباق با مشخصات ارائه می‌کند.

اما هنوز کار تمام نشده است.

مرحله دوم: Validation 🧪

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

او می‌گوید:

«من می‌توانم ورود و خروج را ثبت کنم، اما سیستم برای شیفت‌های شبانه مناسب نیست؛ چون ساعت خروج من مربوط به روز بعد است.»

اینجا یک مشکل مهم آشکار شده است.

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

این موضوع اهمیت Validation را نشان می‌دهد.

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

Verification 🔍

آیا چیزی که ساخته‌ایم مطابق Specification است؟

Validation 🧪

آیا چیزی که ساخته‌ایم واقعاً برای کاربر و کسب‌وکار مناسب است؟

آیا Verification بدون اجرای نرم‌افزار انجام می‌شود؟

بله.

این یکی از ویژگی‌های مهم Verification است. برای مثال می‌توانیم یک Requirement را قبل از شروع Development بررسی کنیم.

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

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

تستر یا Business Analyst می‌تواند بپرسد:

«سریع یعنی چه؟»

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

«صفحه Dashboard باید در شرایط عادی حداکثر در ۲ ثانیه بارگذاری شود.»

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

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

آیا Validation همیشه نیاز به اجرای نرم‌افزار دارد؟

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

برای مثال:

• اجرای یک سناریوی خرید
• تست فرایند پرداخت
• اجرای یک سناریوی End-to-End
• انجام UAT
• بررسی رفتار سیستم توسط کاربران یا نمایندگان کسب‌وکار

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

با این حال، نباید Validation را به یک Test Type خاص محدود کنیم.

آیا Verification همان Static Testing است؟

خیر.

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

Static Testing رویکردی برای ارزیابی Work Productها بدون اجرای نرم‌افزار است و می‌تواند شامل فعالیت‌هایی مانند موارد زیر باشد:

• Review
• Inspection
• Walkthrough

این فعالیت‌ها می‌توانند برای Verification مورد استفاده قرار گیرند، اما Verification مفهوم گسترده‌تری است و به Static Testing محدود نمی‌شود.

آیا Validation همان UAT است؟

باز هم خیر.

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

برای مثال:

• Functional Testing
• System Testing
• End-to-End Testing
• Acceptance Testing
• User Acceptance Testing (UAT)
• بررسی سناریوهای واقعی کاربر

بنابراین بهتر است این رابطه را این‌طور در ذهن داشته باشیم:

UAT ⊂ Validation

یعنی UAT می‌تواند بخشی از فعالیت‌های Validation باشد، اما Validation محدود به UAT نیست.

آیا تستر فقط در Validation نقش دارد؟

خیر. 👨‍💻

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

نقش تستر در Verification

• Requirementها را Review کند.
• Acceptance Criteria را بررسی کند.
• Testability Requirementها را ارزیابی کند.
• Test Caseها را Review کند.
• Traceability را بررسی کند.
• در جلسات Review شرکت کند.

نقش تستر در Validation

• Functional Test اجرا کند.
• System Test انجام دهد.
• End-to-End Scenarioها را بررسی کند.
• رفتار واقعی سیستم را ارزیابی کند.
• سناریوهای کاربر را تست کند.
• از Acceptance Criteria برای ارزیابی محصول استفاده کند.
• در UAT از کاربران و تیم کسب‌وکار پشتیبانی کند.

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

یک تشبیه ساده برای به خاطر سپردن تفاوت

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

در Verification می‌پرسیم:

آیا ساختمان طبق نقشه و مشخصات فنی ساخته شده است؟

در Validation می‌پرسیم:

آیا این ساختمان واقعاً برای کاری که قرار است در آن انجام شود مناسب است؟

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

در این حالت:

Verification می‌تواند موفق باشد، اما Validation مشکل داشته باشد.

همین مفهوم در نرم‌افزار نیز وجود دارد.

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

تصور کنید فقط Verification انجام دهیم.

ممکن است محصولی بسازیم که:

• دقیقاً مطابق Requirement باشد.
• طراحی مناسبی داشته باشد.
• کد آن مطابق Specification باشد.
• Test Caseهای تعریف‌شده را Pass کند.

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

از طرف دیگر، اگر فقط Validation انجام دهیم، ممکن است محصول در عمل نیاز کاربر را برآورده کند، اما در فرایند توسعه، مشکلات جدی در Requirement، Design، Code یا مستندات وجود داشته باشد.

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

🔍 Verification: آیا درست ساخته‌ایم؟

🧪 Validation: آیا چیز درستی ساخته‌ایم؟

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

اگر بخواهیم این دو مفهوم را خیلی سریع به خاطر بسپاریم:

Verification → Specification

Validation → User / Business Need

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

در بخش بعدی، این دو مفهوم را وارد چرخه توسعه نرم‌افزار (SDLC) می‌کنیم تا ببینیم Verification و Validation فقط مربوط به مرحله Testing نیستند و در طول چرخه توسعه چه جایگاهی دارند.

Verification و Validation در چرخه توسعه نرم‌افزار (SDLC) 🔄

تا اینجا تفاوت Verification و Validation را در سطح مفهومی بررسی کردیم. اما یک سؤال مهم باقی می‌ماند:

این دو فرایند دقیقاً در چه زمانی از چرخه توسعه نرم‌افزار انجام می‌شوند؟

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

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

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

Verification و Validation در مراحل مختلف SDLC

یک چرخه ساده را در نظر بگیریم:

Requirements → Design → Development → Testing → Release

در هر مرحله، نگاه ما کمی متفاوت است.

1. مرحله Requirements

یکی از اولین نقاط مهم برای Verification همین‌جاست.

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

«کاربر باید بتواند با کیف پول دیجیتال پرداخت کند.»

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

• آیا Requirement واضح است؟
• آیا قابل تست است؟
• آیا شرایط موفقیت و شکست مشخص شده است؟
• آیا Acceptance Criteria تعریف شده است؟
• آیا محدودیت‌های کسب‌وکار مشخص هستند؟
• آیا Requirement با سایر Requirementها تناقض ندارد؟

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

این یک نمونه مهم از Verification است. 🔍

2. مرحله Design

بعد از مشخص شدن Requirement، تیم طراحی سیستم را انجام می‌دهد. در این مرحله نیز Verification ادامه دارد.

برای مثال بررسی می‌شود:

• آیا Design نیازمندی را پوشش می‌دهد؟
• آیا معماری انتخاب‌شده با نیاز سیستم سازگار است؟
• آیا Flow پرداخت درست طراحی شده است؟
• آیا Error Handling در نظر گرفته شده است؟
• آیا ارتباط سیستم با سرویس کیف پول مشخص است؟

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

«در صورت ناموفق بودن پرداخت، سفارش نباید به وضعیت Paid تغییر کند.»

در Design باید مشخص شود که این وضعیت چگونه مدیریت خواهد شد.

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

3. مرحله Development

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

Code Review

Developer کد را پیاده‌سازی کرده و عضو دیگری از تیم آن را بررسی می‌کند.

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

• منطق کد با Design مطابقت ندارد.
• یک شرط مهم در نظر گرفته نشده است.
• استانداردهای Coding رعایت نشده‌اند.
• رفتار پیاده‌سازی‌شده با Requirement متفاوت است.

این‌ها نمونه‌هایی از فعالیت‌های Verification هستند.

بنابراین Verification لزوماً کاری نیست که فقط قبل از Development انجام شود؛ بلکه می‌تواند در طول فرایند توسعه نیز ادامه پیدا کند.

4. مرحله Testing

در این مرحله Validation پررنگ‌تر می‌شود. 🧪

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

برای قابلیت پرداخت با کیف پول، مثلاً:

1. کاربر محصول را انتخاب می‌کند.
2. وارد Checkout می‌شود.
3. کیف پول را انتخاب می‌کند.
4. پرداخت را انجام می‌دهد.
5. نتیجه تراکنش بررسی می‌شود.
6. وضعیت سفارش بررسی می‌شود.
7. موجودی کیف پول بررسی می‌شود.

اینجا سؤال اصلی این است:

آیا سیستم در عمل همان رفتاری را دارد که کاربر و کسب‌وکار انتظار دارند؟

این نگاه به Validation نزدیک است.

5. مرحله Acceptance و UAT

در مرحله Acceptance، نقش Validation می‌تواند حتی پررنگ‌تر شود.

فرض کنید تیم QA تمام Test Caseهای خود را اجرا کرده و مشکلی پیدا نکرده است.

حالا Product Owner یا نماینده کسب‌وکار سناریوی واقعی خود را اجرا می‌کند.

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

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

اگر این نیاز در Requirement اولیه وجود نداشته باشد، ممکن است از نظر Verification همه چیز درست به نظر برسد، اما Validation نشان دهد که محصول هنوز کاملاً با نیاز کسب‌وکار هماهنگ نیست.

6. مرحله Release

حتی نزدیک Release نیز Validation اهمیت خود را از دست نمی‌دهد.

تیم باید مطمئن شود محصولی که قرار است در اختیار کاربران قرار گیرد:

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

البته Release به معنای پایان همیشگی Validation نیست.

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

Verification و Validation در SDLC چه تفاوتی دارند؟

اگر بخواهیم مسیر را خلاصه کنیم:

مرحله SDLC	Verification	Validation
Requirements	Review و بررسی کیفیت Requirement	بررسی ارتباط Requirement با نیاز واقعی
Design	Design Review	بررسی اینکه Design قابلیت برآورده کردن نیاز را دارد
Development	Code Review و بررسی Implementation	ارزیابی رفتار قابلیت پیاده‌سازی‌شده
Testing	Review Test Case و Test Documentation	اجرای تست و ارزیابی رفتار سیستم
Acceptance	بررسی مستندات و معیارها	بررسی محصول توسط Business/User
Release	بررسی آمادگی و تطابق با معیارها	اطمینان از مناسب بودن محصول برای استفاده

البته این جدول را نباید یک قانون کاملاً سخت در نظر گرفت؛ در پروژه‌های مختلف، فعالیت‌ها و مرزهای Verification و Validation می‌توانند متفاوت باشند.

نکته مهم برای تسترها: V&V یک فعالیت یک‌باره نیست

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

Verification و Validation یک مرحله مشخص و جداگانه در انتهای پروژه نیستند.

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

مثلاً:

Requirement Review
🔍 Verification

↓

Design Review
🔍 Verification

↓

Code Review
🔍 Verification

↓

Functional / System Testing
🧪 Validation

↓

UAT
🧪 Validation

↓

Release & User Feedback
🧪 Validation

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

یک نکته درباره Agile

در Agile این مفاهیم حذف نمی‌شوند؛ بلکه معمولاً تکرارشونده و مستمر اجرا می‌شوند.

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

در همان Sprint می‌توان فعالیت‌هایی مانند موارد زیر را انجام داد:

• Requirement Review → Verification
• Design / Code Review → Verification
• Functional Testing → Validation
• Acceptance / UAT → Validation

بنابراین در Agile به جای اینکه Verification و Validation را به دو نقطه دور از هم در انتهای پروژه محدود کنیم، این فعالیت‌ها می‌توانند در هر Iteration تکرار شوند.

در نتیجه:

تفاوت مفهومی Verification و Validation در Agile تغییر نمی‌کند؛ اما نحوه و زمان اجرای فعالیت‌های مرتبط با آن‌ها معمولاً Iterative و Continuous می‌شود.

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

تا اینجا فهمیدیم Verification و Validation در SDLC چگونه حضور دارند. اما هنوز درباره روش‌ها و تکنیک‌هایی که برای انجام Verification استفاده می‌شوند صحبت نکرده‌ایم.

مثلاً:

• Review چیست؟
• Inspection چه تفاوتی با Review دارد؟
• Walkthrough چیست؟
• Code Review چه نقشی دارد؟
• Static Testing چه ارتباطی با Verification دارد؟

در بخش بعدی سراغ همین موضوع می‌رویم و روش‌ها و تکنیک‌های Verification را بررسی می‌کنیم. 🔍

روش‌ها و تکنیک‌های Verification در تست نرم‌افزار 🔍

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

اما یک سؤال عملی‌تر وجود دارد:

چطور Verification را انجام می‌دهیم؟

Verification فقط یک مفهوم تئوری نیست. تیم نرم‌افزار می‌تواند با استفاده از روش‌هایی مثل Review، Inspection، Walkthrough و Code Review، مشکلات را قبل از رسیدن نرم‌افزار به مرحله اجرای تست شناسایی کند.

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

1. Review چیست؟

Review یکی از رایج‌ترین روش‌های بررسی Work Productهاست.

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

این خروجی می‌تواند شامل موارد زیر باشد:

• Requirement
• User Story
• Acceptance Criteria
• Design Document
• Test Case
• Source Code
• مستندات فنی

مثلاً در فروشگاه اینترنتی خودمان، تیم QA Requirement مربوط به پرداخت را Review می‌کند.

اگر Requirement نوشته باشد:

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

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

«سریع یعنی چند ثانیه؟»

همین سؤال ساده ممکن است باعث شود Requirement دقیق‌تر شود و در مراحل بعدی، تست‌پذیرتر باشد.

2. Inspection چیست؟

Inspection یکی از ساختاریافته‌ترین انواع Review است.

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

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

• خطا
• ابهام
• عدم تطابق
• نقص
• عدم رعایت استاندارد

برای مثال، یک تیم می‌تواند یک Requirement Specification را با استفاده از یک Checklist مشخص بررسی کند و موارد مشکل‌دار را ثبت کند.

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

Inspection بیشتر روی شناسایی Defect در Work Product تمرکز دارد و معمولاً از Reviewهای ساختاریافته‌تر و رسمی‌تر محسوب می‌شود.

3. Walkthrough چیست؟

در Walkthrough معمولاً صاحب Work Product آن را برای سایر اعضای تیم توضیح می‌دهد و افراد حاضر درباره آن سؤال یا بازخورد ارائه می‌کنند.

برای مثال، Business Analyst می‌تواند User Story مربوط به پرداخت را برای تیم توضیح دهد.

تستر در طول جلسه ممکن است بپرسد:

«اگر تراکنش موفق باشد اما Callback در دسترس نباشد، چه اتفاقی می‌افتد؟»

یا:

«اگر کاربر دکمه پرداخت را دوبار کلیک کند، چه می‌شود؟»

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

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

4. Code Review

یکی دیگر از فعالیت‌های مهم Verification، Code Review است.

در Code Review، کد نوشته‌شده توسط Developer توسط یک یا چند عضو دیگر تیم بررسی می‌شود.

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

• تطابق کد با Requirement
• تطابق با Design
• خطاهای منطقی
• رعایت Coding Standards
• خوانایی کد
• مشکلات احتمالی امنیتی
• مشکلات Maintainability

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

«اگر پرداخت ناموفق باشد، وضعیت سفارش نباید به Paid تغییر کند.»

در Code Review ممکن است مشخص شود که در یکی از مسیرهای خطا، وضعیت سفارش اشتباهاً Paid می‌شود.

این مشکل قبل از اجرای Test Case پیدا شده است.

این مثال نشان می‌دهد چرا Verification می‌تواند به شناسایی زودهنگام Defect و کاهش هزینه اصلاح آن کمک کند. 🎯

5. بررسی Test Caseها

شاید کمتر درباره آن صحبت شود، اما خود Test Case نیز می‌تواند مورد Verification قرار بگیرد.

فرض کنید برای قابلیت پرداخت، تستری Test Case زیر را نوشته است:

«کاربر وارد صفحه پرداخت می‌شود و پرداخت را انجام می‌دهد.»

قبل از اجرای Test Case می‌توان پرسید:

• آیا Preconditions مشخص هستند؟
• آیا Test Data مشخص است؟
• آیا Expected Result دقیق است؟
• آیا Requirement مربوطه پوشش داده شده است؟
• آیا سناریوی شکست پرداخت بررسی شده است؟
• آیا Alternative Flowها در نظر گرفته شده‌اند؟

در اینجا در واقع داریم Test Documentation را Verify می‌کنیم.

6. Requirements Review

برای تسترها، Requirements Review اهمیت بسیار زیادی دارد.

یک Requirement خوب باید تا حد امکان:

• واضح باشد.
• قابل فهم باشد.
• ابهام نداشته باشد.
• قابل تست باشد.
• قابل اندازه‌گیری باشد.
• با سایر Requirementها تناقض نداشته باشد.

مثلاً این Requirement:

«صفحه پرداخت باید سریع باشد.»

برای تستر مناسب نیست؛ چون «سریع» یک معیار دقیق نیست.

اما اگر نوشته شود:

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

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

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

Verification و Static Testing چه رابطه‌ای دارند؟

این دو مفهوم را نباید با یکدیگر یکی بدانیم.

Verification یک مفهوم گسترده‌تر است که هدف آن بررسی تطابق Work Product با مشخصات و معیارهای تعریف‌شده است.

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

برای مثال:

Requirement Review
↓
Static Testing
↓
Verification

یا:

Code Review
↓
Static Testing
↓
Verification

بنابراین:

Static Testing می‌تواند یکی از ابزارهای مهم برای Verification باشد، اما Verification و Static Testing دقیقاً یک مفهوم نیستند.

چرا Verification باید زود انجام شود؟

برگردیم به همان فروشگاه اینترنتی.

فرض کنید Requirement از ابتدا این باشد:

«سیستم باید امکان پرداخت آنلاین را فراهم کند.»

اما مشخص نشده که:

• پرداخت ناموفق چه وضعیتی دارد.
• تراکنش Timeout شده چگونه مدیریت می‌شود.
• اگر پول کسر شد ولی سفارش ثبت نشد چه اتفاقی می‌افتد.
• کاربر چگونه دوباره پرداخت می‌کند.

اگر این ابهامات در زمان Requirement Review پیدا شوند، اصلاح آن‌ها معمولاً ساده‌تر است.

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

به همین دلیل یکی از اهداف مهم Verification این است که:

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

آیا همه Reviewها Verification هستند؟

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

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

• انتقال دانش
• دریافت Feedback
• پیدا کردن Defect
• بررسی انطباق با استاندارد
• ارزیابی قابلیت نگهداری
• بررسی آمادگی یک Work Product

بنابراین وقتی درباره Verification صحبت می‌کنیم، باید ببینیم هدف Review چیست و چه چیزی را قرار است Verify کنیم.

خلاصه روش‌های مهم Verification

روش	کاربرد اصلی
Review	بررسی Work Product و شناسایی مشکلات
Inspection	Review رسمی و ساختاریافته
Walkthrough	ارائه Work Product و دریافت Feedback
Code Review	بررسی کد از نظر کیفیت و تطابق
Requirements Review	بررسی کیفیت و تست‌پذیری Requirement
Test Case Review	بررسی پوشش و کیفیت Test Caseها

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

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

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

وقتی یک تستر Requirement را می‌خواند و می‌گوید:

«این Requirement قابل تست نیست.»

یا:

«این سناریو مشخص نشده است.»

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

این همان تغییری است که یک تستر را از صرفاً اجرای تست‌ها به سمت نگاه مهندسی به کیفیت می‌برد. 🚀

در بخش بعدی، سراغ طرف دیگر ماجرا می‌رویم و بررسی می‌کنیم Validation با چه روش‌ها و فعالیت‌هایی انجام می‌شود و چه ارتباطی با Functional Testing، System Testing، Acceptance Testing و UAT دارد.

روش‌ها و تکنیک‌های Validation در تست نرم‌افزار 🧪

در بخش قبل دیدیم که Verification بیشتر با بررسی Requirement، Design، Code و سایر Work Productها سروکار دارد.

حالا نوبت Validation است.

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

به زبان ساده:

Verification می‌پرسد: آیا درست ساخته‌ایم؟
Validation می‌پرسد: آیا چیزی که ساخته‌ایم واقعاً همان چیزی است که به آن نیاز داریم؟

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

1. Functional Testing

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

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

برای مثال در فروشگاه اینترنتی:

• افزودن محصول به سبد خرید
• حذف محصول
• اعمال کد تخفیف
• محاسبه هزینه ارسال
• پرداخت
• ثبت سفارش

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

اما نکته مهم این است که Functional Testing صرفاً به این سؤال محدود نمی‌شود که:

«آیا قابلیت مطابق مشخصات کار می‌کند؟»

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

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

2. System Testing

در System Testing سیستم را به‌صورت یکپارچه و در سطح سیستم ارزیابی می‌کنیم.

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

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

Login → Search → Product → Cart → Checkout → Payment → Order Confirmation

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

مثلاً:

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

System Testing می‌تواند چنین مشکلاتی را آشکار کند و شواهد مهمی برای Validation فراهم کند.

3. End-to-End Testing

در End-to-End Testing یک فرایند واقعی و کامل کاربر را از نقطه شروع تا پایان بررسی می‌کنیم.

مثلاً:

«کاربر وارد حساب می‌شود → محصول انتخاب می‌کند → سفارش ثبت می‌کند → پرداخت انجام می‌دهد → سفارش را در پنل خود مشاهده می‌کند.»

این نوع تست برای Validation ارزش زیادی دارد، چون به Business Flow واقعی نزدیک است.

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

4. Acceptance Testing

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

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

برای مثال:

Acceptance Criteria: «پس از پرداخت موفق، سفارش باید با وضعیت Paid ثبت شود و کاربر باید شماره سفارش دریافت کند.»

حالا سیستم را بررسی می‌کنیم.

اگر پرداخت موفق شود اما شماره سفارش نمایش داده نشود، Acceptance Criteria به‌طور کامل برآورده نشده است.

5. User Acceptance Testing یا UAT

یکی از شناخته‌شده‌ترین فعالیت‌های مرتبط با Validation، User Acceptance Testing (UAT) است.

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

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

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

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

ممکن است QA تمام Test Caseهای خود را Pass کرده باشد، اما UAT نشان دهد که یک نیاز واقعی کاربر هنوز به‌درستی پوشش داده نشده است.

بنابراین:

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

یک سناریوی کامل از Validation

بیایید دوباره به فروشگاه اینترنتی برگردیم.

فرض کنیم Business Requirement این است:

«کاربر باید بتواند خرید خود را به‌صورت آنلاین انجام دهد.»

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

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

انتخاب محصول → سبد خرید → پرداخت → ثبت سفارش

همه چیز موفق است. ✅

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

پرداخت موفق → قطع ارتباط با سرویس پرداخت → بازگشت کاربر به سایت

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

اینجا تستر فقط یک Bug پیدا نکرده است؛ بلکه به تیم کمک کرده تا بفهمد:

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

این نگاه، بخش مهمی از Validation است.

Validation فقط Happy Path نیست

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

مثلاً:

User → Checkout → Payment → Success

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

بنابراین برای Validation باید سناریوهای مختلف را نیز در نظر گرفت:

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

چرا؟

چون هدف Validation فقط این نیست که ببینیم:

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

بلکه باید ببینیم:

«آیا محصول در شرایط واقعی استفاده، رفتار قابل قبول و مورد انتظار دارد؟»

نقش کاربران واقعی در Validation

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

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

«فرایند خرید کاملاً درست کار می‌کند.»

اما کاربر می‌گوید:

«من نمی‌دانم در این صفحه باید چه کاری انجام دهم.»

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

به همین دلیل Validation می‌تواند دیدگاه‌هایی را آشکار کند که صرفاً با بررسی Specification یا اجرای Test Case مشخص نمی‌شوند.

آیا Performance Testing و Security Testing هم می‌توانند بخشی از Validation باشند؟

بسته به هدف و زمینه پروژه، بله.

Validation یک Test Type مشخص نیست.

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

«سیستم باید در زمان اوج استفاده پاسخ قابل قبول داشته باشد.»

آن‌وقت Performance Testing می‌تواند شواهدی برای Validation فراهم کند.

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

«اطلاعات حساس کاربران نباید در اختیار افراد غیرمجاز قرار گیرد.»

فعالیت‌های Security Testing می‌توانند برای ارزیابی این نیاز مورد استفاده قرار گیرند.

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

Validation در برابر Test Typeها

می‌توانیم رابطه را این‌طور ببینیم:

• Validation
  • Functional Testing
  • System Testing
  • End-to-End Testing
  • Acceptance Testing
  • UAT
  • Performance Testing^*
  • Security Testing^*

^* در صورتی که برای ارزیابی نیاز یا هدف مربوطه استفاده شوند.

بنابراین Validation یک Test Type نیست؛ بلکه یک مفهوم و هدف ارزیابی است که فعالیت‌های مختلف تست می‌توانند به آن کمک کنند.

یک نکته مهم برای تسترها 🎯

وقتی Test Case می‌نویسید، فقط به این فکر نکنید:

«طبق Requirement چه چیزی باید تست شود؟»

یک قدم جلوتر بروید و بپرسید:

«کاربر در دنیای واقعی چگونه از این قابلیت استفاده می‌کند؟»

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

البته این به معنی نادیده گرفتن Requirement نیست؛ بلکه یعنی تستر علاوه بر Specification، نگاه کاربر و Business Flow را نیز در نظر بگیرد.

جمع‌بندی

Validation معمولاً از طریق ارزیابی محصول واقعی و رفتار آن در سناریوهای مختلف انجام می‌شود و فعالیت‌هایی مانند Functional Testing، System Testing، End-to-End Testing، Acceptance Testing و UAT می‌توانند در آن نقش داشته باشند.

اما باید این نکته را همیشه به خاطر داشته باشیم:

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

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

Verification و Validation در STLC چه جایگاهی دارند؟

در این بخش دقیق‌تر بررسی می‌کنیم که یک تستر نرم‌افزار در STLC دقیقاً در کدام نقاط می‌تواند در Verification و Validation نقش داشته باشد.

Verification و Validation در STLC چه جایگاهی دارند؟ 🔍🧪

تا اینجا دیدیم که Verification و Validation فقط به مرحله اجرای تست محدود نمی‌شوند و می‌توانند در بخش‌های مختلف SDLC حضور داشته باشند.

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

Verification و Validation در STLC دقیقاً کجا قرار می‌گیرند؟

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

Verification و Validation خودشان دو مرحله مستقل از STLC نیستند.

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

Verification و Validation در STLC چه جایگاهی دارند؟ 🔍🧪

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

اگر با STLC (Software Testing Life Cycle) آشنا باشید، ممکن است این سؤال مطرح شود:

Verification و Validation دقیقاً در کدام مرحله از STLC قرار می‌گیرند؟

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

Verification و Validation دو مرحله مستقل از STLC نیستند.

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

اگر با مراحل STLC آشنا نیستید، پیشنهاد می‌کنیم ابتدا مقاله جامع چرخه حیات تست نرم‌افزار (STLC) را مطالعه کنید و سپس به این بخش برگردید. در ادامه، فقط جایگاه Verification و Validation را در مهم‌ترین فعالیت‌های STLC بررسی می‌کنیم.

Verification و Validation در مراحل مختلف STLC

برای یک تستر، مهم‌ترین نکته این است که بداند V&V فقط هنگام اجرای Test Case اتفاق نمی‌افتد. از زمانی که Requirement در اختیار تیم تست قرار می‌گیرد تا زمانی که نتایج تست بررسی و چرخه تست بسته می‌شود، فعالیت‌هایی وجود دارند که می‌توانند با Verification یا Validation ارتباط داشته باشند.

1. Requirement Analysis 🔍

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

فرض کنید Requirement پروژه فروشگاه اینترنتی این باشد:

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

تستر نباید صرفاً Requirement را دریافت کند و منتظر آماده شدن Build بماند. می‌تواند همان ابتدا درباره ابهام‌ها و Testability آن سؤال کند:

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

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

2. Test Planning 🔍

در مرحله Test Planning نیز می‌توان از نگاه Verification استفاده کرد.

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

• چه بخش‌هایی باید تست شوند؟
• Scope تست چیست و چه مواردی خارج از Scope هستند؟
• چه Test Levelهایی موردنیاز هستند؟
• چه Test Typeهایی باید انجام شوند؟
• Entry Criteria و Exit Criteria چیست؟
• چه منابع، ابزارها و محیطی موردنیاز است؟

سپس می‌توان Test Plan و در صورت وجود، Test Strategy را Review کرد تا مشخص شود برنامه تست با Requirementها، Scope و اهداف پروژه هماهنگ است.

در اینجا Verification بیشتر متوجه درستی و کفایت Test Work Productها است، نه اجرای خود نرم‌افزار.

3. Test Case Design 🔍

در مرحله طراحی Test Case نیز Verification نقش مهمی دارد.

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

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

تستر برای این Requirement Test Case طراحی می‌کند. اما قبل از اجرای آن می‌توان بررسی کرد:

• آیا Test Case Requirement را پوشش می‌دهد؟
• آیا Preconditions مشخص هستند؟
• آیا Test Data مناسب است؟
• آیا Expected Result دقیق و قابل بررسی است؟
• آیا Negative Scenarioها در نظر گرفته شده‌اند؟
• آیا Alternative Flowهای مهم پوشش داده شده‌اند؟
• آیا Traceability با Requirement برقرار است؟

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

4. Test Environment Setup

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

برای مثال، تیم باید مطمئن شود موارد موردنیاز برای اجرای تست فراهم هستند:

• Application Version
• Database
• APIها
• Payment Gateway
• Test Accountها
• Test Data
• سرویس‌ها و وابستگی‌های خارجی
• ابزارهای موردنیاز برای تست

فرض کنید قرار است قابلیت پرداخت آنلاین تست شود، اما Payment Gateway در محیط تست در دسترس نیست. در چنین شرایطی اجرای تست نمی‌تواند نتیجه قابل اتکایی ارائه دهد.

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

5. Test Execution 🧪

در Test Execution، Validation پررنگ‌تر می‌شود؛ زیرا در این مرحله نرم‌افزار را اجرا می‌کنیم و رفتار واقعی آن را در برابر رفتار مورد انتظار ارزیابی می‌کنیم.

برای مثال:

Expected Result:

پس از پرداخت موفق، سفارش باید با وضعیت Paid ثبت شود.

Actual Result:

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

در اینجا رفتار واقعی سیستم با نتیجه مورد انتظار مطابقت ندارد و تستر می‌تواند یک Defect ثبت کند.

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

6. Defect Reporting

ثبت و تحلیل Defect نیز می‌تواند از دو زاویه بررسی شود.

«پس از پرداخت موفق، وضعیت سفارش تغییر نمی‌کند.»

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

• 🔍 Verification: آیا رفتار سیستم با Requirement و Specification مطابقت دارد؟
• 🧪 Validation: آیا این رفتار برای کاربر و فرایند واقعی کسب‌وکار قابل قبول است؟

بنابراین یک Defect می‌تواند هم از نظر انطباق با مشخصات و هم از نظر تأثیر آن بر نیاز واقعی کاربر و کسب‌وکار بررسی شود.

7. Retesting و Regression Testing

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

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

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

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

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

8. Test Closure

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

• چه تعداد Test Case اجرا شده است؟
• چند مورد Pass و Fail شده‌اند؟
• چه Defectهایی ثبت شده‌اند؟
• چه Defectهایی هنوز باز هستند؟
• آیا Exit Criteria برآورده شده است؟
• آیا ریسک‌های باقی‌مانده قابل قبول هستند؟
• آیا محصول برای مرحله بعدی آماده است؟

این اطلاعات به تیم کمک می‌کنند درباره کیفیت و آمادگی محصول تصمیم آگاهانه‌تری بگیرد. البته Test Closure به‌تنهایی به معنای موفقیت Validation نیست؛ بلکه یکی از منابع شواهد برای تصمیم‌گیری درباره وضعیت محصول است.

Verification و Validation در STLC؛ یک نگاه سریع

مرحله STLC	نمونه فعالیت مرتبط با Verification	نمونه فعالیت مرتبط با Validation
Requirement Analysis	Review Requirement و بررسی Testability	بررسی ارتباط Requirement با نیاز Business
Test Planning	Review Test Plan و Test Strategy	بررسی پوشش اهداف و ریسک‌های محصول
Test Case Design	Review Test Case و Traceability	طراحی سناریوهای نزدیک به رفتار واقعی کاربر
Environment Setup	بررسی آمادگی و صحت Environment	فراهم کردن شرایط مناسب برای ارزیابی محصول
Test Execution	مقایسه رفتار با Specification و Expected Result	ارزیابی رفتار واقعی سیستم
Defect Management	بررسی مغایرت با Requirement	بررسی تأثیر Defect بر کاربر و Business
Retesting	بررسی اصلاح Defect	ارزیابی رفتار اصلاح‌شده در سناریوی واقعی
Test Closure	بررسی شواهد تست و Exit Criteria	کمک به ارزیابی آمادگی محصول برای مرحله بعد

یک نکته مهم: STLC با Validation یکی نیست

ممکن است به دلیل نقش پررنگ Testing در Validation، این تصور ایجاد شود که:

«چون STLC شامل اجرای تست است، پس STLC همان Validation است.»

این برداشت درست نیست.

STLC چارچوبی برای سازمان‌دهی فعالیت‌های مرتبط با تست نرم‌افزار است؛ از تحلیل Requirement و برنامه‌ریزی تست گرفته تا طراحی، آماده‌سازی محیط، اجرای تست و Test Closure.

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

Testing می‌تواند یکی از مهم‌ترین منابع شواهد برای Validation باشد، اما Validation فقط به STLC محدود نمی‌شود.

نقش تستر در Verification و Validation

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

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

«من Test Caseها را اجرا می‌کنم و نتیجه Pass یا Fail را گزارش می‌دهم.»

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

🔍 از دید Verification

• آیا Requirement واضح و قابل تست است؟
• آیا Acceptance Criteria کامل است؟
• آیا Test Caseها Requirementها را پوشش می‌دهند؟
• آیا Test Coverage مناسب است؟

🧪 از دید Validation

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

این تغییر نگاه، یکی از قدم‌های مهم در مسیر تبدیل شدن از Test Executor به یک Software Tester حرفه‌ای است. 🎯

یک تصویر ذهنی ساده از V&V در STLC

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

Requirement Analysis
↓ 🔍 Verification
Test Planning
↓ 🔍 Verification
Test Case Design
↓ 🔍 Verification
Environment Setup
↓
Test Execution
↓ 🧪 Validation Evidence
Defect → Retest → Regression
↓ 🧪 Validation Evidence
Test Closure

این تصویر صرفاً برای ساده‌تر شدن مفهوم است و نباید به این معنا برداشت شود که Verification فقط در مراحل ابتدایی و Validation فقط در Test Execution انجام می‌شود. در پروژه واقعی، هر دو می‌توانند در مراحل مختلف STLC هم‌پوشانی، تکرار و تعامل داشته باشند.

در ادامه مقاله، بررسی می‌کنیم که Verification و Validation در Agile چه تفاوتی دارند و وقتی تیم با Sprint، User Story، Acceptance Criteria و Increment کار می‌کند، این دو مفهوم چگونه در طول توسعه تکرار می‌شوند.

Verification و Validation در Agile چه تفاوتی دارند؟ 🔄

اگر تا اینجا با مفهوم Verification و Validation آشنا شده باشیم، ممکن است یک سؤال طبیعی ایجاد شود:

آیا در Agile این دو مفهوم شکل متفاوتی پیدا می‌کنند؟

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

خود مفهوم Verification و Validation در Agile تغییر نمی‌کند، اما نحوه و زمان انجام آن‌ها متفاوت است.

در مدل‌هایی مانند Waterfall ممکن است فعالیت‌های توسعه و تست بیشتر به‌صورت مرحله‌ای انجام شوند، اما در Agile تیم در Iterationها و Sprintهای کوتاه کار می‌کند و بنابراین Verification و Validation نیز می‌توانند به‌صورت مداوم و تکرارشونده انجام شوند.

Verification در Agile چگونه انجام می‌شود؟ 🔍

فرض کنیم تیم در یک Sprint قرار است قابلیت پرداخت آنلاین را توسعه دهد.

User Story ممکن است چیزی شبیه این باشد:

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

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

بررسی User Story

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

• آیا User Story واضح است؟
• آیا هدف کاربر مشخص است؟
• آیا Acceptance Criteria وجود دارد؟
• آیا شرایط موفقیت مشخص است؟
• آیا سناریوهای خطا مشخص شده‌اند؟

مثلاً اگر Acceptance Criteria فقط این باشد:

«پرداخت باید موفق شود.»

این معیار احتمالاً کافی نیست.

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

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

این بررسی‌ها بخشی از نگاه Verification هستند.

Validation در Agile چگونه انجام می‌شود؟ 🧪

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

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

مثلاً:

Login → Product → Cart → Checkout → Payment → Order

اگر رفتار واقعی سیستم با نیاز مورد انتظار مطابقت داشته باشد، شواهد مناسبی برای Validation به دست آمده است.

در پایان Sprint نیز ممکن است قابلیت توسط Product Owner یا Business Representative بررسی شود.

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

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

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

تفاوت مهم Agile با مدل‌های Sequential

در مدل‌های Sequential، ممکن است تیم مدت زیادی روی Requirement و Design کار کند و سپس وارد Development و Testing شود.

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

User Story
↓
🔍 Verification
↓
Development
↓
🔍 Verification
↓
Testing
↓
🧪 Validation
↓
Business Feedback
↓
Improvement

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

بنابراین V&V در Agile بیشتر Continuous و Iterative است.

یک مثال واقعی از Agile

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

قبل از توسعه:

تستر User Story و Acceptance Criteria را بررسی می‌کند. 🔍

بعد از توسعه:

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

Product Owner قابلیت را بررسی می‌کند و می‌گوید:

«کاربر باید بتواند تعداد محصول را هم مستقیماً در سبد تغییر دهد.»

تیم این Feedback را ثبت می‌کند و ممکن است آن را به یک User Story جدید تبدیل کند.

در Sprint بعدی، قابلیت جدید توسعه داده می‌شود و دوباره چرخه Verification و Validation تکرار می‌شود.

این دقیقاً یکی از مزیت‌های رویکرد Agile است:

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

نقش Acceptance Criteria در V&V در Agile

Acceptance Criteria در Agile اهمیت زیادی دارد و می‌تواند نقطه اتصال خوبی بین Verification و Validation باشد.

مثلاً:

Given: کاربر محصولی در سبد خرید دارد
When: پرداخت موفق انجام می‌شود
Then: سفارش باید با وضعیت Paid ثبت شود.

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

آیا Acceptance Criteria واضح، کامل و قابل تست است؟

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

آیا سیستم در عمل این رفتار را دارد؟

بنابراین Acceptance Criteria هم برای تعریف انتظار و هم برای ارزیابی نتیجه بسیار مهم است.

آیا Agile باعث می‌شود Verification و Validation یکی شوند؟

خیر.

حتی در Agile نیز تفاوت مفهومی آن‌ها حفظ می‌شود.

برای مثال:

Verification 🔍

آیا User Story و Acceptance Criteria درست تعریف شده‌اند؟

آیا Design و Code با آن‌ها مطابقت دارند؟

Validation 🧪

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

آیا کاربر یا کسب‌وکار می‌تواند با آن به هدف موردنظر برسد؟

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

V&V در Agile و نقش Tester

در Agile، تستر معمولاً نباید منتظر بماند تا Developer کار را کاملاً تمام کند.

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

• Refinement
• بررسی User Story
• بررسی Acceptance Criteria
• طراحی سناریو
• Test Planning
• Test Execution
• بررسی Feedback کاربران

مشارکت کند.

در نتیجه تستر می‌تواند هم در Verification و هم در Validation نقش داشته باشد.

این موضوع با مفهوم Shift-Left Testing نیز ارتباط پیدا می‌کند؛ یعنی تلاش برای شناسایی مشکلات هرچه زودتر در چرخه توسعه.

خلاصه تفاوت V&V در Agile

موضوع	Verification در Agile	Validation در Agile
تمرکز	User Story، Acceptance Criteria، Design، Code و Test Work Product	رفتار واقعی محصول و نیاز کاربر
زمان	در طول Sprint	در طول Sprint و هنگام دریافت Feedback
مثال	Review User Story	اجرای سناریوی واقعی
مشارکت	کل تیم	Tester، Product Owner، Business و کاربران
رویکرد	Continuous	Continuous و Iterative

نتیجه

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

Agile مفهوم Verification و Validation را تغییر نمی‌دهد؛ بلکه باعث می‌شود این دو فعالیت به‌جای اینکه در نقاط جدا و دیرهنگام پروژه متمرکز باشند، به‌صورت مستمر و تکرارشونده در هر Sprint انجام شوند. 🔄

حالا به یکی از مهم‌ترین مدل‌هایی می‌رسیم که ارتباط Verification و Validation را به شکلی بسیار واضح نشان می‌دهد:

اگر بخواهیم رابطه Verification و Validation را در یک مدل توسعه نرم‌افزار به شکل بسیار واضح ببینیم، V-Model یکی از بهترین مثال‌هاست.

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

اما قبل از هر چیز یک نکته مهم:

V-Model نمی‌گوید Verification فقط در سمت چپ و Validation فقط در سمت راست انجام می‌شود.

این یک ساده‌سازی رایج است. در واقع، Verification و Validation مفاهیم گسترده‌تری هستند که در مراحل مختلف چرخه توسعه و تست حضور دارند.

V-Model چیست؟

V-Model را می‌توان توسعه‌ای از رویکردهای Sequential دانست که در آن برای هر مرحله مهم توسعه، فعالیت‌های تست متناظر نیز در نظر گرفته می‌شود.

یک نمایش ساده از V-Model:

Requirements Analysis        Acceptance Testing
        ↓                          ↑
System Design              System Testing
        ↓                          ↑
Architecture Design      Integration Testing
        ↓                          ↑
Module Design                 Unit Testing
        ↓                          ↑
       Coding

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

به همین دلیل V-Model برای فهم ارتباط Verification و Validation بسیار مفید است.

Verification در سمت چپ V-Model

در سمت چپ V، تیم روی تعریف و ساخت محصول کار می‌کند.

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

Requirements Analysis

در این مرحله Requirementها بررسی می‌شوند.

مثلاً:

کاربر باید بتواند سفارش خود را آنلاین پرداخت کند.

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

• آیا Requirement واضح است؟
• آیا قابل تست است؟
• آیا ابهام دارد؟
• آیا شرایط موفقیت و شکست مشخص شده؟
• آیا با سایر Requirementها تناقض ندارد؟

System Design

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

آیا System Design می‌تواند Requirementهای تعریف‌شده را پوشش دهد؟

برای مثال اگر سیستم باید پرداخت آنلاین را پشتیبانی کند، Design باید نحوه ارتباط با Payment Gateway، مدیریت خطا و وضعیت تراکنش را مشخص کند.

این نوع بررسی می‌تواند بخشی از Verification باشد.

Architecture Design

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

• آیا معماری انتخاب‌شده نیازمندی‌های سیستم را پوشش می‌دهد؟
• آیا ارتباط بین سرویس‌ها درست طراحی شده؟
• آیا محدودیت‌های فنی در نظر گرفته شده‌اند؟

Module Design

در سطح جزئی‌تر، طراحی Moduleها بررسی می‌شود.

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

Validation در سمت راست V-Model

حالا به سمت راست V می‌رسیم.

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

Unit Testing

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

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

Integration Testing

در Integration Testing، تعامل بین اجزای مختلف بررسی می‌شود.

مثلاً:

Order Service ↔ Payment Service

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

System Testing

در System Testing، سیستم را در سطح گسترده‌تری بررسی می‌کنیم.

برای مثال کل فرایند خرید:

Login → Product → Cart → Checkout → Payment → Order

Acceptance Testing

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

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

ارتباط مراحل V-Model

یکی از ویژگی‌های جذاب V-Model این است که هر مرحله توسعه، یک سطح تست متناظر دارد.

سمت توسعه	سمت تست
Requirements	Acceptance Testing
System Design	System Testing
Architecture Design	Integration Testing
Module Design	Unit Testing
Coding	—

این رابطه باعث می‌شود تیم از همان زمان تعریف Requirement به این فکر کند که:

«این Requirement را بعداً چگونه باید تست کنیم؟»

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

چرا V-Model برای فهم V&V مناسب است؟

فرض کنید در مرحله Requirements یک Requirement تعریف شده است:

«کاربر باید بتواند سفارش خود را با موفقیت پرداخت کند.»

تیم در همان زمان می‌تواند به Acceptance Testing فکر کند:

چگونه قرار است در نهایت اثبات کنیم که این نیازمندی برآورده شده است؟

سپس در مرحله Design، تست System نیز در نظر گرفته می‌شود.

در مرحله Architecture، Integration Testing اهمیت پیدا می‌کند.

و در سطح Module، Unit Testing مطرح می‌شود.

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

یک داستان کوتاه از V-Model

فرض کنید تیم فروشگاه اینترنتی ما در جلسه Requirements نشسته است.

Business Analyst می‌گوید:

«کاربر باید بتواند پرداخت آنلاین انجام دهد.»

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

«اگر پرداخت انجام شود ولی Callback درگاه به سیستم نرسد، وضعیت سفارش چه خواهد بود؟»

تیم درباره موضوع صحبت می‌کند و Requirement کامل‌تر می‌شود.

چند هفته بعد، وقتی System Testing انجام می‌شود، همین سناریو تست می‌شود.

اگر این حالت از ابتدا در Requirement دیده نشده بود، ممکن بود تیم خیلی دیر متوجه مشکل شود.

این مثال نشان می‌دهد که فکر کردن به تست از همان ابتدای توسعه یکی از ایده‌های مهم V-Model است. 🎯

آیا سمت چپ V-Model فقط Verification است؟

خیر.

این نکته را حتماً باید در مقاله روشن کنیم.

گاهی در منابع آموزشی ساده، سمت چپ V-Model را Verification و سمت راست را Validation معرفی می‌کنند.

این توضیح برای درک اولیه مفید است، اما از نظر مفهومی نباید آن را یک قانون مطلق بدانیم.

Verification می‌تواند در فعالیت‌های مختلفی مثل Review و بررسی Work Productها انجام شود.

Validation نیز می‌تواند در سطوح مختلفی از تست و ارزیابی محصول اتفاق بیفتد.

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

سمت چپ V-Model بیشتر با فعالیت‌های تعریف و ساخت محصول و سمت راست بیشتر با ارزیابی محصول ساخته‌شده ارتباط دارد؛ این ساختار به درک رابطه Verification و Validation کمک می‌کند، اما این دو مفهوم دقیقاً معادل دو نیمه V نیستند.

V-Model چه چیزی به تستر یاد می‌دهد؟

یکی از مهم‌ترین درس‌های V-Model برای یک تستر این است:

تست نباید یک فعالیت کاملاً دیرهنگام باشد.

اگر Requirement امروز نوشته می‌شود، باید از همین امروز به Testability و نحوه ارزیابی آن فکر کرد.

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

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

این نگاه با مفاهیمی مثل Early Testing، Shift-Left و Quality Assurance ارتباط پیدا می‌کند.

جمع‌بندی V-Model

می‌توانیم ارتباط را این‌طور به خاطر بسپاریم:

Requirements
🔍 Review / Verification
↓
System Design
🔍 Verification
↓
Architecture Design
🔍 Verification
↓
Coding
↓
🧪 Unit Testing
🧪 Integration Testing
🧪 System Testing
🧪 Acceptance Testing

اما نکته اصلی فقط شکل V نیست.

پیام مهم V-Model این است:

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

در ادامه، برای اینکه تمام این مفاهیم از حالت تئوری خارج شوند، سراغ یک مثال جامع از Verification و Validation در یک پروژه واقعی می‌رویم و کل مسیر را از Requirement تا Acceptance و UAT دنبال می‌کنیم.

مثال جامع Verification و Validation در یک پروژه واقعی 🛒

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

برای این مثال، همان فروشگاه اینترنتی «شاپینو» را در نظر بگیریم.

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

هدف کسب‌وکار ساده است:

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

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

مرحله اول: تعریف Requirement

Business Analyst این Requirement را می‌نویسد:

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

در نگاه اول Requirement ساده و قابل فهم به نظر می‌رسد.

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

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

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

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

این بخش چه نوع فعالیتی است؟

🔍 Verification

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

مرحله دوم: تعریف Acceptance Criteria

بعد از بررسی Requirement، تیم معیارهای پذیرش را مشخص می‌کند.

مثلاً:

Acceptance Criteria

1. کاربر باید بتواند روش پرداخت آنلاین را انتخاب کند.
2. پس از پرداخت موفق، سفارش باید با وضعیت Paid ثبت شود.
3. در صورت پرداخت ناموفق، سفارش نباید Paid شود.
4. کاربر باید پس از پرداخت موفق شماره سفارش دریافت کند.
5. اگر تراکنش ناموفق باشد، کاربر باید بتواند دوباره تلاش کند.

حالا Requirement بسیار دقیق‌تر شده است.

مرحله سوم: Verification در Test Caseها

تستر بر اساس Acceptance Criteria، Test Case طراحی می‌کند.

مثلاً:

Test Case 1

Scenario: پرداخت موفق

Precondition:
کاربر یک سفارش معتبر دارد.

Steps:

1. ورود به Checkout
2. انتخاب پرداخت آنلاین
3. انتقال به درگاه
4. انجام پرداخت موفق
5. بازگشت به سایت

Expected Result:

سفارش باید با وضعیت Paid ثبت شود و شماره سفارش به کاربر نمایش داده شود.

تستر قبل از اجرای Test Case آن را Review می‌کند.

• آیا Requirement پوشش داده شده؟
• آیا Expected Result واضح است؟
• آیا Test Data مناسب است؟
• آیا Scenarioهای منفی هم وجود دارند؟

این بخش نیز می‌تواند نمونه‌ای از Verification باشد.

مرحله چهارم: Development

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

در این مرحله Code Review انجام می‌شود.

یکی از Developerها متوجه می‌شود که در یکی از مسیرهای خطا، وضعیت سفارش به اشتباه Paid ثبت می‌شود.

کد اصلاح می‌شود.

این هم یک نمونه دیگر از Verification است:

Requirement → Design → Code

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

مرحله پنجم: اجرای تست 🧪

حالا Build در محیط تست آماده است.

تستر Test Caseها را اجرا می‌کند.

سناریوی پرداخت موفق

کاربر:

Product → Cart → Checkout → Payment

پرداخت موفق انجام می‌شود.

نتیجه:

Order Status = Paid ✅

Test Case:

Pass

سناریوی پرداخت ناموفق

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

نتیجه:

Order Status = Pending ✅

Test Case:

Pass

سناریوی پرداخت موفق اما Callback ناموفق

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

پرداخت در درگاه موفق است، اما Callback به سیستم فروشگاه نمی‌رسد.

نتیجه:

Order Status = Pending

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

اینجا یک مشکل پیدا شده است.

آیا این فقط یک Bug است؟

از دید Testing، بله، می‌توانیم آن را به‌عنوان یک Defect بررسی و ثبت کنیم.

اما از دید Validation، یک سؤال مهم‌تر داریم:

آیا رفتار محصول در این شرایط واقعی برای کسب‌وکار و کاربر قابل قبول است؟

اگر پاسخ «خیر» باشد، این مشکل مستقیماً روی اعتبارسنجی محصول تأثیر می‌گذارد.

مرحله ششم: اصلاح و Retest

Developer مشکل را اصلاح می‌کند.

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

این بار:

Payment Success
↓
Callback
↓
Order = Paid
↓
Order Number نمایش داده می‌شود

همه چیز درست است. ✅

اما تستر هنوز کار را تمام نکرده است.

مرحله هفتم: Regression Testing

تغییر مربوط به Payment ممکن است روی قسمت‌های دیگر سیستم تأثیر گذاشته باشد.

بنابراین تستر Regression Testing انجام می‌دهد.

مثلاً بررسی می‌کند:

• ثبت سفارش عادی
• پرداخت با روش دیگر
• لغو سفارش
• Refund
• نمایش تاریخچه سفارش
• موجودی محصول

ممکن است قابلیت جدید Payment درست شده باشد، اما یک تغییر جانبی در بخش دیگری ایجاد کرده باشد.

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

مرحله هشتم: UAT

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

او یک سناریوی واقعی اجرا می‌کند:

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

فرایند با موفقیت انجام می‌شود.

Product Owner می‌گوید:

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

اینجا شواهد مهمی برای Validation به دست آمده است.

حالا Verification و Validation را کنار هم ببینیم

کل مسیر ما این بود:

Requirement
     ↓
🔍 Verification
     ↓
Acceptance Criteria
     ↓
🔍 Verification
     ↓
Design & Development
     ↓
🔍 Verification
     ↓
Test Case
     ↓
🔍 Verification
     ↓
Test Execution
     ↓
🧪 Validation
     ↓
System / E2E Testing
     ↓
🧪 Validation
     ↓
UAT
     ↓
🧪 Validation
     ↓
Business Acceptance

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

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

فرض کنیم در Requirement نوشته شده:

«کاربر باید بتواند با کارت بانکی پرداخت کند.»

تیم همه چیز را دقیقاً طبق همین Requirement پیاده‌سازی کرده است.

Verification می‌تواند بگوید:

بله، محصول مطابق Requirement ساخته شده است.** ✅

اما Product Owner در UAT می‌گوید:

«برای کسب‌وکار ما پرداخت با کیف پول هم ضروری است.»

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

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

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

و این دقیقاً یکی از دلایلی است که باید Verification و Validation را از هم تفکیک کنیم.

اگر فقط Verification داشتیم چه می‌شد؟

ممکن بود تیم بگوید:

«Requirement را کامل پیاده کردیم، Test Caseها Pass شدند؛ پس محصول آماده است.»

اما شاید Requirement از ابتدا نیاز واقعی کاربر را پوشش نداده باشد.

در نتیجه:

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

اگر فقط Validation داشتیم چه می‌شد؟

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

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

• Requirement
• Design
• Code
• Documentation
• Test Coverage

وجود داشته باشد.

بنابراین داشتن هر دو نگاه ضروری است.

یک فرمول ذهنی برای تسترها 🎯

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

سؤال اول 🔍

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

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

سؤال دوم 🧪

آیا چیزی که ساخته‌ایم واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند؟

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

این دو سؤال ساده، بخش زیادی از ابهام درباره V&V را از بین می‌برند.

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

مهم‌ترین درس این مثال برای یک تستر این است که کیفیت محصول فقط با Pass شدن Test Caseها تعریف نمی‌شود.

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

• Requirement را بررسی کند.
• Acceptance Criteria را به چالش بکشد.
• Test Case مناسب طراحی کند.
• رفتار واقعی سیستم را بررسی کند.
• سناریوهای واقعی کاربر را در نظر بگیرد.
• با Business و Product Owner ارتباط داشته باشد.
• نتایج تست را در context کسب‌وکار تحلیل کند.

به همین دلیل Verification و Validation فقط دو اصطلاح برای حفظ کردن نیستند؛ بلکه دو زاویه متفاوت برای فکر کردن درباره کیفیت نرم‌افزار هستند. 🧠

اشتباهات رایج درباره Verification و Validation

در این بخش بررسی می‌کنیم چه برداشت‌های اشتباهی درباره V&V وجود دارند؛ مثلاً اینکه Verification همان Testing است، Validation همان UAT است یا اینکه این دو فقط در پایان پروژه انجام می‌شوند.

اشتباهات رایج درباره Verification و Validation ⚠️

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

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

اشتباه اول: Verification و Validation همان Testing هستند ❌

این یکی از رایج‌ترین اشتباهات است.

ممکن است تصور کنیم:

Verification = Testing
Validation = Testing

اما این رابطه دقیق نیست.

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

مثلاً:

• Requirement Review
• Design Review
• Code Review

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

از طرف دیگر، Functional Testing، System Testing و UAT می‌توانند برای Validation شواهد فراهم کنند.

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

Testing یکی از ابزارهای مهم برای ارزیابی و Validation محصول است، اما Verification و Validation مفاهیم گسترده‌تری هستند.

اشتباه دوم: Verification فقط قبل از Testing انجام می‌شود ❌

این تصور هم کاملاً درست نیست.

ممکن است Verification در مراحل مختلف انجام شود:

Requirement Review

↓

Design Review

↓

Code Review

↓

Test Case Review

حتی بعد از اجرای تست نیز ممکن است Work Product یا نتایج حاصل از تست مورد بررسی قرار گیرند.

بنابراین Verification یک فعالیت یک‌باره نیست.

اشتباه سوم: Validation فقط در پایان پروژه انجام می‌شود ❌

این تصور بیشتر از مدل‌های سنتی و Sequential به وجود آمده است.

در واقع Validation می‌تواند در طول توسعه انجام شود.

به‌خصوص در Agile، تیم می‌تواند یک قابلیت کوچک را توسعه دهد، آن را تست کند، از Product Owner یا کاربران Feedback بگیرد و سپس بر اساس آن قابلیت را بهبود دهد.

Build → Test → Feedback → Improve

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

Validation می‌تواند Continuous و Iterative باشد.

اشتباه چهارم: Validation همان UAT است ❌

این اشتباه بسیار رایج است.

UAT یا User Acceptance Testing می‌تواند یکی از فعالیت‌های مهم برای Validation باشد، اما:

Validation ≠ UAT

Validation مفهوم گسترده‌تری است.

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

• Functional Testing
• System Testing
• End-to-End Testing
• Acceptance Testing
• UAT

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

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

اشتباه پنجم: Verification یعنی بررسی مدارک و Validation یعنی اجرای نرم‌افزار ❌

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

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

• Requirement Review
• Design Review
• Code Review

بدون اجرای نرم‌افزار انجام می‌شوند.

همچنین Validation معمولاً با اجرای محصول ارتباط نزدیکی دارد.

اما این تقسیم‌بندی مطلق نیست.

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

یعنی بپرسیم:

آیا داریم تطابق با Specification را بررسی می‌کنیم؟

یا:

آیا داریم مناسب بودن محصول برای نیاز واقعی را ارزیابی می‌کنیم؟

اشتباه ششم: اگر Verification موفق باشد، یعنی محصول حتماً خوب است ❌

فرض کنید Requirement اشتباه یا ناقص باشد.

تیم ممکن است Requirement را کاملاً درست پیاده‌سازی کند.

در این حالت:

Verification → موفق

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

مثلاً:

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

تیم دقیقاً طبق Requirement یک گزارش PDF ایجاد می‌کند.

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

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

این همان جایی است که Validation اهمیت پیدا می‌کند.

اشتباه هفتم: اگر همه Test Caseها Pass شوند، Validation موفق بوده است ❌

این هم یک نکته مهم برای تسترهاست.

فرض کنید:

100 Test Case

همه Pass شده‌اند. ✅

آیا می‌توانیم با اطمینان بگوییم محصول نیاز واقعی کاربر را برآورده می‌کند؟

نه لزوماً.

ممکن است:

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

Pass Rate بالا به‌تنهایی اثبات نمی‌کند که Validation کامل و موفق بوده است.

اشتباه هشتم: Verification مسئولیت Tester است و Validation مسئولیت User ❌

این تقسیم‌بندی بیش از حد ساده است.

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

مثلاً در Verification:

• Business Analyst
• Developer
• Tester
• Architect
• Product Owner

می‌توانند مشارکت کنند.

در Validation نیز:

• Tester
• Product Owner
• Business Representative
• End User
• Developer

می‌توانند نقش داشته باشند.

V&V مسئولیت یک نقش واحد نیست؛ یک فعالیت تیمی و چندنقشی است.

اشتباه نهم: Verification و Validation فقط در Waterfall اهمیت دارند ❌

این هم اشتباه است.

در Agile نیز هر دو مفهوم کاملاً قابل استفاده هستند.

تفاوت اصلی در نحوه اجراست.

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

اما در Agile:

هر Sprint

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

Verification → Development → Testing → Validation → Feedback

باشد.

پس Agile مفهوم V&V را حذف نمی‌کند؛ بلکه آن را تکرارشونده‌تر و مستمرتر می‌کند.

اشتباه دهم: Verification و Validation دو مرحله کاملاً جدا هستند ❌

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

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

اول تمام Verification را انجام می‌دهیم.

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

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

برای مثال یک Requirement ابتدا Review می‌شود.

بعد Design بررسی می‌شود.

بعد Code Review انجام می‌شود.

سپس Test Caseها Review می‌شوند.

بعد محصول تست می‌شود.

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

یک اشتباه رایج در مصاحبه‌های تست نرم‌افزار 🎯

اگر در مصاحبه از شما پرسیده شود:

Verification و Validation چه تفاوتی دارند؟

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

Verification بررسی می‌کند که آیا محصول را مطابق Specification و Requirement ساخته‌ایم؛ Validation بررسی می‌کند که آیا محصول ساخته‌شده واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند.

اما اگر مصاحبه‌کننده سؤال را ادامه داد و پرسید:

«پس Verification همان Static Testing و Validation همان Dynamic Testing است؟»

بهتر است پاسخ دهید:

خیر. این یک ساده‌سازی بیش از حد است. Static Testing می‌تواند یکی از روش‌های انجام Verification باشد و Dynamic Testing می‌تواند شواهدی برای Validation فراهم کند، اما این دو جفت مفهوم دقیقاً معادل یکدیگر نیستند.

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

یک جدول برای مرور سریع 🧠

تصور اشتباه	واقعیت
Verification = Testing	❌ Verification گسترده‌تر است
Validation = UAT	❌ UAT فقط یکی از فعالیت‌های مرتبط است
Verification فقط بدون اجرای نرم‌افزار است	❌ بیش از این است
Validation فقط در پایان پروژه است	❌ می‌تواند مستمر باشد
Pass شدن Test Caseها یعنی Validation موفق است	❌ لزوماً نه
V&V فقط مسئولیت Tester است	❌ تیمی است
V&V فقط در Waterfall است	❌ در Agile هم وجود دارد
Verification و Validation کاملاً جدا هستند	❌ می‌توانند هم‌پوشان و تکرارشونده باشند

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

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

🔍 Verification

آیا چیزی که ساخته‌ایم مطابق آن چیزی است که مشخص کرده‌ایم؟

🧪 Validation

آیا چیزی که ساخته‌ایم واقعاً همان چیزی است که کاربر و کسب‌وکار به آن نیاز دارند؟

اگر این دو سؤال را به‌درستی در ذهن داشته باشید، بسیاری از اختلافات ظاهری بین اصطلاحات V&V، Testing، UAT، Static Testing و Acceptance Testing نیز راحت‌تر قابل درک خواهند بود.

مرحله بعدی مقاله

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

چک‌لیست عملی Verification و Validation برای تسترها ✅

در این بخش، به‌جای تعریف و تئوری، یک Checklist قابل استفاده در پروژه می‌سازیم؛ از زمانی که Requirement به دست تستر می‌رسد تا اجرای تست، ثبت Defect، Retest، Regression و در نهایت Acceptance.

چک‌لیست عملی Verification و Validation برای تسترها ✅

حالا که مفاهیم Verification و Validation را از جنبه‌های مختلف بررسی کردیم، وقت آن است که این مفاهیم را به چیزی تبدیل کنیم که یک تستر واقعاً بتواند در پروژه از آن استفاده کند.

فرض کنید فردا یک User Story جدید به شما تحویل داده می‌شود. لازم نیست فقط منتظر Build بمانید.

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

🔍 Verification: آیا چیزی که قرار است بسازیم درست تعریف و ساخته شده است؟

🧪 Validation: آیا چیزی که ساخته‌ایم واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند؟

در ادامه یک Checklist مرحله‌به‌مرحله می‌سازیم.

بخش اول: Verification Checklist 🔍

1. بررسی Requirement

قبل از طراحی Test Caseها، Requirement را بررسی کنید.

چک کنید:

• Requirement واضح است.
• Requirement ابهام ندارد.
• Requirement قابل تست است.
• شرایط موفقیت مشخص است.
• شرایط خطا مشخص است.
• Business Ruleها مشخص هستند.
• محدودیت‌ها مشخص هستند.
• Requirement با سایر Requirementها تناقض ندارد.
• وابستگی‌های خارجی مشخص هستند.
• Requirement قابل اندازه‌گیری است.

مثلاً اگر نوشته شده:

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

از خودتان بپرسید:

«سریع یعنی چه؟»

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

2. بررسی Acceptance Criteria

در پروژه‌های Agile، Acceptance Criteria اهمیت زیادی دارد.

بررسی کنید:

• Acceptance Criteria برای User Story تعریف شده است.
• معیارها واضح هستند.
• قابل تست هستند.
• Expected Result مشخص است.
• Positive Scenario مشخص است.
• Negative Scenarioهای مهم مشخص شده‌اند.
• Edge Caseهای مهم در نظر گرفته شده‌اند.
• معیارها با نیاز کسب‌وکار هماهنگ هستند.

مثلاً:

«کاربر باید بتواند پرداخت کند.»

معیار کاملی نیست.

اما:

«پس از پرداخت موفق، سفارش باید با وضعیت Paid ثبت شود.»

قابل بررسی‌تر است.

3. بررسی Testability

یکی از مهم‌ترین مهارت‌های یک تستر حرفه‌ای، تشخیص Testability است.

از خودتان بپرسید:

«آیا واقعاً می‌توانم این Requirement را تست کنم؟»

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

«سیستم باید تجربه کاربری خوبی داشته باشد.»

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

«تجربه کاربری خوب را چگونه اندازه‌گیری و ارزیابی کنیم؟»

این سؤال می‌تواند باعث شود Requirement به معیارهای مشخص‌تری تبدیل شود.

4. بررسی Test Caseها

قبل از اجرای Test Caseها:

• Requirement مرتبط مشخص است.
• Traceability وجود دارد.
• Preconditions مشخص هستند.
• Test Data مشخص است.
• Steps واضح هستند.
• Expected Result دقیق است.
• Positive Scenario پوشش داده شده.
• Negative Scenario پوشش داده شده.
• Boundary Conditionها بررسی شده‌اند.
• Test Case قابل تکرار است.

این مرحله خودش یک نمونه مهم از Verification Work Product است.

5. بررسی Test Coverage

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

آیا چیزهایی که باید تست شوند، واقعاً در Test Caseها پوشش داده شده‌اند؟

برای این کار می‌توان از Traceability Matrix کمک گرفت.

Requirement	Test Case	وضعیت
پرداخت موفق	TC-01	Pass
پرداخت ناموفق	TC-02	Pass
Callback ناموفق	TC-03	Fail
Retry Payment	TC-04	Pass

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

بخش دوم: Validation Checklist 🧪

حالا وارد بخش Validation می‌شویم.

اینجا سؤال اصلی تغییر می‌کند:

آیا محصول واقعاً همان کاری را انجام می‌دهد که کاربر و کسب‌وکار انتظار دارند؟

6. اجرای سناریوی اصلی

ابتدا Happy Path را بررسی کنید.

مثلاً در فروشگاه:

Login → Product → Cart → Checkout → Payment → Order

بررسی کنید:

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

7. بررسی Negative Scenarioها

بعد از Happy Path، سراغ شرایط غیرعادی بروید.

• پرداخت ناموفق
• Timeout
• قطع اینترنت
• داده نامعتبر
• موجودی ناکافی
• Session Expire
• دوبار کلیک روی Submit
• Retry
• Refresh صفحه

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

8. بررسی Business Flow

گاهی Test Caseها Pass می‌شوند، اما Business Flow مشکل دارد.

مثلاً:

کاربر محصول را خریداری می‌کند.

همه تست‌ها Pass هستند.

اما بعد از پرداخت:

موجودی کالا کم نمی‌شود.

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

بنابراین از خودتان بپرسید:

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

9. بررسی End-to-End

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

مثلاً:

Login

↓

Search

↓

Product

↓

Cart

↓

Checkout

↓

Payment

↓

Order

↓

Invoice

این مسیر را End-to-End بررسی کنید.

10. بررسی نیاز واقعی کاربر

اینجا یکی از مهم‌ترین بخش‌های Validation قرار دارد.

از خودتان بپرسید:

آیا این قابلیت واقعاً مشکل کاربر را حل می‌کند؟

مثلاً تیم یک سیستم گزارش‌گیری ساخته است.

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

اما کاربران می‌گویند:

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

از نظر فنی Feature ساخته شده است.

اما از نظر Business Need هنوز ممکن است کافی نباشد.

11. بررسی Acceptance و UAT

در صورت نیاز، سناریوهای واقعی کسب‌وکار را با Business Representative یا User بررسی کنید.

«اگر من یک سفارش واقعی ثبت کنم، آیا تمام فرایند موردنیاز کسب‌وکار را طی می‌کنم؟»

بررسی کنید:

• Business Scenarioها اجرا شده‌اند.
• Acceptance Criteria برآورده شده‌اند.
• کاربران مناسب درگیر شده‌اند.
• Feedback کاربران ثبت شده است.
• مشکلات مهم قبل از Sign-off بررسی شده‌اند.

12. Retest و Regression

بعد از Fix شدن Defect:

Retest

بررسی کنید:

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

Regression

بررسی کنید:

آیا Fix باعث خراب شدن بخش دیگری نشده است؟

این دو را با هم اشتباه نگیرید.

یک سناریوی کامل از Checklist

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

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

Verification

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

Requirement

✅ واضح است.

Acceptance Criteria

✅ مشخص است.

Test Case

✅ سناریوهای اصلی و منفی دارد.

Traceability

✅ Requirement به Test Case متصل است.

Test Data

✅ آماده است.

Validation

تستر اجرا می‌کند:

• Payment Success ✅
• Payment Failure ✅
• Timeout ✅
• Retry ✅
• End-to-End Purchase ✅

سپس Business Representative سناریوی واقعی را اجرا می‌کند:

Purchase → Payment → Order → Invoice

و تأیید می‌کند:

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

در اینجا شواهد مناسبی از Validation داریم.

چک‌لیست نهایی V&V برای تستر 🎯

می‌توانید این چک‌لیست را به‌صورت یک الگوی ذهنی در پروژه‌ها استفاده کنید:

🔍 Verification

• Requirement بررسی شده؟
• Requirement قابل تست است؟
• Acceptance Criteria کامل است؟
• Business Ruleها مشخص‌اند؟
• Design بررسی شده؟
• Test Caseها Review شده‌اند؟
• Traceability برقرار است؟
• Test Coverage مناسب است؟
• Test Environment آماده و مطابق نیاز است؟

🧪 Validation

• Happy Path تست شده؟
• Negative Scenarioها تست شده‌اند؟
• Edge Caseهای مهم بررسی شده‌اند؟
• End-to-End Flow تست شده؟
• Business Flow بررسی شده؟
• نیاز واقعی کاربر بررسی شده؟
• Acceptance Testing انجام شده؟
• UAT در صورت نیاز انجام شده؟
• Defectهای مهم Retest شده‌اند؟
• Regression مناسب انجام شده؟
• Feedback کاربر یا Business بررسی شده؟

مهم‌ترین نکته این بخش

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

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

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

«چه Test Caseهایی باید اجرا کنم؟»

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

🔍 آیا چیزی که قرار است بسازیم درست تعریف و ساخته شده است؟

🧪 آیا چیزی که ساخته‌ایم واقعاً ارزش و نیاز مورد انتظار کاربر را برآورده می‌کند؟

جمع‌بندی نهایی Verification و Validation

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

Verification بیشتر روی تطابق Work Product با Requirement، Specification و معیارهای تعریف‌شده تمرکز دارد؛ در حالی که Validation بیشتر به این سؤال پاسخ می‌دهد که آیا محصول ساخته‌شده واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند یا خیر.

به همین دلیل فعالیت‌هایی مانند Requirement Review، Design Review و Code Review می‌توانند در Verification نقش داشته باشند و فعالیت‌هایی مانند Functional Testing، System Testing، End-to-End Testing، Acceptance Testing و UAT می‌توانند شواهدی برای Validation فراهم کنند.

در Agile نیز تفاوت مفهومی این دو از بین نمی‌رود؛ بلکه Verification و Validation می‌توانند در هر Sprint و به‌صورت Iterative و Continuous انجام شوند.

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

🔍 Verification: آیا محصول را درست ساخته‌ایم؟

🧪 Validation: آیا محصول درستی را ساخته‌ایم؟

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

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

منابع و مراجع

• NASA Systems Engineering Handbook – Verification and Validation
• NASA Systems Engineering Handbook
• ISTQB Standard Glossary of Terms Used in Software Testing
• ISTQB Glossary – Testing
• ISTQB Glossary – Validation
• ISTQB Glossary – Verification
• Manifesto for Agile Software Development
• Agile Alliance – The Agile Manifesto
• NASA Software Engineering Handbook – Verification Planning
• NASA Systems Engineering Handbook – Fundamentals of Systems Engineering

سوالات متداول درباره Verification و Validation ❓

Verification و Validation چه تفاوتی دارند؟

Verification بررسی می‌کند که آیا محصول مطابق Requirement، Specification و معیارهای تعریف‌شده ساخته شده است یا خیر. Validation بررسی می‌کند که آیا محصول ساخته‌شده واقعاً نیاز کاربر و کسب‌وکار را برآورده می‌کند یا خیر.

آیا Verification و Validation همان Testing هستند؟

خیر. Testing با Verification و Validation ارتباط دارد، اما این مفاهیم یکسان نیستند. فعالیت‌هایی مانند Requirement Review، Design Review و Code Review می‌توانند در Verification نقش داشته باشند و Testing می‌تواند شواهد مهمی برای Validation فراهم کند.

آیا Verification همان Static Testing و Validation همان Dynamic Testing است؟

خیر. این یک ساده‌سازی بیش از حد است. Static Testing می‌تواند یکی از روش‌های انجام Verification باشد و Dynamic Testing می‌تواند شواهدی برای Validation فراهم کند، اما این دو جفت مفهوم دقیقاً معادل یکدیگر نیستند.

Verification در STLC در کدام مرحله انجام می‌شود؟

Verification محدود به یک مرحله خاص از STLC نیست. برای مثال می‌تواند در Requirement Analysis، Test Planning، Test Case Design، Review مستندات تست و بررسی Test Work Productها انجام شود.

Validation در STLC در کدام مرحله انجام می‌شود؟

Validation نیز یک مرحله مستقل از STLC نیست. با این حال، در Test Execution، System Testing، End-to-End Testing، Acceptance Testing و UAT می‌توان شواهد مهمی برای Validation محصول به دست آورد.

آیا Validation همان UAT است؟

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

آیا Verification فقط قبل از اجرای نرم‌افزار انجام می‌شود؟

خیر. Verification می‌تواند در مراحل مختلف چرخه توسعه و تست انجام شود؛ از Requirement و Design گرفته تا Code، Test Case و سایر Work Productها. بنابراین Verification یک فعالیت صرفاً پیش از اجرای نرم‌افزار نیست.

آیا Validation فقط در پایان پروژه انجام می‌شود؟

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

اگر همه Test Caseها Pass شوند، آیا Validation موفق بوده است؟

نه لزوماً. ممکن است Test Caseها ناقص باشند، نیاز واقعی کاربر پوشش داده نشده باشد یا Requirement اولیه ناقص باشد. بنابراین Pass شدن Test Caseها به‌تنهایی اثبات نمی‌کند که محصول تمام نیازهای واقعی کاربر و کسب‌وکار را برآورده کرده است.

آیا Verification و Validation فقط در Waterfall استفاده می‌شوند؟

خیر. هر دو مفهوم در Agile نیز کاربرد دارند. در Agile فعالیت‌های مرتبط با Verification و Validation می‌توانند در هر Sprint و به‌صورت Continuous و Iterative انجام شوند.

آیا Verification و Validation دو مرحله کاملاً جدا هستند؟

خیر. این دو مفهوم ممکن است در طول چرخه توسعه و تست با یکدیگر هم‌پوشانی داشته باشند و چندین بار تکرار شوند. برای مثال Requirement Review، Design Review، Test Case Review و Test Execution همگی می‌توانند بخشی از این چرخه باشند.

چه کسی مسئول Verification و Validation است؟

Verification و Validation معمولاً مسئولیت یک نقش واحد نیستند. Business Analyst، Developer، Tester، Architect، Product Owner و Business Representative می‌توانند با توجه به نوع فعالیت در این فرایندها مشارکت داشته باشند.

نقش Tester در Verification و Validation چیست؟

تستر می‌تواند از بررسی Requirement و Acceptance Criteria تا طراحی Test Case، اجرای تست، بررسی سناریوهای واقعی، تحلیل Defect، Retest، Regression و ارزیابی نیازهای کاربر در Verification و Validation نقش داشته باشد.

آیا STLC همان Validation است؟

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

ساده‌ترین راه برای به خاطر سپردن تفاوت Verification و Validation چیست؟

می‌توانید این دو سؤال را به خاطر بسپارید: Verification می‌پرسد «آیا محصول را درست ساخته‌ایم؟» و Validation می‌پرسد «آیا محصول درستی را ساخته‌ایم؟»