تست در شرکتهای کوچک و متوسط

در سوئد عنوان Test engineer یا Quality Assurance چند سالی است که در شرکتهای نرم افزاری با اندازه کوچک و متوسط (حد اکثر 250 نفر پرسنل) مطرح شده است که علت آن میتواند گسترش کسب و کارهای خلاق و دانش بنیان از یک طرف و از طرفی دیگر رقابت این کسب و کارها در جذب مشتری در فضای بازار آزاد باشد. فضای رقابتی که در آن شرکتها وادار میشوند کیفیت محصول نرم افزار خود را هم  بخاطر بهبود تجربه مشتری Customer Experience و هم کاهش حجم کاری بخش خدمات پس از فروش و نتیجه کاهش هزینه ها، در سطح قابل قبولی نگه دارند. البته این توجه به کیفیت تنها محدود به استخدام Test engineer نمیشود بلکه در کل منجر به بازبینی در فرایند های تولید نرم افزار و بالا بردن آگاهی و حساسیت  بخش تحقیق و توسعه (R&D)  میشود.

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

این مشکلات در مجموع باعث میشود که برنامه نویسان بازخورد سریع و دقیقی از کیفیت کد خود نداشته باشند. در نتیجه رفته رفته مدیران فنی (CTO) به این فکر افتادند که tester هایی استخدام کنند که هم تحصیلات مرتبط با علوم کامپیوتر داشته باشند و هم تا حد قابل قبولی توانایی درک کد نرم افزار شرکت و هم اسکریپت نویسی برای test automation را داشته باشند. ورود من به دنیای تست نرم افزار مصادف با همین روند تغییر در شرکت های کوچک و متوسط بود. زمانی که هم از یک سو بخاطر پیش زمینه فکری برنامه نویس ها از tester های قبلی، باید توانایی فنی خود را  در R&D  ثابت میکردم و هم اینکه در نبود افراد با تجربه در زمینه استفاده از ابزارهای تست و automation باید به تنهایی روش و ابزار مناسب را پیدا کرده و آن را یاد میگرفتم.  در پست بعدی در مورد یکی از این چالشها مینویسم.