تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
تفاوت بین یک توسعه دهنده، آزمونگر و یک مهندس توسعه نرم افزار در آزمون نرم افزار (Software Development Engineer in Test-SDET) چیست؟
این موضوع شوخی نیست. در واقع، این یک سوال بسیار جدی است که در جامعه توسعه‌دهندگان نرم‌افزار مورد بحث است. دیدگاه Agile اتفاق بزرگی را رقم زد و آن اتفاق، محو شدن تمایز تاریخی بین آزمونگران نرم‌افزار و توسعه‌دهندگان بود. وقتی همه چیز خوب پیش می‌رود، توسعه‌دهندگان بیشتر به آزمون می‌پردازند و احساس مسئولیت بیشتری نسبت به کیفیت محصول خواهند داشت. آزمونگران نیز در ابتدای هر اسپرینت شروع به طراحی آزمون می‌کنند و به طور مداوم در این حلقه هستند، به همین دلیل است که می‌توان از آنها استفاده کرد. اگر همه چیز خوب پیش برود، نواقص کمتری به سورس کد وارد می‌شود، در نتیجه نقش آزمونگران از پیدا کردن اشتباهات توسعه‌دهندگان به تحقق تجربه کاربری، تغییر می یابد.
با این حال، یک موضوع مهم در این میان، این است که چه مقدار از مسئولیت تست باید به توسعه‌دهندگان منتق شود، و از طرف دیگر تا چه حد داشتن دانش برنامه‌نویسی برای آزمونگران مهم است؟ من فکر می‌کنم که پیشنهاد یکپارچه‌سازی نقش‌ها(تبدیل شدن توسعه‌دهندگان به آزمونگر و آزمونگرها به برنامه‌نویس) که از جمله اهداف متدولوژی Agile است، ضروری است چون:
۱- خارج از GAFA، درخواست توسعه‌دهندگان برای تبدیل شدن به آزمونگر بر سرعت نوآوری تاثیر می‌گذارد
اگر شما گوگل، اپل، فیس‌بوک یا آمازون(که به صورت مخفف اصطلاحا GAFA نامیده می‌شود) هستید، همیشه باید استعداد بالایی داشته باشید تا بتوانید سرعت نوآوری ارائه شده در بازار را افزایش دهید. اگر شما نیاز به افزایش سرعت در پروژه‌های موجود و یا راه‌اندازی پروژه جدید دارید، حتی می‌توانید توسعه‌دهندگان بالا رده را در نقش مهندس توسعه نرم‌افزار در تست قرار دهید. بسیاری از توسعه‌دهندگان مشتاق این موقعیت نه چندان مطلوب هستند به این امید که بتوانند یک روز در رویای کارفرمای خود به یک توسعه‌دهنده کامل تبدیل شوند.
با این حال، در شرکت‌های بزرگ شما از نعمت توسعه‌دهندگان رده بالایی که درب اتاق شما را بزنند، برخوردار نیستید. به همین دلیل جذب و حفظ توسعه‌دهندگان با ارزش، جز دغدغه‌های مداوم است. در نتیجه، زمانی که همه توسعه دهندگان بالقوه در حال توسعه هستند، برآوردن تقاضای ناپایدار کسب و کار برای نرم افزار، به اندازه کافی سخت است. شما به سادگی نمی‌توانید توسعه‌دهندگان را بر روی وظایف تست در سطح بالا متمرکز کنید. جاییکه اگر آزمونگران حرفه‌ای بهتر از عهده بر نیایند، قطعا به می‌تواند به خوبی کار را جمع کنند.
۲- عدم نیاز به مهارت برنام نویسی برای پایین‌ترین سطح آزمون خودکار نرم‌افزار
به منظور پاسخگویی سریعتر به انتظارات و نیازمندی‌ها، متدهای توسعه نرم‌افزار بسیار لاغرتر و سبک‌تر شده‌اند، تا بدین ترتیب انتظارات تیم‌ها را برای نرم‌افزار‌های سریعتر برآورده نمایند. همچنین فن‌آوری‌های آزمون نرم‌افزار نیز پیشرفت کرده‌اند. در این راستا رویکردهای سبک اسکریپت‌نویسی برای اعمال سریع تغییرات طراحی شده‌اند. با این حال، بسیاری از تیم‌ها هنوز هم این ذهنیت را دارند که خودکارسازی آزمون، نیازمند رویکرد نگهداشت سنگین و تست مبتنی بر اسکریپت است که چند دهه پیش معرفی شد، که البته هنوز هم نتایج ضعیفی(در بهترین حالت نرخ اتوماسیون آزمون نرم‌افزار برابر ۲۰ درصد است) ارائه می‌دهد. تقریبا در بین تمامی صنایع، مردم پذیرفتند که نرم‌افزار بوسیله تجزیه سطوح پیچیدگی، درجات پیشرفته‌ای از اتوماسیون را ممکن می‌سازد. وقت آن رسیده که صنعت آزمون نرم افزار نیز این موضوع را پذیرا باشد.
تحقیقات شرکت Tricentis در محیط‌های سازمانی در صنایع مختلف، نشان می‌دهد که رویکردهای بدون اسکریپت(Scriptless) به طور قابل توجهی پایدارترند. این رویکردهای، رایج‌ترین تنگناهای آزمون را حذف می‌کنند. اول اینکه تعداد اعضای تیم که می‌توانند در آزمون نرم افزار موثر باشند را افزایش می‌دهد؛ دوم اینکه با توجه به قابلیت استفاده مجدد(ریاReusability) و ماژولار بودن، هماهنگ شدن با برنامه‌های در حال توسعه آسانتر است، و نکته سوم اینکه شما را از نگهداشت Test Code base که تنها برای آزمودن Code Base واقعی شما طراحی شده است، خلاص می‌کند.
۳- آزمون توسط هر دو گروه توسعه دهندگان و آزمونگران، سریعتر انجام خواهد شد
تجربه من نشان داده است که اگر آزمون نرم افزار، توسط هر دو گروه توسعه‌دهندگان و آزمونگران حرفه‌ای انجام شود، نواقص مهم خیلی سریعتر افشا خواهند شد. تشخیص هر گونه نقصدر اسرع وقت منجر به تاثیر بسیار مهمی بر سرعت پیشرفت اسپرینت و جلوگیری از افزایش نرخ نقص گزارش شده در آینده خواهد داشت.
توسعه دادن تست، برای افشای خطاهای برنامه‌نویسی ایده آل است. این آزمون شامل بررسی Functionality(کارکرد) و Stability(ثبات) کد است که برای اجرای یک داستان کاربری نوشته می‌شود. این موضوع بسیار مهم است، چرا که اگر برخی از اشتباهات سطح پایین، وارد Code Base شوند، یافتن و تشخیص این مشکل با یک تست یونیت مستقیم نسبت به یک تست End-to-End بسیار موثرتر است، زیرا Functionality را از منظر کاربری بررسی می‌کند.
با این حال، اگر آزمون شما عمدتا از پایین به بالا توسط مهندسین طراحی شده باشد، احتمالا مسائل مهمی که کاربران به آن توجه می‌کنند، نادیده گرفته می‌شود.
اگر کاربر، برنامه را به شیوه‌ای که برنامه‌نویسان پیش‌بینی نمی‌کنند انجام دهد، آیا برنامه به شیوه‌ای معقول پاسخ می‌دهد؟ آیا Functionality برنامه شما به طور مناسب با طیف گسترده‌ای از وابستگی‌های ممکن، در تعامل است؟ با استفاده از آزمونگران حرفه‌ای که به شدت Functionality اصلی در زمینه یک بیزینس خاص را مورد بررسی قرار می‌دهند، می‌توان بسیاری از مشکلات را پیدا کرد که در غیر این صورت تا زمانی که نرم افزار تولید نشود و در محیط عملیاتی قرار نگیرد، متوجه آن نخواهید شد.
در نهایت اینکه وقتی توسعه‌دهندگان با همکاری آزمونگران حرفه‌ای، به آزمون نرم افزار بپردازند، درک کاملتری از ریسک‌های کسب و کار مرتبط با این Release خواهند داشت. همچنین می‌توان برای حل مسائل با ریسک بالا، قبل از اینکه کاربران مدنظر با آن مواجه شوند، با همکاری تیم توسعه و تیم تست به بررسی و حل آن می‌پردازند که این همان هدف نهایی تست است، که صد البته نیاز به همکاری بیشتر در میان نقش‌ها دارد، و نه بحث و جدل بیشتر توسعه‌دهنده و آزمونگر!
