How to Run Exploratory Test Sessions in Jira With Linked Findings

A tester spots an incorrect checkout total, captures a screenshot, and creates a Jira bug. Later, the developer cannot tell which build was tested, what changed before the failure, or whether the screenshot belongs to the original investigation or a retest. The finding exists, but its context is missing.

Exploratory test sessions in Jira need a record of the investigation as well as a place to track the resulting work. The workflow below uses AgileTest for Jira Cloud, a separately installed app, to capture item-level notes, timing, attachments, and links. Jira work items coordinate ownership and follow-up; the app supplies the exploratory recording interface.

Prepare the Cloud Project and Separate the Records

Before booking the session, confirm that AgileTest is installed on the intended Cloud site. Open it through Apps > AgileTest or the project sidebar. In the project configuration, the Exploratory Test strategy and its Test Session work-type mapping must be available. Company-managed and team-managed projects have different setup paths, so ask the person responsible for Jira configuration to confirm the mapping rather than changing shared settings during testing.

Check that the tester can open the relevant exploratory work item, add findings and evidence, and create or access the intended Jira follow-ups. The reviewer should also be able to open those records. For files attached directly to native Jira work items, Jira's Create attachments permission and space access apply, and attachments must be allowed. Do not assume those checks describe the permissions or storage behavior of attachments inside the app's item panel.

AgileTest terminology can be confusing because its scope-creation button is labeled + Test Session. Keep the following layers separate when planning and reviewing the work.

Record	Purpose	Context to Preserve
Exploratory Test	Jira work item defining the investigation's scope	Charter, responsible tester, relevant build and environment
Test Session	An execution attempt against that scope	Attempt reference, starting conditions, discoveries and gaps
Test Session Item	An individual validation, observation or issue recorded in the app	Notes, item result, elapsed time, attachments and tracked work
Jira bug or other follow-up	Work requiring investigation, clarification or a change	Owner, reproduction details and connection to the originating finding

The component guide distinguishes a Test Session attempt from its Exploratory Test scope. Its documented recording action is +Test Session Item, however, rather than a separate attempt-creation control. Keep an explicit attempt reference in your notes; do not assume the app automatically creates isolated attempt containers or immutable execution snapshots.

Define the Charter Before Starting the Clock

A charter explains what to investigate and what information the team needs. “Test checkout” leaves the tester choosing between unrelated risks. “Explore delivery-option changes after applying a promotion to discover inconsistent payable totals” gives the investigation a boundary while leaving room to follow unexpected behavior.

Record the starting context with the charter:

• The risk or question, and the approved rule used to judge the result.
• The environment, build identifier, browser configuration and relevant feature settings.
• Safe test data and the starting state needed to reproduce an observation.
• The planned timebox, tester, scope exclusions and person who will review the findings.

These are recommended contents, not mandatory AgileTest fields. Put useful context in the scope description and carry attempt-specific details into the new item notes. For background on keeping the mission flexible without losing accountability, see the explanation of exploratory testing charters, session notes, and debriefs.

To create the scope in AgileTest, open the Exploratory Test section, select + Test Session, enter a Summary and the optional Description, then select Create. Use the summary to identify the investigation, not to predict that every check will pass. The description can hold the charter, environment and boundaries. Alternatively, open an existing scope only after confirming it is the intended investigation and that earlier evidence will remain distinguishable.

If your team organizes this work through an AgileTest milestone, choose the intended milestone deliberately. The component documentation says changing that selection reassigns the exploratory record and results. Treat it as a reporting-context change, not a harmless display filter.

Begin a Distinct Attempt and Record Findings as Items

Start each execution with a fresh attempt reference and starting-state description. A local label such as “checkout exploration, attempt A” is a note-taking convention, not an app-generated identifier. Reusing the same parent work item does not make the new build or test conditions self-evident.

Open the Exploratory Test detail screen through its key. When working from the Jira work item, the documented widget route is View apps > Test Session. Confirm that you are recording against the intended scope before adding evidence.

Use Item Timers Without Confusing Them With the Timebox

Select +Test Session Item to open the recording panel. In Elapsed Time, select Start when beginning that item's investigation and Stop when finishing the verification. The timer belongs to the item being recorded. Total Elapsed Time sums item elapsed times; it is not automatically the same as the wall-clock window you reserved.

Use a separate reminder for the planned timebox. The documented Start and Stop controls do not establish automatic expiry, a Pause button, or how restarting a timer handles earlier time. If interrupted, stop the current activity and record the interruption. On returning, make the resumed work's context explicit, using a fresh item where needed rather than assuming an undocumented pause-and-resume calculation.

A timebox limits how long to investigate before reviewing direction. It does not require forcing every open question into a final result. When the window ends, preserve the current evidence and record what remains unexplored.

Save Notes, Evidence and an Appropriate Item Result

In Notes, record meaningful actions, observations and the reasons for changing direction. “Checkout failed” is too broad. Identify the starting cart, the delivery option changed, the displayed total before and after, and the expected rule. Keep a possible explanation separate from what was observed: a stale total does not prove which service or cache caused it.

Use Attachments for supporting findings. A screenshot should identify the relevant state; a short recording can show the sequence that produced it. Reference the build and attempt in the notes, and use evidence labels that another tester can match to the files. Remove credentials, payment details and personal information before attaching material.

A new item defaults to TODO. The documented selectable results are Fail, Query, Blocked, Skipped, Retest and Pass. Choose the one that describes that item: an unclear requirement is a Query, while an unavailable dependency can leave work Blocked. Observation, hypothesis and question can be useful labels in prose, but they are not additional documented result buttons. Select Add to save the item into Session Logs and the Test Session Item Board.

The basic-information Status field synchronizes with the Jira ticket's workflow status. Treat that separately from item results and elapsed time. Moving the ticket to In Progress or Done is not evidence that a timer started or stopped, that every item was verified, or that a linked bug was resolved.

Give Each Actionable Finding a Linked Follow-Up

A finding needs a Jira bug, task or clarification request when it requires action beyond the session. Check for an existing report before creating another. Use the Jira creation controls available to your authorized project; the vendor walkthrough describes creating or linking follow-up work, but that does not establish a universal Create Bug button in every item panel.

For the app's item-level association, the documented control is the work item tracking dropdown. Add the relevant work item there and check the saved finding's reference. Do not assume this creates a particular native link direction, copies every attachment, adds a backlink to the bug, or synchronizes workflow states.

Make the follow-up understandable without requiring someone to reconstruct the entire session. Include:

• The exploratory parent key, explicit attempt reference and identifying item note.
• Build, environment, relevant settings and synthetic-data starting conditions.
• The shortest known reproduction sequence, expected behavior and actual observation.
• Evidence references, impact, unresolved questions and the next responsible person.

A native Jira link between the parent and a bug can aid navigation, using a relationship type configured by your administrator. It does not identify the exact finding or execution attempt by itself. Put that context in the follow-up description or a clear reference, and verify that the recipient can open both the work and its supporting evidence.

Linking a bug records a relationship. The defect's investigation, prioritization and resolution remain separate work. Likewise, a Query item needs someone to answer it even when no defect has been confirmed.

Work Through a Fictional Checkout Investigation

The following example is fictional. No application was tested and no customer defects or timing measurements are being reported.

Assume a QA environment running build checkout-candidate-B, a synthetic shopper and a resettable cart with an eligible promotion. The approved rule for this example requires the payable total displayed after a delivery change to agree with the final review total. The charter targets delivery changes after promotion application; live payment capture and performance measurement are outside scope. The team chooses a 45-minute wall-clock investigation window.

In attempt A, the tester starts with the ordinary delivery path and records a Pass item: the displayed payable total agrees with final review for that starting cart. The note identifies the cart fixture, delivery choice, build and comparison performed. This establishes one observed condition, not that all checkout combinations are safe.

Next, changing delivery after applying the promotion leaves the displayed total unchanged while final review shows a different total. The tester records a Fail against the assumed rule, then repeats the sequence from the documented reset state. Example attachment labels CART-before, DELIVERY-after and REVIEW-total identify the relevant captures. Those are illustrative labels, not real uploaded files.

The follow-up bug describes the mismatch without asserting an unproven backend cause. Its context identifies attempt A and the failed item, includes the reproducer and evidence references, and names the checkout engineer as the next investigator. The tester associates that Jira work item with the finding through work item tracking and checks that the reference is retained.

A further variation raises a different uncertainty: should the promotion remain eligible for another delivery service? Until the product owner clarifies the rule, the tester records a Query item instead of manufacturing an expected result. The question gets its own follow-up owner and remains visible in the debrief.

Suppose the saved item durations are 9, 18 and 11 minutes. Their total is 38 minutes. A separately recorded 7-minute interruption accounts for the rest of the 45-minute window. This arithmetic illustrates why the team's wall-clock budget and item elapsed total can differ; it does not demonstrate automatic interruption exclusion or any particular app pause behavior. The tester records the discrepancy explicitly rather than treating the totals as interchangeable.

Debrief the Activity and Retain the Retest Context

Before leaving the session, stop any running item timer and check that the intended notes, results, attachments and work references were saved. Review the record with a peer or lead: what was explored, what changed the investigation's direction, which observations support the reported concern, and which variations were never reached?

For the checkout example, the debrief assigns the total mismatch to the engineer, the eligibility question to the product owner, and any unexamined delivery variations to a later charter. Review in the intended milestone when your team uses that context. Record the gaps even if the Jira scope work item moves to Done. Finishing an investigation does not resolve its bugs or authorize release.

When a corrected build arrives, begin a new, explicitly identified attempt with fresh starting conditions and item evidence. Preserve attempt A's failure. The new record should identify the corrected build, rerun the original reproducer and state what additional variation was checked. If the behavior now matches the rule, record that result in the new context and follow the team's separate bug-verification workflow.

Consider the exploratory activity finished when another person can understand its evidence, its limits and who owns the remaining work. A closed ticket or a stopped clock alone cannot provide that handoff.