ممکن است یک تیم نرمافزار را دقیقاً مطابق مشخصات بسازد، اما محصول همچنان مسئله کاربر را حل نکند. این همان فاصلهای است که دو مفهوم Verification و Validation روشن میکنند: یکی میپرسد آیا خروجی را طبق الزامهای تعیینشده ساختهایم و دیگری میسنجد آیا خروجی برای استفاده و نیاز واقعی مناسب است.
در فارسی، Verification را معمولاً راستیآزمایی یا صحهگذاری و Validation را اعتبارسنجی ترجمه میکنند. در این مقاله تفاوت دقیق آنها، فعالیتهای هرکدام، جایگاهشان در SDLC و STLC، اشتباه رایج «ایستا در برابر پویا» و یک مثال عملی از فروشگاه اینترنتی را بررسی میکنیم.
فهرست مطالب
تفاوت Verification و Validation در یک نگاه
- Verification: آیا محصول و مصنوعات آن با نیازمندیها، طراحی و معیارهای مشخصشده مطابقت دارند؟ به بیان مشهور: Are we building the product right?
- Validation: آیا محصول نهایی یا در حال تکامل برای نیاز، استفاده و زمینه واقعی کاربر مناسب است؟ به بیان مشهور: Are we building the right product?
مثال ساده: اگر معیار نوشته باشد «کد تخفیف برای سفارش بالای ۵۰۰ هزار تومان اعمال شود»، بررسی پیادهسازی همین قانون Verification است. اما اینکه این قانون واقعاً هدف کمپین، انتظار کاربر و سودآوری موردنظر را تأمین کند، بخشی از Validation است.
این دو مکملاند. Verification بدون Validation میتواند محصولی دقیق اما بیفایده بسازد؛ Validation بدون کنترل درستبودن پیادهسازی نیز نمیتواند نتیجه قابلاعتماد بدهد.
Verification یا راستیآزمایی چیست؟
Verification فرایند ارزیابی خروجیهای یک فعالیت توسعه است تا مشخص شود الزامها و معیارهای تعیینشده برای همان فعالیت برآورده شدهاند یا نه. خروجی میتواند سند نیازمندی، مدل طراحی، قرارداد API، کد، تستکیس، فایل پیکربندی یا نسخه نرمافزار باشد.
بر اساس راهنمای مرجع NIST درباره Software V&V، فعالیتهای Verification محصولات هر مرحله توسعه را در برابر الزامهای آغاز آن مرحله بررسی میکنند. بنابراین Verification فقط «بازبینی کد» نیست؛ بسته به خروجی و معیار میتواند تحلیل، Review، Demonstration یا Test باشد.
نمونه فعالیتهای Verification
- بازبینی نیازمندی از نظر کاملبودن، سازگاری و قابلیت تست؛
- بررسی طراحی در برابر محدودیتهای معماری و امنیتی؛
- Code Review و تحلیل استاتیک؛
- کنترل Traceability میان نیازمندی، طراحی، کد و تست؛
- تست واحد یک تابع در برابر قرارداد مشخص آن؛
- Contract Test میان دو سرویس؛
- بررسی تستکیسها در برابر معیار پذیرش؛
- کنترل Build، تنظیمات و Release در برابر Baseline توافقشده.
Verification چه نوع عیبی پیدا میکند؟
- نیازمندی ناقص یا متناقض؛
- طراحی ناسازگار با الزام فنی؛
- پیادهسازی متفاوت با Specification؛
- فرمول، نوع داده یا شرط اشتباه؛
- نقض استاندارد کدنویسی یا امنیت؛
- پوشش ناقص تست نسبت به نیازمندی؛
- تغییر بدون مستند یا تنظیمات ناهماهنگ.
تست استاتیک یکی از ابزارهای مهم Verification است، اما تمام آن نیست.
Validation یا اعتبارسنجی چیست؟
Validation شواهدی فراهم میکند که محصول برای نیاز و استفاده موردنظر کاربر یا ذینفع مناسب است. معیار فقط «مطابقت با سند» نیست؛ ممکن است خود سند نیاز واقعی را بد فهمیده باشد. Validation میپرسد آیا مسئله درست را با تجربه و نتیجه قابلقبول حل کردهایم.
نمونه فعالیتهای Validation
- مصاحبه و مشاهده کاربر برای فهم مسئله؛
- ارزیابی Prototype یا MVP با کاربران هدف؛
- تست سیستم و مسیر End-to-End در زمینه نزدیک به واقعیت؛
- User Acceptance Testing یا UAT؛
- آزمون Alpha/Beta و Pilot محدود؛
- تست کاربردپذیری و دسترسپذیری؛
- بررسی سناریوهای عملیاتی، بازیابی و پشتیبانی؛
- اندازهگیری نتیجه پس از انتشار، مانند تکمیل موفق فرایند و نرخ خطا.
Validation چه نوع مشکلی پیدا میکند؟
- حلکردن مسئله اشتباه؛
- فرایند دشوار یا نامفهوم برای کاربر؛
- نادیدهگرفتن زمینه واقعی استفاده؛
- عدم تناسب عملکرد با حجم، دستگاه یا شبکه واقعی؛
- پیام و اصطلاح نامأنوس برای مخاطب؛
- نیاز پشتیبانی یا عملیات که در Specification دیده نشده است؛
- محصول درستپیادهشدهای که ارزش مورد انتظار را ایجاد نمیکند.
تست پذیرش یکی از فعالیتهای مهم Validation است، اما Validation را نباید فقط به UAT انتهای پروژه محدود کرد. اعتبارسنجی ایده، Story و Prototype از همان ابتدا جلوی ساخت قابلیت بیارزش را میگیرد.
جدول مقایسه Verification و Validation
| معیار | Verification | Validation |
|---|---|---|
| پرسش اصلی | آیا محصول را درست میسازیم؟ | آیا محصول درست را میسازیم؟ |
| مرجع ارزیابی | نیازمندی، Specification، طراحی و استاندارد | نیاز و استفاده واقعی کاربر/کسبوکار |
| تمرکز | درستی و کاملبودن خروجی هر مرحله | تناسب محصول با هدف و زمینه استفاده |
| زمان | در سراسر چرخه توسعه | از کشف مسئله تا پس از انتشار |
| روشها | Review، تحلیل، تست واحد/یکپارچگی، Traceability | Prototype، UAT، System Test، Pilot، بازخورد واقعی |
| شرکتکنندگان | توسعه، QA، معماری، امنیت و بازبین تخصصی | کاربر، Product، کسبوکار، QA، پشتیبانی و عملیات |
| نمونه خروجی | یافته Review، نتیجه تست، گزارش انطباق | تأیید پذیرش، بازخورد کاربر، نتیجه آزمایش و شاخص استفاده |
| ریسک در صورت حذف | ساخت نادرست یا ناقص آنچه تعریف شده | ساخت درستِ چیزی که کسی به آن نیاز ندارد |
آیا Verification همیشه ایستا و Validation همیشه پویا است؟
خیر؛ این یک میانبر آموزشی رایج اما بیشازحد ساده است. بسیاری از فعالیتهای Verification ایستا هستند—مانند Review نیازمندی و Code Review—و بسیاری از فعالیتهای Validation با اجرای محصول انجام میشوند—مانند UAT. با این حال، مرز آنها «اجراشدن یا نشدن کد» نیست؛ مرز اصلی نوع پرسش و مرجع ارزیابی است.
تست واحد یا یکپارچگی میتواند اجرای پویا باشد و همچنان برای Verification استفاده شود، چون پیادهسازی را در برابر Specification میسنجد. از سوی دیگر، Review یک Prototype یا سناریوی فرایند با کاربر میتواند بدون نرمافزار کامل، برای Validation به کار رود.
به جای حفظکردن «Verification = Static» و «Validation = Dynamic»، بپرسید: نتیجه را با چه مرجعی مقایسه میکنیم—مشخصات ساخت یا نیاز واقعی استفاده؟
تفاوت V&V با QA و Testing
- QA: رویکرد کلان و فرایندمحور برای پیشگیری و بهبود کیفیت؛
- Testing: فعالیتهای ارزیابی برای کشف عیب و فراهمکردن اطلاعات کیفیت؛
- V&V: دو هدف مکمل برای سنجش درستبودن خروجیها و مناسببودن محصول.
Testing میتواند در خدمت Verification، Validation یا هر دو باشد. برای مثال، تست سیستم یک قانون مشخص را Verify و همزمان جریان واقعی کاربر را Validate میکند. برای دیدن جایگاه این مفاهیم، راهنمای تست نرمافزار چیست را بخوانید.
Verification و Validation در چرخه توسعه نرمافزار
| مرحله | نمونه Verification | نمونه Validation |
|---|---|---|
| کشف و نیازمندی | بررسی کاملبودن و عدم تناقض Story | مصاحبه کاربر و اعتبارسنجی مسئله |
| طراحی | Review معماری در برابر محدودیتها | تست Prototype و جریان با کاربر |
| توسعه | Code Review، تحلیل استاتیک، Unit Test | Demo زودهنگام قابلیت به Product/کاربر |
| یکپارچگی | Contract و Integration Test در برابر قرارداد | بررسی سناریوی واقعی چندسرویسه |
| سیستم و پذیرش | تست نیازمندیهای مشخصشده | UAT، تست کاربردپذیری و Pilot |
| پس از انتشار | کنترل تنظیمات و Release مورد تأیید | مشاهده رفتار واقعی، Feedback و Outcome |
در چرخه حیات تست نرمافزار (STLC)، V&V از تحلیل نیازمندی آغاز میشود و تا اختتام و بازخورد بعد از انتشار ادامه دارد. محدودکردن آن به یک Gate پایانی، هزینه اصلاح و ریسک ساخت اشتباه را بیشتر میکند.
V-Model چه ارتباطی با Verification و Validation دارد؟
V-Model ارتباط فعالیتهای تعریف/طراحی در سمت چپ را با سطح متناظر تست در سمت راست نشان میدهد. بهصورت ساده:
- نیاز کسبوکار ↔ تست پذیرش؛
- نیازمندی سیستم ↔ تست سیستم؛
- معماری ↔ تست یکپارچگی؛
- طراحی جزء ↔ تست واحد.
سمت چپ فقط برای مستندسازی نیست؛ Review و طراحی تست باید همزمان پیش بروند. سمت راست نیز صرفاً «Validation» نیست؛ اجرای هر سطح میتواند هم انطباق با Specification و هم تناسب با نیاز را بررسی کند. راهنمای سطوح تست نرمافزار این ارتباط را کاملتر توضیح میدهد.
مثال عملی: قابلیت لغو سفارش در فروشگاه اینترنتی
فرض کنید نیازمندی میگوید: «کاربر تا پیش از ارسال کالا میتواند سفارش را لغو کند و مبلغ به کیف پول بازگردد.»
فعالیتهای Verification
- Review نیازمندی: «پیش از ارسال» دقیقاً کدام Statusها را شامل میشود؟
- بررسی طراحی: آیا لغو و بازپرداخت اتمیکاند یا خطر وضعیت نیمهکاره وجود دارد؟
- Code Review: مجوز کاربر و Idempotency درخواست لغو کنترل شده است؟
- Unit Test: مبلغ بازپرداخت برای تخفیف و هزینه ارسال درست محاسبه میشود؟
- Integration Test: وضعیت سفارش و تراکنش کیف پول سازگار بهروزرسانی میشوند؟
- Traceability: همه معیارهای پذیرش تست متناظر دارند؟
فعالیتهای Validation
- مصاحبه با پشتیبانی: کاربران در چه زمانی و با چه دلیلی لغو میکنند؟
- تست Prototype: دکمه لغو و پیام پیامد آن برای کاربر قابلفهم است؟
- UAT: تیم عملیات وضعیت لغو را در پنل و فرایند انبار بهدرستی میبیند؟
- Pilot: در بازه محدود، نرخ تماس پشتیبانی و خطای فرایند کنترل میشود؟
- پس از انتشار: آیا کاربران بدون تماس با پشتیبانی لغو را کامل میکنند؟
ممکن است همه تستهای Verification پاس شوند، اما Validation نشان دهد بازگشت به کیف پول برای بخش بزرگی از کاربران قابلقبول نیست و انتظار بازگشت به روش پرداخت اولیه دارند. در این حالت، پیادهسازی طبق سند درست بوده ولی خود تصمیم محصول نیاز به بازنگری دارد.
نقشها و مسئولیتها در V&V
- Product/Business: تعریف Outcome، نیاز کاربر و معیار پذیرش؛
- BA: شفافیت، سازگاری و Traceability نیازمندی؛
- Developer: Review، تست سطح پایین و انطباق پیادهسازی؛
- QA/Test: تحلیل ریسک، طراحی پوشش، اجرای V&V و گزارش شواهد؛
- UX Research/Design: اعتبارسنجی جریان و تجربه با کاربر؛
- Security/Operations: کنترلهای تخصصی و تناسب عملیاتی؛
- User/Customer: بازخورد زمینه واقعی و پذیرش.
در محصولات ایمنیحیاتی، مالی یا تحت مقررات، ممکن است Independent Verification and Validation (IV&V) لازم باشد؛ یعنی بخشی از ارزیابی توسط تیمی مستقل از گروه توسعه انجام شود تا عینیت و اعتماد بیشتر شود. میزان استقلال باید با ریسک و الزام قانونی تعیین شود.
چکلیست Verification
- نسخه و مرجع ارزیابی (Requirement/Design/Standard) مشخص است.
- نیازمندی کامل، سازگار، قابلردیابی و قابل تست است.
- طراحی همه محدودیتهای عملکردی و غیرکارکردی را پوشش میدهد.
- کد و تنظیمات با استاندارد و معماری همراستا هستند.
- ورودی نامعتبر، خطا، Timeout و بازیابی بررسی شدهاند.
- تستها به نیازمندی و ریسک مرتبطاند و نتیجه مورد انتظار دقیق است.
- یافتهها مالک، اولویت و شواهد دارند.
- اصلاحها دوباره بررسی یا Retest شدهاند.
چکلیست Validation
- مسئله و کاربر هدف با شواهد مشخص شدهاند.
- معیار موفقیت فقط Feature Delivery نیست و Outcome دارد.
- Prototype یا نسخه زودهنگام با نماینده واقعی کاربر بررسی شده است.
- داده، دستگاه، زبان، شبکه و زمینه استفاده واقعبینانهاند.
- سناریوی End-to-End، خطا و بازیابی عملیاتی پوشش داده شدهاند.
- نیاز دسترسپذیری، پشتیبانی و آموزش دیده شده است.
- UAT معیار، مسئول و تصمیم ثبتشده دارد.
- پس از انتشار، Feedback و شاخص واقعی برای اصلاح فرضها جمع میشود.
اشتباهات رایج
- یکیدانستن Verification با تست ایستا و Validation با تست پویا؛
- اعتبارسنجی محصول فقط در UAT انتهای پروژه؛
- فرض درستبودن سند نیازمندی بدون بررسی نیاز واقعی؛
- استفاده از نظر مدیر محصول بهعنوان جایگزین بازخورد کاربر؛
- نداشتن Traceability و مرجع روشن برای Verification؛
- اندازهگیری خروجی مانند تعداد Feature به جای Outcome کاربر؛
- نادیدهگرفتن شرایط واقعی ایران مانند RTL، ارقام، واحد پول، دستگاه و کیفیت شبکه؛
- تبدیل V&V به Gate اداری به جای فرایند یادگیری و کاهش ریسک.
سوالات متداول
Verification و Validation به فارسی چه میشوند؟
Verification معمولاً «راستیآزمایی» یا «صحهگذاری» و Validation «اعتبارسنجی» ترجمه میشود. چون ترجمهها در منابع متفاوتاند، نوشتن اصطلاح انگلیسی کنار فارسی ابهام را کم میکند.
کدامیک زودتر انجام میشود؟
هر دو از ابتدا آغاز میشوند و پیوستهاند. اعتبارسنجی مسئله و نیاز حتی پیش از Specification انجام میشود؛ Verification نیز از نخستین سند و طراحی شروع میشود. ترتیب خطی «اول Verification، بعد Validation» همیشه درست نیست.
آیا تست جعبهسیاه همان Validation است؟
خیر. Black-box یک رویکرد طراحی تست بر اساس ورودی و خروجی است. میتواند برای Validation یا Verification استفاده شود؛ هدف و مرجع ارزیابی تعیینکنندهاند.
آیا تست جعبهسفید همان Verification است؟
خیر. White-box بر ساختار داخلی تمرکز دارد و اغلب در Verification مفید است، اما Verification دامنه گستردهتری شامل نیازمندی، طراحی، کد، پیکربندی و تست دارد.
آیا یک تست میتواند هم Verification و هم Validation باشد؟
بله. یک سناریوی End-to-End میتواند هم تطابق با معیار پذیرش را Verify کند و هم مناسببودن جریان برای کاربر را Validate کند؛ به شرط آنکه هر دو نوع معیار و شواهد روشن باشند.
جمعبندی
Verification میسنجد خروجیها مطابق الزامها و معیارهای تعیینشده ساخته شدهاند؛ Validation بررسی میکند محصول در زمینه واقعی، نیاز درست را حل میکند. تفاوت آنها در «ایستا یا پویا بودن» خلاصه نمیشود. تیمهای قوی هر دو را از ابتدای چرخه و با مشارکت کاربر، کسبوکار و مهندسی اجرا میکنند تا نهفقط محصول را درست بسازند، بلکه محصول درست را بسازند.
