Quality Assurance process can be easy as A, B, C or complex, consisting of the several stages, sub-tests, hundreds of checks and repeating iterations.
Every approach needs a good plan and strategy though. Without them your project testing may turn out messy, some significant but quick-to-do tasks can be forgotten, and the delivery will be postponed or even failed. Such consequences result in a dragged overall development process and may even lead to tech debt. TestFort team of QA experts always documents every project with excellence and highly caring attitude to achieve supreme quality of the code at the end. Today we share our expertise and review how the notions of Test Plan and Test Strategy are different from each other on the example of cross-platform software testing.
Don’t mix Test Strategy with Test Plan document
Test Strategy documentation is usually composed by project managers. It is a static document that specifies how QA process is carried out in the company. It doesn’t include all peculiarities of potential projects but defines overall testing standards which are usually followed while writing Test Plans for every project separately. Sometimes even a couple of Test Plans, if required.
The key components of the Test Strategy are as follows:
- Scope and objectives
- Business industry standards to follow
- Key business issues to pay attention to
- Roles and responsibilities
- Status reporting
- Testing tools
- Possible risks and ways to leverage them
- Configuration or changes management
- Issues tracking and reporting
- Test deliverables
Down to the Test Plan in software testing
The Test Plan in software testing, is a super-informative document that lists everything there is to know about a project that’s going to be tested by QA engineers. It is normally composed with the help of the Test Strategy document but with additional information about the particular project.
The following components make a Test Plan document:
- Project ID
- Components to be tested
- Components that won’t be tested
- Testing techniques
- Task Distribution
- Suspension criteria
- Resumption criteria
- Risk management
- Testing tools
- Devices to be used
- Test deliverables and schedule
- Approval criteria
Cross-platform testing: planning and strategizing
Now, as you more-less understand the difference between Test Plan and Test Strategy, let’s get down to the specifics. Cross-platform testing, aka compatibility testing, is aimed at making your software compatible with the most used and less used platforms, systems, devices, web-browsers, etc. The strategy of cross-platform software testing has to be well-established, otherwise engineers can mess up the project. Let’s review a couple of key points of Test Plan and Test Strategy to grasp the idea of how QA documentation is composed for some specific testing type.
In Test Strategy and Test Plan documents there are scope and objectives items. The first document shows how scope and objectives have to be determined. The second document sets planned workload for the specific project. It is important to make sure that both vendor of the QA services and the client know what goal has to be achieved at the end of collaboration. The plan for cross-platform testing has to describe what kind of project has to be examined, what its purpose, functionality, and demonstrates what has to be covered overall, without going into the detail.
Components to test/not to test
This item is a detailed review of specific software components that can/will be tested. Depending on the complexity of the software that needs to be tested — there are usually components that don’t need to be checked. This is quite important part of testing documentation that needs to be well-negotiated and clear up to the point when the QA process actually begins.
Roles and responsibilities
To avoid misunderstandings within the team, all roles and responsibilities have to be discussed and fixed. There’s usually Project Manager, who plans and controls working process along with negotiations with the client, QA Team Leader, who divides, distributes, and controls the quality of the work done, and QA engineers, who test the product. These roles have to be clearly communicated to the client and documented.
Tools, testing techniques, and devices to be used in the QA process like for cross-platform testing, are listed in the Test Plan document to provide the client with maximum information and bring more understanding of what and how will you check the software. Test Strategy documentation usually includes this item as well, and demonstrates all tools and devices that company acquires, along with the list of testing techniques that can be applied.
Test deliverables and schedule
Iterations, reporting, documenting, and test cases delivery processes has to be planned beforehand. There always has to be at least approximate schedule of test deliverables, which is needed to shape the project within a time scale, put it under certain conditions, organize the team, and help plan the next one.
Possible risks and ways to leverage them
There is a possibility that some time, something may go wrong in the course of cross-platform testing process. For such cases, all possible risks have to be negotiated before they actually happen. Moreover, potential solutions to the issues, along with suspension and resumption criteria, also have to be documented for the sake of security, transparency, and trust within the vendor and the client.
TestFort team is keen on high quality as we aim to build trustworthy relationships with our customers. We believe that well-composed testing documentation is a half of successful service. This is the reason why our certified QA engineers win globally-recognized awards, and consistently level-up their skills. Contact us if you want to get your software polished till it works like a clock.