A test result says “Failed”. The attached screenshot shows “Connection interrupted”. A developer reproduces exactly that message, which is what the portal is supposed to display when the connection drops. What actually went wrong?
For a retry scenario, check the state after the warning. The fictional ServiceDesk example includes a case for preventing duplicate requests after a retry. If a response is interrupted and the customer retries, that one logical operation should leave exactly one request.
Give the next tester something to reproduce
Here is a fictional example of a failed result. The build and references are sample values:
Build RC2, test tenant, customer role. Submitted one request titled “Demo printer”. Interrupted the response on the test network, restored the connection and clicked Retry once. After reloading the list, two references were present: DEMO-41 and DEMO-42. Expected one request. The duplicate appeared in two out of three independent attempts.
This separates actions, observations and expectations. It does not yet tell you whether the browser submitted twice or the server processed the same message twice. Leave the cause open until someone has evidence for it.
Attach evidence of the discrepancy
For this case, a crop of the reloaded list showing both references is more useful than the connection warning. If the question is how many requests left the browser, a sanitised network trace may help. Check for access tokens, cookies and personal details before attaching it. These five lines are enough to start a report:
Build, environment and role: Starting state and test data: Action, interruption and retry: Expected / actual state after reload: Evidence and frequency:
Retest on a new build
Repeat the same sequence with fresh data on the corrected build. Also run the ordinary submission without interrupting the network. One successful attempt tells you little about an intermittent failure. Record how many times you retried and what the list contained each time. Keep the original result attached to the old build and the retest attached to the new one.
In Zeta Test Management, recorded observations and attachments belong with the run result. You can also link an issue when your installation has the integration configured. See reviewing results in the browser for how to find the underlying results when investigating a report.