خانه / تست نرم‌افزار / پیشگیری از عیب در سیستم: کاهش هزینه‌ها و ارتقای کیفیت

پیشگیری از عیب در سیستم: کاهش هزینه‌ها و ارتقای کیفیت

پیشگیری از عیب در سیستم: کاهش هزینه‌ها و ارتقای کیفیت

نویسنده:

زمان مطالعه 10 دقیقه

انتشار:

به‌روزرسانی:

تعداد نظرات: 3

حتما جمله «پیشگیری بهتر از درمان است» را شنیده‌اید و باید گفت این جمله علاوه بر علم پزشکی، در مورد عیب در چرخه عمر توسعه نرم‌افزار هم صدق می‌کند. عیب و خطاها همان طور که توسط توسعه‌دهندگان نرم‌افزار تعریف شده‌اند، مغایرت‌هایی در برنامه با ویژگی‌های مطلوب برنامه هستند. این ویژگی‌‌ها شامل الزامات کامل و صحیح و مشخصاتی است که از مشتریان بالقوه گرفته شده است. بنابراین، عیب باعث می‌شود که نرم‌افزار نتواند الزامات را برآورده کند و در نتیجه مشتریان ناراضی شوند. 

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

عیب در حوزه توسعه نرم‌افزار چقدر جدی است؟ طبق گزارش مجله Computer Finance، حدود ۶۰ درصد از توسعه‌دهندگان نرم‌افزار در آمریکا درگیر رفع کردن خطاها هستند. حتی بدون توجه به فراهم کردن کیفیت لازم برای جلب رضایت مشتریان، واقعیت این است که این رقم نشان دهنده اهمیت پیشگیری از عیب در نرم‌افزار است. 

مزیت تشخیص زودهنگام عیب چیست؟

داده‌های به دست آمده از گزارش‌های مختلف، از نیاز برای رفع زود هنگام نقایص پشتیبانی می‌کنند. موسسه ملی فناوری استاندارد (‏NIST) تحقیقی را در سال ۲۰۰۲ منتشر کرد که در آن هزینه رفع باگی (bug) که در مرحله تولید نرم‌افزار پیدا شود، ۱۵ ساعت تخمین زده می‌شود؛ در حالی که این هزینه در مرحله کدنویسی ۵ ساعت است.

موسسه علوم سیستم‌ها در IBM گزارش داده ‌است که هزینه رفع خطایی که پس از انتشار محصول پیدا می‌شود، چهار تا پنج برابر حالتی است که این خطا در طول مرحله طراحی پیدا شود و تا ۱۰۰ برابر بیش از خطایی است که در مرحله نگهداشت شناسایی شد (‏شکل ۱)‏.

defect prevention costs
شکل ۱: هزینه‌های نسبی برای رفع عیب در نرم‌افزار (منبع: موسسه علوم سیستم‌های IBM)

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

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

اصول پیشگیری از عیب چیست؟

مکانیسم پیشگیری از عیب چگونه کار می‌کند؟ پاسخ در چرخه پیشگیری از عیب است (‏شکل ۲)‏. بخش جدایی‌ناپذیر فرایند پیشگیری از عیب با تجزیه و تحلیل نیاز شروع می‌شود که در آن نیازهای مشتری را بدون ایجاد خطاهای اضافی به مشخصات محصول تبدیل می‌کنیم.

معماری نرم‌افزار طراحی می‌شود، بعد از آن بررسی کدها و انجام تست برای پیدا کردن عیب‌ها و در نهایت ثبت عیب و مستندسازی انجام می‌شود.

defect prevention cycle
شکل ۲: چرخه پیشگیری از عیب (‏منبع: ۱۹۹۸ کنسرسیوم بهره‌وری نرم‌افزار IEEE)

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

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

این اقدامات پیشگیرانه، پس از موافقت و تعهد اعضای تیم به عنوان زمینه‌ای برای پروژه‌های آینده در سازمان گنجانده می‌شوند. هدف این روش ارائه یک راه حل بلندمدت و ایجاد بلوغ سازمانی برای یادگیری از اشتباه‌ است.

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

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

در ادامه به مواردی که برای پیشگیری از عیب‌ها مورد نیاز است، می‌پردازیم:

۱- تحلیل الزامات نرم‌افزار

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

خطاهای الزامات و طراحی در فرانت‌اند (front-end) را نمی‌توان با کمک انجام تست پیدا کرد و از بین برد؛ در عوض نیاز به بررسی پیش تست‌ها و بازرسی دارد. جدول ۱ عیب‌های معرفی شده در مراحل مختلف چرخه عمر توسعه نرم‌افزار را نشان می‌دهد.

defect in software by phase
جدول ۱: تقسیم نقص‌های وارد شده به نرم‌افزار در هر فاز

بر اساس تحقیقات مجله Crosstalk با توجه به مطالعات انجام‌ شده توسط جوامع مختلف توسعه نرم‌افزار، واضح است که اکثر شکست‌ها در محصولات نرم‌افزاری ناشی از خطا در الزامات و مراحل طراحی است که شامل ۶۴ درصد از کل هزینه‌های عیب است (‏شکل ۳).

software defect source
شکل ۳: منشا عیب‌های نرم‌افزار (منبع: Crosstalk)

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

۲- بررسی: خود-بازبینی و بازبینی همکار

«خود-بازبینی» یکی از موثرترین اقدامات برای پیدا کردن عیب‌هایی است که ممکن است بعدا توسط تیم تست یا مشتری کشف شود. اکثر سازمان‌های نرم‌افزاری در حال حاضر این را به بخشی از «بهترین روش کدنویسی (Best Practice)» تبدیل کرده‌اند و در واقع کیفیت محصول خود را افزایش می‌دهند.

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

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

هدف انجام بازبینی توسط همکار نیز شبیه خود-بازبینی است، تنها تفاوت اینجاست که یک همکار (‏کسی که عملکرد کد را به خوبی درک می‌کند)‏ کد را بررسی می‌کند و کد از نگاهی دیگر نیز بررسی می‌شود.

۳- ثبت و مستندسازی عیب

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

یک ابزار ثبت خطا و عیب باید اطلاعات اساسی و خاصی را در مورد عیب‌ها ثبت کند، مواردی مانند:

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

۴- تجزیه و تحلیل ریشه‌ای علت و تعیین اقدامات پیشگیرانه

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

تجزیه و تحلیل ریشه‌ای علت یک عیب (Root Cause Analysis)، توسط سه اصل کلیدی هدایت می‌شود:

  • کاهش خطا برای بهبود کیفیت 

تجزیه و تحلیل باید منجر به اجرای تغییرات، در فرایندهایی شود که باعث جلوگیری از عیب‌ها می‌شود و به اطمینان از تشخیص زود هنگام آن‌ها کمک می‌کند.

  • استفاده از متخصص‌های داخلی

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

  • هدف قرار دادن خطاهای سیستماتیک

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

با این دستورالعمل‌ها، عیب‌ها برای تعیین منشا آن‌ها تجزیه و تحلیل می‌شوند. مجموعه‌ای از این علت‌ها، به انجام «تحلیل علت ریشه‌ای» کمک خواهد کرد. عیب‌ها براساس نوع آن‌ها طبقه‌بندی می‌شوند. یک نمودار پارتو (Pareto chart) برای نشان دادن عوامل عیب با بالاترین فرکانس وقوع و هدف آماده شده‌ است. مثالی از طبقه‌بندی عیب در نمودار پارتو (شکل ۴) نشان‌داده شده‌است.

Defect Classification in a Pareto Chart
شکل ۴: مثالی از طبقه‌بندی عیب در یک نمودار پارتو

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

Cause-and-Effect Diagram for a Defect
شکل ۵: نمودار علت و معلول برای یک عیب

نمودار علت و معلولی (cause-and-effect diagram)، که به عنوان نمودار استخوان ماهی (fishbone diagram) نیز شناخته می‌شود، یک تکنیک گرافیکی ساده برای دسته‌بندی و ایجاد ارتباط بین عواملی است که به تحلیل یک وضعیت خاص کمک می‌کند. نمودار علت و معلولی معمولا در یک تیم و در طی یک جلسه طوفان فکری (brainstorming) تسهیل شده، آماده می‌شود. وقتی که علت‌های ریشه‌ای مشخص شدند، برای پیدا کردن راهکارهای حل آن‌ها نیاز به برگزاری جلسات طوفان فکری دیگری است. هدف کلی این است که مشخص شود چه تغییراتی باید در فرایندها گنجانده شوند تا که بازگشت عیب‌ها به فرایند را به حداقل رساند.

۵- در نظر گرفتن رویه‌ها در فرایند توسعه نرم‌افزار

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

  • اشاره به عیب‌های سخت و فرایند تجزیه و تحلیل آن‌ها در صورت وضعیت عملکرد ماهانه تیم
  • برگزاری جلساتی به صورت ماهانه یا دوهفته‌ای، براساس زمانبندی پروژه برای آگاه کردن تیم از خطاها یا عیب‌های سیستماتیک، علائم و راه‌حل‌های آن‌ها 
  • ایجاد معیارهایی برای ‌پیشگیری از عیب در فرایندهای چرخه حیات توسعه نرم‌افزار
  • استفاده از نتایج تجزیه و تحلیل علت ریشه‌ای انجام شده در پروژه‌های قبلی، به عنوان خط پایه برای پروژه‌های آینده
  •  نظارت بر پیشرفت فرایند پیشگیری از عیب و بررسی این که آیا تعداد عیوب کم می‌شود؟ آیا تیم توسعه از اشتباهات گذشته درس می‌گیرد؟

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

جمع‌بندی

اشتباه کردن جزئی از انسان بودن است اما روش‌های پیشگیری از عیب، توانایی توسعه‌دهندگان نرم‌افزار برای یادگیری از آن خطاها و مهم‌تر از آن، یادگیری از اشتباهات دیگران را افزایش می‌دهد. مزایای اجرای روش پیشگیری از عیب شامل موارد زیر است:

  • بهبود چک لیست کیفیت محصول
  • کاهش دوباره کاری‌ها
  • کاهش قابل‌توجه تعداد و شدت عیب‌ها
  • ایجاد ارتباط بهتر بین تیم پروژه و مدیریت ارشد
  •  برنامه‌ریزی بهتر و بهینه‌تر منابع 

 

منبع:

Defect Prevention: Reducing Costs and Enhancing Quality

 

 

با ما همراه شوید!

تیم‌های مختلف آسا در ساختمان‌ها و موقعیت‌های مکانی مختلف آسا مستقر هستند. برای اطلاع از آدرس‌ها و راه‌های ارتباطی با آسا، به صفحه «درباره آسا» مراجعه کنید.

سعید زارعی نیم‌رخ

سوالات متداول

دیدگاه‌ها

3 پاسخ به “پیشگیری از عیب در سیستم: کاهش هزینه‌ها و ارتقای کیفیت”

  1. مریم نیم‌رخ
    مریم

    مطلب جالبی بود
    مرسی که به اشتراک گذاشتین

  2. حسین نیم‌رخ
    حسین

    ممنون جناب زارعی بابت این مقاله خوب. یه سوال داشتم. برای automation test شما چه ابزاری رو پیشنهاد میکنید؟ مخصوصا اگه میکروسرویس استفاده شده باشه تو پروژه

    1. سعید نیم‌رخ
      سعید

      سلام و عرض ادب و روز بخیر، واژه automation test به شدت واژه کلی هست و برای تمامی لول های تست قابلیت اتومات سازی وجود دارد
      بنابراین شرایط کمی پاسخ به سوال شما طولانی خواهد شد ولی من در چند ضمینه سعی تست سعی میکنم Best practice هارو خدمتتون بگم
      UI test ——————> seleniun / cypress
      API automation test (request) ———————> استفاده از پایتون و لایبرری unit test
      این دو ضمینه معمولا دغدغه اتومات سازی در بیشتر سازمان هاست

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

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