Static Testing چیست؟ راهنمای کاربردی تست ایستا بر اساس ISTQB

۱. مقدمه

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

اما آیا تست نرم‌افزار حتماً باید با اجرای آن آغاز شود؟

خیر. بخش مهمی از فعالیت‌های تست می‌تواند قبل از اجرای نرم‌افزار و حتی پیش از شروع توسعه انجام شود. این رویکرد با عنوان Static Testing (تست ایستا) شناخته می‌شود.

در تست ایستا، به‌جای اینکه منتظر بمانیم نرم‌افزار ساخته شود و سپس مشکلات آن را از طریق اجرای تست پیدا کنیم، Work Productهای مختلف مانند نیازمندی‌ها، طراحی، کد و تست کیس‌ها را بدون نیاز به اجرای نرم‌افزار بررسی می‌کنیم. این بررسی می‌تواند به‌صورت دستی، مانند Review، یا با استفاده از ابزارهای Static Analysis انجام شود.

برای درک بهتر، فرض کنید یک تیم در حال توسعه سامانه فروشگاه اینترنتی است. Business Analyst نیازمندی زیر را در سند پروژه ثبت کرده است:

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

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

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

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

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

هدف این مقاله چیست؟

در این مقاله، Static Testing را بر اساس مفاهیم ISTQB Certified Tester Foundation Level (CTFL) v4.0.1 بررسی می‌کنیم و در کنار مفاهیم نظری، به کاربرد آن در پروژه‌های واقعی می‌پردازیم.

در طول مقاله با موضوعات زیر آشنا خواهیم شد:

• Static Testing چیست و چه تفاوتی با Dynamic Testing دارد؟
• تست ایستا در مدل‌های Waterfall و Agile چه زمانی انجام می‌شود؟
• چه Work Productهایی را می‌توان بررسی کرد؟
• Review چیست و چه انواعی دارد؟
• نقش‌هایی مانند Author، Reviewer و Moderator چه مسئولیت‌هایی دارند؟
• چگونه یک تستر Requirements و User Story را بررسی می‌کند؟
• چه Defectهایی با Static Testing قابل شناسایی هستند؟
• چگونه یک Checklist کاربردی برای Review طراحی کنیم؟

هدف نهایی این است که پس از مطالعه مقاله، Static Testing را نه فقط به‌عنوان یک مفهوم تئوری در ISTQB، بلکه به‌عنوان بخشی از فعالیت‌های روزمره یک Software Tester یا QA Engineer درک کنیم.

۲. Static Testing چیست؟ (تست ایستا)

۲.۱ تعریف Static Testing

Static Testing یا تست ایستا، روشی برای بررسی Work Productها بدون اجرای نرم‌افزار است که با هدف شناسایی Defectها، ابهامات، ناسازگاری‌ها و سایر مشکلات احتمالی انجام می‌شود.

بر اساس چارچوب ISTQB، تست ایستا شامل فعالیت‌هایی مانند Review و Static Analysis است و می‌تواند در مراحل مختلف چرخه توسعه نرم‌افزار انجام شود.

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

رویکرد اول: Dynamic Testing

در Dynamic Testing، نرم‌افزار یا بخشی از آن اجرا می‌شود و رفتار واقعی سیستم را بررسی می‌کنیم.

مثلاً برای تست Login:

1. صفحه Login را باز می‌کنیم.
2. Username و Password وارد می‌کنیم.
3. روی دکمه Login کلیک می‌کنیم.
4. نتیجه اجرای سیستم را بررسی می‌کنیم.

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

رویکرد دوم: Static Testing

در Static Testing، قبل از اجرای نرم‌افزار، Work Product مرتبط را بررسی می‌کنیم.

مثلاً قبل از اینکه صفحه Login توسعه پیدا کند، Requirement زیر را دریافت می‌کنیم:

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

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

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

در اینجا هنوز صفحه Login اجرا نشده است؛ اما تستر می‌تواند مشکلات موجود در Requirement را شناسایی و برای اصلاح آن‌ها اقدام کند.

۲.۲ آیا Static Testing فقط برای کد است؟

خیر. یکی از نکات مهم در ISTQB این است که Static Testing به Source Code محدود نمی‌شود.

هر Work Product مناسب می‌تواند بر اساس هدف و شرایط پروژه تحت بررسی قرار بگیرد.

نمونه‌هایی از Work Productهای قابل بررسی

Work Product	نمونه موارد قابل بررسی
Requirements	SRS، Business Requirements و نیازمندی‌های عملکردی
User Stories و Acceptance Criteria	وضوح، کامل بودن و قابلیت تست‌پذیری
Design Documents	راهکار طراحی و جنبه‌های فنی
Source Code	Code Review و Static Analysis
Test Cases و Test Plans	پوشش، درستی و کامل بودن طراحی تست
API Documentation و سایر اسناد	سازگاری، ابهام و اطلاعات ناقص

نکته: فهرست بالا نمونه‌هایی از Work Productهاست؛ اینکه چه مواردی بررسی شوند به پروژه، ریسک و هدف Review بستگی دارد.

۲.۳ Static Testing چگونه به کشف زودهنگام Defect کمک می‌کند؟

یکی از مزایای اصلی Static Testing، شناسایی مشکلات در مراحل اولیه توسعه است.

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

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

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

مثال: Requirement مربوط به سقف انتقال وجه

Requirement اولیه:

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

از دید تستر، این Requirement چند ابهام دارد:

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

این موارد لزوماً همه Defect قطعی نیستند؛ بعضی از آن‌ها سؤال یا ابهام در Requirement هستند که باید با افراد مسئول بررسی شوند.

نسخه دقیق‌تر Requirement

کاربر می‌تواند در هر تراکنش مبلغی بین ۱۰۰٬۰۰۰ تا ۵۰٬۰۰۰٬۰۰۰ ریال انتقال دهد، مشروط بر اینکه موجودی حساب برای انجام تراکنش کافی باشد.

این نسخه هنوز ممکن است به جزئیات بیشتری نیاز داشته باشد، اما نسبت به عبارت «مبلغ دلخواه» قابل بررسی‌تر است.

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

۲.۴ آیا Static Testing فقط قبل از شروع تست انجام می‌شود؟

خیر. Static Testing در مراحل مختلف SDLC قابل انجام است و محدود به مرحله پیش از Dynamic Testing نیست.

مرحله	نمونه فعالیت Static Testing
Backlog Refinement	بررسی User Story و Acceptance Criteria
Design	بررسی راهکار فنی
Development	Code Review و Static Analysis
Test Preparation	بررسی Test Caseها و Test Plan
پس از اصلاح Work Product	Review مجدد برای بررسی اصلاحات

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

در مدل Waterfall نیز می‌توان در مراحل Requirements، Design، Development و Test Preparation، Work Productهای مرتبط را بررسی کرد.

جمع‌بندی بخش ۲

• Static Testing بدون اجرای نرم‌افزار انجام می‌شود.
• این نوع تست فقط به Source Code محدود نیست.
• Requirements، Design، Test Cases و سایر Work Productها می‌توانند بررسی شوند.
• Static Testing می‌تواند به شناسایی زودهنگام Defect و ابهام کمک کند.
• تست ایستا در مراحل مختلف SDLC و در مدل‌های Waterfall و Agile کاربرد دارد.

۳. جایگاه Static Testing در SDLC و Shift-Left Testing

یکی از مهم‌ترین نکات درباره Static Testing این است که آن را نباید به یک مرحله خاص از پروژه محدود کنیم. تست ایستا می‌تواند در مراحل مختلف Software Development Lifecycle انجام شود و یکی از کاربردهای مهم آن، کمک به شناسایی مشکلات هرچه زودتر در چرخه توسعه است.

برای اینکه جایگاه آن را بهتر درک کنیم، ابتدا Waterfall و سپس Agile را بررسی کنیم.

۳.۱ Static Testing در مدل Waterfall

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

Requirements ← Design ← Development ← Testing ← Release

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

در واقع، تستر می‌تواند خیلی زودتر وارد فرایند شود:

Requirements
     ↓
  Review
     ↓
Design
     ↓
  Review
     ↓
Development
     ↓
Code Review / Static Analysis
     ↓
Testing
     ↓
Dynamic Testing

برای مثال، وقتی تیم در حال تهیه Requirements است، تستر می‌تواند آن‌ها را از نظر:

• کامل بودن
• واضح بودن
• سازگاری
• قابل تست بودن
• وجود شرایط مرزی و خطا

بررسی کند.

در مرحله Design نیز می‌توان Design Document را بررسی کرد و در مرحله Development، Code Review یا Static Analysis انجام داد.

بنابراین حتی در یک رویکرد ترتیبی مانند Waterfall، Testing فقط به اجرای Test Caseها پس از Development محدود نمی‌شود.

۳.۲ یک مثال واقعی در Waterfall

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

مرحله اول: Requirements

Business Analyst این Requirement را نوشته است:

کاربر باید بتواند با کارت بانکی خود پرداخت کند.

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

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

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

مرحله دوم: Design

تیم طراحی مشخص کرده است که Payment Service از طریق یک API با درگاه بانکی ارتباط داشته باشد.

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

اگر Payment Gateway در دسترس نباشد چه اتفاقی می‌افتد؟

یا:

اگر درخواست پرداخت ارسال شود اما Response دریافت نشود، سیستم چگونه از پرداخت تکراری جلوگیری می‌کند؟

این هم Static Testing است، چون هنوز رفتار واقعی سیستم را اجرا نکرده‌ایم.

مرحله سوم: Development

Developer کد مربوط به Payment Service را نوشته است.

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

• Code Review
• Static Analysis
• بررسی Coding Standards
• بررسی برخی مشکلات امنیتی یا Code Smellها

را انجام داد.

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

حالا نرم‌افزار قابل اجراست.

تستر می‌تواند وارد مرحله Dynamic Testing شود و سناریوهایی مانند موارد زیر را اجرا کند:

• پرداخت موفق
• پرداخت ناموفق
• Timeout
• موجودی ناکافی
• پرداخت تکراری
• سایر سناریوهای مرتبط

پس می‌بینیم که Static Testing و Dynamic Testing در کنار یکدیگر قرار می‌گیرند، نه اینکه یکی جای دیگری را بگیرد.

۳.۳ Static Testing در Agile

در Agile شرایط کمی متفاوت است.

در Agile معمولاً به جای اینکه ابتدا همه Requirements نوشته شوند، سپس همه Designها انجام شوند و در نهایت تست شروع شود، کار در چرخه‌های کوتاه‌تر و تکرارشونده انجام می‌شود.

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

Product Backlog
      ↓
Backlog Refinement
      ↓
User Story + Acceptance Criteria
      ↓
Development
      ↓
Code Review / Static Analysis
      ↓
Dynamic Testing
      ↓
Feedback
      ↓
Improvement

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

برای مثال:

As a customer, I want to reset my password, so that I can regain access to my account.

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

• اگر Email وجود نداشته باشد چه؟
• اگر لینک Reset منقضی شده باشد چه؟
• لینک Reset چند دقیقه معتبر است؟
• آیا کاربر می‌تواند چند بار درخواست Reset ارسال کند؟
• بعد از تغییر Password، Sessionهای قبلی چه می‌شوند؟

این پرسش‌ها می‌توانند باعث شوند User Story و Acceptance Criteria قبل از Development کامل‌تر شوند.

این همان جایی است که Shift-Left اهمیت پیدا می‌کند.

۳.۴ Shift-Left Testing چیست؟

Shift-Left یعنی فعالیت‌های تست و کیفیت را تا حد امکان زودتر در چرخه توسعه انجام دهیم.

به زبان ساده:

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

مثلاً:

رویکرد سنتی‌تر:

Requirement
     ↓
Development
     ↓
Testing
     ↓
Bug
     ↓
Fix

با رویکرد Shift-Left:

Requirement
     ↓
Requirement Review
     ↓
Development
     ↓
Code Review / Static Analysis
     ↓
Dynamic Testing

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

۳.۵ آیا Shift-Left یعنی تستر باید همه کارها را انجام دهد؟

خیر. این یک سوءبرداشت رایج است.

Shift-Left به این معنی نیست که:

«Tester باید زودتر وارد شود و همه چیز را خودش تست کند.»

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

در Agile و رویکردهای مدرن، کیفیت بیشتر یک مسئولیت تیمی است. بنابراین:

• Business Analyst: می‌تواند Requirement را بررسی کند.
• Tester: می‌تواند Testability و سناریوهای مختلف را بررسی کند.
• Developer: می‌تواند Design و Code را Review کند.
• Product Owner: می‌تواند نیاز Business و Acceptance Criteria را بررسی کند.

در نتیجه:

Shift-Left بیشتر درباره زمان و نحوه توجه به کیفیت است، نه انتقال تمام مسئولیت تست به Tester.

۳.۶ Static Testing و Shift-Left چه ارتباطی دارند؟

Static Testing یکی از روش‌هایی است که به اجرای Shift-Left کمک می‌کند.

مرحله	Work Product	فعالیت
Requirements	Requirement / User Story	Review
Design	Design Document	Technical Review
Development	Source Code	Code Review / Static Analysis
Test Preparation	Test Case	Testware Review
Testing	Software	Dynamic Testing

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

برای مثال:

Requirement ناقص
        ↓
Design ناقص
        ↓
Implementation ناقص
        ↓
Test Failure / Defect

به همین دلیل Static Testing می‌تواند نقش مهمی در پیشگیری و کشف زودهنگام مشکلات داشته باشد.

۳.۷ یک نکته مهم: Static Testing فقط مخصوص Waterfall یا Agile نیست

Static Testing به یک SDLC خاص وابسته نیست.

می‌توان آن را در:

• Waterfall
• V-Model
• Agile
• DevOps
• Continuous Delivery

و سایر رویکردهای توسعه استفاده کرد.

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

«آیا در Agile Static Testing داریم؟»

یا:

«آیا Static Testing فقط در Waterfall انجام می‌شود؟»

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

در این پروژه، کدام Work Product را، در چه زمانی و با چه روشی باید Review یا تحلیل کنیم؟

این نگاه، Static Testing را از یک مفهوم صرفاً تئوری به یک فعالیت واقعی در فرایند QA تبدیل می‌کند.

جمع‌بندی بخش ۳

تا اینجا می‌توانیم جایگاه Static Testing را این‌طور خلاصه کنیم:

Static Testing می‌تواند از Requirements شروع شود، در Design و Development ادامه پیدا کند و حتی Testware را نیز پوشش دهد.

و مهم‌تر اینکه:

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

این دقیقاً یکی از ایده‌های مهم Shift-Left Testing است.

۴. چه Work Productهایی را می‌توان با Static Testing بررسی کرد؟

یکی از نکات مهم در Static Testing این است که موضوع بررسی فقط Source Code نیست.

هر محصول کاری یا Work Product که در طول توسعه نرم‌افزار تولید می‌شود، در صورت مناسب بودن برای Review یا Static Analysis، می‌تواند مورد بررسی قرار گیرد.

برای یک Tester، این موضوع اهمیت زیادی دارد؛ چون بخش قابل‌توجهی از مشکلات نرم‌افزار ممکن است قبل از رسیدن به مرحله اجرای Software، در همین Work Productها ایجاد شده باشند.

Requirements
     ↓
Design
     ↓
Source Code
     ↓
Testware
     ↓
Software

در هر یک از این مراحل، Work Productهایی تولید می‌شوند که می‌توان آن‌ها را بررسی کرد.

۴.۱ بررسی Requirements

Requirements یکی از مهم‌ترین Work Productهایی است که می‌توان با Static Testing بررسی کرد.

تستر در این مرحله هنوز Software را اجرا نمی‌کند؛ بلکه بررسی می‌کند آیا Requirementها برای ساخت و تست محصول مناسب هستند یا خیر.

برای مثال:

سیستم باید به کاربر اجازه دهد رمز عبور خود را تغییر دهد.

این Requirement از نظر مفهومی قابل فهم است، اما برای پیاده‌سازی و تست هنوز سؤال‌های زیادی وجود دارد:

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

تستر با مطرح کردن این موارد می‌تواند به شناسایی Ambiguity، Missing Information و سایر مشکلات Requirement کمک کند.

نکته مهم: تستر قرار نیست Business Requirement را به‌تنهایی تعریف کند. وظیفه تستر این است که ابهام‌ها و مشکلات قابل مشاهده را شناسایی و با افراد مسئول مطرح کند.

۴.۲ بررسی User Story

در پروژه‌های Agile، یکی از مهم‌ترین Work Productهایی که Tester با آن سروکار دارد User Story است.

As a customer,
I want to reset my password,
so that I can regain access to my account.

تستر می‌تواند قبل از Development آن را بررسی کند.

مثلاً:

آیا User Story واضح است؟

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

آیا قابل تست است؟

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

آیا Acceptance Criteria وجود دارد؟

مثلاً:

Given the user has a registered email
When the user requests a password reset
Then the system sends a reset link to the registered email

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

• Email ثبت نشده باشد.
• لینک منقضی شده باشد.
• لینک قبلاً استفاده شده باشد.
• کاربر چند بار درخواست Reset ارسال کند.

این موارد می‌توانند در Review User Story مطرح شوند.

۴.۳ بررسی Acceptance Criteria

Acceptance Criteria نیز می‌تواند تحت Static Testing قرار بگیرد.

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

Password باید حداقل ۸ کاراکتر داشته باشد.

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

• آیا دقیقاً ۸ کاراکتر مجاز است؟
• آیا Space مجاز است؟
• آیا حروف بزرگ و کوچک اهمیت دارند؟
• آیا عدد الزامی است؟
• آیا کاراکتر خاص الزامی است؟

این پرسش‌ها کمک می‌کنند Acceptance Criteria قبل از Development دقیق‌تر شود.

یک نکته مهم برای Tester: Acceptance Criteria باید تا حد امکان قابل تست باشد.

مثلاً:

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

در مقابل:

✅ سیستم باید پاسخ درخواست را در شرایط مشخص‌شده، حداکثر ظرف ۲ ثانیه ارائه کند.

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

۴.۴ بررسی Design

Static Testing فقط به Requirements محدود نمی‌شود.

وقتی تیم یک Design Document تهیه می‌کند، می‌توان آن را قبل از Implementation بررسی کرد.

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

Web Application
       ↓
Order Service
       ↓
Payment Service
       ↓
Payment Gateway

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

• اگر Payment Gateway در دسترس نباشد چه اتفاقی می‌افتد؟
• اگر درخواست ارسال شود ولی Response دریافت نشود چه؟
• آیا امکان Duplicate Payment وجود دارد؟
• آیا اطلاعات حساس به‌درستی محافظت می‌شوند؟
• آیا طراحی با Requirementهای اصلی سازگار است؟

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

۴.۵ بررسی Source Code

اینجا همان بخشی است که معمولاً وقتی درباره Static Testing صحبت می‌کنیم، سریع به ذهن می‌رسد.

Code Review

یک یا چند Developer یا فرد فنی دیگر Source Code را بررسی می‌کنند.

برای مثال:

• منطق اشتباه
• رعایت نکردن Coding Standard
• خوانایی پایین
• مشکلات طراحی
• خطاهای احتمالی

را بررسی می‌کنند.

Static Analysis

ابزار Source Code را تحلیل می‌کند و می‌تواند مواردی مانند برخی:

• Code Smellها
• Coding Standard Violationها
• مشکلات احتمالی امنیتی
• مشکلات ساختاری

را شناسایی کند.

ابزارهایی مانند SonarQube، ESLint و Pylint نمونه‌هایی از ابزارهایی هستند که می‌توانند در Static Analysis استفاده شوند.

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

Static Testing مساوی Static Analysis نیست.

Static Analysis یکی از روش‌های انجام Static Testing است و Static Testing می‌تواند فعالیت‌های انسانی مانند Review را نیز شامل شود.

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

۴.۶ بررسی Testware

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

Testware به Work Productهایی گفته می‌شود که برای فعالیت‌های تست ایجاد و استفاده می‌شوند.

برای مثال:

• Test Plan
• Test Cases
• Test Conditions
• Test Data
• Test Procedures
• Test Reports

این موارد نیز می‌توانند Review شوند.

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

Test Case: Login with valid credentials

Precondition:
User exists.

Steps:
1. Enter username
2. Enter password
3. Click Login

Expected Result:
User should be logged in.

در نگاه اول Test Case مناسب به نظر می‌رسد، اما Tester دیگری هنگام Review ممکن است متوجه شود که:

• URL یا صفحه مورد نظر مشخص نیست.
• Test Data مشخص نیست.
• Expected Result دقیق نیست.
• وضعیت Session مشخص نشده است.
• نتیجه مورد انتظار بعد از Login دقیقاً تعریف نشده است.

پس خود Test Case نیز می‌تواند قبل از Execution مورد Static Testing قرار بگیرد.

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

در پروژه‌هایی که API وجود دارد، Documentation مربوط به API نیز می‌تواند مورد بررسی قرار گیرد.

مثلاً API زیر را داریم:

POST /api/users

در Documentation نوشته شده:

Creates a new user.

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

• چه فیلدهایی Required هستند؟
• چه فیلدهایی Optional هستند؟
• فرمت Email چیست؟
• Password چه محدودیت‌هایی دارد؟
• Response Code در حالت موفق چیست؟
• در صورت Duplicate Email چه اتفاقی می‌افتد؟
• Error Response چه ساختاری دارد؟

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

این کار حتی می‌تواند روی کیفیت تست‌های بعدی API نیز تأثیر بگذارد.

۴.۸ آیا همه Work Productها باید Review شوند؟

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

Static Testing به این معنی نیست که:

«هر سندی که در پروژه تولید شد باید حتماً یک جلسه Review رسمی داشته باشد.»

نوع و میزان Review به عواملی مانند:

• Risk
• Complexity
• اهمیت Work Product
• زمان و منابع
• الزامات پروژه
• نیازهای کسب‌وکار

بستگی دارد.

مثلاً ممکن است یک تغییر کوچک در متن یک مستند داخلی فقط به یک Informal Review نیاز داشته باشد، در حالی که یک Design مهم در یک سیستم حساس ممکن است نیازمند یک Review رسمی‌تر باشد.

بنابراین در پروژه واقعی باید پرسید:

کدام Work Product ارزش Review دارد، چه چیزی باید در آن بررسی شود و چه سطحی از Formality مناسب است؟

۴.۹ یک نگاه یکپارچه از دید Tester

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

Requirement
    ↓
آیا واضح و کامل است؟
    ↓
User Story
    ↓
آیا قابل تست است؟
    ↓
Acceptance Criteria
    ↓
آیا سناریوهای اصلی و خطا مشخص شده‌اند؟
    ↓
Design
    ↓
آیا راهکار با Requirement سازگار است؟
    ↓
Source Code
    ↓
Code Review / Static Analysis
    ↓
Testware
    ↓
آیا Test Caseها درست و کامل هستند؟
    ↓
Dynamic Testing

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

جمع‌بندی بخش ۴

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

• Requirements
• User Stories
• Acceptance Criteria
• Design
• Source Code
• Testware
• API Documentation
• سایر مستندات و محصولات کاری پروژه

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

قبل از اینکه یک Work Product به مرحله بعدی منتقل شود، می‌توان آن را از نظر کیفیت، کامل بودن، سازگاری، وضوح و قابلیت تست بررسی کرد.

۵. Static Testing چگونه انجام می‌شود؟

فرآیند Static Testing، به‌ویژه زمانی که از روش Review استفاده می‌شود، باید متناسب با هدف، ریسک، پیچیدگی و میزان رسمی‌بودن Review طراحی شود. در استاندارد ISO/IEC 20246، یک فرآیند عمومی و انعطاف‌پذیر برای Review معرفی شده است که در ISTQB CTFL نیز مورد استفاده قرار می‌گیرد.

در این فرآیند، فعالیت‌های اصلی شامل Planning، Review Initiation، Individual Review، Communication and Analysis، Fixing and Reporting و Follow-up هستند. در Reviewهای رسمی‌تر، فعالیت‌ها و مستندات بیشتری موردنیاز خواهد بود.

۵.۱ Planning؛ برنامه‌ریزی Review

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

در مرحله Planning، موارد زیر مشخص می‌شوند:

• Work Product: چه چیزی قرار است بررسی شود؟ مانند User Story، SRS، Design، Source Code یا Test Case.
• Review Objective: هدف از بررسی چیست؟ برای مثال، شناسایی ابهام‌ها، بررسی کامل‌بودن نیازمندی‌ها یا ارزیابی Testability.
• Scope: کدام بخش‌های Work Product در محدوده Review قرار دارند؟
• Reviewers: چه افرادی باید Work Product را بررسی کنند؟
• Review Type: چه نوع Review با توجه به هدف، ریسک و پیچیدگی انتخاب شود؟
• Quality Characteristics: چه ویژگی‌هایی باید ارزیابی شوند؟ مانند Completeness، Correctness، Consistency و Testability.
• Entry and Exit Criteria: چه شرایطی برای شروع و پایان Review باید برقرار باشد؟
• Supporting Information: چه استانداردها، مستندات یا اطلاعات زمینه‌ای برای بررسی موردنیاز است؟
• Effort and Timeframe: چه میزان زمان و تلاش برای Review در نظر گرفته می‌شود؟

مثال عملی؛ برنامه‌ریزی Review برای تغییر رمز عبور

فرض کنید تیم قرار است User Story مربوط به تغییر رمز عبور را بررسی کند. پیش از شروع Review، لازم است موارد زیر مشخص شوند:

• آیا هدف Review، بررسی کامل‌بودن نیازمندی‌هاست یا بررسی امنیت و Testability؟
• آیا Acceptance Criteria نوشته شده است؟
• آیا قوانین امنیتی مرتبط در دسترس هستند؟
• آیا Product Owner، Developer و Tester باید در Review مشارکت کنند؟
• آیا Review به‌صورت غیررسمی انجام می‌شود یا به فرآیند رسمی‌تری نیاز دارد؟

نکته مهم: نوع و میزان رسمی‌بودن Review باید با ریسک، پیچیدگی و اهمیت Work Product متناسب باشد. همه Reviewها به یک سطح از تشریفات و مستندسازی نیاز ندارند.

۵.۲ Review Initiation؛ آغاز Review

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

فعالیت‌های اصلی این مرحله عبارت‌اند از:

• مشخص‌کردن Work Product و نسخه مورد بررسی.
• در اختیار قراردادن Work Product برای Reviewers.
• توضیح هدف، محدوده و معیارهای Review.
• اطمینان از اینکه Reviewers اطلاعات زمینه‌ای موردنیاز را در اختیار دارند.
• توضیح نقش‌ها و مسئولیت‌های افراد مشارکت‌کننده.
• مشخص‌کردن روش ثبت و مدیریت Findings.
• بررسی آمادگی Work Product برای شروع Review.

اهمیت اطلاعات زمینه‌ای

Reviewer برای بررسی دقیق یک Work Product، به‌خصوص در پروژه‌های پیچیده، ممکن است به اطلاعات و مستندات مرتبط نیاز داشته باشد؛ از جمله:

• Business Requirement
• Product Requirement
• Acceptance Criteria
• Business Rules
• Design و معماری مرتبط
• User Storyهای وابسته
• قوانین امنیتی یا قانونی
• اطلاعات مربوط به نسخه قبلی سیستم

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

Entry Criteria چیست؟

Entry Criteria شرایطی هستند که باید پیش از شروع Review برقرار باشند. برای نمونه:

• نسخه مشخصی از Work Product در دسترس باشد.
• هدف و محدوده Review مشخص شده باشد.
• افراد موردنیاز انتخاب شده باشند.
• اطلاعات و مستندات مرتبط در اختیار Reviewers قرار گرفته باشد.

Entry Criteria در همه تیم‌ها و پروژه‌ها یکسان نیست و می‌تواند بر اساس نوع Review، سطح رسمی‌بودن و شرایط سازمان تعیین شود.

۵.۳ Individual Review؛ بررسی فردی

در این مرحله، هر Reviewer به‌صورت مستقل Work Product را بررسی می‌کند. هدف این است که کیفیت Work Product ارزیابی شده و Anomalyها، Recommendationها و Questionهای احتمالی شناسایی شوند.

بررسی فردی اهمیت زیادی دارد؛ زیرا افراد مختلف با توجه به نقش، تجربه و دیدگاه خود ممکن است مشکلات متفاوتی را شناسایی کنند. برای مثال، Product Owner بیشتر بر نیاز کسب‌وکار تمرکز می‌کند، Developer به امکان پیاده‌سازی توجه دارد و Tester قابلیت تست و پوشش سناریوها را بررسی می‌کند.

موارد مهم در Individual Review از دید Tester

۱. Clarity؛ شفافیت

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

۲. Completeness؛ کامل‌بودن

• آیا همه سناریوهای مهم پوشش داده شده‌اند؟
• آیا شرایط خطا مشخص شده است؟
• آیا Business Ruleهای مرتبط نوشته شده‌اند؟
• آیا نیازمندی‌های مربوط به مجوزها و امنیت مشخص هستند؟

۳. Consistency؛ سازگاری

• آیا این Work Product با مستندات دیگر تناقض دارد؟
• آیا نام فیلدها، قوانین و مقادیر در بخش‌های مختلف یکسان هستند؟

۴. Testability؛ قابلیت تست

• آیا می‌توان براساس این نیازمندی Test Case طراحی کرد؟
• آیا Expected Result قابل‌اندازه‌گیری و قابل‌بررسی است؟
• آیا داده‌های لازم برای تست مشخص هستند؟

۵. Traceability؛ قابلیت ردیابی

• آیا این مورد به Requirement یا Business Goal مرتبط است؟
• آیا Acceptance Criteria با نیازمندی اصلی سازگار است؟
• آیا می‌توان آن را به Test Caseهای مرتبط متصل کرد؟

مثال؛ بررسی User Story مربوط به تغییر رمز عبور

نیازمندی زیر را در نظر بگیرید:

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

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

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

در این مرحله، Tester لزوماً نباید همه پرسش‌ها را به‌عنوان Bug ثبت کند. برخی موارد ممکن است به شکل Question، Missing Information، Ambiguity یا Recommendation ثبت شوند و سپس در مرحله Communication and Analysis مورد بررسی قرار بگیرند.

۵.۴ Communication and Analysis؛ ارتباط و تحلیل Findings

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

Finding به هر مسئله، پرسش، ابهام، تناقض یا نکته‌ای گفته می‌شود که در جریان Review شناسایی شده و نیازمند بررسی یا تصمیم‌گیری است.

در مرحله Communication and Analysis، تیم باید به پرسش‌های زیر پاسخ دهد:

• آیا Finding واقعاً یک مشکل محسوب می‌شود؟
• نوع Finding چیست؟
• چه اثری بر محصول یا پروژه دارد؟
• آیا نیاز به اصلاح دارد؟
• چه کسی مسئول بررسی یا اصلاح آن است؟
• آیا باید Finding ثبت، رد یا به‌عنوان ریسک پذیرفته شود؟

دسته‌بندی احتمالی Findings

نوع Finding	توضیح
Defect	وجود مشکل در Work Product
Ambiguity	وجود عبارت یا مفهوم مبهم
Missing Information	نبود اطلاعات ضروری
Inconsistency	وجود تناقض با بخش یا سند دیگر
Question	پرسشی که نیاز به پاسخ دارد
Recommendation	پیشنهادی برای بهبود Work Product

مثال؛ تحلیل یک Finding

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

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

Tester می‌تواند Finding زیر را ثبت کند:

• Category: Ambiguity / Untestable Requirement
• Finding: معیار قابل‌اندازه‌گیری برای زمان پاسخ مشخص نشده است.
• Question: حداکثر زمان قابل‌قبول پاسخ چقدر است؟
• Impact: بدون معیار مشخص، بررسی عملکرد و طراحی Expected Result دشوار خواهد بود.

پس از مطرح‌شدن Finding، ممکن است Product Owner معیار دقیق‌تری ارائه کند:

در شرایط عادی، پاسخ API باید حداکثر طی ۲ ثانیه به کاربر بازگردانده شود.

در این مثال، Finding ابتدا تحلیل شده و سپس Work Product بهبود پیدا می‌کند. بنابراین شناسایی Finding به‌تنهایی پایان کار نیست؛ بلکه باید درباره اعتبار، اثر و اقدام مناسب تصمیم‌گیری شود.

۵.۵ Fixing and Reporting؛ اصلاح و گزارش‌دهی

پس از تحلیل Findings، تصمیم‌های لازم درباره اصلاح Work Product گرفته می‌شود. همه Findings الزاماً به یک شکل مدیریت نمی‌شوند و اقدام مناسب به نوع Finding، اهمیت آن، ریسک و میزان رسمی‌بودن Review بستگی دارد.

برای هر Finding ممکن است یکی از اقدامات زیر انجام شود:

• اصلاح Work Product
• درخواست اطلاعات بیشتر
• ارجاع موضوع به صاحب نیازمندی یا Business Owner
• رد Finding در صورت نادرست‌بودن
• پذیرش ریسک یا تصمیم‌گیری برای عدم اصلاح
• ایجاد Task یا Defect در ابزار مدیریت پروژه

اطلاعات مفید برای ثبت Finding

بسته به میزان رسمی‌بودن Review، می‌توان اطلاعات زیر را ثبت کرد:

• شناسه Finding
• Work Product و نسخه آن
• محل یا بخش مربوطه
• شرح مشکل یا پرسش
• نوع Finding
• شدت یا اهمیت
• فرد مسئول
• تصمیم اتخاذشده
• وضعیت
• نتیجه اصلاح

مثال ثبت Finding

فیلد	مقدار
Work Product	Password Reset User Story
Category	Missing Information
Finding	رفتار سیستم در صورت منقضی‌شدن لینک بازیابی مشخص نشده است.
Impact	ممکن است رفتار سیستم در پیاده‌سازی و تست متفاوت باشد.
Owner	Product Owner
Action	تکمیل Acceptance Criteria

نکته: میزان گزارش‌دهی باید با نوع Review متناسب باشد. در یک Review غیررسمی ممکن است ثبت یک Comment در Jira کافی باشد؛ اما در Inspection رسمی، ثبت دقیق‌تر Findings و نتایج اهمیت بیشتری دارد.

۵.۶ Follow-up؛ پیگیری پس از Review

فرآیند Review با شناسایی Findings یا پایان جلسه تمام نمی‌شود. در مرحله Follow-up، بررسی می‌شود که اقدامات توافق‌شده انجام شده‌اند یا خیر و آیا نتایج مورد انتظار حاصل شده است.

فعالیت‌های Follow-up می‌توانند شامل موارد زیر باشند:

• بررسی اصلاح‌شدن Findings
• بررسی وضعیت Taskها یا Defectهای ثبت‌شده
• اطمینان از اینکه فرد مسئول اقدام موردنظر را انجام داده است
• بررسی اینکه اصلاح انجام‌شده مشکل جدیدی ایجاد نکرده باشد
• انجام Re-review در صورت نیاز
• به‌روزرسانی وضعیت Review

آیا همیشه Re-review لازم است؟

خیر. انجام Re-review به نوع Finding، میزان تغییرات، سطح ریسک و سیاست تیم بستگی دارد.

• اصلاح یک غلط تایپی ساده ممکن است به Re-review جداگانه نیاز نداشته باشد.
• تغییر منطق پرداخت، قوانین امنیتی یا Acceptance Criteria مهم، احتمالاً نیازمند بررسی مجدد است.

مثال؛ پیگیری اصلاح یک Requirement

در Review مربوط به انتقال وجه، مشخص می‌شود که رفتار سیستم در صورت Timeout مشخص نیست. پس از اصلاح Requirement، Tester یا سایر Reviewers باید بررسی کنند:

• آیا رفتار موردنظر به‌صورت واضح نوشته شده است؟
• آیا از ایجاد تراکنش تکراری جلوگیری می‌شود؟
• آیا Acceptance Criteria با Requirement جدید سازگار است؟
• آیا Design و Test Caseهای مرتبط نیز باید اصلاح شوند؟

بنابراین Follow-up فقط بررسی «انجام‌شدن اصلاح» نیست؛ بلکه باید مشخص شود که اصلاح، مشکل را به‌درستی برطرف کرده و اثر نامطلوبی بر بخش‌های مرتبط ایجاد نکرده است.

۵.۷ جمع‌بندی فرآیند Review در ISTQB

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

Planning
   ↓
Review Initiation
   ↓
Individual Review
   ↓
Communication and Analysis
   ↓
Fixing and Reporting
   ↓
Follow-up
   ↓
Re-review در صورت نیاز

در این فرآیند، نقش Tester فقط پیدا کردن اشتباهات نگارشی یا بررسی وجود Bug نیست. Tester باید با نگاه تحلیلی بررسی کند که آیا Work Product:

• واضح و قابل‌فهم است؟
• کامل است؟
• با سایر مستندات سازگاری دارد؟
• قابل تست است؟
• سناریوهای خطا و Boundary Conditions را پوشش می‌دهد؟
• با نیازمندی‌های کسب‌وکار و Acceptance Criteria هماهنگ است؟
• قابلیت ردیابی تا Test Case یا Requirement را دارد؟

نکته مهم مطابق رویکرد ISTQB

Review یک فرآیند واحد با میزان رسمی‌بودن ثابت نیست. شکل اجرای آن می‌تواند بر اساس Review Type، ریسک، پیچیدگی، هدف و شرایط پروژه متفاوت باشد.

همچنین Static Testing به Review محدود نمی‌شود و Static Analysis نیز یکی از روش‌های آن است. Review معمولاً بر مشارکت و تحلیل انسانی تکیه دارد، درحالی‌که Static Analysis با استفاده از ابزارها و قواعد مشخص، Work Productهایی مانند Source Code را بررسی می‌کند.

نتیجه نهایی: هدف فرآیند Review این است که مشکلات Work Product در زمان مناسب شناسایی و تحلیل شوند تا تصمیم‌گیری و اصلاح آن‌ها پیش از ایجاد هزینه یا ریسک بیشتر امکان‌پذیر باشد.

منبع این بخش

• ISTQB CTFL v4.0.1 Syllabus – Chapter 3: Static Testing

۵.۸ آیا همیشه باید یک جلسه رسمی برگزار کنیم؟

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

Static Testing می‌تواند بسیار ساده انجام شود.

حالت اول — Informal

Tester در Jira یک Comment می‌گذارد:

Acceptance Criteria does not specify the behavior when the reset link has expired.

حالت دوم — Review تیمی

Tester، BA و Developer در یک جلسه کوتاه User Story را بررسی می‌کنند.

حالت سوم — Review رسمی

برای یک Work Product مهم، فرآیند رسمی‌تری با موارد زیر انجام می‌شود:

• Planning
• نقش‌های مشخص
• Preparation
• ثبت Findings
• Follow-up

بنابراین Static Testing الزاماً به معنی برگزاری جلسه رسمی نیست.

۵.۹ Tester در Static Testing دقیقاً چه کاری انجام می‌دهد؟

اگر بخواهیم تمام این بخش را از دید شغلی یک Tester خلاصه کنیم، می‌توانیم بگوییم:

Work Product دریافت می‌شود
        ↓
آن را مطالعه می‌کنم
        ↓
ابهام‌ها را پیدا می‌کنم
        ↓
موارد ناقص را بررسی می‌کنم
        ↓
Consistency را بررسی می‌کنم
        ↓
Testability را بررسی می‌کنم
        ↓
Findings را مطرح / ثبت می‌کنم
        ↓
اصلاحات انجام می‌شود
        ↓
در صورت نیاز Re-review انجام می‌دهم

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

یک نکته مهم درباره «Defect» در Static Testing

در Static Testing ممکن است چیزی پیدا کنیم که هنوز Bug اجرایی نیست.

مثلاً:

Requirement می‌گوید «کاربر باید سریع Login شود.»

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

Login takes 5 seconds ← Bug

اما می‌توانیم بگوییم:

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

پس یکی از ارزش‌های Static Testing این است که مشکلات را قبل از تبدیل شدن به Failure یا Defect در Software شناسایی کنیم.

جمع‌بندی بخش ۵

فرآیند Static Testing را می‌توان به شکل ساده این‌گونه در ذهن داشت:

Plan ← Start ← Review ← Discuss ← Fix ← Re-review

اما میزان رسمی بودن این مراحل به نوع Review و شرایط پروژه بستگی دارد.

۶. Review چیست و چه نقشی در Static Testing دارد؟

یکی از مهم‌ترین روش‌های انجام Static Testing، بررسی یا Review کردن Work Productها است.

در Review، یک Work Product مانند Requirement، User Story، Acceptance Criteria، Design، Source Code یا Test Case توسط یک یا چند نفر بررسی می‌شود تا مشکلات، ابهام‌ها، ناسازگاری‌ها و سایر مواردی که می‌توانند کیفیت محصول را تحت تأثیر قرار دهند، شناسایی شوند.

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

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

در استاندارد ISTQB CTFL v4.0.1، Review به‌عنوان یکی از موضوعات اصلی Static Testing مطرح شده و برای آن فرآیند، نقش‌ها و انواع مختلفی در نظر گرفته شده است.

Review فقط یک جلسه نیست

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

برای مثال، ممکن است یک Tester یک User Story را به‌تنهایی بخواند و متوجه شود که یکی از Acceptance Criteriaها مبهم است. سپس این موضوع را با Business Analyst یا Product Owner مطرح کند و بعد از اصلاح، دوباره آن را بررسی کند.

این هم می‌تواند بخشی از فرآیند Review باشد.

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

بنابراین میزان رسمی بودن Review می‌تواند متفاوت باشد.

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

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

برای مثال، فرض کنید این User Story را داریم:

As a customer, I want to reset my password so that I can regain access to my account.

در نگاه اول، User Story منطقی به نظر می‌رسد؛ اما یک Tester هنگام Review ممکن است سؤالاتی مانند موارد زیر مطرح کند:

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

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

Tester با بررسی خود Requirement یا User Story، مواردی را پیدا می‌کند که ممکن است در آینده باعث Defect، ابهام، برداشت متفاوت یا مشکل در Testability شوند.

این دقیقاً همان ارزش Static Testing است: مشکل را تا حد امکان قبل از رسیدن آن به مرحله اجرای نرم‌افزار پیدا کنیم.

Review چه تفاوتی با Dynamic Testing دارد؟

Static Testing	Dynamic Testing
بدون اجرای نرم‌افزار انجام می‌شود.	با اجرای نرم‌افزار انجام می‌شود.
Work Product بررسی می‌شود.	رفتار نرم‌افزار بررسی می‌شود.
Requirement، Design، Code، Test Case و… می‌توانند بررسی شوند.	Software یا Test Object اجرا می‌شود.
هدف، پیدا کردن مشکلات در Work Product است.	هدف، بررسی رفتار واقعی سیستم و شناسایی Defectهای زمان اجراست.
می‌تواند قبل از آماده شدن نرم‌افزار انجام شود.	معمولاً به یک Test Object قابل اجرا نیاز دارد.

برای مثال، اگر Tester در User Story متوجه شود که عبارت «سیستم باید سریع پاسخ دهد» معیار مشخصی ندارد، این یک مشکل در Requirement است و می‌توان آن را در Static Testing شناسایی کرد.

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

Review چه تفاوتی با Static Analysis دارد؟

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

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

Review بیشتر بر بررسی Work Product توسط افراد و تعامل میان افراد تمرکز دارد.

در مقابل، Static Analysis معمولاً با استفاده از ابزارها برای تحلیل Work Product، به‌خصوص Source Code، انجام می‌شود.

Requirement
     ↓
   Review
     ↓
ابهام، تناقض، اطلاعات ناقص

Source Code
     ↓
Static Analysis Tool
     ↓
Code Smell / Vulnerability / Coding Issue

در یک پروژه واقعی حتی ممکن است هر دو مورد استفاده شوند.

برای مثال، یک Developer کد را با ابزار Static Analysis بررسی می‌کند و سپس یک Reviewer نیز Code Review انجام می‌دهد.

پس:

Review و Static Analysis دو مفهوم مرتبط هستند، اما یکسان نیستند.

آیا هر Review الزاماً باید رسمی و گروهی باشد؟

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

ممکن است یک Developer از Tester بخواهد:

«این User Story رو یه نگاه بنداز ببین چیزی از قلم نیفتاده.»

Tester User Story را بررسی می‌کند و چند سؤال مطرح می‌کند. این یک Review نسبتاً غیررسمی است.

در مقابل، برای یک سیستم بانکی یا یک محصول با الزامات قانونی، ممکن است Review بسیار ساختاریافته‌تر باشد و افراد مشخصی در آن نقش داشته باشند، یافته‌ها ثبت شوند و فرآیند Follow-up نیز انجام شود.

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

نقش Tester در Review چیست؟

Tester در Review الزاماً کسی نیست که فقط دنبال «Bug» بگردد.

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

برای مثال هنگام بررسی یک User Story، Tester می‌تواند به این موارد توجه کند:

• آیا Requirement واضح است؟
• آیا چیزی مبهم است؟
• آیا Acceptance Criteria کامل است؟
• آیا شرایط مرزی مشخص شده‌اند؟
• آیا حالت‌های Error مشخص شده‌اند؟
• آیا Requirement قابل تست است؟
• آیا بین بخش‌های مختلف Requirement تناقض وجود دارد؟
• آیا Requirement با نیاز Business سازگار است؟
• آیا اطلاعات موردنیاز برای طراحی Test Case وجود دارد؟

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

یک نکته مهم: Review با Inspection یکی نیست

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

Review یک مفهوم کلی‌تر است.

در ISTQB، Review Typeهای مختلفی وجود دارند که از جمله آن‌ها می‌توان به موارد زیر اشاره کرد:

• Informal Review
• Walkthrough
• Technical Review
• Inspection

بنابراین:

Inspection یک نوع Review است، نه اینکه Review و Inspection دو نام برای یک فعالیت باشند.

۷. نقش‌ها و مسئولیت‌ها در Review

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

در ISTQB، نقش‌های اصلی Review عبارت‌اند از:

• Manager
• Author
• Moderator
• Scribe
• Reviewer
• Review Leader

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

۷.۱ Manager

Manager کسی است که درباره انجام Review تصمیم می‌گیرد و منابع لازم برای آن را فراهم می‌کند.

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

• چه Work Productهایی باید Review شوند؟
• چه زمانی Review انجام شود؟
• چه افرادی در Review حضور داشته باشند؟
• چه میزان زمان برای Review اختصاص داده شود؟

در یک پروژه واقعی، این نقش می‌تواند به Project Manager، Development Manager، QA Manager یا فرد مسئول پروژه نزدیک باشد؛ اما الزاماً یکی از این عنوان‌های شغلی نیست.

مثلاً در یک پروژه بانکی ممکن است Manager تصمیم بگیرد که قبل از تأیید نهایی یک Requirement مهم، یک Review رسمی انجام شود.

۷.۲ Author

Author فردی است که Work Product مورد بررسی را ایجاد کرده است و معمولاً مسئول اصلاح مواردی است که در Review پیدا می‌شوند.

Work Product	Author احتمالی
Requirement	Business Analyst / Product Owner
User Story	Product Owner / Business Analyst
Design Document	Software Architect / Developer
Source Code	Developer
Test Case	Tester
Test Plan	Test Manager / Tester

بنابراین Author الزاماً Developer نیست.

مثلاً اگر یک Tester یک Test Case نوشته باشد و آن Test Case وارد Review شود، در آن Review، Tester می‌تواند Author باشد.

۷.۳ Reviewer

Reviewer کسی است که Work Product را بررسی می‌کند و به دنبال Anomaly، ابهام، ناسازگاری، اطلاعات ناقص یا سایر مشکلات می‌گردد.

در اینجا نقش Tester بسیار مهم می‌شود.

برای مثال، هنگام Review یک User Story، Tester می‌تواند از خودش بپرسد:

• آیا Requirement قابل تست است؟
• آیا Acceptance Criteria کامل است؟
• آیا شرایط مرزی مشخص شده‌اند؟
• آیا حالت‌های Error مشخص شده‌اند؟
• آیا Requirement با سایر Requirements تناقض دارد؟
• آیا می‌توان بر اساس این Requirement Test Case طراحی کرد؟

اما Reviewer الزاماً Tester نیست.

بسته به Work Product، افراد مختلف می‌توانند Reviewer باشند؛ برای مثال:

• Tester
• Developer
• Business Analyst
• Product Owner
• Architect
• Security Specialist
• Domain Expert

Reviewer می‌تواند یکی از اعضای پروژه، یک Subject Matter Expert یا سایر Stakeholderهای مرتبط باشد.

۷.۴ Moderator / Facilitator

Moderator یا Facilitator مسئول کمک به اجرای مؤثر Review است.

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

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

• هماهنگ کردن جلسه
• مدیریت زمان
• حفظ تمرکز جلسه
• ایجاد فضای مناسب برای بیان نظرها
• جلوگیری از تبدیل Review به بحث شخصی
• کمک به حل اختلاف‌نظرها
• اطمینان از اینکه فرآیند Review درست پیش می‌رود

مثلاً فرض کنید Developer یک Requirement را به شکل خاصی تفسیر کرده، اما Tester و Business Analyst برداشت دیگری دارند.

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

۷.۵ Scribe / Recorder

Scribe یا Recorder مسئول ثبت اطلاعات مهم Review است.

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

• Anomalyهای پیدا شده
• تصمیم‌های گرفته‌شده
• Action Itemها
• مواردی که نیاز به بررسی بیشتر دارند
• افراد مسئول انجام اقدامات بعدی

فرض کنید در Review یک User Story به این نتیجه برسیم:

Acceptance Criteria مربوط به Invalid Password باید اضافه شود.

Scribe می‌تواند این Finding یا تصمیم را ثبت کند تا بعداً فراموش نشود.

در پروژه‌های کوچک، ممکن است این نقش به‌صورت رسمی وجود نداشته باشد و مثلاً Moderator یا یکی از Reviewerها یادداشت‌ها را ثبت کند.

۷.۶ Review Leader

Review Leader مسئولیت کلی Review را بر عهده دارد.

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

برای مثال Review Leader ممکن است درباره موارد زیر تصمیم‌گیری یا هماهنگی کند:

• چه کسانی در Review حضور داشته باشند؟
• Review چه زمانی انجام شود؟
• چه نوع Reviewای مناسب است؟
• Review چگونه سازمان‌دهی شود؟
• محدوده Review چه باشد؟

به بیان ساده:

Review Leader مسئول کلی سازمان‌دهی Review است، در حالی که Moderator بیشتر بر اجرای مؤثر Review، به‌خصوص جلسه، تمرکز دارد.

۷.۷ آیا این نقش‌ها در هر پروژه جدا از هم هستند؟

خیر. این یکی از مهم‌ترین نکات عملی است.

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

Manager
   ↓
Review Leader
   ↓
Moderator
   ↓
Reviewer ← Tester
Reviewer ← Developer
Reviewer ← Business Analyst
   ↓
Scribe
   ↓
Author → اصلاح Work Product

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

Product Owner
    → Author

Senior Developer
    → Reviewer + Moderator

Tester
    → Reviewer + Scribe

بنابراین نباید تصور کنیم که برای انجام یک Review ساده حتماً باید شش نفر مختلف در تیم داشته باشیم.

در پروژه‌های کوچک، نقش‌ها می‌توانند با توجه به شرایط تیم ترکیب شوند.

۷.۸ نقش Tester در Review دقیقاً چیست؟

برای یک Tester، مهم‌ترین نقش معمولاً Reviewer است.

اما نکته مهم این است که Tester فقط به دنبال Bug نیست.

Tester می‌تواند از همان مرحله Requirement به دنبال مشکلاتی باشد که بعداً باعث ایجاد Defect یا مشکل در Testing می‌شوند.

مثلاً:

Requirement:

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

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

«سریع‌ترین زمان ممکن یعنی چند ثانیه؟»

اگر مشخص شود منظور Business این است که پاسخ باید حداکثر در ۲ ثانیه باشد، Requirement اکنون قابل اندازه‌گیری‌تر و قابل تست‌تر شده است.

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

۷.۹ این نقش‌ها در Agile و Waterfall چگونه دیده می‌شوند؟

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

SRS
 ↓
Author: Business Analyst
 ↓
Reviewers:
Tester + Developer + Architect
 ↓
Review Findings
 ↓
Fix
 ↓
Approval

ممکن است یک Review رسمی قبل از Baseline شدن SRS انجام شود.

در Agile، همین مسئولیت‌ها می‌توانند در فعالیت‌های روزمره تیم پخش شوند.

Product Owner
    ↓
توضیح User Story

Developer + Tester
    ↓
Review / Discussion

Tester
    ↓
بررسی Testability و Acceptance Criteria

Developer
    ↓
بررسی Technical Feasibility

Team
    ↓
رفع ابهام و اصلاح Story

بنابراین Agile باعث حذف Review نمی‌شود؛ بلکه Review می‌تواند در فعالیت‌های همکاری روزمره تیم ادغام شود.

جمع‌بندی بخش ۷

برای درک نقش‌ها در Review، بهتر است این تصویر ذهنی را داشته باشیم:

نقش	مسئولیت اصلی
Manager	تصمیم‌گیری درباره Review و فراهم کردن منابع
Author	ایجاد و اصلاح Work Product
Reviewer	بررسی Work Product و پیدا کردن Anomalyها
Moderator	تسهیل و مدیریت مؤثر Review
Scribe	ثبت Findings و تصمیمات
Review Leader	مسئولیت کلی سازمان‌دهی Review

و مهم‌تر از همه:

این‌ها نقش هستند، نه الزاماً Job Title.

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

۸. انواع Review در ISTQB

همه Reviewها به یک شکل انجام نمی‌شوند. گاهی یک Tester فقط چند دقیقه یک User Story را بررسی می‌کند و چند سؤال از Product Owner می‌پرسد. گاهی یک گروه از افراد متخصص یک Design را بررسی می‌کنند و درباره یک تصمیم فنی به توافق می‌رسند. در پروژه‌های حساس‌تر نیز ممکن است یک Review کاملاً رسمی، ساختاریافته و مستند انجام شود.

به همین دلیل، ISTQB چهار نوع Review را با درجات مختلف Formality معرفی می‌کند:

1. Informal Review
2. Walkthrough
3. Technical Review
4. Inspection

این Review Typeها از نظر میزان Formality، هدف، نقش افراد و نحوه اجرای Review با یکدیگر تفاوت دارند.

۸.۱ Informal Review

Informal Review ساده‌ترین و کم‌تشریفات‌ترین نوع Review است. در این نوع Review، فرآیند مشخص و رسمی الزام‌آوری وجود ندارد و معمولاً خروجی رسمی و مستندی نیز الزامی نیست.

هدف اصلی آن، پیدا کردن Anomalyها و مشکلات موجود در Work Product است.

برای مثال، فرض کنید Business Analyst یک User Story جدید نوشته و آن را در Jira قرار داده است. Tester User Story را می‌خواند و متوجه می‌شود:

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

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

مثال در Agile

در یک تیم Scrum، Tester هنگام Backlog Refinement می‌گوید:

«برای این User Story مشخص نکردیم اگر ایمیل کاربر وجود نداشته باشد چه اتفاقی می‌افتد.»

تیم درباره آن صحبت می‌کند و Acceptance Criteria اصلاح می‌شود. این می‌تواند یک Informal Review باشد.

مثال در Waterfall

فرض کنید Business Analyst نسخه اولیه SRS را برای Developer و Tester ارسال کرده است. Tester سند را مطالعه می‌کند و چند ابهام را برای Business Analyst می‌فرستد. این نیز می‌تواند یک Informal Review باشد.

ویژگی‌های اصلی Informal Review

ویژگی	Informal Review
Formality	پایین
فرآیند رسمی	الزام‌آور نیست
خروجی رسمی	الزامی نیست
هدف اصلی	پیدا کردن Anomaly
جلسه رسمی	الزامی نیست
کاربرد	بسیار رایج در فعالیت‌های روزمره تیم

بنابراین Informal Review را می‌توان یک بررسی ساده و کم‌هزینه Work Product در نظر گرفت؛ البته با این تفاوت که در چارچوب ISTQB، این فعالیت همچنان یک نوع Review محسوب می‌شود.

۸.۲ Walkthrough

در Walkthrough، برخلاف Informal Review، یک ویژگی مهم وجود دارد:

Walkthrough توسط Author هدایت می‌شود.

یعنی فردی که Work Product را ایجاد کرده، آن را برای سایر افراد توضیح می‌دهد و Review را پیش می‌برد.

فرض کنید یک Business Analyst یک SRS نوشته است. در جلسه Walkthrough، Business Analyst سند را برای اعضای تیم توضیح می‌دهد:

Business Analyst
       ↓
توضیح Requirementها
       ↓
Tester + Developer + Architect
       ↓
سؤال / Feedback / Finding
       ↓
اصلاح Work Product

هدف Walkthrough فقط پیدا کردن Defect نیست. این Review می‌تواند اهداف مختلفی داشته باشد، از جمله:

• بررسی کیفیت Work Product
• ایجاد اطمینان نسبت به Work Product
• آموزش Reviewerها
• رسیدن به Consensus
• تولید ایده‌های جدید
• کمک به Author برای بهبود Work Product
• پیدا کردن Anomalyها

Reviewerها ممکن است قبل از جلسه، Work Product را به‌صورت فردی بررسی کنند، اما این کار در Walkthrough الزامی نیست.

مثال Agile

فرض کنید Product Owner یک User Story پیچیده نوشته است. در جلسه، Product Owner Story را برای تیم توضیح می‌دهد.

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

Developer درباره رفتار سیستم توضیح می‌دهد و تیم درباره Acceptance Criteria به یک درک مشترک می‌رسد. این نمونه‌ای از کاربرد Walkthrough در یک محیط Agile است.

مثال Waterfall

فرض کنید Architect یک Design Document برای سیستم جدید آماده کرده است. او Design را برای Developerها، Testerها و سایر افراد فنی توضیح می‌دهد و اعضای تیم درباره تصمیمات موجود در Design سؤال می‌کنند. اینجا نیز Walkthrough می‌تواند برای ایجاد درک مشترک و پیدا کردن مشکلات استفاده شود.

۸.۳ Technical Review

Technical Review یک Review تخصصی‌تر است. در این نوع Review، Reviewerها باید از نظر فنی صلاحیت بررسی Work Product را داشته باشند و Review توسط Moderator هدایت می‌شود.

یکی از اهداف مهم Technical Review، رسیدن به Consensus و تصمیم‌گیری درباره مسائل فنی است.

برای مثال فرض کنید تیم در حال طراحی یک Microservice جدید است. Design پیشنهادی شامل موارد زیر است:

API Gateway
     ↓
Authentication Service
     ↓
Order Service
     ↓
Database

در Technical Review ممکن است افراد زیر حضور داشته باشند:

• Software Architect
• Senior Developer
• Tester
• Security Specialist
• Database Specialist

و درباره موضوعاتی مانند این بحث کنند:

• آیا Design از نظر فنی مناسب است؟
• آیا Security Risk وجود دارد؟
• آیا APIها Testable هستند؟
• آیا Error Handling مناسب است؟
• آیا Performance Requirementها قابل دستیابی هستند؟
• آیا Design با Architecture فعلی سازگار است؟

در اینجا هدف صرفاً پیدا کردن غلط تایپی یا یک Requirement ناقص نیست؛ بلکه ارزیابی فنی و رسیدن به تصمیم درباره مسائل Technical اهمیت زیادی دارد.

مثال Technical Review در Agile

فرض کنید تیم قصد دارد یک Feature جدید را با Event-Driven Architecture پیاده‌سازی کند. Developer یک Design پیشنهاد می‌دهد.

Architect
Developer
Tester
Security Specialist
       ↓
بررسی Design
       ↓
شناسایی Technical Issue
       ↓
بحث و تصمیم‌گیری
       ↓
Consensus

Tester نیز می‌تواند در این Review نقش داشته باشد و درباره مواردی مانند Testability، Error Handling، Integration Points، Observability و Failure Scenarios سؤال مطرح کند.

۸.۴ Inspection

Inspection رسمی‌ترین نوع Review در بین چهار نوع Review معرفی‌شده در CTFL است. Inspection از یک فرآیند ساختاریافته و کامل استفاده می‌کند و یکی از اهداف اصلی آن پیدا کردن تعداد زیادی از Anomalyها در Work Product است.

Inspection علاوه بر پیدا کردن Anomaly، می‌تواند اهداف دیگری مانند ارزیابی کیفیت، ایجاد اطمینان نسبت به Work Product، کمک به بهبود Author و جمع‌آوری Metrics برای بهبود فرآیند توسعه داشته باشد.

در Inspection معمولاً فعالیت‌های Review Process به‌صورت کامل‌تر اجرا می‌شوند:

Planning
   ↓
Review Initiation
   ↓
Individual Review
   ↓
Communication & Analysis
   ↓
Fixing & Reporting
   ↓
Follow-up

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

یک نکته مهم درباره Inspection

در Inspection، Author نمی‌تواند Review Leader یا Scribe باشد.

این نکته یکی از جزئیات مهم CTFL است و در سؤالات ISTQB نیز مورد توجه قرار می‌گیرد. تفکیک این نقش‌ها به ساختاریافته‌تر بودن Review و ثبت مستقل اطلاعات کمک می‌کند.

۸.۵ مقایسه چهار نوع Review

ویژگی	Informal Review	Walkthrough	Technical Review	Inspection
Formality	کم	متوسط	نسبتاً بالا	بسیار بالا
فرآیند تعریف‌شده	الزام‌آور نیست	دارد	دارد	کامل و رسمی
چه کسی هدایت می‌کند؟	مشخص نیست	Author	Moderator	Review Leader
Reviewer متخصص	الزامی نیست	بسته به هدف	بله، از نظر فنی	افراد منتخب و واجد شرایط
هدف اصلی	پیدا کردن Anomaly	بررسی، آموزش، Consensus و سایر اهداف	تصمیم‌گیری فنی و Consensus	پیدا کردن تعداد زیادی Anomaly
خروجی رسمی	الزامی نیست	ممکن است	معمولاً وجود دارد	دارد
Metrics	معمولاً خیر	ممکن است	ممکن است	می‌تواند برای بهبود فرآیند استفاده شود

این جدول را نباید به‌صورت یک قانون مطلق در نظر گرفت. انتخاب Review Type به شرایط پروژه، Work Product، ریسک، منابع، پیچیدگی، Criticality، الزامات قانونی و فرهنگ سازمانی بستگی دارد. حتی یک Work Product می‌تواند در مراحل مختلف با Review Typeهای متفاوت بررسی شود.

۸.۶ یک مثال واحد برای درک تفاوت چهار Review

فرض کنیم یک User Story برای Reset Password داریم. همین User Story را می‌توان با چهار رویکرد مختلف Review کرد.

Informal Review

Tester User Story را می‌خواند و به Product Owner می‌گوید:

«مشخص نکردیم لینک Reset Password چه مدت معتبر است.»

Product Owner Requirement را اصلاح می‌کند.

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

Walkthrough

Product Owner User Story را برای تیم توضیح می‌دهد. Tester سؤال می‌پرسد:

«اگر کاربر دوباره درخواست Reset Password بدهد چه اتفاقی می‌افتد؟»

Developer درباره رفتار سیستم توضیح می‌دهد و تیم درباره Acceptance Criteria به توافق می‌رسد. Author هدایت‌کننده Review است.

Technical Review

برای بررسی Technical Design مربوط به Password Reset، Developer، Architect، Tester و Security Specialist حضور دارند. موضوعاتی مانند Token expiration، Authentication، Security، API behavior و Error handling بررسی می‌شوند.

تمرکز اصلی روی مسائل فنی و تصمیم‌گیری Technical است.

Inspection

فرض کنید Password Reset بخشی از یک سیستم بانکی حساس است. Requirementها و Design باید با یک فرآیند رسمی بررسی شوند. افراد مشخصی به‌عنوان Reviewer انتخاب می‌شوند، افراد قبل از جلسه Work Product را مطالعه می‌کنند، Findings ثبت می‌شوند، جلسه برگزار می‌شود، اصلاحات انجام می‌شوند و Follow-up صورت می‌گیرد.

اینجا Review بسیار رسمی و ساختاریافته است.

۸.۷ آیا Review Typeها بر اساس Waterfall و Agile انتخاب می‌شوند؟

خیر. نباید تصور کنیم مثلاً:

Waterfall = Inspection
Agile = Informal Review

چنین قاعده‌ای در ISTQB وجود ندارد. نوع Review به نیاز و شرایط Review بستگی دارد، نه صرفاً به اینکه پروژه Agile است یا Waterfall.

برای مثال در Agile ممکن است Informal Review برای یک User Story، Walkthrough برای یک Design، Technical Review برای یک Architecture Decision و حتی در شرایط مناسب Inspection رسمی برای یک Work Product حساس انجام شود.

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

مفاهیم Static Testing و Review در CTFL مستقل از یک SDLC خاص مطرح می‌شوند و می‌توانند در رویکردهای مختلف توسعه به کار روند.

جمع‌بندی

Review
│
├── Informal Review
│   └── ساده و کم‌تشریفات
│
├── Walkthrough
│   └── هدایت‌شده توسط Author
│
├── Technical Review
│   └── Reviewerهای فنی + Moderator
│
└── Inspection
    └── رسمی و ساختاریافته

چهار Review Type اصلی که در CTFL باید بشناسیم عبارت‌اند از Informal Review، Walkthrough، Technical Review و Inspection.

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

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

۹. فرآیند Review از Planning تا Follow-up

تا اینجا با مفهوم Review، نقش‌های مختلف و چهار نوع Review در ISTQB آشنا شدیم. حالا سؤال مهم این است:

یک Review در عمل چگونه انجام می‌شود؟

ISTQB CTFL v4.0.1 یک فرآیند عمومی و قابل تنظیم برای Review معرفی می‌کند که بر اساس ISO/IEC 20246 تعریف شده است. این فرآیند بسته به میزان Formality می‌تواند ساده یا بسیار ساختاریافته باشد. همچنین ممکن است برای یک Work Product بزرگ، فرآیند Review در چند مرحله تکرار شود.

پنج فعالیت اصلی Review در CTFL عبارت‌اند از Planning، Review Initiation، Individual Review، Communication & Analysis و Fixing & Reporting. علاوه بر این، در صورت نیاز ممکن است Follow-up یا Re-review برای بررسی اقدامات انجام‌شده صورت گیرد.

Planning
    ↓
Review Initiation
    ↓
Individual Review
    ↓
Communication & Analysis
    ↓
Fixing & Reporting
    ↓
Follow-up / Re-review

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

۹.۱ Planning؛ برنامه‌ریزی Review

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

• هدف Review چیست؟
• چه Work Productای باید بررسی شود؟
• کدام بخش‌های Work Product در محدوده Review هستند؟
• چه Quality Characteristicهایی باید بررسی شوند؟
• چه استانداردها یا مستنداتی باید مورد استفاده قرار گیرند؟
• چه افرادی باید در Review حضور داشته باشند؟
• چه نقشی دارند؟
• چه زمانی برای Review در نظر گرفته می‌شود؟
• چه مقدار Effort مورد نیاز است؟
• معیار پایان Review چیست؟

ISTQB در CTFL v4.0.1 این موارد را در فعالیت Planning مطرح می‌کند.

مثال

فرض کنیم قرار است User Story مربوط به Reset Password را Review کنیم.

مورد	تصمیم نمونه
Work Product	User Story + Acceptance Criteria
هدف	بررسی کامل بودن، واضح بودن و Testability نیازمندی
Reviewerها	Tester، Developer، Product Owner
تمرکز Tester	Testability، Error Conditions، Boundary Conditions، Missing Acceptance Criteria و Ambiguity

در یک Review غیررسمی ممکن است همه این موارد به‌صورت شفاهی و ساده انجام شوند، اما در یک Inspection رسمی، Planning می‌تواند بسیار دقیق‌تر و مستندتر باشد.

۹.۲ Review Initiation؛ آماده‌سازی برای Review

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

• آیا همه Reviewerها به Work Product دسترسی دارند؟
• آیا نسخه صحیح سند در اختیار آن‌هاست؟
• آیا Reviewerها نقش خود را می‌دانند؟
• آیا هدف و محدوده Review مشخص است؟
• آیا Checklist یا سایر اطلاعات مورد نیاز در اختیار Reviewerها قرار گرفته است؟
• آیا اطلاعات لازم برای انجام Review موجود است؟

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

برای مثال، فرض کنید Tester قرار است User Story شماره US-245 را Review کند. اگر Tester نسخه قدیمی User Story را دریافت کرده باشد، نتیجه Review می‌تواند بی‌اعتبار شود.

User Story: US-245
Version: 1.3
Status: Ready for Review
Reviewer: Tester
Scope: Story + Acceptance Criteria

در Reviewهای رسمی‌تر، این آماده‌سازی اهمیت بیشتری پیدا می‌کند.

۹.۳ Individual Review؛ بررسی فردی

حالا هر Reviewer Work Product را به‌صورت مستقل بررسی می‌کند. این مرحله یکی از مهم‌ترین قسمت‌های Review است.

• مقایسه Work Product با Requirementهای مرتبط
• بررسی Acceptance Criteria
• شناسایی ابهام‌ها و اطلاعات ناقص
• پیدا کردن ناسازگاری‌ها
• بررسی Testability
• در نظر گرفتن شرایط مرزی
• بررسی حالت‌های Error
• استفاده از Checklist یا Review Technique در صورت نیاز

در این مرحله Reviewer می‌تواند مواردی مانند Anomalies، Recommendations و Questions را ثبت کند.

مثلاً:

Finding	نوع مسئله
مدت اعتبار Reset Link مشخص نیست	Missing Information
رفتار سیستم برای Email نامعتبر مشخص نیست	Missing Scenario
تعداد دفعات درخواست Reset مشخص نیست	Ambiguity
شرایط Password جدید مشخص نیست	Missing Requirement
رفتار Sessionهای قبلی مشخص نیست	Question

در این مرحله Tester هنوز الزاماً نمی‌گوید «این یک Bug است». بلکه می‌گوید:

«این Work Product یک Finding دارد که باید بررسی شود.»

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

۹.۴ Communication & Analysis؛ ارتباط و تحلیل Findings

بعد از اینکه Reviewerها بررسی فردی خود را انجام دادند، Findings باید با یکدیگر مطرح و تحلیل شوند. این مرحله ممکن است در قالب یک Review Meeting انجام شود، اما الزاماً تمام Reviewها به جلسه رسمی نیاز ندارند.

هدف این مرحله این است که مشخص شود هر Finding دقیقاً چیست و چه اقدامی باید درباره آن انجام شود.

Tester:
"Reset Link expiration مشخص نشده."

Product Owner:
"منظور Business، 15 دقیقه است."

Developer:
"از نظر Implementation مشکلی ندارد."

Team:
"Acceptance Criteria اصلاح شود."

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

آیا هر Finding یک Defect است؟

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

فرض کنید Tester این جمله را در Requirement پیدا کند:

The system should respond quickly.

Tester می‌پرسد: «Quickly یعنی چند ثانیه؟»

این یک Finding است، اما هنوز نمی‌توان گفت یک Software Defect پیدا شده است؛ چون ممکن است هنوز اصلاً نرم‌افزاری ساخته نشده باشد.

پس Finding می‌تواند شامل مواردی مانند Defect، Question، Ambiguity، Recommendation یا Missing Information باشد.

۹.۵ Fixing & Reporting؛ اصلاح و گزارش‌دهی

بعد از تحلیل Findings، مواردی که نیاز به اصلاح دارند باید پیگیری شوند.

Finding:
Reset Link expiration مشخص نیست.

Action:
Acceptance Criteria اصلاح شود.

Owner:
Product Owner

Status:
Open

بعد از اصلاح:

Acceptance Criteria:
The reset link shall expire after 15 minutes.

در پروژه واقعی ممکن است این موارد در ابزارهایی مانند Jira، Azure DevOps یا ابزار مدیریت مستندات ثبت و پیگیری شوند.

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

۹.۶ Follow-up / Re-review؛ پیگیری و بررسی مجدد

بعد از اصلاح Work Product ممکن است نیاز باشد دوباره آن را بررسی کنیم.

فرض کنید Tester در Review اولیه متوجه شده:

Password باید حداقل ۸ کاراکتر داشته باشد.

Product Owner Requirement را اصلاح کرده است. حالا Tester باید بررسی کند که اصلاح واقعاً انجام شده و Requirement جدید نیز مشکل دیگری ایجاد نکرده است.

Initial Review
      ↓
Finding
      ↓
Fix
      ↓
Re-review
      ↓
Accepted

این همان جایی است که Re-review اهمیت پیدا می‌کند. در Reviewهای رسمی‌تر، Follow-up می‌تواند بخش مهمی از فرآیند باشد؛ مخصوصاً زمانی که Findings زیادی وجود داشته باشد یا اصلاحات انجام‌شده نیاز به تأیید داشته باشند.

۹.۷ یک مثال کامل از Review یک User Story

مرحله اول: Planning

هدف:
بررسی کیفیت Requirement

Reviewer:
Tester + Developer

Work Product:
User Story + Acceptance Criteria

مرحله دوم: Review Initiation

Tester نسخه نهایی User Story را دریافت می‌کند و Checklist مربوط به Requirement Review را در اختیار دارد.

مرحله سوم: Individual Review

Tester User Story را مطالعه می‌کند و متوجه می‌شود:

Reset Link expiration مشخص نشده است.

همچنین متوجه می‌شود رفتار سیستم در صورت استفاده مجدد از Reset Link مشخص نیست. Tester این موارد را ثبت می‌کند.

مرحله چهارم: Communication & Analysis

Tester:
مدت اعتبار لینک Reset مشخص نشده.

Product Owner:
لینک باید ۱۵ دقیقه معتبر باشد.

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

Team:
Acceptance Criteria اصلاح شود.

مرحله پنجم: Fixing & Reporting

Product Owner User Story را اصلاح می‌کند:

Acceptance Criteria:

1. The reset link shall expire after 15 minutes.
2. A reset link can only be used once.
3. An expired reset link shall not allow password reset.

مرحله ششم: Follow-up / Re-review

Tester نسخه جدید User Story را بررسی می‌کند. حالا Requirementها واضح‌تر و قابل تست‌تر هستند. Tester بررسی می‌کند که Findingهای قبلی برطرف شده‌اند و اگر مورد جدیدی ایجاد نشده باشد، Review برای این بخش خاتمه پیدا می‌کند.

۹.۸ Review Process در یک نگاه

1. برنامه‌ریزی
       ↓
2. آماده شدن برای Review
       ↓
3. مطالعه و بررسی Work Product
       ↓
4. پیدا کردن Findings
       ↓
5. مطرح کردن و تحلیل Findings
       ↓
6. اصلاح Work Product
       ↓
7. بررسی مجدد در صورت نیاز
       ↓
8. پایان Review

پس Review صرفاً این نیست که «یک سند را بخوانیم و بگوییم خوب است یا بد.» بلکه یک فرآیند مشخص برای پیدا کردن، تحلیل، اصلاح و پیگیری مشکلات Work Product است.

نکته مهم برای Tester

از دید یک Tester، ارزش Review در این است که قبل از اینکه Requirement به Test Case، کد و در نهایت نرم‌افزار تبدیل شود، بتوانیم مشکل را شناسایی کنیم.

Requirement اشتباه
       ↓
Design اشتباه
       ↓
Code اشتباه
       ↓
Test Case اشتباه
       ↓
Defect

اما با Static Testing و Review می‌توانیم بخشی از این مشکلات را زودتر متوقف کنیم:

Requirement
       ↓
Review
       ↓
Finding
       ↓
Fix
       ↓
Requirement بهتر
       ↓
Design / Code / Test بهتر

به همین دلیل، Review یکی از فعالیت‌های مهم در رویکرد Shift-Left Testing محسوب می‌شود؛ زیرا امکان شناسایی مشکلات کیفیتی را پیش از اجرای نرم‌افزار فراهم می‌کند. Feedback زودهنگام و مکرر نیز می‌تواند به جلوگیری از سوءتفاهم‌های Requirement و کاهش Rework کمک کند.

۱۰. مثال عملی؛ بررسی یک User Story از دید Tester

تا اینجا با مفهوم Static Testing، Review، نقش‌ها، انواع Review و Review Process آشنا شدیم. حالا می‌خواهیم ببینیم یک Tester در یک پروژه واقعی چگونه از Static Testing استفاده می‌کند.

برای این کار، یک User Story مربوط به تغییر رمز عبور (Change Password) را در نظر می‌گیریم.

هدف این مثال فقط پیدا کردن چند ایراد از User Story نیست؛ بلکه می‌خواهیم ببینیم Tester چگونه از مرحله دریافت Requirement تا اصلاح آن، به کیفیت Work Product کمک می‌کند.

۱۰.۱ User Story اولیه

فرض کنید Product Owner این User Story را نوشته است:

As a registered user, I want to change my password so that I can keep my account secure.

Acceptance Criteria اولیه به شکل زیر است:

Acceptance Criteria:

1. The user can change their password.
2. The new password must be valid.
3. The system should show a success message after changing the password.

در نگاه اول Requirement منطقی به نظر می‌رسد، اما آیا این User Story برای شروع Development و Testing کافی است؟

نه لزوماً. اینجاست که Static Testing و Review اهمیت پیدا می‌کنند.

۱۰.۲ Tester در Review به چه چیزهایی توجه می‌کند؟

Tester هنگام بررسی این User Story فقط به این سؤال نگاه نمی‌کند که «آیا جمله User Story درست نوشته شده؟» بلکه از دید Quality و Testability آن را بررسی می‌کند.

آیا Requirement واضح است؟

عبارت The new password must be valid. سؤال ایجاد می‌کند: Valid یعنی چه؟

آیا Password باید:

• حداقل ۸ کاراکتر داشته باشد؟
• حداقل یک حرف بزرگ داشته باشد؟
• حداقل یک عدد داشته باشد؟
• حداقل یک Symbol داشته باشد؟

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

آیا Requirement کامل است؟

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

این موارد می‌توانند روی طراحی Test Caseها تأثیر مستقیم داشته باشند.

آیا شرایط Error مشخص شده‌اند؟

Acceptance Criteria فقط حالت موفق را بیان کرده است، اما درباره حالت‌های ناموفق چیزی نمی‌گوید.

• اگر Current Password اشتباه باشد چه؟
• اگر New Password نامعتبر باشد چه؟
• اگر Confirm Password متفاوت باشد چه؟
• اگر Session کاربر منقضی شده باشد چه؟

۱۰.۳ Findings که Tester پیدا می‌کند

فرض کنیم Tester بررسی خود را انجام داده و موارد زیر را پیدا کرده است:

#	Finding	نوع مسئله
1	قوانین Password مشخص نیست	Missing Information / Ambiguity
2	رفتار سیستم برای Current Password اشتباه مشخص نیست	Missing Scenario
3	مشخص نشده New Password می‌تواند با Password قبلی یکسان باشد یا خیر	Missing Requirement
4	رفتار سیستم برای عدم تطابق New Password و Confirm Password مشخص نیست	Missing Scenario
5	رفتار سیستم بعد از Session Expiration مشخص نیست	Missing Scenario
6	فقط Success Scenario تعریف شده است	Incomplete Acceptance Criteria

نکته مهم این است که Tester در این مرحله لزوماً همه این موارد را به‌عنوان Bug ثبت نمی‌کند. این‌ها ابتدا Review Findings هستند و بعد از بررسی و تحلیل، تیم تصمیم می‌گیرد کدام موارد باید اصلاح شوند.

۱۰.۴ مطرح کردن Findings

حالا Tester Findings را با Product Owner و سایر اعضای تیم مطرح می‌کند.

Tester:
در Acceptance Criteria گفته شده Password باید Valid باشد،
اما مشخص نشده Valid دقیقاً یعنی چه.

Product Owner:
Password باید حداقل ۸ کاراکتر داشته باشد و حداقل یک عدد
و یک حرف بزرگ داشته باشد.

Tester:
اگر Current Password اشتباه وارد شود چه اتفاقی باید بیفتد؟

Product Owner:
باید پیام خطای مناسب نمایش داده شود و Password تغییر نکند.

Developer:
آیا کاربر می‌تواند Password قبلی خودش را دوباره انتخاب کند؟

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

۱۰.۵ Acceptance Criteria اصلاح‌شده

Acceptance Criteria:

1. The user must enter their current password.

2. The current password must be verified before changing
   the password.

3. The new password must:
   - contain at least 8 characters
   - contain at least one uppercase letter
   - contain at least one number

4. The new password must be different from the current password.

5. The new password and confirmation password must match.

6. If the current password is incorrect, the password must not
   be changed and an appropriate error message must be displayed.

7. If the new password does not meet the password policy,
   the password must not be changed.

8. If the new password and confirmation password do not match,
   the password must not be changed.

9. After a successful password change, the system must display
   a success message.

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

۱۰.۶ Tester بعد از اصلاح چه می‌کند؟

کار Tester با اصلاح Requirement تمام نمی‌شود. Tester باید بررسی کند که Findings قبلی واقعاً برطرف شده‌اند.

Finding #1
Password rules are unclear
        ↓
Fixed
        ↓
Tester Re-review
        ↓
Accepted

همین فرآیند برای سایر Findings نیز انجام می‌شود. اگر هنوز مسئله‌ای باقی مانده باشد، Review ادامه پیدا می‌کند.

۱۰.۷ از همین Requirement چه Test Caseهایی می‌توان ساخت؟

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

Scenario	Expected Result
Current Password صحیح	امکان تغییر Password
Current Password اشتباه	Password تغییر نکند
Password کمتر از ۸ کاراکتر	Password تغییر نکند
Password بدون Uppercase	Password تغییر نکند
Password بدون Number	Password تغییر نکند
New Password مشابه Current Password	Password تغییر نکند
New Password و Confirmation متفاوت	Password تغییر نکند
تمام شرایط صحیح	Password با موفقیت تغییر کند

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

هرچه Requirement واضح‌تر و Testableتر باشد، طراحی و اجرای تست نیز قابل‌اعتمادتر می‌شود.

۱۰.۸ Static Testing چگونه جلوی هزینه‌های بعدی را می‌گیرد؟

فرض کنیم Requirement اولیه بدون Review وارد Development شود. Developer ممکن است برداشت خودش را از Password Policy داشته باشد. مثلاً تصور کند حداقل ۶ کاراکتر کافی است.

Requirement
     ↓
Development
     ↓
Testing
     ↓
Finding
     ↓
Requirement Clarification
     ↓
Code Change
     ↓
Retest
     ↓
Regression Testing

یعنی یک ابهام ساده در Requirement می‌تواند باعث Rework در چند مرحله شود.

اما اگر همان ابهام در Review شناسایی شود:

Requirement
     ↓
Review
     ↓
Ambiguity Found
     ↓
Requirement Fix
     ↓
Development

مشکل بسیار زودتر برطرف می‌شود. این یکی از دلایل اصلی اهمیت Static Testing و Shift-Left است.

۱۰.۹ آیا Static Testing جای Dynamic Testing را می‌گیرد؟

خیر. حتی اگر Requirement را خوب Review کنیم، باز هم به Dynamic Testing نیاز داریم.

در مثال Password:

• Static Testing می‌تواند کامل بودن Requirement، مشخص بودن قوانین Password، Testability و تعریف Error Scenarioها را بررسی کند.
• Dynamic Testing باید بررسی کند که سیستم واقعاً Password را طبق این قوانین تغییر می‌دهد، Password نامعتبر را Reject می‌کند، Error Message درست نمایش داده می‌شود، API رفتار صحیح دارد و Database به‌درستی Update می‌شود.

Requirement
    ↓
Static Testing / Review
    ↓
Requirement Fix
    ↓
Development
    ↓
Dynamic Testing
    ↓
Defect Detection
    ↓
Fix
    ↓
Retest
    ↓
Regression Testing

۱۰.۱۰ این مثال در Agile چگونه اتفاق می‌افتد؟

در یک تیم Agile، چنین Reviewای می‌تواند حتی قبل از شروع Sprint Development اتفاق بیفتد. برای مثال در Backlog Refinement:

Product Owner
      ↓
User Story
      ↓
Tester + Developer
      ↓
Review / Discussion
      ↓
Questions & Findings
      ↓
Story Refinement
      ↓
Ready for Development

Tester از دید Testability به User Story نگاه می‌کند، Developer از دید Technical Feasibility سؤال مطرح می‌کند و Product Owner نیز Business Requirement را توضیح می‌دهد. در نتیجه، تیم قبل از شروع Development به درک مشترک‌تری از Requirement می‌رسد.

۱۰.۱۱ این مثال در Waterfall چگونه خواهد بود؟

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

Business Requirements
        ↓
SRS
        ↓
Review
        ↓
Finding
        ↓
SRS Correction
        ↓
Approval / Baseline
        ↓
Design
        ↓
Development
        ↓
Testing

در این مدل، Review می‌تواند در مرحله Requirement یا Design انجام شود؛ یعنی خیلی قبل‌تر از اجرای تست نرم‌افزار. بنابراین Static Testing به یک SDLC خاص محدود نیست.

جمع‌بندی مثال

در این مثال، Tester قبل از اجرای نرم‌افزار توانست مواردی مانند Requirementهای ناقص، ابهام، Missing Scenario، Acceptance Criteria ناقص و مشکلات Testability را شناسایی کند.

سپس این Findings با تیم مطرح شدند، Requirement اصلاح شد و بعد از Re-review، Work Product برای مراحل بعدی آماده‌تر شد.

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

Understand
    ↓
Review
    ↓
Question
    ↓
Find
    ↓
Discuss
    ↓
Improve
    ↓
Re-review

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

۱۱. Static Testing و Defect Management

یکی از سؤال‌های مهم هنگام یادگیری Static Testing این است:

«اگر Tester در Review یک مشکل پیدا کند، آیا باید آن را به‌عنوان Bug ثبت کند؟»

لزوماً نه. در Static Testing ممکن است یک Anomaly در Requirement، Design، Source Code یا Testware پیدا شود. این مورد باید بررسی و تحلیل شود تا مشخص شود دقیقاً چه نوع مسئله‌ای است و چه اقدامی باید درباره آن انجام شود.

موارد گزارش‌شده به‌عنوان Anomaly ممکن است در نهایت Defect واقعی نباشند و حتی به مواردی مانند False Positive یا Change Request تبدیل شوند.

۱۱.۱ Anomaly چیست؟

در ساده‌ترین حالت، Anomaly یعنی چیزی که هنگام بررسی Work Product غیرعادی، مشکوک یا مشکل‌دار به نظر می‌رسد و نیاز به بررسی بیشتر دارد.

برای مثال Tester هنگام Review یک Requirement می‌بیند:

The system should respond quickly.

Tester سؤال می‌کند: «Quickly یعنی چه مقدار زمان؟»

در این مرحله یک Finding / Anomaly داریم، اما هنوز نمی‌توان گفت «یک Bug در نرم‌افزار پیدا شد»، چون ممکن است هنوز حتی یک خط کد برای این Requirement نوشته نشده باشد.

۱۱.۲ Finding چه زمانی به Defect تبدیل می‌شود؟

فرض کنیم Tester این مورد را در Review مطرح می‌کند. Product Owner توضیح می‌دهد:

منظور Business این بوده که Response Time حداکثر ۲ ثانیه باشد.

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

Finding / Anomaly
       ↓
Analysis
       ↓
Classification
       ↓
Defect / Change Request / False Positive / Other

۱۱.۳ Defect در Static Testing می‌تواند در Requirement باشد

یک تصور اشتباه این است که Defect فقط در Source Code وجود دارد. در حالی که Defect می‌تواند در Work Productهای مختلف وجود داشته باشد.

Requirement Defect

The system should allow users to login quickly.

مشکل: «Quickly» قابل اندازه‌گیری نیست.

Design Defect

در Design، یک Database Structure نامناسب انتخاب شده که می‌تواند باعث مشکلات Performance یا Scalability شود.

Code Defect

در Source Code ممکن است مواردی مانند Variable تعریف‌نشده، Unreachable Code، Duplicate Code یا Complexity بیش از حد وجود داشته باشد. برخی از این موارد را می‌توان با Static Analysis زودتر شناسایی کرد.

۱۱.۴ Defect Report فقط برای Dynamic Testing نیست

وقتی درباره Defect Report صحبت می‌کنیم، معمولاً ذهنمان به یک Bug Report مربوط به تست نرم‌افزار می‌رود. اما Anomalyهای Static Testing نیز می‌توانند وارد فرآیند Defect Management شوند.

Title:
Password policy is not defined in the User Story

Work Product:
US-245

Finding:
The requirement states that the password must be valid,
but the password policy is not defined.

Impact:
Test cases cannot be designed unambiguously.

Suggested Action:
Define password policy in the Acceptance Criteria.

اینجا هنوز نرم‌افزار اجرا نشده است، اما یک مشکل واقعی در Work Product شناسایی شده است. در عمل، Defectهای شناسایی‌شده از Static Testing نیز می‌توانند با فرآیند مشابهی نسبت به Defectهای دیگر مدیریت و پیگیری شوند.

۱۱.۵ فرآیند Defect Management چگونه به Static Testing مرتبط می‌شود؟

فرآیند کلی را می‌توان این‌گونه دید:

Anomaly Found
      ↓
Log
      ↓
Analyze
      ↓
Classify
      ↓
Decide on Action
      ↓
Fix / Accept / Change Request / Other
      ↓
Close

این فرآیند به نوع SDLC و فرآیند مدیریت Defect سازمان بستگی دارد. برای مثال، در یک تیم ممکن است Finding مربوط به Requirement مستقیماً در Jira به‌عنوان Task ثبت شود و در تیم دیگر همان Finding به‌عنوان Defect ثبت شود.

بنابراین ابزار و نام Statusها ممکن است متفاوت باشند، اما اصل فرآیند مشابه است: Finding باید بررسی، درباره آن تصمیم‌گیری و سپس پیگیری شود.

۱۱.۶ مثال واقعی؛ از Finding تا Defect

به مثال Password Reset برگردیم. Tester هنگام Review این مورد را پیدا می‌کند:

Password must be valid.

Tester سؤال می‌کند: «Valid Password یعنی چه؟»

مرحله اول: Finding

Finding:
Password validation rules are not defined.

مرحله دوم: Analysis

Product Owner توضیح می‌دهد که Password باید حداقل ۸ کاراکتر، یک حرف بزرگ و یک عدد داشته باشد. حالا مشخص شده که Requirement واقعاً ناقص بوده است.

مرحله سوم: Classification

تیم تصمیم می‌گیرد این مورد به‌عنوان Requirement Defect ثبت شود.

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

The password must:
- contain at least 8 characters
- contain at least one uppercase letter
- contain at least one number

مرحله پنجم: Re-review

Tester دوباره Requirement را بررسی می‌کند. اگر مورد دیگری وجود نداشته باشد:

Finding
   ↓
Requirement Defect
   ↓
Fix
   ↓
Re-review
   ↓
Closed

۱۱.۷ آیا Static Testing می‌تواند Defect را مستقیماً پیدا کند؟

بله. در Static Testing می‌توان Defect را مستقیماً در Work Product شناسایی کرد.

مثلاً:

Requirement:
"The user can delete any account."

Tester متوجه می‌شود این Requirement با Security Policy سازمان تناقض دارد. در این حالت Defect در خود Requirement قابل مشاهده است.

اما در Dynamic Testing معمولاً نرم‌افزار را اجرا می‌کنیم، یک Failure مشاهده می‌کنیم و سپس با تحلیل Failure به Defect مربوطه می‌رسیم.

Static Testing

Work Product
     ↓
Defect

Dynamic Testing

Software Execution
     ↓
Failure
     ↓
Analysis
     ↓
Defect

۱۱.۸ آیا هر Defectی را می‌توان با Static Testing پیدا کرد؟

خیر. Static و Dynamic Testing مکمل یکدیگر هستند.

Static Testing در پیدا کردن برخی مشکلات مناسب است، مانند:

• Requirementهای مبهم
• Requirementهای متناقض
• Requirementهای ناقص
• برخی Design Defectها
• برخی Coding Defectها
• نقض Coding Standard
• برخی مشکلات ساختاری در Testware

در مقابل، Dynamic Testing برای مواردی مانند رفتار نادرست در Runtime، مشکلات Integration، مشکلات Performance در شرایط واقعی اجرا، مشکلات UI، مشکلات API هنگام اجرا و مشکلاتی که فقط در شرایط خاص Runtime ظاهر می‌شوند اهمیت زیادی دارد.

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

۱۱.۹ Static Testing و Shift-Left

یکی از مهم‌ترین مزایای ارتباط Static Testing با Defect Management، پیدا کردن مشکلات در مراحل ابتدایی SDLC است.

Requirement
    ↓
Design
    ↓
Development
    ↓
Testing
    ↓
Defect
    ↓
Rework

اما اگر Static Testing در همان مرحله Requirement انجام شود:

Requirement
    ↓
Review
    ↓
Defect Found
    ↓
Requirement Fix
    ↓
Development

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

۱۱.۱۰ یک نکته مهم درباره Severity و Priority

بعد از شناسایی Defect، ممکن است لازم باشد مواردی مانند Severity و Priority نیز مشخص شوند.

Requirement Defect:
Password policy is missing

ممکن است این مورد از نظر Business بسیار مهم باشد و لازم باشد قبل از شروع Development اصلاح شود. در مقابل، یک ابهام جزئی در متن یک Requirement ممکن است تأثیر بسیار کمتری داشته باشد.

بنابراین همه Findings اهمیت یکسانی ندارند. نحوه تعیین Severity و Priority نیز به فرآیند Defect Management سازمان بستگی دارد و ممکن است بین پروژه‌ها متفاوت باشد.

۱۱.۱۱ چرا Defect Management برای Static Testing مهم است؟

اگر Findingهای Static Testing فقط در جلسه مطرح شوند و بعد فراموش شوند، بخش مهمی از ارزش Static Testing از بین می‌رود.

• Finding را ثبت کنیم.
• آن را تحلیل کنیم.
• مسئول اصلاح را مشخص کنیم.
• وضعیت آن را پیگیری کنیم.
• اصلاح را بررسی کنیم.
• در صورت نیاز Re-review انجام دهیم.
• در نهایت آن را Close کنیم.

به همین دلیل Static Testing و Defect Management در عمل ارتباط بسیار نزدیکی دارند.

جمع‌بندی

Static Testing
      ↓
Finding / Anomaly
      ↓
Analysis
      ↓
Classification
      ↓
Defect / Change Request / False Positive / Other
      ↓
Action
      ↓
Fix / Accept / Change
      ↓
Follow-up / Re-review
      ↓
Closure

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

هر چیزی که در Review پیدا می‌شود، لزوماً از همان ابتدا یک Bug نیست؛ ابتدا یک Finding یا Anomaly است که باید تحلیل و طبقه‌بندی شود.

همچنین Static Testing فقط برای پیدا کردن مشکلات Requirement نیست. می‌تواند روی Design، Source Code و Testware نیز انجام شود و در بسیاری از موارد، مشکلات را قبل از اجرای نرم‌افزار آشکار کند.

در نتیجه، Defect Management فقط فعالیتی برای Bugهایی که بعد از اجرای نرم‌افزار پیدا می‌شوند نیست؛ Anomalyهای حاصل از Static Testing نیز باید به شکل مناسبی مدیریت و پیگیری شوند.

۱۲. Static Testing در مقابل Dynamic Testing

یکی از رایج‌ترین اشتباهات در یادگیری Software Testing این است که Static Testing و Dynamic Testing را دو روش کاملاً جدا و رقیب یکدیگر در نظر بگیریم. در واقع، این دو رویکرد مکمل یکدیگر هستند.

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

تفاوت اصلی این است:

در Static Testing، Work Product بدون اجرای Software بررسی می‌شود؛ در Dynamic Testing، Software یا Test Object اجرا می‌شود تا رفتار واقعی آن بررسی شود.

۱۲.۱ تفاوت اصلی در یک نگاه

ویژگی	Static Testing	Dynamic Testing
اجرای نرم‌افزار	انجام نمی‌شود	انجام می‌شود
تمرکز اصلی	Work Product	رفتار Software
زمان انجام	از مراحل ابتدایی SDLC قابل انجام است	معمولاً پس از آماده شدن Test Object قابل اجراست
Requirement	قابل بررسی	معمولاً مبنای طراحی تست
Design	قابل بررسی	می‌تواند از طریق اجرای سیستم مورد ارزیابی قرار گیرد
Source Code	قابل بررسی	رفتار نرم‌افزار از طریق اجرای آن بررسی می‌شود
Testware	قابل بررسی	Test Case اجرا می‌شود
ابزارهای نمونه	Review Tools، Static Analysis Tools	Test Automation، API Testing، UI Testing و…
نوع Feedback	اغلب زودهنگام	معمولاً پس از آماده شدن Test Object
نمونه Finding	Requirement مبهم	Login با Credential معتبر کار نمی‌کند

۱۲.۲ Static Testing از چه چیزی سؤال می‌پرسد؟

در Static Testing، سؤال اصلی می‌تواند این باشد:

«آیا Work Product که داریم درست، کامل، واضح، سازگار و قابل استفاده است؟»

برای مثال Tester یک User Story را بررسی می‌کند:

The system should respond quickly.

Tester می‌پرسد: «Quickly یعنی چه؟» این سؤال حتی قبل از نوشته شدن Code می‌تواند مطرح شود.

۱۲.۳ Dynamic Testing از چه چیزی سؤال می‌پرسد؟

در Dynamic Testing سؤال بیشتر به این شکل است:

«وقتی Software را اجرا می‌کنیم، آیا رفتار واقعی آن مطابق Requirement است؟»

مثلاً Requirement می‌گوید:

Response Time must be less than 2 seconds.

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

Request
   ↓
API
   ↓
Response
   ↓
Response Time = 4.7 seconds

در این حالت Failure مشاهده شده است و Tester باید آن را تحلیل کند تا Defect مربوطه را شناسایی و گزارش کند.

۱۲.۴ Static Testing می‌تواند خیلی زودتر شروع شود

یکی از مزیت‌های مهم Static Testing این است که برای انجام آن الزاماً نیازی نیست Software آماده اجرا باشد.

Requirements
     ↓
Static Testing
     ↓
Design
     ↓
Static Testing
     ↓
Code
     ↓
Static Testing
     ↓
Dynamic Testing

در واقع Static Testing می‌تواند در مراحل مختلف SDLC انجام شود؛ برای مثال Tester می‌تواند قبل از شروع Development، User Story و Acceptance Criteria را بررسی کند.

۱۲.۵ Dynamic Testing به Test Object قابل اجرا نیاز دارد

برای انجام Dynamic Testing باید چیزی داشته باشیم که بتوانیم اجرا و مشاهده کنیم؛ برای مثال Application، API، Service، Mobile App یا Web Application.

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

User should be redirected to Dashboard after successful login.

در Static Testing می‌توانیم Requirement را بررسی کنیم، اما برای بررسی اینکه واقعاً Redirect اتفاق می‌افتد یا نه، باید Software را اجرا کنیم.

Enter Username
      ↓
Enter Password
      ↓
Click Login
      ↓
System Execution
      ↓
Dashboard

۱۲.۶ Static Testing و Dynamic Testing می‌توانند یک Defect را در مراحل مختلف پیدا کنند

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

User can reset the password using a valid email address.

Static Testing

Tester Requirement را Review می‌کند و می‌پرسد: «Valid Email یعنی چه؟» تیم متوجه می‌شود Requirement به اندازه کافی مشخص نیست و آن را اصلاح می‌کند.

Dynamic Testing

فرض کنیم Requirement اصلاح شده و Software ساخته شده است. Tester Email معتبر وارد می‌کند، اما Reset Email ارسال نمی‌شود. اینجا Failure مشاهده شده است و Tester می‌تواند Defect را گزارش کند.

Static Testing
    ↓
Requirement Defect

Dynamic Testing
    ↓
Failure
    ↓
Defect

۱۲.۷ تفاوت در نوع Defectهایی که پیدا می‌شوند

Static Testing در پیدا کردن برخی مشکلات بسیار مناسب است، مانند:

• Requirementهای مبهم
• Requirementهای ناقص
• Requirementهای متناقض
• مشکلات Design
• برخی Coding Defectها
• نقض Coding Standard
• مشکلات ساختاری در Testware

در مقابل، Dynamic Testing برای مواردی مانند رفتار نادرست در Runtime، مشکلات Integration، مشکلات Performance در شرایط واقعی اجرا، مشکلات UI، مشکلات API هنگام اجرا و مشکلاتی که فقط در شرایط خاص Runtime ظاهر می‌شوند اهمیت زیادی دارد.

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

۱۲.۸ تفاوت در Feedback

Static Testing معمولاً Feedback را زودتر فراهم می‌کند.

Monday
Requirement Created
        ↓
Tuesday
Tester Review
        ↓
Finding
        ↓
Requirement Fixed

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

Requirement
    ↓
Development
    ↓
Testing
    ↓
Finding
    ↓
Code Change
    ↓
Retest

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

۱۲.۹ Static Testing جای Dynamic Testing را نمی‌گیرد

خیر. حتی اگر Requirements و Code را خوب Review کنیم، باز هم به Dynamic Testing نیاز داریم.

مثلاً Requirement درست است:

Password must contain at least 8 characters.

اما Implementation اشتباه است:

if password.length >= 6

Review می‌تواند این مشکل را در Source Code پیدا کند، اما Dynamic Testing نیز می‌تواند آن را هنگام اجرای سیستم آشکار کند. از طرف دیگر، برخی مشکلات فقط هنگام Runtime خودشان را نشان می‌دهند.

Static Testing
       +
Dynamic Testing
       ↓
Better Defect Detection

۱۲.۱۰ Static Testing و Dynamic Testing در یک پروژه واقعی

در یک پروژه واقعی، این دو رویکرد معمولاً کنار هم قرار می‌گیرند. برای مثال در یک Feature جدید:

User Story
     ↓
Review
     ↓
Acceptance Criteria Review
     ↓
Technical Design Review
     ↓
Development
     ↓
Code Review / Static Analysis
     ↓
Build
     ↓
API Testing
     ↓
UI Testing
     ↓
Integration Testing
     ↓
E2E Testing
     ↓
Regression Testing

در این فرآیند، Static Testing فقط یک فعالیت در ابتدای پروژه نیست و می‌تواند در نقاط مختلف چرخه توسعه ادامه داشته باشد.

۱۲.۱۱ مقایسه از دید Tester

اگر بخواهیم تفاوت را از دید شغلی یک Tester ببینیم:

در Static Testing

• آیا این Requirement واضح است؟
• آیا چیزی از قلم افتاده؟
• آیا می‌توان این Requirement را Test کرد؟
• آیا بین دو Requirement تناقض وجود دارد؟
• آیا این Design Testable است؟
• آیا Test Caseها خودشان کیفیت مناسبی دارند؟

در Dynamic Testing

• آیا سیستم مطابق Requirement رفتار می‌کند؟
• اگر Input اشتباه باشد چه اتفاقی می‌افتد؟
• آیا API Response صحیح است؟
• آیا UI درست کار می‌کند؟
• آیا سیستم در شرایط Load مورد انتظار عملکرد مناسبی دارد؟
• آیا Integration بین Serviceها درست انجام می‌شود؟

بنابراین Static Testing بیشتر بر پیشگیری و شناسایی زودهنگام مشکلات Work Product تمرکز دارد، در حالی که Dynamic Testing امکان مشاهده رفتار واقعی Test Object را فراهم می‌کند.

۱۲.۱۲ یک مثال بسیار ساده

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

«کاربر باید بتواند با Email و Password وارد سیستم شود.»

Static Testing

• آیا مشخص شده اگر Password اشتباه باشد چه اتفاقی می‌افتد؟
• آیا Account Lockout تعریف شده؟
• آیا Email Case Sensitive است؟
• آیا پیام Error مشخص شده؟

Dynamic Testing

Email: user@example.com
Password: WrongPassword
        ↓
Click Login
        ↓
Actual Result

حالا Tester رفتار واقعی سیستم را بررسی می‌کند. ممکن است سیستم به جای نمایش Error، کاربر را وارد Dashboard کند؛ در اینجا یک Failure واقعی در Runtime مشاهده شده است.

۱۲.۱۳ نتیجه مقایسه

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

             Software Quality
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
   Static Testing       Dynamic Testing
          │                   │
          ↓                   ↓
Review / Analysis       Test Execution
          │                   │
          ↓                   ↓
Early Findings          Runtime Failures
          │                   │
          └─────────┬─────────┘
                    ↓
              Better Quality

Static Testing کمک می‌کند مشکلات را در Work Productها هرچه زودتر پیدا و اصلاح کنیم. Dynamic Testing کمک می‌کند رفتار واقعی Software را هنگام اجرا بررسی کنیم.

در یک فرآیند Testing جامع، این دو رویکرد در کنار یکدیگر استفاده می‌شوند.

۱۳. Static Testing در مقابل Static Analysis

یکی از ابهام‌های رایج در مبحث Static Testing این است که گاهی Static Testing و Static Analysis به جای یکدیگر استفاده می‌شوند. در حالی که این دو اصطلاح یکسان نیستند.

بر اساس ISTQB، Static Testing یک مفهوم گسترده‌تر است که شامل دو رویکرد مهم می‌شود:

Static Testing
│
├── Reviews
│
└── Static Analysis

یعنی:

Static Analysis یکی از روش‌های انجام Static Testing است، نه مترادف آن.

۱۳.۱ Static Analysis چیست؟

Static Analysis به بررسی یک Work Product با استفاده از ابزارها گفته می‌شود، بدون اینکه Software اجرا شود. در این روش، ابزار Source Code یا برخی Work Productهای دیگر را بررسی می‌کند و بر اساس قوانین، الگوها و معیارهای مشخص، مشکلات احتمالی را شناسایی می‌کند.

برای مثال فرض کنید Developer کدی نوشته است که یک متغیر را تعریف کرده اما هیچ‌وقت از آن استفاده نمی‌کند:

username = getUsername()

// username is never used

یک Static Analysis Tool می‌تواند چنین مسئله‌ای را شناسایی کند.

• نقض Coding Standard
• Code Smell
• بعضی خطاهای Coding
• پیچیدگی بیش از حد
• کدهای تکراری
• برخی مشکلات امنیتی
• برخی متغیرهای بدون استفاده

نکته مهم این است که Static Analysis بدون اجرای Software انجام می‌شود؛ بنابراین در دسته Static Testing قرار می‌گیرد.

۱۳.۲ Review و Static Analysis چه تفاوتی دارند؟

هر دو زیرمجموعه Static Testing هستند، اما روش کارشان متفاوت است.

             Static Testing
                   │
        ┌──────────┴──────────┐
        ↓                     ↓
      Review            Static Analysis
        │                     │
        ↓                     ↓
 Human Examination       Tool-based Analysis

در Review، انسان‌ها Work Product را بررسی می‌کنند. در Static Analysis، ابزار Software را بر اساس قوانین و معیارهای مشخص تحلیل می‌کند.

مثال Review

Tester یک User Story را می‌خواند و می‌گوید:

«عبارت “سریع” دقیقاً یعنی چه؟»

این یک Finding است که از طریق تحلیل انسانی پیدا شده است.

مثال Static Analysis

Unused variable: userId

در اینجا Finding توسط ابزار شناسایی شده است.

۱۳.۳ آیا Static Analysis فقط برای Source Code است؟

خیر. اما در پروژه‌های نرم‌افزاری، رایج‌ترین کاربرد Static Analysis مربوط به Source Code است.

برای مثال ابزارهای Static Analysis می‌توانند Code را از نظر مواردی مانند Coding Rules، Code Smells، Complexity، Duplications، Potential Bugs و Security Issues بررسی کنند.

در مقابل، Review می‌تواند Work Productهای متنوعی را بررسی کند:

• Requirements
• User Stories
• Acceptance Criteria
• Architecture
• Design
• Source Code
• Test Cases
• Test Plans
• Documentation
• API Specifications

بنابراین دامنه Review از نظر نوع Work Product می‌تواند بسیار گسترده‌تر باشد.

۱۳.۴ یک مثال واقعی از تفاوت Review و Static Analysis

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

مرحله اول: Review

Tester User Story را بررسی می‌کند:

User can reset their password using their email address.

Tester متوجه می‌شود که مشخص نیست Email نامعتبر چه می‌شود، اگر Email وجود نداشته باشد چه می‌شود، لینک Reset Password چقدر اعتبار دارد، آیا کاربر می‌تواند چند بار درخواست Reset بدهد و بعد از Reset شدن Password، Sessionهای قبلی چه می‌شوند.

این مشکلات با Static Analysis پیدا نمی‌شوند، چون مشکل اصلی در Requirement و Business Context است و نیاز به تحلیل انسانی دارد.

مرحله دوم: Static Analysis

بعد از Development، Developer کد مربوط به Password Reset را نوشته است. Static Analysis Tool کد را بررسی می‌کند و مثلاً موارد زیر را گزارش می‌دهد:

Potential security issue
High code complexity
Duplicated code
Unused variable
Coding standard violation

۱۳.۵ آیا Tester باید Static Analysis انجام دهد؟

لزومی ندارد که همیشه خود Tester مسئول اجرای Static Analysis باشد. در یک تیم واقعی ممکن است Developer ابزار را اجرا کند، CI/CD Pipeline آن را به‌صورت خودکار اجرا کند، Quality Engineer نتایج را بررسی کند، Tester روی Findings مرتبط با کیفیت یا ریسک تمرکز کند و تیم به‌صورت مشترک درباره رفع Findings تصمیم بگیرد.

این موضوع با رویکرد Whole Team Approach در CTFL نیز هماهنگ است؛ کیفیت صرفاً مسئولیت یک نقش خاص نیست.

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

۱۳.۶ Code Review همان Static Analysis است؟

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

Code Review

یک Developer دیگر کد را بررسی می‌کند و درباره منطق، ساختار، سازگاری با Design و Requirement و Edge Caseهای مهم سؤال می‌کند. این یک Human Review است.

Static Analysis

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

Pull Request
     ↓
Static Analysis
     ↓
Code Quality / Security Findings

پس:

Code Review
      ≠
Static Analysis

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

۱۳.۷ ابزارهایی مثل SonarQube کجای این تصویر قرار می‌گیرند؟

ابزارهایی مانند SonarQube نمونه‌ای از ابزارهای پشتیبان Static Analysis هستند.

برای مثال می‌توانند Source Code را بررسی کنند و درباره مواردی مانند Bugs، Vulnerabilities، Code Smells، Duplications، Maintainability و بعضی معیارهای کیفیت Code اطلاعات ارائه دهند.

Developer writes Code
        ↓
Pull Request / Build
        ↓
Static Analysis Tool
        ↓
Findings
        ↓
Developer / Team
        ↓
Fix

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

۱۳.۸ آیا Static Analysis جای Code Review را می‌گیرد؟

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

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

Cyclomatic Complexity = High

اما این سؤال را به شکل کامل پاسخ نمی‌دهد:

«آیا این طراحی واقعاً بهترین راه‌حل برای نیاز کسب‌وکار است؟»

یا در مورد Requirement نمی‌تواند به‌تنهایی مشخص کند که آیا User Story واقعاً نیاز کاربر را به‌درستی بیان می‌کند یا خیر.

Human Review
      +
Static Analysis
      ↓
Broader Static Testing Coverage

۱۳.۹ رابطه Static Analysis با CI/CD

یکی از کاربردهای مهم Static Analysis در پروژه‌های مدرن، اجرای خودکار آن در CI/CD Pipeline است.

Developer
    ↓
Commit
    ↓
Build
    ↓
Static Analysis
    ↓
Quality Gate
    ↓
Pass / Fail

فرض کنید تیم یک Quality Gate تعریف کرده باشد که اگر یک مشکل امنیتی با Severity بالا پیدا شد، Pipeline اجازه ادامه نداشته باشد. در این حالت Static Analysis می‌تواند به‌صورت خودکار بخشی از کنترل کیفیت Code را انجام دهد.

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

۱۳.۱۰ یک مثال کامل از همکاری Review و Static Analysis

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

مرحله ۱: Requirement Review

Tester و سایر اعضای تیم User Story را بررسی می‌کنند.

Finding: مشخص نیست در صورت Timeout شدن پرداخت چه اتفاقی باید بیفتد.

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

مرحله ۲: Design Review

تیم Design را بررسی می‌کند.

Finding: وضعیت Pending برای Transaction در Design مشخص نشده است.

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

مرحله ۳: Code Review

Developer دیگری Pull Request را بررسی می‌کند.

Finding: Handling مربوط به یک Error مهم در Code وجود ندارد.

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

مرحله ۴: Static Analysis

Pipeline کد را تحلیل می‌کند:

High Severity Security Finding

تیم Finding را بررسی و در صورت تأیید اصلاح می‌کند.

مرحله ۵: Dynamic Testing

بعد از Build، Tester سیستم را اجرا می‌کند و سناریوی Timeout را بررسی می‌کند. این بار رفتار واقعی سیستم بررسی می‌شود.

۱۳.۱۱ تفاوت چهار مفهوم مهم

مفهوم	چه چیزی را بررسی می‌کند؟	چگونه؟
Static Testing	Work Product	بدون اجرای Software
Review	Work Product	بررسی انسانی
Static Analysis	معمولاً Code و سایر موارد قابل تحلیل	ابزارمحور
Dynamic Testing	Test Object	با اجرای Software

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

Testing
│
├── Static Testing
│   │
│   ├── Reviews
│   │   ├── Informal Review
│   │   ├── Walkthrough
│   │   ├── Technical Review
│   │   └── Inspection
│   │
│   └── Static Analysis
│
└── Dynamic Testing

این ساختار با دسته‌بندی کلی Static Testing در CTFL v4.0.1 مطابقت دارد.

۱۳.۱۲ یک نکته مهم برای Tester

اگر بخواهیم این موضوع را از دید یک Tester خلاصه کنیم، لازم نیست Tester یک متخصص عمیق Static Analysis باشد تا بتواند از Static Testing استفاده کند.

1. چه Work Productهایی را می‌توان قبل از اجرا بررسی کرد.
2. چه مشکلاتی را بهتر است با Review پیدا کرد.
3. چه مشکلاتی را ابزارهای Static Analysis می‌توانند شناسایی کنند.
4. Findings ابزارها را چگونه بررسی و پیگیری کند.
5. چه زمانی یک Finding واقعاً یک Defect محسوب می‌شود.
6. چگونه نتایج Static Testing را در کنار Dynamic Testing قرار دهد.

در یک تیم حرفه‌ای، هدف این نیست که Review یا Static Analysis جای Dynamic Testing را بگیرد؛ هدف این است که از هرکدام در جایی استفاده شود که بیشترین ارزش را ایجاد می‌کند.

جمع‌بندی

Static Testing یک مفهوم کلی است؛ Review و Static Analysis دو روش مهم برای انجام آن هستند.

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

هیچ‌کدام جای Dynamic Testing را نمی‌گیرند؛ بلکه در کنار آن، پوشش بهتری برای شناسایی مشکلات و افزایش کیفیت Software ایجاد می‌کنند.

۱۴. ابزارهای Static Testing

Static Testing الزاماً به معنی استفاده از یک ابزار خاص نیست. همان‌طور که در بخش‌های قبل دیدیم، Review می‌تواند کاملاً انسانی و حتی بدون ابزار انجام شود. در مقابل، Static Analysis معمولاً با استفاده از ابزارهایی انجام می‌شود که Work Product را بدون اجرای Software بررسی می‌کنند.

بنابراین وقتی درباره ابزارهای Static Testing صحبت می‌کنیم، بهتر است آن‌ها را در چند گروه ببینیم:

Static Testing Tools
│
├── Review / Collaboration Tools
├── Code Review Tools
├── Static Analysis Tools
└── Security / Specialized Analysis Tools

۱۴.۱ ابزارهای Review و مدیریت همکاری

برای بررسی Requirement، User Story، Acceptance Criteria، Design یا سایر Work Productها الزاماً به ابزار تخصصی Testing نیاز نداریم. در بسیاری از پروژه‌ها همین ابزارهای مدیریت پروژه و همکاری برای انجام Review استفاده می‌شوند.

• Jira
• Azure DevOps
• Confluence
• GitHub
• GitLab
• Microsoft Teams
• ابزارهای مدیریت مستندات

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

User Story:
As a user,
I want to reset my password,
so that I can regain access to my account.

Tester می‌تواند همان‌جا Requirement را بررسی کند و Finding خود را مطرح کند؛ مثلاً:

• Acceptance Criteria برای Email نامعتبر مشخص نشده است.
• رفتار سیستم در صورت Expired شدن Reset Link مشخص نیست.

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

۱۴.۲ ابزارهای Code Review

در پروژه‌های مدرن، Code Review معمولاً از طریق سیستم‌های مدیریت Source Code انجام می‌شود.

• GitHub Pull Request
• GitLab Merge Request
• Bitbucket Pull Request

Developer
    ↓
Create Branch
    ↓
Commit
    ↓
Pull Request / Merge Request
    ↓
Code Review
    ↓
Comments / Findings
    ↓
Fix
    ↓
Re-review
    ↓
Merge

مثلاً Tester یا Developer دیگر می‌تواند در Code Review درباره یک بخش از Code سؤال کند:

«آیا این حالت Error نیز باید مدیریت شود؟»

یا:

«این شرط با Requirement تعریف‌شده در User Story سازگار نیست.»

در اینجا Code Review یک Review انسانی است و نباید آن را با Static Analysis یکی دانست.

۱۴.۳ ابزارهای Static Analysis

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

• Bugs
• Code Smells
• Coding Standard Violations
• Duplicated Code
• Complexity
• برخی مشکلات امنیتی

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

Source Code
     ↓
Static Analysis
     ↓
Finding
     ↓
Developer / Team
     ↓
Fix

نکته مهم این است که خروجی ابزار باید تحلیل و تفسیر شود. هر Finding ابزار لزوماً به معنی وجود یک Defect قطعی نیست؛ ممکن است یک Rule در یک پروژه کاربرد نداشته باشد یا Finding در Context خاص پروژه قابل قبول باشد.

۱۴.۴ Static Analysis در چه مرحله‌ای اجرا می‌شود؟

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

Developer
    ↓
Write Code
    ↓
Local Static Analysis
    ↓
Commit
    ↓
Pull Request
    ↓
CI Pipeline
    ↓
Static Analysis
    ↓
Quality Gate
    ↓
Build / Deployment

در بعضی تیم‌ها Developer حتی قبل از Commit نتیجه Static Analysis را مشاهده می‌کند. در تیم‌های دیگر، تحلیل به‌صورت خودکار در CI/CD Pipeline انجام می‌شود.

در نتیجه Static Analysis می‌تواند بخشی از فرآیند روزمره Development باشد، نه یک فعالیت جداگانه در انتهای پروژه.

۱۴.۵ Quality Gate چیست؟

در برخی ابزارهای Static Analysis مفهومی به نام Quality Gate وجود دارد. Quality Gate مجموعه‌ای از معیارهاست که مشخص می‌کند نتیجه Analysis قابل قبول است یا خیر.

Critical Security Issues = 0
New Bugs = 0
New Vulnerabilities = 0

Static Analysis
       ↓
Quality Gate
   ↙       ↘
Pass       Fail
 ↓           ↓
Continue    Fix

اگر Quality Gate Fail شود، تیم باید Findingهای مربوطه را بررسی کند و در صورت نیاز آن‌ها را اصلاح کند. معیارهای Quality Gate باید متناسب با پروژه، ریسک و سیاست‌های تیم تعریف شوند و یک تنظیم ثابت برای همه پروژه‌ها وجود ندارد.

۱۴.۶ ابزارهای Static Testing فقط برای Code نیستند

یک تصور اشتباه این است که Static Testing Tools فقط ابزارهای Code Analysis هستند. در حالی که Static Testing دامنه وسیع‌تری دارد.

Work Product	نمونه فعالیت
Requirement	Review
User Story	Review
Acceptance Criteria	Review
Design	Technical Review
Source Code	Code Review / Static Analysis
Test Case	Review
Test Plan	Review
API Specification	Review
Documentation	Review

بنابراین اگر Tester یک Test Case را قبل از اجرای آن بررسی کند، این نیز می‌تواند بخشی از Static Testing باشد.

Test Case:

1. Login
2. Enter username
3. Enter password
4. Click Login
5. Verify Dashboard

Tester ممکن است متوجه شود که هیچ Test Caseای برای Password اشتباه وجود ندارد. این Finding از طریق Review پیدا شده، نه Static Analysis.

۱۴.۷ ابزارهای Security Static Analysis

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

Source Code
     ↓
Security Analysis
     ↓
Potential Vulnerability
     ↓
Security Review
     ↓
Fix

این نوع ابزارها به‌خصوص در پروژه‌هایی که Security Risk اهمیت زیادی دارد، می‌توانند در کنار سایر فعالیت‌های Static Testing استفاده شوند. همانند سایر ابزارهای خودکار، خروجی آن‌ها باید بررسی شود و نباید بدون تحلیل انسانی به‌عنوان حقیقت قطعی در نظر گرفته شود.

۱۴.۸ نقش Tester در استفاده از ابزارهای Static Testing

Tester در همه پروژه‌ها الزاماً مسئول اجرای تمام ابزارهای Static Testing نیست. ممکن است وظایف بین اعضای تیم تقسیم شده باشد.

فعالیت	مسئول احتمالی
Requirement Review	Tester / BA / PO / Team
Technical Review	Developer / Architect / Technical Team
Code Review	Developer / Technical Team
Static Analysis	Developer / CI/CD
Security Analysis	Developer / Security / DevSecOps
بررسی Findings	Team
Retest بعد از اصلاح	Tester

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

Tester ممکن است خودش Static Analysis Tool را اجرا نکند، اما باید بتواند نتایج مرتبط با کیفیت و ریسک را درک و پیگیری کند.

۱۴.۹ آیا Tester باید SonarQube را یاد بگیرد؟

برای یک Tester، یادگیری عمیق تمام قابلیت‌های یک ابزار Static Analysis معمولاً ضروری نیست؛ اما شناخت مفاهیم اصلی بسیار مفید است.

• Static Analysis چیست؟
• Finding چیست؟
• Code Smell چیست؟
• Vulnerability چیست؟
• Quality Gate چیست؟
• Severity و Priority چه تفاوتی دارند؟
• چگونه Findingها پیگیری می‌شوند؟
• چه زمانی یک Finding نیاز به اصلاح دارد؟
• چگونه Static Analysis در CI/CD قرار می‌گیرد؟

برای یک QA یا Automation Engineer که به سمت Quality Engineering حرکت می‌کند، آشنایی بیشتر با این ابزارها می‌تواند اهمیت بیشتری پیدا کند.

۱۴.۱۰ یک مثال واقعی در فرآیند توسعه

فرض کنید Developer یک Feature برای Login توسعه داده است.

مرحله اول: Code Review

Code Review
     ↓
Finding:
Error handling is incomplete

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

مرحله دوم: Static Analysis

Static Analysis
     ↓
Finding:
High Complexity

تیم Finding را بررسی می‌کند.

مرحله سوم: Quality Gate

Quality Gate
     ↓
FAIL

Developer باید مشکل را برطرف کند.

مرحله چهارم: Dynamic Testing

Login
  ↓
Valid Credentials
  ↓
Dashboard

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

۱۴.۱۱ یک نکته مهم: ابزار جای تفکر Tester را نمی‌گیرد

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

Static Analysis
      ↓
0 Findings

آیا می‌توان نتیجه گرفت «پس Software کاملاً بدون مشکل است»؟ خیر.

ابزار فقط چیزهایی را پیدا می‌کند که Ruleها و قابلیت‌های آن برای شناسایی‌شان طراحی شده‌اند. ممکن است Requirement اشتباه باشد، Business Rule ناقص باشد، یک سناریوی مهم کاربر در نظر گرفته نشده باشد یا Design با نیاز واقعی کاربر مطابقت نداشته باشد. این موارد همچنان به تفکر انتقادی، Review و تحلیل انسانی نیاز دارند.

۱۴.۱۲ جمع‌بندی ابزارهای Static Testing

Static Testing
│
├── Human-based
│   ├── Requirement Review
│   ├── User Story Review
│   ├── Design Review
│   ├── Code Review
│   └── Testware Review
│
└── Tool-based
    ├── Static Code Analysis
    ├── Security Analysis
    └── Quality Checks

بنابراین وقتی در یک پروژه از Static Testing صحبت می‌کنیم، نباید فقط به ابزارهایی مانند SonarQube فکر کنیم. یک Tester ممکن است بدون اجرای حتی یک ابزار تخصصی، با بررسی دقیق یک User Story، یک Defect مهم را قبل از شروع Development پیدا کند.

از طرف دیگر، ابزارهای Static Analysis می‌توانند حجم زیادی از بررسی‌های تکراری و Rule-based را به‌صورت خودکار انجام دهند.

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

۱۵. چک‌لیست عملی Static Testing برای Tester

تا اینجا با مفهوم Static Testing، Review، Review Typeها، Static Analysis و ابزارهای مرتبط آشنا شدیم.

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

یک Tester در عمل هنگام انجام Static Testing دقیقاً باید چه چیزهایی را بررسی کند؟

پاسخ به این سؤال به نوع Work Product بستگی دارد. یک Checklist برای User Story با Checklist مربوط به Source Code یا Test Case یکسان نیست.

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

۱۵.۱ قبل از شروع Review چه چیزهایی را بررسی کنیم؟

قبل از اینکه وارد جزئیات Work Product شویم، ابتدا باید مطمئن شویم چیزی که قرار است Review کنیم، شرایط لازم برای Review را دارد.

Checklist اولیه

• آیا نسخه صحیح Work Product را در اختیار دارم؟
• هدف این Review مشخص است؟
• Scope بررسی مشخص است؟
• آیا Acceptance Criteria یا سایر معیارهای پذیرش در دسترس هستند؟
• آیا Requirementهای مرتبط را دارم؟
• آیا اصطلاحات تخصصی یا Business Rules موردنیاز را می‌شناسم؟
• آیا نسخه قبلی وجود دارد که بتوانم با آن مقایسه کنم؟
• آیا Checklist یا استاندارد مشخصی برای این نوع Work Product وجود دارد؟

این مرحله ساده به نظر می‌رسد، اما اگر Tester بدون شناخت Context شروع به Review کند، احتمال دارد بخشی از مشکلات مهم را از دست بدهد.

۱۵.۲ بررسی Requirement و User Story

یکی از مهم‌ترین کاربردهای Static Testing برای Tester، بررسی Requirementها و User Storyهاست.

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

وضوح (Clarity)

• آیا Requirement واضح است؟
• آیا عبارت مبهمی وجود دارد؟
• آیا کلماتی مانند «سریع»، «مناسب»، «بهینه» یا «به‌راحتی» بدون تعریف استفاده شده‌اند؟
• آیا افراد مختلف تیم برداشت یکسانی از Requirement خواهند داشت؟

مثلاً:

The system should respond quickly.

کلمه quickly مشخص نیست. آیا منظور کمتر از ۱ ثانیه است؟ ۲ ثانیه؟ یا ۵ ثانیه؟

تا زمانی که معیار مشخصی برای این Requirement تعریف نشده باشد، Testability آن پایین خواهد بود.

۱۵.۳ بررسی کامل بودن (Completeness)

یکی از سؤال‌های مهم Tester این است:

آیا چیزی از قلم افتاده است؟

برای مثال Requirement فقط سناریوی موفق را تعریف کرده است:

User can change their password.

اما درباره موارد زیر چیزی نگفته است:

• Password اشتباه
• Password قبلی
• Password جدید نامعتبر
• Passwordهای یکسان
• Session منقضی‌شده
• کاربر بدون دسترسی
• خطای Server

Tester باید بررسی کند که آیا این موارد باید در Requirement یا Acceptance Criteria مشخص شوند یا خیر.

۱۵.۴ بررسی Consistency

گاهی هر Requirement به تنهایی درست به نظر می‌رسد، اما وقتی چند Requirement را کنار هم قرار می‌دهیم، تناقض پیدا می‌شود.

Requirement A:

Password must contain at least 8 characters.

Requirement B:

Password must contain at least 10 characters.

در اینجا سؤال Tester این است:

کدام Requirement معتبر است؟

این موضوع باید قبل از Development مشخص شود.

۱۵.۵ بررسی Testability

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

آیا این Requirement قابل Test کردن است؟

مثلاً:

The system should provide a user-friendly interface.

این Requirement بسیار کلی است و Tester نمی‌تواند به‌راحتی مشخص کند چه چیزی باید Pass یا Fail اعلام شود.

اما اگر Requirement دقیق‌تر باشد:

The error message must be displayed below the Email field when an invalid email format is entered.

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

Input:
invalid email

Expected Result:
Error message appears below Email field

۱۵.۶ بررسی Acceptance Criteria

Acceptance Criteria یکی از مهم‌ترین بخش‌هایی است که Tester باید در Review بررسی کند.

• آیا قابل فهم است؟
• آیا قابل Test است؟
• آیا Expected Result مشخص است؟
• آیا شرایط موفقیت مشخص شده است؟
• آیا شرایط خطا مشخص شده است؟
• آیا Boundaryها مشخص هستند؟
• آیا Business Ruleها پوشش داده شده‌اند؟
• آیا Criteria با User Story سازگار است؟

برای مثال:

User can enter an age.

این Acceptance Criteria ناقص است.

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

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

این سؤال‌ها بعداً مستقیماً روی Test Design تأثیر می‌گذارند.

۱۵.۷ بررسی Design

Static Testing فقط محدود به Requirement نیست. Tester می‌تواند Design را نیز بررسی کند.

Web App
   ↓
API Gateway
   ↓
Auth Service
   ↓
User Service
   ↓
Database

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

• آیا Flow کامل مشخص شده است؟
• در صورت Timeout چه اتفاقی می‌افتد؟
• اگر یک Service در دسترس نباشد چه می‌شود؟
• آیا Error Handling مشخص است؟
• آیا Retry وجود دارد؟
• آیا Authentication و Authorization در محل مناسب انجام می‌شوند؟
• آیا Responseهای Error مشخص هستند؟
• آیا طراحی قابل Test است؟

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

۱۵.۸ بررسی API Specification

Tester در پروژه‌های API محور می‌تواند API Specification را نیز Review کند.

POST /users

Request

• Required Fieldها مشخص هستند؟
• Data Typeها مشخص هستند؟
• Validation Ruleها مشخص هستند؟
• Fieldهای Optional مشخص هستند؟

Response

• Status Code مشخص است؟
• Response Body مشخص است؟
• Error Response مشخص است؟
• Validation Error مشخص است؟

Authentication

• Authentication Method مشخص است؟
• Authorization Rule مشخص است؟
• Token Expiration مشخص است؟

اگر این موارد قبل از Development مشخص شوند، احتمال سوءتفاهم بین Developer و Tester کاهش پیدا می‌کند.

۱۵.۹ بررسی Test Case

خود Testware نیز می‌تواند تحت Static Testing قرار بگیرد.

فرض کنید Test Case زیر را داریم:

Test Case:

1. Open Login Page
2. Enter Username
3. Enter Password
4. Click Login
5. Verify Dashboard

Tester هنگام Review می‌تواند سؤال کند:

• Preconditions مشخص هستند؟
• Test Data مشخص است؟
• Expected Result دقیق است؟
• آیا فقط Happy Path بررسی شده است؟
• Negative Scenario وجود دارد؟
• Boundary Case وجود دارد؟
• آیا Test Case با Requirement مرتبط است؟
• آیا Steps واضح هستند؟
• آیا Test Case قابل تکرار است؟

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

Account should be locked after 5 failed login attempts.

اما هیچ Test Caseای برای این سناریو وجود نداشته باشد، Review می‌تواند این Gap را قبل از اجرای تست‌ها پیدا کند.

۱۵.۱۰ بررسی Documentation

Documentation نیز می‌تواند Work Product مورد بررسی باشد.

POST /login

Response:
200 OK

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

• آیا Request Example وجود دارد؟
• آیا Required Fields مشخص هستند؟
• آیا Error Responseها مشخص هستند؟
• آیا Authentication توضیح داده شده است؟
• آیا Status Codeهای مختلف مشخص هستند؟
• آیا Documentation با API واقعی سازگار است؟

در اینجا حتی بدون اجرای API می‌توان مشکلات زیادی را در Documentation پیدا کرد.

۱۵.۱۱ Checklist عمومی Tester

سؤال بررسی	معیار
آیا واضح است؟	Clarity
آیا کامل است؟	Completeness
آیا تناقض دارد؟	Consistency
آیا قابل Test است؟	Testability
آیا قابل پیگیری است؟	Traceability
آیا Business Ruleها مشخص‌اند؟	Business Rules
آیا Error Scenarioها مشخص‌اند؟	Negative Scenarios
آیا Boundaryها مشخص‌اند؟	Boundary Conditions
آیا Assumption پنهانی وجود دارد؟	Assumptions
آیا با سایر Work Productها سازگار است؟	Consistency
آیا نسخه صحیح بررسی می‌شود؟	Version
آیا تغییرات اخیر در نظر گرفته شده‌اند؟	Changes

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

۱۵.۱۲ Tester هنگام Review فقط دنبال «اشتباه» نیست

یک نکته بسیار مهم این است که هدف Review فقط پیدا کردن Error نیست.

Tester ممکن است در Review با موارد مختلفی مواجه شود:

Finding
│
├── Defect
├── Ambiguity
├── Missing Information
├── Inconsistency
├── Question
└── Recommendation

مثلاً:

«آیا باید کاربر بعد از تغییر Password از تمام Sessionهای قبلی خارج شود؟»

این جمله لزوماً گزارش یک Defect نیست. ممکن است یک Question باشد که باعث شود Business Rule مشخص شود.

پس Tester نباید از ابتدا هر Finding را به عنوان Bug ثبت کند.

۱۵.۱۳ Checklist را به نوع Work Product متصل کنیم

یک Checklist واحد برای همه چیز مناسب نیست. بهتر است Checklist بر اساس نوع Work Product تنظیم شود:

User Story
    ↓
Clarity
Completeness
Testability
Acceptance Criteria
Business Rules
Negative Scenarios

Design
    ↓
Architecture
Interfaces
Error Handling
Security
Performance
Testability

Test Case
    ↓
Coverage
Expected Result
Test Data
Preconditions
Traceability
Negative / Boundary Cases

Source Code
    ↓
Code Review
Coding Standards
Maintainability
Logic
Security
Static Analysis

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

۱۵.۱۴ یک نکته مهم درباره Checklist

Checklist نباید تبدیل به یک فرم مکانیکی شود که Tester فقط گزینه‌های آن را تیک بزند.

هدف Checklist این است که:

به فکر کردن Tester جهت بدهد، نه اینکه جایگزین فکر کردن شود.

مثلاً ممکن است Checklist بگوید:

آیا Requirement کامل است؟

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

بنابراین یک Tester حرفه‌ای علاوه بر Checklist باید بتواند سؤال‌های جدیدی را بر اساس Context پروژه مطرح کند.

۱۵.۱۵ Checklist نهایی برای Review یک User Story

قبل از Review

• هدف User Story مشخص است.
• Business Context را می‌دانم.
• Requirementهای مرتبط در دسترس هستند.
• Acceptance Criteria وجود دارد.

هنگام Review

• User Story واضح است.
• اطلاعات ضروری کامل است.
• تناقضی با Requirementهای دیگر ندارد.
• Acceptance Criteria قابل Test هستند.
• Happy Path مشخص است.
• Negative Scenarioها بررسی شده‌اند.
• Boundaryها مشخص هستند.
• Error Handling مشخص است.
• Business Ruleها واضح هستند.
• Test Data موردنیاز قابل تهیه است.
• Requirement قابل Trace شدن است.

بعد از Review

• Findingها ثبت شده‌اند.
• Findingها با تیم بررسی شده‌اند.
• مسئول اصلاح مشخص است.
• اصلاحات انجام شده‌اند.
• در صورت نیاز Re-review انجام شده است.

این Checklist می‌تواند به مرور زمان بر اساس نوع پروژه، تکنولوژی و تجربه تیم توسعه پیدا کند.

جمع‌بندی

Static Testing زمانی بیشترین ارزش را ایجاد می‌کند که Tester آن را فقط به عنوان یک مرحله تئوری در نظر نگیرد.

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

در واقع یکی از ارزشمندترین مهارت‌های Tester در Static Testing این نیست که فقط «اشتباه را پیدا کند»؛ بلکه این است که بتواند بپرسد:

«چه چیزی هنوز مشخص نشده است؟»

همین سؤال ساده می‌تواند یک Requirement ناقص، یک Acceptance Criteria مبهم، یک Design غیرقابل Test یا حتی یک Test Case ناکافی را قبل از آنکه به مشکل در Runtime تبدیل شود، آشکار کند.

۱۶. اشتباهات رایج در Static Testing

Static Testing در ظاهر ساده به نظر می‌رسد: یک Work Product را بررسی می‌کنیم و مشکلات را پیدا می‌کنیم.

اما در پروژه واقعی، نحوه انجام Review اهمیت زیادی دارد. ممکن است یک تیم جلسات Review زیادی برگزار کند، ابزارهای Static Analysis داشته باشد و Checklistهای مختلفی استفاده کند، اما همچنان مشکلات مهمی تا مراحل بعدی باقی بمانند.

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

۱۶.۱ شروع Review بدون شناخت Context

یکی از اشتباهات مهم این است که Tester بدون شناخت Business Context شروع به بررسی Requirement کند.

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

User can cancel an order.

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

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

بنابراین Review فقط خواندن جملات Requirement نیست. Tester باید تا حد ممکن Business Context و هدف Feature را نیز درک کند.

۱۶.۲ تبدیل Review به پیدا کردن ایرادهای ظاهری

گاهی Review بیش از حد روی مواردی مانند Grammar، Typo، Formatting و Naming تمرکز می‌کند و مسائل مهم‌تر نادیده گرفته می‌شوند.

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

• Missing Requirements
• Ambiguity
• Inconsistency
• Untestable Requirements
• Missing Error Scenarios
• Security Risks
• Business Rule Gaps

هدف Static Testing فقط پیدا کردن غلط املایی نیست.

۱۶.۳ تصور اینکه هر Finding یک Bug است

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

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

«اگر Session کاربر در هنگام پرداخت منقضی شود چه اتفاقی باید بیفتد؟»

این ممکن است یک Question یا Missing Information باشد. بعد از بررسی مشخص می‌شود:

این حالت باید باعث انتقال کاربر به صفحه Login شود.

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

Finding
   ↓
Analysis
   ↓
Classification
   ↓
Action

۱۶.۴ فرض کردن اینکه «همه چیز را می‌دانیم»

یکی از خطرناک‌ترین اشتباهات در Review، Assumption است.

مثلاً Requirement می‌گوید:

User enters an email address.

Tester ممکن است تصور کند که Email باید حتماً فرمت معتبر داشته باشد؛ اما آیا واقعاً این موضوع در Requirement یا Business Rule تعریف شده است؟

فرض‌های پنهان می‌توانند بعداً باعث اختلاف بین Product Owner، Business Analyst، Developer و Tester شوند.

یکی از کارهای مهم Tester این است که Assumptionهای پنهان را آشکار کند.

۱۶.۵ فقط Happy Path را بررسی کردن

این اشتباه بسیار رایج است.

مثلاً User Story:

User can transfer money to another account.

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

Valid Account
      ↓
Valid Amount
      ↓
Transfer
      ↓
Success

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

• اگر موجودی کافی نباشد چه؟
• اگر Account مقصد معتبر نباشد چه؟
• اگر مبلغ صفر باشد چه؟
• اگر مبلغ منفی باشد چه؟
• اگر Transfer دوبار ارسال شود چه؟
• اگر سرویس بانک مقصد در دسترس نباشد چه؟
• اگر Timeout رخ دهد چه؟

قرار نیست همه این موارد حتماً در همان Requirement نوشته شوند، اما Tester باید بررسی کند که آیا این Business Rules و رفتارها مشخص شده‌اند یا خیر.

۱۶.۶ انجام Review فقط در پایان کار

یکی از اشتباهات رایج این است که تیم می‌گوید: «وقتی Requirement کامل شد، آن را Review می‌کنیم.» یا «وقتی Code تمام شد، Code Review انجام می‌دهیم.»

Static Testing می‌تواند در طول چرخه توسعه انجام شود.

User Story
    ↓
Review
    ↓
Design
    ↓
Technical Review
    ↓
Code
    ↓
Code Review
    ↓
Static Analysis

در Agile حتی ممکن است User Story در Backlog Refinement بررسی شود، قبل از اینکه وارد Sprint Development شود.

بنابراین Static Testing فقط یک مرحله پایانی نیست.

۱۶.۷ تصور اینکه Review حتماً باید جلسه باشد

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

• ممکن است یک Tester یک User Story را بررسی کند و Findingهای خود را در Jira ثبت کند.
• ممکن است یک Developer یک Pull Request را بررسی کند.
• ممکن است یک تیم برای یک Work Product مهم، Inspection رسمی برگزار کند.

سطح Formality باید با نیاز پروژه، Risk و نوع Work Product متناسب باشد.

۱۶.۸ استفاده افراطی از Checklist

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

☑ Clear
☑ Complete
☑ Testable
☑ Consistent

اما آیا واقعاً Tester درباره این موارد فکر کرده است؟

Checklist باید حافظه و تفکر Tester را تقویت کند، نه اینکه جایگزین تحلیل او شود.

۱۶.۹ اعتماد کامل به ابزارهای Static Analysis

این اشتباه در مورد Static Analysis Tools نیز اتفاق می‌افتد.

فرض کنیم ابزار هیچ Findingای گزارش نکرده است:

Static Analysis
      ↓
0 Findings

این به معنی «Code کاملاً بدون مشکل است» نیست.

ابزار بر اساس Ruleها و قابلیت‌های خودش تحلیل می‌کند. ممکن است Requirement اشتباه باشد، Business Logic اشتباه باشد، یک Scenario پوشش داده نشده باشد، Design مشکل داشته باشد یا یک مشکل فقط در Runtime قابل مشاهده باشد.

0 Findings ≠ 0 Defects

۱۶.۱۰ نادیده گرفتن Findingهای ابزار

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

اگر Findingها مرتباً نادیده گرفته شوند، ممکن است به مرور حجم زیادی از Technical Debt ایجاد شود.

Finding
   ↓
Review
   ↓
Valid?
 ↙     ↘
Yes     No
 ↓       ↓
Fix    Dismiss / Accept

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

۱۶.۱۱ عدم انجام Re-review بعد از اصلاح

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

این موضوع می‌تواند مشکل‌ساز باشد، چون ممکن است:

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

Finding
   ↓
Fix
   ↓
Re-review
   ↓
Close

۱۶.۱۲ تمرکز بیش از حد روی Technical Details

Tester باید بتواند Technical Details را بررسی کند، اما در Review Requirement نباید Business Need را فراموش کند.

مثلاً ممکن است تیم ساعت‌ها درباره اینکه REST API باشد یا GraphQL بحث کند، در حالی که سؤال مهم‌تر این است:

«آیا Requirement واقعاً نیاز کاربر را پوشش می‌دهد؟»

Review باید با هدف و نوع Work Product هماهنگ باشد.

۱۶.۱۳ تبدیل Review به جلسه سرزنش افراد

هدف Review پیدا کردن مشکل در Work Product است، نه پیدا کردن مقصر.

مثلاً اگر Requirement ناقص است، هدف این نیست که بگوییم: «چه کسی این Requirement را اشتباه نوشته؟»

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

«چه چیزی در فرآیند باعث شد این Requirement ناقص بماند؟»

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

۱۶.۱۴ بررسی نکردن ارتباط بین Work Productها

یک Requirement ممکن است به تنهایی درست به نظر برسد، اما با Work Product دیگری ناسازگار باشد.

Requirement
    ↕
Design
    ↕
API Specification
    ↕
Test Case
    ↕
Source Code

Tester باید در صورت امکان بررسی کند که این موارد با یکدیگر سازگار هستند. این موضوع به Traceability نیز ارتباط پیدا می‌کند.

مثلاً Requirement می‌گوید:

Maximum file size is 10 MB.

اما API Documentation می‌گوید:

Maximum file size: 5 MB

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

۱۶.۱۵ تصور اینکه Static Testing فقط وظیفه Tester است

Quality مسئولیت یک نقش واحد نیست.

• Tester
• Developer
• Business Analyst
• Product Owner
• Architect
• Security Specialist
• سایر افراد مرتبط با Work Product

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

Tester: آیا این Requirement قابل Test است؟

Developer: آیا این Requirement از نظر فنی قابل پیاده‌سازی است؟

Product Owner: آیا این Requirement نیاز کسب‌وکار را پوشش می‌دهد؟

Security Specialist: آیا Security Requirementها پوشش داده شده‌اند؟

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

۱۶.۱۶ انتخاب Review Type نامناسب

گاهی تیم برای همه Work Productها یک نوع Review انجام می‌دهد. اما Review Type باید با شرایط پروژه متناسب باشد.

مثلاً برای یک تغییر کوچک در یک User Story ممکن است یک Review ساده کافی باشد. اما برای یک سیستم حساس یا یک Work Product با Risk بالا، ممکن است Review رسمی‌تر و ساختاریافته‌تری مناسب باشد.

چهار Review Type معرفی‌شده در ISTQB عبارت‌اند از:

• Informal Review
• Walkthrough
• Technical Review
• Inspection

هدف این نیست که همیشه رسمی‌ترین نوع Review را انتخاب کنیم؛ هدف انتخاب روشی متناسب با Risk، Complexity، Criticality و نیاز پروژه است.

۱۶.۱۷ مستندسازی نکردن Findings مهم

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

Finding
Owner
Action
Status
Resolution

البته سطح مستندسازی باید متناسب با Formality Review باشد. در یک Informal Review کوچک ممکن است ثبت همه جزئیات ضروری نباشد.

۱۶.۱۸ جمع‌بندی اشتباهات رایج

اشتباه	نتیجه احتمالی
Review بدون Context	از دست رفتن مشکلات Business
فقط بررسی Grammar	نادیده گرفتن Defectهای مهم
هر Finding = Bug	گزارش‌های غیرضروری
Assumptionهای پنهان	سوءتفاهم بین اعضای تیم
فقط Happy Path	پوشش ناقص
Review فقط در پایان	افزایش Rework و احتمال افزایش هزینه اصلاح
Review فقط به صورت جلسه	کاهش انعطاف
Checklist مکانیکی	کاهش تفکر تحلیلی
اعتماد کامل به ابزار	False Sense of Quality
نادیده گرفتن Findings	افزایش Technical Debt
بدون Re-review	باقی ماندن مشکل
سرزنش افراد	کاهش همکاری
عدم Traceability	ناسازگاری بین Work Productها
Tester تنها مسئول کیفیت	تضعیف Whole Team Quality

در نهایت، Static Testing زمانی مؤثر است که به عنوان بخشی از فرآیند توسعه و کیفیت دیده شود، نه یک فرم یا جلسه اجباری.

هدف اصلی این نیست که تعداد زیادی Finding تولید کنیم؛ هدف این است که مشکلات مهم را در زمانی پیدا کنیم که اصلاح آن‌ها ساده‌تر و معمولاً کم‌هزینه‌تر و کم‌ریسک‌تر است.

۱۷. Static Testing در Agile

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

در Agile، Static Testing معمولاً به شکل یک مرحله رسمی و جداگانه انجام نمی‌شود؛ بلکه می‌تواند در فعالیت‌های روزمره تیم مانند Backlog Refinement، Review کردن User Story، Technical Discussion، Code Review و Static Analysis قرار بگیرد.

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

۱۷.۱ Static Testing در کجای Agile قرار می‌گیرد؟

Product Backlog
      ↓
Backlog Refinement
      ↓
User Story Review
      ↓
Acceptance Criteria Review
      ↓
Sprint Planning
      ↓
Development
      ↓
Code Review
      ↓
Static Analysis
      ↓
Dynamic Testing
      ↓
Feedback
      ↓
Fix / Improvement

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

۱۷.۲ Static Testing در Backlog Refinement

یکی از نقاط مناسب برای انجام Static Testing در Agile، Backlog Refinement است.

فرض کنیم User Story زیر وارد Backlog شده است:

As a user, I want to change my password so that I can keep my account secure.

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

• حداقل طول Password چقدر است؟
• آیا Password باید شامل عدد باشد؟
• آیا Password قبلی می‌تواند دوباره استفاده شود؟
• اگر Password فعلی اشتباه باشد چه اتفاقی می‌افتد؟
• اگر Confirmation با Password جدید متفاوت باشد چه؟
• بعد از تغییر Password چه اتفاقی برای Sessionهای قبلی می‌افتد؟

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

۱۷.۳ چرا Tester باید در Refinement حضور داشته باشد؟

اگر Tester فقط بعد از پایان Development وارد Feature شود، ممکن است بسیاری از ابهامات Requirement تا آن زمان باقی بمانند.

User Story
    ↓
Development
    ↓
Testing
    ↓
Ambiguous Requirement

حالا تیم باید هم Code را اصلاح کند و هم Requirement را دوباره بررسی کند.

اما اگر Tester زودتر وارد فرآیند شود:

User Story
    ↓
Tester Review
    ↓
Finding
    ↓
Requirement Clarification
    ↓
Development

مشکل قبل از Development برطرف شده است. این دقیقاً یکی از ارزش‌های رویکرد Shift-Left است.

۱۷.۴ Static Testing و Definition of Ready

برخی تیم‌های Agile از مفهومی به نام Definition of Ready (DoR) استفاده می‌کنند.

DoR مشخص می‌کند یک User Story چه شرایطی باید داشته باشد تا تیم بتواند آن را وارد Development کند.

• User Story واضح باشد.
• Acceptance Criteria مشخص باشد.
• Dependencyهای مهم مشخص باشند.
• Business Ruleهای اصلی مشخص باشند.
• Story قابل Test باشد.

این موارد می‌توانند به عنوان بخشی از فرآیند Static Testing استفاده شوند.

اما باید توجه داشت که Definition of Ready یک الزام عمومی Agile یا یک نوع Review در ISTQB نیست؛ بلکه یک Practice است که برخی تیم‌ها برای آماده بودن Work Item استفاده می‌کنند.

۱۷.۵ Static Testing در زمان Development

Static Testing بعد از شروع Development نیز ادامه دارد.

Developer
   ↓
Pull Request
   ↓
Code Review
   ↓
Static Analysis
   ↓
Fix
   ↓
Re-review
   ↓
Merge

در این مرحله Code Review، Static Analysis، بررسی Coding Standard و بررسی Security Findings می‌توانند بخشی از Static Testing باشند.

۱۷.۶ نقش Tester در Code Review در Agile

Tester لزوماً جای Developer را در Code Review نمی‌گیرد، اما در شرایط مناسب می‌تواند از زاویه کیفیت و Testability به Code یا Design نگاه کند.

• آیا این تغییر امکان تست کردن Error Scenario را فراهم می‌کند؟
• آیا این تغییر رفتار API را با Acceptance Criteria سازگار نگه می‌دارد؟
• آیا این تغییر روی یک سناریوی موجود تأثیر می‌گذارد؟

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

۱۷.۷ Static Analysis در CI/CD

در تیم‌های Agile مدرن، Static Analysis می‌تواند به صورت خودکار در Pipeline قرار گیرد.

Pull Request
      ↓
Build
      ↓
Static Analysis
      ↓
Quality Gate
   ↙       ↘
 Pass      Fail
  ↓          ↓
Continue    Fix

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

۱۷.۸ Static Testing و Sprint

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

ابتدای Sprint

User Story
    ↓
Refinement
    ↓
Review

هنگام Development

Design
    ↓
Technical Review
    ↓
Development

هنگام آماده شدن Code

Code
    ↓
Code Review
    ↓
Static Analysis

بعد از Build

Build
    ↓
Dynamic Testing

بنابراین Static Testing می‌تواند در طول Sprint چندین بار اتفاق بیفتد.

۱۷.۹ آیا Sprint Review همان Static Testing است؟

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

Sprint Review یک رویداد Agile برای بررسی Increment و دریافت Feedback از Stakeholderهاست.

اما Review در مفهوم Static Testing، بررسی یک Work Product برای شناسایی Anomalyها و ارزیابی کیفیت آن است.

ممکن است در Sprint Review درباره کیفیت یا مشکلات محصول صحبت شود، اما این موضوع به این معنی نیست که Sprint Review یکی از چهار Review Type تعریف‌شده در ISTQB است.

• Informal Review
• Walkthrough
• Technical Review
• Inspection

بنابراین صرف وجود کلمه Review به معنی یکی بودن دو مفهوم نیست.

۱۷.۱۰ Static Testing و Acceptance Criteria

Acceptance Criteria در Agile اهمیت زیادی دارد.

User can upload a profile picture.

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

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

هرچه این موارد زودتر مشخص شوند، Test Design بعدی نیز دقیق‌تر خواهد بود.

به همین دلیل Static Testing می‌تواند مستقیماً روی کیفیت Test Cases و Test Coverage اثر بگذارد.

۱۷.۱۱ Static Testing و مثال یک Sprint واقعی

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

User can transfer money to another account.

مرحله ۱ — Backlog Refinement

Tester متوجه می‌شود رفتار Transfer در صورت Timeout مشخص نیست و Finding مطرح می‌شود.

مرحله ۲ — Requirement اصلاح می‌شود

Business Rule اضافه می‌شود:

If the transaction status is unknown, the system must not create a duplicate transaction.

مرحله ۳ — Design Review

تیم بررسی می‌کند که چگونه از Duplicate Transaction جلوگیری شود.

مرحله ۴ — Development

Developer Feature را پیاده‌سازی می‌کند.

مرحله ۵ — Code Review

Code توسط اعضای تیم بررسی می‌شود.

مرحله ۶ — Static Analysis

Pipeline کد را بررسی می‌کند.

مرحله ۷ — Dynamic Testing

• Successful Transfer
• Insufficient Balance
• Invalid Account
• Timeout
• Duplicate Request
• Network Failure

در این مثال، Static Testing و Dynamic Testing در کنار هم قرار گرفته‌اند.

۱۷.۱۲ Static Testing در Agile فقط برای Tester نیست

در Agile کیفیت یک مسئولیت مشترک است.

Product Owner: روی نیاز کسب‌وکار و Acceptance Criteria تمرکز می‌کند.

Business Analyst: روی Requirement و Business Rules تمرکز می‌کند.

Developer: روی Design، Code و Technical Quality تمرکز می‌کند.

Tester: روی Testability، سناریوها، ریسک‌ها و کیفیت قابل آزمون تمرکز می‌کند.

Security Specialist: روی Security Requirements و Riskهای امنیتی تمرکز می‌کند.

این افراد می‌توانند در یک Review مشترک، مشکلات متفاوتی را پیدا کنند.

۱۷.۱۳ مهم‌ترین تفاوت Agile با رویکردهای سنتی

نباید این تصور را ایجاد کنیم که Static Testing فقط در Agile انجام می‌شود. در Waterfall نیز Static Testing می‌تواند در مراحل مختلف انجام شود.

تفاوت مهم این است که در Agile، به دلیل چرخه‌های کوتاه و Incremental Development، Review و Feedback معمولاً مکررتر و نزدیک‌تر به جریان روزانه توسعه اتفاق می‌افتند.

Waterfall

Requirements → Review
Design       → Review
Code         → Review
Testing

Agile

Story → Review → Development → Test
Story → Review → Development → Test
Story → Review → Development → Test

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

۱۷.۱۴ Static Testing در Agile و Shift-Left

Shift-Left
    ↓
Find Problems Earlier
    ↓
Static Testing
    ↓
Early Feedback
    ↓
Less Rework

اما Shift-Left به معنی این نیست که همه Testing باید فقط قبل از Development انجام شود. هدف این است که فعالیت‌های مناسب کیفیت، تا حد امکان زودتر و در طول فرآیند انجام شوند.

بنابراین حتی در Agile:

Static Testing و Dynamic Testing هر دو لازم‌اند و مکمل یکدیگر هستند.

۱۷.۱۵ جمع‌بندی

Backlog
   ↓
User Story Review
   ↓
Acceptance Criteria Review
   ↓
Design Review
   ↓
Code Review
   ↓
Static Analysis
   ↓
Dynamic Testing
   ↓
Feedback
   ↓
Improvement

نقش مهم Tester این است که منتظر آماده شدن Software نماند.

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

به همین دلیل، Static Testing در Agile را بهتر است یک فعالیت پیوسته برای دریافت Feedback زودهنگام و افزایش کیفیت Work Productها بدانیم، نه یک مرحله جداگانه قبل از Dynamic Testing.

۱۸. جمع‌بندی؛ Static Testing را چگونه در پروژه استفاده کنیم؟

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

این رویکرد به ما کمک می‌کند قبل از اینکه مشکلات Work Productها به Failure در زمان اجرای Software تبدیل شوند، آن‌ها را شناسایی و اصلاح کنیم.

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

۱۸.۱ مهم‌ترین مفاهیمی که یاد گرفتیم

۱. Static Testing بدون اجرای Software انجام می‌شود

در Static Testing، Work Product بدون اجرای Software مورد بررسی قرار می‌گیرد.

• Requirements
• User Stories
• Acceptance Criteria
• Design
• Source Code
• Testware
• Documentation

۲. Static Testing فقط Review نیست

Static Testing
│
├── Reviews
│   ├── Informal Review
│   ├── Walkthrough
│   ├── Technical Review
│   └── Inspection
│
└── Static Analysis

بنابراین Review و Static Analysis دو مسیر مهم برای انجام Static Testing هستند.

۳. Review الزاماً یک جلسه رسمی نیست

Review می‌تواند بسیار ساده باشد. مثلاً Tester یک User Story را می‌خواند و متوجه می‌شود رفتار سیستم در صورت ورود Password اشتباه مشخص نشده است.

این خودش می‌تواند بخشی از Static Testing باشد. از طرف دیگر، در پروژه‌های حساس می‌توان Review را با فرآیند رسمی‌تر، نقش‌های مشخص و مستندسازی دقیق انجام داد.

۴. چهار Review Type در ISTQB را باید بشناسیم

Review Type	ویژگی اصلی
Informal Review	کمترین Formality
Walkthrough	هدایت توسط Author
Technical Review	تمرکز بیشتر بر جنبه‌های فنی
Inspection	ساختاریافته و رسمی

انتخاب نوع Review به عواملی مانند Risk، Complexity، Criticality و نیاز پروژه بستگی دارد.

۱۸.۲ مهم‌ترین نقش Tester در Static Testing

یکی از مهم‌ترین مهارت‌های Tester در Static Testing، پرسیدن سؤال‌های درست است.

User can reset the password.

• Password جدید چه قوانینی دارد؟
• Email نامعتبر چه می‌شود؟
• اگر کاربر وجود نداشته باشد چه؟
• Reset Link چه مدت اعتبار دارد؟
• اگر Link منقضی شود چه؟
• آیا Sessionهای قبلی باید Invalid شوند؟
• آیا این Requirement قابل Test است؟

گاهی ارزش یک Tester در Static Testing بیشتر از پیدا کردن یک اشتباه مشخص، در آشکار کردن چیزهایی است که هنوز درباره آن‌ها تصمیم گرفته نشده است.

۱۸.۳ Static Testing و Shift-Left

Requirement
   ↓
Static Testing
   ↓
Finding
   ↓
Fix
   ↓
Development

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

البته هدف Shift-Left حذف Dynamic Testing نیست؛ بلکه هدف، پیدا کردن مشکلات مناسب در زمانی زودتر از چرخه توسعه است.

۱۸.۴ Static Testing و Dynamic Testing مکمل یکدیگرند

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

Static Testing

• Requirementهای مبهم
• Requirementهای ناقص
• تناقض‌ها
• مشکلات Design
• بعضی Coding Defectها
• مشکلات Testware

Dynamic Testing

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

Input
  ↓
Software Execution
  ↓
Actual Result
  ↓
Compare with Expected Result

Static Testing
      +
Dynamic Testing
      ↓
More Complete Testing Approach

۱۸.۵ Static Testing و Static Analysis را اشتباه نگیریم

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

Static Analysis یکی از روش‌های Static Testing است.

Static Testing
   │
   ├── Human Review
   │
   └── Static Analysis
          ↓
        Tools

• بررسی User Story توسط Tester → Review
• بررسی Pull Request توسط Developer → Code Review
• تحلیل خودکار Source Code → Static Analysis

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

۱۸.۶ در Agile، Static Testing یک فعالیت پیوسته است

در Agile لازم نیست Static Testing را به یک مرحله مشخص محدود کنیم.

• Backlog Refinement
• User Story Review
• Acceptance Criteria Review
• Design Review
• Code Review
• Static Analysis
• Testware Review

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

۱۸.۷ یک مدل ذهنی ساده برای Tester

                Work Product
                     │
                     ↓
              Static Testing
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
        Review            Static Analysis
          │                     │
          ↓                     ↓
     Human Thinking          Tool-based
          │                     │
          └──────────┬──────────┘
                     ↓
                  Findings
                     ↓
                  Analysis
                     ↓
              Fix / Decision
                     ↓
                Re-review
                     ↓
              Dynamic Testing
                     ↓
                Runtime Check

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

۱۸.۸ اگر بخواهیم از فردا Static Testing را شروع کنیم

برای یک Tester که می‌خواهد Static Testing را در پروژه واقعی وارد کار خود کند، لازم نیست از ابتدا یک فرآیند پیچیده ایجاد کند.

قدم اول: User Story را قبل از Development بخوان

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

قدم دوم: سؤال بپرس

Ambiguity
Missing Information
Inconsistency
Untestable Requirement
Missing Error Scenario
Missing Business Rule

قدم سوم: Findings را ثبت و با تیم بررسی کن

Finding را با Product Owner، BA، Developer یا افراد مرتبط مطرح کن. هدف پیدا کردن مقصر نیست؛ هدف روشن شدن موضوع است.

قدم چهارم: بعد از اصلاح، Re-review انجام بده

اگر Requirement یا Work Product تغییر کرد، نسخه جدید را دوباره بررسی کن.

قدم پنجم: بعد از آماده شدن Software، Dynamic Testing را انجام بده

Static Testing جای Dynamic Testing را نمی‌گیرد؛ بلکه کمک می‌کند Dynamic Testing روی یک مبنای باکیفیت‌تر انجام شود.

۱۸.۹ مهم‌ترین نکته مقاله

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

Testing از لحظه اجرای Software شروع نمی‌شود.

Testing می‌تواند از همان زمانی شروع شود که Requirement، User Story، Design یا Test Case نوشته می‌شود.

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

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

این همان جایی است که Static Testing به یکی از ابزارهای مهم یک رویکرد مدرن برای Software Quality تبدیل می‌شود.

۱۹. منابع

برای تهیه این مقاله و بررسی مفاهیم Static Testing، Review و Work Product Review از منابع زیر استفاده شده است:

1. ISTQB – Certified Tester Foundation Level (CTFL) Syllabus v4.0.1
   منبع اصلی مقاله برای مفاهیم Static Testing، Review، Static Analysis، Work Product، Review Process و نقش‌ها در Review.
   مشاهده Syllabus رسمی ISTQB CTFL v4.0.1
2. ISTQB – Certified Tester Foundation Level (CTFL) v4.0
   صفحه رسمی ISTQB درباره CTFL و سرفصل‌های نسخه 4.0، شامل بخش Static Testing و Feedback & Review Process.
   صفحه رسمی CTFL v4.0 در ISTQB
3. ISO/IEC 20246:2017 – Software and systems engineering — Work product reviews
   استاندارد بین‌المللی مربوط به Reviewهای Work Product که چارچوب عمومی، فعالیت‌ها، وظایف و مستندات مرتبط با Review را تعریف می‌کند.
   صفحه رسمی ISO/IEC 20246:2017 در ISO
4. ISTQB – CTFL v4.0 Help & Official Information
   اطلاعات رسمی ISTQB درباره نسخه 4.0، منابع آموزشی و نحوه استفاده از Syllabus و Sample Examهای رسمی.
   اطلاعات رسمی CTFL v4.0 در ISTQB

۲۰. سوالات متداول درباره Static Testing

Static Testing چیست؟

Static Testing مجموعه‌ای از فعالیت‌های تست است که در آن Work Productها بدون اجرای Software بررسی می‌شوند تا Defectها، ابهام‌ها، تناقض‌ها و سایر مشکلات شناسایی شوند. Review و Static Analysis دو روش مهم برای انجام Static Testing هستند.

آیا Static Testing فقط برای Requirementها انجام می‌شود؟

خیر. Requirement، User Story، Acceptance Criteria، Design، Source Code، Testware، API Specification و Documentation از جمله Work Productهایی هستند که می‌توانند در شرایط مناسب تحت Static Testing قرار بگیرند.

آیا Static Testing فقط قبل از Dynamic Testing انجام می‌شود؟

خیر. Static Testing می‌تواند در مراحل مختلف SDLC و حتی در طول Development انجام شود. برای مثال Requirement Review، Design Review، Code Review و Static Analysis می‌توانند در نقاط مختلف چرخه توسعه انجام شوند.

آیا Review و Static Testing یکسان هستند؟

خیر. Review یکی از روش‌های مهم Static Testing است. Static Testing مفهوم گسترده‌تری دارد و علاوه بر Review، Static Analysis را نیز شامل می‌شود.

چهار نوع Review در ISTQB کدام‌اند؟

چهار Review Type معرفی‌شده در CTFL عبارت‌اند از Informal Review، Walkthrough، Technical Review و Inspection.

آیا هر Finding در Static Testing یک Bug است؟

خیر. Finding ممکن است Defect، Ambiguity، Missing Information، Inconsistency، Question یا Recommendation باشد. بنابراین بهتر است ابتدا Finding تحلیل و Classification شود و سپس درباره اقدام مناسب تصمیم‌گیری شود.

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

خیر. Static Analysis یکی از روش‌های Static Testing است که معمولاً با استفاده از ابزارها انجام می‌شود و به‌خصوص برای Source Code کاربرد دارد. Static Testing مفهوم گسترده‌تری دارد و Reviewهای انسانی را نیز شامل می‌شود.

آیا Tester باید در Reviewهای Requirement شرکت کند؟

در بسیاری از پروژه‌ها مشارکت Tester در Review Requirement و User Story می‌تواند ارزشمند باشد، زیرا Tester می‌تواند از دیدگاه Testability، سناریوهای خطا، Boundaryها، Business Rules و ریسک‌های تست‌پذیری سؤال‌های مهمی مطرح کند. این موضوع به ساختار و فرآیند هر تیم نیز بستگی دارد.

آیا Static Testing در Agile هم انجام می‌شود؟

بله. Static Testing در Agile می‌تواند در فعالیت‌هایی مانند Backlog Refinement، User Story Review، Acceptance Criteria Review، Design Review، Code Review و Static Analysis انجام شود. در Agile این فعالیت‌ها معمولاً به شکل پیوسته و در جریان کار تیم اتفاق می‌افتند.

آیا Static Testing جایگزین Dynamic Testing می‌شود؟

خیر. Static Testing و Dynamic Testing مکمل یکدیگر هستند. Static Testing می‌تواند بسیاری از مشکلات Work Product را قبل از اجرای Software شناسایی کند، اما برای بررسی رفتار واقعی Software و کشف برخی Failureها به Dynamic Testing نیاز داریم.

چرا Re-review بعد از اصلاح مهم است؟

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

آیا Checklist می‌تواند جایگزین تجربه و تحلیل Tester شود؟

خیر. Checklist باید به Tester کمک کند موارد مهم را فراموش نکند، اما نباید جایگزین تحلیل، شناخت Business Context و تفکر انتقادی شود. یک Tester حرفه‌ای باید بتواند بر اساس Context پروژه سؤال‌های جدیدی نیز مطرح کند.