در این مقاله، میخواهیم درباره ی تست نرم‌افزار صحبت کنیم. احتمالا حتی اگر کسی که در زمینه‌های کامپیوتری کار نمی‌کند و در این زمینه، دانش خاصی ندارد هم موضوع بحث ما را بشنود،میتواند حدس بزند که ما میخواهیم درباره ی چه چیزی صحبت کنیم؟! بله؛ ما میخواهیم بررسی کنیم که با استفاده از چه راههایی میتوانیم مطمئن شویم که برنامه ی ما اولا؛ از نظر منطقی درست کار می کند و دوما؛ تمام قابلیت هایی که بخاطر آنها طراحی شده است را میتواند پشتیبانی کند. اما این مسئله، شاید فقط از دور اینقدر زیبا و منطقی به نظر بیاید و بعد از اینکه کمی وارد دنیای برنامه‌نویسی شدیم و روی توسعه ی نرم افزارهای مختلف تمرکز کردیم، متوجه شویم که نقاط مبهم زیادی درباره ی تست نرم‌افزار وجود دارد. در این سری مقاله سعی میکنیم، آن نقاط مبهم را بشناسیم و آنها را رفع کنیم.
همانطور که در مقدمه گفتیم؛ تست نرم‌افزار، از دور خیلی مقوله‌ی منطقی و خوب و ضروری ای به نظر میرسد. اما اگر فردی که تازه وارد دنیای نرم‌افزارهای کامپیوتری شده است، شروع به برنامه‌نویسی و توسعه نرم‌افزارهای کوچک یا بزرگ در قالب گروههای فردی یا کوچک کند؛ ممکن است در مواجهه با تست نرم افزار به این موضوع فکر کند که چرا باید نرم‌افزاری که در حین توسعه، بارها و بارها اجرا شده و ایرادات و خطاهای آن رفع شده را دوباره تست کنند؟ چرا این تست را در مواردی با کد های مخصوص و به صورت اتوماتیک انجام می دهند؟ چرا در شرکت های بزرگ، اصولا یک فرد یا یک گروه را استخدام میکنند که فقط خطاها و ایرادات برنامه را بگیرند؟ آیا این کار برای به چالش کشیدن توانایی های فرد برنامه‌نویس است یا خیر؟! برای رسیدن به پاسخ این سوالات، پیشنهاد می‌کنم تا انتهای این مقاله صبر کنید.
تست نرم‌افزار شامل مجموعه عملیات‌هایی است که انجام می‌شود تا به ما این اطمینان را بدهد که اولا؛ برنامه ی توسعه داده شده،از نظر منطقی و عملکردی درست کار میکند و دوما؛ این نرم‌افزار ،تمام قابلیت‌هایی که کارفرما یا ذی‌نفعان نرم‌افزار از آن میخواهند را برآورده میکند. به عبارت دیگر،نرم‌افزار ایجاد شده دقیقا همان چیزی است که آن ها میخواهند. این عملیات ها ممکن است شامل یکسری کدهای تست خودکار باشد که در کنار کد اصلی برنامه توسعه داده می‌شود و برای توسعه ی آنها باید از فریم ورک های مخصوص استفاده کنیم. یا حتی ممکن است شامل یکسری فرآیند جانبی باشد؛ برای مثال در مراحلی از تست، فرد یا افرادی مامور میشوند که خود را به جای کاربر بگذارند و به جای او، با نرم‌افزار شما کار کنند و ایراداتی که می‌بینند را گزارش کنند تا در مراحل بعدی توسعه آنها را بهتر کنید.
حتما شنیده اید که میگویند، بهترین دوست هرکس، کسی است که عیب هایش را به او هدیه بدهد. در بحث تست نرم‌افزار هم، یک قانون طلایی وجود دارد که براساس همین مفهوم ایجاد شده است و باعث می شود اهمیت تست نرم‌افزار را بهتر درک کنیم. این قانون می گوید که : (اگر تیم توسعه ی یک نرم‌افزار، خطاهای برنامه را پیدا نکنند؛ قطعا مشتری آن را پیدا میکند و آن زمان، دیگر برای جلوگیری از عواقب خیلی بد فاش‌شدن آن خطا، خیلی دیر است!)
وقتی خطایی در برنامه وجود داشته باشد و تیم توسعه نتوانند تا قبل از انتشار محصول نرم‌افزاری به آن پی ببرند و این خطا، توسط کاربر نرم افزار کشف شود؛ اتفاقی که می افتد این است که احتمالا آن کاربر مشخص، دیگر نمیتواند به نرم‌افزار شما اعتماد کند و اگر بتواند، برای اپلیکیشن شما جایگزینی پیدا کند یا حتی کارش را بدون برنامه ی شما انجام دهد؛ احتمالا نه تنها نرم‌افزار شما را برای همیشه از روی دستگاه خود پاک میکند، بلکه ممکن است تا جاییکه بتواند به اطرافیان نیز توصیه کند که از نرم‌افزار شما استفاده نکنند و به جای آن، از راههای جایگزینی که وجود دارد استفاده کنند. و به این ترتیب، شما بدون آنکه متوجه شوید دقیقا چه اتفاقی افتاده است، تعدادی از کاربران خود را از دست داده اید و مقدار زیادی تبلیغات منفی یا بی‌اعتمادی را برای شرکت خود خریده اید که قطعا در طولانی مدت، روی وضعیت اقتصادی و اعتبار شرکت شما، بی تاثیر نخواهد بود.
خطاهایی که به وسیله ی استراتژی های تست، سعی میکنیم آنها را کشف کنیم،به دو دسته ی کلی تقسیم می شوند:
1- خطاهایی که ممکن است در هنگام توسعه‌ی نرم‌افزار، به طور ناخواسته و به دلیل اشتباه برنامه‌نویس رخ داده باشد که قاعدتا خطاهایی هستند که تیم توسعه‌دهنده، از وجودشان اطلاعی ندارد که بتواند آن ها را برطرف کند.(چون اگر اطلاع پیدا می‌کرد، قاعدتا آن را تا قبل از انتشار نسخه‌ی نهایی نرم‌افزار رفع کرده بود و اکنون مشکلی وجود نداشت.)
2- خطاهایی که به رفتار کاربر در نرم‌افزار مربوط می‌شود. برای مثال، در جاهایی که کاربر باید ورودی خاصی وارد کند، ممکن است به هر دلیلی نتواند ورودی را با فرمتی که برنامه نویس انتظار داشته و روند برنامه را با توجه به آن چیده است وارد کند و در نتیجه روند برنامه مختلط شود.
برای هر پروژه نرم افزاری ، قاعدتا با توجه به تفاوت در پست های افراد، نگرش های متفاوتی نسبت به تست وجود دارد که عملیات تست کردن را تحت تاثیر قرار می دهد. به طور کلی دو گروه اصلی وظیفه دارند کل فرآیند تست را انجام دهند : توسعه‌دهندگان و گروه تست نرم‌افزار.
1- توسعه‌دهندگان سیستم
قاعدتا معقول‌ترین انتخاب این است که برای تست یک نرم‌افزار، در ابتدا به سراغ توسعه دهندگان آن برویم؛ چراکه توسعه‌دهندگان یک نرم‌افزار، بهترین افرادی هستند که ساختار آن را کاملا می‌شناسند و می‌توانند ایرادات موجود در آن را رفع کنند.
اما چالشی که در این مرحله وجود دارد این است که اگر از افرادی که نرم‌افزار را توسعه داده‌اند، خواسته شود که یک دور دیگر کل نرم‌افزار را تست کنند؛ طبیعتا خواهند گفت که اطمینان دارند که برنامه‌ای که ساخته اند بی‌نقص بوده و کاملا طبق نیاز مشتری و چیزی که با توجه به برنامه و بودجه‌ی پروژه از آنها خواسته شده است، کار میکند. البته این نوع نگاه، از نظر روانشناسی کاملا طبیعی است. چراکه توسعه دهندگان هر سیستمی، در زمان توسعه، مستندسازی و ساخت یک برنامه، هیچوقت از عمد کاری انجام نمی دهند که برنامه ایرادی پیدا کند. همچنین در حین توسعه هم قدم‌به‌قدم برنامه را تست می کنند و تا جایی که امکان دارد، از درست بودن عملکرد آن اطمینان پیدا می کنند. اما واقعیت این است که حتی با بالاترین دقت ها هم، تقریبا همواره تعدادی خطا کشف نشده باقی می‌مانند. پس حتی اگر خطایی هم باقی مانده باشد، حتما خطایی بوده است که برنامه‌نویس نتوانسته‌است آن را پیدا و رفع کند و به همین دلیل، تیم مدیریت پروژه نباید اهمیت تست نرم‌افزار را نادیده بگیرد و صرف تایید توسعه‌دهندگانِ خود و پایان یافتن فرآیند توسعه‌ی نرم‌افزار، برنامه را کاملا درست و بدون خطا در نظر بگیرد و از تست دوباره ی نرم‌افزار چشم‌پوشی کند. چرا که طبق قانون طلایی تست نرم‌افزار که در بخش قبل به آن اشاره کردیم؛ در صورتیکه خطایی وجود داشته باشد که توسط تیم سازنده‌ی برنامه کشف نشده باشد، مشتری آن را کشف می کند و در آن صورت، اعتبار شرکت زیر سوال خواهد رفت.
2- تیم مستقل تست نرم‌افزار
در کنار توسعه دهندگان، گروهی هم هستند که اصولا برای این استخدام میشوند که خطاهای برنامه را پیدا کنند. این گروه که اختصارا آنها را ITG(Independent Test Group) می گویند، وظیفه دارند خطاهایی را که توسط برنامه نویس حل نشده اند را پیدا کرده و آنها را گزارش کنند. البته قاعدتا اینطور نیست که جریان برنامه بعد از گزارش شدن خطاها و مشکلات توسط گروه ITG رها شود! بلکه تیم آزمایشگر باید به طور مداوم با تیم توسعه‌دهنده در تعامل باشند و مشکلات را گزارش کنند تا تیم توسعه بتوانند آنها را رفع کنند.
سه تصور غلط در زمینه‌ی تست‌کردن وجود دارد که به‌دلیل تفاوت در دیدگاه افرادیکه در تیم توسعه‌ی نرم‌افزار نقش‌های متفاوتی دارند، ایجاد شده است. در این بخش میخواهیم این سه دیدگاه غلط را بشناسیم و آنها را اصلاح کنیم:
1- وظیفه ی برنامه نویس، تنها توسعه ی نرم افزار است و نیاز نیست هیچ تستی بنویسد.
--> همانطور که در بخش‌های قبل نیز به آن اشاره شد، بخش مهمی از مراحل تست برنامه برعهده ی برنامه‌نویس‌ها است و توسعه دهنده های هر نرم‌افزار باید بخش زیادی از تست ها (بخصوص تست هایی که برای اعتبار سنجی شرایط حساس در جریان اجرای برنامه یا شرط های مرزی حلقه ها و دستورهای کنترلی و یا رفتار کاربر می شود) را درحین توسعه، پیاده سازی کنند.
2- زمانی که برنامه در حال تست توسط یک آزمایشگر خارج از تیم توسعه است، حتما باید به دلایلی شکست بخورد.
--> در مواقعیکه کار تحلیل نرم‌افزار خیلی دقیق و منظم پیش برود و برنامه چندبار مورد تست قرار بگیرد، ممکن است دیگر در نرم‌افزار خطا یا ایراد خاصی وجود نداشته باشد. این دیدگاه که تیم تست نرم‌افزار حتما باید یک یا چند ایراد پیدا کند وگرنه انگار کار خود را به خوبی و درست انجام نداده است،کاملا غلط می باشد و مبنای دقیقی ندارد.
3- افراد مسئول تست برنامه، تنها زمانی به پروژه اضافه می شوند که پروژه تکمیل شده است. و در حین توسعه هیچ تستی انجام نمی شود.
--> اگر بعد از گذراندن زمان نسبتا زیادی که برای توسعه‌ی نرم‌افزار مورد نظرمان صرف شده است، آن را به دست تیم تست‌کننده‌ی نرم‌افزار بسپاریم؛ باعث می‌شود زمان تحویل و انتشار فایل نهایی پروژه به شدت طولانی تر شود. چراکه بعد از تحلیل نرم‌افزار و گزارش‌شدن خطاها، این ایرادات باید دوباره به سمت تیم توسعه‌دهنده برگردد تا اصلاح شود. و دوباره مدت طولانی ای طول می کشد تا نسخه ی بعدی نرم افزار آماده و برای بررسی مجدد تیم تست ارسال شود. در نتیجه انتشار برنامه مدت زیادی عقب می افتد. در صورتیکه برای انجام خیلی از تست ها، هیچ ضرورتی وجود ندارد که تا توسعه ی کامل برنامه منتظر بمانیم و میتوان همزمان با کار تیم توسعه، مراحل تست را هم انجام داد و در زمان صرفه جویی کرد.
یکی از سوالات رایجی که در هنگام تست نرم‌افزار پرسیده می شود، این است که از کجا بفهمیم که تست به خوبی انجام شده است؟ یا از کجا بفهمیم که تست کردن برنامه کافیست و دیگر نیازی به انجام تست های بیشتر نیست؟
متاسفانه جواب مشخص و از پیش تعیین شده‌ای برای این سوال وجود ندارد. اما چند پاسخ عملی که حاصل تجربه های عملی تست‌کننده‌ها است وجود دارد که می توانند برای پیدا کردن پاسخ به شما کمک کنند:
- به عنوان اولین پاسخ، باید بگوییم که : شما هیچوقت نمیتوانید ادعا کنید که عملیات تست کردن کامل انجام شده است! چراکه حتی اگر از درست‌بودن عملکرد بخش‌های مختلف برنامه مطمئن باشید، بازهم هر باری که کاربر برنامه را اجرا می کند، میتوانیم بگوییم که برنامه ی شما در حال آزمایش است و هرلحظه ممکن است به هر دلیلی در روند اجرای آن خطا رخ دهد! این حقیقت تلخ، در واقع اهمیت این موضوع را میرساند که شما باید تا جای ممکن تضمین کنید که با احتمال بالایی هیچ خطای غیرمنتظره و بررسی‌نشده ای رخ نمی‌دهد تا کمترین احتمال برای پیدا شدن خطاهای جدید باقی بماند.
- پاسخ دیگری که در این باره وجود دارد و تاحدودی بی رحمانه اما در عین حال منطقی است، این است که: هر زمانی که قراردادی که برای پشتیبانی نرم افزار بسته اید به پایان رسید یا از شرکت مورد نظر استعفا دادید و یا کارفرما آنقدر دچار محدودیت شد که درخواست پشتیبانی نرم‌افزار را لغو کرد، کار شما به عنوان تست‌کننده تمام می شود. البته در این صورت، باز هم این مراحل فقط برای شما تمام می‌شود نه برای صاحبین نرم‌افزار!
Source : Roger S. Pressman, Bruce R. Maxim. "Software Engineering A Practtitioner's Approach" - 9th Edition
در مقاله ی بعدی، به معرفی مراحل تست نرم‌افزار که ارتباط تنگاتنگی با مراحل مختلف طراحی نرم‌افزار دارند، می‌پردازیم. با من همراه باشید.
