Choosing the right test strategy is like wondering what kind of brush you’ll paint a wall with. You can’t use the same one to outline the corners, can you? If you wear a very thin one you may spend a lot of time painting it; and if you use a very large one it probably won’t do you good for the small areas.

On the one hand, it would take us time and it wouldn’t be perfect, or it would be fast and it would really look really bad. That’s why there are different brushes for different use cases and the same applies to tests.

A test plan is useful to discipline the testing process. So the best result we can get is when our whole team is aligned from start to finish. Otherwise, without such guidance it would be a disaster when team members draw different conclusions about the scope, risk, and prioritization of product characteristics.

At Trycore we work in an agile environment where we perform short sprints; sometimes each sprint focuses only on some user stories, so it is normal that the documentation is not extensive but of quality. This high-level test plan makes the times a guide for our agile teams.

We want stakeholders to read this document with the most important elements such as scope, what will it try; the customer’s goal; what will not be proven; team roles, how many QA, leaders, automateds, analysts, among others, and what their role will be in the project; what methodology will be used; browsers/OS/devices to test; types of tests, such as security, performance, automation, and more; guidelines for reporting errors; tools to use; risks; launch criteria.