فرآیند تست نرم‌افزار؛ یک انتخاب یا یک ضرورت؟

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

انواع مختلفی از تست نرم‌افزار، متناسب با فازهای مختلف توسعهٔ نرم‌افزار و در راستای اهداف متفاوت وجود داره؛ تست دسترسی (Accessibility testing)، تست سازگاری (Compatibility testing)، تست پسرفت (Regression testing)، تست تخریبی (Destructive testing)، تست کاربردپذیری (Usability testing)، تست امنیتی (Security testing)، تست بهره‌وری (Performance testing) و … از جمله انواع این فرایند هستند که برای هر مورد، مراحل و تست‌کیس (Test case) منحصر به‌فرد، طراحی و اجرا میشه.

فرآیندهای موسوم به تست نرم‌افزار، در روند تولید و توسعهٔ هر نوع محصول نرم‌افزاری، فارغ از کاربرد ویا محیط اجرایی، میتونه مورد استفاده قرار بگیره و مؤثر واقع بشه؛ تجهیزات بیمارستانی و نظامی، تأسیسات الکترونیکی، انواع گجت‌ها، نرم‌افزارهای سازمانی، اپلیکیشن‌های موبایل، وب‌سایت‌ها و هر نوع محصولی نرم‌افزاری مستقل ویا غیرمستقل، نمونه‌ای از این مواردند. قاعدتاً عواملی مثل ارتباط داشتن محصول نرم‌افزاری با تراکنش‌های مالی، اطلاعات افراد حقیقی یا حقوقی و سلامتی موجودات زنده، از جمله مواردی هستن که اهمیت تست نرم‌افزار رو به طور جدی افزایش میدند.

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

واضحه که محصولات تولید شده به روش‌های غیراستاندارد یا به اصطلاح ابتکاری، در اکثر موارد، یا آزمون‌پذیر نیستند و یا به علت ضعیف بودن میزان آزمون‌پذیری، نیازمند صرف هزینه و زمان بسیار بیشتری هستند. (مطالعهٔ بیشتر در زمینهٔ آزمون‌پذیری)

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

عامل انسانی

درحال حاضر تمامی پروژه‌های نرم‌افزاری، مستقیم ویا غیرمستقیم، توسط انسان‌ها تولید میشن و هنوز هیچ ماشینی وجود نداره که بتونه روند تولید نرم‌افزار رو بهتر از انسان‌ها و به صورت کاملاً مستقل انجام بده.

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

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

طرح ایده

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

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

کاربران ویژه و خلاق

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

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

اما چه راه‌هایی برای بررسی همهٔ سناریوهای ممکن روی یک سیستم وجود داره؟ چطور میشه از ایمن بودن همهٔ سناریوها مطمئن شد؟

تخمین بازهٔ زمانی

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

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

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

اما آیا هیچ راه اصولی برای تخمین زمان مناسب یک پروژهٔ خاص وجود داره؟ چه پارامترهایی باید مورد توجه قرار بگیره؟

مقیاس پذیری

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

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

متدولوژی مناسب

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

تقریباً تمام متدولوژی‌های مطرح در توسعهٔ نرم‌افزار اعم از طراحی محور(Design-driven)، رفتار محور (Behavior-driven)، آزمون محور(Test-driven)، تکرار شونده (Iterative)، چابک (Agile)، ناب (Lean) و … هرکدام توسط تعدادی از شرکت‌های مطرح و موفق دنیا مورد استفاده قرار میگیرن.

چطور میشه برای یک محصول یا ایدهٔ خاص، متدولوژی مناسب رو تشخیص داد و با اصول اون پیش رفت، تا به بهترین نتیجهٔ ممکن برسیم؟

تغییرات نهایی

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

اغلب ویژگی‌هایی که در مرحلهٔ تحلیل و طراحی سیستم در نظر گرفته میشه، توی اصلاحیه‌های بعدی در نظر گرفته نمیشه؛ به این دلیل که با گذر زمان، بیشتر این موارد از خاطر افراد تیم فراموش میشه و فرصتی هم برای مرور مجدد طراح‌ها و مستندات وجود نداره.

درسته که این مورد، تقریباً اجتناب ناپذیره، اما میشه راهی برای کنترل این خطاها و کاهش هزینه‌های تغییرات مطرح کرد؟

 

«نتیجه گیری»

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

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


پاورقی:

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

  • IRS: سازمان درآمد داخلی امریکا (سال ۲۰۰۶ میلادی)
    • دلیل خطا: عدم وجود سیستم تشخیص تقلب و لاگ نشدن داده‌ها در پرتال سازمان
    • نتیجه: ایجاد اختلال غیرقابل ردگیری در حساب‌های مالی (خسارت ۳۰۰ میلیون دلاری)
  • سفینهٔ فضایی Mariner1 (سال ۱۹۶۲ میلادی)
    • دلیل خطا: اشتباه برنامه‌نویس در وارد کردن فرمول محاسباتی و جا انداختن تنها یک پارامتر در فرمول
    • نتیجه: انحراف و بروز انفجار پس از ۲۹۳ ثانیه از شروع (خسارت ۱۹ میلیون دلاری)
  • پروژهٔ استارت‌آپ GoZoomo (سال ۲۰۱۴ تا ۲۰۱۶ میلادی)
    • دلیل خطا: اشتباه در طرح اولیه سیستم و ادامهٔ مسیر توسعه با همان مدل نادرست
    • نتیجه: تعطیل شدن پروژه پس از حدود ۲ سال فعالیت بیش از ۶۵ نفر (خسارت تقریبی ۳ میلیون دلاری)
  • باگ FDIV در پردازندهٔ پنتیوم اینتل (سال ۱۹۹۴ میلادی)
    • خطا: ایراد در فرمول محاسبهٔ اعداد اعشاری و برگرداندن نتایج نادرست در مواقعی خاص
    • نتیجه: اعلام خرابی و جمع‌آوری ۵ میلیون پردازنده (خسارت ۴۷۵ میلیون دلاری و کاهش اعتبار برند)
  • دستگاه رادیوتراپی Therac-25 (سال ۱۹۸۵ تا ۲۰۰۰ میلادی)
    • خطا: اشتباه جزئی در تعریف حلقه و دوبرابر شدن مقدار داده در شرایط خاص
    • نتیجه: استفاده از دز نامناسب برای برخی بیماران (مرگ ۱۰ نفر و ۲۰ صدمهٔ فیزیکی غیرقابل جبران)

6 دیدگاه برای «فرآیند تست نرم‌افزار؛ یک انتخاب یا یک ضرورت؟»

    1. ممنون که مطالعه کردین 😉
      اتفاقاً یکی از استانداردهای مقاله‌نویسی اینه که متن باید حتماً justify باشه. اما طبق فیدبک‌هایی که از بعضی از دوستان گرفتم، گویا به‌خاطر تفاوت‌های متن چاپی با متن دیجیتالی، و همینطور مشکلات برخی از مرورگر‌ها برای درست justify کردن متن، متون justify توی وبلاگ، باعث اذیت شدن چشم میشه.

پاسخ دهید

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