Eight states increase the accuracy of test case states

In general, the test case status is recorded in the work in three states: Pass (pass), failure (fail), and queued Wait (in queue). But I tend to represent the life cycle of a generic test case more accurately, even though the cycle of your tests changes. Here is a list of the test case lifecycles I used:

queued (in queue): The test case has been assigned to a tester and is not ready to run in this test phase.

in Progress (IP): The test is in progress and lasts for some time. (If a test takes less than a day, I don't say a test is marked as in-progress because I track the status of the test case every day)

block: Some factors can cause the test to fail, such as a lack of functionality or a lack of a part of the test environment. I usually record the blocked status in the comment bar of the test Case Summary worksheet. You can understand blocking as: I want to run the test, but I can't run the test yet.

Skip: You decide to skip a test at the current Test stage, possibly because it has a relatively low priority. (Again, I'll record the reason I skipped this test in the Comments column of the test Case Summary worksheet.) You can think of skipping as: I can run this test now, but I don't want to run it.

Pass: The test run is finished, and the test person gets the expected test result status and test behavior.

failure (fail): In many cases, testers get unexpected test results, state or behavior, and these results differ significantly from the test objectives. This raises questions about the quality of the system. One or more test errors need to be recorded.

Warning (Warn): In many cases, testers get unexpected test results, state or behavior, but these results are not very different from the test objectives (I usually write a warning in the pass-through column of the test Package Summary worksheet, not a single column). Another idea is that a warning means that the current error is irrelevant, or that there is no point in the feature being tested. The system reported more mistakes. One of my criteria for dealing with this problem is that the tests that are only related to the delay or the error that are not necessarily changed can be flagged as warnings, not failures.

off (Close): A test in which the first loop is marked as a failure or warning, the second Test release modifies the error that occurred in the first Test loop. No error occurs after the entire test case has been rerun. Marking this type of test as off rather than passing allows you to track the fact that the test failed in one of the test releases (as with a test marked as a warning, the tests that I marked as closed in the test Package Summary worksheet are also included in the success category).

Eight states increase the accuracy of test case states