Perhaps, you can do without a deliberate testing strategy, especially if your team has a lot of dedicated workers, costs, and time.

In other words, if you deliver web products once a year and “once in a blue moon.”

In these perfect conditions, you won’t need any strategy since you have a possibility to test your software functionality for several months, in different ways, using available technics and strategies in any logical order, even for several times, and, sooner or later, your software will be ready for production.

But in reality, you will certainly face certain challenges while working on a project; lack of qualified workers, constantly rising requirements – and you can’t do without a clearly defined plan anymore. And proper building and further implementation of a testing strategy will help you to solve these problems.

Further, we’ll try to analyze all aspects that are somehow connected with a process of building an efficient testing strategy, and we’ll also provide examples of how to make a decision on testing tools in any given situation.

So let’s start

Why do we need a testing strategy?

The answer is simple:

• To establish efficient software testing with limited resources. This means that the first thing we should think of is what resources are available;
• To make every project team member understand the meaning and the role of testing, the results that can be reached with its help, and the advantages that it can bring. In other words – to make every project group member have equal expectations and understanding of what is happening in a quality assurance field. And definitely, to rapidly find potential problems that will happen inevitably during software development.

Who should build a strategy?

Primarily, it’s obviously a task of a tester and a project manager.

Types of testing: which ones should be used and why

First, let’s recall the testing types that exist and where each of them will be the most suitable. It’s better to analyze this topic by providing certain examples which will help you understand a pattern of using a certain type of testing.

Installation testing

Even if an application is new and is installed for the first time, you should check the way it starts working: whether it launches or not, whether there is a possibility to interact with its established logic. No matter –whether it’s a mobile, web, or desktop application.

In a web product, you should verify that updates did not disappear after a product had been launched and the way a product should behave during an active session.

As for mobile and desktop applications, you should discuss the ways of delivering a new distributive to an end-user and also, an updating process, that starts when a client starts working with a utility.

For every project, it’s recommended to discuss such items as system warm-up: installing directories, registering the users, and other data that a client needs to start using a product.

Performance testing

The following factors will affect a final decision on a product: the number of potential clients that can work in a system, amount of data that will be used.

What we have	How to solve it
We have data that a product will be used by 20 users or less. We also know that they will constantly operate the tables with numerous values.	It’s important to perform volume testing with a lot of input data.
We have information regarding the fact that clients will upload media files to a server while working with a product.	We should define a maximum number of files that can be uploaded to a server and keep this information in our mind.
A product is used by approx. 3-4 users a week.	We don’t need to perform performance testing.

Regression testing

It takes much time to test the overall system’s functionality. Therefore, it’s crucial to estimate the time that will be spent on performing complete regression testing and the risks that may arise if regression testing is not performed.

What we have	How to solve it
We launch the first version of a product and its components.	We don’t need to perform regression testing.
A project is quite big and complete regression testing requires as much time as a product’s development. The deadline by which a product should be delivered to a client doesn’t include this.	We don’t need to perform regression testing but we should work on implementing other tests.
The entire structure of microservices is covered with automated contract tests.	We don’t need to perform regression testing. We should only perform manual regression testing of functionality only when a team of developers asks for this.

Integration testing

To estimate the necessity to perform integration testing, we need to list all external systems that somehow interact with a product and mention the data we operate and transfer.

What we have	How to solve it
All data on offers are transferred from a portal to an analytical system.	It’s important to check not only that sales transfer to a proper place and in a proper form but that they are properly delivered – that nothing has been lost during this transfer.

Localization testing

We should answer the following questions:

• What languages are supported by a system?
• Can we switch on additional localizations while using a product?
• What countries is this product targeted at?
• Is there a need for interacting with different time zones?

What we have	How to solve it
A web product’s system provides two languages: French and Russian.	It’s important to discuss with a project manager what interface and in what language must be displayed to a user.
A client wants a product to be multilingual.	You should answer the following questions: in what way a system should verify text blocks, where you can find blocks in Arabic, what resolution should be used for displaying the text that is commonly written right to left.

Cross-browser/cross-platform testing

Developers can’t check a mobile application on all mobile devices.

When we talk about desktop applications, we may ask: will we test it on IE11?

Before we start testing an application, we should thoroughly analyze on what operating systems and browsers it will be used most frequently.

What we have	How to solve it
All residents of a country can use a mobile application.	You should analyze data on using mobile platforms for your product and make a decision on which ones you will test its performance.
Only corporate workers use an application on their local machines.	You can recommend using only one browser. This will help to reduce the time needed to perform cross-browser testing of a utility.

Therefore, we should work on other types of testing:

• Regression testing (whether it’s needed or not);
• Acceptance testing;
• Criteria of a perfect interface;
• Unit testing;
• Performance/security testing;
• Failover and recovery testing (how a product behaves in extreme conditions)

Testing priorities

Development of every product may go together with certain unexpected situations so it’s very helpful to have “a cheat sheet” with a defined plan, to not search for a solution in technical documents of related projects.

Even in a normal mode, established priorities are very important. For example, creating a set of automated tests should be planned, taking established priorities into account: the most critical scripts are primarily automated (this process is also called smoke testing).

What we have	How to solve it
A product that is being developed is used during the pre-onboarding of passengers for flights in airports. If something breaks, a team of developers will have no time to fix it. Therefore, there must be no bugs and critical errors.	You should primarily test a script of using a system in an airport.

Work environment

It’s important to think about and approve with every department of developers the environments that are needed for work and who will use it. You can commonly use two-three environments and one production.

What we have	How to solve it
A system contains CD/CI, smoke tests are created to perform primary testing of the product’s functionality.	You need to have an environment to build software code in one branch, running all smoke tests where all external systems are closed with so-called “stubs.”
Beta testing is constantly performed.	We need an environment that can be seen from the outside and that will be more stable than a QA environment.

Tasks that a tester should do on a project

It’s important to discuss in advance all potential actions that must be done by a tester during his/her work on a project since such actions can be very different from each other, depending on the products that are being developed.

This point will help a project manager understand what level of competence can be put on a tester and how much time is needed to do the defined tasks.

You can discuss the following points with a team of testers:

• The time needed to execute testing tasks;
• Creating a set of automated functional tests;
• Updating the testing strategies;
• Manual test execution;
• Reviewing the automated test scripts.

Maintaining test documentation on a project

Before starting to work on a project, you should also discuss a type of documents and then simply review it:

• What type of documents will be used on a project;
• Are test cases up-to-date;
• Whether a test team works on checklists or not;
• How frequently these documents will be updated.

What we have	How to solve it
Approximately 300 test cases have been created for a developed product. They don’t need to be run once again and be updated.	Put all test cases aside and give preference to interaction with simple checklists that are created to perform a certain task.

Criteria of how to start and end a process of testing

If a QA engineer can switch to another task anytime – it’s not a schedule but complete chaos. Since this task can be simply not ready. Or ready but not deployed. As a result, a tester spends his/her time on bug searching, though he/she could actually wait until the tasks on this functionality will be completed.

When multitasking becomes more common on a project, you should operate clear criteria that this function or system is ready for a test.

What we have	How to solve it
There is a rule on a project that every update or test should be displayed in a checklist.	A task can be considered checked only in a case when we have followed all steps of a checklist.
Work on a project is done by sprints.	A sprint is completed when all edits and comments have a “Closed” status.
A project has a set of written test cases and regression testing is being performed.	Regression testing has resulted in no bugs found.

Conclusion

Unfortunately, there is no unified and universal testing strategy. It should be established each time when a project group starts working on creating a new product.

• It’s important to understand the fact that a testing strategy must not be your target – its’ a simple tool that helps to reach certain results;
• Right after writing a strategy, it becomes clear where are failures and how to fix them;
• A strategy must be updated even during a final stage of software development since its relevance is a key to the overall performance of an entire team.