Test Management for QA Engineers

The projects that a QA Engineers participate can range from small maintenance projects, emergency fixes( spanning 1-2 days or less), mid-range projects(spanning weeks or months) to full-scale large projects( can last up to a year or more). While each of these projects may differ in terms of testing efforts and resources, they all adhere to common test process.

Let’s divide this test management process into 3 categories:

• Test Requirement Strategy
• Test Case Design
• Test Execution

1. Test Requirement Strategy

Gathering test requirements in an organized format that can be used for creating test plans and test cases. In order to effectively do this:

• Review available project materials
• Arrange meetings with several project team members such as domain leads, business owners, Business analysts, and project leads. 
• Ensure the test requirements are reviewed by all project team members
• Convert the test requirements into a test plan, followed by test cases

2. Test Case Design

Test case design activity resolves mostly around functional system testing. Designing test cases ensure that the system requirements and specifications are achieved by creating test conditions as part of the overall acceptance criteria. Test cases can be created using the following guidelines:

• High-level test cases(HLTC): Create test cases without detailed steps. A high-level test case could be as simple as having a title like “Login to Website successfully”
• Test Case Review: The author should review the HLTC before assigning it for peer review. Peer review is an enforced inspection to check that test coverage is completely based on the requirements gathered. Not all organizations follow this but it is a good practice to adopt to ensure there is good test coverage.
• Detailed Test cases: Once peer review is completed, detailed test cases are created. It is more refined and is generally written with details that include description, steps if required, expected results, actual results, additional notes, and test parameters (if any)
• Test strategy and Tactics: Different test approaches and techniques must be planned out at an early stage, QA Engineers utilize a balance of functional and non-functional techniques that can be used to develop and execute test cases. Testing includes controls to test for both positive and negative results.

Test Case Format

While creating test cases, follow the format below:

Title: The title should be concise and include the basic information needed to quickly identify what is being tested, what to expect, and under what conditions the test is to be run. It should be in Title case a

                    Functional Area: [Feature] (should  | Should Not) Behavior [ When]

Functional Area: This is required. It is a high-level functional area or component that is being tested.

Feature: This identifies the specific feature being tested. It is normally required. It can be omitted if the feature is implied. Such as when testing errors in the login functional area, or when the entire functional area is being tested.

Should | Should Not: This is required, If the test is confirming that something happens, use Should. If it's confirmation that something does not happen, use Should Not.

Behavior: This is required, it explains what should or should not be happening

When: This explains under what circumstances the test is run, such as “when the username is invalid”. if is not included in the title, “Every time” is implied. 

Test Case Steps

The test case steps are meant to let a tester know how to prepare the system for the test and how to test the feature. They should include enough details so that somebody with a basic understanding of the application can pick up a test case and execute it with minimal questions. They should not assume that the user of the test case will be an expert. If detailed instructions are needed to explain how to perform a specific step, it should link to ticket tracking systems with details. that way, if the instructions change due to a program change, only one place needs to be updated. 

Format: 

The test case must follow a GIVEN - WHEN - THEN rule. This provides documentation in a structured format for expressing scenarios.

For a specific scenario, you analyze three things:

GIVEN : what are the preconditions before the action is tested. What data is int he system? what are the set of parameters?

WHEN : What input data will be tested? what are the actions needs to be carried out?

THEN: In response to the action(WHEN), what should be the observable outcome? What are the expected behavior or results?

GIVEN:

There should be at least one “Given” test step. However, if the Given is None then it can be omitted. This should be relatively rare. The requirements are :

• Must start with “Given” to indicate that it is a prerequisite and part of the test case
• Must not have anything in the expected result since a “Given” step is not the focus of the test
• In the event of a failure on a “Given” step, the test case will be considered blocked, not failed.
• For complex prerequisites that are not obvious on how to perform, include a link to a ticket tracking system or other documentation so that somebody who has never run the test will know what to do

WHEN:

These are steps the user takes to perform the test. The requirements are:

• Must start with “When” to indicate it is an actual step. The When can sometimes be omitted if it makes the wording awkward. 
• Must have a “Then” in the expected result
• If is a multi-step action, the “Then” should start in the final “when” point. 

THEN:

This explains the expected result of a “When” step.  As a result, it should be in the expected result. The requirements are:

• Does not need to include “Then”, Since that is implied by being in the expected result.
• Must have a corresponding when in the action. If it is a multi-step result, then there can be only a single “When” for all steps. 
• There can be multiple “When” expected results for a single “Then” step.

Multi-Step Actions and Results

If an action or result consists of multiple steps, it can be split into multiple lines, Each line should be in a separate row, indented with four spaces, and begin with an upper case AND. This allows the user to see that it is a single test but allows each step to be checked off and passed or failed when running it. For Example:

Title: Successful login to an “X” Website

Action                                                                                Expected Result

GIVEN the URL for an “X” website 

WHEN the user enters the valid username            THEN the user is able to successfully log in to

 and password                                                                 the “X” Website

Review the Test Cases

When you receive a review request, the reviewer can follow the below checklist:

• Ensure the user has followed a standard test case format.
• Verify that the user has followed the requirements and the test cases have functionality coverage. 
• Look for redundant test cases and request to remove it. 
• It is possible that two or more test cases can test the same thing and can be merged into one by using parameters.
• Test data must be attached to the test cases links to the test data repository must be mentioned in the test cases. 
• Once you have reviewed the test cases, reply back with your feedback and comments. 
• Discuss and implement the changes required. 
• After the author makes the required changes if any. The reviewer can sign off and test cases will be ready for testing. 

3. Test Execution

Acceptance is an incremental process of approving or rejecting deliverables during development based on how well the deliverables satisfy the predefined criteria. The QA resources should encourage customers, business owners, or end users to be actively involved in defining and evaluating what type of information is required, and deciding if the product is ready to progress to the next phase. 

Start with smoke testing to determine if the application under test is stable enough to perform full testing.

This is followed by functional system testing that focuses on the following testing techniques:

• Requirements Testing: The goal is to verify that system performs correctly and the correctness is sustained until the system becomes operational
• Error Handling: The goal here is to verify that system can properly handle incorrect data. This is an iterative process that involves trial and error by first injecting an error and then correcting it, and then re-entering the same error to satisfy the correct error handling cycle
• Interconnection Testing: Most applications are frequently interconnected to one or multiple systems. The goal is to ensure that the interconnection between systems functions correctly
• Control Testing: The controls included in this testing are data validation, file integrity, audits, and other aspects of system-related integrity in compliance with policies and procedures. 
• Keep track of the test results to show the pass/fail status of the test
• Attach screenshots of the final test to the ticket for each requirement
• The QA resource has the option to perform selective or complete regression testing based on risk, scope, and type of change. In doing so, the impact of each on other system components should be assessed carefully.