معیارهای تست نرمافزار (Software Test Metrics) عددهایی هستند که وضعیت تست و کیفیت محصول را قابل اندازهگیری میکنند. متریک تست خوب به مدیر کمک میکند درباره انتشار، منابع و ریسک تصمیم بگیرد. در این راهنما معیارهای اصلی را با فرمول، تفسیر درست و یک قالب گزارش کیفیت برای مدیران مرور میکنیم.
برای آشنایی با مفاهیم پایه، اول راهنمای تست نرمافزار چیست را ببینید.
چرا به معیارهای تست نیاز داریم
بدون عدد، گزارش تست به جملههایی مثل «تقریباً آماده است» محدود میشود. این جملهها برای تصمیمگیری کافی نیستند. معیارهای تست سه کار اصلی انجام میدهند:
- شفافیت: همه یک تصویر مشترک از وضعیت دارند.
- تصمیمگیری: انتشار، تعویق یا تخصیص منابع بیشتر بر پایه داده انجام میشود.
- بهبود: روند عددها در چند نسخه نشان میدهد فرایند بهتر شده یا نه.
ویژگیهای یک معیار خوب
- به یک سؤال مشخص پاسخ میدهد: هر عدد باید به تصمیمی کمک کند.
- قابل اندازهگیری و تکرار است: دو نفر با یک داده، عدد یکسانی به دست میآورند.
- بهموقع است: وقتی هنوز فرصت اقدام هست، در دسترس است.
- دستکاریپذیر نیست: نمیتوان بدون بهبود واقعی، عدد را بهتر نشان داد.
- در کنار معیارهای دیگر معنا دارد: یک عدد تنها معمولاً گمراهکننده است.
دستهبندی معیارهای تست
معیارها را میتوان در سه دسته دید:
- معیارهای فرایند: کارایی فعالیتهای تست را نشان میدهند. مثل پیشرفت اجرا و اثربخشی کشف باگ.
- معیارهای محصول: کیفیت خود نرمافزار را نشان میدهند. مثل چگالی باگ و باگهای باز بر اساس شدت.
- معیارهای پروژه: وضعیت زمانبندی و منابع تست را نشان میدهند. مثل تستهای باقیمانده نسبت به زمان باقیمانده.
در گزارشها از هر سه دسته استفاده کنید. تمرکز فقط بر فرایند، کیفیت محصول را پنهان میکند. تمرکز فقط بر محصول، مشکلات فرایند را.
معیارهای اصلی و فرمولها
جدول زیر معیارهای پرکاربرد را با فرمول و کاربرد نشان میدهد:
| معیار | فرمول | به چه سؤالی پاسخ میدهد |
|---|---|---|
| پیشرفت اجرا | (تعداد تستهای اجراشده ÷ تعداد تستهای برنامهریزیشده) × ۱۰۰ | چقدر از کار تست انجام شده است |
| نرخ قبولی | (تعداد تستهای پاس ÷ تعداد تستهای اجراشده) × ۱۰۰ | چه سهمی از تستهای اجراشده موفق بودهاند |
| نرخ مسدودی | (تعداد تستهای مسدود ÷ تعداد تستهای برنامهریزیشده) × ۱۰۰ | چه مقدار از کار به دلیل موانع متوقف است |
| چگالی باگ | تعداد باگها ÷ اندازه ماژول (مثلاً هزار خط کد یا تعداد نیازمندی) | کدام بخش محصول مشکل بیشتری دارد |
| اثربخشی حذف باگ (DRE) | (باگهای کشفشده پیش از انتشار ÷ کل باگهای پیش و پس از انتشار) × ۱۰۰ | فرایند تست چه سهمی از باگها را پیش از انتشار پیدا کرده است |
| نشت باگ | (باگهای کشفشده در محیط عملیاتی ÷ کل باگها) × ۱۰۰ | چه سهمی از باگها از تست عبور کردهاند |
| پوشش نیازمندی | (نیازمندیهای دارای حداقل یک تست ÷ کل نیازمندیها) × ۱۰۰ | کدام نیازمندیها اصلاً تست ندارند |
| نرخ بازگشایی باگ | (باگهای بازگشاییشده ÷ باگهای رفعشده) × ۱۰۰ | کیفیت رفع باگها چقدر است |
| میانگین زمان رفع | مجموع زمان از ثبت تا رفع ÷ تعداد باگهای رفعشده | باگها با چه سرعتی رفع میشوند |
| پوشش اتوماسیون | (تستهای رگرسیون خودکار ÷ کل تستهای رگرسیون) × ۱۰۰ | اتوماسیون چقدر پیش رفته است |
نکتههایی درباره چند معیار
- نرخ قبولی: همیشه کنار پیشرفت اجرا گزارش شود. نرخ قبولی بالا روی ده درصد تستها، تصویر کاملی نمیدهد.
- چگالی باگ: برای مقایسه ماژولهای یک محصول مفید است. مقایسه آن بین تیمها یا محصولات مختلف معمولاً معنا ندارد.
- اثربخشی حذف باگ: فقط بعد از گذشت مدتی از انتشار قابل محاسبه است. چون باگهای محیط عملیاتی بهتدریج گزارش میشوند.
- پوشش نیازمندی: از ماتریس ردیابی نیازمندی به دست میآید و با پوشش کد فرق دارد.
یک مثال محاسبه
فرض کنید برای یک نسخه ۴۰۰ تست برنامهریزی کردهاید. تا امروز ۳۲۰ تست اجرا شده است. از این تعداد ۲۸۸ تست پاس شده، ۲۰ تست شکست خورده و ۱۲ تست مسدود است. عددها فرضی و فقط برای نمایش روش محاسبه هستند.
- پیشرفت اجرا: ۳۲۰ تقسیم بر ۴۰۰، یعنی ۸۰ درصد.
- نرخ قبولی: ۲۸۸ تقسیم بر ۳۲۰، یعنی ۹۰ درصد.
- نرخ مسدودی: ۱۲ تقسیم بر ۴۰۰، یعنی ۳ درصد.
حالا فرض کنید پیش از انتشار ۴۵ باگ پیدا شده و در ماه اول بعد از انتشار ۵ باگ دیگر گزارش شده است. اثربخشی حذف باگ برابر است با ۴۵ تقسیم بر ۵۰، یعنی ۹۰ درصد. نشت باگ هم ۵ تقسیم بر ۵۰، یعنی ۱۰ درصد است.
پیش از محاسبه، یک تصمیم را روشن کنید: تست مسدود جزو «اجراشده» حساب میشود یا نه. در این مثال حساب شده است. هر انتخابی کنید، در همه گزارشها یکسان به کار ببرید.
پوشش نیازمندی و پوشش کد
پوشش کد نشان میدهد تستهای خودکار چه سهمی از خطوط یا شاخههای کد را اجرا کردهاند. پوشش نیازمندی نشان میدهد چه سهمی از نیازمندیها تست دارند. هر دو مفیدند، اما هیچکدام کیفیت تست را تضمین نمیکنند. کدی که اجرا شده، لزوماً درست بررسی نشده است.
تفسیر درست معیارها
عدد بدون زمینه میتواند گمراه کند. این اصول کمک میکنند:
روند مهمتر از عدد لحظهای است
نرخ قبولی ۷۰ درصد در روز اول تست طبیعی است. همین عدد در روز آخر پیش از انتشار نگرانکننده است. عددها را همیشه در طول زمان و در مقایسه با نسخههای قبلی نشان دهید.
عددها را با هم بخوانید
- پیشرفت اجرای پایین همراه نرخ مسدودی بالا یعنی مشکل از محیط یا وابستگیهاست، نه از تیم تست.
- نرخ قبولی بالا همراه پوشش نیازمندی پایین یعنی بخشهایی از محصول اصلاً دیده نشده است.
- کاهش باگهای جدید همراه کاهش اجرای تست، لزوماً نشانه بهبود کیفیت نیست.
شدت را در نظر بگیرید
ده باگ جزئی با یک باگ بحرانی برابر نیست. تعداد باگها را همیشه بر اساس شدت تفکیک کنید. تعریف سطحهای شدت را در چرخه عمر باگ توضیح دادهایم.
زمینه کسبوکار را فراموش نکنید
یک عدد یکسان در دو محصول معنای متفاوتی دارد. نشت باگ اندک در یک ابزار داخلی شاید قابل قبول باشد. همان عدد در سامانه پرداخت یا سلامت، ریسک جدی است. آستانههای قابل قبول را با مالک محصول و بر اساس ریسک کسبوکار تعیین کنید. این آستانهها بخشی از معیارهای خروج در طرح تست هستند.
معیارهایی که گمراه میکنند
بعضی عددها سادهاند اما رفتار نادرست ایجاد میکنند:
- تعداد تستکیسها: تعداد زیاد تست لزوماً پوشش بهتر نیست. ممکن است تستها تکراری یا سطحی باشند.
- تعداد باگ به ازای هر تستر: تسترها را به ثبت باگهای کوچک و تکراری تشویق میکند و همکاری را کم میکند.
- صددرصد پوشش کد بهعنوان هدف: تیم را به نوشتن تستهای بیارزش برای رسیدن به عدد سوق میدهد.
- مقایسه تیمها با یک عدد: محصولات، ریسکها و بلوغ تیمها متفاوت است.
قاعده کلی این است: معیار را برای فهم وضعیت به کار ببرید، نه برای ارزیابی عملکرد فردی. وقتی عدد به هدف شخصی تبدیل شود، ارزش اطلاعاتیاش کم میشود.
گزارش کیفیت برای مدیران
مدیران وقت محدودی دارند. گزارش کیفیت باید در یک نگاه به سؤال اصلی پاسخ دهد: وضعیت انتشار و ریسکهای آن.
ساختار پیشنهادی گزارش یکصفحهای
- خلاصه وضعیت: یک جمله؛ مثلاً «آماده انتشار با دو ریسک شناختهشده».
- شاخصهای اصلی: پیشرفت اجرا، نرخ قبولی، پوشش نیازمندی و باگهای باز بر اساس شدت.
- روند: مقایسه با اجرای قبلی یا نسخه قبلی.
- ریسکها و موانع: نیازمندیهای تستنشده، باگهای بحرانی باز و موانع محیطی.
- پیشنهاد تیم تست: انتشار، انتشار مشروط یا تعویق، همراه دلیل.
نمونه جدول خلاصه
| شاخص | این نسخه | نسخه قبل | توضیح |
|---|---|---|---|
| پیشرفت اجرا | ۹۵٪ | ۹۸٪ | ۱۲ تست به دلیل در دسترس نبودن سرویس پرداخت آزمایشی مسدود است |
| نرخ قبولی | ۹۱٪ | ۸۹٪ | — |
| پوشش نیازمندی | ۹۶٪ | ۹۲٪ | دو نیازمندی جدید هنوز تست ندارند |
| باگهای باز بحرانی | ۰ | ۱ | — |
| باگهای باز با شدت بالا | ۲ | ۳ | هر دو در ماژول گزارشها؛ راهحل موقت وجود دارد |
عددهای این جدول فقط برای نمایش قالب هستند. عددهای واقعی را از دادههای تیم خودتان بگیرید.
نمایش بصری عددها
نمودار درست، روند را سریعتر از جدول نشان میدهد. چند انتخاب ساده کافی است:
- نمودار خطی برای روند نرخ قبولی یا باگهای باز در طول روزها.
- نمودار میلهای انباشته برای تفکیک نتیجهها به پاس، شکست، مسدود و اجرانشده.
- نمودار میلهای برای مقایسه چگالی باگ بین ماژولها.
از نمودارهای سهبعدی و رنگهای زیاد پرهیز کنید. هر نمودار باید عنوان، واحد و بازه زمانی روشن داشته باشد.
تناوب و مخاطب
- گزارش روزانه: برای تیم در دوره تست فشرده؛ کوتاه و عملیاتی.
- گزارش پایان اجرا یا اسپرینت: برای راهبر تیم و مدیر محصول.
- گزارش پایان انتشار: برای مدیران؛ شامل روند و درسهای آموخته.
محتوا و تناوب گزارشها را در طرح تست مشخص کنید تا انتظارها از ابتدا روشن باشد.
شروع کار با معیارهای تست
لازم نیست همه معیارها را یکباره پیاده کنید. این مسیر سادهتر است:
- سه تا پنج معیار انتخاب کنید: معمولاً پیشرفت اجرا، نرخ قبولی، باگهای باز بر اساس شدت و پوشش نیازمندی شروع خوبی است.
- منبع داده را مشخص کنید: هر عدد باید از یک منبع قابل اعتماد بیاید، نه از شمارش دستی.
- تعریفها را مستند کنید: مثلاً مشخص کنید تست مسدود در «اجراشده» حساب میشود یا نه.
- چند دوره داده جمع کنید: روند بعد از چند نسخه معنا پیدا میکند.
- مرور و اصلاح کنید: معیاری که به هیچ تصمیمی کمک نمیکند را کنار بگذارید.
برای معیارهای مربوط به رگرسیون و اتوماسیون، مقالههای تست رگرسیون و اتوماسیون تست را هم ببینید.
در TestRail نتیجه هر تست با وضعیتهای Passed، Failed، Blocked، Retest یا Untested ثبت میشود. به همین دلیل پیشرفت اجرا و نرخ قبولی هر اجرا، طرح و مایلستون بدون شمارش دستی در دسترس است. گزارشهای داخلی خلاصه نتیجهها، مقایسه اجراها و پوشش بر اساس ارجاعها را نشان میدهند. اتصال به Jira هم باگهای ثبتشده روی نتیجهها را کنار همین عددها قرار میدهد. برای دیدن اینکه تیمهای نرمافزاری چطور از این گزارشها استفاده میکنند، صفحه TestRail برای تیمهای نرمافزاری را ببینید.
جمعبندی
معیارهای تست نرمافزار وضعیت تست و کیفیت محصول را قابل اندازهگیری میکنند. معیارهای کم اما معنادار انتخاب کنید و تعریف هرکدام را مستند کنید. عددها را با هم و در طول زمان بخوانید و از تبدیل آنها به ابزار ارزیابی فردی پرهیز کنید. گزارش کیفیت برای مدیران باید کوتاه، روندمحور و همراه پیشنهاد روشن باشد. برای مرور مفاهیم پایه، به راهنمای تست نرمافزار برگردید.