نوشتن تست کیس مهارتی پایه برای هر تستر نرمافزار و مهندس QA است. یک تستکیس خوب را هر عضو تیم میتواند بدون ابهام اجرا کند و به همان نتیجه برسد. این مقاله اجزای تستکیس، مراحل نوشتن، تکنیکهای طراحی و یک نمونه کامل را مرور میکند.
تستکیس چیست و چه تفاوتی با سناریوی تست دارد
تستکیس (Test Case) مجموعهای از پیششرطها، مراحل، دادهها و نتیجه مورد انتظار است. هدف آن بررسی یک رفتار مشخص از نرمافزار است. تستکیس پل بین نیازمندی و اجرای تست است.
سناریوی تست یک موقعیت کلی را توصیف میکند. مثلاً «کاربر با ایمیل و رمز عبور وارد سامانه میشود». از یک سناریو معمولاً چند تستکیس ساخته میشود:
- ورود با اطلاعات معتبر
- ورود با رمز عبور نادرست
- ورود با ایمیل ثبتنشده
- ورود با فیلدهای خالی
- قفل شدن حساب پس از چند تلاش ناموفق
| معیار | سناریوی تست | تستکیس |
|---|---|---|
| سطح جزئیات | کلی | دقیق و گامبهگام |
| پرسش اصلی | چه چیزی تست شود | چطور تست شود |
| داده تست | معمولاً ندارد | داده مشخص دارد |
| نتیجه مورد انتظار | کلی | دقیق و قابل سنجش |
| کاربرد | برنامهریزی و پوشش | اجرا و ثبت نتیجه |
اجزای یک تستکیس استاندارد
قالب تستکیس در تیمهای مختلف کمی فرق دارد. اما این اجزا تقریباً در همه قالبها دیده میشوند:
- شناسه: یک کد یکتا برای ارجاع؛ مثلاً TC-101.
- عنوان: یک جمله کوتاه که هدف تست را روشن میکند.
- نیازمندی مرتبط: شناسه نیازمندی یا داستان کاربری که این تست پوشش میدهد.
- پیششرط: وضعیتی که پیش از شروع باید برقرار باشد.
- داده تست: مقادیر مشخص ورودی.
- مراحل: گامهای شمارهدار و روشن.
- نتیجه مورد انتظار: رفتار دقیق و قابل سنجش سیستم.
- اولویت: اهمیت تست برای انتخاب در چرخههای کوتاه.
- نوع تست: مثلاً عملکردی، رگرسیون یا دود.
- پسشرط: وضعیتی که پس از اجرا باید برقرار باشد یا پاکسازی لازم.
عنوان خوب چه ویژگیای دارد
عنوان باید بدون خواندن مراحل، هدف تست را بگوید. یک الگوی ساده این است: «[قابلیت] – [شرط] – [نتیجه]». مثلاً «ورود – رمز عبور نادرست – نمایش پیام خطا». عنوانی مثل «تست ورود ۲» هیچ اطلاعاتی نمیدهد.
مراحل نوشتن تستکیس حرفهای
۱. نیازمندی را کامل بفهمید
پیش از نوشتن، نیازمندی و معیارهای پذیرش را بخوانید. هر ابهامی را با مدیر محصول یا تحلیلگر روشن کنید. تستکیسی که بر پایه فرض نادرست نوشته شود، باگ واقعی را پیدا نمیکند.
۲. سناریوها را فهرست کنید
برای هر نیازمندی، مسیرهای اصلی و فرعی را بنویسید. مسیر موفق، مسیرهای خطا و حالتهای مرزی را جدا کنید. این فهرست نقشه پوشش شماست.
۳. تکنیک طراحی مناسب را انتخاب کنید
بهجای نوشتن تست برای همه ورودیهای ممکن، از تکنیکهای طراحی تست استفاده کنید. این تکنیکها در بخش بعد توضیح داده شدهاند.
۴. مراحل را روشن و مستقل بنویسید
- هر گام فقط یک عمل داشته باشد.
- از فعل امری و جمله کوتاه استفاده کنید؛ مثلاً «روی دکمه ورود کلیک کنید».
- نام دقیق دکمهها و فیلدها را همانطور که در رابط کاربری آمده بنویسید.
- تستکیس به نتیجه تستکیس دیگری وابسته نباشد.
۵. نتیجه مورد انتظار را قابل سنجش کنید
«سیستم درست کار میکند» نتیجه مورد انتظار نیست. نتیجه باید دقیق باشد؛ مثلاً «پیام «رمز عبور نادرست است» زیر فیلد رمز نمایش داده میشود». اگر دو تستر با خواندن نتیجه به دو برداشت برسند، باید آن را بازنویسی کرد.
۶. بازبینی همتا انجام دهید
یک همتیمی تستکیس را بخواند و بدون کمک شما اجرا کند. هر جا سؤال پیش آمد، همان جا نیاز به اصلاح دارد.
۷. تستکیسها را اولویتبندی کنید
همیشه زمان کافی برای اجرای همه تستها وجود ندارد. اولویت به تیم کمک میکند در چرخههای کوتاه، مهمترین تستها را اجرا کند. یک تقسیمبندی ساده:
- اولویت بالا: مسیرهای حیاتی کسبوکار مثل ورود، پرداخت و ثبت سفارش.
- اولویت متوسط: قابلیتهای پرکاربرد اما غیرحیاتی.
- اولویت پایین: حالتهای نادر و بخشهای کماثر.
تستکیسهای اولویت بالا معمولاً پایه مجموعه تست دود و رگرسیون میشوند.
تکنیکهای طراحی تستکیس
افراز همارزی
ورودیها به گروههایی تقسیم میشوند که سیستم با آنها رفتار یکسانی دارد. از هر گروه یک مقدار تست میشود. مثلاً اگر سن مجاز ۱۸ تا ۶۵ سال باشد، سه گروه داریم: کمتر از ۱۸، بین ۱۸ و ۶۵، و بیشتر از ۶۵.
تحلیل مقادیر مرزی
باگها معمولاً روی مرزها پنهان میشوند. در همان مثال سن، مقادیر ۱۷، ۱۸، ۶۵ و ۶۶ تست میشوند. این تکنیک مکمل افراز همارزی است.
جدول تصمیم
وقتی نتیجه به ترکیب چند شرط بستگی دارد، یک جدول ساخته میشود. هر ستون یک ترکیب از شرطها و نتیجه آن است. مثلاً تخفیف به عضویت کاربر و مبلغ سبد خرید بستگی دارد. هر ترکیب یک تستکیس میشود.
انتقال حالت
برای سیستمهایی که وضعیت دارند، مثل سفارش با وضعیتهای «ثبتشده»، «پرداختشده» و «ارسالشده»، انتقالهای مجاز و غیرمجاز تست میشوند.
حدس خطا و تست اکتشافی
تجربه تستر هم منبع مهمی برای تستکیس است. ورودیهایی مثل فاصله اضافه، نویسههای فارسی و عربی، یا اعداد فارسی در فیلدهای عددی، نمونههایی از حدس خطا هستند. تست اکتشافی هم ایدههای تازه برای تستکیسهای آینده میدهد.
نمونه تستکیس: فرم ورود به سامانه
در این نمونه، نیازمندی این است: «کاربر با ایمیل و رمز عبور وارد سامانه میشود. پس از پنج تلاش ناموفق، حساب به مدت ۱۵ دقیقه قفل میشود.»
| شناسه | عنوان | پیششرط | مراحل | نتیجه مورد انتظار |
|---|---|---|---|---|
| TC-101 | ورود – اطلاعات معتبر – ورود موفق | کاربر با ایمیل test@example.com و رمز معتبر ثبتنام کرده است | ۱) صفحه ورود را باز کنید؛ ۲) ایمیل را وارد کنید؛ ۳) رمز عبور معتبر را وارد کنید؛ ۴) روی «ورود» کلیک کنید | کاربر به داشبورد هدایت میشود و نام او در سربرگ نمایش داده میشود |
| TC-102 | ورود – رمز نادرست – نمایش پیام خطا | کاربر ثبتنام کرده است | ۱) صفحه ورود را باز کنید؛ ۲) ایمیل معتبر را وارد کنید؛ ۳) رمز نادرست را وارد کنید؛ ۴) روی «ورود» کلیک کنید | پیام «ایمیل یا رمز عبور نادرست است» نمایش داده میشود و کاربر در صفحه ورود میماند |
| TC-103 | ورود – فیلدهای خالی – نمایش خطای اعتبارسنجی | صفحه ورود در دسترس است | ۱) صفحه ورود را باز کنید؛ ۲) بدون پر کردن فیلدها روی «ورود» کلیک کنید | زیر هر دو فیلد پیام «این فیلد الزامی است» نمایش داده میشود |
| TC-104 | ورود – پنج تلاش ناموفق – قفل شدن حساب | کاربر ثبتنام کرده و تلاش ناموفقی ندارد | ۱) پنج بار پشت سر هم با رمز نادرست تلاش کنید؛ ۲) بار ششم رمز معتبر را وارد کنید | پیام قفل بودن حساب به مدت ۱۵ دقیقه نمایش داده میشود و ورود انجام نمیشود |
| TC-105 | ورود – ایمیل با حروف بزرگ – ورود موفق | کاربر با ایمیل test@example.com ثبتنام کرده است | ۱) ایمیل را بهصورت TEST@EXAMPLE.COM وارد کنید؛ ۲) رمز معتبر را وارد کنید؛ ۳) روی «ورود» کلیک کنید | ورود موفق انجام میشود، چون ایمیل به حروف بزرگ و کوچک حساس نیست |
به چند نکته در این نمونه توجه کنید. هر تستکیس فقط یک رفتار را بررسی میکند. دادهها مشخص هستند. نتیجه مورد انتظار دقیق و قابل سنجش است. تستکیس TC-104 مقدار مرزی پنج تلاش را پوشش میدهد. TC-105 هم از نیازمندی ضمنی درباره حساسیت ایمیل به حروف آمده است که باید با تیم محصول تأیید شود.
اشتباهات رایج در نوشتن تستکیس
- مراحل مبهم: «فرم را پر کنید» بدون مشخص کردن دادهها.
- چند هدف در یک تستکیس: وقتی تست رد شود، معلوم نیست کدام بخش خراب است.
- نتیجه مورد انتظار کلی: «صفحه درست نمایش داده میشود» قابل سنجش نیست.
- وابستگی بین تستکیسها: رد شدن یک تست باعث رد شدن زنجیرهای تستهای بعدی میشود.
- نبود ارتباط با نیازمندی: نمیتوان گفت کدام نیازمندی پوشش داده شده است.
- تمرکز فقط بر مسیر موفق: بیشتر باگها در مسیرهای خطا و مرزها هستند.
- بهروز نکردن تستکیسها: پس از تغییر محصول، تستکیس قدیمی نتیجه گمراهکننده میدهد.
برای رفع مشکل ارتباط با نیازمندی، از ماتریس ردیابی استفاده کنید. روش ساخت آن در مقاله ماتریس ردیابی نیازمندی آمده است. تستکیسهایی که در هر ریلیز تکرار میشوند هم پایه مجموعه تست رگرسیون را میسازند. بخشی از آنها بعداً کاندیدای اتوماسیون تست میشوند.
نگهداری و سازماندهی تستکیسها در TestRail
با رشد محصول، تعداد تستکیسها سریع زیاد میشود. در TestRail، تستکیسها در سوئیتها و بخشها دستهبندی میشوند؛ مثلاً یک بخش برای «ورود» و یک بخش برای «سبد خرید». فیلدهای سفارشی مثل نیازمندی مرتبط یا نوع تست، قالب تیم را یکسان میکنند. هنگام اجرا، تستکیسهای انتخابی در یک Test Run قرار میگیرند و نتیجه هر کدام با وضعیت Passed، Failed، Blocked یا Retest ثبت میشود. اتصال به Jira هم باگ را مستقیم به تستکیس رد شده وصل میکند. اگر تستکیسهای شما امروز در اکسل یا ابزار دیگری هستند، صفحه مهاجرت به TestRail مسیر انتقال را توضیح میدهد.
جمعبندی
نوشتن تست کیس حرفهای با فهم دقیق نیازمندی شروع میشود. تکنیکهایی مثل افراز همارزی و تحلیل مقادیر مرزی، تعداد تست را کم و پوشش را زیاد میکنند. هر تستکیس باید یک هدف، داده مشخص و نتیجه قابل سنجش داشته باشد. تستکیس خوب حلقه اصلی زنجیره نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز است. برای دیدن جایگاه تستکیس در کل فرایند، راهنمای جامع تست نرمافزار را بخوانید.