تضمین کیفیت نرم‌افزار (Software Quality Assurance)
مقدمه
کیفیت به صورت مشخصات یا ویژگی‌های یک شیء تعریف شده است که در اینجا ویژگی‌ها به مشخصات قابل اندازه‌گیری اشاره دارد، مواردی که قادر به مقایسه آن‌ها با استانداردهای شناخته شده هستیم.
انواع کیفیت:
کیفیت طراحی به مشخصاتی اشاره دارد که طراحان برای یک آیتم مشخص می‌کنند. درجه متریال، مشخصات تحمل و کارایی، همگی به کیفیت طراحی کمک می‌کنند.
کیفیت سازگاری درجه‌ای که مشخصات طراحی در طی تولید از آن تبعیت می‌کند. درجه سازگاری بزرگتر منجر به سطح کیفیت سازگاری بالاتری می‌شود.
کیفیت نرم‌افزار به صورت سازگاری با نیازمندی‌های عملکردی و کارایی که به صورت صریح بیان شده‌اند، استانداردهای توسعه که به صورت صریح مستند شده‌اند، ویژگی‌های ضمنی که از همه نرم‌افزار‌هایی که به صورت حرفه‌ای توسعه داده شده‌اند انتظار می‌رود، تعریف شده است.
در توسعه نرم‌افزار، کیفیت طراحی شامل نیازمندی‌ها، مشخصات و طراحی سیستمی می‌باشد که در آن کیفیت سازگاری به عنوان یک مسئله مهم در پیاده‌سازی مورد توجه قرار می‌گیرد.
اگر پیاده‌سازی از طراحی تبعیت کند و سیستم حاصله نیازمندی‌ها و اهداف کارایی را برآورده سازد، کیفیت سازگاری بالا است.
تضمین کیفیت نرم‌افزار (SQA)
تضمین کیفیت نرم‌افزار (SQA) یک فعالیت چتری است که در سراسر فرآیند نرم‌افزار اعمال می‌شود.
تضمین کیفیت نرم‌افزار شامل موارد زیر است:
رویکرد مدیریت کیفیت
فن‌آوری مهندسی نرم‌افزار موثر
بررسی فنی رسمی
استراتژی تست چند لایه
کنترل مستندات نرم‌افزاری و تغییرات ایجاد شده در آن
روشی برای تضمین سازگاری با استانداردهای توسعه نرم‌افزار
مکانیزم اندازه‌گیری و گزارش‌دهی
تضمین کیفیت نرم‌افزار (SQA)
تضمین کیفیت نرم افزار متشکل از وظایف گوناگون مرتبط با دو حوزه مختلف می‌باشد، مهندس نرم‌افزار که کار فنی انجام می‌دهد و گروه تضمین کیفیت نرم افزار که مسئولیت برنامه‌ریزی تضمین کیفیت، نظارت، تحلیل و گزارش‌دهی را بر عهده دارد.
آماده‌سازی یک طرح تضمین کیفیت نرم افزار برای یک پروژه
این طرح در طی برنامه‌ریزی پروژه توسعه داده می‌شود و توسط همه افراد ذی‌نفع مورد بررسی قرار می‌گیرد. فعالیت‌های تضمین کیفیت نرم افزار توسط تیم مهندسی نرم‌افزار انجام می‌گیرد و گروه تضمین کیفیت نرم افزار SQA توسط این طرح کنترل می‌شوند. این طرح موارد زیر را نشان می‌دهد:
ارزیابی‌هایی که باید انجام شود
حسابرسی‌ها و بررسی‌هایی که باید انجام شود
استانداردهای قابل اجرا برای پروژه
روش‌های گزارش و ردیابی خطا
مستنداتی که باید توسط تیم SQA تولید شوند
میزان بازخورد فراهم شده برای تیم پروژه نرم‌افزاری
شرکت کردن در توسعه توصیف فرآیند نرم‌افزاری پروژه
تیم نرم‌افزاری فرایندی را برای کاری که باید انجام شود انتخاب می‌کند.
تضمین کیفیت نرم افزار SQA، توصیف فرآیند برای انطباق با سیاست سازمان، استانداردهای داخلی نرم‌افزار، استانداردهای اعمال شده خارجی و سایر بخش‌های طرح پروژه نرم‌افزاری را بررسی می‌کند.
بررسی فعالیت‌های مهندسی نرم‌افزار برای تأیید انطباق‌ها با فرآیند نرم‌افزاری تعریف شده
گروه تضمین کیفیت نرم افزار، مسیر انحرافات از فرایند را شناسایی و مستند نموده و بررسی می‌کند که اصلاحات انجام شده باشد.
بازبینی محصولات کاری نرم‌افزاری طراحی شده برای تأیید انطباق با چیزهایی که به عنوان بخشی از فرایند نرم‌افزار تعریف شده است
تضمین کیفیت نرم افزار SQA محصولات کاری انتخاب شده را بررسی می‌کند، مسیر انحرافات را شناسایی و مستند می‌کند؛ بررسی می‌کند که اصلاحات انجام شده باشد؛ و به طور دوره‌ای نتایج کارهای خود را به مدیر پروژه گزارش می‌دهد.
تضمین این که انحرافات در نرم‌افزار و محصولات کاری مطابق با روش‌های مستندسازی مستند و مدیریت شده‌اند.
ثبت هرگونه عدم انطباق و گزارش به مدیر ارشد
مرتبط با تضمین حصول سطح کیفیت لازم در محصول نرم‌افزاری می‌باشد.
در سطح سازمانی، مدیریت کیفیت مرتبط با ایجاد چارچوبی از فرآیندها و استانداردهای سازمانی می‌باشد که منجر به نرم‌افزاری با کیفیت بالا می‌شوند.
در سطح پروژه، مدیریت کیفیت همچنین مرتبط با ایجاد یک طرح کیفیت برای پروژه می‌باشد. طرح کیفیت باید اهداف کیفیت پروژه را تعیین نموده و فرآیندها و استانداردهای مورد استفاده را تعریف کند.
بررسی‌های نرم‌افزاری (Software Reviews)
بررسی‌های نرم‌افزاری، فیلتری برای فرآیند مهندسی نرم‌افزار هستند.
بررسی‌ها در طی توسعه نرم‌افزار در نقاط مختلف صورت می‌گیرند و برای کشف خطاها و نقص‌هایی که می‌توانند حذف شوند به کار می‌روند.
بررسی‌های نرم‌افزار، فعالیت‌های مهندسی نرم‌افزار که ما آن‌ها را آنالیز، طراحی و کد‌نویسی می‌نامیم، را تصفیه می‌کنند.
بررسی، روش استفاده گروه مختلفی از افراد است برای:
شناسایی اصلاحات مورد نیاز در محصول یک فرد یا یک تیم
تایید قسمت‌هایی از محصول که اصلاح آن‌ها مطلوب یا مورد نیاز نیست
دستیابی به کیفیت یکنواخت‌تر، یا حداقل قابل پیش‌بینی‌تر کار فنی جهت مدیریت بهتر
یک گروه بخشی یا تمام فرایند یا سیستم و اسناد مرتبط با آن را برای یافتن مشکلات احتمالی مورد بررسی قرار می‌دهد.
نرم افزار یا مستندات ممکن است در یک بررسی "پایان یافته" باشند که نشان می‌دهد که پیشرفت به مرحله بعدی توسعه توسط مدیریت تایید شده است.
انواع مختلفی از بررسی با اهداف مختلف وجود دارد
بازرسی برای حذف نقص (محصول)
بررسی‌هایی برای ارزیابی پیشرفت (محصول و فرآیند)
بررسی‌های کیفیت (محصول و استانداردها).
بررسی های کیفیت
گروهی از افراد که بخش یا کل یک سیستم نرم‌افزاری و مستندات مرتبط با آن را به دقت بررسی می‌کنند.
کد، طراحی‌ها، مشخصات، طرح‌های تست، استانداردها و غیره، همگی می‌توانند بررسی شوند.
نرم افزار یا مستندات ممکن است در یک بررسی "پایان یافته" باشند که نشان می‌دهد که پیشرفت به مرحله بعدی توسعه توسط مدیریت تایید شده است.
فرآیند بررسی های نرم افزار
بازبینی های برنامه
بررسی‌های متناظری وجود دارند که در آن‌ها مهندسان، کد منبع یک سیستم را با هدف کشف ناهنجاری‌ها و نقص‌ها مورد بررسی قرار می‌دهند.
بازبینی‌ها به اجرای یک سیستم نیازی ندارند و بنابراین ممکن است قبل از پیاده‌سازی مورد استفاد قرار گیرند.
آن‌ها ممکن است برای هر نمایشی از سیستم (نیازمندی‌ها، طراحی، پیکربندی داده‌ها، داده‌های تست و غیره) به کار گرفته شوند.
نشان داده شده است که آن‌ها روش موثری برای کشف خطاهای برنامه هستند.
چک‌لیستی از خطاهای متداول باید جهت انجام بازربینی‌ها مورد استفاده قرار گیرد.
چک لیست‌های خطا به زبان برنامه‌نویسی وابسته هستند و ویژگی خطاهایی که احتمالا در آن زبان به وجود می‌آیند را منعکس می‌سازند.
به طور کلی، بررسی نوع "ضعیف‌تر"، منجر به چک‌لیست بزرگتر می‌شود.
مثال‌ها: مقداردهی اولیه، نام‌گذاری ثابت، اتمام حلقه، محدوه‌های آرایه، غیره.
| طبقه نقص | چک‌لیست بازبینی |
|---|---|
| نقص‌های داده | آیا همه متغیرهای برنامه قبل از اینکه مقدار آن‌ها مورد استفاده قرار گیرد، مقداردهی اولیه شده‌اند ؟ آیا همه ثابت‌ها نام‌گذاری شده‌اند؟ حد بالایی آرایه‌ها باید مساوی با اندازه آرایه یا اندازه آرایه منهای یک باشد؟ در صورتی که رشته‌های کاراکتری مورد استفاده قرار گیرد، یک جداکننده صریح تخصیص داده می‌شود؟ آیا امکان سرریزی بافر وجود دارد؟ |
| نقص‌های کنترل | برای هر عبارت شرطی، آیا شرط درست است؟ آیا پایان هر حلقه مشخص شده است؟ آیا عبارات ترکیبی به درستی با براکت احاطه شده‌اند؟ آیا در هر عبارت، همه حالت‌های ممکن مد نظر قرار گرفته‌اند؟ آیا در هر case statement که باید بعد از هر case یک break قرار گیرد، break قرار گرفته است؟ |
| نقص‌های ورودی/خروجی | آیا همه متغیرهای ورودی مورد استفاده قرار گرفته‌اند؟ آیا به همه متغیرهای خروجی قبل از اینکه در خروجی نمایش داده شوند، مقداری تخصیص داده شده است؟ آیا ورودی‌های غیرمنتظره می‌توانند منجر به خرابی شوند؟ |
چک لیست بازبینی اول
| طبقه نقص | چک‌لیست بازبینی |
|---|---|
| نقص‌های واسط | آیا همه فراخوانی تابع و متد دارای تعداد صحیحی از پارامترها می‌باشند؟ |
| نقص‌های مدیریت ذخیره‌سازی | در صورتی که ساختار لینک تغییر کند، آیا همه لینک‌ها مجددا به درستی تخصیص داده می‌شوند؟ آن نیست به درستی صورت می‌گیرد؟ |
| نقص‌های مدیریت استثنا | آیا همه شرایط وقوع خطای ممکن مد نظر قرار گرفته‌اند؟ |
چک لیست بازبینی دوم
قابلیت اطمینان نرم‌افزار
قابلیت اطمینان یک ویژگی سیستم قابل اندازه‌گیری است و بنابراین نیازمندی‌های قابلیت اطمینان غیرعملکردی ممکن است بطورکمی مشخص شوند. این مفهوم تعداد شکست‌هایی که در طی استفاده نرمال از سیستم یا زمانی که سیستم باید در دسترس باشد رخ می‌دهند را، تعریف می‌کند.
نیازمندی‌های قابلیت اطمینان عملکردی، عملکردهایی از سیستم و نرم‌افزار را تعریف می‌کنند که از رخداد نقص‌ها در نرم‌افزار جلوگیری کرده، یا اینکه نقص‌ها را شناسایی می‌کنند و بنابراین تضمین می‌کنند که این نقص‌ها منجر به شکست سیستم نمی‌شوند.
همچنین نیازمندی‌های قابلیت اطمینان نرم‌افزار ممکن است با شکست سخت‌افزاری یا خطای عملگر مقابله کنند.
احتمال اینکه عملیات سیستم در یک مدت زمان مشخص و در یک محیط معین برای یک هدف معین با شکست همراه نباشد.
دسترس‌پذیری
احتمال اینکه یک سیستم، در یک لحظه از زمان، قابل استفاده و قادر به ارائه سرویس‌های درخواست شده باشد.
هر دو ویژگی می‌توانند بطور کمی بیان شوند به عنوان مثال دسترس‌پذیری 0.999 به معنای این است که سیستم در 0.999 درصد از مواقع در دسترس و در حال اجراست.
فرآیند تعیین قابلیت اطمینان
شناسایی ریسک: شناسایی انواع شکست‌های سیستم که ممکن است منجر به ضررهای اقتصادی شوند.
تحلیل ریسک: تخمین هزینه‌ها و پیامدهای انواع مختلفی از شکست‌های سیستم.
تفکیک ریسک: شناسایی علت‌های ریشه‌ای شکست سیستم.
کاهش ریسک: تهیه مشخصات قابلیت اطمینان، شامل نیازمندی‌های کمی که سطوح شکست قابل قبول را تعریف می‌کنند.
انواع شکست سیستم
| نوع شکست | توضیحات |
|---|---|
| عدم سرویس‌دهی | سیستم در دسترس نیست و نمی‌تواند سرویس‌های خود را به کاربران تحویل دهد. ممکن است در جایی که پیامدهای ناشی از شکست سرویس‌های غیر بحرانی کمتر از پیامدهای ناشی از شکست سرویس بحرانی است، میان عدم سرویس‌دهی بحرانی و عدم سرویس دهی غیربحرانی تمایز قائل شوید. |
| تحویل سرویس نادرست | سیستم سرویس را به درستی به کاربران تحویل نمی‌دهد. باز هم ممكن است بر حسب خطاهاي كوچك و خطاهای بزرگ یا خطا در تحویل سرویس‌های بحرانی و غیربحرانی مشخص شود. |
| خرابی سیستم / داده | شکست سیستم منجر به آسیب رساندن به خود سیستم و یا داده‌های آن می‌شود. این شکست معمولا و نه لزوما در ارتباط با انواع دیگر شکست‌ها می‌باشد. |
انواع شکست سیستم
معیارهای قابلیت اطمینان
معیارهای قابلیت اطمینان، واحدهای اندازه‌گیری قابلیت اطمینان سیستم هستند.
قابلیت اطمینان سیستم، با شمارش تعداد شکست‌های عملیاتی اندازه‌گیری می‌شود، و در جای مناسب، آن را به درخواست‌های داده شده به سیستم و مدت زمانی که سیستم قابل استفاده است ارتباط می‌دهند.
یک برنامه اندازه‌گیری طولانی مدت، برای ارزیابی قابلیت اطمینان سیستم‌های بحرانی لازم است.
معیارها
احتمال شکست به محض درخواست
نرخ وقوع شکست/متوسط زمان لازم برای رخداد شکست
دسترس‌پذیری
مثال‌ها: احتمال شکست به محض درخواست (POFOD)
احتمال شکست سیستم وقتی که سرویسی درخواست می‌شود. وقتی که درخواست‌های سرویس متناوب و نسبتا کم است، مفید می‌باشد.
برای سیستم‌های حفاظتی که سرویس‌ها بعضی از اوقات درخواست می‌شوند و در مواردی که عدم تحویل سرویس منجر به پیامدهای جدی می‌شود مناسب است.
برای بسیاری از سیستم‌های بحرانی-ایمنی که دارای مولفه‌های مدیریت استثنا هستند مناسب می‌باشد.
سیستم خاموشی اضطراری در یک دستگاه شیمیایی.
نرخ وقوع نقص (ROCOF)
نرخ وقوع شکست در سیستم را منعکس می‌سازد.
نرخ وقوع نقص 0.002 به معنای رخداد 2 شکست در هر 1000 واحد زمان عملیاتی می‌باشد. به عنوان مثال 2 شکست در هر 1000 ساعت عملیات.
برای سیستم‌های که باید تعداد زیادی از درخواست‌های مشابه را در یک زمان کوتاه پردازش کنند مناسب می‌باشد
سیستم پردازش کارت اعتباری، سیستم رزرو هواپیمایی.
نرخ وقوع نقص دوطرفه، برابر با متوسط زمان لازم برای رخداد شکست می‌باشد (MTTF)
برای سیستم‌های دارای تراکنش‌های بزرگ که پردازش سیستم زمان زیادی طول می‌کشد (مانند سیستم‌های CAD) مناسب می‌باشد. MTTF باید بیشتر از زمان مورد انتظار برای پردازش تراکنش باشد.
درک‌هایی از قابلیت اطمینان
تعریف رسمی قابلیت اطمینان همیشه منعکس‌کننده درک کاربر از قابلیت اطمینان سیستم نمی‌باشد.
تصورات از محیطی که سیستم در آن مورد استفاده قرار می‌گیرد ممکن است نادرست باشند.
احتمالا کاربرد یک سیستم در یک محیط اداری کاملا متفاوت با کاربرد همان سیستم در محیط دانشگاه می‌باشد
پیامدهای شکست سیستم بر روی درک از قابلیت اطمینان تاثیر می‌گذارد
غیرقابل اطمینان بودن شیشه پاک کن شیشهِ جلوی ماشین ممکن است در آب و هوای خشک بی‌اهمیت باشد.
شکست‌هایی که پیامدهای جدی دارند (مانند از کارافتادگی موتور یک ماشین) نسبت به سایر شکست‌ها نزد کاربران از اهمیت بیشتری برخوردارند.
قابلیت اطمینان و مشخصات
قابلیت اطمینان تنها می‌تواند به صورت رسمی و با توجه به مشخصات سیستم تعریف شود، به عبارت دیگر شکست، انحراف از مشخصات می‌باشد.
اما، بسیاری از مشخصات ناقص یا نادرست هستند، بنابراین سیستمی که مطابق با مشخصات آن می‌باشد، ممکن است از دید کاربران سیستم با شکست مواجه شود.
علاوه بر این، کاربران مشخصات را نمی‌خوانند، بنابراین نمی‌دانند سیستم چگونه باید رفتار کند.
بنابراین درک از قابلیت اطمینان در عمل بسیار مهم است.
شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه تست و تضمین کیفیت نرم افزار ارائه می دهد:
تست عملکردی نرم افزارهای تحت وب، دسکتاپ، موبایل و نهفته
تست پرفورمنس (تست بار و فشار) سامانه های نرم افزاری
تست امنیت و نفوذ سامانه های نرم افزاری
برون سپاری تست و تضمین کیفیت نرم افزار
ممیزی کیفیت نرم افزارهای تهیه شده
ارائه مشاوره در حوزه تست و تضمین کیفیت نرم افزار
ارائه استاندارد، متدولوژی، ابزار و چک-لیست در حوزه تست نرم افزار
تهیه و آموزش ابزارهای تست عملکردی همچون SOATest و Ranorex
تهیه و آموزش ابزارهای تست پرفورمنس (تست بار و فشار) همچون WPLT و LoadTest
تهیه و آموزش ابزارهای تست امنیت و نفوذ همچون WebInspect و AppScan
راه اندازی ابزارهای تحلیل ایستا (مرور سورس کد) همچون JTest، dotTest، C++Test، Sonar و Checkmarx
راه اندازی ابزارهای تحلیل پویا (پروفایلر) همچون Yourkit Java Profiler و Yourkit dotNet Profiler
مانیتور کردن شاخص های کارایی سامانه های نرم افزاری از طریق ابزارهای مدیریت کارایی همچون AppDynamics
نویسنده : شرکت مهندس پیشگان آزمون افزار یاس
مراجع
[1]-Swapna Kishore, Rajesh Naik, “ISO 9001:2000 for Software Organizations”, Tata McGraw-Hill Publishing Company Limited, 2003.
[2]-A.J.G. Babu, Nalina Suresh, "Modelling and optimizing software quality", International Journal of Quality & Reliability Management, Vol. 13 Issue: 3, pp.95-103, 1996.
[3]-A. Pimputkar, P.Patel, “Study on Software Testing and Software Quality Assurance”, International Journal of Advance Research in Engineering, Science & Technology, Vol. 4 Issue: 5, pp.227-232, 2017.
[4]-W. E. LEWIS, “Software Testing and Continuous Quality”, Third Edition, CRC Press, 2009.
[5]-K. NAIK, P. TRIPATHY: “Software Testing and Quality Assurance”, WILEY, 2008.
[6]-L. Sommerville, “Software Engineering”, 8th Edition, 2006.
[7]-A. P. MATHUR, “Foundations of Software Testing”, Pearson Education, 2009.
[8]-D. GALIN, “Software Quality Assurance: From Theory to”, Pearson Education, 2004
[9]-Roger S. Pressman, “Software Engineering: A Practitioner Approach”, 6th Edition, McGraw-Hill, 2005.
[10]-S.A. Kelkar, “Software Quality and Testing: A Concise Study”, PHI Learning Private Limited, 2012.
[11]-A.Adhikari, “Software Quality Assurance”, Published in Education, 2014.