شاید به این فکر می‌کنید که شرکت نرم‌افزاری‌تان باید یک تستر استخدام کند یا نه. ۵ دلیلی را مطرح می‌کنیم که معمولاً تستر استخدام نمی‌کنند.
برنامۀ بتا دارید
برخی فکر می‌کنند که بهترین راه برای اشکال‌یابی یک سیستم تحویل آن به یکمشتری و انتظار دریافت تیکت‌هاست. صنعت شما بر ما معلوم نیست اما تا جایی که می‌دانیم یافتن مشتری‌های خوب جداً دشوار است. قطعاً نمی‌خواهیم کارمان را با تحویل نرم‌افزارهای مشکل‌دار بدتر کنیم.
به‌طو مثال صنعت مخابرات را که استاندارد اطمینان ۵ تا ۹ دارد درنظر بگیرید. اگر به مشتری پیشنهاد شود که نرم‌افزار در فاز بتا باشد، سریعاً ارتباطشان را قطع می‌کنند. البته این در همۀ صنایع صادق است.
فرض کنید که مقاله‌ای بنویسیم که خطاهای دستورزبانی نداشته باشد اما کم‌وبیش جمله‌ای جاافتاده باشد. آیا به خودتان زحمت می‌دهید که به ما ایمیلی بفرستید و اطلاع بدهید که مقاله مشکلی دارد؟ آیا خبرنامۀ ما را به همکارانتان پیشنهاد می‌کنید؟ گمان نمی‌کنیم! پس فکر کنید که مشتریان شما چه احساسی دارند وقتی که نقص و خطاهایی را در نرم‌افزار حیاتی خود می‌یابند.
توسعه‌دهندگان تنبل می‌شوند
برخی مدیران فکر می‌کنند که اگر توسعه‌دهنده‌ها بدانند که شخص دیگری مسئول آزمون آن‌هاست تنبل می‌شوند. اما کسی که به کارش افتخار می‌کند، صرف‌نظر از اینکه یک تیم مختص تسترها دارید یا خیر، خودش کدش را با دقت تست می‌کند.
اگر توسعه‌دهندگان تنبل می‌شوند، تسترها را سرزنش نکنید، توسعه‌دهندگان را سرزنش کنید! استخدام نکردن یک تیم تستر وضعیت شما را بهتر نمی‌کند. حتی بدتر هم می‌کند؛ زیرا کد ضعیف توسعه‌دهنده شما در آزمایشگاه تستر رو نمی‌شود بلکه در دستان مشتری، خودش را نشان می‌دهد.
نمی‌توانیم خرج تسترها را بدهیم
اگر می‌توانید خرج تست را بدهید می‌توانید از پس هزینۀ تستر هم برآیید. سبک‌سنگین‌های مالی و استدلال صحیح به شما اثبات می‌کند که به‌کارگیری متخصصان و کارشناسان به‌صرفه‌تر است؛ البته مادام اینکه بتوانید این متخصصان را مشغول نگه دارید.
اگر در ماه ۵۰ نفر برای توسعۀ نرم‌افزار احتیاج دارید، با اعداد و ارقام اثبات می‌شود که در ماه ۲۵ نفر برای آزمون و اعتبارسنجی آن استخدام می‌کنید. کدام به‌صرفه‌تر است؟ به‌کارگیری ۲۵ نفر در ماه برای آزمون توسعه‌دهندگان و تسترها؟
دلایل زیادی هست که شرکت‌های نرم‌افزاری باید یک تیم متخصص از تسترها و افراد متخصص QA داشته باشند که نرم‌افزاری را که توسعه‌دهنده‌ها توسعه می‌دهد آزمون کنند. این کار آن‌هاست؛ نسبت ۱ به ۳ را درنظر بگیرید و به ازای هر سه توسعه‌دهنده یک تستر استخدام کنید، حتی اگر به‌معنای این باشد که برای متوازن نگه داشتن بودجۀ هزینه انسانی یک توسعه‌دهنده حذف می‌کنید.
تسترها باگ‌های بسیاری را پیدا می‌کنند
این بهانه مزخرف‌تر از دلایل قبلی است. موافقم که در برخی از موارد باگ‌های گزارش آزمون بی‌ارزش هستند. کارکترهای غیر ASCI را در یک فیلد وارد کنید، ASCII را در دیگری و کارهای بی‌اهمیت دیگر و سپس کلید را می‌فشارید، و سیستم خطا را برمی‌گرداند. هیچ مشتری‌ای تابه‌حال در این سناریو ِاستقرارِ زنده وارد نشده است.
اگر فکر می‌کنید که تستر شما باگ‌های بی‌اهمیت زیادی را پیدا می‌کند آن‌ها راهنمایی کنید. تلاششان را مسخره نکنید یا گزارش‌های مشکل را نادیده نگیرید. موارد استفاده موردنظر خود و محدودیت‌های شناخته‌شده و قابل‌قبول را شناسایی کنید.
نمی‌توانیم هیچ تستر خوبی بیابیم یا حفظش کنیم
در این مشکل واقعاً حق با شماست. تسترهای خوب به‌سختی پیدا می‌شوند و تسترهای طرازاول، تیم توسعۀ محصول شما را دگرگون می‌کنند. بازهم دلیلی نیست که نخواهید یک تیم متخصص تست داشته باشید.
سه پیشنهاد برای حفظ تسترها:
- وقتی تستر استخدام می‌کنید، درجست‌وجوی افرادی باشید که حداقل یک نقش QA داشته باشند. پذیرای فارغ‌التحصیلان و کسانی که این سمت را می‌پذیرند باشید. ممکن است به‌محض دوران آزمایشی‌شان درخواست تغییر سمت کند.
- به تستر خود حقوق رقابتی پیشنهاد کنید. برخی از شرکت‌ها معمولاً به تسترهای خود کم‌تر از توسعه‌دهنده پرداخت می‌کنند. درنتیجه تسترها درخواست تغییر سمت می‌کنند زیرا می‌خواهند حقوق بیشتری کسب کنند، و البته نمی‌توانید سرزنششان کنید. میزان پرداختتان را بالا ببرید تا انگیزه‌ای برای ماندنشان در تیم QA فراهم کنید.
- به تسترها اجازه بدهید که مهارت‌های فنی‌شان را تقویت کنند. به آن‌ها فرصتی بدهید که متن‌های آزمون‌شدۀ تستشان را بگیرند، نصب کنند و شبکه‌های تست را پیکربندی کنند و دوره‌های توسعه و طراحی ببینند. با ارائه این مزایا می‌توانید تسترهای خودتان را ترغیب کنید که طی مدت طولانی در نقش خود بمانند. تا وقتی که تصمیم می‌گیرند که به تیم توسعه بروند آماده‌تر باشند.
فلسفۀ اشکال‌یابی (دیباگینگ) و روش درست آن چیست؟ در خط دید بخوانید.
