Nobody ever wants to work with long and monotonous test plans. More and more QA engineers come to the so-called test planning methods which contain all the thoughts and ideas that the project team can and will certainly have while developing and testing software.

[highlight dark=”no”]Effective thoughts about various testing factors should be recorded in a very simple and understandable way[/highlight] since such documentation will always be in the foreground until the final release of the entire product.

When drawing up a test plan, it is worth taking into account 5 basic criteria:

1. What exactly will be tested? – The scope of testing.
2. How will the software be tested?
3. Who will test it?
4. Why is it necessary to test it?
5. When will the testing process begin and finish?

You have to understand that creating a plan of 50-100 pages long is a waste of valuable time since no one will bother with such documentation. Modern methods and tendencies in the field of QA services require minimal but effective documentation.

The following offers three options for creating such a test plan. Let’s analyze them in more detail.

Test Planning As a Mindmap of the Entire Project

Mindmaps are an invaluable time saver. They may contain a lot of useful things.

The structure of such a mindmap should include the following aspects:

• Creating a central node, the nature of which is in the question, what QA should receive after test completion, and what shouldn’t be tested.
• Creating branches: testing scope, timescale, testing recourses involved, testing approaches, potential risks, and possible assumptions.

Here are some examples of creating a mindmap:
Using Mind Maps for Test Planning
Mind Maps in Software Testing

The One Page Test Plan

This is quite a complex approach to implement – creating a test plan in the form of a single page document. Regarding its content, this document covers all the important testing criteria as the mindmap.

Nevertheless, some clients don’t really like to analyze mindmaps, finding them quite difficult and confusing. In this situation, single page documents might be helpful: they will capture the whole essence, and at the same time will be short and easy to understand.

The scope of such a document and sequence of test steps of implementation is identical to the mindmap.

Of course, all the points of the test plan may not fit onto 1 page. But it shouldn’t be a problem. If you’re intended to minimize the amount of information, it’ll be ok! Just make sure that provided information is relevant both for the QA department and a client.

Test Matrix

This strategy is especially popular with Agile and Lean approaches. Conventionally, if you have several mindmaps at once, you can easily arrange them in a set of sections of the general test plan.

Here is a simple and illustrative example – https://www.slideshare.net/lonsdalesystems/software-testing-canvas

The basic benefit of this approach is the development of a good mechanism for collaborative test planning (for example, interaction between the testing and the support departments).

Conclusion

In general, the test plan itself does not contain anything useful. It is extremely important what thoughts and ideas are laid in its structure. The test plan is just an “intermediary thing” with the QA team’s intentions for a certain period. It will constantly change during the progress of the entire project and will be supplemented by more and more new data.

Instead of writing a huge document that will definitely become out of date as the requirements are finalized, focus on the implementation of small and flexible documents that are easy to update and edit!