A tester can finish a field session without reliable access to Jira and still return results to the right execution records. The difficult part is preserving which attempt each observation belongs to, then checking what the import changed. A workbook can contain the right outcome while its imported case status, tester attribution, or timestamp differs from what the team expects.
QMetry Test Management for Jira Cloud documents an Excel round trip for existing test-cycle executions. This is functionality of the installed QMetry app, not native Jira behavior or a procedure for QMetry Enterprise, Server, or Data Center. The guidance below follows the current Cloud documentation. The example is fictional; no live export, import, or tenant test was performed.
The workbook must return to the same QMetry instance and space from which it was exported. Re-import updates existing cycles and their exported executions; it does not create new test cycles. Archived or deleted cycles are excluded, and archived executions are not included in import processing.
The documented permission is Test Cycle Execute for both export and import. Before an authorized team uses the procedure, confirm access, the target space, and the current app screens. Documentation-backed labels do not establish that every tenant has identical navigation or settings.
Choose an import owner and agree which executions will be handled offline. As a team convention, avoid parallel edits to those same attempts until reconciliation is complete, or explicitly review any online changes before returning the file. The documentation does not establish an automatic merge or conflict-resolution guarantee.
Keep a separate review note identifying the cycle, selected execution scope, environment, build, offline tester, and intended importer. These are suggested handoff notes, not extra columns to add to the exported workbook.
Use the export route described in the Cloud re-import guide, rather than assuming that any execution report is a valid import file.
The guide permits a maximum of 20 cycles in one export. Choose the with-steps option when the offline tester needs to record step results and actual outcomes. A case-only export is appropriate only when case-level recording is sufficient and the team understands how import propagation will affect the existing steps.
The exported identifiers connect the workbook to existing executions. The guide calls out Execution UID identifiers, alongside cycle and case keys, version information, and execution numbers. Keep the exact headers and values supplied by the actual export; do not substitute a locally designed identifier format.
Parameterized steps need particular care. QMetry exports rows according to the parameter-group combinations shown on the execution screen. Repeated-looking step text can therefore represent different combinations. Do not deduplicate rows merely because their descriptions look identical.
Treat the working file as a return channel for the exported records, not as a new test repository. QMetry says not to delete, modify, or add columns, particularly column names and unique keys or IDs. Mapping is automatic, and structural changes can cause errors or skipped records.
Keep cycle keys, case keys, execution identifiers, and the exported version and execution information unchanged. Update only fields documented for the round trip, using values valid in the target space. The guide describes execution results and fields such as Build, Environment, Comments, Actual Result for steps, Actual Time, Planned On, Executed By, and execution custom fields. Do not interpret the presence of a descriptive column as permission to rewrite the underlying test definition.
A practical handoff check is to compare the working file with the untouched original:
These checks are a team review practice, not a claim that QMetry locks the workbook. Cases or steps that were not in the original export are ignored during import, and re-import does not create new field values. Adding rows or inventing an environment name is not a supported way to extend scope.
Keep any sensitive evidence in the team's approved storage location. A spreadsheet can carry observations without proving who performed them or when they happened. If offline timing matters, preserve the original date, time, timezone, and tester in separate evidence notes or an appropriate supported Comments field. Do not repurpose an execution identifier or add a timestamp column to the import schema.
Before editing results, establish the space's auto-propagation setting and whether the file includes steps. The import guide defines the following behavior. These are import-specific rules; they should not be replaced with assumptions drawn from interactive case-status updates on the execution screen.
Check | Auto-Propagation | Case Result After Import | Step Results After Import |
|---|---|---|---|
File includes test cases and steps | On | Calculated from step statuses; the file's case status is ignored | Imported from the file |
File includes test cases and steps | Off | Imported from the file | Imported from the file |
File includes test cases without steps | On | Imported from the file | Case status is copied to the steps |
File includes test cases without steps | Off | Imported from the file | Existing step statuses do not change |
With steps and propagation on, a disagreement between the workbook's case result and the resulting case status may be the documented calculation, rather than a lost cell. Without steps and propagation on, a case-level update also changes step statuses. Decide whether that is appropriate before selecting the case-only route.
When propagation is off and steps are supplied, case and step results can be imported independently. Review inconsistencies instead of assuming that import will reconcile them for you. The table does not define every status-precedence rule in a configured space, so do not predict an exact calculated status without checking that configuration.
Execution Assignee represents the user assigned to execute the test case. Executed By is a different field. For this Excel import, QMetry states that Executed By takes its value from the file; if the value is missing, it defaults to the user performing the import.
A coordinator uploading a tester's workbook can therefore become the recorded execution user when that field is blank. Confirm the intended, valid Executed By value before handoff. Neither an assignment nor the importer's identity alone proves who performed the offline work.
The guide says Executed On is set to the current date and time during import, and data for it in the import file is ignored. Do not use the imported timestamp as a reconstruction of the offline session.
Actual Time is also distinct: it represents execution duration, not the calendar timestamp. The import guide says it is imported regardless of timer settings. Retain the tester's supported duration value without presenting it as a measurement produced by an online stopwatch during the offline session.
Before uploading, the import owner should confirm the same instance and space, unchanged identifiers and structure, matching with-steps or without-steps format, valid mandatory values, and the intended propagation behavior. If a cycle or execution changed while the team was offline, resolve that discrepancy before assuming the older workbook can be returned safely.
The documented re-import route is:
The guide specifies a file size up to 10MB and a maximum of 20 cycles or 5000 records per import. Check both scope and file size, particularly when parameterized steps expand the workbook. Do not assume that 5000 records means 5000 distinct test cases.
A success message does not prove that every intended value was accepted. Missing or invalid mandatory system or custom fields cause import failure and validation errors in the post-import logs. Missing required columns also prevent import. Invalid nonmandatory values can be skipped while valid data is imported, so review those fields even when the operation proceeds. The guide also says Excel import operations do not trigger email notifications; use the documented progress and record review rather than waiting for an email.
Reconcile by the original execution identity, not the displayed summary alone. Compare the intended case and step results with the actual records under the selected propagation rule. Check Actual Result and Comments where used, Build and Environment, mandatory custom fields, Executed By, and the import-time Executed On value. Record unresolved or skipped items separately and assign their correction to an owner.
Avoid unrelated repair actions. The grid execution documentation describes syncing the latest test-case version as resetting execution statuses and erasing execution values. That is not a harmless way to fix a malformed offline file. Preserve the returned workbook and diagnostic information, understand the specific rejection, and agree a correction before another authorized import.
Imagine a separate review note for an existing cycle exported with steps. The labels Checkout attempt A and Refund attempt B below are explanatory aliases, not QMetry UID values or a replacement upload template. No import has been run.
For Checkout attempt A, the tester records a successful case result while one step is unsuccessful. The reviewer first checks the propagation setting. With propagation on, the documented expectation is a case result calculated from step statuses, with the workbook's case result ignored. With propagation off, both levels are imported as supplied, so the inconsistency requires human review. Neither route justifies inventing an exact aggregate status without the space's rules.
For Refund attempt B, Maya performed the offline work and Leon will upload the file. Executed By is blank. The documented expectation is attribution to Leon, the importer, rather than automatic recognition of Maya. The reviewer asks for the appropriate valid field value if Maya should be attributed and retains the original offline evidence separately.
For both attempts, the review note preserves when the offline observations were made, including timezone. Executed On after import is expected to reflect import time, not that earlier observation time. The reviewer then checks the actual execution records and import diagnostics. The worksheet's expectations are a review aid, not evidence that an upload succeeded.
Assign one person to close the reconciliation: identify which exported attempts were updated, which values were skipped or rejected, and which discrepancies still need action. Keep the original export, returned file, and review evidence according to the team's own policy.
The useful completion criterion is that the intended existing executions contain the reviewed results, with understood propagation and provenance. Connectivity returning, a file uploading, or a current Executed On timestamp is not enough to establish that outcome.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
