Test Plans and it's importance

I think people in software testing has often heard the words test plan, however, not all people know what is a test plan, the importance and parts of it, today I'm going to describe what for me are the main and most important parts of the test plan and what is it.

A test plan is a document that describes what QA will do within the project, if you ask me, you can't assure or guarantee a successful and quality project without a test plan because you won't have enough information about the project, I mean, what to test, how to test it, what types of tests you need to do, etc. You must have a scope and a coverage to test, and depending on the type of project, it can be more complex or not. A test plan must define the following:

• Scope: What you'll test.
• Objective: The main goal of the client for this project.
• Out of scope: What you won't test.
• Roles and responsibilities: How many QAs (QA lead, Automation tester, QA analyst, etc) and what they'll do in the project.
• Methodology: The approach of the project to test, is it BDD?, is it agile? are you doing test cases ?
• Browsers/OS/Devices to test: This should be defined by the client, however as a QA you need to know the most used browsers/OS/devices worldwide and if the client doesn't know you can always propose stuff to test, of course, the last word is the client's word.
• Breakpoints to test (if this is a web responsive design project)
• Types of testing that will be performed (security, performance, automation, accessibility, etc): Not all projects require all testing types, this depends on the project, and sometimes internal testers on the client side do some of this tests, from my perspective, you should always propose to do all testing types if you have the skills to do them.
  
• Guidelines for bug reporting: Each company has their own template, it's good to have it here.
  
• Description of bugs severity: You need to describe what's a blocker, critical, major or minor issue in here so all the team is clear about the bugs the QA team will log.
  
• Tools to use: This is good for all the team to agree on tools to use and not change them in the middle of the project, tools are important here because you may not know all tools requested by the client, of course this may change, but still you should add them.
  
• Risks: You need to highlight the risks of the project, for instance: deadline too close, training needed for some tool, team is not big enough, etc
• Environments: This may not be known in this phase of the project, but if you do, don't forget to add which environments will be use,

You may have a lot more items besides the ones I mentioned above, like exit or success criteria, deliverables, oversight of features to test, and more, however, this also depends on the company's internal templates and your approach too, but with the items above you have got yourself a great test plan.

 

It's really important that the test plan is shared not only with the client, but also with the team members because all developers, product owner, project manager and design team must be informed about the scope, this helps a lot to establish expectations and changes on the plan if there are some, of course any change must be an agreement between the whole team. The agreement and approval of this document is important because it guarantees a valid scope and a valid approach of what you as a QA will do.

In a lot of interviews I have had with different candidates, when they are asked about the parts of a test plan, some of them always mention test cases, in my experience and from my perspective, test cases are noted and described later in the project, since you still can't do or know the whole functionality of the project until a further phase, don't forget the test plan is the first or one of the first deliverables of the project done by QA.

As you can see the test plan defines and limits your testing and it's really important to have a test plan on all projects you have to work on, no matter how small or simple they may be, it's the first guide or baseline of what you'll do during the project's execution.

Once gain, I hope you like this post, next Tuesday I'll be talking about Test cases Vs Feature files.

Leave your comments

@LuchoAgileQA