فرض بر این است که خواننده، اهمیت تست و تضمین کیفیت را در حیات یک کسب و کار نرم‌افزاری بداند. در اینجا به این موضوع پرداخته نمی‌شود. اما کافی است بدانید که بخش بزرگی از عامل موفقیت شرکت‌های بزرگ نرم‌افزاری فرآیند تضمین کیفیت و تست است. برای مثال علت اصلی شکست Flud به عنوان یک بیزینس بزرگ را نبود فرآیند موثر QA می‌دانند.
در فرآیند تست، مهندسین تست همیشه با چالش‌هایی روبه‌رو هستند که اگر اصول پیاده‌سازی و اجرای تست را به درستی درک نکنند در این چالش‌ها موفق نیستند. به عنوان مثال از مهندسین تست یا مدیران تست می‌شنویم:
در واقع چالش اصلی را می‌توان در این نکته خلاصه کرد که کسی که دانش تست دارد لزوما مهندس تست نیست! در تعریف مهندس آمده است که « یک مهندس می‌بایست ضمن شناخت مسئله یا موضوع کاری، علوم و فنون لازم، محدودیت‌های مربوطه را تشخیص دهد تا بتواند به دستاوردهای لازم برسد.»
همین امر در حرفه‌های مرتبط با نرم‌افزار هم دیده می‌شود که توسعه‌دهنده‌ها با مطالعه syntax های یک زبان برنامه نویسی مهارت خود را برای توسعه یک نرم‌افزار کافی می‌بینند.
یکی از مهار‌ت‌هایی که هر مهندس باید داشته باشد این است که بتواند با بودجه محدود بهترین فرآیند تست را برای تست محصول تشخیص و راه‌اندازی نماید در غیر این صورت بهره‌وری پایین تست سبب می‌شود که مدیران و ذی نفعان پروژه تست را کم اهمیت تشخیص دهند و بودجه آن را کمتر کنند (اگر بودجه‌ای در نظر گرفته باشند!).
مهندس تست باید همیشه از خود بپرسد آیا تست‌های پیاده شده ارزشی دارد؟ آیا فرآیند تست از این بهتر نمی‌شود؟ چه قدمی برای کاهش هماهنگی بین تسترها و تیم توسعه می‌تواند بردارد؟
هر چه نرم‌افزار بزرگتر می‌شود این چالش‌ها مشکل تر و پیچیده تر است و صرفا با به خدمت گرفتن ریسورس بیشتر حل نمی‌شود. در این حالت، به جای استفاده بیشتر و بیشتر از ریسورس‌ها یا افزایش نیرو‌های تست، باید استراتژی‌های تست را تغییرداد. چرا که در دنیای واقعی، هر پروژه به یک رویکرد و استراتژی منحصر به فرد نیاز دارد.
تجربه شخصی نویسنده این است که در بیشتر موارد، نبود استراتژی درست علت اصلی موثر نبودن تست است و در خیلی از موارد دیده شده که بدون هزینه اضافی و صرفا با تغییر رویکرد و استراتژی تیم تست، فرآیند تست کارا تر بوده است.
اما پاسخ دادن به این سوالات ساده نیست و نیاز به تجربه و دانش کافی دارد. زیرا استراتژی مشخص و ثابتی برای تست همه نرم‌افزارها وجود ندارد. ممکن است نرم‌افزار تحت تست، نرم‌افزاری کوچک باشد و صرفا با تست‌های دستی ساده بتوان نیازمندی آن را برطرف نمود از طرفی ممکن است به حدی پیچیده و یا بزرگ باشد که صرفا با یک فرآیند تست اتوماتیک ساده نتوان پاسخگوی نیاز آن باشیم.
در همین راستا، مواردی را ذکر می‌کنیم که مهندسین تست بتوانند با آن ارزش تستها را بالا ببرند یا بر اساس بودجه تعیین شده برای تست بهترین بهره‌وری از آن را داشته باشند.
کدام بخش از تستها باید به صورت دستی و کدام بخش‌ها باید اتوماتیک باشند؟
برای افزایش بهره‌وری تست لزومی ندارد همه تستها اتوماتیک شوند. تست‌هایی باید اتوماتیک شوند که:
شاید بپرسید که از موارد بالا چگونه می‌توان به این نتیجه رسید که کدام تستها باید اتوماتیک شوند؟ در صورتی که معیار کاهش هزینه‌ها باشد، یک راهکار ساده برای بررسی این موضوع، می‌تواند بررسی هزینه میان مدت در دو حالت تست دستی و اتوماتیک باشد.
برای مثال برای یک پروژه با اندازه متوسط می‌توان هزینه‌های پیاده‌سازی، نگهداری و اجرای تست‌های اتوماتیک را با تست‌های دستی در یک بازه زمانی ۶ ماهه مقایسه کرد تا بتوان میزان به صرفه بودن تست‌های اتوماتیک را بررسی کرد.
از طرفی باید توجه داشت که اتوماتیک کردن برخی از روش‌های تست ممکن است چالش‌های زیادی را داشته باشد. برای توضیح بیشتر مطلب مزیت-تست-اتوماتیک-نرم-افزار-و-اپلیکیشن را مطالعه کنید.
برای مثال تست اکتشافی (exploratory testing) باید به صورت دستی پیاده شود. زیرا در این حالت تست کیس نوشته نمی‌شود و تسترها با نگاه موشکافانه در جهت کشف خطا‌ها اقدام می‌کنند.
بهره گرفتن از یک مهندس QA امری ضروری در این راستا می‌تواند باشد
