آموزش تست نرم افزار؛ از کجا شروع کنیم و چه مسیری را ادامه دهیم؟

یادگیری تست نرم افزار (Software Testing) فقط به یاد گرفتن چند ابزار، نوشتن تست‌کیس یا پیدا کردن باگ محدود نمی‌شود. یک تستر حرفه‌ای باید بداند نرم افزار چگونه توسعه پیدا می‌کند، نیازمندی چیست، چگونه باید تست طراحی کرد، Defectها چگونه مدیریت می‌شوند و هر نوع تست چه زمانی و با چه هدفی مورد استفاده قرار می‌گیرد.

به همین دلیل، اگر قصد دارید تست نرم افزار را از صفر یاد بگیرید، احتمالاً با سؤال‌های زیادی روبه‌رو می‌شوید: از کجا شروع کنم؟ اول Manual Testing را یاد بگیرم یا Automation؟ آیا باید برنامه‌نویسی بلد باشم؟ چه زمانی سراغ API Testing و SQL بروم؟ Test Case و Test Design چه ارتباطی با هم دارند؟ و در نهایت برای ورود به بازار کار باید چه مهارت‌هایی داشته باشم؟

این مقاله قرار نیست جای تمام آموزش‌های تخصصی را بگیرد. هدف آن این است که یک مسیر یادگیری تست نرم افزار در اختیار شما قرار دهد؛ مسیری که از مفاهیم پایه شروع می‌شود و قدم‌به‌قدم به Manual Testing، Web Testing، API Testing، Database، Automation Testing و مسیرهای تخصصی‌تر می‌رسد.

در هر مرحله، ابتدا مفهوم و جایگاه آن را در مسیر یادگیری بررسی می‌کنیم و سپس شما را به آموزش‌های تخصصی‌تر همان موضوع هدایت می‌کنیم. بنابراین می‌توانید این صفحه را به‌عنوان یک نقشه راه (Roadmap) برای یادگیری Software Testing در نظر بگیرید.

مسیر یادگیری تست نرم افزار در یک نگاه 🧭

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

Testing Fundamentals
↓
SDLC، STLC و Agile
↓
Requirements و مستندات نرم افزار
↓
Test Levels و Test Types
↓
Test Design Techniques
↓
Test Case و Test Execution
↓
Bug Reporting و Defect Management
↓
Manual و Exploratory Testing
↓
Web، API و Database Testing
↓
QA Process و Test Management
↓
Automation Testing
↓
مسیر تخصصی موردنظر شما

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

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

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

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

برای مثال، وقتی یک Tester بتواند یک Requirement را تحلیل کند، شرایط مختلف آن را شناسایی کند، Test مناسب طراحی کند و نتیجه را با رفتار مورد انتظار مقایسه کند، یادگیری Automation برای او معنا و کاربرد بیشتری پیدا می‌کند.

در این مسیر چه چیزی یاد می‌گیریم؟

• مبانی Software Testing: مفاهیم پایه، هدف Testing و ارتباط آن با Software Quality.
• فرآیند توسعه و تست: آشنایی با SDLC، STLC و روش‌های توسعه مانند Agile و Scrum.
• Requirements: یادگیری مفاهیمی مانند Requirement، BRD، SRS، PRD، FRD، User Story و Acceptance Criteria.
• Test Levels و Test Types: شناخت جایگاه Unit، Integration، System، Acceptance، Functional و Non-Functional Testing و سایر انواع مهم تست.
• Test Design: یادگیری روش‌هایی که به Tester کمک می‌کنند Test Caseهای مؤثرتر و پوشش تست مناسب‌تری طراحی کند.
• Test Execution و Bug Reporting: آشنایی با اجرای تست، ثبت نتیجه و گزارش Defect.
• Manual و Exploratory Testing: ساختن مهارت‌های عملی پایه برای انجام Testing بدون وابستگی به Automation.
• Web، API و Database Testing: گسترش مهارت‌های Testing برای سیستم‌های واقعی و معماری‌های مختلف.
• QA و Test Management: آشنایی با فرآیندها، مستندات و فعالیت‌هایی که Testing را در سطح تیم و پروژه سازمان‌دهی می‌کنند.
• Automation Testing: ورود به تست خودکار، برنامه‌نویسی، ابزارهای Automation و در ادامه CI/CD.
• مسیرهای تخصصی: انتخاب حوزه‌ای مانند Automation، API و Microservices، Performance، Security یا سایر شاخه‌های تخصصی Testing.

حالا که تصویر کلی مسیر را داریم، بهتر است از اولین قدم شروع کنیم: درک درست از Software Testing و مفاهیم بنیادی آن.

مبانی تست نرم افزار (Software Testing Fundamentals)

قبل از اینکه وارد Test Case، Bug Report، Automation یا ابزارهای Testing شویم، باید یک سؤال اساسی را پاسخ دهیم: Software Testing دقیقاً چیست و چرا به آن نیاز داریم؟

تست نرم افزار (Software Testing) مجموعه‌ای از فعالیت‌ها برای ارزیابی یک سیستم نرم افزاری و بررسی این موضوع است که آیا رفتار آن با نیازمندی‌ها و انتظارات موردنظر مطابقت دارد یا خیر. Testing همچنین می‌تواند اطلاعات ارزشمندی درباره کیفیت، ریسک‌ها و مشکلات احتمالی محصول در اختیار تیم قرار دهد.

اما Testing فقط به معنی پیدا کردن Bug نیست. یک Tester باید بتواند رفتار مورد انتظار سیستم را درک کند، شرایط مختلف را بررسی کند، شواهد جمع‌آوری کند و درباره ریسک‌ها و نتایج تست اطلاعات قابل اتکایی ارائه دهد.

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

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

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

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

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

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

Software Quality چه ارتباطی با Testing دارد؟

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

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

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

QA، QC و Software Testing چه تفاوتی دارند؟

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

• QA (Quality Assurance): بیشتر بر ایجاد و بهبود فرآیندها و روش‌هایی تمرکز دارد که احتمال تولید محصول باکیفیت را افزایش می‌دهند.
• QC (Quality Control): بیشتر بر بررسی خروجی محصول و شناسایی مشکلات و عدم انطباق‌ها تمرکز دارد.
• Software Testing: مجموعه فعالیت‌هایی برای ارزیابی و بررسی نرم افزار و کسب اطلاعات درباره کیفیت و ریسک‌های آن است.

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

برای بررسی دقیق‌تر این تفاوت، می‌توانید به مقاله QA vs QC مراجعه کنید.

Error، Defect و Failure؛ سه مفهوم پایه در Testing

یکی دیگر از پایه‌های مهم در یادگیری Software Testing، شناخت تفاوت میان Error، Defect و Failure است. این اصطلاحات گاهی در گفتگوهای روزمره به‌جای Bug یا حتی یکدیگر استفاده می‌شوند، اما در مباحث Testing تفاوت مفهومی دارند.

• Error: یک اقدام یا وضعیت نادرست انسانی که می‌تواند باعث ایجاد مشکل در نرم افزار شود.
• Defect: نقص موجود در یک Work Product یا نرم افزار که می‌تواند باعث شود سیستم رفتاری متفاوت از رفتار مورد انتظار داشته باشد.
• Failure: زمانی که سیستم هنگام اجرا نتواند رفتار مورد انتظار خود را ارائه دهد.

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

درک این تفاوت‌ها بعدها هنگام یادگیری Bug Reporting، Defect Management، Root Cause Analysis و Retesting اهمیت بیشتری پیدا می‌کند. برای بررسی کامل‌تر این مفاهیم، مقاله خطا(Error) نقص(Defect) خرابی (Failure) دقیقا چیست؟ را مطالعه کنید.

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم Software Testing چیست و چه هدفی دارد.
• تفاوت میان پیدا کردن Bug و ارزیابی کیفیت و ریسک محصول را درک کنیم.
• ارتباط Testing با Software Quality را بشناسیم.
• تفاوت مفهومی QA، QC و Testing را بدانیم.
• مفهوم Error، Defect و Failure را از یکدیگر تشخیص دهیم.
• بدانیم Testing فقط بررسی مسیرهای موفق و Happy Path نیست.
• درک کنیم که هدف Testing صرفاً اثبات «نرم افزار بدون Bug است» نیست؛ بلکه کسب اطلاعات قابل اتکا درباره رفتار، کیفیت و ریسک‌های محصول است.

چرخه توسعه نرم افزار، STLC و جایگاه تست در پروژه

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

به همین دلیل، قدم بعدی در مسیر یادگیری تست نرم افزار، آشنایی با چرخه توسعه نرم افزار (SDLC) و چرخه تست نرم افزار (STLC) است.

SDLC چیست؟

SDLC یا Software Development Life Cycle به چرخه‌ای گفته می‌شود که طی آن یک نرم افزار از ایده و نیازمندی اولیه به سمت طراحی، توسعه، تست، انتشار و نگهداری حرکت می‌کند.

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

نیازمندی‌ها → تحلیل و طراحی → توسعه → تست → انتشار → نگهداری

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

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

STLC چیست؟

STLC یا Software Testing Life Cycle چرخه فعالیت‌های مرتبط با تست نرم افزار است. این چرخه کمک می‌کند فعالیت‌های تست به‌صورت منظم و هدفمند انجام شوند و تیم تست بداند در هر مرحله چه کاری باید انجام دهد و چه خروجی‌ای انتظار می‌رود.

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

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

جایگاه تستر از چه زمانی شروع می‌شود؟

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

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

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

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

Agile و Scrum چه ارتباطی با تست نرم افزار دارند؟

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

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

در چنین محیطی، تستر باید بتواند هم‌زمان با پیشرفت توسعه کار کند و فعالیت‌هایی مانند بررسی داستان کاربر(User Story)، بررسی معیارهای پذیرش (Acceptance Criteria)، طراحی تست، اجرای تست، گزارش باگ و تست مجدد را در چرخه توسعه انجام دهد.

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

تست در SDLC و STLC چه مسیری را طی می‌کند؟

اگر SDLC و STLC را کنار یکدیگر قرار دهیم، تصویر ساده‌ای از مسیر کاری تستر به دست می‌آید:

نیازمندی
↓
تحلیل نیازمندی و شناسایی شرایط تست
↓
طراحی تست سناریو و تست کیس
↓
آماده‌سازی داده و محیط تست
↓
اجرای تست
↓
گزارش باگ
↓
رفع باگ و تست مجدد
↓
تست رگرسیون
↓
گزارش نتایج و وضعیت کیفیت

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم SDLC چیست و تست نرم افزار چه جایگاهی در چرخه توسعه دارد.
• با مفهوم STLC و فعالیت‌های اصلی چرخه تست آشنا باشیم.
• بدانیم فعالیت تست فقط به اجرای تست کیس محدود نمی‌شود.
• اهمیت مشارکت تستر در مراحل ابتدایی پروژه و بررسی نیازمندی‌ها را درک کنیم.
• با نقش Agile و Scrum در نحوه انجام فعالیت‌های تست آشنا باشیم.
• ارتباط میان نیازمندی، سناریو تست، تست کیس، اجرای تست، گزارش باگ، تست مجدد و تست رگرسیون را درک کنیم.

نیازمندی‌ها و مستندات نرم افزار (Requirements & Documentation)

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

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

چرا Requirement برای تستر مهم است؟

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

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

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

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

انواع و سطوح مختلف نیازمندی

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

• Business Requirement: بیان‌کننده نیاز یا هدف کسب‌وکار.
• User یا System Requirement: بیان دقیق‌تر چیزی که کاربر یا سیستم باید ارائه دهد.
• Functional Requirement: مشخص می‌کند سیستم چه کاری باید انجام دهد.
• Non-Functional Requirement: ویژگی‌ها و محدودیت‌هایی مانند کارایی، امنیت، قابلیت استفاده یا قابلیت اطمینان را مشخص می‌کند.

این مفاهیم در مستنداتی مانند BRD، SRS، PRD و FRD نیز دیده می‌شوند و شناخت آن‌ها به تستر کمک می‌کند ارتباط میان نیاز کسب‌وکار، رفتار مورد انتظار سیستم و تست‌های موردنیاز را بهتر درک کند.

User Story و Acceptance Criteria

در تیم‌هایی که با Agile و Scrum کار می‌کنند، بخشی از نیازمندی‌ها ممکن است در قالب User Story بیان شوند. User Story معمولاً نیاز یک کاربر یا ذی‌نفع را از زاویه دید او بیان می‌کند.

اما برای تستر، خود User Story همیشه برای طراحی تست کافی نیست. Acceptance Criteria یا معیارهای پذیرش شرایطی را مشخص می‌کنند که باید برقرار باشند تا بتوان گفت یک User Story معیارهای مورد انتظار را برآورده کرده است.

برای مثال:

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

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

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

تستر در پروژه واقعی معمولاً فقط با یک فایل Requirement کار نمی‌کند. بسته به پروژه ممکن است با BRD، SRS، PRD، FRD، User Story، Acceptance Criteria، مستندات API، مستندات فنی و سایر مستندات محصول سروکار داشته باشد.

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

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

از نیازمندی تا تست کیس چه اتفاقی می‌افتد؟

یکی از مهم‌ترین زنجیره‌هایی که باید در ابتدای مسیر یادگیری تست نرم افزار در ذهن داشته باشید، این است:

Requirement
↓
Test Scenario
↓
Test Case
↓
Test Data
↓
Test Execution
↓
Expected Result / Actual Result
↓
Pass / Fail

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

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم Requirement یا نیازمندی چیست و چرا پایه مهمی برای طراحی تست محسوب می‌شود.
• تفاوت کلی نیازمندی‌های کسب‌وکار، کاربر، سیستمی، Functional و Non-Functional را درک کنیم.
• با نقش BRD، SRS، PRD و FRD در مستندسازی نیازمندی‌ها آشنا باشیم.
• مفهوم User Story و Acceptance Criteria را بشناسیم.
• بتوانیم از یک نیازمندی، شرایط و سناریوهای قابل‌تست را شناسایی کنیم.
• ارتباط میان Requirement → Test Scenario → Test Case → Test Data → Test Execution را درک کنیم.
• بدانیم یک تستر فقط اجراکننده تست نیست و تحلیل نیازمندی و شناسایی ابهام‌ها نیز بخشی مهم از فعالیت اوست.

سطوح تست و انواع تست نرم افزار (Test Levels & Test Types)

حالا که با نیازمندی‌ها و ارتباط آن‌ها با طراحی تست آشنا شدیم، باید یاد بگیریم که تست‌ها را چگونه دسته‌بندی کنیم و هر تست چه هدفی دارد. اینجا یکی از بخش‌هایی قرار دارد که در ابتدای مسیر ممکن است کمی گیج‌کننده باشد؛ چون اصطلاحاتی مانند Unit، Integration، System، Functional، Regression و Acceptance همگی به تست مربوط هستند، اما دقیقاً یک نوع دسته‌بندی را نشان نمی‌دهند.

برای جلوگیری از این سردرگمی، ابتدا باید تفاوت میان سطح تست (Test Level) و نوع تست (Test Type) را درک کنیم.

سطح تست (Test Level) چیست؟

سطح تست مشخص می‌کند چه بخش یا محدوده‌ای از نرم افزار در حال تست است. به‌صورت کلی، در مسیر یادگیری تست نرم افزار با سطوحی مانند Unit، Integration، System و Acceptance Testing روبه‌رو می‌شویم.

• Unit Testing: بررسی یک واحد کوچک از نرم افزار، معمولاً در سطح کد یا یک جزء مستقل.
• Integration Testing: بررسی تعامل و ارتباط میان اجزا، ماژول‌ها یا سیستم‌های مختلف.
• System Testing: بررسی سیستم یکپارچه در برابر نیازمندی‌های مشخص‌شده.
• Acceptance Testing: بررسی اینکه آیا سیستم برای پذیرش توسط مشتری، کسب‌وکار یا سایر ذی‌نفعان معیارهای موردنظر را برآورده می‌کند یا خیر.

برای مثال، در یک فروشگاه اینترنتی ممکن است ابتدا منطق محاسبه قیمت یک محصول به‌صورت Unit Test بررسی شود، سپس ارتباط سرویس سبد خرید با سرویس موجودی در Integration Testing تست شود و در ادامه کل فرآیند خرید در سطح سیستم بررسی شود.

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

نوع تست (Test Type) چیست؟

نوع تست بیشتر به هدف یا جنبه‌ای اشاره می‌کند که می‌خواهیم با تست بررسی کنیم. یکی از تقسیم‌بندی‌های مهم در این زمینه، Functional Testing و Non-Functional Testing است.

• Functional Testing: بررسی می‌کند سیستم چه کارهایی را انجام می‌دهد و آیا عملکردهای آن مطابق نیازمندی‌های موردنظر هستند یا خیر.
• Non-Functional Testing: ویژگی‌ها و جنبه‌هایی از سیستم مانند کارایی، امنیت، قابلیت استفاده و قابلیت اطمینان را بررسی می‌کند.

برای مثال، در یک صفحه ورود، بررسی اینکه کاربر با نام کاربری و رمز عبور صحیح وارد حساب خود می‌شود، یک بررسی Functional است. اما بررسی اینکه همین صفحه در زمان ورود هم‌زمان تعداد زیادی کاربر همچنان عملکرد قابل‌قبولی دارد، در حوزه Non-Functional و به‌طور مشخص Performance Testing قرار می‌گیرد.

چند تست مهم که باید در این مرحله بشناسیم

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

• Smoke Testing: بررسی اولیه و سریع قابلیت‌های اصلی برای اطمینان از اینکه Build برای ادامه تست مناسب است.
• Sanity Testing: در اصطلاحات ISTQB فعلی، با Smoke Test به‌عنوان یک اصطلاح مترادف مطرح می‌شود؛ با این حال، در بسیاری از تیم‌ها Sanity برای بررسی محدودتر پس از یک تغییر یا اصلاح نیز به‌کار می‌رود.
• Regression Testing: بررسی بخش‌های مرتبط و موجود سیستم برای اطمینان از اینکه تغییرات جدید باعث ایجاد مشکل در قابلیت‌های قبلی نشده‌اند.
• Retesting: اجرای دوباره تست مربوط به یک مشکل اصلاح‌شده برای بررسی اینکه آیا مشکل موردنظر واقعاً برطرف شده است یا خیر.
• End-to-End Testing: بررسی یک جریان کامل کسب‌وکار یا کاربر از ابتدا تا انتها، که می‌تواند بخش‌های مختلف سیستم و حتی چند سرویس را درگیر کند.
• Acceptance Testing: ارزیابی محصول یا قابلیت در برابر معیارهای پذیرش و نیازهای پذیرش‌شده.

نکته مهم این است که این اصطلاحات الزاماً در یک دسته قرار نمی‌گیرند. برای مثال، Regression Testing و Retesting را نباید با Test Levelهایی مانند Unit یا System یکی دانست. هرکدام از این اصطلاحات زاویه متفاوتی از فعالیت تست را توصیف می‌کنند.

یک مثال برای درک تفاوت‌ها

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

• تست منطق اعتبارسنجی رمز عبور می‌تواند در سطح Unit Testing انجام شود.
• بررسی ارتباط سرویس تغییر رمز عبور با سرویس احراز هویت می‌تواند در Integration Testing انجام شود.
• بررسی کامل فرآیند تغییر رمز عبور از رابط کاربری تا ثبت تغییرات می‌تواند بخشی از System یا End-to-End Testing باشد.
• بررسی اینکه قابلیت جدید طبق معیارهای پذیرش مورد انتظار کار می‌کند، می‌تواند در Acceptance Testing انجام شود.
• بررسی اینکه قابلیت‌های قبلی مانند ورود و بازیابی رمز عبور بعد از این تغییر همچنان درست کار می‌کنند، بخشی از Regression Testing است.
• اگر تیم اعلام کند یک مشکل مشخص در تغییر رمز عبور اصلاح شده، اجرای دوباره تست همان مشکل برای بررسی اصلاح آن، Retesting است.

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• تفاوت میان Test Level و Test Type را درک کنیم.
• سطوح اصلی تست شامل Unit، Integration، System و Acceptance Testing را بشناسیم.
• تفاوت کلی Functional و Non-Functional Testing را بدانیم.
• هدف و کاربرد اولیه Smoke، Sanity، Regression و Retesting را بشناسیم.
• بدانیم End-to-End Testing برای بررسی جریان‌های کامل سیستم استفاده می‌شود.
• درک کنیم که یک قابلیت می‌تواند در چند سطح و با چند هدف متفاوت تست شود.
• بدانیم برای شروع مسیر Testing لازم نیست تمام انواع تست را عمیق یاد بگیریم؛ ابتدا باید دسته‌بندی، هدف و جایگاه آن‌ها را درک کنیم.

طراحی تست (Test Design) چیست؟

بعد از آشنایی با مبانی تست نرم افزار، یکی از مفاهیم مهمی که باید یاد بگیرید طراحی تست (Test Design) است. طراحی تست به فرایندی گفته می‌شود که طی آن تستر مشخص می‌کند چه شرایطی باید بررسی شوند و چگونه می‌توان Test Caseهای مناسب برای ارزیابی نرم افزار طراحی کرد.

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

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

در طراحی تست، تکنیک‌های طراحی تست نقش مهمی دارند. تکنیک‌های تست به تستر کمک می‌کنند Test Conditions و Test Caseها را به شکل ساختاریافته‌تر و مؤثرتری انتخاب کند.

اگر می‌خواهید فرایند طراحی تست، اجزای آن و نحوه تبدیل Requirements به Test Case را به‌صورت کامل یاد بگیرید، مقاله طراحی تست (Test Design) چیست؟ را مطالعه کنید.

در ادامه، به سراغ تکنیک‌های طراحی تست (Test Techniques) می‌رویم؛ یعنی روش‌هایی که می‌توانند در طراحی تست و انتخاب شرایط مناسب برای تست به کار گرفته شوند.

تکنیک‌های طراحی تست (Test Design Techniques)

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

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

به این روش‌ها تکنیک‌های طراحی تست (Test Design Techniques) گفته می‌شود. این تکنیک‌ها به تستر کمک می‌کنند شرایط تست، داده‌های تست و تست کیس‌های مناسب‌تری را از روی نیازمندی‌ها و سایر اطلاعات موجود استخراج کند.

چرا Test Design Technique اهمیت دارد؟

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

یک تستر مبتدی ممکن است فقط یک سفارش ۱.۵ میلیون تومانی ایجاد کند و ببیند تخفیف اعمال می‌شود. اما آیا این تست برای بررسی قانون کافی است؟

احتمالاً نه. سؤال مهم این است که اگر مبلغ سفارش ۹۹۹ هزار تومان، دقیقاً ۱ میلیون تومان یا ۱ میلیون و یک تومان باشد چه اتفاقی می‌افتد؟

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

تکنیک‌های جعبه سیاه (Black-box Test Techniques)

در تکنیک‌های Black-box، تستر برای طراحی تست بیشتر بر رفتار مورد انتظار سیستم، نیازمندی‌ها، قوانین کسب‌وکار و ورودی و خروجی سیستم تمرکز می‌کند و برای طراحی تست لزوماً نیازی به دانستن جزئیات کد داخلی ندارد.

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

• Equivalence Partitioning: تقسیم ورودی‌ها به گروه‌هایی که انتظار می‌رود سیستم در برابر آن‌ها رفتار مشابهی داشته باشد.
• Boundary Value Analysis: تمرکز بر مقادیر مرزی، جایی که احتمال بروز خطا معمولاً اهمیت بیشتری دارد.
• Decision Table Testing: بررسی ترکیب شرایط و نتایج مختلف، به‌خصوص زمانی که چند قانون کسب‌وکار روی نتیجه تأثیر می‌گذارند.
• State Transition Testing: بررسی رفتار سیستم در حالت‌های مختلف و انتقال از یک حالت به حالت دیگر.
• Use Case Testing: طراحی تست بر اساس جریان‌های موجود در Use Caseها و تعامل کاربر یا سیستم با قابلیت موردنظر.

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

تکنیک‌های جعبه سفید (White-box Test Techniques)

در White-box Testing، اطلاعات مربوط به ساختار داخلی نرم افزار، کد، منطق برنامه یا مسیرهای اجرایی می‌تواند در طراحی تست مورد استفاده قرار گیرد.

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

• Statement Testing: طراحی تست با هدف اجرای دستورهای موجود در کد.
• Branch Testing: بررسی شاخه‌های مختلف تصمیم‌گیری در کد.
• Coverage: استفاده از معیارهای پوشش برای ارزیابی اینکه چه بخش‌هایی از ساختار کد توسط تست‌ها اجرا شده‌اند.

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

تکنیک‌های مبتنی بر تجربه (Experience-based Techniques)

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

• Error Guessing: استفاده از تجربه برای حدس زدن شرایطی که احتمال ایجاد خطا در آن‌ها بیشتر است.
• Exploratory Testing: یادگیری، طراحی تست و اجرای تست می‌توانند هم‌زمان و به‌صورت انعطاف‌پذیر انجام شوند؛ تستر بر اساس اطلاعاتی که در طول بررسی به دست می‌آورد، مسیر تست را نیز تغییر می‌دهد.

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

Test Level، Test Type و Test Technique را با هم اشتباه نگیریم

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

• Test Level: مشخص می‌کند چه سطحی از سیستم در حال تست است؛ مانند Unit، Integration، System و Acceptance.
• Test Type: هدف یا جنبه مورد بررسی را مشخص می‌کند؛ مانند Functional یا Non-Functional Testing.
• Test Design Technique: مشخص می‌کند برای طراحی تست‌ها از چه روشی استفاده می‌کنیم؛ مانند Equivalence Partitioning یا Boundary Value Analysis.

برای مثال، یک تست می‌تواند در System Testing انجام شود، هدف آن Functional Testing باشد و تست کیس‌های آن با استفاده از Boundary Value Analysis طراحی شده باشند. بنابراین این سه اصطلاح رقیب یکدیگر نیستند؛ بلکه جنبه‌های متفاوتی از یک فعالیت تست را توصیف می‌کنند.

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم تکنیک طراحی تست چیست و چرا برای طراحی تست کیس‌های مؤثر اهمیت دارد.
• با مفهوم کلی تکنیک‌های Black-box، White-box و Experience-based آشنا باشیم.
• تکنیک‌های مهمی مانند Equivalence Partitioning، Boundary Value Analysis، Decision Table و State Transition را بشناسیم.
• بدانیم تجربه تستر نیز می‌تواند در طراحی تست و شناسایی شرایط پرریسک نقش داشته باشد.
• تفاوت میان Test Level، Test Type و Test Design Technique را به‌درستی تشخیص دهیم.
• درک کنیم که هدف تکنیک‌های طراحی تست، انتخاب هوشمندانه تست‌ها و افزایش پوشش و اثربخشی تست است، نه صرفاً افزایش تعداد تست کیس‌ها.

تست کیس، سناریو تست و اجرای تست (Test Case & Test Execution)

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

در این مرحله با چند مفهوم بسیار مهم روبه‌رو می‌شویم: سناریو تست (Test Scenario)، تست کیس (Test Case)، داده تست (Test Data) و اجرای تست (Test Execution). این مفاهیم ارتباط نزدیکی با یکدیگر دارند، اما کاربردشان یکسان نیست.

سناریو تست چیست؟

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

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

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

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

تست کیس چیست؟

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

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

• Test Case ID: شناسه تست کیس
• Title یا Description: عنوان یا توضیح تست
• Precondition: پیش‌شرط‌های لازم برای اجرای تست
• Test Steps: مراحل انجام تست
• Test Data: داده‌های مورد استفاده
• Expected Result: نتیجه مورد انتظار
• Actual Result: نتیجه واقعی پس از اجرای تست
• Status: وضعیت تست مانند Pass یا Fail

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

تفاوت سناریو تست و تست کیس

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

Requirement
↓
Test Scenario
↓
Test Case
↓
Test Data
↓
Test Execution

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

داده تست (Test Data) چیست؟

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

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

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

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

اجرای تست (Test Execution)

بعد از آماده شدن تست کیس، محیط و داده‌های موردنیاز، تستر می‌تواند تست را اجرا کند. در این مرحله، نتیجه واقعی (Actual Result) با نتیجه مورد انتظار (Expected Result) مقایسه می‌شود.

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

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

یک تست کیس ساده در عمل

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

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

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

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

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

آیا همیشه باید تست کیس‌های رسمی داشته باشیم؟

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

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• تفاوت میان تست سناریو و تست کیس را درک کنیم.
• بدانیم یک تست کیس معمولاً چه اطلاعاتی را شامل می‌شود.
• مفهوم داده تست و اهمیت انتخاب داده‌های مناسب را بشناسیم.
• بدانیم هنگام اجرای تست باید نتیجه واقعی را با نتیجه مورد انتظار مقایسه کنیم.
• تفاوت میان وضعیت‌های Pass و Fail را درک کنیم.
• بدانیم Fail شدن تست همیشه به معنی وجود Defect در کد نیست و باید علت آن بررسی شود.
• درک کنیم که تست کیس یک ابزار برای ساختارمند کردن تست است و قالب و میزان مستندسازی آن می‌تواند با توجه به پروژه متفاوت باشد.

گزارش باگ و مدیریت نقص‌ها (Bug Reporting & Defect Management)

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

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

گزارش باگ (Bug Report) چیست؟

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

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

• عنوان: توضیح کوتاه و مشخص درباره مشکل
• محیط تست: مانند نسخه نرم افزار، مرورگر، سیستم‌عامل یا محیط اجرا
• پیش‌شرط: شرایط لازم برای مشاهده مشکل
• مراحل بازتولید: مراحلی که برای مشاهده دوباره مشکل انجام شده‌اند
• نتیجه مورد انتظار: سیستم چه رفتاری باید داشته باشد؟
• نتیجه واقعی: سیستم در عمل چه رفتاری نشان داده است؟
• Severity و Priority: اطلاعات مربوط به شدت و اولویت مشکل
• پیوست‌ها: در صورت نیاز، مانند Screenshot، Video، Log یا سایر شواهد

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

یک گزارش باگ خوب چه ویژگی‌هایی دارد؟

گزارش باگ خوب لزوماً طولانی نیست؛ بلکه واضح، دقیق، قابل بازتولید و مبتنی بر شواهد است.

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

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

Severity و Priority چه تفاوتی دارند؟

در مدیریت باگ معمولاً با دو مفهوم Severity و Priority روبه‌رو می‌شویم که نباید آن‌ها را یکی در نظر گرفت.

• Severity: میزان تأثیر یا شدت یک مشکل بر سیستم یا کسب‌وکار را توصیف می‌کند.
• Priority: نشان می‌دهد رفع یک مشکل از نظر ترتیب رسیدگی، چه میزان اهمیت یا فوریتی دارد.

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

چرخه عمر باگ (Bug Lifecycle)

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

New → Assigned → In Progress → Fixed → Retest → Closed

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

تست مجدد (Retesting) و تست رگرسیون (Regression Testing)

بعد از رفع یک باگ، دو مفهوم مهم وارد جریان تست می‌شوند: Retesting و Regression Testing.

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

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

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

Bug Report فقط برای پیدا کردن مقصر نیست

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

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم گزارش باگ چیست و چرا کیفیت آن برای تیم اهمیت دارد.
• بتوانیم اطلاعات اصلی موردنیاز برای یک گزارش باگ را شناسایی کنیم.
• تفاوت میان نتیجه مورد انتظار و نتیجه واقعی را در گزارش مشکل به‌درستی بیان کنیم.
• مفهوم Severity و Priority و تفاوت کلی آن‌ها را درک کنیم.
• با مفهوم چرخه عمر باگ آشنا باشیم.
• تفاوت تست مجدد (Retesting) و تست رگرسیون (Regression Testing) را بدانیم.
• درک کنیم که گزارش باگ یک ابزار ارتباطی برای کمک به تیم در حل مشکل است، نه ابزاری برای مقصر دانستن افراد.

تست دستی و تست اکتشافی (Manual & Exploratory Testing)

تا اینجا با مفاهیم پایه، نیازمندی‌ها، انواع و سطوح تست، تکنیک‌های طراحی تست، تست کیس و گزارش باگ آشنا شدیم. حالا می‌توانیم وارد یکی از مهم‌ترین مهارت‌های عملی در مسیر یادگیری تست نرم افزار شویم: تست دستی (Manual Testing).

تست دستی به این معناست که تستر بدون استفاده از اسکریپت‌های خودکار، رفتار نرم افزار را بررسی می‌کند. اما Manual Testing صرفاً کلیک کردن روی دکمه‌ها و پیدا کردن چند Bug نیست؛ تستر باید بر اساس نیازمندی‌ها، ریسک‌ها و تکنیک‌های طراحی تست، بررسی هدفمندی انجام دهد.

چرا یادگیری Manual Testing مهم است؟

حتی اگر هدف نهایی شما تبدیل شدن به یک Automation Tester باشد، درک درست Manual Testing اهمیت زیادی دارد. ابزار Automation به‌تنهایی نمی‌تواند مشخص کند چه چیزی ارزش تست کردن دارد یا آیا یک رفتار از نظر کسب‌وکار درست است.

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

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

تست دستی فقط اجرای تست کیس نیست

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

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

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

Exploratory Testing چیست؟

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

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

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

Manual Testing و Exploratory Testing یکی نیستند

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

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

تستر دستی چه مهارت‌هایی باید داشته باشد؟

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

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

بعد از شکل‌گیری این پایه‌ها، یادگیری ابزارهایی مانند ابزارهای مدیریت تست، مدیریت باگ، تست API یا ابزارهای Automation بسیار معنادارتر خواهد بود؛ چون ابزار را برای حل یک مسئله مشخص استفاده می‌کنید، نه صرفاً برای یادگیری خود ابزار.

در پایان این مرحله چه چیزهایی باید بلد باشیم؟

• بدانیم Manual Testing چیست و چرا پایه مهمی برای یادگیری تست نرم افزار محسوب می‌شود.
• بتوانیم نیازمندی را به تست سناریو و تست کیس تبدیل کنیم و تست را به‌صورت هدفمند اجرا کنیم.
• تفاوت میان Manual Testing و Exploratory Testing را درک کنیم.
• با مفهوم تست اکتشافی و نحوه تصمیم‌گیری تستر در حین اجرای آن آشنا باشیم.
• بتوانیم نتیجه تست را تحلیل و در صورت مشاهده مشکل، باگ را به‌درستی گزارش کنیم.
• بدانیم تستر دستی علاوه بر اجرای تست، به تحلیل، مشاهده، پرسشگری و شناسایی ریسک نیز نیاز دارد.

۱۰. تست نرم‌افزار در وب، رابط کاربری و جریان‌های End-to-End

بعد از یادگیری مبانی تست، نیازمندی‌ها، سطوح و انواع تست، تکنیک‌های طراحی تست و نحوه اجرای تست و گزارش باگ، یکی از مهم‌ترین محیط‌هایی که یک تستر با آن مواجه می‌شود، نرم‌افزارهای تحت وب (Web Applications) هستند.

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

به همین دلیل، یادگیری تست وب (Web Testing) برای بسیاری از تسترها یک نقطه مهم در مسیر یادگیری تست نرم‌افزار است. در این مرحله باید بتوانید رفتار نرم‌افزار را از دید کاربر بررسی کنید و در عین حال بدانید یک جریان کاربر چگونه از رابط کاربری تا Backend، API و Database ادامه پیدا می‌کند.

تست وب (Web Testing) چیست؟ 🌐

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

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

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

تست رابط کاربری (UI Testing)

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

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

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

البته UI Testing فقط به بررسی ظاهر محدود نمی‌شود. قابلیت استفاده (Usability)، دسترسی‌پذیری (Accessibility)، رفتار Responsive و سازگاری رابط کاربری در مرورگرها و دستگاه‌های مختلف نیز می‌توانند در ارزیابی یک رابط کاربری اهمیت داشته باشند.

تست End-to-End یا E2E چیست؟

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

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

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

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

نکته مهم این است که E2E Testing الزاماً فقط به رابط کاربری وابسته نیست. در معماری‌های مدرن ممکن است یک جریان End-to-End از چند سرویس و API عبور کند و حتی بدون تعامل مستقیم با UI نیز قابل بررسی باشد.

تست وب فقط بررسی ظاهر سایت نیست

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

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

• آیا قابلیت موردنظر مطابق Requirement کار می‌کند؟
• آیا داده واردشده توسط کاربر به‌درستی اعتبارسنجی می‌شود؟
• آیا پیام خطا و وضعیت سیستم برای کاربر قابل فهم است؟
• آیا رفتار سیستم در مرورگرهای مختلف یکسان یا قابل قبول است؟
• آیا صفحه در اندازه‌های مختلف نمایشگر به‌درستی کار می‌کند؟
• آیا دسترسی کاربران دارای محدودیت‌های مختلف به قابلیت‌ها به‌درستی کنترل می‌شود؟
• آیا ارتباط Frontend با API نتیجه مورد انتظار را ایجاد می‌کند؟
• آیا جریان کامل کاربر از ابتدا تا انتها بدون شکست اجرا می‌شود؟

یک مثال واقعی از تست وب

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

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

• UI Testing: آیا فیلد کد تخفیف و دکمه اعمال به‌درستی نمایش داده می‌شوند؟
• Functional Testing: آیا کد معتبر باعث اعمال تخفیف صحیح می‌شود؟
• Validation: سیستم با کد خالی، نامعتبر یا منقضی‌شده چه رفتاری دارد؟
• API Testing: آیا درخواست اعمال تخفیف و پاسخ API صحیح هستند؟
• Regression Testing: آیا اضافه شدن قابلیت تخفیف روی محاسبه مبلغ سفارش تأثیر منفی نگذاشته است؟
• E2E Testing: آیا کاربر می‌تواند از انتخاب محصول تا پرداخت نهایی، سفارش دارای تخفیف را با موفقیت تکمیل کند؟

این مثال نشان می‌دهد که یک قابلیت وب می‌تواند هم‌زمان از چند زاویه مختلف تست شود و UI، API، Functional، Regression و E2E لزوماً جایگزین یکدیگر نیستند؛ بلکه هرکدام بخشی از ریسک را پوشش می‌دهند.

مرورگر و ابزارهای توسعه‌دهنده (Browser DevTools)

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

تستر می‌تواند با استفاده از ابزارهای توسعه‌دهنده مرورگر، اطلاعاتی مانند درخواست‌های Network، پاسخ API، خطاهای Console، وضعیت عناصر صفحه، Cookieها و برخی اطلاعات مربوط به Storage را بررسی کند.

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• بدانید Web Testing چیست و چه تفاوتی با صرفاً بررسی ظاهر سایت دارد.
• مفهوم UI Testing و محدوده آن را درک کنید.
• بتوانید یک جریان واقعی کاربر را به‌صورت End-to-End تحلیل کنید.
• تفاوت UI Testing، Functional Testing و E2E Testing را در سطح مفهومی بدانید.
• با مفاهیمی مانند Responsive، Cross-Browser و Accessibility در حد آشنایی اولیه آشنا باشید.
• بدانید API و Backend چگونه می‌توانند بخشی از یک جریان وب باشند.
• با کاربردهای اصلی Browser DevTools برای بررسی مشکلات وب آشنا باشید.
• بتوانید برای یک قابلیت وب، Test Scenarioهای معنادار طراحی کنید.

۱۱. تست API و دیتابیس؛ بررسی منطق پشت رابط کاربری

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

در بسیاری از نرم‌افزارهای مدرن، چیزی که کاربر در رابط کاربری می‌بیند، نتیجه همکاری چند لایه مختلف است؛ Frontend درخواست را ارسال می‌کند، API آن درخواست را دریافت و پردازش می‌کند، سرویس‌های Backend منطق کسب‌وکار را اجرا می‌کنند و در نهایت ممکن است اطلاعات از Database خوانده یا در آن ذخیره شود.

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

تست API چیست؟ 🔌

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

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

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

در تست API چه چیزهایی بررسی می‌شوند؟

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

• درستی HTTP Method مانند GET، POST، PUT و DELETE
• صحت Request و پارامترهای ارسال‌شده
• HTTP Status Code مناسب
• ساختار و محتوای Response
• اعتبارسنجی داده‌های ورودی
• رفتار سیستم در برابر داده‌های نامعتبر یا ناقص
• احراز هویت (Authentication) و مجوز دسترسی (Authorization)
• مدیریت خطا و پیام‌های مربوط به آن
• درستی Business Ruleها در پاسخ API

بنابراین API Testing فقط به این سؤال محدود نمی‌شود که «آیا API پاسخ می‌دهد؟». سؤال مهم‌تر این است که آیا API در شرایط مختلف، رفتار مورد انتظار سیستم را اجرا می‌کند؟

یک مثال ساده از تست API

فرض کنید API مربوط به ورود کاربر، اطلاعات ایمیل و رمز عبور را دریافت می‌کند.

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

• ورود با اطلاعات صحیح
• ورود با رمز عبور اشتباه
• ارسال ایمیل خالی
• ارسال رمز عبور خالی
• ارسال اطلاعات ناقص
• ارسال داده با فرمت نامعتبر
• بررسی رفتار کاربر بدون مجوز
• بررسی ساختار Response و Status Code

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

ابزارهای تست API

برای تست API ابزارهای مختلفی وجود دارد. یکی از ابزارهای شناخته‌شده در این حوزه Postman است. در کنار آن، تست API می‌تواند با ابزارها و کتابخانه‌های برنامه‌نویسی نیز انجام شود و در پروژه‌های Automation به بخشی از تست‌های خودکار تبدیل شود.

در این مرحله از مسیر یادگیری، هدف اصلی این نیست که همه ابزارها را یاد بگیرید؛ بلکه باید ابتدا مفهوم API، Request، Response، HTTP، Status Code و نحوه طراحی تست برای API را درک کنید.

تست دیتابیس (Database Testing) چیست؟ 🗄️

تست دیتابیس(Database Testing) به بررسی صحت داده‌ها و رفتار بخش‌های مرتبط با ذخیره‌سازی و بازیابی اطلاعات گفته می‌شود.

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

این موضوع اهمیت زیادی دارد، زیرا ممکن است رابط کاربری نتیجه‌ای ظاهراً صحیح نمایش دهد، اما داده‌ای که در Backend یا Database ذخیره شده است اشتباه باشد.

SQL چرا برای تستر مهم است؟

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

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

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

ارتباط UI، API و Database

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

کاربر → UI → API → Backend → Database

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

• کاربر اطلاعات جدید را در UI وارد می‌کند.
• Frontend درخواست را به API ارسال می‌کند.
• Backend اطلاعات را اعتبارسنجی و پردازش می‌کند.
• اطلاعات جدید در Database ذخیره می‌شود.
• API نتیجه عملیات را برمی‌گرداند.
• UI نتیجه را به کاربر نمایش می‌دهد.

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

API Testing و Database Testing چه ارتباطی با E2E دارند؟

در یک جریان End-to-End ممکن است چندین لایه سیستم درگیر باشند. به همین دلیل، آشنایی با API و Database به تستر کمک می‌کند جریان کامل را بهتر درک و اعتبارسنجی کند.

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

• UI: آیا سفارش به کاربر نمایش داده می‌شود؟
• API: آیا درخواست ثبت سفارش و Response صحیح هستند؟
• Database: آیا اطلاعات سفارش به‌درستی ذخیره شده‌اند؟
• E2E: آیا کل فرآیند از انتخاب محصول تا ثبت موفق سفارش درست اجرا می‌شود؟

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• مفهوم API و نقش آن در ارتباط میان بخش‌های مختلف نرم‌افزار را درک کنید.
• بتوانید Request و Response را در سطح مقدماتی تحلیل کنید.
• با HTTP Methodها و Status Codeهای مهم آشنا باشید.
• بتوانید برای API سناریوهای مثبت و منفی طراحی کنید.
• بدانید Database چه نقشی در جریان اجرای نرم‌افزار دارد.
• با SQL در حد موردنیاز برای بررسی و اعتبارسنجی داده‌ها آشنا باشید.
• ارتباط میان UI، API، Backend و Database را درک کنید.
• بدانید چگونه می‌توان یک مشکل را از UI به لایه‌های پایین‌تر سیستم دنبال کرد.

۱۲. مدیریت تست و فرایند QA (Test Management & QA Process)

تا اینجا بیشتر درباره این صحبت کردیم که چه چیزی را تست کنیم و چگونه برای آن تست طراحی و اجرا کنیم. اما در یک پروژه واقعی، تست فقط مجموعه‌ای از Test Caseها و Bug Reportها نیست.

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

اینجاست که مفاهیمی مانند Test Strategy، Test Plan، STLC، Test Documentation و Requirements Traceability Matrix (RTM) اهمیت پیدا می‌کنند.

Test Strategy چیست؟ 🧭

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

برای مثال، یک Test Strategy می‌تواند درباره موضوعاتی مانند موارد زیر تصمیم‌گیری کند:

• چه سطوح و انواع تستی در پروژه مورد استفاده قرار گیرند؟
• تمرکز تست بر چه ریسک‌هایی باشد؟
• چه بخش‌هایی Manual و چه بخش‌هایی Automated Testing داشته باشند؟
• چه محیط‌هایی برای تست موردنیاز باشند؟
• رویکرد مدیریت و گزارش Defectها چگونه باشد؟
• چه معیارهایی برای ارزیابی وضعیت تست و کیفیت استفاده شوند؟

بنابراین Test Strategy بیشتر درباره رویکرد و جهت‌گیری کلی تست است و نباید آن را با فهرست Test Caseها اشتباه گرفت.

Test Plan چیست؟

Test Plan سند یا برنامه‌ای است که جزئیات اجرایی تست را برای یک پروژه، Release، Feature یا محدوده مشخص بیان می‌کند.

برای مثال، در یک Test Plan ممکن است مواردی مانند Scope، Test Objectives، منابع، محیط تست، زمان‌بندی، مسئولیت‌ها، Entry Criteria و Exit Criteria مشخص شوند.

تفاوت ساده این دو مفهوم را می‌توان این‌گونه در نظر گرفت:

Test Strategy → رویکرد کلی تست
Test Plan → برنامه و جزئیات اجرای تست در یک محدوده مشخص

STLC و مدیریت فرایند تست

در بخش‌های ابتدایی مسیر یادگیری با STLC یا Software Testing Life Cycle آشنا شدیم. حالا می‌توانیم آن را از دید مدیریت تست بهتر درک کنیم.

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

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

مستندسازی تست (Test Documentation)

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

بسته به پروژه و روش توسعه، ممکن است با مستنداتی مانند Test Strategy، Test Plan، Test Scenario، Test Case، Test Data، Test Execution Record، Bug Report و Test Summary Report مواجه شوید.

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

Requirements Traceability Matrix یا RTM

Requirements Traceability Matrix یا RTM ابزاری برای ایجاد ارتباط و Traceability میان Requirementها و سایر Artefactهای پروژه، مانند Test Caseها و Defectها است.

برای مثال، می‌توان مشخص کرد یک Requirement با کدام Test Caseها پوشش داده شده و در صورت وجود Defect، آن Defect به کدام بخش از Requirement یا Test مرتبط است.

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

در این مقاله RTM را فقط در حد جایگاه آن در مسیر یادگیری معرفی می‌کنیم؛ زیرا Requirements Traceability Matrix خود یک موضوع مستقل و تخصصی است.

Test Reporting و سنجش وضعیت تست

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

برای مثال، گزارش تست می‌تواند اطلاعاتی درباره تعداد Test Caseهای اجراشده، وضعیت Pass و Fail، Defectهای باز، ریسک‌های شناخته‌شده و وضعیت کلی تست ارائه کند.

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• تفاوت کلی Test Strategy و Test Plan را درک کنید.
• بدانید Test Management چه نقشی در پروژه‌های نرم‌افزاری دارد.
• مفهوم STLC و ارتباط آن با فعالیت‌های تست را درک کنید.
• با انواع اصلی Test Documentation آشنا باشید.
• بدانید RTM چیست و چه نقشی در Traceability دارد.
• بتوانید مفهوم Test Reporting و اهمیت آن برای تصمیم‌گیری درباره کیفیت را توضیح دهید.
• درک کنید که مدیریت تست فقط اجرای Test Case و ثبت Bug نیست.

۱۳. اتوماسیون تست (Automation Testing) 🤖

تا اینجا مسیر اصلی تست نرم‌افزار را از مبانی و Requirements تا Test Case، Bug Report، تست دستی، تست وب، API و مدیریت تست بررسی کردیم. در این مرحله می‌توانیم وارد یکی از مهم‌ترین شاخه‌های مسیر حرفه‌ای تست نرم‌افزار شویم: اتوماسیون تست (Test Automation).

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

اتوماسیون تست چیست؟

Test Automation استفاده از ابزارها، Frameworkها و کد برای اجرای خودکار فعالیت‌های تست و بررسی نتایج آن‌هاست.

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

در چنین شرایطی می‌توان Test Caseهای مناسب را به Test Script تبدیل کرد تا سیستم بتواند آن‌ها را به‌صورت خودکار اجرا و نتیجه را گزارش کند.

آیا Automation جایگزین Manual Testing می‌شود؟

خیر. یکی از مهم‌ترین نکات در مسیر یادگیری Automation این است که Automation Testing را جایگزین کامل Manual Testing ندانیم.

یک Test Script معمولاً همان چیزی را اجرا می‌کند که برای آن طراحی شده است؛ اما تستر می‌تواند فراتر از اجرای یک Script، Requirementها را تحلیل کند، ریسک‌ها را شناسایی کند، سناریوهای جدید طراحی کند و رفتارهای غیرمنتظره سیستم را بررسی کند.

به همین دلیل، در بسیاری از پروژه‌ها بهترین رویکرد ترکیبی از Manual Testing و Automation Testing است؛ هرکدام برای بخشی از مسئله‌ای که در آن مناسب‌تر هستند.

چه تست‌هایی برای Automation مناسب‌تر هستند؟

هر Test Case الزاماً گزینه مناسبی برای Automation نیست. هنگام تصمیم‌گیری باید عواملی مانند تکرارپذیری، ثبات رفتار، هزینه نگهداری و ارزش تست در نظر گرفته شوند.

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

• تست‌های Regression تکرارشونده
• سناریوهای مهم و پایدار کسب‌وکار
• تست‌های API
• بررسی جریان‌های مهم و قابل تکرار کاربر
• تست‌هایی که اجرای دستی آن‌ها زمان زیادی می‌گیرد
• تست‌هایی که در هر Release یا Build باید مرتباً اجرا شوند

در مقابل، بعضی فعالیت‌ها مانند Exploratory Testing، بررسی‌های اکتشافی، ارزیابی برخی جنبه‌های Usability یا سناریوهایی که مرتباً تغییر می‌کنند، ممکن است گزینه مناسبی برای Automation کامل نباشند.

سطوح مختلف اتوماسیون تست

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

• Unit Test Automation: خودکارسازی تست‌های مربوط به واحدهای کوچک کد
• API Test Automation: خودکارسازی تست سرویس‌ها و APIها
• UI Test Automation: خودکارسازی تعامل با رابط کاربری
• End-to-End Automation: خودکارسازی جریان‌های کامل و معنادار کاربر

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

برای شروع Automation چه چیزهایی باید یاد بگیریم؟

ورود به Automation معمولاً نیازمند یادگیری چند مهارت در کنار مفاهیم Testing است. مهم‌ترین آن‌ها عبارت‌اند از:

• مبانی Programming
• ساختارهای داده و مفاهیم پایه زبان برنامه‌نویسی
• کار با شرط‌ها، حلقه‌ها، توابع و Exceptionها
• کار با ابزارهای Version Control مانند Git
• مفاهیم مربوط به Test Automation Framework
• کار با Locatorها و تعامل با عناصر UI در صورت ورود به UI Automation
• خواندن و تحلیل Log و گزارش اجرای تست
• آشنایی با CI/CD برای اجرای خودکار تست‌ها در Pipeline

برای مثال، اگر هدف شما Automation Testing با Playwright باشد، یادگیری یک زبان مانند Python یا JavaScript/TypeScript در کنار مفاهیم تست می‌تواند پایه لازم برای ساخت و نگهداری Test Scriptها را فراهم کند.

Automation بدون درک Testing می‌تواند مشکل‌ساز شود

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

فرض کنید تستری بتواند با یک Framework چندین Test Script بنویسد، اما نداند کدام Requirement مهم‌تر است، چه سناریویی ارزش تست دارد، چه زمانی باید Regression انجام شود یا یک Failure واقعاً نشان‌دهنده Defect است یا نه.

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

Automation و CI/CD

یکی از مهم‌ترین مزایای Automation زمانی دیده می‌شود که تست‌های خودکار در فرآیند CI/CD قرار می‌گیرند.

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

برای مثال، یک Pipeline می‌تواند پس از ایجاد یک تغییر در کد، مجموعه‌ای از Unit Testها و API Testها را اجرا کند و سپس در مراحل بعدی تست‌های دیگری را انجام دهد. این رویکرد به تیم کمک می‌کند مشکلات را سریع‌تر شناسایی کند.

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• بدانید Test Automation چیست و چه هدفی دارد.
• درک کنید Automation جایگزین کامل Manual Testing نیست.
• بتوانید Test Caseهای مناسب برای Automation را تا حدی تشخیص دهید.
• با تفاوت Automation در سطح Unit، API، UI و E2E آشنا باشید.
• بدانید برای ورود به Automation به چه مبانی برنامه‌نویسی نیاز دارید.
• مفهوم Test Automation Framework را درک کنید.
• با نقش Git و CI/CD در Automation آشنا باشید.
• درک کنید که انتخاب سناریوی مناسب، به اندازه نوشتن Test Script اهمیت دارد.

۱۴. ابزارها و محیط کاری تستر (Testing Tools & Environment) 🛠️

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

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

ابزارهای مدیریت تست (Test Management Tools)

در پروژه‌های مختلف ممکن است Test Scenario، Test Case، Test Execution و نتایج تست در ابزارهای مدیریت تست ثبت و مدیریت شوند.

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

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

ابزارهای مدیریت باگ و Issue Tracking

وقتی تستر یک Defect پیدا می‌کند، باید بتواند آن را ثبت، پیگیری و در طول چرخه عمر آن مدیریت کند. برای این کار از ابزارهای Issue Tracking و Bug Tracking استفاده می‌شود.

در این ابزارها معمولاً اطلاعاتی مانند عنوان مشکل، توضیحات، Steps to Reproduce، Expected Result، Actual Result، Severity، Priority، Environment، Attachment و وضعیت فعلی Defect ثبت می‌شود.

این ابزارها علاوه بر ثبت Bug، برای مدیریت Task، Story و سایر Work Itemهای پروژه نیز ممکن است مورد استفاده قرار بگیرند.

ابزارهای تست API 🔌

برای تست API می‌توان از ابزارهایی استفاده کرد که امکان ارسال Request، مشاهده Response، مدیریت Environmentها و اجرای مجموعه‌ای از تست‌ها را فراهم می‌کنند.

در ابتدای مسیر، آشنایی با ابزارهایی مانند Postman می‌تواند برای درک بهتر API Testing مفید باشد؛ اما همان‌طور که در بخش API Testing گفتیم، یادگیری ابزار نباید جایگزین درک HTTP، Request، Response، Authentication، Status Code و طراحی تست شود.

Browser DevTools

Browser DevTools یکی از در دسترس‌ترین ابزارهای یک تستر وب است و برای بررسی مشکلاتی که در مرورگر رخ می‌دهند کاربرد زیادی دارد.

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

برای مثال، اگر کاربر روی دکمه «پرداخت» کلیک کند اما نتیجه‌ای در UI مشاهده نشود، بررسی Network می‌تواند نشان دهد آیا Request ارسال شده، چه Responseای دریافت شده و آیا خطایی در ارتباط وجود داشته است یا خیر.

Git و Version Control

تسترهایی که وارد Automation می‌شوند یا در تیم‌های فنی مدرن فعالیت می‌کنند، بهتر است با مفهوم Version Control و ابزارهایی مانند Git آشنا باشند.

Git امکان مدیریت تغییرات کد و همکاری چند نفر روی یک پروژه را فراهم می‌کند. برای یک Automation Tester، آشنایی با مفاهیمی مانند Repository، Commit، Branch، Merge و Pull Request می‌تواند بخش مهمی از کار روزمره باشد.

CI/CD و اجرای خودکار تست‌ها ⚙️

در تیم‌های مدرن، تست‌ها می‌توانند بخشی از فرآیند CI/CD باشند. در این حالت اجرای تست فقط به سیستم شخصی تستر وابسته نیست و می‌تواند در Pipeline پروژه نیز انجام شود.

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

در این مرحله لازم نیست یک تستر مبتدی تمام ابزارهای CI/CD را به‌صورت عمیق یاد بگیرد. کافی است ابتدا مفهوم Pipeline، اجرای خودکار تست و نقش تست در فرآیند Delivery را درک کند.

آیا باید همه ابزارهای تست را یاد بگیریم؟

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

ابزارها بر اساس نوع پروژه، تکنولوژی، تیم و نیاز کسب‌وکار انتخاب می‌شوند. ممکن است یک شرکت از یک ابزار برای مدیریت تست استفاده کند و شرکت دیگری ابزار متفاوتی داشته باشد، اما مفاهیمی مانند Test Case، Defect، Traceability و Test Execution در هر دو محیط قابل استفاده هستند.

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

یک محیط کاری واقعی تستر چگونه است؟

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

• Requirement یا User Story را بررسی می‌کنید.
• Test Scenario و Test Case طراحی می‌کنید.
• Build جدید را در محیط تست بررسی می‌کنید.
• تست‌ها را اجرا و نتیجه آن‌ها را ثبت می‌کنید.
• در صورت مشاهده مشکل، Bug Report ایجاد می‌کنید.
• برای تحلیل یک مشکل وب از Browser DevTools استفاده می‌کنید.
• برای بررسی Backend یک API را تست می‌کنید.
• در صورت نیاز Database را با SQL بررسی می‌کنید.
• نتایج تست را در ابزارهای تیم ثبت و پیگیری می‌کنید.
• در تیم Automation، Test Scriptها را از طریق Git و CI/CD مدیریت و اجرا می‌کنید.

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

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• بدانید ابزارهای تست چه مسئله‌ای را در پروژه حل می‌کنند.
• با مفهوم Test Management و Bug Tracking آشنا باشید.
• بتوانید از Browser DevTools برای بررسی مشکلات پایه وب استفاده کنید.
• با مفهوم Version Control و نقش Git در تیم‌های نرم‌افزاری آشنا باشید.
• مفهوم CI/CD و نقش Automation Testing در Pipeline را درک کنید.
• بدانید لازم نیست همه ابزارهای موجود در بازار را یاد بگیرید.
• بتوانید یک ابزار جدید را بر اساس نیاز پروژه و با تکیه بر مفاهیم قبلی یاد بگیرید.

۱۵. مسیرهای تخصصی بعد از یادگیری مبانی تست نرم‌افزار 🧭

تا اینجا یک پایه نسبتاً کامل برای ورود به دنیای تست نرم‌افزار ساختیم؛ از مبانی Testing و Requirements گرفته تا Test Design، Test Case، Bug Reporting، Manual Testing، Web Testing، API، Database، Test Management و Automation.

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

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

۱. مسیر Automation Testing 🤖

یکی از رایج‌ترین مسیرهای تخصصی، Automation Testing است. در این مسیر تستر علاوه بر دانش Testing، مهارت‌های برنامه‌نویسی و کار با Frameworkهای Automation را نیز توسعه می‌دهد.

این مسیر می‌تواند شامل یادگیری زبان برنامه‌نویسی، ساخت Test Script، طراحی Framework، UI Automation، API Automation، مدیریت Test Data و اجرای تست‌ها در CI/CD باشد.

ابزارهایی مانند Playwright نیز می‌توانند در مسیر UI و End-to-End Automation مورد استفاده قرار گیرند.

این مسیر برای افرادی مناسب است که از ترکیب Testing و Programming لذت می‌برند و می‌خواهند به سمت نقش‌هایی مانند Automation Tester یا SDET حرکت کنند.

۲. مسیر API، Backend و Microservices

اگر به منطق پشت سیستم و معماری نرم‌افزار علاقه دارید، می‌توانید مسیر خود را به سمت API Testing، Backend Testing و Microservices Testing توسعه دهید.

در این مسیر، آشنایی عمیق‌تر با HTTP، REST API، Authentication، Authorization، Database، Message Brokerها و ارتباط میان سرویس‌ها اهمیت پیدا می‌کند.

در معماری‌های Microservices، تستر باید علاوه بر بررسی هر سرویس، تعامل میان سرویس‌ها را نیز در نظر بگیرد. در چنین محیطی مفاهیمی مانند Contract Testing نیز اهمیت پیدا می‌کنند.

۳. مسیر Performance Testing

در Performance Testing تمرکز اصلی روی رفتار سیستم در شرایط مختلف بار و فشار است.

در این مسیر با مفاهیمی مانند Load، Stress، Spike و سایر انواع تست عملکرد، همچنین Metricهایی مانند Response Time، Throughput و Error Rate آشنا می‌شوید.

Performance Testing در سیستم‌هایی که تعداد زیادی کاربر یا حجم زیادی از درخواست‌ها دارند اهمیت ویژه‌ای پیدا می‌کند.

۴. مسیر Security Testing 🔐

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

تستر در این مسیر با مفاهیمی مانند Authentication، Authorization، Session Management، Input Validation و آسیب‌پذیری‌های رایج نرم‌افزار آشنا می‌شود.

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

۵. مسیر Mobile Testing 📱

اگر هدف شما تست اپلیکیشن‌های موبایل است، می‌توانید روی Android و iOS Testing تمرکز کنید.

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

۶. مسیر تخصص در حوزه‌های کسب‌وکار

یک مسیر دیگر، تخصص پیدا کردن در Domain یا حوزه کسب‌وکار است.

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

در پروژه‌های پیچیده، فقط دانستن تکنیک‌های تست کافی نیست؛ درک قوانین، فرآیندها، ریسک‌ها و اصطلاحات همان حوزه نیز می‌تواند کیفیت تحلیل تستر را افزایش دهد.

آیا باید فقط یکی از این مسیرها را انتخاب کنیم؟

نه لزوماً.

این مسیرها می‌توانند با یکدیگر ترکیب شوند. برای مثال، یک تستر می‌تواند ابتدا Manual Testing را یاد بگیرد، سپس وارد Automation شود و در ادامه روی API و Microservices نیز تخصص پیدا کند.

یا فرد دیگری ممکن است به جای تمرکز روی Automation، مسیر Performance یا Security Testing را انتخاب کند.

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

چگونه مسیر تخصصی خود را انتخاب کنیم؟

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

• آیا به Programming و ساخت Test Script علاقه دارم؟ → Automation Testing
• آیا به Backend، API و معماری سیستم علاقه دارم؟ → API / Backend / Microservices Testing
• آیا به رفتار سیستم در شرایط بار و حجم بالای درخواست علاقه دارم؟ → Performance Testing
• آیا به امنیت و شناسایی آسیب‌پذیری‌ها علاقه دارم؟ → Security Testing
• آیا می‌خواهم روی اپلیکیشن‌های موبایل کار کنم؟ → Mobile Testing
• آیا به یک صنعت یا حوزه کسب‌وکار خاص علاقه دارم؟ → Domain Specialization

این انتخاب دائمی نیست. با افزایش تجربه ممکن است مسیر حرفه‌ای شما تغییر کند یا چند تخصص در کنار یکدیگر قرار بگیرند.

در پایان این مرحله چه چیزهایی باید بلد باشیم؟ 🎯

• بدانید بعد از یادگیری مبانی Testing چه مسیرهای تخصصی وجود دارند.
• تفاوت کلی Automation، API/Microservices، Performance، Security و Mobile Testing را بشناسید.
• بدانید برای تخصصی شدن لازم نیست همه حوزه‌های Testing را هم‌زمان یاد بگیرید.
• بتوانید مسیر تخصصی خود را بر اساس علاقه، هدف شغلی و نیاز بازار انتخاب کنید.
• درک کنید که تخصص حرفه‌ای معمولاً بر پایه مفاهیم بنیادی و تجربه عملی Testing ساخته می‌شود.

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

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

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

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

در قدم اول باید با مفاهیم بنیادی آشنا شوید:

• Software Testing
• Software Quality
• QA و QC
• Error، Defect و Failure
• هدف و ارزش Testing

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

مرحله دوم: چرخه توسعه و فرایند تست

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

• SDLC
• STLC
• Agile و Scrum
• نقش تستر در چرخه توسعه
• Maintenance Testing

مرحله سوم: Requirements و مستندات

بعد از شناخت چرخه توسعه، باید بتوانید Requirementها را بخوانید، تحلیل کنید و از روی آن‌ها نیازهای تست را استخراج کنید.

• Requirement
• BRD
• SRS
• PRD
• FRD
• User Story
• Acceptance Criteria
• Software Documentation
• Requirements Traceability

یکی از زنجیره‌های مهمی که باید در این مرحله در ذهن شما شکل بگیرد این است:

Requirement → Test Scenario → Test Design → Test Case → Test Execution → Defect → Retesting → Regression

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

حالا باید یاد بگیرید برای یک Requirement یا Feature، تست مناسب را انتخاب کنید.

• Test Levels مانند Unit، Integration، System و Acceptance
• Test Types مانند Functional و Non-Functional
• Smoke، Sanity، Regression و Retesting
• End-to-End و Acceptance Testing
• Black-box، White-box و Experience-based Techniques
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table و State Transition

در این مرحله یک نکته بسیار مهم را فراموش نکنید: Test Level، Test Type و Test Design Technique مفاهیم یکسانی نیستند. دانستن تفاوت آن‌ها یکی از پایه‌های مهم طراحی درست تست است.

مرحله پنجم: Test Case و اجرای تست

در این مرحله باید بتوانید سناریوهای مناسب را به Test Caseهای قابل اجرا تبدیل کنید و نتایج اجرای آن‌ها را به شکل صحیح ثبت کنید.

• Test Scenario
• Test Case
• Test Data
• Precondition
• Expected Result
• Actual Result
• Pass / Fail
• Test Execution

مرحله ششم: Bug Reporting و Defect Management

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

• Bug Report
• Severity و Priority
• Steps to Reproduce
• Expected و Actual Result
• Defect Lifecycle
• Retesting
• Regression Testing

مرحله هفتم: Manual و Exploratory Testing

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

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

مرحله هشتم: Web، API و Database Testing

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

• Web Testing
• UI Testing
• Responsive و Cross-Browser Testing
• Accessibility Testing
• API Testing
• Database Testing
• SQL
• ارتباط میان UI، API، Backend و Database

مرحله نهم: Test Management و QA Process

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

• Test Strategy
• Test Plan
• Test Documentation
• Test Reporting
• Test Management
• Requirements Traceability Matrix

مرحله دهم: Automation Testing

در این مرحله، اگر هدف شما ورود به Automation باشد، می‌توانید دانش Testing را با Programming و ابزارهای Automation ترکیب کنید.

• Programming Fundamentals
• Git و Version Control
• Test Automation Frameworks
• UI Automation
• API Automation
• End-to-End Automation
• CI/CD

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

مرحله یازدهم: انتخاب مسیر تخصصی

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

• Automation Testing
• API و Backend Testing
• Microservices و Contract Testing
• Performance Testing
• Security Testing
• Mobile Testing
• تخصص در یک حوزه کسب‌وکار خاص

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

یک نقشه راه ساده برای شروع 🚀

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

مبانی Testing
↓
SDLC / STLC / Agile
↓
Requirements و مستندات
↓
Test Levels / Test Types / Test Techniques
↓
Test Scenario / Test Case / Test Execution
↓
Bug Reporting / Retesting / Regression
↓
Manual / Exploratory Testing
↓
Web / API / Database Testing
↓
Test Management
↓
Automation یا یک مسیر تخصصی

آیا برای شروع کار باید همه این موارد را بلد باشیم؟

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

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

بعد از آن می‌توانید هم‌زمان با تجربه پروژه‌ای، مهارت‌های خود را در API، SQL، Automation، CI/CD یا سایر حوزه‌های تخصصی توسعه دهید.

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

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

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

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

ابزارهایی مانند Postman، Playwright، ابزارهای Bug Tracking یا Frameworkهای Automation می‌توانند این مسیر را قدرتمندتر کنند؛ اما ارزش آن‌ها زمانی مشخص می‌شود که تستر بداند چه چیزی را، چرا و چگونه باید تست کند.

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

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

منابع

• ISTQB® Certified Tester Foundation Level (CTFL) v4.0 — مرجع اصلی برای مفاهیم پایه تست نرم‌افزار، Test Levels، Test Types، Test Techniques، Test Management، Defect Management و Test Tools.
• ISTQB® CTFL Syllabus v4.0.1 — سرفصل رسمی آزمون Foundation Level و یکی از مهم‌ترین منابع برای مطالعه ساختارمند مباحث تست نرم‌افزار.
• ISTQB® Certifications — معرفی مسیرها و گواهینامه‌های مختلف ISTQB شامل Foundation، Advanced، Specialist و Expert.
• ISTQB® – What We Do — آشنایی با Certified Tester Scheme، واژه‌نامه و ساختار کلی چارچوب آموزشی و حرفه‌ای ISTQB.

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

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

برای یادگیری تست نرم افزار از کجا شروع کنیم؟

بهتر است یادگیری را از مبانی Software Testing شروع کنید؛ سپس به سراغ SDLC، STLC، Requirements، Test Levels، Test Types، Test Design Techniques، Test Case و Bug Reporting بروید و بعد از ایجاد این پایه، مسیرهای تخصصی مانند Automation، API، Performance یا Security Testing را انتخاب کنید.

آیا برای یادگیری تست نرم افزار باید برنامه نویسی بلد باشیم؟

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

آیا باید ابتدا Manual Testing را یاد بگیریم و بعد سراغ Automation برویم؟

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

تفاوت Test Level، Test Type و Test Technique چیست؟

Test Level مشخص می‌کند تست در چه سطحی از سیستم انجام می‌شود؛ مانند Unit، Integration، System و Acceptance. Test Type بر هدف تست تمرکز دارد؛ مانند Functional، Performance یا Regression Testing. Test Technique نیز روشی است که برای طراحی تست‌ها استفاده می‌شود؛ مانند Equivalence Partitioning، Boundary Value Analysis یا Decision Table.

آیا یادگیری Test Case برای یک تستر ضروری است؟

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

آیا SQL برای تست نرم افزار لازم است؟

SQL برای همه موقعیت‌های شغلی تستر به یک اندازه ضروری نیست، اما یادگیری مفاهیم پایه SQL برای بررسی داده‌های Database، اعتبارسنجی نتایج API و بررسی جریان داده در بسیاری از پروژه‌ها بسیار مفید است.

چه زمانی باید Automation Testing را شروع کنیم؟

بهتر است بعد از یادگیری مبانی تست، Test Case، Bug Reporting، Regression Testing و آشنایی با رفتار سیستم، وارد Automation شوید. در این مرحله یادگیری Programming، Git، یک Automation Framework و در ادامه CI/CD می‌تواند مسیر شما را برای Automation Testing آماده کند.

آیا برای تبدیل شدن به تستر باید همه ابزارهای تست را یاد بگیریم؟

خیر. هدف یادگیری نباید حفظ کردن تعداد زیادی ابزار باشد. ابتدا مفاهیم و فرایندهای تست را یاد بگیرید و سپس ابزارهایی را انتخاب کنید که با نوع پروژه و مسیر تخصصی شما مرتبط هستند؛ برای مثال ابزارهای API Testing، Bug Tracking، Test Management، Version Control یا Automation.

بعد از یادگیری مبانی تست نرم افزار چه مسیری را انتخاب کنیم؟

انتخاب مسیر به علاقه و هدف شغلی شما بستگی دارد. برخی تسترها به سمت Automation Testing می‌روند، برخی روی API و Backend تمرکز می‌کنند و بعضی مسیرهای تخصصی مانند Performance، Security، Mobile یا Microservices Testing را انتخاب می‌کنند.

آیا برای ورود به بازار کار باید تمام مباحث این مقاله را بلد باشیم؟

خیر. این مقاله یک مسیر یادگیری جامع است، نه فهرست الزام‌های یک موقعیت شغلی Junior. برای شروع کار، تسلط مناسب بر مبانی تست، Requirements، Test Case، Test Execution، Bug Reporting و آشنایی با فرایند توسعه نرم افزار اهمیت بیشتری دارد و سپس می‌توانید دانش خود را در یک مسیر تخصصی گسترش دهید.

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

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

آیا ISTQB برای یادگیری تست نرم افزار ضروری است؟

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