تست کیس و تست سناریو چیست؟

در این مقاله سعی شده درباره ی مفاهیم و نوشتن تست کیس (test case) و تست سناریو (test scenario) ، ویژگی ها و چالش های آن به زبان ساده بحث شود.

تست سناریو چیست؟

قبل از تعریف تست کیس ، نیاز هست با مفهوم تست سناریو و تفاوتش با تست کیس آشنا شویم. تست سناریو یک توضیح کوتاه و کلی در مورد این است که چه کاری باید انجام بگیرید و تمرکزش بر روی فانکشنالیتی یک اپلیکشن است.

برای مثال، یک سامانه را که از قسمت های مختلف مانند صفحه ی لاگین، صفحه ی HomePage، نوار جستجو و.... تشکیل شده است را درنظر بگیرید. تستر باید طبق نیازمندی های نرم افزار فرایند لاگین کردن را تست کند. برای اینکار باید یک سناریو طراحی کند. مانند:
بررسی فرآیند لاگین با ورودی های معتبر

این توضیح مختصر و کوتاه یک سناریو نامیده می‌شود. درواقع تستر با یک نگاه به این متن، متوجه میشود که چکاری باید انجام دهد و کدام فانکشنالیتی را باید بررسی کند. اما چگونه؟! برای جواب دادن به این سوال باید به تست کیس مراجعه کند.
تست سناریو در اصطلاح یک High-Level-Documentation است و در آن صحبتی از جزییات کار، صورت نمی‌گیرد. این جزییات بصورت step by step در تست کیس پیاده می‌شود
برای مثال قبل Test Case به این صورت نوشته می‌شود:

1. وارد وبسایت شوید.
2. ایمیل و پسورد معتبر را در فیلد‌های مشخص شده وارد کنید.
3. روی دکمه‌ی ورود کلیک کنید ..

در Test Case چگونگی انجام کار و همچنین جزییات بصورت دقیق مشخص می‌شود.

ممکن است برای یک سناریو، چندین Test Case در نظر گرفته شود.
برای مثال:

سناریو: بررسی فرایند پرداخت یک محصول

1. testCase - پرداخت با کارت بانکی
2. testCase- پرداخت با اعتبار

برای مشخص شدن تفاوت های test case و test scenario به جدول زیر توجه کنید.

تست کیس چیست؟

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

نوشتن تست کیس چه کمکی می‌کند؟

فرض می‌کنیم تست کیس مستند شده نداریم، در این صورت چه اتفاقی می‌افتد؟

• اگر در طول توسعه ی نرم فزار، تست کیس document شده نداشته باشیم. در این صورت اجرای مورد تست ها، وابسته به افرادی می‌شود که آن ها را اجرا می‌کنند.فرض کنید در تست رگریشن (regression) قبل از release، مهندس تست شما، ۲۰۰ test case را اجرا می‌کند. برای نسخه ی بعدی نرم افزار، که همراه با تغییرات ( مانند اضافه کردن فیچر جدید، اصلاح کد و یا ....) است، تستر ممکن است ۱۵۰ test case را قبل از نسخه دهی اجرا کند. مهندس تست باید این را در نظر داشته باشد که تست های قبلی در نسخه ی قبلی را هم اجرا کند.( فرض می‌کنیم فیچر های نسخه ی قبلی حذف نشده اند). با عدم وجود تست کیس مستند، تستر طبقه بندی درستی نسبت به اجرای تست‌کیس ها ندارد.در واقع همه ی این سناریو ها وابسته به حافظه و ذهن تستر دارد و اگر این تستر از شرکت خارج شود و مهندس جدیدی جایگزین شود، شرکت با مشکل جدی در اجرای تست‌کیس ها مواجه می‌شود. چراکه تستر جدید هیج دانشی نسبت به تست‌کیس های اجرا شده ندارد.
• مشکل بعدی در زمینه ی کیفیت کد بروز می‌کند. عدم وجود تست کیس ، کیفیت تست ها را تحت تاثیر قرار می‌دهد. منظور از کیفیت ، پوشش تست (Test Coverage) است. بدون وجود تست‌کیس، قطعا پوشش تست خوب هم درکار نخواهد بود. چرا که مشخص نیست کدام نواحی و فانکشنالیتی های اپلیکیشن و همچنین تمامی سناریوهای رایج برای یک فیچر، در تست ها پوشش داده شده است یا خیر.
• ممکن است تستر برخی از فیچر ها و فانکشنالیتی ها را فراموش کند، و از یاد ببرد.
• اجرای تست های تکراری
• عدم وجود تست کیس استاندارد، منجر به عدم اعتماد به تستر می‌شود. برای مثال فرض کنید شما قبل از نسخه دهی،تمامی فیچر ها و فانکشنالیتی ها را تست و بررسی می‌کنید. بعد از pass شدن همه ی تست ها و حل کردن مشکلات، نسخه را تحویل کارفرما می‌دهید. بعد از مدتی یک باگ یا نقص در قسمتی از اپلیکیشن مشاهده می‌شود. اگر شما تست‌کیس استاندارد نداشته باشید، نمی‌توانید به کارفرما یا ذینفعان پروژه ثابت کنید که فیچر مورد بحث، در مراحل تست، با سناریوهای مشخص،مورد تایید و بررسی قرار گرفته است.

بطور خلاصه میتوان گفت عدم مستند کردن test case ها منجر به عدم ثبات در اجرای آن‌ها، عدم Test Coverage مناسب و همچنین وابستگی به فرد یا افراد مشخص، می‌شود. درنتیجه نوشتن تست کیس از اهمیت ویژه ای برخوردار است.

ویژگی های Test case

این ویژگی ها عبارتند از:

• اولین و مهم ترین ویژگی تست کیس خوب، داشتن Test Coverage خوب است. زمانی که Test Coverage مناسب باشد، کیفیت تست هم افزایش میابد. منظور از پوشش تست، پوشش تمامی سناریو های مثبت و منفی ممکن، در قسمت های مختلف اپلیکیشن( شامل ماژول ها، فیچرها و فانکشنالیتی ها) است. با این کار احتمال یافتن باگ افزایش پیدا می‌کند. هدف مهندسین تست یافتن باگ است، بنابراین اگر پوشش تست، مناسب نباشد، از این هدف دور می‌شوند.برای مثال فرض کنید شما برای اپلیکیشن خود 200 تست‌کیس طراحی کردید، اما پوشش تست شما 50% است. اگر test case شما به درستی طراحی شده باشد، ممکن است با اضافه کردن یک test case، پوشش تست شما افزایش پیدا کند و برای مثال به ۸۰٪ برسید. در نتیجه در این قسمت طراحی test case از اهمیت ویژه ای برخوردار است.
• اگر تست کیس به درستی مستند شده باشد، هنگامی که یک نیروی جدید تست وارد شرکت می‌شود، با مطالعه ی Test Case Document متوجه عملکرد سامانه و همچنین به درک مناسبی از آن دست پیدا خواهد کرد
• تست کیس باید جوری طراحی شده باشد که قابلیت کشف خطا را داشته باشد
• در ابتدا سناریو های مثبت و سپس سناریو های منفی طراحی شوند (Negative)
• تکراری(Duplicate) نباشد
• تست کیس باید جوری باشد که بتوان هم بصورت دستی و اتوماتیک پیاده کرد. در واقع اگر تست‌کیس ها برای تست دستی (manual) طراحی شده است، تبدیل آن به تست اتوماتیک ساده باشد.
• از تکنیک های Test Case Design استفاده شده باشد.