تست چابک
فرآیندهای پیش رو در روش تست سنتی
تهیه مستندات نیازمندیها از طریق ارتباط با کاربر نهایی و مرور آنها.
معمولا مستندات نیازمندیها به عنوان پایه و اساس کار در نظر گرفته میشوند.
به منظور ایجاد الزامات تست (test conditions) و موارد تست (test-cases)، تجزیه و تحلیل این نیازمندیها لازم است.
نوشتن روالهای تست.
سپس منتظر یک نسخه از نرمافزار میمانیم تا در محیط تست مستقر شود.
در این مرحله اجرای تستها شروع میشود.
پس از رفع خطاها و یا افزودن قابلیتهای جدید، مجددا از قسمتهایی که اصلاح شدند یا تغییر کردند تست میگیریم.
پس از رسیدن به ریسک قابل قبول و معیارهای تست در حد کافی، نرم افزار را روانه بازار میکنیم.
در شکل زیر روش سنتی (آبشاری) توسعه نرمافزار نشان داده شده است:
چالشهای روش تست سنتی
فاصله زمانی قابل توجه بین زمان توسعه نرمافزار و زمان اخذ بازخورد
در فرآیند تست، تاخیر در پیداکردن اشکالات نرم افزار میتواند پیامدهای زیادی داشته باشد.
تغییر کردن نیازمندیها بر روی موارد تستی که توسعه یافتهاند، تاثیر میگذارد.
گروههای مختلف ممکن است انتظارات متفاوتی از محصول نهایی داشته باشند.
هنگامی که تست و تضمین کیفیت نرمافزار آخرین فعالیت قبل از تعیین تاریخ انتشار نرم افزار باشد، تضمین کیفیت ناقص انجام میشود و بسیاری از فعالیتهای مربوط به تست و تضمین کیفیت نادیده گرفته میشود.
ماتریس تست چابک
اصول چهار گانهی تست چابک، مدلی برای آزمون در دنیای چابک فراهم میکند. سمت چپ تصویر فوق راهنمایی برای توسعه دهندگان و تستهای اولیه است. سمت راست تصویر فوق درباره ارزیابی محصول از دیدگاه کاربری میباشد.
قواعد تست چابک
تست فقط در یک فاز انجام نمیشود
تست، کل پروژه را پیش میبرد
همه افراد درگیر در پروژه، تست انجام میدهند
کوتاه کردن زمان پاسخ گویی به بازخوردها
کد تمیز
کاستن از حجم مستندات تست
مبتنی بر تست بودن
- انجام پیوسته تست توسط تیم چابک، باعث افزایش اطمینان و پیشرفت بهتر کار است.
- در روش توسعه سنتی سیستمها، تست دریچه کیفیت محسوب میشود اما در روش توسعه چابک، بازخوردهایی به صورت مداوم ارائه میشود که باعث برآورده شدن نیازهای کاربر در محصول نهایی میگردد.
- در روش توسعه سنتی سیستمها، تنها تیم تست است که تست را انجام میدهد در حالیکه در روش چابک، توسعهدهندگان و تحلیل گران کسب و کار نیز برنامه کاربردی را تست میکنند.
- در روش توسعه سنتی سیستمها، تنها در طی تست پذیرش تیم تجاری میتواند از وضعیت توسعه محصول آگاه گردد در حالی که در روش چابک، تیم تجاری در هر یک از تکرارها دخیل است و بازخوردهای پیوسته آنها زمان پاسخگویی به بازخوردها را کوتاه میکند و همچنین هزینه رفع خطاها نیز کاسته میشود.
- در روش توسعه چابک، خطاهای مطرح شده در هر تکرار رفع میشوند بنابراین کد واضح و تمیز نگه داشته میشود.
- به جای مستندات طولانی، تسترهای چابک از چک لیست قابل استفاده مجدد بهره میبرند و بیشتر به تست توجه دارند تا به جزئیات غیرضروری.
- در روش توسعه سنتی، تست کردن بعد از پیاده سازی انجام میشود در حالی که در تست چابک، تست کردن در حین پیاده سازی انجام میگردد.
مزایای تست چابک
ارائه بازخوردهای دائمی به توسعه دهندگان، این اجازه را به تسترها میدهد که در بهترین زمان بهترین سوال را بپرسند.
تشخیص سریع وابستگیها ، مسائل فنی و چالشهای تست و بن بستها
تغییر به عنوان یک بخش واقعی از توسعه نرم افزار پذیرفته میشود
همکاری تیمی سبب هم افزایی و رسیدن به هدف مشترک میشود.
کیفیت از ابتدا لحاظ میشود چرا که معیارهای نهایی پذیرش از شروع کار در نظر گرفته میشوند.
نیازمندیهای تست به صورت تیمی مورد بحث قرار میگیرد که این امر منجر به شناسایی بهتر نیازمندیها از دیدگاه فنی و تجاری شده و از سوء برداشت جلوگیری میکند.
فرآیند چابک اغلب نیاز به معیارهای ورود و خروج برای سناریوهای تست دارد. تست چابک اطمینان میدهد که هر نیازمندی به خوبی تعریف شده و قابل اندازه گیری است که این امر به متخصصین تضمین کیفیت اجازه میدهد تشخیص دهند که آیا هر نیازمندی کامل شده است یا خیر.
تیم تضمین کیفیت در مرحله نوشتن تصویر کلی نیازمندیها مشارکت میکند تا بدین وسیله اطمینان دهد که تخمین فعالیتهای تست نادیده گرفته نشده است.
در تست چابک، از تستهای خودکار سازی شده برای پیاده سازی تست رگرسیون استفاده میگردد.
مسئولیت کیفیت با کل تیم است و نه صرفا با تیم تست. در واقع کل تیم چابک، برروی استراتژی تست، موارد تست و اولویتبندی خطاها توافق میکند.
روش تست چابک
روش تست چابک سه ستون دارد :
1. مجموعه نگرشهای ذهنی
همه مسئول تضمین کیفیت هستند.
پذیرش نگرش تست چابک
همکاری با مشتریان
2.مجموعه مهارت ها
خودکارسازی
نوشتن نیازمندیهای تست که به برنامه نویسان کمک میکند
مهارت انجام دادن انواع تست ها
ارتباطات اثر بخش و همکاری تیمی
3.مجموعه ابزار
ابزارهای توسعه و ساخت
کنترل سورس
محیط یکپارچه توسعه نرمافزار
ابزارهای ساخت ( Ant & Maven)
یکپارچه سازی پیوسته (CrusieControl and Hudson)
ابزارهای پوشش کد (Cobetura)
ابزارهای نیازمندیها
ویکی
چک لیست
نقشه ذهنی (mind map)
شبیه سازی با استفاده از mock object ها
نمودار جریان (flow diagram)
ابزارهای خودکارسازی تست
ابزارهای سطح تست واحد (Junit برای جاوا و Nunit برای .NET)
توسعه مبتنی بر رفتار یا BDD (easyb و JBehave برای جاوا و NSpec و NBehave برای .NET)
ابزارهای تست عملکردی در لایه API (Fit و FintNesse)
ابزار خودکار سازی واسط کاربری گرافیکی (QTP)
ابزارهایی برای بهبود ارتباطات بین تیم های توزیع شده
فرآیندهای پیش رو در تست چابک
مشتریان نیازمندیهای تجاری را آماده نموده و تحلیلگر کسب و کار یا تیم مهندسی آن را بازبینی میکند. در حالت ایده آل تیم تست/تضمین کیفیت در بازبینی این نیازمندیها دخیل هستند تا بتوانند برای مراحل بعدی برنامهریزی کنند.
تیم مهندسی در طی مراحل طراحی و پیاده سازی، سناریو های مورد استفاده کاربر (User story) را مینویسند. سپس مشتری به طور منظم آنها را بازبینی میکند و بر طبق آن مشخصات نیازمندی را تغییر میدهد. تیم تست تا زمانی که سند یکپارچهای آماده شود این چرخه را به صورت منظم دنبال میکند. دلیل این کار آن است که مشتری، تیم مهندسی و تیم تست مطمئن باشند همگی در یک سطح درک هستند و تست همه نیازمندیهای مشتری را پوشش میدهد.
هنگامی که تیم مهندسی پیاده سازی را شروع میکند، تیم تست نیز برنامهریزی تست، استراتژیهای تست و آماده سازی موارد تست را شروع میکند. برای اطمینان یافتن از کامل بودن پوشش تست و پرهیز کردن از تهیه موارد تست غیر ضروری، تمام فعالیتهای تست مستند شده و جهت بازبینی تحویل مشتری و تیم مهندسی داده میشود.
هنگامی که توسعهدهنده کد را پیادهسازی میکند، تیم تست تشخص میدهد که آیا برنامه کاربردی با استفاده از این کدهای پیادهسازی شده امکان ساخت سریع جهت تست را دارد. این کار برای تشخیص اشکالات برنامه در مراحل اولیه است طوریکه توسعهدهنده بتواند طبق اولویت بندی در گامهای بعدی آنها را رفع نماید. این چرخه تا زمان اتمام پیادهسازی کد ادامه دارد. به محض اینکه چرخه تست شروع شود، تیم تست میتواند عمدتا بر روی آیتمهای مهم تست همچون تست یکپارچه سازی، تست سهولت کاربری و تست سیستم متمرکز شود.
چالشهای تست چابک
ناکافی بودن پوشش تست
شکسته شدن تصادفی کد (broken code) به دلیل ساختهای مکرر
مساله یافتن خطاهای برنامه در مراحل اولیه زمانی که رفع آنها راحت تر و ارزان تر است
تست ناکافی برای واسط برنامهنویسی کاربردی(API) منتشر شده
اطمینان از این که انتشار جدید، گلوگاههای کارایی ایجاد نکند
راهکارهای مواجهه با چالشهای تست چابک
اتصال تستها به سناریو های مورد استفاده کاربر (user story) جهت کسب اطلاع از میزان پوشش تست به ازای هر کدام از آنها
یکپارچه سازی با ابزار سورس-کنترل جهت پیدا کردن کد تغییر داده شده غیر مورد انتظار
تحلیل متریکهای خاص برای تشخیص قابلیت ردیابی (traceability) و پوشش تست از دست رفته
اجرای تستهای خودکار رگرسیون در هر ساخت جهت تشخیص کدهای شکسته (broken code)
تحلیل متریکهای خاص برای تشخیص تستهای رگرسیون انجام شده و کدهای شکسته شده
بازبینی سورس کد و فراوردههای تست جهت پیدا کردن خطاهای مراحل اولیه
استفاده از ابزارهای تحلیل ایستا (static analysis) برای پیدا کردن خطاهای مراحل اولیه
اجرای تست های خودکارسازی شدهی API برای اطمینان از کارکرد صحیح API
اجرای تست بار بر روی API ها برای اطمینان از زمان پاسخ مناسب آنها
تحلیل متریکهای خاص برای تشخیص پوشش تست API و پاسخگو بودن آن
اجرای تست بار برنامه کاربردی جهت اطمینان از اینکه انتشار اخیر باعث ایجاد عوارض جانبی بر روی سیستم نشده باشد
پیاده سازی مانیتورینگ محصول برای شناسایی رفتار اجرایی برنامه کاربردی در محیط عملیاتی
تحلیل متریکهای خاص برای تشخیص گلوگاه ها در کارایی برنامه کاربردی و API ها
بهترین تجارب تست چابک
- تست در داخل تکرارهای پروژه (sprint ها)
- خودکارسازی تست
- ارسال محافظه کارانه کد و بازگشت به عقب سریع
- توسعه مبتنی بر تست (TDD)
- نوشتن تستهای شکست خورده، پاس کردن تست، پیرایش (ساخت مجدد کد)
- توسعه عملیات تست
توسعه مبتنی بر تست (TDD)
ابزارهای تست چابک
شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه تست چابک ارائه می دهد:
ارائه مشاوره در حوزه تست چابک
تهیه و آموزش ابزارهای تست چابک در حوزه تستهای عملکردی، کارایی و امنیت
راه اندازی متد توسعه مبتنی بر تست (Test-Driven Development)
ارائه راهکارهای چابک برای بهبود کیفیت نرم افزار در حال تولید
نویسنده : شرکت مهندس پیشگان آزمون افزار یاس
مراجع
[1]- Lisa Crispin, Janet Gregory, “Agile Testing”, A Practical Guide for Testers and Agile Teams, 2009
[2]- THE CASE FOR AGILE TESTING, cognizant 20-20 insights, June 2014
[3]- Five Challenges for Agile Testing Teams Solutions to Improve Agile Testing Results, 2012 by SmartBear