جمعه , ۲۸ اردیبهشت ۱۴۰۳

کیفیت بدون مشخص بودن انتظار از سیستم بی معنیست

The quality is meaningless without a certain expectation of the system
The quality is meaningless without a certain expectation of the system

یکی از مهمترین مسائلی که اغلب در همه تیم‌های نرم‌افزاری فراموش می‌شود، موضوع مدیریت نیازمندی‌هاست(Requirements Management). در ایران، این موضوع تقریبا در هیچ شرکتی به عنوان یک مبحث جدی نگریسته نمی‌شود، و در اکثر این شرکت‌ها حتی چنین موضوعی مطرح هم نمی‌شود.

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

به عنوان نمونه اگر به دیسیپلین‌های RUP(به عنوان یک چارچوب توسعه نرم‌افزار) بنگریم، در پنج دیسیپلین اول که دیسیپلین‌های توسعه‌ای نامیده می‌شوند، خواهیم دید که Requirements از دیسیپلین‌های اولیه است. البته اکثر ما ارتباط این مرحله را بیشتر پیش‌زمینه‌ای برای تحلیل و طراحی می‌دانیم.

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

در اکثر بسته‌های نرم‌افزاریِ ALM مانند محصولات IBM، سیستم مدیریت نیازمندی(مثلا Rational Requisite Pro) قابلیت اتصال به سیستم‌های Test Automation به صورت مستقیم را دارد. اگر بخواهیم جمله‌ای ساده درباره چند خطی که در بالا سیاهه شد، ذکر کنیم، باید بگوییم: بهتر است بدون مدیریت نیازمندی‌هایتان، تست، کیفیت و مدیریت آنها را فراموش کنید. در این حالت فرآیند تست که باید ضامن کیفیت محصول باشد، خود در نهایت بی کیفیتی انجام می‌گیرد. این سبک از آزمودن نرم‌افزار، کمترین بازدهی را به ارمغان خواهد آورد.

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

مِلیک وارطانیان

همچنین ببینید

Test Data Bottleneck

تنگنای داده های تست و راهکار آن

زمان زیادی برای یافتن کیس های مناسب برای داده های تست هدر می شود، چندین …

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

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