از چه ابزاری برای تست اتومات استفاده کنیم؟ آیا بهتر است خودمان فریمورک های تست را بنویسیم یا از راهکارهای موجود استفاده کنیم؟ ابزارهای متن باز بهترند یا ابزارهای تست اتومات تجاری؟ اینها سوالاتی هستند که معمولا در تیم هایی که به تازگی تصمیم به اتومات سازی گرفته اند پرسیده می شود.
به نظر من اگرچه ابزارهای اتومات سازی می توانند تاثیر قابل توجهی در رسیدن به این هدف داشته باشند اما نکته ای که معمولاً باعث شکست خوردن اتومات سازی تست ها و یا عدم استقبال از تیم اتومات ساز می شود نه خود تست ها و ابزار های انتخاب شده، بلکه دیگرعواملی است که در ادامه به دو مورد از مهم ترین آنها اشاره خواهم کرد. اما قبل از هر چیز لازم می دانم تا منظور خودم را از شکست خوردن تست اتومات مشخص کنم.
از دید من تست اتومات در صورتی که به‌طور مداوم به تضمین کیفیت سیستم در حال توسعه کمک نکند، شکست خورده و یا عملاً بی فایده است.
مداوم با این مضمون که :
- تست های اتومات به‌طور مداوم اجرا می‌شوند.
- نتایج تست های اتومات به‌طور مداوم قابل رصد شدن هستند و گزارشات مفیدی برای مشکل یابی تولید می کنند (monitoring, investigation & troubleshooting).
- تست های اتومات جدید به‌طور مداوم اضافه می شوند.
با فرض اینکه محصول شما قابلیت تست پذیری را داشته باشد و فارغ از اینکه چه سطحی از تست اتومات مد نظر است، اگر یکی از موارد ذکر شده قابل دستیابی نباشد تست اتومات از رسیدن به هدف اصلی خود که همان تضمین کیفیت در تمامی مراحل پروژه است باز مانده است.
اگر این تعریف و انتظارات (شروط تداوم) را بپذیریم، متوجه خواهیم شد که عوامل مهم دیگری به غیر از ابزار اتومات سازی تست و روش پیاده سازی آنها در موفقیت و یا شکست تست اتومات تاثیر دارند.
یکی از مهمترینِ این عوامل بستر و محیط مناسب برای اجرای مداوم تست ها است. مخصوصاً برای تست های غیریونیت، وجود یک محیط تست (staging) که مشابه محیط اجرایی (Live/Production) این امکان را به تیم می دهد تا محصولِ در حالِ توسعه و ویژگی های جدید اضافه شده را قبل از ارایه به مشتری در محیطی مشابه و با داده های مشابه تست کند. استفاده از چنین محیط هایی برای تست دارای دو مشکل عمده می باشد که عبارتند از: هزینه های ساخت چنین محیطی و همسان سازی داده های آن با محیط اجرایی (synchronization) .
اگرچه معمولا زیرساخت های محیط تست دارای سخت افزارهای سبک تر و ارزان قیمت تری نسبت به محیط اجرایی هستند اما نمی بایست این نکته فراموش شود که مادامی که تعداد تست ها و تیم های پروژه افزایش می بایند، نیاز به محیط تست با قابلیت بالا غیرقابل انکار است و طبیعتا تهیه و نگهداری چنین سخت افزارها و بستری هزینه بر است. در شرکت زالاندو به مدت یک ماه تست های اتومات بدلیل عدم توانایی پاسخگویی سرور پایگاه داده محیط تست گاها قرمز بودند. این مشکل می تواند برای بستر تست اتومات نیز صادق باشد. به‌عنوان مثال فرض کنید که ۴ تیم، هر یک دارای پنجاه تست اتومات واسط کاربری ارزشمند (UI Test) هستند که قرار است بر روی یک اجراکننده سلینوم (selenium node)، که هریک ظرفیت ۴ مرورگر وب مختلف (IE,Firefox,Chrome,Opera) دارند اجرا شوند. می شود تصور کرد که تست های هر تیم می بایست حداقل ۳۰ دقیقه در صف بمانند…. معادل یک ترمز دستی بزرگ برای continuous delivery.
مشکل دوم، همسان سازی داده های دو محیط تست و محیط اجرایی است. در صورتی که تست های شما با داده های واقعی سرو کار نداشته باشند، ممکن است خطا های (bug) پنهان زیادی را متوجه نشوید. راه حل رایج، dump و همسان سازی (synchronization) اتومات و یا دستی داده ها در بازه های تعریف شده می باشد. هر چند که گاها این بهترین راه حل نیست و ممکن است این تاخیر منجر به مشکلاتی شود. یک راه حل برای این مشکل استفاده از بیش از یک محیط اجرایی و کنترل آن است. فرض کنید محصول شما روی cloud است و بر روی سه instance اجرا می شود؛ در این حالت می توان یکی از instance ها را موقتا از دسترس خارج کرد، نسخه جدید با ویژگی جدید را deploy کرده، تست ها را با داده های محیط اجرایی اجرا و در صورتی که تست ها موفقیت آمیز بودند instance را به loadbalancer اضافه نمود. البته این راه کار محدود به cloud نبوده و می توان آن را در هر محیط مشابهی عملیاتی نمود.
دومین عامل شکست تست اتومات، ابزارها و فریمورک هایی هستند که تست اتومات را اجرا و مدیریت می کنند. از مهمترین موارد می توان به تست های واسط کاربری (Automated UI Test) اشاره نمود. مطمئنا شما هم با چنین مشکلاتی برخورد کرده اید که تست اتومات واسط کاربری شما (مثلا Selenium) در ماشین خودتان سبز، ولی وقتی بر روی محیط تست اجرا می شود قرمز است. بعد از صرف کردن ۱ ساعت متوجه می شوید که دلیل قرمز بودن تست، نه کد پیاده ساز است و نه منطق تست شما. دلیل، عدم انطباق نسخه WebDriver با نسخه جدید Firefox ماشین محیط تست است. موارد این چنینی که تست ها را قرمز می کنند (در حالی که کد شما و تست شما کاملا سالم هستند)، باعث می شوند تا نتایج تست ها غیرقابل اعتماد باشند. و این خود باعث عدم تداوم در اجرا و یا اضافه کردن تست های جدید خواهد بود. راه حل ایده آل، داشتن یک تیم متخصص است که به طور تمام وقت چنین محیط ها و ابزارهایی را به‌روز نگه داشته و نگهداری می کنند. این متخصصین معمولا فرآیند و ابزارهای Continuous Integration را نیز مدیریت کرده و کمک شایانی به ارتقاء کیفیت می کنند. هرچند که در شرکت ها و یا تیم های بزرگ، راضی نگه داشتن تمامی تیم ها می تواند سخت و بحث برانگیز باشد. شاید بهتر باشد راه حل های مناسب تست خود را dockerize کنید و اجازه دهید هر تیم تولیدی از آن به‌صورت جداگانه استفاده و مراقبت کند.
دو مورد ذکر شده تنها دلایل عدم موفقیت تست اتومات نبوده و قطعا عوامل مهم دیگری نیز در این امر دخیل هستند اما بهتر است قبل از هزینه کردن و شروع به نوشتن تست های اتومات به نکات ذکر شده فکر کرد و راه‌کار مناسبی برای آنها پیدا کرد.
منبع:
[1] https://de.linkedin.com/in/masoodg
