Finally, your designer and a team of developers have finished making fantastically beautiful and multifunctional website, the future clients are completely satisfied and are ready to pay your organization and everything you need to do is to finally test the product.

Right here lies most beautiful and so cute thing that may happen in the everyday life of a tester: you think that the new version of a browser is released, a new extension appeared in the sphere of mobile devices and actually, a beautiful design and funny animations can hide serious bugs which will make YOU embarrassed. To somehow calm down and stop panicking, you open a folder with documents on website testing plan on your computer…

But don’t forget about a strategy of independent software testing services. Let’s talk about it.

The Reasons for Using a Testing Strategy

A testing strategy is a short document which, in its logic of use, precedes a typical test plan while working with developed web product. Before writing a detailed plan for testing the operability of a software product, you should absolutely efficiently formalize some fundamental approaches to testing and see for yourself that all members of your team equally understand what will be tested and how.

What Must Be Described in Such Strategy

• What types of testing must be used?
• Will UI testing, testing of the performance of system components, the work of configuration, etc be performed;
• Will the team of QA perform static types of tests, for example, reviewing the requirements defined;
• Will you perform exploratory testing and in what proportion.

It’s very useful to describe all test activities that will somehow be done in your plan.

For example, test design, preparing necessary test environment, etc.

You may ask: why to do so? – to remember everything while working on the test plan.

What will be the basis for the future tests? Where will you take the values for checking the tests defined?

For example, it can be special requirements, test scripts, typical classifications and standards.

Working on the strategy, we’d like to mention a list of important criteria which are responsible for the severity and priority of the bugs found or system errors.

Usually, the evaluation of bugs is always controversial, in case it contains criteria by which they can be evaluated. The most suitable variant is to formalize the importance of bugs and the strategy of its fixing right in the test strategy.

Logically-considered and developed test strategy is quite a qualitative basis for future development of other technical project documents (in our case, test plan), which helps to completely avoid misunderstanding in future.

The Concept of Test Plan

A test plan is a special technical document which describes all future scope of work for testing a developed product, from documenting the object itself, used at the beginning of development strategy, criteria of finding the bugs and also a logic of finishing the work with obligatory evaluation of risks and also variants of their solving.

Recommendations for Designing Test Plans

Every existing methodology used for testing web products has an original template for designing test plans. We suggest that the following discussion of issues on writing the plans must be reviewed on the basis of international standard IEEE:

• TestPlanTemplate RUP;
• TestPlanTemplate IEEE 829.

Thoroughly reviewing these documents, it becomes clear that they describe the same details but in different forms.

In case you don’t want to use a classical template and decide to develop and implement your own in the form, most suitable for your project, you should create a document which will at least answer the following questions:

• What exactly must be tested (test object, used web environment, additional applications, what equipment is used to perform this;
• What will be tested (complete list of system functions which must be tested to check its maximum functionality);
• How exactly you will test (so-called test strategy – types of testing and also how they are applied to the test object);
• When exactly you will test (logically described structure of testing: preparatory works, the process of testing, analysis of information obtained with planned stages of project web development.)

If you can clearly answer all above-mentioned questions while designing a test plan, you can be absolutely sure that you have well-designed and, the main thing, correctly designed test plan of the projects.

Then, to make the document finished, you must add the following points to it:

• Actual environment of the system checked;
• Equipment and virtual systems used for testing;
• Possible risks and the ways to solve them.

Types of Test Plans

Usually, you can meet the following types:

• Master Test plan;
• Test plan (detailed test plan).

After analyzing these both documents, you may come to a conclusion that the main difference between them is that master plan is regarded to be more static, as it contains in its structure so-called “high level” of data which are not always used in the process of testing the developed environment.

As for a detailed test plan, it may contain more detailed information on the strategy of good testing, a complete description of the work done. It means that such type of plan can be regarded as more “live” source of test manipulations, which can be always edited and you may find a real state of affairs while testing of the product developed.

Reviewing and Approving the Plan

When documents on test plan are written by only 1 person, they become quite one-sided and so it’s highly recommended to periodically review it with the help of other QAs and also plan the procedure of approving the document inside project team.

For example, such a project team may include:

• The main employee of QA department;
• Test manager (the main QA manager);
• Head of development;
• Project manager.

Every mentioned member of the process of developing a software or other web product, must before approval review and add his or her suggestions and comments about the project to make the product, which will be released, completely qualitative.

Test Plan in 1 Page – 100 % Success!

Just show your project manager multi-page material on planned strategy and test plan of developed product, the reading of which takes at least an hour – which he or she does not have and won’t have. Or show him a short one-page document which shows how you are going to test.

I think he or she will like the second variant more!

Speaking about time, the main peculiarity of one-page test plan will be that it will take much less time than working on a long document. And this will allow to re-distribute time of a tester on working on other projects and subtasks.

Short size means that the most important and actual information must be in it. It’s the most important for the people who will use this document for testing the software functionality.

You should not include minor details, which won’t be interesting for others.

If you, as a tester, write long test plans and want to decrease them to 1 page, speak with those people who will read them: what exactly they would like to read. As a variant, use different forms of its designing (what we mentioned above) and try to include all actual information.

It’s very important to understand that some projects can’t do without a multi-page template.

If you must add something to a plan, according to business thoughts – do this!

If your future plan must contain only all sets of tests, just leave some space on a page and link files or utilities to operate designed test cases between each other. The final target of the one-page test plan is a short overview of all planned testing strategies.

If any member of the project would like to get additional information, the links written in the test plan will help him or her to do this, not taking much space in the document structure.

For example, relinking can be done for the next objects and components:

• Tools used for testing;
• Special test charters;
• A list of possible risks;
• Links for the prototypes used and tests performed;
• Documents on web structure;
• Design document on the whole project.

Even if you understand that it will take more than one page, this still will help you to look at your test plan from another perspective, will help to realize that it can be done in another way so that testing document will be completely valuable and efficient.

Some Ideas for Original Presentation of Your Test Plan

If you don’t have much space, then be creative!

You can easily find on the Internet a suitable variant of a useful template, just be sure that all available sections can be used for your project.

Don’t waste time on writing something that can’t be described in another way or what obligatory must use a template.

Take a look at such variants:

• Dashboard type. Such a structure type allows a reader of a plan to understand what exactly you are going to test. Try to use different types and styles to completely attract the user’s attention to different text fields;
  

  Dashboard Type of Test Plan

• Excel or another table. You can easily show in a table any lists of tests or test scripts which you will use for this project.
• Trello board. Good web tool which allows co-operating with a virtual board where you can write all tasks needed and also follow its status of implementation. Such style of work with test plans to some extent reminds the cooperation with agile-projects.

To conclude, it must be said that we are always spending much precious time on creating a good test documentation for a particular project beccause we offer only qualitative QA services. But it’s time to leave such practice!

Create the templates, try new approaches, combine available practices and possibilities and then writing the technical documentation and the process of its studying will become for you a little bit more pleasant and interesting.