تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: بخشی از مسیر DevOps نیاز به پذیرش متدولوژی‌های Agile(چابک) دارد. زمانیکه برای تست از مدل آبشاری سنتی(Traditional Waterfall Model که دارای چند چرخه طولانی Release در هر سال)، به مدل چابک(با تغییراتی که هر دو هفته رخ می‌دهند) سوییچ می‌کنید، چه معنایی دارد؟ در اینجا پنج عامل کلیدی و ضروری برای دستیابی به تست نرم‌افزار چابک در DevOps وجود دارد.
در سال‌های اخیر، بسیاری از سازمان‌ها توسط DevOps تحت تاثیر قرار گرفته‌اند.
با تغییر ذهنیات افراد، اتومات‌سازی فرآیندهای استقرار(Deployment) و Build بوسیله پیاده‌سازی ابزارها و فرآیندهای مناسب، افزایش تست اتوماتیک، شکست دیوارهای میان Development و Operation، و نیز اتوماتیک‌سازی Monitoring و Reporting، برخی DevOps را به صورت End-to-End اجرا کرده، و آنرا در همه شئونات دخیل کرده‌اند. با این حال، باید در نظر داشت که اکثر سازمان‌ها تنها در مرحله آغاز مهاجرت خود به DevOps هستند و یا در میانه راه فرآیند تحول قرار گرفته‌اند.
بخشی از مسیر DevOps نیاز به پذیرش متدولوژی‌های Agile(چابک) دارد. زمانیکه برای تست از مدل آبشاری سنتی(Traditional Waterfall Model که دارای چند چرخه طولانی Release در هر سال)، به مدل چابک(با تغییراتی که هر دو هفته رخ می‌دهند) سوییچ می‌کنید، چه معنایی دارد؟
در بیشتر سازمان‌ها، تقابلی میان دو دنیای سیستم‌های قدیمی(Legacy System) با سیستم‌های مدرن را مشاهده می‌کنید. با این حال، این دو دنیا برای پیشبرد کارها باید با هم همکاری داشته باشند. در گذشته ما باید تست‌های رگرسیون سیستم‌های Legacy را طی چندین هفته انجام می‌دادیم(هم به صورت دستی و هم به صورت خودکار) اما در هر حال حاضر دیگر به آن اندازه برای انجام تست وقت نداریم.
تغییر شکل از مدل آبشار سنتی به یک مدل چابک، نیازمند رویکردهای جدیدی در تست است.
بهینه‌سازی اتوماسیون تست یک روش عالی برای پر کردن این شکاف است. با تست‌های اتوماتیکِ در محل، می‌توانید منابع کم تست را برای فعالیتی‌های ارزشمند تست تخصیص داده، زمان صرف شده در اجرای تست را کاهش داده، و تعداد سیکل‌های ممکن تست در یک بازه زمانی کوتاهتر را افزایش دهید. تأثیر این تغییرات می‌تواند بلافاصله با کاهش تلاشِ صورت گرفته، صرفه‌جویی در هزینه و بهبود Time-to-Market ملموس گردد.
یکی از سازمان‌هایی که من در آنجا مشغول به کار هستم، در چند سال اخیر حجم زیادی از اتوماسیون را اجرا کرده و اشتباهات زیادی در این فرآیند انجام داده است! اما در کنار این اشتباهات درس‌های فراوانی گرفته‌ایم، و اکنون می‌توانیم با دنیایی که هر لحظه بیشتر و بیشتر به سمت Agility پیش می‌رود، سازگار شویم. اتوماسیون تنها در صورتی کار می‌کند که شما تست‌های قوی داشته باشید که بدون نظارت به صورت کامل(از ابتدا تا انتها) اجرا می‌شوند.
در اینجا پنج عامل کلیدی برای دستیابی به تست نرم‌افزار Agile در DevOps ارائه شده است:
۱- مدیریت داده‌های تست
داشتن داده‌های درست تست اولین گام مهم در اتوماسیون است. اگر Test Data شما پایدار نباشد، هرگز موفق نخواهید شد. طبق آمار موجود در صنعت نرم‌افزاری، نزدیک به ۳۰ درصد از نارسایی(Failureهای) اجرای تست به علت Test Data نادرست است.
برای هر یک از Test Caseهای خود، باید تعریف کنید که چه Dataای برای اجرای تست مورد نیاز است. این موضوع را منعطف نگه دارید. در این روش ویژگی‌های Test Data را به جای خود آن تشریح نمایید. به عنوان مثال، “محمد از ایران” خودش یک Test Data است، که به معنی یک “یک شخص مذکر با ملیت ایرانی” است.
پس از مشخص شدن ویژگی‌های مورد نظر، بهترین مکان برای پیدا کردن Test data کجاست؟ اگر بخواهید از GDPR(مقررات عمومی حفاظت از داده اتحادیه اروپا) تبعیت کنید، باید داده‌ها را به صورت مصنوعی بسازید. در صورتیکه نیاز به Historical Data نداشته باشید(هر چند که دشوار است، اما می‌توانید اطلاعات تاریخچه را هم بسازید)، این یک گزینه مناسب است، اما به این شرط که تنظیمات داده‌ای(Data Setup) شما خیلی پیچیده نبوده و یا در میان سیستم‌های مختلف توزیع نشده باشد.
اگر شما نیاز به اطلاعات پیچیده‌تری دارید، ممکن است مجبور به استفاده از داده‌های موجودِ مشتریان شوید که البته باید فرآیند ناشناس‌سازی(در صورت نیاز به پیروی از GDPR) روی آنها انجام شود. در این مورد برای پیدا کردن داده‌ها در پایگاه داده باید بر اساس ترکیبات دقیق روی Attributeها، از Query استفاده نمایید.
معمولا، ترکیبی از هر دو رویکرد به بهترین شکل کار می‌کند. ایجاد Test Data مصنوعی و اجرای Query روی پایگاه داده برای دستیابی به اطلاعات مناسب به عنوان Test Data، می‌تواند و باید خودکار شود.
مدیریت داده‌های مناسب برای تست، نه تنها برای اتوماسیون ضروری است، بلکه برای تست دستی نیز لازم است. طبق برخی از نظرسنجی‌ها و آمارها، تست‌های دستی ۵۰ تا ۷۵ درصد تلاش خود را برای یافتن و Test Data مناسب اختصاص می‌دهند. برای حصول ROI، داده تست باید مستقل از افرادی باشد که آنرا برای شما نگهداری می‌کنند.
۲- Steering(کنترل) منعطف
هنگام طراحی Test Caseهای خود، به جای کپی کردن چندباره یک Test Case به منظور تحقق معیارهای معین، از پارمترهای کنترلی(Steering Parameter) استفاده نمایید.
بیایید فرض کنیم شما باید ابتدا در محیط توسعه و سپس در یک محیط شبهِ بهره‌برداری Test Caseهای خود را اجرا کنید. علاوه بر این شما نیاز دارید که با دو نقش X و Y به سیستم Login نمایید. اینکه چهار بار برای هر ترکیب از محیط و نقش، Test Case را کپی کنید، راهکار اولیه تست برای شماست؛ حال اینکه شما می‌توانید این پارامترها را به عنوان عنصر کنترلی(Steering)، آن هم فقط یک بار در این Test Case وارد نمایید. این باعث می‌شود که مجموع نگهداشت این Test Case به میزان ۷۵ درصد کاهش یابد.
هر زمان که ممکن باشد بهتر است که با Step Blockهای Reusable در تست کار کنید. مراحل تست(Test Step) تکراری را می‌توان یک بار تعریف کرده و در Test Caseهای مختلف مورد استفاده قرار داد. برای مثال، با یک لاگین برای یک اپلیکیشن یا سازمان از یک مشتری جدید، که بارها و بارها برای Test Caseهای بعدی استفاده می‌شود، نیازی به تکرار وجود ندارد. این کار موجب صرفه جویی در زمان ارزشمند و تلاش(Effort) می‌شود.
یک Test Case ناموفق اغلب منجر به خاتمه اجرای خودکار می‌شود؛ بنابراین، Test Case بعدی نمی‌تواند اجرا شود، چرا که برنامه در حالت “undefined”(تعریف نشده) باقی مانده است. تصور کنید که اجرای اتوماتیک را در عصر آغاز می‌کنید تا Test Caseها را شبانه اجرا نماید. صبح روز بعد، خواهید دید که Test Caseهای شما اجرا نشده‌اند، چرا که اولین Test Case شما Fail شده و جلوی اجرای باقی موارد را گرفته است.
می‌توان جلوی این اتفاق را با تعریف سناریوهای Recovery برای هر یک از Test Caseها سد کرده و یا آنها را به طور کامل از یکدیگر مستقل نمود. در حقیقت باید دستورالعملی برای Test Case در شرایط Failure تدوین نمایید.
۳- مجازی‌سازی سرویس و محیط تست
بعد از از دست دادن Test Data، موضوع محیط تست ناقص، دسترس‌ناپذیر، و ناپایدار یکی از زمانگیرترین موضوعات در تست است.
این سناریو را در نظر بگیرید: تست‌های شما Plan شده‌اند، تسترها زمان خود را برای یک روز خاص سازماندهی کرده و آنرا برای انجام کارهای دیگر مسدود کرده‌اند، اما زمانیکه می‌خواهید اپلیکیشن را تست کنید، اپلیکیشن در دسترس نیست. حتی ممکن است اپلیکیشن در دسترس باشد، اما اپلیکیشن دیگری که بدان وابسته هستیم، و یا سرویس مستقلی که Data مورد نیاز شما را ارائه می‌دهد، در دسترس نباشد.
هر چه افراد و اپلییکشن بیشتر درگیر می‌شوند، محیط تست هم پیچیده‌تر می‌شود و ریسک عدم دسترسی افزایش می‌یابد.
با این وجود باید قبول کرد که در دنیای مدرن و Agile امروز، دوره انتظار برای تست تا زمانی که تمام کامپوننت‌ها توسعه یافته و تمام سیستم‌ها و سرویس‌ها تکمیل شوند، به سر آمده است. در عوض، شما نیاز دارید کامپوننت‌ها یا سیستم‌هایی که هنوز متصل نبوده و یا توسعه نیافته‌اند را شبیه‌سازی کنید. با این اوصاف تست می‌تواند زودتر آغاز شود. این کار با مجازی‌سازی سرویس امکان پذیر است. شما نیاز دارید پارامترهایی که یک سرویس منتظر آنهاست و همچنین داده‌هایی که Return می‌کند، را بدانید.
یک ابزار Service Virtualization Testing(تست مجازی‌سازی سرویس) خوب می‌تواند به شرایط در حال تغییر واکنش نشان داده و در صورتیکه سرویس واقعی در دسترس باشد از سرویس مجازی به سرویس واقعی سوییچ کند. علاوه بر این یک ابزار خوب مجازی‌سازی سرویس باید بتواند در صورت عدم دسترسی به سرویس واقعی به سرویس مجازی سوییچ نماید.
به یاد داشته باشید که نمی‌توانید تمام تست‌های خود را بر اساس سرویس‌های مجازی انجام دهید؛ در یک نقطه خاص، شما باید تست واقعی، و End-to-End را آغاز کنید. اما اگر تست را خیلی سریعتر آغاز کنید، بسیاری از نواقص(Defect) مهم قبل از تست‌های End-to-End بروز خواهند کرد. این کار باعث صرفه‌جویی در مقدار قابل توجهی از هزینه های دوباره‌کاری(Rework) و دیباگ کردن می‌شود.
علاوه بر این، یک محیط تست مدیریت شده به بهبود ثبات(Stability) کمک می‌کند. چنین چیزی را می‌توان با اقدامات سازمانی(مثلا یک تیم مدیریت محیط تست متمرکز که محیط تست را هماهنگ نموده و کنترل می‌کند) و یا تعریف “فرآیندهای ویژه مدیریت محیط تست” حاصل کرد.
بسیاری از سازمان‌ها نمی‌خواهند فرآیندهای زیادی را در کار خود بگنجانند، زیرا معتقدند Agile Development نیازی به فرآیند ندارد. با این حال، فرآیندهای خاص(یا به جای آن، قوانین تعامل) برای بهبود ثبات محیط تست ضروری هستند.
این فرآیندها نیاز به صرف زمان زیاد ندارند، حداقل برای مراحل پیشرفته‌تر تست(Test Stage)، مانند تست‌های End-to-End یا Business Verificationها:
- اگر چندین اپلیکیشن و سرویس از تیم‌های مختلف درگیر باشند، اسلات‌های زمانی(Time Slot) را وقتی تعریف کنید که باید استقرار(Deployment) انجام شود. زمانیکه همه کارشان را انجام دادند، تسترها این موضوع را متوجه خواهند شد و می‌توانند تست را شروع کنند.
- اقداماتی مانند ری‌استارت کردن اپلیکیشن‌ها و سرویس‌ها، رفرش‌های پایگاه داده یا سایر اختلالات باید در خلال Time Slotهایی که هیچ تستری آنرا تست نمی‌کند، Plan شوند.
- اگر تسترها زمانی که می‌خواهند تست را Plan کنند(مثلا بر اساس تقویم)، با دیگران مراوده نمایند(چه برای Test Caseهای اتوماتیک و چه برای Test Caseهای دستی)، تیم مدیریت محیط تست بهتر می‌تواند با دیگران هماهنگ شده و ارتباط برقرار کند.
- تغییرات ریزِ جدید با تسترها در میان گذاشته شوند، چرا که بهتر است آنها بتوانند Test Caseهای خود را بر این اساس تطبیق دهند.
۴- کاربران تستی
هنگام اتومات کردن Test Caseها، بهترین کار این است که هرگز با اعتبار و اکانت شخصی خود وارد اتوماسیون تست نشوید. زیرا اگر شما بیمار شوید یا به هر دلیل نتوانید در محل کار حاضر شوید، همکار شما قادر نخواهد بود Test Caseهایی را که شما طراحی کرده‌اید اجرا نماید، چرا که برای این کار باید اکانت شما را در اختیار داشته باشد. همچنین، استفاده از اکانت شخصی دیگران در بسیاری از شرکت‌ها نقض امنیت محسوب می‌شود.
رویکرد صحیح این است که کاربران تستی ویژه‌ای را که بازیگر نقش‌های مورد نیاز شما برای تست کردن اپلیکیشن هستند، ستاپ نمایید. مزیت کاربران تستی این است که اگر کسی از شرکت خارج شود یا نقش خود را تغییر دهد، آنها همچنان باقی خواهند ماند. فقط از رعایت مسائل امنیتی اطمینان حاصل نمایید، مانند: Single Sign-on، Remote Desktop Connection، فایروال‌ها، دسترسی مجرمانه یا سایر موانع احتمالی.
۵- تست مداوم(Continuous Testing) و یکپارچه‌سازی مداوم(Continuous Integration)
Test Caseهای اتوماتیک خود را در چرخه توسعه نرم‌افزار مداوم(Continuous Software Development Cycle) ادغام(Integrate) کنید. اگر Test Caseها پایدار هستند، پس چرا هر شب و یا پس از هر Build آنها را اجرا نمی‌کنند، تا به سرعت نتایج مربوط به وضعیت نرم‌افزار را دریافت کنند؟ برای این منظور اطمینان حاصل کنید که تست‌های طویل‌‌الاجرا(تست‌هایی که اجرای آنها طول می‌کشد) در Test Automationهایی ادغام می‌شوند که در خلال Buildهای شبانه اجرا می‌شوند، چرا که این تنها زمانیست که شما وقت کافی برای پایان اجرای تست، قبل از آغاز Build بعدی دارید.
برخی از ابزارهای اتوماسیون با ابزارهای توسعه استاندارد که قابلیت یکپارچه‌سازی مداوم(Continuous Integration) را فراهم می‌کنند، ادغام می‌شوند. توصیه می‌کنم برای کاهش زمان تست و استفاده سریع از نتایج، از اجرای توزیع شده(Distributed Execution) برای اجرای Test Caseهای خودکار در چند دستگاه به صورت موازی، استفاده کنید.
