I love day planners, making lists, rearranging things, even packing and unpacking to move, because I love going through things and organizing. So, test plans are totally my jam. They are an excuse/reason to channel all of my annoying organization quirks into something actually useful to more than just myself.

I usually try to have a planning meeting with devs, PM, and QA to talk through where we are, what I think needs to be tested and how. I also utilize everyone in the room, and we’ll collaborate on ways to test things that are more difficult, such as changes that are backend only, or scenarios that require a lot of setup and collaboration, so we can all be on the same page.

A test plan is a document that you create – it’s basically a blueprint for testing, and includes:

• Scope
• Approach to testing – what will be tested and how
• Specific scenarios or functionality to account for
• Any deadlines to be accounted for
• Assignments on who is doing what
• Any blockers
• Any questions/unknowns
• Any environment needs or limitations
• Risk Assessment

There are many different ways to document test plans, and honestly whatever works for you is best. Personally, I use google docs and bullet points. It is very important that your test plan is always up to date, which means it will most likely change frequently before what you’re testing is released to production.