کیفیت نرم افزار و 7 افسانه تست اتوماتیک

– مدیر : “چرا این نرم افزار اینقدر باگ داره ؟ این چه وضع کار کردنه؟”

– برنامه نویس: “این ماهیت نرم افزاره، نمیشه کاریش کرد، فقط اگر ما بشینیم و تست بنویسیم باگ نخواهیم داشت”

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

حالا بعضی سنسورها بزرگتر هستند مثلا تست های یکپارچه و بعضی تست ها ریز هستند برای اندازه گیری یک واحد کوچک Unit Test.

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

راه حل ؟ راه حل این است که ما سریعتر بفهمیم که جایی شکسته است. چطوری؟ با کار گذاری سنسور (Test نوشتن).

خوب عالی من فهمیدم چکار باید بکنم، از فردا هزاران Test به پروژه اضافه خواهد شد (:

تجربه چه می گوید؟

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

  • جهانی فکر کنید محلی عمل کنید

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

سعی نکنید سریع حرکت کنید و بگید خوب تست که نوشتم حالا برای موارد بعدی تست بنویسم. بهبود مداوم و تدریجی می تواند باعث ایجاد فرهنگ شود.

  • باگ ها بهترین جا برای شروع تست نوشتن 

یکی از بهترین تجربیات ما این بوده است که هیچ باگی در سیستم رفع نمی شود تا تست برای آن نوشته شود. یکی از بدترین چیزها در نرم افزار این است که شما باگی را رفع می کنید ولی چند مدت دیگر دوباره همان باگ گزارش می شود.

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

  • TDD خوب است ولی خیلی زود است

TDD یا Test Driven Development  خوب است ولی برای بسیاری از تیم ها زود است، و نکته مهم در موردش این است که این بیشتر یک روش طراحی است تا تست نوشتن. اگر اصرار دارید از این روش استفاده کنید : 1- سعی نکنید یک شبه بتوانید این روش را تیم انجام بدهند 2- این روش نیاز به تجربه در عمل دارد، با نوشتن ماشین حساب نمی شود این روش را یاد گرفت 3- در هر چیزی این روش بدرد نمی خورد، برای کارهای روتین از این روش استفاده نکنید، معمولا اگر در حال طراحی یک مسئله پیچیده هستید می تواند خوب عمل کند.

  • اجرای تست باید خودکار و بعد از هر Check-in یا Commit انجام شود

بهترین تست های دنیا را هم بنویسید اگر اجرای آن خودکار نباشد و لاز باشد کسی آن را دستی اجرا کند، مطمئن باشید بعد از مدتی کنار گذاشته خواهند شد. پس اتصال تست ها به سیستم Continuous Integration الزامی است.

  • تست UI آخرین تست 

ابزار تست های UI در این چند سال بشدت بهتر شده اند ولی هنوز مانند تست های Backend  نیستند. بدلیل اینکه طراحی UI شکننده تر از بخش های دیگر است، پیشنهاد می شود این بخش آخرین جایی باشد که سراغ آن می روید.

  •  برنامه نویس ها دوست ندارند تست بنویسند

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

  • تعداد تست بالا به معنای پوشش تست بالا نیست

یکی از معیارهایی که معمولا ما را سر در گم می کند تعداد تست بالا و Test Coverage است، که وقتی فکر می کنیم یک ابزار Test Coverage نشان می دهد پوشش تست 90% است، پس خیلی عالی هستیم، در حال که بهترین پوشش این است که وقتی جای حساسی از سیستم می شکند شما خبر دار شوید.

  • Unit Test یا Integration 

خیلی فرق نمی کند، مهم این است که شروع کنید و کوچک شروع کنید. اما تجربه نشان داده در سطح محصول تولیدی بهتر است از تست های یکپارچه یا Acceptance Test استفاده کنید، برای شروع بخش هایی مانند framework از Unit استفاده کنید.

  • کدهای تست هم نیاز به نگه داری دارند

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

اگر دوستان علاقمند بودند، شاید بعدا چند تا مورد تست واقعی رو با هم بررسی کردیم.

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

اسد صفری

 

درباره اسد صفری

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

1 دیدگاه در “کیفیت نرم افزار و 7 افسانه تست اتوماتیک

دیدگاهتان را بنویسید

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

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.