تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
چکیده: اتوماسیون تست در طولانی مدت می تواند به جایی برسد که دیگر اهداف سازمانی را پشتیبانی نکند. ما در این مقاله بر آنیم که چهار دلیل اصلی برای این وضعیت نادرست را بررسی کنیم و متوجه شویم که معیارهای انتخاب شدۀ دقیق و یک رویکرد جامع، انطباقی و ریسک‌محور در یک راه طولانی برای پیشگیری و رفع این مشکل کمک زیادی می کند.
اتوماسیون تست به قدری برای متدهای مدرن تحویل نرم‌افزار به چنان کلیدی تبدیل شده است، که ممکن است پرسیدن این سوال تقریباً بی معنی به نظر برسد: “آیا چیزی به نام اتوماسیون تست بیش از حد وجود دارد؟” به هر حال، آیا ما به دنبال کاهش کار دستی، و همچنین قابلیت اطمینان، انعطاف‌پذیری و زمان زیاد برای عرضه محصول به بازار نیستیم؟ آیا می‌شود این مقدار همیشه زیاد باشد؟
خب، من می گویم که اتوماسیون تست با هیچ یک از موارد مذکور در بالا برابر نیست، و در واقع می تواند دقیقاً برعکس آن باشد. بنابراین چگونه می توانیم بگوییم که آیا آن را به درستی انجام داده ایم، یا اینکه قسمت زیادی یا کمی از آن را درست انجام داده ایم؟
برای اینکه ما در مورد این سوال فکر کنیم، اجازه دهید به یک مثال نگاه کنیم.
اجرای سبز ۲۰۰ ساعته
اخیرا به پروژه ای برخورد کردم، که یکی از اعضای بلندپایه آن با افتخار به من می‌گفت که تیم آنها ۱۰۰۰۰ تست اتوماتیک ایجاد کرده است که ۲۰۰ ساعت طول می کشد تا اجرا شوند و همه آنها هم پاس می شوند.
چنین چیزی قطعا نتیجه سال ها کار تخصصیست و این تیم از دستاوردهای خود بسیار راضی بوده است. دقیقا درست است، زیرا انجام آن، کار کمی نیست. این مثل ساختن مدلی از اهرام مصر در اندازه واقعی در حیاط چند ده متری یک خانه ویلاییست. با توجه به این همه تلاش و مهندسی. سوال فقط این است: “آیا چنین حرکات سنگینی لازم است؟”
در حین صحبت با وی، متوجه شدم که کار شرکت آنها در زمینه ارائه دستگاه های اینترنت اشیا(IoT) تحت شبکه است و نگرانی اصلی آنها سیستم عامل آن دستگاه ها و برخی نرم افزارهای مدیریت مبتنی بر وب بود. آنها سه بار در سال به‌روزرسانی‌ها را ارسال می‌کردند و مجموعه تست کامل را قبل از هر انتشار اجرا می‌کردند.
بنابراین برای پاسخ به اساسی‌ترین سوال، باید گفت آنها توانایی ۲۰۰ ساعت اجرا را داشتند، و این یعنی آنها فقط باید یک هفته یا بیشتر برای تست نهایی پس از چهار ماه کار توسعه سرمایه‌گذاری کنند، که پیشنهاد خوبی به نظر می‌رسد. البته چنین چیزی تنها به این دلیل امکان پذیر بود که مجموعه تست ها Pass می‌شد که اصطلاحا همیشه سبز نامیده می‌شود، و تبعا نیازی به اجرای مجدد نبود. این نتیجه درخشان در تست به این دلیل بود که تیم چهار ماه از زمان خود را با تست دستی برای یافتن تمام نواقص موجود در سیستم تحت تست و نگهداری مجموعه تست های اتوماتیک برای شناسایی هرگونه تغییر مورد نیاز و ایجاد آنها صرف می کرد.
در اصل، این تیم به جای یک سیستم، در حال تست کردن و توسعه دادن دو سیستم بود. و مزیت مجموعه تست اتوماتیک آنها عمدتاً نشان دادن چراغ سبز قبل از انتشار بود.
حالا شکی نیست که این چراغ سبز حال همه را خوب می‌کند. چیزی که باعث شد آنها احساس بدی داشته باشند (و دلیلی که ما این گفتگو را داشتیم) این بود که تیم به منظور کاهش هزینه با تعدیل نیرو مواجه شد.
حالا طنز ماجرا در اینجاست که تیم توسعه می توانست با Shelf کردن Test Suiteهای با نتیجه یکسان برای مشتری، بهره وری خود را به میزان قابل توجهی افزایش دهد. کاهش اتوماسیون تست آنها به مقدار صفر یک پیشرفت بزرگ محسوب می‌شود. و راه های بسیار آسان تری برای چراغ سبز وجود دارد.
بسیار خب. اینجا چه خطایی رخ داده است؟ چگونه می توانیم ارزیابی کنیم که آیا اتوماسیون تست ما به جای اینکه علیه ما باشد برای ما کار می کند؟ و چگونه بفهمیم که مقدار و نوع مناسبی از اتوماسیون را در اختیار گرفته ایم؟
برای اینکه مسیر درستی را انتخاب کنیم، باید برخی از دام‌های رایج را بررسی کنیم. آنها عبارتند از:
- روش ها تغییر کرده است
- کلی نگر نباشیم
- عدم درک ریسک
- عدم ارزیابی مداوم سلامتی
روش ها تغییر کرده اند
در چند سال گذشته تغییرات بازار در نحوه طراحی، توسعه، تست و تحویل سیستم های نرم افزاری تاثیر گذار بوده است. این احتمال وجود دارد که سازمان شما روش ها، فرآیند و فناوری خود را در پاسخ به این محیط به سرعت در حال توسعه تغییر دهد.
دام شماره ۱ رویکرد اتوماسیون خود را با این تغییرات تطبیق ندهید
به عنوان مثال، تحولات Agile را در نظر بگیرید. بسیاری از سازمان ها از یک SDLC (System Development Life Cycle) سنتی به یک چرخه حیات Agile تغییر می کنند تا به مشتریان خود پاسخ بهتری بدهند و در بازار پیشرو باشند. این معمولاً به معنای تغییر از یک SDLC سنتی به یک چرخه حیات Agile است.
رویکرد سنتی این است که اتوماسیون جایگزین کار دستی می شود. در مقابل رویکرد Agile این است که بازخورد سریع و کاهش ریسک را به موقع ارائه دهد. این تفاوت بسیار مهم است.
طبق معیارهای سنتی، تا زمانی یک Test Suite بتواند کار را موثرتر از کار دستی انجام دهد، اندازه و سرعت آن مهم نیست. به جای صفی از افراد که سطل‌های خاک را دست به دست میکنند، به تسمه نقاله فکر کنید که به جای پنجاه نفر فقط یک نفر را به کار می گیرد.
با این حال، با توجه به معیارهای Agile، سرعت و به موقع بودن بازخورد، بسیار مهم است. اتوماسیون باید روان کننده توسعه باشد نه نوعی دستگاه اضافی که خود به روانکاری مداوم نیاز دارد. این بدان معنی است که باید سریع و کمتر نیازمند پشتیبانی باشد.
به عبارت دیگر، اگر سعی می‌کنید Agile باشید و هنوز موفقیت را با تعداد Test Case های دستی جایگزین شده یا ساعت ها تست دستی که در آن صرفه جویی کردید، می سنجید، معیارهای درستی ندارید. بهتر است به جای نگرانی برای ساعت‌ها اجرا، نگران اجرا در چند دقیقه بدون توقف و پیوسته در زنجیره ابزار یکپارچه سازی و استقرار و ایضا نظارت بر پایداری تست در هر سطح تست باشیم.
کلی نگر نباشیم
صنعت مشاوره ترجیح میدهد Best Practiceها را ترویج دهد. چنین چیزی به ما این ایده را می دهد که روش های خاصی وجود دارند که آنقدر ایده آل هستند که با هر شرایطی مطابقت دارند. در حقیقت، چنین چیزی وجود ندارد، زمینه محصول بسیار اهمیت دارد، که حتی یک رویکرد تست کاملا دستی می‌تواند در یک سناریوی درست یک اتوماسیون تست ۵ میلیون دلاری را شکست دهد.
دام شماره ۲ نیاز نیست که بدانید سازمان شما برای رسیدن به چه چیزی به شما نیاز دارد یا به آن اهمیت میدهد
دو زمینه برای بررسی وجود دارد. اولی، که در آن اتوماسیون تست بخشی از فرآیند نگهداشت(Maintenance) است. این روند برای سازمان‌هایی است که فناوری اطلاعات در آنها یک محصول نیست بلکه کاملا یک مقوله پشتیبانیست. دوم، سازمان هایی که اتوماسیون تست در آنها بخشی از فرآیند Production است، که البته یک موضوع معمول برای شرکت‌هاییست که محصولات و خدمات نرم افزاری ارائه می دهند.
در هر دو مورد، توانمندی‌ها و قابلیت‌هایی غیر از کیفیت وجود دارد که حائز اهمیت است. اتوماسیون تست برای نگهداشت معمولا مقرون به صرفه است. اما برای تولید یا همان Production ممکن است شامل زمان رسیدن به بازار(سرعت)، انعطاف پذیری برای واکنش و نوآوری (Agility)، بهره وری و موارد دیگر نیز باشد. این توانایی ها مستقیماً بر موفقیت سازمان شما در حوزه کسب و کاری آن تأثیر می گذارد. بنابراین شما نمی توانید به اتوماسیون تست صرفاً از نظر کیفیت نگاه کنید.
در مثال بالا، Test Suite دویست ساعته کاملاً منطقی بود تا زمانی که متوجه شدیم که شرکت می‌خواهد این کار برای او ارزانتر آب بخورد. یا مثال دیگری را در نظر بگیرید که در آن شما مالک یک استارت آپ هستید و هنوز در مرحله کشف مشتریان، Business Model و فرصت های بازار خود هستید. در این صورت درگیر شدن با یک اتوماسیون سنگین صرفا چیزی را در اختیار شما قرار می دهد که باید در حین پوست اندازی و تطبیق با بازار آن را تغییر دهید(در این مورد بهتر است آن را سبک وزن نگه دارید).
درسی که در اینجا می‌آموزیم این است که باید اتوماسیون تست خود را شکل دهید تا بتواند تمام قابلیت‌های مورد نیاز را بروز دهد. اگر سرعت لازم است، آن را سریع کنید. اگر به کیفیت بی عیب و نقص نیاز است، آن را پوشش دهید. اگر مقرون به صرفه بودن مورد نیاز است، آن را به ارزان قیمت کنید. اما به یاد داشته باشید که هر قابلیت و توانمندی که به آن می دهید معمولاً به قیمت قربانی شدن قابلیت دیگریست، پس عاقلانه انتخاب کنید.
درک نکردن ریسک
با ظهور متخصصان و مهندسان اتوماسیون در تست، تیم ها اغلب با موقعیتی مواجه می شوند که در آن کاملاً قادر به حل موانع فنی تست اتوماتیک هستند، اما اینکه چه چیزی و چرا باید تست شود، را به خوبی درک نمی کنند.
دام شماره ۳ فراموش کردن این موضوع که فلسفه وجودیِ تست برای کاهش ریسک است
تست فقط در صورتی ارزش انجام دادن دارد که آنچه تست می کنیم قابلیت بروز Failure داشته باشد. و البته فقط زمانی کارآمد است که آسیب و خسارت این Failure احتمالی بیش از هزینه تلاش ما برای جلوگیری و به دام انداختن آن باشد. یک مشکل رایج برای اتوماسیون تست زمانیست که آنرا از ارزیابی و تشخیص این موضوع جدا می‌کنیم و به شکل اشتباه Test Effort را در مناطقی رشد می‌دهیم که ریسکی را به اندازه کافی کاهش نمی‌دهد.
به عنوان مثال، اخیراً در یک پروژه غیرایرانی با یک سیستم Back-end مواجه شدم که علاوه بر ده هزار Unit Test، بیست هزار تست سطح بالای رگرسیون دیگر نیز داشت که بخش قابل توجهی از آنها تست‌های Selenium GUI بودند(در این مورد هر Test Data Set منجر به بروز یک Physical Test Case شده بود، که اعداد مذبور در حقیقت مبین یک Test Data Set و یا Physical test Case هستند، نه تعداد Logical Test Caseها). اگر به مدل هرم تست(Testing Pyramid) نگاه کنیم، مشکوک خواهیم شد که درصد زیادی از تست های سطح بالاتر احتمالاً اضافی هستند و خطر قابل توجهی را کاهش نمی‌دهند. و همچنین می‌پرسیم که چرا یک سیستم Back-end که در آن ۹۹٫۹۹ درصد از تمام تعاملات از طریق APIها اتفاق می‌افتد، چندین هزار تست رابط کاربری گرافیکی دارد.
اتفاقی که در اینجا افتاد این است که این مجموعه اتوماسیون طی سال‌ها رشد کرده بود، که توسط DoD-Definition of Done هدایت می‌شد که برای تمام معیارهای پذیرش(Acceptance Criteria) در یک Ticket به پوشش تست خودکار نیاز داشت. و Storyها با محوریتِ دید کاربر نوشته شده بودند، که تست را تشویق می کرد تا هر جریانی را با در نظر گرفتن تعامل انسانی مشاهده کنید.
چیزی که اتفاق نیفتاده بود این بود که به طور معمول پرسیده شود که خطر وجود نقص در یک تغییر خاص چیست (مثلاً کدام قسمت بیشتر احتمال دارد یا ممکن است که شکست بخورد، یا کدام بخش به طور ثابت با سایر بخش‌های سیستم مرتبط و بر آنها تاثیرگذار است و در معرض خطر رگرسیون ناخواسته قرار دارد) و اینکه کدام قسمت از ریسک، قبلاً توسط Unit Testing یا سایر تست های موجود پوشش داده شده است.
برای جلوگیری از دام رشد هرس نشده و ناپایدار، باید تولید تست‌های هوشمندانه را بخشی از فرآیند اتوماسیون تست کنیم. این به معنای آگاهی از ریسک و کمی‌سازی، کسب دانش الگوهای نقص(Defect Pattern)، به کارگیری الگوهای طراحی تست مانند هرم تست و معیارهای موفقیت واضح برای تست است.
همه این موارد ما را به مرحله آخر هدایت می کند.
عدم ارزیابی مداوم سلامتی
در مهندسی نرم افزار، ما بر استانداردها و معیارهای موفقیت اشاره می کنیم تا بگوییم که چگونه کار می کنیم. با این حال، در اتوماسیون تست، اغلب با ارزیابی و سنجش هایی مواجه می‌شویم که از هر نوع هدف کسب و کاری یا تناسب با وضعیت جاری جدا هستند و اغلب به درد خودمان می‌خورند(مثلاً معیار محبوب “درصد اتوماتیک سازی”).
با فرض اینکه اتوماسیون تست باید ریسک را کاهش دهد، باید توانایی‌های کسب و کاری مورد نیاز(سرعت، کنترل هزینه، چابکی و غیره) را نیز ارائه دهد و از اهداف تحول‌آفرین شما پشتیبانی نماید.
اما سوال اینجاست چگونه بدون اندزه گیری در نیل به این اهداف، به پاسخ برسیم، و موفقیت خود را جشن بگیریم؟
دام شماره ۴ این است که کنترل پرواز موثری نداشته باشید
در مثال اول ما، یعنی اجرای سبز ۲۰۰ ساعته، موفقیت در Functional Coverage و ایضا زمان صرفه جویی شده(در صورت تست دستی) اندازه‌گیری شد. یک محاسبه ساده ممکن است نشان دهد که یک ساعت کار در اتوماسیون معادل ۲۰ ساعت کار تست دستی را پوشش می دهد. اگر چنین باشد، معنی آن بدین می‌شود اینکه Test Suite اتوماتیک ما منجر به صرفه جویی ۴۰۰۰ ساعته در انجام تست شده است، صرف نظر از این واقعیت که این زمان به دلیل اجرای سبز تقریبا هیچ Failureای را پیدا نمی‌کرد.
با توجه به فشار هزینه، آیا یک معیار سالم تر، هزینه پشتیبانی و اثربخشی در یافتن Failureها نیست؟
در مثال دوم، سیستم Back-end تست شده با سلنیوم، موفقیت در تکمیل Ticket(بر اساس نیروی کار) ارزیابی می‌شد.
با این حال، چارچوب بزرگ‌تر دارای مشکلات وابستگی و پایداری بود که با تست‌های سنگین و طولانی‌مدت در اجرا همراه بود که به تعداد قابل‌توجهی از محیط‌های ایستای تست برای تست بسیاری از تغییرات و شاخه‌ها به صورت موازای، نیاز داشت. به عبارت دیگر شکننده، کند و گران بود. اگر بخواهیم این روند را تغییر دهیم. وقتی زمان اجرا به سطح قابل قبول‌تری کاهش یابد، پایداری تست افزایش یافته، و پیرو آن هزینه نگهداشت و محیط به مرور زمان کاهش می‌یابد، و همه اینها در حالیست که متریک‌های کیفیت(مانند افت نقص) در همان سطح قبلی باقی می ماند.
