Tuesday, May 16, 2017

Email: The easy way to remember how to write a test plan

Team,
Something you’ll probably have to do at some point is to write a test plan.  There is an IEEE standard for writing test plans but no one follows it (maybe the military).  Test plans vary wildly from company to company.  Too small and it won’t be enough information, too big and no one will ever read it.

It can be hard to remember what goes in a test plan but it’s a common practice and interview question, so I think of it like this:
  • Who
    • Who are the stakeholders
      • Stakeholders can be loosely defined as “people with an interest in the project” such as project managers, product managers, key customers, your boss, etc.
      • If needed, write a RACI chart
    • Who will be doing the testing
      • Who is on the team, do we have enough people, do we have the right people
  • What
    • What will we test (what is the scope of testing)
      • Include a list of high-level areas we will test.  How specific you get will depend on the project. 
    • What will we NOT test
      • Include a list of what you will NOT test.  Sounds weird but this is very important to include.  This will include things like
      • the customer’s servers
      • security
  • When
    • Do we have a delivery date or a list of milestones (phases)?
    • If we need to deliver by date X, development must deliver to us by date Y
  • Where
    • Environmental factors
      • “we need a server with version 1.2 as well as version 1.4”
  • How
    • A discussion of tools we’ll use, testing types we’ll do (and maybe processes)
      • We’ll use the API
      • We’ll use Selenium
      • We’ll do load testing
      • We’ll test directly in the database
      • We’ll use processes X, Y, Z 
  • Why
    • …doesn’t really work in this who/what/when way of thinking

On top of all of this, a few things to include are

  • Risks
    • the dates are tight here, any shift in development will push us back
    • some environment goes down a lot or is out of our control (maybe it relies on the client or someone 3rd party)
  • Dependencies
    • we need credentials for X to complete testing
    • we need better specifications for Y part of the system
  • Results
    • How will you measure your success
    • How will you deliver that data