Y@SiN
09-13-2009, 04:09 PM
در حقيقت، از دید آزمايش واقع‌گرایانه يا Pragmatic، آزمايشی عملی است که از دو فاکتور مؤثر و مقرون به صرفه بودن بهره‌مند باشد. مؤثر یعنی‌گرفتن نتیجه دلخواه و مقرون به‌صرفه، یعنی در اختیار گذاشتن نیرو براي آزمايش نرم‌افزار با بودجه معین و در زمان خاص. اما به راستی آزمايش نرم‌افزار چيست؟ اغلب ما به این سؤال این‌گونه جواب می‌دهیم که آزمايش یعنی فیلتری که نرم‌افزار از آن عبور می‌کند و پس از عبور نرم‌افزار این نرم‌افزار از هر گونه باگی پاک می‌شود و مصرف‌کننده نهایی نرم‌افزار می‌تواند بدون ترس از این‌که روزی ممکن است سیستم دچار اشکال شود، از آن استفاده کند.
شاید جالب باشد که بگویم آزمايش نرم‌افزار این نیست که ثابت کند نرم‌افزار هیچ‌گونه باگی ندارد یا این‌که نرم‌افزار فاقد هرگونه اشکال است. این اهداف برای گروه آزمايش نرم‌افزار تقریباً بعید است. به نظر شما چرا این‌گونه است؟ تصور کنید سیستمی که یک کار بزرگی انجام می دهد مثلاً در یک محیط دانشگاهی محاسبات علمی انجام می‌دهد یا این‌که در کارخانه‌ای سیستم‌های فنی آن را تنظیم می‌کند؛ حاوی چندین هزار عملیات کاربردی است که ممکن است در طول کار با سیستم نرم‌افزاری از هر زیر سیستم چند دفعه خاص و آن نیز با ورودی اطلاعات متغییر انجام شود.
مشکل اینجا است که از نظر مدیریت، ما موظف به رفع تمامی اشکالات نرم‌افزاری هستیم و نباید خدای نکرده حتی یک باگ کوچک نیز پس از اتمام کار ما که وظیفه آزمايش نرم‌افزار را داریم، باقی بماند. مدیران ارشد فکر می‌کنند که آزمايش کار آسانی است و هر کس می‌تواند نرم‌افزار را آزمايش کند حتی اپراتورهای مبتدی. از طرف دیگر جالب است که گروهي از برنامه‌نویسان می‌گویند، ما Unit Test را در هر ماجول انجام داده‌ایم و محال است که برنامه ما با اشکالی مواجه شود. به نظر من هر دوی این گروه اشتباه می‌کنند.
دیدگاه‌های مختلفی از آزمايش نرم‌افزار وجود دارد. گروهی اعتقاد دارند، آزمايش نرم‌افزار به این دليل نیست که چیزی را اثبات کنیم، بلکه هدفش این است که کار نکردن نرم‌افزار مطابق انتظار کاربر را کم کنیم. گروهی نیز اعتقاد دارند که آزمايش نرم‌افزار فقط به این دليل است که نشان دهيم نرم‌افزار کار می‌کند یا نه و حتی برخی اعتقاد دارند که بین آزمايش و دیباگ کردن تفاوت زيادي وجود ندارد.
آزمايش، در واقع هر فعالیتی است که برای ارزیابی کارکرد نرم‌افزار و تطابق خروجی نرم‌افزار با نیازهای اولیه کاربران آن نرم‌افزار است. اما سؤال اين است که از کجا بفهمیم که واقعاً سیستم همان‌گونه که باید کار می کند و نیازهای مورد نظر کاربر را تأمین می‌کند؟ مجموعه‌ای از ابزار، تکنیک‌ها و مستندات که آزمايش کننده‌های سیستم‌های نرم‌افزاری از آن استفاده می‌کنند و به Test Oracle مشهور است می‌تواند به این کار کمک کند. اما به راستی آزمايش نرم‌افزار چه فایده‌ای دارد؟ در جواب این سؤال می‌توان گفت، علاوه بر این‌که آزمايش می‌تواند به ما این اطمینان را بدهد که نیازهای کاربران سیستم درباره این نرم‌افزار تأمین شده‌است می‌توان از تکنیک‌های آزمايش برای رسیدن به کیفیت مطلوب نرم‌افزار نیز بهره برد و در مدیریت ریسک نرم‌افزار از آن بهره جست.
ریسک‌هایي مانند کیفیت، بودجه، زمان‌بندی و قابلیت‌ها، ریسک‌هایی هستند که اگر به آن‌ها توجه نشود حتماً باعث خواهند شد، پروژه شکست بخورد. تأثیر هر یک از این ریسک‌ها بر دیگر ریسک‌ها زیاد است. یکی از این ریسک‌ها کیفیت نرم‌افزار است که می‌توان با استفاده از آزمايش کردن نرم‌افزار آن را به حداقل رساند. در نتیجه ریسک شکست پروژه را در مجموع پایین آوریم.
پس می‌توانیم تعریفی از گروه آزمايش آن هم از نوع واقع‌گرایانه یا Pragmatic داشته باشیم:
گروه آزمايش گروهی هستند که به صورت مؤثر، مقرون به صرفه، صحیح، با برنامه زمان بندی مشخص سرویس آزمايش و اطلاعات کیفیتی نرم‌افزار را در اختیار گروه پروژه قرار می‌دهند که با استفاده از آن اطلاعات می‌توان کیفیت سیستم و طبعاً ریسک پروژه را پایین آورد.
نکته قابل توجه این است که معنی کیفیت نیز توسط تیم آزمايش باید برای تیم پروژه و مدیریت مشخص باشد. زیرا اگر تعریف آن مشخص نباشد نمی‌توان پارامترهایی را که باعث افزایش یا کاهش آن می‌شوند شناسايی کرد.
به‌طورکلی می‌توان کیفیت را این‌گونه تعریف کرد:
مناسب استفاده، قابلیت‌ها توسط کاربران رضایت‌بخش باشد، کمبود و اشکال نداشته باشد که باعث شود مشتری از محصول ناراضي باشد و شکایت کند. به نظر من این تعریف از همه تعاریف برای هدف آزمايش مناسب‌تر است.
اغلب توصیه شده است که به گروه آزمايش اجازه بدهیم فعالیت‌هایي را که حتی فکر می‌کنند ممکن است مورد نظر مشتری نباشد یا ممکن است اشکالی داشته باشد، باگ خطاب کنند. این دیدگاه باعث می‌شود کیفیت نرم‌افزار که دلیل عمده آزمايش نرم‌افزار است هیچ‌گاه در خطر نيفتد و همیشه در سطح بالايی باقي‌بماند.
امين صفايي
ماهنامه شبکه
شاید جالب باشد که بگویم آزمايش نرم‌افزار این نیست که ثابت کند نرم‌افزار هیچ‌گونه باگی ندارد یا این‌که نرم‌افزار فاقد هرگونه اشکال است. این اهداف برای گروه آزمايش نرم‌افزار تقریباً بعید است. به نظر شما چرا این‌گونه است؟ تصور کنید سیستمی که یک کار بزرگی انجام می دهد مثلاً در یک محیط دانشگاهی محاسبات علمی انجام می‌دهد یا این‌که در کارخانه‌ای سیستم‌های فنی آن را تنظیم می‌کند؛ حاوی چندین هزار عملیات کاربردی است که ممکن است در طول کار با سیستم نرم‌افزاری از هر زیر سیستم چند دفعه خاص و آن نیز با ورودی اطلاعات متغییر انجام شود.
مشکل اینجا است که از نظر مدیریت، ما موظف به رفع تمامی اشکالات نرم‌افزاری هستیم و نباید خدای نکرده حتی یک باگ کوچک نیز پس از اتمام کار ما که وظیفه آزمايش نرم‌افزار را داریم، باقی بماند. مدیران ارشد فکر می‌کنند که آزمايش کار آسانی است و هر کس می‌تواند نرم‌افزار را آزمايش کند حتی اپراتورهای مبتدی. از طرف دیگر جالب است که گروهي از برنامه‌نویسان می‌گویند، ما Unit Test را در هر ماجول انجام داده‌ایم و محال است که برنامه ما با اشکالی مواجه شود. به نظر من هر دوی این گروه اشتباه می‌کنند.
دیدگاه‌های مختلفی از آزمايش نرم‌افزار وجود دارد. گروهی اعتقاد دارند، آزمايش نرم‌افزار به این دليل نیست که چیزی را اثبات کنیم، بلکه هدفش این است که کار نکردن نرم‌افزار مطابق انتظار کاربر را کم کنیم. گروهی نیز اعتقاد دارند که آزمايش نرم‌افزار فقط به این دليل است که نشان دهيم نرم‌افزار کار می‌کند یا نه و حتی برخی اعتقاد دارند که بین آزمايش و دیباگ کردن تفاوت زيادي وجود ندارد.
آزمايش، در واقع هر فعالیتی است که برای ارزیابی کارکرد نرم‌افزار و تطابق خروجی نرم‌افزار با نیازهای اولیه کاربران آن نرم‌افزار است. اما سؤال اين است که از کجا بفهمیم که واقعاً سیستم همان‌گونه که باید کار می کند و نیازهای مورد نظر کاربر را تأمین می‌کند؟ مجموعه‌ای از ابزار، تکنیک‌ها و مستندات که آزمايش کننده‌های سیستم‌های نرم‌افزاری از آن استفاده می‌کنند و به Test Oracle مشهور است می‌تواند به این کار کمک کند. اما به راستی آزمايش نرم‌افزار چه فایده‌ای دارد؟ در جواب این سؤال می‌توان گفت، علاوه بر این‌که آزمايش می‌تواند به ما این اطمینان را بدهد که نیازهای کاربران سیستم درباره این نرم‌افزار تأمین شده‌است می‌توان از تکنیک‌های آزمايش برای رسیدن به کیفیت مطلوب نرم‌افزار نیز بهره برد و در مدیریت ریسک نرم‌افزار از آن بهره جست.
ریسک‌هایي مانند کیفیت، بودجه، زمان‌بندی و قابلیت‌ها، ریسک‌هایی هستند که اگر به آن‌ها توجه نشود حتماً باعث خواهند شد، پروژه شکست بخورد. تأثیر هر یک از این ریسک‌ها بر دیگر ریسک‌ها زیاد است. یکی از این ریسک‌ها کیفیت نرم‌افزار است که می‌توان با استفاده از آزمايش کردن نرم‌افزار آن را به حداقل رساند. در نتیجه ریسک شکست پروژه را در مجموع پایین آوریم.
پس می‌توانیم تعریفی از گروه آزمايش آن هم از نوع واقع‌گرایانه یا Pragmatic داشته باشیم:
گروه آزمايش گروهی هستند که به صورت مؤثر، مقرون به صرفه، صحیح، با برنامه زمان بندی مشخص سرویس آزمايش و اطلاعات کیفیتی نرم‌افزار را در اختیار گروه پروژه قرار می‌دهند که با استفاده از آن اطلاعات می‌توان کیفیت سیستم و طبعاً ریسک پروژه را پایین آورد.
نکته قابل توجه این است که معنی کیفیت نیز توسط تیم آزمايش باید برای تیم پروژه و مدیریت مشخص باشد. زیرا اگر تعریف آن مشخص نباشد نمی‌توان پارامترهایی را که باعث افزایش یا کاهش آن می‌شوند شناسايی کرد.
به‌طورکلی می‌توان کیفیت را این‌گونه تعریف کرد:
مناسب استفاده، قابلیت‌ها توسط کاربران رضایت‌بخش باشد، کمبود و اشکال نداشته باشد که باعث شود مشتری از محصول ناراضي باشد و شکایت کند. به نظر من این تعریف از همه تعاریف برای هدف آزمايش مناسب‌تر است.
اغلب توصیه شده است که به گروه آزمايش اجازه بدهیم فعالیت‌هایي را که حتی فکر می‌کنند ممکن است مورد نظر مشتری نباشد یا ممکن است اشکالی داشته باشد، باگ خطاب کنند. این دیدگاه باعث می‌شود کیفیت نرم‌افزار که دلیل عمده آزمايش نرم‌افزار است هیچ‌گاه در خطر نيفتد و همیشه در سطح بالايی باقي‌بماند.
امين صفايي
ماهنامه شبکه