تا به حال شده که یک باگ مهم را پیدا کنید، اما در میان انبوهی از ایمیل‌ها یا پیام‌های چت گم شود و توسعه‌دهندگان هرگز آن را نبینند؟ یا شاید در جلسات اسپرینت شرکت کرده‌اید و احساس کرده‌اید که نقش شما به عنوان تستر در فرآیند چابک (Agile) نادیده گرفته می‌شود. اگر این سناریوها برایتان آشناست، مشکل از مهارت‌های تست شما نیست؛ بلکه مشکل در “نحوه مدیریت فرآیند” است. جیرا (Jira) دقیقاً همان ابزاری است که این آشفتگی را به نظم تبدیل می‌کند. این پلتفرم، زبان مشترک بین تسترها، برنامه‌نویسان و مدیران محصول است. در این راهنما، نه با اصطلاحات پیچیده فنی، بلکه به زبان ساده یاد می‌گیرید که چطور جیرا را به قدرتمندترین اسلحه خود در تضمین کیفیت نرم‌افزار تبدیل کنید.

چرا جیرا برای تسترها یک ابزار حیاتی است؟

در دنیای توسعه نرم‌افزار مدرن، سرعت و دقت باید در کنار هم باشند. جیرا در اصل برای ردیابی مشکلات (Issue Tracking) طراحی شده بود، اما امروز قلب تپنده تیم‌های چابک است. برای یک تستر، جیرا فراتر از یک دفترچه یادداشت دیجیتال است؛ این ابزار به شما امکان می‌دهد:

  • شفافیت کامل: همه می‌بینند شما چه باگ‌هایی پیدا کرده‌اید و وضعیت آن‌ها چیست.
  • تاریخچه دقیق: هرگز بحثی پیش نمی‌آید که “من این را قبلاً گفته بودم یا نه”.
  • مدیریت گردش کار: باگ‌ها به صورت خودکار به شخص مسئول ارجاع داده می‌شوند.
[پیشنهاد لینک داخلی: آشنایی با متدولوژی اسکرام و نقش تستر در آن]

شروع کار: مفاهیم پایه جیرا برای تسترها

قبل از شیرجه زدن در مدیریت باگ، باید با واژه‌نامه جیرا آشنا شویم. نترسید، این‌ها تنها کلماتی هستند که هر روز خواهید شنید:

۱. ایشو (Issue)

در جیرا، هر چیزی یک “ایشو” است. یک باگ، یک تسک جدید، یا یک داستان کاربر (User Story)، همگی نوعی ایشو هستند. به عنوان تستر، شما بیشتر با نوع “Bug” سر و کار دارید.

۲. پروژه (Project)

ظرف بزرگی است که تمام ایشوها در آن نگهداری می‌شوند. مثلاً اگر روی اپلیکیشن اندروید شرکت کار می‌کنید، احتمالاً یک پروژه به نام “Android App” در جیرا دارید.

۳. گردش کار (Workflow)

این مسیر زندگی یک باگ است. یک باگ از حالت “باز” (Open) شروع می‌شود، به “در حال انجام” (In Progress) می‌رود و در نهایت “بسته” (Closed) می‌شود. درک این چرخه برای تستر حیاتی است.

راهنمای گام‌به‌گام گزارش باگ (Bug Reporting) در جیرا

هنر یک تستر، پیدا کردن باگ نیست؛ بلکه گزارش دادن آن به شکلی است که برنامه‌نویس بتواند فوراً آن را بازتولید و رفع کند. یک گزارش باگ ناقص در جیرا، فقط باعث اتلاف وقت و “پینگ‌پنگ” شدن تسک بین شما و دولوپر می‌شود.

اجزای یک تیکت باگ استاندارد

وقتی دکمه Create را در جیرا می‌زنید، این فیلدها را با دقت پر کنید:

  1. Summary (خلاصه): تیتر خبری باگ شماست. باید کوتاه و گویا باشد.
    • بد: دکمه کار نمی‌کند.
    • خوب: دکمه “ثبت نام” در صفحه لاگین ارور ۵۰۰ می‌دهد.
  2. Description (توضیحات): قلب گزارش شما. اینجا باید سه بخش اصلی داشته باشد:
    • Steps to Reproduce (مراحل بازتولید): قدم به قدم بنویسید چه کردید (۱. باز کردن برنامه، ۲. کلیک روی دکمه…).
    • Actual Result (نتیجه فعلی): چه اتفاقی افتاد؟ (برنامه کرش کرد).
    • Expected Result (نتیجه مورد انتظار): باید چه می‌شد؟ (باید وارد صفحه پروفایل می‌شد).
  3. Priority (اولویت): چقدر این باگ مهم است؟
    • Critical: سیستم کلاً از کار افتاده.
    • Major: عملکرد اصلی مختل شده اما راه‌حل موقت دارد.
    • Minor: مشکلات ظاهری یا غلط املایی.
  4. Attachment (پیوست): همیشه اسکرین‌شات یا ویدیو از باگ بگیرید. یک تصویر گویاتر از هزار خط توضیح است.
[پیشنهاد لینک داخلی: ابزارهای ضبط صفحه نمایش برای تسترها]

مدیریت اسپرینت (Sprint) و بورد جیرا

در تیم‌های چابک، کارها در بازه‌های زمانی مشخص (معمولاً ۲ هفته) که اسپرینت نامیده می‌شود، انجام می‌گیرند. بورد جیرا (Jira Board) جایی است که شما وضعیت تمام کارها را در یک نگاه می‌بینید. این بورد معمولاً شامل ستون‌های زیر است:

  • To Do: کارهایی که باید انجام شوند.
  • In Progress: کارهایی که دولوپرها در حال انجام آن هستند.
  • Ready for QA / In Test: این ستون مخصوص شماست! وقتی دولوپر کارش تمام شد، تسک را به اینجا منتقل می‌کند.
  • Done: وقتی شما تست کردید و تایید کردید، تسک به اینجا می‌آید.

وظایف تستر در طول اسپرینت

  1. مانیتور کردن ستون Ready for QA: هر روز صبح این ستون را چک کنید. تسک‌های جدید را بردارید و تست را شروع کنید.
  2. تغییر وضعیت (Transition): اگر باگی پیدا کردید، تسک را به ستون قبلی (In Progress) برگردانید و کامنت بگذارید. اگر باگ رفع شده بود، آن را به Done ببرید.
  3. لینک کردن باگ‌ها: اگر حین تستِ یک فیچر جدید، باگی پیدا کردید، یک باگ جدید بسازید و آن را به استوری اصلی لینک (Link Issue) کنید. نوع لینک معمولاً “Blocks” یا “Relates to” است.

تکنیک‌های پیشرفته جیرا برای تسترهای حرفه‌ای

حالا که اصول اولیه را می‌دانید، بیایید سطح کار را بالا ببریم. استفاده از این قابلیت‌ها شما را از یک تستر معمولی به یک تستر ارشد (Senior QA) تبدیل می‌کند.

۱. استفاده از داشبورد (Dashboard) شخصی

شما می‌توانید یک صفحه اختصاصی بسازید که به محض ورود به جیرا ببینید:

  • چند باگ با اولویت بالا به شما ارجاع شده است؟
  • وضعیت باگ‌هایی که گزارش کرده‌اید چیست؟
  • نمودار گرافیکی از باگ‌های باز در پروژه.برای این کار از Gadgetهای جیرا استفاده کنید و فیلترهای خود را بسازید (JQL).

۲. اتصال جیرا به ابزارهای تست (Zephyr یا Xray)

جیرا به تنهایی برای مدیریت تست‌کیس‌ها (Test Cases) طراحی نشده است. اما پلاگین‌هایی مثل Zephyr یا Xray وجود دارند که داخل جیرا نصب می‌شوند. با این ابزارها می‌توانید:

  • سناریوهای تست (Test Scenarios) را بنویسید.
  • تست‌پلن (Test Plan) ایجاد کنید.
  • نتیجه اجرای هر تست (Pass/Fail) را مستقیماً به یک ایشو متصل کنید.
[پیشنهاد لینک داخلی: مقایسه پلاگین‌های مدیریت تست در جیرا: Zephyr در برابر Xray]

۳. جستجوی پیشرفته با JQL

زبان جستجوی جیرا (Jira Query Language) قدرت فوق‌العاده‌ای دارد. مثلاً اگر بخواهید تمام باگ‌های باز که توسط شما گزارش شده و در اسپرینت فعلی هستند را ببینید، می‌توانید دستوری شبیه به این بنویسید:reporter = currentUser() AND type = Bug AND status != Done AND sprint in openSprints()

اشتباهات رایج تسترها در جیرا (و چگونگی اجتناب از آن‌ها)

اشتباه رایج راه حل صحیح
توضیحات مبهم: نوشتن “کار نمی‌کند”. دقت: همیشه سناریوی دقیق و محیط تست (مرورگر، سیستم عامل) را ذکر کنید.
فراموشی در تغییر وضعیت: باگ رفع شده اما هنوز در ستون QA است. نظم: به محض اتمام تست، وضعیت تیکت را آپدیت کنید تا بورد به‌روز بماند.
ترکیب چند باگ در یک تیکت: گزارش ۵ مشکل مختلف در یک ایشو. تفکیک: قانون طلایی: “هر باگ، یک تیکت”. این کار پیگیری را آسان می‌کند.
عدم بررسی تکراری بودن: ثبت باگی که قبلاً همکار شما ثبت کرده است. جستجو: قبل از ساخت تیکت جدید، یک جستجوی سریع در باگ‌های باز انجام دهید.

سوالات متداول

۱. آیا برای کار با جیرا باید برنامه‌نویسی بلد باشیم؟خیر، اصلاً نیازی نیست. جیرا یک ابزار مدیریتی است و محیط کاربری بصری دارد. تنها بخش کمی فنی آن JQL است که یادگیری آن بسیار ساده و شبیه به زبان انگلیسی است.

۲. تفاوت Epic، Story و Bug در جیرا چیست؟Epic یک هدف بزرگ است (مثلاً: طراحی سیستم پرداخت). Story بخش‌های کوچک‌تر اپیک است که قابل انجام در یک اسپرینت است (مثلاً: درگاه پرداخت بانک ملت). Bug هم اشکالی است که در عملکرد سیستم وجود دارد.

۳. وقتی دولوپر باگ را “Reject” می‌کند باید چه کار کنم؟آرامش خود را حفظ کنید! در بخش کامنت‌ها دلیل را بپرسید. ممکن است سوءتفاهم در مورد “عملکرد مورد انتظار” باشد یا شاید توضیحات شما برای بازتولید باگ کافی نبوده است. با ارائه مستندات بیشتر (عکس و فیلم) باگ را اثبات کنید.

۴. ساب‌تسک (Sub-task) چه کاربردی برای تستر دارد؟گاهی یک Story بزرگ است و شما می‌خواهید کار تست آن را به چند بخش تقسیم کنید (مثلاً تست در کروم، تست در فایرفاکس). می‌توانید برای هر کدام یک ساب‌تسک زیر همان استوری اصلی ایجاد کنید.

۵. بهترین وضعیت (Status) برای وقتی که باگ رفع نشده چیست؟اگر دولوپر ادعا کرد باگ را رفع کرده اما شما در تست مجدد دیدید هنوز مشکل پابرجاست، تیکت را به Reopened تغییر دهید و در کامنت توضیح دهید که چرا تایید نشده است.

جمع‌بندی: جیرا، دستیار هوشمند شما

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

از همین امروز شروع کنید: اولین داشبورد شخصی‌تان را بسازید یا سعی کنید گزارش باگ بعدی‌تان را با جزئیات کامل و ساختار‌یافته در جیرا ثبت کنید. تفاوت را احساس خواهید کرد.

دیدگاهتان را بنویسید