چگونه در عمل تست اتوماتیک را پیاده سازی کنیم؟

زمانیکه در مورد لزوم تست های اتوماتیک سخن می گوییم همه ما یکصدا موافق وجود آنها هستیم اما زمانی که پروژه شروع می شود زمان نوشتن تست های اتوماتیک هیچ وقت فرا نمی رسد، یا زمان کمی برای این قضیه صرف می شود اما به بهانه های مختلف دوباره کناره گذاشته می شود.

در این نوشته بیشتر قصد من آموزش نحوه  تست نوشتن نیست، بلکه بررسی روشی برای عملیاتی کردن فرآیند تست نویسی توسط برنامه نویس ها است.

اولین دلیل نوشته نشدن تست، افسانه Coverage است

خیلی از برنامه نویس ها یا مدیران دوست دارند Code Coverage یا Test Coverage عدد بالایی نشان دهد. Code coverage معیاری است که نشان می دهد چه میزان از کدهای نوشته شده زیر چتر تست قرار گرفته اند و به نوعی این تست ها تضمین کننده عملکرد کدهای زیر چتر خود هستند.

برای مثال قانونی در تیم تصویب می شود که Coverage باید بالای 90% باشد . برنامه نویس ها خیلی خوب بلد هستند که چگونه این عدد را بالا ببرند. روش AssertionFreeTesting یکی از این روش ها است، تست نوشته شده است و سعی می کند کدی را نیز تست کند، ولی واقعا چیزی تست نمی شود.

پس اگر هدف از نوشتن تست بالا بردن Coverage باشد، شما به اعداد خوبی دست خواهید یافت ولی چیزی تست نخواهد شد و پس از مدتی به خود خواهید گفت خوب این تست ها که کاری برای ما نمی کنند، پس چرا هستند؟

هدف از تست نوشتن، تنها کیفیت است

شاید خیلی ساده بتوان گفت دو هدف کلی از نوشتن تست داریم؛

1- به باگ های خودمان رسیدگی کنیم قبل از اینکه به باگ هایمان رسیدگی کنند (قبل از اینکه مشتری آنها را پیدا کند سیستم تست آنها را پیدا کرده و به ما نشان بدهد)

2- زمانیکه یک قسمت از طراحی موجود را تغییر می دهیم، دست و دلمان نلرزد

استراتژی بک لاگ تست خودکار

شاید روش های زیادی برای شروع نوشتن تست های خودکار وجود داشته باشد، ما در اینجا به روش بک لاگ تست خودکار اشاره می کنیم.

برای شروع تست، بک لاگ تست خودکار ایجاد کنید

تست کیس های موجود سیستم را در قالب یک بک لاگ لیست کنید:

بک لاگ تست خودکار

دانلود فایل نمونه بک لاگ تست خودکار

این فایل را چگونه درست کنم؟ و چه کسی باید آن را درست کند؟ 

بهترین راه برای ساختن این فایل مراجعه به تست های دستی است که انجام می شوند، اگر در تیم خود شخصی را دارید که دستی سیستم را تست می کند، از او بخواهید که تست کیس های خود را داخل فایلی ثبت کند، بعد از همان شخص بخواهید در یکی از ستون ها بنویسد که هر بار این روند به صورتی دستی چقدر طول می کشد؟

بعد از مالک محصول بخواهید که میزان اهمیت هر مورد  را در قالب ریسک مشخص کند، آیتمی که ریسک بالایی دارد، یعنی اینکه اگر از کار بیفتد یا مشکلی در آن پیش بیاید، باعث نارضایتی بالایی برای مشتریان را ذی نفعان می شود، مثلا  در سیستم خدمات پشتیبانی، اگر قابلیت ثبت تیکت باگ داشته باشد، مشتری اصلا خوشحال نخواهد بود، اما اگر ایمیل به کاربر جدید نرود، میشود به گونه دیگری اینکار را انجام داد یا اصلا با مشتری کنار آمد.

آخرین مرحله اینجاست که تیم یا نفراتی از تیم، تخمین بزنند که  اگر لازم باشد این سناریو به صورت تست خودکار به همانگونه که دستی انجام میشد، تبدیل شود چقدر زمان نیاز دارد؟ این تخمین می تواند به روش Story point  یا ساعت/روز باشد.

الویت بندی بک لاگ تست های خودکار

همانند هر بک لاگ دیگری، این بک لاگ نیز باید اولویت بندی شود، برای این کار می توانید ترکیبی از ریسک، مدت زمان نوشتن تست و مدت زمان تست دستی را لحاظ کنید، یعنی اینکه “بالاترین آیتم موردی است که ریسک بالایی دارد و زمان تست دستی آن طولانی است و زمان نوشتن تست خودکار کم است”.

همانند بک لاگ محصول، احتمالا هیچ وقت نوبت به پیاده سازی آیتم های ته بک لاگ نخواهد رسید، اصلا لزومی هم به خودکار سازی نیست (:

استفاده از بک لاگ تست خودکار در برنامه ریزی اسپرینت

از مالک محصول بخواهید، 10 تا 20 درصد ظرفیت اسپرینت ها صرف خودکاری سازی تست های شود(البته حتما باید لزوم این داستان را به مالک محصول نیز توضیح دهید) . بدین صورت در هر جلسه برنامه ریزی اسپرینت به میزان 10 تا 20 درصد اسپرینت می توانید با توجه به اولویت برای خودکاری سازی در اسپرینت بعدی انتخاب کنید.

چابک و موفق باشید

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

4 دیدگاه

  1. شروع خوبی بود … اما:

    – بک لاگ جدا برای تست؟
    – درگیرکردن مالک محصول در اولویت بندی و بررسی تست کیس ها؟ 😐

    به نظرم معیارهای پذیرش هر داستان کاربر میتونه از تست کیس ها پشتیبانی کنه و در نهایت، تکالیف جدید فنی در بک لاگ اسپرینت برای هر تست ایجاد بشه!

    با ایده ی بک لاگ جدیدخیلی موافق نیستم، نگهداری همون یک دونه ش برای خودش مکافاتیه ؛)

    • اسد صفری   •     Author

      بک لاگ جدا کردیم برای اینکه زیاد مالک محصول رو درگیر این داستان نکنیم،
      در اکثر تیم ها و بر اساس تجربه، معمار یا مدیر فنی تیم مسئولیت نگه داری این بک لاگ رو داره،
      حقیقتش اینکه شلوغ کردن بک لاگ محصول خوبی نیست، و اضافه کردن اینها در قالب شرایط پذیرش زمانی فکر خوبی است که شما تازه دارین ویژگی رو می خواهید پیاده سازی کنید، این نوشته برای زمانی است که ویژگی ها پیاده سازی شده اند

  2. احتمالاً کاملاً بستگی به شرایط داره. ما Technical Storyهای تست نوشتن رو توی بکلاگ اصلی گذاشتیم و اتفاقاً این‌ها تنها Technical Storyهایی بودند که مالک محصول ازشون سر در میاورد! (خوشبختانه مالک محصول ما قبلاً یه آزمونگر بوده)
    خوشبختانه مالک محصول خیلی خوب همکاری کرد و الان یه سوئیت عالی تست اتوماتیک داریم.

    کلاً به نظرم اگر امکانش باشه باید سعی کرد که مالک محصول رو به سمت درک مفهوم بدهی فنی سوق بدیم و ازش بخواهیم برای باز پس دادنش همکاری بکنه به جای اینکه موضوع رو ازش مخفی بکنیم.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *