استراتژی تست نرمافزار
دو موضع افراطی در این حوزه هست و هر دو پرهزینهاند.
یکی میگوید تست وقت تلفکردن است و «ما که خودمان امتحان میکنیم». دیگری میگوید پوشش تست باید صد درصد باشد و بدون آن چیزی منتشر نمیشود.
اولی سامانهای میسازد که هر تغییرش قمار است. دومی پروژهای میسازد که نصف بودجهاش صرف نگهداری تستهایی میشود که هیچ باگی نمیگیرند.
سؤال درست این نیست که «چقدر تست بنویسیم». این است که کدام خرابی برای این کسبوکار گران است، و ارزانترین راه گرفتنش کدام است.
سه لایه و کاری که هرکدام میکند
تست واحد
کوچکترین قطعه را جدا امتحان میکند. سریع — هزارانتا در چند ثانیه — و ارزان.
بهترین کاربردش منطق پیچیده و بیوابستگی است: محاسبهٔ تخفیف پلهای، تبدیل تاریخ، قواعد مالیاتی، محاسبهٔ کرایه بر اساس مسافت و زمان. هر جا فرمولی هست که چند حالت مرزی دارد، تست واحد ارزانترین بیمه است.
بدترین کاربردش تست گترها و سترها و کدهایی است که منطقی ندارند. اینها پوشش را بالا میبرند و هیچ باگی نمیگیرند — که دقیقاً همان چیزی است که پوشش را به سنجهٔ گمراهکننده تبدیل میکند.
تست یکپارچگی
چند قطعه با هم، معمولاً همراه پایگاه دادهٔ واقعی. کندتر و بهمراتب ارزشمندتر در سامانههای سازمانی.
چرا؟ چون بیشتر باگهای واقعی در مرزها هستند، نه داخل قطعهها: کوئریای که شرط دسترسی را جا انداخته، تراکنشی که نیمهکاره مانده، اتصالی که پاسخ غیرمنتظره گرفته.
اگر بودجهٔ تست محدود دارید، این لایه بیشترین بازده را دارد. توصیهٔ ما در پروژههای سازمانی، وزندادن به همین لایه است — برخلاف هرم کلاسیک تست که وزن را روی تست واحد میگذارد.
تست سرتاسری
کل سامانه از دید کاربر، از مرورگر تا پایگاه داده.
گران، کند، و شکننده. هر تغییر کوچک در رابط کاربری میشکندشان. تیمی که صد تست سرتاسری دارد، معمولاً تیمی است که یاد گرفته آنها را نادیده بگیرد — و تستی که نادیده گرفته میشود از نبودنش بدتر است، چون هزینهٔ نگهداری دارد و اعتماد کاذب میدهد.
قاعدهٔ ما: فقط برای مسیرهای درآمدزا. ثبتنام، افزودن به سبد، پرداخت، ثبت سفارش. پنج تا ده تست سرتاسری که همیشه سبزند، از صدتای بیاعتبار بهترند.
چه چیزی را حتماً تست کنید
اگر فهرست کوتاهی میخواهید، اینها در سامانههای سازمانی بیشترین بازده را دارند:
- هر جا پول حساب میشود. قیمت، تخفیف، مالیات، کرایه، تسویه. گرانترین باگها اینجایند و شرمآورترینشان هم.
- بررسی دسترسی. «آیا کاربر الف میتواند رکورد کاربر ب را ببیند؟» این تست را برای هر نقش بنویسید. چرایش در سطوح دسترسی.
- حالتهای مرزی داده. خالی، صفر، منفی، خیلی بزرگ، متن فارسی با اعداد فارسی، شمارهٔ تلفن با فرمتهای مختلف.
- اتصالهای بیرونی در حالت خطا. سرویس پاسخ نمیدهد، کند است، پاسخ ناقص میدهد. این را با شبیهسازی تست کنید نه با سرویس واقعی.
- باگی که یک بار اتفاق افتاده. هر باگ تولیدی باید قبل از رفع شدن، یک تست بگیرد. این تنها راه تضمین برنگشتنش است.
آن مورد آخر سادهترین قاعدهای است که میشود امروز شروع کرد و بیشترین اثر را در بلندمدت دارد.
تست دستی هم لازم است
خودکارسازی همهچیز نه ممکن است نه لازم. چیزهایی هست که فقط آدم میبیند:
- آیا این صفحه گیجکننده است؟
- آیا پیام خطا برای کاربر واقعی معنا دارد؟
- آیا چیدمان در فارسی به هم ریخته؟
- آیا این جریان کاری با فرایند واقعی سازمان میخواند؟
تست اکتشافی — که در آن کسی با سامانه بازی میکند تا بشکندش — باگهایی پیدا میکند که هیچ تست نوشتهشدهای نمیگیرد، چون تست فقط چیزی را میآزماید که نویسندهاش به آن فکر کرده.
نکتهٔ عملی: بگذارید کسی جز نویسندهٔ کد این کار را بکند. نویسنده ناخودآگاه همان مسیری را میرود که در ذهنش ساخته.
محیط تست، مسئلهای که دستکم گرفته میشود
بیشتر «باگهای عجیب» ریشهشان در تفاوت محیط است. سه توصیه:
محیط آزمایش باید شبیه محیط اصلی باشد — همان نسخهٔ پایگاه داده، همان پیکربندی. تفاوتها را بنویسید تا بدانید کجا نمیشود به تست اعتماد کرد.
دادهٔ آزمایشی واقعینما بسازید. سامانهای که فقط با ده رکورد تست شده، در روز اول با صد هزار رکورد رفتار دیگری دارد. مخصوصاً صفحات فهرست و گزارشها.
دادهٔ واقعی مشتریان را در محیط آزمایش نگذارید — یا دستکم پیش از انتقال ناشناسسازی کنید. این یکی از شایعترین نشتهای داده در پروژههای سازمانی است و معمولاً از سر بیتوجهی رخ میدهد نه بدخواهی.
اگر هیچ تستی ندارید
سامانهای که سالها بدون تست کار کرده و حالا هر تغییرش ترسناک است، وضعیت شایعی است. مسیری که در این پروژهها جواب داده:
۱. تست ننویسید برای همهچیز. تلاش برای پوششدادن سامانهٔ موجود، ماهها طول میکشد و نیمهکاره رها میشود.
۲. از باگها شروع کنید. هر باگی که گزارش میشود، اول تستی که آن را نشان دهد، بعد رفع. این کار خودبهخود پوشش را دقیقاً همانجا میبرد که باگها هستند.
۳. کد جدید با تست بیاید. پوشش قدیمی را رها کنید؛ فقط نگذارید بدتر شود.
۴. سه تا پنج مسیر حیاتی را سرتاسری بگیرید. همانهایی که اگر بشکنند کسبوکار میایستد.
بعد از شش ماه، پوشش شما دقیقاً روی پرریسکترین بخشها متمرکز است — که بهتر از پوشش یکنواخت هفتاد درصدی است.
پوشش تست، و چرا سنجهٔ بدی است
عدد پوشش میگوید چند درصد خطوط کد اجرا شدهاند. نمیگوید چیزی واقعاً بررسی شده. تستی که کد را اجرا کند و هیچ ادعایی نکند، پوشش میسازد و ارزشی ندارد.
اگر هدف عددی بگذارید، تیم به آن عدد میرسد — به ارزانترین شکل ممکن، که معمولاً همان تستهای بیارزش است.
سنجههای بهتر: تعداد باگهایی که به تولید میرسند، و مدت زمان از گزارش باگ تا رفعش. اینها نتیجه را میسنجند نه فعالیت را.
و یک جمعبندی کوتاه
تست، خرید بیمه است. بیمهٔ بیشتر همیشه بهتر نیست؛ بیمهٔ متناسب با خسارت بهتر است.
برای فروشگاهی که روزی صد میلیون تومان فروش دارد، تست مسیر پرداخت واجب است. برای پنل داخلی که پنج نفر از آن استفاده میکنند، تست کامل رابط کاربری اسراف است.
این تناسب را کسی باید بنشیند و یک بار تعیین کند. تیمهایی که این گفتوگو را نکردهاند، معمولاً هم بیش از حد تست دارند و هم در جای غلط.