Test case review process

When the test engineer writes a test case, he/she may skip some scenarios, inputs and writes wrong navigation steps, which may affect the entire test execution process.

To avoid this, we will do one round of review and approval process before starting test execution.

If we don't go for the review process, we miss out some scenarios, accuracy won't be there, and the test engineer won't be serious.

All the cases need to be sent for the review process only after the completion of writing the test case. So, the other person does not get disturbed.

Once the author finishes writing the test case, it needs to be sent for the other test engineer known as a reviewer for the review process.

The reviewer opens the test case with the corresponding requirement and checks the correctness of the test case, proper flow, and maximum test coverage.

During this review process, if the reviewer found any mistake, he/she writes it in a separate document, which is known as Review document and sends it back to the author.

The author goes through all the review comments and starts doing the changes if it is necessary, then send it back once again for the review process.

This correction process will continue until both authors, and the reviewer will satisfy.

Once the review is successful, the reviewer sends it back to the test lead for the final approval process.

During this approval process, the Team leads are always kept in the loop so that the author and reviewer will be serious in their jobs.

When the test cases are written, review, and approved, it will be stored in one centralized location, which is known as Test Case Repository.

Note:

Test Case Repository

• A test case repository is a centralized location where all the baseline test cases (written, review, and approved) are stored.
• When the client gives the requirements, the developer starts developing the modules, and the test engineer will write the test cases according to the requirements.
• A test case repository is used to store the approved test cases.
• Any test engineer wants to test the application, then he/she needs to access the test case only from the test case repository.
• If we do not require any test case, we can drop them from the test case repository.
• For every release, we maintain a different test case repository.
• Once the test cases are baselined or stored in the test case repository, they cannot be edited or changed without the permission of the test lead.
• The testing team always has a complete back-up of the test case repository if any crash happened which is affecting the software.

Review Process

While reviewing, the reviewer checks the following aspect in the test cases:

Template

The reviewer checks whether the template is as per requirements for the product or not.

Header

In the header, we check the following aspects:

• All the attributes are captured or not.
• All the attributes are relevant or not.
• All the attributes are filled or not.

Body

In the body of the test case, we will check the following aspects:

• The test case should be prepared so that it should take minimum time for the execution process.
• All the possible scenarios are covered or not.
• Look for the flow including maximum test Coverage
• The test case design technique is applied or not.
• The test case should be simple to understand
• Proper navigation is written or not.

Once the test case is reviewed, the review comments will be sent to the test case review template.

The reviewer will use the above template and send the comments. If the author fixes the test case, he/she would report it as fixed.

Text Execution Report [Excel]

It is the final document, which is prepared by a test lead when the entire testing process is completed.

The test execution report defined the stability of the application and contained the information like the number of cases written, executed, pass, fail, and their percentage.

The test execution report is a final summary report based on which the quality of the application is defined, and it also helps in deciding that the application can be handed over to the customer or not.

Every module has a separate spreadsheet of their respective module.

Let see one example of a test execution report where we have different modules such as Sales, Amount transfer, Tax, Loan.

The test lead made this report, and the test engineer sends the individual features that he/she has tested and executed.

The test lead sends this report to the following:

• Development Team
• Management
• Test manager
• Customer

Where a development team needs the list of failed test cases.

As we can see in the below table that we have a list of test case names, related status, and comments.

The below table is showing the amount transfer test case data.

Amount Transfer