In this article on software testing I’m going to cover one of the key elements of Software Quality Assurance, the Overall Test Strategy.
Understanding software testing and the broader scope of Software Quality Assurance is an important part of the project manager’s scope. It’s important because, when well documented and agreed to, it lessens the chance of project issues coming up along the way. It also helps to control scope, resources, and time and prevent delays in project delivery timeframes.
Software Testing: The Overall Test Strategy
One of the first deliverables a Project Manager should require from the Testing or QA Team is the Overall Test Strategy. It can go by other names such as the Master Test Strategy or just the Test Strategy document. This sets the tone or foundation for test planning for the entire project.
Photo Credit: lornlab
This project deliverable is often tailored to the particular company or organization that is performing the software testing.
Here are a few of the components you’ll find in many Test Strategy documents:
This section often covers the purpose of the document, the project overview, general priorities, system areas being impacted, business areas involved and any special assumptions that are being made as part of the software testing process.
Covered here will be the high level functions and/or features that are required to be tested. You may also find what is out-of-scope for testing purposes in this section.
An important part of software testing is to separate the “production” environment from the “testing” environment.
This is done so that no damage occurs to the application and its associated data in the environment where the end user is performing their job.
Many organizations have multiple test environments. For example, there could be separate environments for system testing, business user testing, or pre-implementation testing, among others.
The Test Environments section of the Overall Test Strategy is where all of this is documented, along with the approach of how testing will occur in each environment.
Closely associated with the environments section is the Test Data section. In this section, the approach for what data will be used for testing is covered.
Also, the approach for how the data will be populated into the environments is usually discussed. This includes the plan for refreshing data during testing.
Types of Software Testing
In this section the specific variations or types of testing are specified. This would include types such as Smoke, Functional, System, Regression, Downstream, Security, Usability and any other software testing type that an organization may perform.
This is a section where it is helpful to have a high level diagram of the applications that are being impacted by the project.
In this section the applications and functional areas that are in-scope to be tested are listed.
To maximize clarity, an organization will often list the “nearby” areas that are actually out-of-scope for the software testing effort as well.
This is also a section where you may see the business areas or groups that are considered in-scope and out-of-scope as well. Those named as in-scope may be called upon to perform software testing or validate testing results.
Defect Management and Problem Reporting
This section explains where defects will be documented and how the severity and priority of each defect will be defined.
This section also covers the administration of the process. For example, many organizations will have a regularly occurring defect review or “triage” meeting to discuss open defects and create plans for resolving them. This process is documented in this section.
While this article is by no means an exhaustive tutorial, I do hope you found it helpful. As a project manager, take the time to ensure this deliverable is completed as fully as possible. Do it early in the project.
Also, be sure to achieve buy-in from all stakeholders. By doing so your Test Strategy will serve as a strong foundation when software testing is occurring.