در سوئد عنوان مهندس تست نرم افزار یا Quality Assurance (تضمین کیفیت) نزدیک به دو دهه است که در شرکتهای نرم افزاری با اندازه کوچک و متوسط (حد اکثر 250 نفر پرسنل) مطرح شده است که علت آن میتواند گسترش کسب و کارهای خلاق و دانش بنیان از یک طرف و از طرفی دیگر رقابت این کسب و کارها در جذب مشتری در فضای بازار آزاد باشد. فضای رقابتی که در آن شرکتها وادار میشوند کیفیت محصول نرم افزار خود را هم بخاطر بهبود تجربه مشتری (Customer Experience) و هم کاهش حجم کاری بخش خدمات پس از فروش و نتیجه کاهش هزینه ها، در سطح قابل قبولی نگه دارند. البته این توجه به کیفیت تنها محدود به استخدام مهندس تست نمیشود بلکه در کل منجر به بازبینی در فرایند های تولید نرم افزار و بالا بردن آگاهی و حساسیت بخش تحقیق و توسعه (R&D) میشود.
در ابتدای این روند بهبود کیفیت، Quality Assurance عمداً محدود به انجام تستهای functional به صورت دستی میشد که بر اساس معیارهایی پذیرشی بود که مدیر نرم افزار قبل از کد نویسی در سر داشته یا مستند کرده است. در نتیجه کسی که این تستها را انجام میداد باید فردی باشد که میتوانست به اندازه یک کاربر حرفه ای از نرم افزار استفاده کند و البته کمی هم با محیط تست یعنی سیستم عامل و سخت افزار آشنایی داشته باشد. برای همین در آگهی های استخدام نوشته میشد تحصیلات مرتبط با کامپیوتر یک امتیاز است و نه الزام. این باعث میشد که تست کننده ها مانند غریبه های در R&D دیده شوند. چون هم توانایی فنی ارتباط با برنامه نویسها را نداشتند و هم مدت زمان نسبتاً زیادی طول میکشید که محدودیتها و معماری سیستم را یاد بگیرند و در نتیجه گزارش باگهای اشتباه ندهد. علاوه براین تست کننده بخاطر عدم تسلط به اسکریپت نویسی نمیتوانست در صورت نیاز در فرایند خودکارسازی در مرحله تست سیستم (System Test) به صورت جعبه سیاه (Black box)، مشارکت کند و در نتیجه در صورت اصرار مدیر نرم افزار، خود برنامه نویس مجبور به یادگیری ابزار یا API تستی میشد که علاقه ای به آن نداشت و هم در مواردی این خودکارسازی را برای بخشی از نرم افزار انجام میداد که خود آن را نوشته بود. این مورد آخر که در آینده بیشتر در مورد آن مینویسم در بسیاری از اوقات محدود به تستهای happy path میماند و کیفیتی کاذب را نتیجه میدهد.
این مشکلات در مجموع باعث میشود که برنامه نویسان بازخورد سریع و دقیقی از کیفیت کد خود نداشته باشند. در نتیجه رفته رفته مدیران فنی (CTO) به این فکر افتادند که تست کننده هایی استخدام کنند که هم تحصیلات مرتبط با علوم کامپیوتر داشته باشند و هم تا حد قابل قبولی توانایی درک کد نرم افزار شرکت و هم اسکریپت نویسی برای خودکارسازی تست را داشته باشند. ورود من به دنیای تست نرم افزار (سال 2012) مصادف با همین روند تغییر در شرکت های کوچک و متوسط بود. زمانی که هم از یک سو بخاطر پیش زمینه فکری برنامه نویس ها از مهندسین تست قبلی، باید توانایی فنی خود را در R&D ثابت میکردم و هم اینکه در نبود افراد با تجربه در زمینه استفاده از ابزارهای تست و خودکارسازی باید به تنهایی روش و ابزار مناسب را پیدا کرده و آن را یاد میگرفتم. در پست بعدی در مورد یکی از این چالشها مینویسم.
