طراحی نرم افزار بدون رعایت اصول مهندسی نرم افزار همانند ساخت خانه بدون نقشه استاندارد و مهندسی شده است! متاسفانه در بسیاری از شرکت‌های تولید کننده نرم افزار جهت تولید محصولات نرم افزاری اصول مهندسی را رعایت نمی‌کنند و یا تعدادی از مراحل مخصوصا، مرحله تست را از چرخه تولید نرم افزار خارج می‌کنند. این امر باعث کاهش قیمت تولیدی نرم افزار می‌شود اما هزینه پشتیبانی و نگهداری آن را چندین برابر می‌کند. چرا که بسیاری از ایرادهای برنامه در مرحله تست برطرف نمی‌شوند.
مهندس نرم افزار پیش از اعمال روش‌ها در خصوص موارد تست، بایستی اصول اساسی که تست نرم افزار را هدایت می‌کند، درک کند. مجموعه‌ای از این اصول عبارتند از:
1) تست با توجه به نیازمندی‌های کاربر: همان‌طور که می‌دانید شناسایی نیازمندی‌های کاربر اولین گام چرخه تولید نرم افزار می‌باشد. این نیازها طی یک کار تیمی و روش‌های متفاوت با مشارکت مشتریان یا کاربران و توسعه دهندگان شناسایی می‌شوند. سپس نیازهای عمومی، ضروری، اولویت بالا و حداقل نیازها مشخص می‌گردد. پس از شناخت نیازمندی‌ها، تست‌ها بایستی تاحد خواسته‌های مشتری قابل ردیابی باشند.
2) برنامه ریزی قبل از اجرا: پس از شناخت نیازمندی‌ها و مشخص کردن آنها، برای هر بخش نوشتن برنامه تست (test plan) ضروری است. همه تست‌ها را می‌توان پیش از تولید هرگونه کد، برنامه ریزی و طراحی کرد.
3) قانون پارتو: این قانون بدین معنا است که در هرچیزی، میزان اندکی (۲۰ درصد) دارای اهمیت حیاتی و بسیاری (۸۰ درصد) کم اهمیت و یا دارای اهمیت ناچیز است. مدیران پروژه‌ها می‌دانند که ۲۰ درصد کار(اولین ۱۰ درصد و آخرین ۱۰ درصد) ۸۰ درصد زمان و منابع را مصرف می‌کند بنابراین با تمرکز برآن ۲۰ درصد، ۸۰ درصد نتایج را می‌توان تولید کرد. تست هم از این قاعده مستثنی نیست! یعنی ۸۰ درصد خطاهای کشف نشده در ۲۰ درصد کد است. یا به عبارتی ۲۰ درصد نواقص باعث ۸۰ درصد مشکلات می‌شوند. این اصل به عنوان یک یادآوری روزانه می‌تواند درخدمت ما باشد و به ما بگوید که زمان و انرژی خود را بر آنچه که واقعا مهم است، متمرکز کنیم.
4) شروع تست از اجزای کوچک: تست باید از اجزای کوچک شروع شده و به ابعاد بزرگتر گسترش یابد. اولین تست‌ها بر روی هر یک از مولفه‌ها انجام می‌شوند. با پیشرفت تست، خطاهای مجموعه‌ای از مولفه‌های مجتمع و سپس کل برنامه یافت می‌شود.
5) تست کامل (exhaustive) ممکن نیست: تعداد مسیرهای ممکن برای تست برنامه زیاد است. لذا اجرای هر ترکیبی از مسیرها امکان پذیر نیست. ولی این امکان وجود دارد که برنامه را در حد کفایت پوشش دهیم. غیرممکن است که بتوان یک برنامه را به طور کامل تست کرد.
رعایت اصول تست نرم افزار باعث افزایش زمان تولید و بهره مندی از متخصصین مرتبط در آن زمینه و افزایش هزینه تولید نرم افزار می‌شود اما با در نظر گرفتن کاهش چشمگیر هزینه‌های پشتیبانی و توسعه، نرم افزار تولید شده بسیار مقرون به صرفه تر خواهد بود.
6) انجام تست توسط شخص ثالث بی‌طرف: برای موثر بودن بایستی تست توسط شخص ثالث بی‌طرف انجام شود. منظور از موثربودن این است که خطاها را با احتمال بیشتری پیدا کنیم. به دلایلی که در بخش‌های بعدی ذکر می‌کنیم، مهندس نرم‌افزاری که سیستم را برنامه نویسی کرده است، بهترین کسی نیست که باید همه تست‌ها را انجام دهد. بنابراین برنامه نویس بایستی از تست‌های مختلف برنامه خود اجتناب کند.
7) تست‌های اولیه و متناوب: تست در همان ابتدای کار آغاز شده و در طول چرخه حیات نرم‌افزار ادامه یافته و به صورت متناوب تکرار می‌شود. تست‌های اولیه کمک می‌کنند تا در مراحل اولیه از فرآیند توسعه نرم‌افزار، خطاها تشخیص داده شده و تصحیح آنها به سادگی انجام شود. این تست‌ها باعث کاهش هزینه می‌گردند. این نکته قابل ذکر است که تکرار تست و تناوب آن در طول تولید برنامه بایستی گسترش پیدا کند.
8) انبوهی از خطاها: در پروژه‌های تست، خطاها توزیع نمی‌شوند! در جایی از برنامه که خطا کشف می‌شود این احتمال که خطاهای بیشتری را بتوان پیدا کرد بیشتر است. احتمال اینکه اشکالات بیشتری در قسمتی از برنامه کشف شود متناسب با تعداد اشکالات کشف شده قبلی در آن بخش از برنامه است. به عبارت دیگر هر چه در ماژولی از برنامه خطاهای بیشتری پیدا کنید، احتمال وجود خطاهای دیگر در آن ماژول بیشتر است.
9) ازبین رفتن ردپا: در طول زمان ردپای تست از بین می‌رود. به عبارتی برنامه پس از مدتی در برابر تست‌های تکراری مقاوم خواهد شد. اگر test case ها را فقط تکرار می‌کنید، آنها نمی‌توانند خطاهای جدید را کشف کنند. خطاها با بروز رسانی بخش‌هایی از برنامه و در توابع تست نشده کشف می‌شوند. به منظور جلوگیری از این اثر، test case ها بایستی در طول زمان به روز رسانی شوند.
10) وابستگی تست به محتوا: هیچ دو سیستمی یکسان نیستند که شما بتوانید یک تست را به یک شیوه برای هردوی آنها اجرا کنید. تعریف معیارهای ورودی، خروجی و …. بایستی برای هر برنامه با توجه به محتوای تست تعریف شود. به طور مثال تست وب سایت‌ها بسیار متفاوت از تست سیستم‌های بانکی می‌باشد.
11) نتیجه گیری اشتباه: تست نمی‌تواند نشان دهد که اشکالی وجود ندارد، بلکه تنها قادر است نشان دهد که اشکال وجود دارد! حتی اگر هیچ خطایی کشف نکرده باشید دلیل بر این نمی‌شود که برنامه بدون اشکال می‌باشد. تست نمی تواند ثابت کند که برنامه عاری از خطا می‌باشد. برنامه‌ای که هیچ خطایی در آن کشف نشده دلیل براین نیست که کامل و بی‌نقص است. تشخیص خطا و اثبات و برطرف نمودن آن نمی‌تواند تضمین کند که سیستم قابل استفاده و مطابق انتظارات کاربران می‌باشد. یکپارچه سازی اولیه برنامه از خواسته‌های کاربران و شبیه‌سازی از سیستم می‌تواند مانع از نارضایتی مشتریان باشد.
12) تست شرایط خاص: به غیر از حالت‌های معمولی، شرایط خاص را تست کنید. همان‌طور که می‌دانید تست کامل غیرممکن است بنابراین تسترها بایستی تلاش کنند که در نقاط بحرانی و خطرات خاص تمرکز کرده و خطاهای احتمالی را کشف کنند.
13) هدف از تست نرم افزار یافتن خطا است، نه اطمینان از درستی کارکرد نرم افزار.
14) آزمایش موارد قابل انتظار در برنامه نیمی از ماجراست. نیم دیگر آزمایش مواردی است که انتظار می‌رود برنامه آن را انجام ندهد.
15) با فرض اینکه هیچ نقصی در برنامه نخواهید یافت تست را آغاز نکنید.
کیفیت هدف اصلی تمامی افراد، شرکت‌ها و به صورت کلی سازمان‌هایی است که در جهت تولید و توسعه نرم‌افزار قدم می‌گذارند. در واقع کیفیت نرم‌افزار یک اصل رقابتی در زمینه تولید یک محصول است و تست نرم افزار یکی از مهم ترین عوامل در کیفیت نرم افزار می باشد.
گرفته شده از Testology
