Planning Of Quality Assurance Activities

Planning is not just to write documents and to match terms. Planning is the first step toward achieving the set goals. Quality Assurance (QA) planning can be defined as an activity aimed for optimal resource allocation and goals set for a successful QA process.

Let’s have a look at the most important steps more precisely.

Test plan creation

Test plan is the main document of QA process that describes what testing activities are required. The main purposes of a test plan are:

Defining a scope of work and test strategy

Prioritizing the tasks

Estimation of labor costs

Estimation of resources required (software, tools)

Creating a test plan, you can use some common templates or prepare a specific plan according to your particular needs. But even if you decide to elaborate your own plan from scratch, it still should contain answers to the next questions:

Test strategy consideration

Test strategy can be either a separate document or a part of a test plan. It should contain detailed information about:

Testing types for each separate component and functionality

Testing tools and techniques to be used

Configurations required for testing activities

You can create a test strategy for the whole product at once or elaborate it gradually for each function. It works like this: as soon as developers receive the next task to conduct, testers at the same time consider a test strategy for this new component.

In a test strategy, you can also:

Identify a purpose for each testing type

Mention all the techniques applied to each testing type

The information in the test strategy can be presented either in a form of a standard document or in a more visual form, e.g., table.

Risk assessment

Risk can be defined as a probability of problems caused by software bugs. These difficulties can cause financial losses, spoil the company’s reputation, decrease the level of customers’ trust, increase the time and resources required for project implementation. So, risk management strategy is a quite important part of QA planning.

Information about project risks is also used to define priorities of the testing activities. For example, if the system performance is the high-risk aspect of the product, you should conduct the performance testing as soon as possible.

To analyze risks, you should consider:

How important is the problematic functionality?

How notable is the problem for customers?

Risks do not always concern the product itself, but also:

Specialists qualification

Management problems

Lack of tools

Effort and time estimation

Effort and time estimation help to define:

Approximate cost of QA stage

Time terms

Schedule of works

There are a lot of methods used for effort estimation. Some of them require serious mathematic calculations, but some are much simpler to apply. Here are some of them.

“A shot in the dark”

Using this method, you should rely on your previous experience or just your intuition. Naturally, “a shot in the dark” is among the riskiest effort estimation techniques.

Estimation by experts

The name of the method speaks for itself. By the way, not only experts in the specific field can be engaged, but also other people who have a good understanding of the product under test.

Work decomposition

The work on the project is decomposed into the smallest modules, which are estimated separately. After this, the whole project is estimated according to the effort required for the smallest parts.

Delphi method

This method is similar to work decomposition with the difference that specialists, responsible for different tasks, estimate required time personally. It is one of the most accurate techniques.

Estimation in relation to the dev process

Estimation is built on the assumption that testing effort is directly proportional to development effort.

During effort estimation, it is important to take into consideration:

Specialists’ qualifications

Quality of test documentation

Used automation testing

Tools and technique applied

In conclusion, nowadays agile methods of software development gain more popularity, and time for planning process usually is decreased. As a result, a test plan and strategy can be not documented at all. But in this case, there is a high risk to omit important issues in the overall testing process.