تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
اجازه بدهید با حقیقتی مواجه شویم: Agile حقیقت زندگیست. شاید شما یک کارگاه Full Agile ندارید و یا ممکن است Continuous Integration-CI را انجام ندهید، یا حتی تا کنون در مورد DevOps صحبت هم نکرده باشید، اما واقعیت این است که فشارهای موجود در بازار باعث می‌شود تا بسیاری از مزایا مانند کیفیت و سرعت، که جز ذات متدولوژی‌های Agile یا شبه Agile هستند، را درک کنید.
هنگامیکه شما تبدیل شدن به Agile را آغاز می‌کنید، توسعه‌دهندگان کد را با سرعت بالایی به پیش می‌برند، و اکثر تسترها تلاش می‌کنند تا این سرعت را بالا نگاه دارند. علاوه بر این، تسترها در تیم‌های Agile اغلب مسئولیت تست اتومات، Unite Testing، Regression Testing، و همینطور Load Testing و Performance Testing را به عهده دارند. در این محیط، شما باید نگران بالا نگه داشتن سرعت توسعه باشید، در حالیکه چنین اجماعی انتظارات از کیفیت را افزایش میدهد.
Performance Testing در Agile قدرتمندتر از محیط‌های توسعه استاندارد است، چون شما می‌توانید:
- از کشف دیرهنگام مشکلات Performance جلوگیری کنید: هنگامیکه Load Test و Performance Test تا انتهای چرخه توسعه، تحت فشار قرار دارند، اغلب زمان کمی(نزدیک به هیچ) برای توسعه‌دهندگان برای اعمال تغییرات وجود دارد. این موضوع میتواند منجر به این شود که تاریخ انتشار نسخه را عقب انداخته و در تحویل امکانات مورد نیاز مشتری تاخیر ایجاد شود.
- تغییرات را هنگامی اعمال کنید که آنها ارزانتر هستند: با قرار گرفتن Load Test و Performance Test در فرآیند Continuous Integration Testing، سازمان قادر به در اختیار گرفتن سریع پیامدهای Performance قبل از اینکه برای اصلاح بسیار گران بشوند، خواهد بود. این موضوع به خصوص در هنگام کشف یک مشکل Performance، چند هفته بعد از انتشار نسخه، در تیم‌های Agile صادق است، که میتواند بدین معنی باشد که این کابوس از چند نسخه قبل وجود داشته و علت اصلیِ این مشکل است، که اکنون رفع آن هزینه‌ای به مراتب بیشتر خواهد داشت.
به همین روش، ترکیب کردن Agile با Load Test میتواند مزایایی خاص ایجاد نماید. این موضوع میتواند تیم شما را با چالش‌هایی منحصر به فرد که ممکن نیست در گذشته آنها را تجربه کرده باشید، روبرو کند، از جمله:
- چرخه‌های کوتاهتر توسعه، نیازمند تست بیشتر در زمانی کم هستند: با استفاده از Agile، چرخه‌های توسعه کوتاهتر شده، و Load Test و Performance Test تا روز آخر اسپرینت یا گاهی اوقات در هر کدام از اسپرینت‌های بعدی با فشار انجام می‌شوند. این موضوع غالبا بدین نتیجه منتهی می‌شود که کد سیستم به اندازه کافی تست نشده و یا User Storyها به نسخه بعدی منتقل می‌شوند تا حداقل یک بار مورد تست قرار گیرند. راهکار Conceptual این است که تست را در چرخه توسعه سریعتر آغاز کنید، اما این موضوع به زبان ساده است، و زمانی سختیِ آن پررنگ‌تر می‌شود که بدانید تیم‌های زیادی وجود دارند که منابع و ابزار کافی برای انجام این کار ندارند.
- توسعه‌دهندگان اکنون نیازمند بازخورد هستند: توسعه‌دهندگان Agile باید حقایقی بیشتر از این موضوع که کُد آنها عامل پیامدهای Performance است بدانند: آنها باید بدانند چه زمانی کد آنها باعث آغاز مشکلات شده و چه داستانی در زمان شروع این مشکلات پیش خواهد آمد. این یک درد بزرگ برای توسعه‌دهندگانیست که مجبور به بازگشایی و اصلاح کدی باشند که هفته‌ها و ماه‌های گذشته به درستی کار می‌کرده است. این موضوع علاوه بر این، بدین معنیست که آنها نمی‌توانند وقت خود را صرف کار بر روی امکانات جدید کنند. باید مسائل Performance را در چرخه به سرعت تشخیص دهید، بنابراین شما می‌توانید به منظور صرفه‌جویی در هزینه‌ها سریعا بازخوردهای مهمی را به توسعه‌دهنده ارائه دهید.
- اتومات کردن هدایت کار از Dev به Ops میتواند یک کار ریسکی باشد: در حالیکه DevOps و استقرار مداوم همچنان بخشی از Practiceهای جوانیست که منجر به احساس ترس و نگرانی توسط تیم بهره‌برداری می‌شود. علت این نگرانی در این موضوع نهفته شده است که مبادا تغییرات جدید در کد منجر به کاهش سرعت و یا حتی لغو برنامه در زمان استقرار در محیط Production شود. اتومات کردن برخی از تست‌ها در فرآیند Continuous Integration-CI که میتواند به رفع یا کاهش این نگرانی‌ها کمک کند، بدون وجود Performance Testing کافی همچنان ریسکی واقعی در این زمینه را نوید میدهد. تیم‌های Ops تاثیر بزرگ خرابی اپلیکیشن روی Business را به خوبی می‌دانند.
غلبه بر چالش‌ها
Best Practiceهای زیر درحالیکه در غلبه بر چالش‌های Load Test در یک محیط Agile ایفای نقش می‌کنند، می‌توانند در راستای به حداکثر رساندن امتیازات و مزایا نیز به شما کمک کنند.
Performance SLAها را روی Task Board قرار دهید
هر اپلیکیشنی باید حداقل توافقنامه سطح سرویس(SLA) را به منظور برآورده کردن داشته باشد، اما تیم‌های Agile اغلب بیشتر روی افزودن امکانات و Functionality به یک اپلیکیشن متمرکز می‌شوند تا بهبود Performance در اپلیکیشن. User Storyها معمولا از جنبه Functional و بدون در نظر گرفتن مشخصات نیازمندی‌های Performance در اپلیکیشن، نوشته می‌شوند. اگر تیم قصد دارد به Performance توجه داشته باشد، این موضوع باید در قسمتی از Task Board ثبت شده باشد.
همکاری نزدیک با توسعه‌دهندگان جهت پیشبینی تغییرات
یکی از مزایای کار تسترها در یک محیط Agile این است که آنها معمولا در طول روز، بواسطه جلسات Stand up یا جلساتی مشابه، در جریان به‌روزرسانی‌های کارهای Development قرار می‌گیرند.
در راستای نائل شدن به حداکثر بهره از این سطح همکاری، تسترها باید به صورت مداوم در مورد چگونگی کد شدن داستان‌هایی(User Story) که تست خواهند شد، تفکر کرده و اطلاعات بدست آورند. آیا نیاز به تست کامل و جدید روی Load وجود دارد؟ آیا آنها باعث ایجاد خطا در Test Scriptهای فعلی خواهند شد؟ اگر شما از قبل برنامه‌ریزی کرده‌اید، آیا می‌توانید از تغییرات جزیی روی Test Scriptها جلوگیری کنید؟ اکثر اوقات، اینها تغییراتی کوچک هستند، بنابراین اگر تسترها خود را در تیم درگیر کنند، قادر خواهند بود به لحاظ عملیاتی جلو باشند.
یکپارچگی با Build Server
حتی اگر شما هنوز به طور کامل روی چرخ Agile حرکت نمی‌کنید، احتمالا یک Build Server دارید که برخی از تست‌های اتومات، Unit Testها، Smoke Testها، Regression Testها، و غیره را اجرا می‌کند. همانطور که اهداف Performance به Task Board افزوده شدند، Performance Testها هم باید در میان تست‌هایی که در هر Build انجام می‌شوند، اجرا گردند. این موضوع میتواند به سادگیِ تنظیم یک تریگِر برای آغاز تست توسط Build Server باشد، اما بسته به میزان پیچیدگیِ Integration، میتواند مشتمل بر نمایش Test Resultها در ابزار Build باشد. به صورت ایده‌آل شما فردی را می‌خواهید که Build را به منظور رویت سریع نتایج اجرا کرده و بداند کدام تغییرات وارد Build می‌شوند، آنچنانکه در صورت وجود مشکلاتی در Performance، آنها اصلاح شوند.
CI + Build شبانه + پایان اسپرینتِ Load Test
تفاوت میان Buildهای Continuous Integration، بیلدهای شبانه، و Buildهای تولید شده در پایان اسپرینت‌ها میتواند بسیار زیاد باشد. ما در مورد تفاوت میان یک تغییر منفردِ ارسال شده به سرور Version Control در مقابل تمام تغییرات ارسال شده در یک روز و نیز تمام تغییرات ارسال شده در طول یک اسپرینت، صحبت می‌کنیم. با این زمینه ذهنی، شما باید Load Test خود را با انواع Buildهایی که اجرا می‌کنید، تنظیم نمایید.
توسعه Agile، بهره‌وریِ تیم‌ها و کیفیت را افزایش میدهد.
Best Practice در اینجا این است که کا را به صورت داخلی و کوچک آغاز کنید. برای CI Buildهایی که هرگاه شخصی یک تغییر را ارسال می‌کند آغاز می‌شوند، شما می‌خواهید این تست‌ها به سرعت اجرا شده و سپس نتیجه را به توسعه‌دهنده‌ای که تغییراتش سیستم را متاثر کرده ارجاع دهید. در نظر داشته باشید که اجرای یک تست Performance کوچک(که عمومی‌ترین سناریوهای پوشش یافته با Load معمول روی اپلیکیشنِ شما را شامل شامل می‌شود)، از Load Generatorهای درونیِ خودتان استفاده می‌کند. برای Buildهای شبانه، آنرا بالا ببرید تا چیزی بیش از سناریوهای Corner Case را شامل شود و Load را آنچنانکه در زمان‌های پیک رویت می‌کنید افزایش دهید تا بتوانید هر یک از مسائل Performance که در طول CI Test از دست رفته بودند را ببینید. در پایان اسپرینت، تولید Load از Cloud را مد نظر داشته باشید، تا ببینید هنگامیکه که کاربرها از طریق Firewall به اپلیکیشن شما دسترسی پیدا می‌کنند، چه اتفاقی رخ میدهد. مطمئن شوید که هر SLAای روی لیست محدودیت‌ها، پاس شده است، آنچنانکه هر داستانی که در خلال اسپرینت تکمیل شده است، را بتوان به عنوان “انجام شده” علامت‌گذاری نمود.
جمع‌بندی
Agile Development عبارتند از: افزایش بهره‌وری تیم و کیفیت اپلیکیشن‌ها. هنگام افزودن Load Test و Performance Test به این فرآیند، دقت کنید که Planning باید اجرا شود، تا از این موضوع که Performance یک اولویت در هر Iteration است، اطمینان یابید. برای اینکه از کسب بیشترین سود در راستای ترکیب متدولوژی‌های Agile و Load Test مطمئن شوید، این توصیه‌ها را مد نظر داشته باشید:
- از اینکه Performance SLAها روی Task Board شما یا در لیست محدودیت‌ها قرار گرفته‌اند اطمینان حاصل کنید. تا بدین ترتیب کارکرد خوبِ کُدِ مرتبط با Task را قبل از اینکه Task به صورت “انجام شده” علامت‌گذاری شود، گارانتی کنید.
- همکاری با توسعه‌دهنده‌ها جهت پیشبینیِ زمانیکه تغییرات کُدِ جدید، نیازمند تغییراتی در سناریوهای Performance Test است.
- داشتن Performance Testهایی که به صورت اتوماتیک با هر Build جدیدی اجرا شده و روندهای Performance را Build به Build، پیگیری و Track می‌کنند.
بالا بردن Load و پیچیدگی برای تسترها با اندازه Build، برای پایین نگاه داشتن زمان Build:
- CI=> Performance Smoke Test
- Build شبانه<= Load Test کامل
- پایان اسپرینت<= تست Stress با تولیدکننده‌های Load از طریق Cloud
