تست نرمافزار فرایندی برای سنجش کیفیت محصول پیش از رسیدن آن به دست کاربر است. در این فرایند، رفتار واقعی نرمافزار با رفتار مورد انتظار مقایسه میشود. این راهنما مفاهیم پایه، انواع تست، نقشها و روش مدیریت تست را برای تیمهای توسعه یکجا مرور میکند.
تست نرمافزار چیست و چه هدفی دارد
تست نرمافزار (Software Testing) مجموعهای از فعالیتهای برنامهریزیشده است. هدف آن یافتن خطا، کاهش ریسک و ایجاد اطمینان درباره کیفیت است. تست فقط اجرای برنامه و کلیک روی دکمهها نیست. بررسی نیازمندیها، بازبینی طراحی و تحلیل کد هم بخشی از آن است.
هر تست در اصل به یک پرسش پاسخ میدهد: آیا نرمافزار همان کاری را انجام میدهد که باید انجام دهد. برای پاسخ به این پرسش، به یک مرجع نیاز داریم. این مرجع معمولاً یک نیازمندی، یک معیار پذیرش یا رفتار نسخه قبلی است. به این مرجع در ادبیات تست اوراکل تست میگویند.
اهداف اصلی تست نرمافزار
- پیدا کردن باگها پیش از رسیدن به کاربر نهایی
- اطمینان از تطابق محصول با نیازمندیها و معیارهای پذیرش
- کاهش ریسک کسبوکار در هر ریلیز
- فراهم کردن اطلاعات دقیق برای تصمیم انتشار
- جلوگیری از بازگشت باگهای قدیمی بعد از تغییرات جدید
خطا، نقص و خرابی
سه واژه در تست نرمافزار زیاد بهجای هم به کار میروند، اما معنای متفاوتی دارند:
- خطا (Error): اشتباه انسانی است؛ مثلاً برنامهنویس شرط یک حلقه را اشتباه مینویسد.
- نقص یا باگ (Defect): نتیجه آن اشتباه در کد یا مستندات است.
- خرابی (Failure): رفتار نادرستی است که هنگام اجرای نقص دیده میشود.
همه نقصها به خرابی نمیرسند. نقصی که در مسیری اجرانشده باشد، ممکن است هرگز دیده نشود. به همین دلیل، بازبینی کد و مستندات هم بخش مهمی از تست است.
ارزش تست برای تیم توسعه
تست خوب به تیم سرعت میدهد، نه اینکه آن را کند کند. وقتی تیم به تستها اعتماد دارد، تغییرات بزرگ را با خیال راحتتری انجام میدهد. هزینه رفع باگ هم معمولاً هرچه دیرتر پیدا شود، بیشتر میشود. باگی که در مرحله نیازمندی پیدا شود، با اصلاح یک جمله رفع میشود. همان باگ در محیط عملیاتی ممکن است به بازگشت نسخه، پشتیبانی اضطراری و کاهش اعتماد کاربر برسد.
هفت اصل بنیادین تست نرمافزار
این اصول در منابع استاندارد تست، از جمله سرفصلهای ISTQB، آمدهاند. دانستن آنها به تصمیمگیری بهتر در پروژه کمک میکند.
- تست وجود باگ را نشان میدهد، نه نبود آن را. اگر تستها باگی پیدا نکنند، یعنی احتمالاً باگ کمتری باقی مانده است؛ نه اینکه نرمافزار بینقص است.
- تست کامل ممکن نیست. ترکیب همه ورودیها و مسیرها تقریباً بیپایان است. پس انتخاب تستها باید بر اساس ریسک و اولویت باشد.
- تست زودهنگام هزینه را کم میکند. این همان ایده Shift-Left است. هرچه تست زودتر شروع شود، اصلاح ارزانتر است.
- باگها خوشهای هستند. معمولاً بخش کوچکی از ماژولها بیشتر باگها را دارند. تمرکز روی این بخشها بازده بیشتری دارد.
- پارادوکس آفتکش. اجرای مکرر همان تستها بهمرور باگ جدیدی پیدا نمیکند. تستکیسها باید مرتب بازبینی و بهروز شوند.
- تست به زمینه وابسته است. تست یک سامانه بانکی با تست یک وبسایت خبری فرق دارد. روش، عمق و ابزار باید با زمینه پروژه هماهنگ باشد.
- خطای نبود باگ. نرمافزاری که باگ ندارد ولی نیاز کاربر را برآورده نمیکند، محصول موفقی نیست. پس تست باید درستی خود نیازمندیها را هم بسنجد.
چه زمانی تست کافی است
چون تست کامل ممکن نیست، تیم باید از قبل تعریف کند چه زمانی تست کافی است. این تعریف معمولاً در قالب معیار خروج نوشته میشود. چند نمونه رایج:
- همه تستکیسهای با اولویت بالا اجرا شده باشند.
- هیچ باگ باز با شدت بحرانی باقی نمانده باشد.
- نرخ قبولی تستها به حد توافقشده رسیده باشد.
- ریسکهای باقیمانده مستند و توسط مالک محصول پذیرفته شده باشند.
جایگاه تست در چرخه عمر توسعه نرمافزار
تست یک مرحله جدا در انتهای پروژه نیست. در مدلهای امروزی، تست از روز اول در چرخه عمر توسعه نرمافزار حضور دارد. در تیمهای چابک، تست در هر اسپرینت و گاهی در هر کامیت انجام میشود.
چرخه عمر تست نرمافزار (STLC)
چرخه عمر تست نرمافزار فعالیتهای تست را به چند مرحله منظم تقسیم میکند:
- تحلیل نیازمندیها: تیم تست نیازمندیها را میخواند و موارد قابل تست را مشخص میکند.
- برنامهریزی تست: دامنه، منابع، زمانبندی و ریسکها در طرح تست ثبت میشود.
- طراحی تستکیسها: سناریوها و تستکیسها نوشته و دادههای تست آماده میشود.
- آمادهسازی محیط تست: سرورها، پایگاه داده، حسابهای کاربری و ابزارها تنظیم میشوند.
- اجرای تست: تستها اجرا و نتایج ثبت میشود. باگها گزارش و پیگیری میشوند.
- بستن چرخه تست: نتایج تحلیل، گزارش نهایی تهیه و درسآموختهها ثبت میشود.
هر مرحله معیار ورود و خروج خودش را دارد. مثلاً اجرای تست زمانی شروع میشود که بیلد پایدار روی محیط تست مستقر شده باشد.
رویکرد Shift-Left و تست پیوسته
در رویکرد Shift-Left، تست به ابتدای چرخه منتقل میشود. تسترها در جلسههای تعریف نیازمندی شرکت میکنند. معیارهای پذیرش پیش از شروع توسعه نوشته میشوند. روشهایی مثل TDD و BDD هم به همین هدف کمک میکنند.
در کنار آن، CI/CD امکان اجرای خودکار تستها را در هر تغییر کد فراهم میکند. نتیجه این است که بازخورد کیفیت در چند دقیقه به دست توسعهدهنده میرسد.
تست در تیمهای چابک
در تیمهای چابک، تستر عضو ثابت تیم محصول است. او در برآورد کارها، نوشتن معیارهای پذیرش و بازبینی داستانهای کاربری مشارکت دارد. هر داستان کاربری فقط وقتی «انجامشده» حساب میشود که تستهای آن اجرا و قبول شده باشند. این رویکرد باعث میشود کیفیت در طول اسپرینت ساخته شود، نه در روزهای آخر.
سطوح و انواع تست نرمافزار
انواع تست را میتوان از چند زاویه دستهبندی کرد. رایجترین دستهبندی بر اساس سطح تست است. برای مرور کاملتر، مقاله انواع تست نرمافزار را بخوانید.
چهار سطح اصلی تست
| سطح تست | هدف | چه کسی انجام میدهد | نمونه |
|---|---|---|---|
| تست واحد | بررسی کوچکترین بخش کد بهصورت مستقل | توسعهدهنده | تست یک تابع محاسبه تخفیف |
| تست یکپارچگی | بررسی تعامل ماژولها و سرویسها | توسعهدهنده و تستر | ارتباط سرویس سفارش با درگاه پرداخت |
| تست سیستم | بررسی کل سیستم در برابر نیازمندیها | تیم QA | تست کامل فرایند خرید در محیط تست |
| تست پذیرش | تأیید آمادگی محصول برای استفاده | کاربر یا نماینده کسبوکار | تست پذیرش کاربر پیش از ریلیز |
تست عملکردی و غیرعملکردی
تست عملکردی بررسی میکند که سیستم «چه کاری» انجام میدهد. مثلاً آیا ثبت سفارش درست انجام میشود. تست غیرعملکردی بررسی میکند سیستم «چطور» کار میکند. تست کارایی، تست بار، تست امنیت و تست کاربردپذیری در این دسته قرار میگیرند.
جعبه سیاه، جعبه سفید و جعبه خاکستری
- تست جعبه سیاه: تستر فقط ورودی و خروجی را میبیند و به کد دسترسی ندارد.
- تست جعبه سفید: تست بر اساس ساختار داخلی کد طراحی میشود.
- تست جعبه خاکستری: ترکیبی از هر دو است. تستر دانش محدودی از ساختار داخلی دارد.
تست ایستا و تست پویا
تست ایستا (Static Testing) بدون اجرای کد انجام میشود. بازبینی نیازمندیها، بازبینی کد و تحلیل ایستای کد با ابزارها در این دستهاند. تست ایستا باگ را در ارزانترین نقطه پیدا میکند؛ یعنی پیش از آنکه کدی اجرا شود.
تست پویا (Dynamic Testing) با اجرای نرمافزار انجام میشود. همه سطوح تست که در جدول بالا آمد، در این دسته قرار میگیرند. تیمهای بالغ هر دو را کنار هم به کار میبرند:
- بازبینی معیارهای پذیرش پیش از شروع توسعه
- بازبینی کد پیش از ادغام در شاخه اصلی
- اجرای تستهای خودکار در هر بیلد
- اجرای تستهای دستی و اکتشافی روی قابلیتهای جدید
تستهای پرکاربرد در هر ریلیز
چند نوع تست تقریباً در همه پروژهها تکرار میشوند:
- تست دود (Smoke Testing): بررسی سریع قابلیتهای حیاتی روی بیلد جدید.
- تست سلامت (Sanity Testing): بررسی محدود یک اصلاح یا تغییر کوچک.
- تست رگرسیون: اطمینان از اینکه تغییرات جدید قابلیتهای قبلی را خراب نکرده است. جزئیات آن در مقاله تست رگرسیون آمده است.
- تست اکتشافی: یادگیری، طراحی و اجرای همزمان تست بدون اسکریپت از پیش نوشتهشده.
تست دستی، اتوماسیون تست و هرم تست
هر دو روش دستی و خودکار در یک تیم بالغ جایگاه دارند. انتخاب درست به نوع تست، تعداد تکرار و پایداری قابلیت بستگی دارد.
تست دستی
در تست دستی، تستر مراحل را خودش اجرا و نتیجه را بررسی میکند. این روش برای تست اکتشافی، تست کاربردپذیری و قابلیتهای تازه مناسب است. قضاوت انسانی در این موارد جایگزین ندارد.
اتوماسیون تست
در اتوماسیون تست، اسکریپتها تست را اجرا و نتیجه را با مقدار مورد انتظار مقایسه میکنند. این روش برای تستهای تکراری، تست رگرسیون و اجرا در پایپلاین CI مناسب است. برای شروع اصولی، مقاله اتوماسیون تست را ببینید.
| معیار | تست دستی | اتوماسیون تست |
|---|---|---|
| هزینه شروع | کم | بیشتر؛ نیاز به زیرساخت و کدنویسی |
| سرعت اجرای تکراری | کند | سریع |
| مناسب برای | تست اکتشافی، کاربردپذیری، قابلیتهای جدید | رگرسیون، تست واحد، تست API |
| نگهداری | بهروزرسانی مستندات | بهروزرسانی اسکریپتها با تغییر محصول |
| قضاوت انسانی | بالا | محدود به منطق تعریفشده |
هرم تست
هرم تست یک الگوی ساده برای توزیع تستهاست. پایه هرم، تستهای واحد زیاد، سریع و ارزان است. لایه میانی، تستهای یکپارچگی و API است. رأس هرم، تعداد کمی تست رابط کاربری و سرتاسری است. این توزیع بازخورد را سریع میکند و تستهای شکننده را کم میکند.
تستهای ناپایدار یا فلیکی گاهی قبول و گاهی رد میشوند، بدون اینکه کد تغییر کرده باشد. این تستها اعتماد تیم به نتایج را کم میکنند. بهتر است زود شناسایی، جدا و اصلاح شوند.
مستندات اصلی تست: از نیازمندی تا ریلیز
فرایند تست روی چند سند و مصنوع کلیدی بنا میشود. این مصنوعات یک زنجیره را میسازند: نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز. هر حلقه اطلاعات حلقه بعدی را تأمین میکند.
طرح تست و استراتژی تست
استراتژی تست رویکرد کلی سازمان یا محصول را به تست تعریف میکند. طرح تست همین رویکرد را برای یک پروژه یا ریلیز مشخص جزئی میکند. دامنه، منابع، زمانبندی، ریسکها و معیارهای ورود و خروج در طرح تست میآیند. راهنمای کامل آن در مقاله طرح تست و استراتژی تست آمده است.
سناریو و تستکیس
سناریوی تست یک موقعیت کلی را توصیف میکند؛ مثلاً «کاربر رمز عبور را بازیابی میکند». تستکیس همان سناریو را به مراحل دقیق، داده مشخص و نتیجه مورد انتظار تبدیل میکند. یک تستکیس خوب را هر عضو تیم میتواند بدون ابهام اجرا کند. برای نمونه و قالب آماده، مقاله نوشتن تستکیس حرفهای را بخوانید.
تستکیسهای مرتبط در قالب یک مجموعه تست گروهبندی میشوند. مثلاً همه تستهای سبد خرید در یک مجموعه قرار میگیرند. این گروهبندی انتخاب تستها را برای هر چرخه سادهتر میکند. مثلاً برای یک اصلاح کوچک، فقط مجموعه مرتبط و تستهای دود اجرا میشوند.
اجرای تست و ثبت نتیجه
در هر چرخه، مجموعهای از تستکیسها در قالب یک اجرای تست (Test Run) اجرا میشود. نتیجه هر تست معمولاً یکی از این وضعیتهاست: قبول، رد، مسدود یا نیازمند تست مجدد. ثبت دقیق نتیجه پایه همه گزارشهای بعدی است.
گزارش باگ
وقتی نتیجه واقعی با نتیجه مورد انتظار فرق دارد، یک گزارش باگ ثبت میشود. گزارش خوب شامل مراحل بازتولید، نتیجه واقعی، نتیجه مورد انتظار، محیط و شواهد است. شدت و اولویت باگ هم باید جدا از هم تعیین شوند. مسیر کامل یک باگ را در مقاله چرخه عمر باگ و گزارش باگ ببینید.
ماتریس ردیابی و معیارهای تست
ماتریس ردیابی نیازمندی نشان میدهد هر نیازمندی با کدام تستکیس پوشش داده شده است. این ماتریس شکافهای پوشش را پیش از ریلیز آشکار میکند. جزئیات آن در مقاله ماتریس ردیابی نیازمندی آمده است.
معیارهایی مثل نرخ قبولی، چگالی باگ و پوشش تست تصویر عددی کیفیت را میسازند. این اعداد به مدیر محصول کمک میکنند درباره ریلیز تصمیم بگیرد. برای انتخاب معیارهای درست، مقاله معیارهای تست و گزارش کیفیت را ببینید.
نقشها و مهارتها در تیم کیفیت
کیفیت مسئولیت کل تیم است، اما نقشهای تخصصی هم در آن وجود دارد. سه اصطلاح در این حوزه زیاد با هم اشتباه میشوند: تضمین کیفیت، کنترل کیفیت و تست.
- تضمین کیفیت نرمافزار (QA): بر فرایند تمرکز دارد و از بروز خطا پیشگیری میکند.
- کنترل کیفیت (QC): بر محصول تمرکز دارد و خطاها را شناسایی میکند.
- تست: یکی از فعالیتهای اصلی کنترل کیفیت است که محصول را اجرا و بررسی میکند.
تفاوت دقیق این سه مفهوم را در مقاله تفاوت QA، QC و تست نرمافزار توضیح دادهایم.
مهارتهای یک تستر نرمافزار
یک تستر نرمافزار موفق ترکیبی از مهارتهای فنی و ارتباطی دارد:
- درک عمیق از نیازمندیها و منطق کسبوکار
- تسلط بر تکنیکهای طراحی تست مثل افراز همارزی و تحلیل مقادیر مرزی
- آشنایی با SQL، API و ابزارهای توسعهدهنده مرورگر
- توانایی نوشتن گزارش باگ روشن و قابل بازتولید
- آشنایی با اتوماسیون تست و مفاهیم CI/CD
- ارتباط مؤثر با توسعهدهنده، مدیر محصول و طراح
کیفیت، مسئولیت مشترک
در تیمهای امروزی، کیفیت فقط به تیم تست سپرده نمیشود. مدیر محصول نیازمندی روشن و معیار پذیرش قابل سنجش مینویسد. توسعهدهنده تست واحد مینویسد و کد را پیش از ادغام بازبینی میکند. طراح، تجربه کاربری را پیش از توسعه با کاربران میسنجد. تیم QA این فعالیتها را هماهنگ و فرایند را مرتب بهتر میکند.
همکاری تستر و توسعهدهنده
رابطه تستر و توسعهدهنده یک همکاری است، نه یک رقابت. هر دو هدف مشترکی دارند: انتشار محصولی قابل اعتماد. گزارش باگ باید بر رفتار سیستم تمرکز کند، نه بر افراد. جلسههای کوتاه مشترک برای مرور باگهای مهم، زمان رفع را کم میکند.
اگر قصد ورود به این حرفه یا رشد در آن را دارید، مسیر گامبهگام را در مقاله مهندسی تست نرمافزار؛ نقشه راه QA Engineer ببینید.
مدیریت تست نرمافزار با ابزار مناسب
وقتی تعداد تستکیسها به صدها و هزاران میرسد، فایل اکسل پاسخگو نیست. نسخهها گم میشوند، نتایج پراکنده میشوند و گزارشگیری زمان زیادی میگیرد. ابزار مدیریت تست همه این اطلاعات را در یک جا جمع میکند. برای انتخاب ابزار، مقاله مقایسه ابزارهای مدیریت تست را ببینید.
TestRail یکی از ابزارهای شناختهشده این حوزه است. تستکیسها در آن در قالب سوئیت و بخش (Section) سازماندهی میشوند. تیم برای هر چرخه یک Test Run یا Test Plan میسازد و نتیجه هر تست را با وضعیتهای Passed، Failed، Blocked و Retest ثبت میکند. Milestoneها ریلیزها را دنبال میکنند و گزارشهای آماده، وضعیت کیفیت را برای مدیران شفاف میکنند. اتصال به Jira و API هم زنجیره نیازمندی تا باگ را کامل میکند. اگر تیم شما آماده استقرار چنین فرایندی است، صفحه ابزار مدیریت تست را ببینید و با مسیر شروع آشنا شوید.
جمعبندی
تست نرمافزار فعالیتی پیوسته برای کاهش ریسک و افزایش اعتماد به محصول است. اصول بنیادین تست کمک میکند تلاش تیم روی بخشهای پرریسک متمرکز شود. سطوح و انواع تست، هر کدام بخشی از کیفیت را پوشش میدهند. تست دستی و اتوماسیون تست مکمل هم هستند. در نهایت، وقتی زنجیره نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز شفاف و قابل ردیابی باشد، تیم با اطمینان بیشتری نسخه منتشر میکند.