Test result
The record of one execution of one test case in one run: its status, who or what ran it, when, how long it took, and the evidence attached. Results accumulate into history, and history is what makes flakiness, stability trends and pass-rate comparisons possible. A tool that stores only the latest status has thrown that away.
A status is not enough
Failed tells you something broke. The comment, the screenshot and the linked bug tell you what. A failed result with no evidence sends the next person back to reproduce it from scratch, which costs more than the thirty seconds it took to attach a screenshot. For automated results the evidence is the trace, the video and the error message; for manual ones it is a short note on what was seen and a screenshot of it.
Blocked and skipped are not failures
A case that could not run because the environment was down is Blocked, not Failed. Marking it Failed lowers the pass rate for a reason that has nothing to do with the build and hides the real failures among the noise. Teams that need finer distinctions add custom statuses, and the decision that matters is how each one counts.
Do not overwrite, re-run
When a fix arrives, record a new result instead of editing the old one. The failed result followed by a passed one is the evidence that the fix worked. Editing the failure to Passed erases it, and with it the trail a reviewer or an auditor would follow. Retries in automation work the same way: a test that passed on its second attempt is a different signal from one that passed on its first, which is how flaky tests get found.
In QAM Hub
Each result keeps its status, tester, time, comment and attachments, and can be linked to bugs in the issue tracker. Automated results keep the error and stack trace; Playwright videos and traces are kept for 14 days on Start, 30 on Standard and 60 on Advanced, while screenshots and manual attachments are not removed automatically. The statuses are listed in execution statuses explained.