Creating Your First Test Cycle in Jira with BesTest

A test cycle is a planned, organized execution of a specific set of test cases. Think of it as a "testing sprint" - a defined period where your team runs a group of tests, records the results, and reports on the outcome.

You could execute test cases one by one, whenever you feel like it. But without cycles you lose:

• •Context: When was this test last run? Was it part of the Sprint 5 release or the hotfix?
• •Progress tracking: How far along is testing? When will we be done?
• •Comparison: Did quality improve between releases?
• •Accountability: Who was supposed to test what, and did they finish?

Test cycles solve all of these by grouping executions into a named, time-bound batch with assigned testers and trackable progress.

What You'll Build in This Tutorial

This is a hands-on walkthrough. You'll open BesTest in your project, create a cycle, fill it with test cases (manually or from a Smart Collection), assign testers, execute the tests in the Test Player, log a defect from a failure, and read the results. By the end you'll have a complete, reported test cycle - and a repeatable process for every cycle after it.

You don't need a test plan document to run a cycle, but five minutes of thinking saves hours of confusion. Answer three questions before you click "Create Test Cycle."

Be specific about scope:

• •Bad scope: "Test everything"
• •Good scope: "Verify all new features from Sprint 7 and regression-test the checkout flow"

The cycle type usually answers this for you:

In BesTest, all of these follow the same workflow - the difference is which test cases you include and who executes them. This tutorial uses a sprint test cycle as the example.

Your scope tells you what to pull in: test cases for the sprint's new stories, regression tests for affected areas, and re-verification tests for fixed bugs. If you've set up Smart Collections, this step is one click - you'll see how in the "adding test cases" section below.

To sanity-check the timeline, estimate 5-15 minutes per manual test. For example: 50 test cases at 10 minutes each is 500 minutes; two testers with 3 hours a day each cover that in about 1.5 days, plus buffer for defect triage and re-testing.

Decide who executes what. Assign domain-specific tests to the testers who know that area, balance the load, and for important cycles assign tests to someone who didn't build the feature.

Finally, confirm the environment is ready: the right build is deployed, test data is loaded, and testers have access credentials. That's the whole plan - now let's build the cycle.

Open BesTest and create the cycle - this takes about two minutes.

• •Navigate to your Jira project and click "BesTest" in the project menu bar at the top
• •Go to the "Test Cycles" section
• •Click the "Create Test Cycle" button
• •Fill in the cycle details:

Don't click "Save" yet - the create flow also lets you add test cases and assign testers before saving, which is what we'll do in the next step. (You can also save an empty cycle and add test cases later if you prefer.)

Naming Conventions That Scale

As you create more cycles, good naming becomes important. Patterns that work well:

• •Sprint cycles: Sprint [#] - [Module/Feature] Tests
• •Regression cycles: Regression - Release [version] - [date]
• •UAT cycles: UAT - Release [version] - [stakeholder group]
• •Hotfix cycles: Hotfix - [JIRA-ID] - [brief description]

Consistent naming makes it easy to find historical cycles and compare results across releases.

Multiple Active Cycles

BesTest supports having multiple test cycles active simultaneously - a sprint cycle for the QA team, a UAT cycle for business stakeholders, and a regression cycle can all run in parallel. Each cycle operates independently, and the same test case can be included in multiple cycles, each with its own execution record.

Still in the create flow, switch to the "Test Cases" tab. This is where you fill the cycle, and BesTest gives you three ways to do it.

Option A: Search and Select

The standard flow for most cycles:

• •In the "Test Cases" tab, browse or search the test case list
• •Select the test cases you want to include by checking the boxes
• •Continue with the cycle creation

Option B: Add from a Smart Collection

If you've set up Smart Collections (rule-based groups like "Regression Suite"), this is the fastest method:

• •In the "Test Cases" tab, select the "From Smart Collection" option
• •Choose the relevant collection (e.g., "Regression Suite" or "Sprint 7 Features")
• •All matching test cases are added at once

Use this for large cycles and regression testing - populating a 100-test regression cycle takes seconds instead of half an hour. See the Smart Collections tutorial for setup.

Option C: Filter and Add

When you need a subset that doesn't match an existing collection, apply filters in the "Test Cases" tab - by priority (only High and Critical), tags ("regression", "payment"), linked requirements, or last execution status (only tests that failed last cycle) - then select the filtered results.

How Many Test Cases?

Before moving on, review the list: do all new features have coverage, are regression tests included for impacted areas, and is the total realistic for your timeline?

With the test cases in place, assign them to testers - still in the create flow (you can also do this any time after saving).

• •In the cycle's test case list, click the assignment option on a test case
• •Select the team member who should execute it
• •Repeat for the remaining test cases
• •Click "Save" to create the cycle

Bulk Assignment

For larger cycles, assigning one by one is tedious. Instead:

• •Select multiple test cases using the checkboxes
• •Choose "Assign" from the bulk actions
• •Select the tester - all selected tests are assigned at once

This makes even distribution easy: select the first third and assign to Tester A, the next third to Tester B, and so on.

Quick Assignment Strategies

• •By module: the tester who knows the area best tests it (better depth, but creates silos)
• •Round-robin: even workload and cross-training, at the cost of familiarity
• •By priority: critical tests go to your most experienced testers
• •By test type: functional tests to QA, UAT tests to business users

Most teams combine these - by module for feature tests, round-robin for regression.

Notifications Do the Announcing

BesTest's in-app notifications automatically alert testers when they're assigned test cases, so nobody needs to manually check for new work. Still, tell the team the essentials: the start and end dates, which tests to run first if time is limited, and who to contact when blocked. This matters most for UAT cycles, where business users aren't in BesTest every day.

The cycle is now created, populated, and assigned. Next up: execution. The interactive player below is the real BesTest UI - click through a few steps to get a feel for it before reading on.

This is where the actual testing happens. BesTest's Test Player is a focused, step-by-step execution interface - the interactive player just above this section shows exactly what your testers will see.

Opening the Test Player

Before anyone can execute, the cycle status must be set to "Ready to Execute" - until then, execution is blocked, giving you time to finalize the setup.

• •Open your test cycle in BesTest and set its status to "Ready to Execute"
• •Click the play button on a test case assigned to you - the Test Player opens

The Test Player shows the test case title and description, the preconditions, and each test step with its action and expected result, plus controls for recording results.

Executing Step by Step

For each step in the Test Player:

• •Read the action and perform it in the application under test
• •Compare the actual behavior with the expected result
• •Record the outcome: click "Pass" if they match, "Fail" if they don't, or "Blocked" if you can't execute the step (environment down, missing data, failed dependency)
• •Add a comment (optional but recommended) - note observations even for passing steps
• •Create or link a Jira issue if you need to attach screenshots or other evidence
• •Move to the next step

When a Step Fails

• •Record the step as "Fail"
• •Add a comment describing what actually happened, how it differs from the expected result, and any error messages
• •Create or link a Jira issue where you can attach screenshots showing the failure
• •Decide whether to continue: keep testing if the remaining steps are independent, or mark them "Blocked" if the failure stops everything
• •Log a defect (covered in the next section)

When a Test Can't Run at All

Mark it "Blocked" and comment why - environment down, missing test data, a failed prerequisite test, an unavailable integration. "Blocked" signals an impediment that needs resolution; "not run" just means skipped. Keeping them distinct keeps your progress numbers honest.

Execution Habits That Pay Off

• •Test in order and complete one test case before starting another - partial executions are confusing
• •Document specifics: "It worked" is not a useful comment; "Invoice total displayed as $1,247.50, matching the expected calculation" is
• •Check preconditions - don't carry state from a previous test
• •Don't rush - hurried testing misses defects

When a test step fails, log the defect immediately - while the context is fresh and the evidence is in front of you.

When to Log (and When Not To)

Log a defect when the actual result differs from the expected result, the application errors or crashes, or a feature is missing. Do not log a defect when the test case itself is wrong (update the test case), the environment has a known issue (mark the test "Blocked"), or the expected behavior is ambiguous (discuss with the team first).

Creating a Defect from a Failed Test

• •When a step fails in the Test Player, look for the "Log Defect" or "Create Bug" option
• •BesTest opens a Jira bug creation form pre-populated with context: the test case name and step number, the expected vs. actual result, and a link back to the test execution
• •Add the remaining details:

• •Submit - the bug is created as a Jira issue in your project

The Traceability Chain

When you create a defect from a failed test, BesTest maintains the complete chain:

Requirement → Test Case → Test Execution (Failed Step) → Jira Bug

You can see all bugs discovered during a cycle, trace a bug back to the requirement it affects, and know exactly which test case to re-run when the fix lands.

A Bug Report Template That Works

Summary: [Area] - [What's wrong] - [Key detail]
Example: "Checkout - Tax calculation shows $0.00 for California addresses"

Steps to Reproduce:
1. Navigate to checkout with items in cart
2. Enter shipping address: 123 Main St, Los Angeles, CA 90001
3. Click "Calculate Total"

Expected: Tax displays as 9.5% of subtotal ($47.50 on $500.00)
Actual: Tax displays as $0.00

Environment: Chrome 120, staging.example.com
Test Data: User testbuyer@example.com, Order #TEST-789

Re-Testing After Fixes

When the fix is deployed to the test environment, the tester re-executes the failed test case. If it passes, the bug is verified and closed; if not, it's reopened with updated information. BesTest records the re-test as a new execution, preserving the full history.

As the cycle progresses, stakeholders will ask: "How's testing going? Can we release?" BesTest tracks everything in real time, so you can answer confidently.

Cycle Progress at a Glance

Open your test cycle in BesTest to see the progress overview: total test cases, executed count (passed + failed + blocked), not-run count, pass rate, and completion percentage - all updating live as testers record results.

Jira Dashboard Gadgets for Stakeholders

For people who don't open BesTest directly:

• •Go to your Jira dashboard and click "Add gadget"
• •Search for BesTest gadgets
• •Add the execution progress gadget and configure it for your active cycle

Project managers and product owners now see testing progress right alongside their sprint board.

Requirements Coverage: the "Can We Release?" View

Beyond cycle progress, BesTest maps results back to requirements:

• •Covered: requirements with sufficient test coverage based on their significance (calculated from dev complexity x impact), or manually set to "Covered"
• •Passed: requirements where all linked test cases have passed
• •At risk: requirements with one or more failing linked tests
• •Not tested: requirements with no test cases in this cycle

If critical requirements are at risk or untested, the release decision is clear.

Reporting the Outcome

When the cycle completes (or at any checkpoint), pull the results together for stakeholders:

• •Cycle summary: total tests, pass/fail/blocked/not-run counts, and the top defects found - the answer to "did we test what we planned, and did it pass?"
• •Coverage report: which requirements were validated, which are at risk, which weren't tested - essential for release decisions and compliance evidence
• •Defect summary: counts by severity and status, so the team knows what's still open
• •Execution history: every attempt per test case with timestamps and testers - valuable for audits and for seeing how many fix-and-retest rounds were needed

Share via Jira dashboard gadgets for real-time visibility, or walk through the results in sprint reviews and release meetings.

After your first cycle, you'll quickly discover what works. These practices keep cycles efficient and valuable as you scale.

"Test everything" cycles never finish, multi-week cycles lose momentum, and overloaded cycles lead to rushed execution. Create multiple focused cycles instead - a "Sprint 7 Features" cycle plus a "Regression - Core Workflows" cycle beats one massive "Sprint 7 Everything" cycle.

Run smoke tests first to catch build-breaking issues, then new feature tests (where most bugs live), then high-risk regression, then the rest. If time runs short, you've already covered the highest-risk areas.

Triage failures daily. Critical and major defects should be fixed and re-tested within the cycle; minor defects can be deferred to the next cycle with stakeholder agreement - but document every deferral and its rationale.

After a fix, re-execute the failed test case - don't just mark it passed - and run related tests to check for regressions from the fix. BesTest records each attempt as a new execution, so the history stays intact.

Follow a naming convention ([Type] - [Release/Sprint] - [Scope]) and tag test cases consistently so Smart Collections work reliably. Document the conventions for new team members.

After each cycle, ask: which tests caught real issues? What was painful - unclear tests, unstable environment, overloaded testers? How does this cycle compare with previous ones? Then fix one thing before the next cycle.

Old cycles are historical data: quality comparison across releases, audit evidence, recurring problem areas, and onboarding examples for new team members.