Test Execution In Software Testing: Exact Process And Plan With Example

An ordered guide and outline for executing test scenarios, featuring practical demonstrations.

In this section of our Software Testing compact training series, we’re nearly at the conclusion of the Software Testing Life Cycle (STLC), specifically the Test Execution stage.

To view all the lessons in this complimentary QA teaching series, here is the page: Complimentary Web-Based Software Testing QA Training Course.

Undeniably, the Test Execution is the most pivotal and energetic stage in the STLC and the overall software development cycle. This stage is crucial because it is where the collective contributions and effort of the entire team are validated:

• Did the Business Analyst interpret the requirements accurately?
• Did the development team properly transform the business requirements into functional needs and then into code?
• Did the data architect and DBAs design the right back-end systems?

You’ll find all the responses to these inquiries in the test execution. Therefore, we QAs, in a sense, become the champions of the entire software development process, right? 🙂

The Test Execution phase is also a significant part of the Software Development Life Cycle (SDLC).

The test case writing process concludes when the test cases are written, reviewed by the BAs and Dev team, and any necessary changes have been conveyed to the QA team. However, having the test cases prepared doesn’t immediately mean we can begin the testing process. We need to verify that the application is ready for testing, among other considerations.

Test Execution Principles

Let’s outline a series of key points to understand the Test Execution stage:

#1) One of the most vital parts of Test Execution is the deployment of the build (the code authored by the development team compiled into an installable software, known as a build) to the QA environment. This is a requirement for initiating the Test Execution stage.

#2) Test Execution is conducted in the QA environment. Typically, there are separate environments for development, QA, and production to maintain the integrity of the application throughout the SDLC. These environments should ideally be identical.

#3) The size of the test team may fluctuate during different project stages. There might be only a team lead at first, and as the test design stage progresses, more testers join the team. The Test Execution stage is when the team usually reaches its full size.

#4) Test Execution usually occurs in multiple cycles (generally 2 or 3). Every test case in the test suite gets executed during each cycle. The goal of the first cycle is to discover critical and most of the high-priority defects. The second cycle concentrates on identifying remaining high and medium defects, closing gaps in the test scripts, and producing results.

#5) Test Execution comprises the execution of the test scripts, maintenance of the test scripts (identifying and solving gaps), and reporting defects, status, metrics, etc. When planning this stage, it is essential to estimate the effort required for all these activities, not just the script execution.

#6) Before Test Execution, there’s an intermediate step known as the “Test Readiness Review (TRR).” This step marks the transition from the test design stage to the test execution stage.

For additional details on this step and to download a sample “Test Readiness Review checklist,” you can follow this link: Software Testing Checklist

#7) Apart from the TRR, there are several other checks before acknowledging the current build deployed in the QA environment for test execution. These checks comprise Smoke and Sanity tests. To understand more about these tests, you can access: Dissimilarity between Smoke and Sanity Test

#8) After successful completion of the TRR and Smoke/Sanity tests, the testing cycle officially begins.

#9) Once the build is ready for testing, Exploratory Testing is usually performed. This test aims to identify and rectify critical defects before advancing with further levels of testing. Exploratory testing is carried out without test scripts and documentation and assists testers in becoming familiar with the application.

#10) As with other stages of the STLC, work during the Test Execution stage is divided among team members. This division can be based on modules or test case counts or any other logical approach.

#11) The main outputs of the Test Execution stage are the Defect Report and the Test Execution Status report. Reporting is a vital element and can be made easier using a Test Management tool. However, the actual process of running the test cases remains unchanged. You can refer to this article to understand Test Case Execution using HP ALM (Application Lifecycle Management).

Additional Columns in the Test Cases Document

Two new columns have been added to the Test Case document: Status and Actual Result.

(Note: For live project Test Execution, we have included and updated these columns with test execution results in the downloadable test cases spreadsheet provided below)

#1) Status Column

During Test Execution, the test steps from the test case document are applied to the Application Under Test (AUT) using the identified test data. The behavior of the AUT is observed to ascertain if the expected result is met. If the expected result is not met, it signals a potential defect and the test case status is marked as “Fail.” If the expected result is met, the status is marked as “Pass.” If a test case cannot be executed due to existing defects or unsupported environments, the status is marked as “Blocked.”

A test case that has yet to be executed can be labeled as “Not Run” in the status column or left blank.

• For test cases with multiple steps, if a certain step does not match the expected result, the status of the test case can be marked as “Fail” at that point, and the remaining steps do not need to be executed.
• You may highlight the “Fail” status in red to draw immediate attention.

#2) Actual Result Column

Testers can record any deviations from the expected result in this column. If the expected result is met (or if the test case status is “Pass”), this column can be left blank. Including it in the actual result column would be redundant since the actual result matches the expected result.

A screenshot showing the deviation can be attached to this column for better clarity.

Test Execution Results for the OrangeHRM Live Project

Next, we’ll implement the guidelines mentioned above to the OrangeHRM project and carry out the test execution using practical examples.

A few important points to remember:

• The expanded test case template is provided.
• As pointed out, exploratory testing should be conducted without test scripts. Feel free to explore the application at the same time according to your own preferences.
• Because of limitations in presenting the live project content, only a limited number of test cases and features from the OrangeHRM application are illustrated in the sample Test Execution template. You’re encouraged to work on additional test cases for a more practical experience.
• The document includes the Sanity and Smoke test suites to give you an idea of the types of test cases used at these stages.
• Despite the “Fail” status of some test cases, defects have not yet been logged. Details about the logging of defects, an essential aspect of our role as testers, will be explained in the next article.

Test Cases including Execution Results:

=> Click here to download the Test Case Execution report.

It Includes – Test cases execution result, Smoke tests, Sanity tests, Exploratory test spreadsheets

Lastly, if you have been using a Test Management tool to create and manage your test cases, you can also use it for test execution. Using a tool can ease the reporting process, but the actual test case execution process remains unchanged. This article provides insights into using HP ALM (Application Lifecycle Management) for Test Case Execution: Test Execution using HP ALM.

(Click on the image to enlarge)

We have concluded yet another fascinating facet of the testing process. In the subsequent–and final–article of this complimentary web-based Software Testing QA training compact series, we will delve into defects in greater depth, cover items such as “when to stop testing,” discuss metrics, and tackle the QA sign-off.

=> QA Training Day 6: Bug Tracking, Test Metrics, and Test Sign-off

We’d appreciate hearing your thoughts, so don’t hesitate to share how we’re doing. Look forward to the upcoming article!