تیستن جامعه مهندسین تست نرمافزار ایران
نوشته های مرتبط
تیمهای پرانرژی میدانند که باید تست مداوم(Continuous Testing) انجام دهند، اما اکثریت قریب به اتفاق آنها اینچنین نیستند. برای چرایی این موضوع سه دلیل عمده وجود دارد.
بیایید با یک مساله جدی روبرو شویم: شرکتها نمیخواهند یا نیازی به نرمافزار کامل و بی عیب و نقص ندارند. آنها میخواهند در اسرع وقت نرمافزار جدید و متفاوتی را در اختیار قرار دهند. برای انجام چنین چیزی، شما نیاز به یک بازخورد سریع دارید که آیا آخرین نوآوریها مطابق انتظارات کار کردهاند یا شکست خورده و در Production سوختهاند. شما همچنین باید متوجه شوید که آیا این تغییرات به نحوی Functionality اصلی را که از اهمیت فراوانی برای مشتری برخوردار است، دچار مشکل میکند یا خیر.
اینجا جاییست که تست مداوم به مساله ورود میکند.
تست مداوم، در حقیقت فرآیند اجرای تستهای خودکار به عنوان بخشی از خط تحویل نرمافزار(Software Delivery Pipeline) است تا بدین ترتیب بتوان بازخورد روی ریسکهای کسب و کاری مرتبط با یک Release Candidatenote1 نرمافزاری را در سریعترین زمان ممکن دریافت نمود.
اتوماسیون تست برای تست مداوم ضروری است، اما کافی نیست. اتوماسیون تست طراحی شده است تا مجموعهای از نقاط دادهای(Data Point) از نوع Pass/Fail را با داستانهای کاربر(User Story) یا نیازمندیهای برنامه(Application Requirement) مرتبط سازد. از سوی دیگر، تست مداوم بر ریسک کسب و کار تمرکز کرده و بینشی را در مورد اینکه آیا این نرمافزار را میتوان منتشر کرد یا خیر فراهم میسازد. فراتر از اتوماسیون تست، تست مداوم شامل شیوههایی مانند تطبیق تست با ریسک کسب و کار، استفاده از مجازیسازی سرویس و مدیریت مقدماتی دادههای تست(Test Data) برای یکپارچه سازی مداوم(Continuous Integration) و انجام تست اکتشافی(Exploratory Testing) برای افشای موانع بزرگ در ابتدای هر Iteration است. این فقط موضوعی درباره ابزارهای بیشتر یا ابزارهای متفاوت نیست. بلکه در اینجا نیاز به تحولی عمیقتر روی تمام افراد، فرآیندها و نیز فنآوری وجود دارد.
بیتردید تست مداوم ضروریست، به ویژه اکنون که ۹۷ درصد از سازمانها موضوع چابکی را پذیرفتهاند و ۷۱ درصد آنها در حال تمرین یا اتخاذ DevOps هستند(طبق اطلاعات ارائه شده از سوی Sauce Labs). تحقیقات جدید فورستر(Forrester) تایید میکند که تست مداوم یکی از عوامل کلیدی جدا کننده Agile/DevOps Leaderها از Agile/DevOps Laggardهاست. با این حال، اکثر شرکتها(Enterprise) همچنان یک فرآیند تست پایدار و بالغ در اختیار ندارند. Forrester متوجه شد که حتی سازمانهایی که به طور فعال Agile و DevOps را به کار میگیرند، میزان پذیرش آنها در تست مداوم نسبتا پایین است، و رقم آن به ۲۶% میرسد.
بسیاری از سازمانها در مورد اتوماسیون تست دارای تجربه هستند. به طور معمول، خودکارسازی برخی از تستهای UI و یکپارچهسازی(Integrating) آنها با فرآیند Continuous Integration. با انجام چنین فعالیتهایی آنها پیروزیهای کوچکی به دست میآورند، اما فرآیند آنها فراتر از این نمیرود. بهتر است بگوییم این فرآیند به مرور زمان فرو میربزد. اما چرا؟ معمولا، موانعی که باعث چنین شکستی میشوند به سه دسته تقسیم میشوند:
- زمان و منابع
- پیچیدگی
- نتایج
زمان و منابع
تیمها زمان و منابع مورد نیاز برای اتوماسیون پایدار را به شدت از دست میدهند. بله، اتخاذ برخی از تستهای اساسی UI برای اجرای خودکار، شروع خوبی است. با این حال، شما باید زمان و منابع مورد نیاز را Plan کنید تا:
- Test Scriptهای بیداوم و شکننده را از درگیر شدن تیم روی آنها حفظ کنید.
- ایجاد تست برای هر نیازمندی(Requirement) جدید یا تغییر یافته(یا محل تمرکز تلاشها و یا جاهایی که میتوان از آنها عبور کرد را تعیین کنید).
- ایجاد یک چارچوب تست(Test Framework) که از استفاده مجدد(Reuse) و تست داده محور(Data Driven Testing) پشتیبانی میکنند(هر دو برای ایجاد اتوماسیون پایدار در دراز مدت ضروری هستند).
- تستهای منفرد و چارچوب تست را با برنامه دائما در حال تحول، در هماهنگی نگه دارید.
- Test Suite را اجرا کنید، مخصوصا اگر سعی میکنید که یک UI-Heavy Test Suite بزرگ را متناوبا اجرا کنید.
- تعیین نحوه اتوناتیکسازیِ Use Caseهای پیشرفتهتر، و در حال اجرا نگه داشتن آنها به طور ثابت در یک محیط تست مداوم.
- بازبینی(Review) و تفسیر(Interpret) تست.
با Agile و DevOps، زمان برای ایجاد، نگهداشت، اجرا و تحلیل بسیار محدود است(اما بازخورد سریع ضروریست). اما چگونه میتوان تضمین کرد که مهمترین چیزها بدون تاخیر در Time To Market موجود، به اندازه کافی تحت تست قرار میگیرند؟
پیچیدگی
پیچیدگی نیز یکی دیگر از مسائل اتوماتیکسازی تراکنشها با Business-Criticality بالاست، که معمولا از چندین تکنولوژی(SAP، API، Mobile Interface، و حتی Mainframeها) گذشته، و نیاز به ستاپ و هماهنگی پیچیدهای دارد. در این رابطه شما باید اطمینان حاصل کنید که:
- منابع تست شما چگونگی اتوماتیکسازی تست را در تمام فنآوریهای مختلف دانسته و میتوانند دادهها و نتایج را از یک تکنولوژی به دیگری متصل نمایند.
- از Test Dataهای سازگار، امن و متداولی که برای ستاپ کردن یک تست واقعبینانه نیاز میشوند بهره میگیرید. همچنین باید از انجام تست بواسطه مجموعهای مجتمع از مراحل(با هر بار اجرای تست) نیز اطمینان حاصل کنید.
- به تمام سیستمهای وابسته که برای تستهای شما مورد نیاز هستند(از جمله APIها و برنامههای ثالث که ممکن است ناپایدار، د حال تکامل یا فقط در زمان محدودی قابل دسترسی باشند)، دسترسی قابل اعتماد، مداوم و مقرون به صرفه داشته باشید.
علاوه بر این، شما نیاز به یک روش سیستماتیک برای رفع نواقص بحرانی دراید که فقط میتوان با یک فرد که اپلیکیشن را از منظر کاربر نهایی بررسی میکند بدان دست یافت. اتوماسیون با سرعا بالا و به صورت مکرر بررسی میکند که آیا اقدامات معین به نتایج مورد انتظار(Expected Result) منتهی میشود یا خیر، اما در نظر داشته باشید که نمیتواند مسائل Usability(کاربردپذیری) پیچیده که به طور قابل توجهی بر تجربه کاربر(User Experience) تاثیر میگذارند، را کشف کند.
بدون بازخورد قابل اعتماد و سریع در مورد اینکه چگونه تغییرات برنامه بر تجربه کاربر اصلی تأثیر میگذارد، چگونه خواهید فهمید که آیا یک Release به کسب و کار کمک میکند یا به آن آسیب میرساند؟
نتایج
شایعترین شکایت با نتایج تست، وجود تعداد زیاد False Positiveهاست است که باید مشخص شده و مورد بازبینی قرار گیرد. هنگامی که شما با اتوماسیون تست شروع میکنید، ممکن است مقابله با False Positiveها میسر باشد. با این حال، همانطور که Test Suite شما رشد میکند، و فرکانس تست شما افزایش مییابد، رسیدگی به False Positiveها به سرعت به یک کار غیرقابل تحمل تبدیل میشود. در نهایت، بسیاری از تیمها شروع به نادیده گرفتن False Positiveها میکنند(که اعتماد به نتایج تست و ابتکار تست مداوم را کاهش میدهند) و یا به طور کامل آنرا با اتوماسیون تست تنها میگذارند.
هنگامی که ابتکارت تحویل مداوم و DevOps به اجرا در میآیند، یک مسئله حیاتی دیگر با Resultها ظاهر میشود: آنها یک بینش Risk-Based که برای تصمیمگیری سریع نیاز است ارائه نمیدهند. اگر تا به حال نتایج تست را مشاهده کرده باشید، احتمالا چیزی شبیه به این را دیدهاید:
- ۴۲،۲۷۸ تست Pass شد.
- ۱۰،۰۸۶ تست Fail شد.
- ۹۱۰ تست انجام نشد.
این آمار و ارقام واقعا به شما چه میگوید؟ شما میتوانید ببینید که:
- در مجموع ۵۳،۲۷۴ عدد Test Case وجود دارد.
- تقریبا ۸۰ درصد از این تستها Pass شدهاند.
- بیش از ۱۹ درصد از آنها Fail شدهاند.
- حدود ۱ درصد هم اجرا نشده است.
اما آیا میخواهید تصمیمگیری برای Release را بر اساس این نتایج انجام دهید؟ شاید این Test Failureها مربوط به برخی از Functionalityهای بیاهمیت باشند. شاید آنها مهمترین Functionalityها باشند: مثلا کارکردهای مربوط موتور سیستم. حتی ممکن است مهمترین Functionality شما به طور کامل تحت تست قرار نگرفته باشد. تلاش برای ردیابی این اطلاعات نیاز به یک حجم سنگین کار تحقیقی دستی داشته باشد که پاسخهای متداول و اغلب نادرست ارائه میدهد.
در عصر Agile و DevOps، تصمیمگیری در مورد Release باید به سرعت و حتی به طور خودکار و بلافاصله انجام شود. نتایج تستهایی که بر روی تعداد Test Case تمرکز میکنند، شما را با یک نقطه کور بسیار بزرگ تنها میگذارد که هنگامی که شما در Agile یا DevOps به سرعت به پیش میروید، میتواند به یک نقطه کاملا بحرانی و فوق العاده خطرناک تبدیل شود.
اگر نتایج شما نشان نمیدهد که چه مقدار از Functionalityهای مهم کسب و کار شما تحت تست قرار گرفته و کار میکند، نمیتوانید به آنها برای انجام انتشار اتوماتیک(Automated Release) تکیه کنید. در اینجا به بازبینی و ارزیابی دستی نیاز دارید و این امر به شکل ناگزیر به منجر به تأخیر در هر یک از تحویلها میشود.
پاورقی
