ابزار مدیریت تست (Test Management Tool) جایی است که تست‌کیس‌ها، اجراها و نتیجه‌ها در آن نگهداری می‌شوند. انتخاب ابزار مدیریت تست به اندازه تیم، روش کار و ابزارهای فعلی شما بستگی دارد. در این راهنما سه رویکرد رایج را منصفانه مقایسه می‌کنیم: صفحه‌گسترده‌هایی مثل اکسل و Google Sheets، افزونه‌های داخل Jira مثل Xray و Zephyr، و ابزار مستقلی مثل TestRail.

برای آشنایی با مفاهیم پایه، راهنمای تست نرم‌افزار چیست را ببینید.

ابزار مدیریت تست چه کاری انجام می‌دهد

هر ابزاری که انتخاب کنید، باید چند نیاز اصلی را پوشش دهد. این نیازها معیار مقایسه ما در ادامه هستند.

نیازهای اصلی

  • نگهداری تست‌کیس‌ها: با ساختار، مراحل، نتیجه مورد انتظار و فیلدهای توصیفی.
  • سازمان‌دهی: گروه‌بندی بر اساس ماژول، قابلیت یا نوع تست.
  • اجرای تست: ساختن یک اجرای تست از مجموعه‌ای از تست‌کیس‌ها برای یک نسخه مشخص.
  • ثبت نتیجه: وضعیت هر تست، توضیح، پیوست و مسئول اجرا.
  • تاریخچه: مقایسه نتیجه یک تست در نسخه‌های مختلف.
  • ردیابی: ارتباط تست‌ها با نیازمندی‌ها و باگ‌ها.
  • گزارش: پیشرفت اجرا، نرخ قبولی و وضعیت کیفیت برای تیم و مدیران.
  • یکپارچگی: اتصال به ابزار ردیابی باگ و خط لوله تست خودکار.

چرا این انتخاب مهم است

ابزار مدیریت تست روی عادت‌های روزمره تیم اثر می‌گذارد. جابه‌جایی بعدی هزینه دارد، چون تست‌کیس‌ها و تاریخچه باید منتقل شوند. پس بهتر است از ابتدا نیازهای یک تا دو سال آینده را هم در نظر بگیرید.

صفحه‌گسترده: اکسل و Google Sheets

بسیاری از تیم‌ها مدیریت تست را با صفحه‌گسترده شروع می‌کنند. این انتخاب برای شروع کاملاً منطقی است.

نقاط قوت

  • در دسترس و آشنا: تقریباً همه با آن کار کرده‌اند و آموزش خاصی نمی‌خواهد.
  • انعطاف کامل: هر ستونی که بخواهید اضافه می‌کنید.
  • همکاری هم‌زمان: Google Sheets ویرایش هم‌زمان و تاریخچه نسخه دارد.
  • هزینه جداگانه ندارد: اگر سازمان از قبل مجوز یا حساب آن را دارد.
  • مناسب پروژه‌های کوچک: برای یک محصول ساده با تعداد محدودی تست‌کیس کافی است.

محدودیت‌ها با رشد تیم

  • تاریخچه اجرا دستی است: برای هر اجرا معمولاً یک ستون یا برگه جدید ساخته می‌شود. مقایسه نسخه‌ها به‌مرور سخت می‌شود.
  • ساختار یکپارچه تضمین نمی‌شود: هر نفر ممکن است قالب را کمی تغییر دهد.
  • گزارش‌ها دستی ساخته می‌شوند: نمودار و خلاصه باید با فرمول و به‌روزرسانی دستی تهیه شوند.
  • اتصال به تست خودکار محدود است: ثبت نتیجه خودکار به اسکریپت‌نویسی جداگانه نیاز دارد.
  • ردیابی با پیوند دستی انجام می‌شود: ارتباط تست، نیازمندی و باگ با شناسه‌هایی که دستی وارد می‌شوند حفظ می‌شود.

چه زمانی صفحه‌گسترده کافی است

وقتی تیم تست یک یا دو نفره است، محصول ساده است و انتشارها کم‌تعداد هستند. در این حالت یک قالب منظم با ستون‌های شناسه، عنوان، مراحل، نتیجه مورد انتظار و وضعیت کار را راه می‌اندازد. راهنمای نوشتن تست‌کیس برای طراحی همین ستون‌ها مفید است.

افزونه‌های مدیریت تست داخل Jira

اگر تیم توسعه با Jira کار می‌کند، افزونه‌های مدیریت تست گزینه‌ای طبیعی به نظر می‌رسند. دو خانواده شناخته‌شده در این دسته Xray و Zephyr هستند.

نحوه کار

  • Xray تست‌ها، مجموعه‌ها و اجراها را به‌صورت انواع Issue در خود Jira تعریف می‌کند. یعنی تست هم یک Issue است.
  • Zephyr چند محصول مختلف دارد که داخل Jira کار می‌کنند. ساختار داده و امکانات هرکدام متفاوت است. پیش از انتخاب، نسخه مورد نظر را دقیق بررسی کنید.

نقاط قوت

  • یک ابزار برای همه: توسعه‌دهنده، تستر و مدیر محصول در یک محیط کار می‌کنند.
  • ارتباط مستقیم با داستان‌ها و باگ‌ها: تست‌ها کنار همان Issueها قرار می‌گیرند.
  • استفاده از دسترسی‌ها و گردش‌کار Jira: مدیریت کاربر جداگانه لازم نیست.
  • گزارش در داشبوردهای Jira: برای تیمی که به داشبوردهای Jira عادت دارد آشناست.

نکته‌هایی که باید بررسی کنید

  • وابستگی به پیکربندی Jira: کیفیت تجربه به تنظیمات، نسخه و میزبانی Jira بستگی دارد.
  • اثر بر حجم داده Jira: در ابزارهایی که تست را Issue می‌کنند، تعداد Issueها زیاد می‌شود. این موضوع روی جست‌وجو و فیلترها اثر دارد.
  • مجوز مستقل: افزونه‌ها معمولاً مجوز جداگانه دارند که با تعداد کاربران Jira مرتبط است. شرایط را از فروشنده هر افزونه بپرسید.
  • دسترسی افراد خارج از Jira: اگر تسترها یا ذی‌نفعانی خارج از Jira دارید، باید برایشان حساب Jira هم تعریف شود.

ابزار مستقل مدیریت تست: TestRail

TestRail یک ابزار تخصصی مدیریت تست است که جدا از ابزار ردیابی باگ کار می‌کند و به آن متصل می‌شود.

ساختار داده

  • پروژه: بالاترین سطح سازمان‌دهی.
  • سوئیت و بخش (Suite و Section): تست‌کیس‌ها در ساختاری درختی گروه‌بندی می‌شوند.
  • تست‌کیس: با مراحل، نتیجه مورد انتظار و فیلدهای سفارشی.
  • اجرای تست (Test Run): مجموعه‌ای از تست‌کیس‌ها که برای یک نسخه اجرا می‌شوند.
  • طرح تست (Test Plan): چند اجرا را، مثلاً برای مرورگرها یا پلتفرم‌های مختلف، کنار هم نگه می‌دارد.
  • مایلستون: اجراها و طرح‌ها را به یک نسخه یا هدف زمانی وصل می‌کند.
  • نتیجه: با وضعیت‌های Passed، Failed، Blocked، Retest و Untested ثبت می‌شود.

نقاط قوت

  • تمرکز بر فرایند تست: ساختار سوئیت، اجرا، طرح و مایلستون برای همین کار طراحی شده است.
  • تاریخچه نتیجه‌ها: نتیجه هر تست در اجراهای مختلف قابل مقایسه است.
  • گزارش‌های آماده: گزارش پیشرفت، مقایسه اجراها و پوشش در خود ابزار وجود دارد.
  • یکپارچگی: اتصال به Jira و ابزارهای دیگر ردیابی باگ و API برای ثبت نتیجه تست خودکار.
  • فیلدهای سفارشی: برای تطبیق با فرایند تیم.

نکته‌هایی که باید بررسی کنید

  • یک ابزار دیگر در کنار Jira: کاربران باید با دو محیط کار کنند، هرچند اتصال بین آن‌ها این فاصله را کم می‌کند.
  • مجوز جداگانه: برای کاربران TestRail مجوز مستقل لازم است.
  • انتخاب نسخه استقرار: نسخه Cloud روی زیرساخت فروشنده میزبانی می‌شود. نسخه Server روی سرورهای خود سازمان نصب می‌شود و نگهداری آن با تیم شماست.

جدول مقایسه سه رویکرد

این جدول یک نمای کلی است. جزئیات به نسخه و پیکربندی هر ابزار بستگی دارد.

معیار اکسل و Google Sheets افزونه‌های Jira (Xray، Zephyr) TestRail
شروع کار فوری نیاز به نصب و پیکربندی در Jira نیاز به راه‌اندازی ابزار جداگانه
ساختار تست‌کیس آزاد؛ به نظم تیم بستگی دارد ساختار تعریف‌شده داخل Jira ساختار تعریف‌شده با سوئیت و بخش
تاریخچه اجرا دستی داخلی داخلی
گزارش‌گیری دستی با فرمول و نمودار داخلی و داشبوردهای Jira گزارش‌های داخلی
ارتباط با باگ‌های Jira پیوند دستی بومی از طریق یکپارچه‌سازی
ثبت نتیجه تست خودکار نیاز به اسکریپت جداگانه از طریق API یا امکانات افزونه از طریق API
کاربران خارج از Jira مشکلی ندارد نیاز به حساب Jira حساب TestRail
مناسب برای تیم کوچک، محصول ساده تیمی که همه کارش در Jira است تیمی که فرایند تست ساخت‌یافته و مستقل می‌خواهد

هیچ‌کدام از این گزینه‌ها برای همه تیم‌ها بهترین نیست. انتخاب درست به وضعیت شما بستگی دارد.

معیارهای انتخاب برای تیم شما

پیش از انتخاب، به این پرسش‌ها برای خودتان پاسخ روشن بدهید:

  1. اندازه تیم و رشد آن: امروز چند تستر دارید و یک سال دیگر چند نفر خواهید داشت.
  2. تعداد تست‌کیس‌ها و محصولات: یک محصول با صد تست یا چند محصول با هزاران تست.
  3. جایگاه Jira در سازمان: همه در Jira کار می‌کنند یا فقط تیم توسعه.
  4. سهم تست خودکار: نتیجه تست‌های خودکار باید کنار تست دستی دیده شود یا نه.
  5. نیاز گزارش‌دهی: مدیران چه گزارشی و با چه تناوبی می‌خواهند.
  6. الزامات امنیت و میزبانی: داده‌ها باید روی سرور داخلی بمانند یا میزبانی ابری مجاز است.
  7. ردیابی نیازمندی: برای ممیزی یا قرارداد، ماتریس ردیابی نیازمندی لازم دارید یا نه.
  8. بودجه و فرایند خرید: مجوزها چطور تهیه و تمدید می‌شوند.

سناریوهای رایج

چند وضعیت رایج و گزینه‌ای که معمولاً با آن هماهنگ‌تر است:

  • استارتاپ با یک تستر و یک محصول: یک قالب منظم صفحه‌گسترده برای شروع کافی است. ساختار ستون‌ها را طوری طراحی کنید که بعداً قابل انتقال باشد.
  • تیمی که همه برنامه‌ریزی، توسعه و پشتیبانی‌اش در Jira است: افزونه‌های Jira ارزش بررسی جدی دارند.
  • چند تیم تست روی چند محصول، با تست دستی و خودکار: ابزار مستقل با ساختار اجرا، طرح و مایلستون معمولاً مدیریت را ساده‌تر می‌کند.
  • سازمانی با الزام نگهداری داده روی سرور داخلی: گزینه‌هایی را بررسی کنید که نسخه قابل نصب روی زیرساخت خودتان دارند.

این فهرست قاعده قطعی نیست. فقط نقطه شروعی برای گفتگوی تیم است.

یک آزمایش کوچک انجام دهید

به‌جای تصمیم بر اساس فهرست امکانات، یک پروژه واقعی را در ابزار نامزد پیاده کنید. چند ده تست‌کیس وارد کنید، یک اجرای کامل انجام دهید و گزارش بگیرید. نظر تسترها و مدیر محصول را جمع کنید. این تجربه معمولاً از هر مقایسه نظری دقیق‌تر است.

مهاجرت از صفحه‌گسترده به ابزار مدیریت تست

اگر تصمیم به مهاجرت گرفتید، این گام‌ها کمک می‌کنند:

  1. پاک‌سازی پیش از انتقال: تست‌کیس‌های تکراری و منسوخ را حذف کنید.
  2. یکسان‌سازی ساختار: ستون‌ها را به فیلدهای ابزار جدید نگاشت کنید؛ مثل عنوان، پیش‌شرط، مراحل، نتیجه مورد انتظار، اولویت و نوع.
  3. طراحی ساختار درختی: سوئیت‌ها و بخش‌ها را بر اساس ماژول یا جریان کاربری طراحی کنید.
  4. انتقال آزمایشی: یک بخش کوچک را منتقل کنید و نتیجه را بررسی کنید.
  5. انتقال کامل: معمولاً با خروجی CSV و ورود دسته‌ای یا از طریق API.
  6. آموزش تیم: قواعد نام‌گذاری، فیلدها و گردش‌کار را مستند کنید.
  7. دوره موازی کوتاه: مدت کوتاهی هر دو ابزار را نگه دارید و بعد صفحه‌گسترده را فقط‌خواندنی کنید.

در این مرحله طرح تست هم باید به‌روز شود تا نحوه ساختن اجراها و گزارش‌ها در ابزار جدید مشخص باشد. برای تعریف شاخص‌های گزارش هم مقاله معیارهای تست را ببینید.

TestRail امکان ورود تست‌کیس‌ها از فایل CSV و XML را دارد و از طریق API هم می‌توان داده را منتقل کرد. نگاشت ستون‌های صفحه‌گسترده به فیلدهای پیش‌فرض و سفارشی، و طراحی ساختار سوئیت و بخش، مهم‌ترین تصمیم‌های این انتقال هستند. اگر تیم شما حجم زیادی تست‌کیس در اکسل یا ابزار دیگری دارد، صفحه مهاجرت به TestRail مراحل و خدمات این انتقال را توضیح می‌دهد.

جمع‌بندی

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