Day 26 task: What does your Test Plan look like, what format do you use?
The looks and strictness of a test plan depends heavily on the context and collaboration with the product owner/project sponsor. Some application contracts define specific content of the test plan, while in other contexts the test plan is just a tab of test cases in a tool.
My best test plans are one pr. release looking at:
- delivery scope (requirements, changes)
- test cases / test scope
- people involved, if it changes.
This obliviously can be semi automated in modern test management tools for frequent deliveries. Everything else on how we work (boards, gates), environments, tools etc can be captured in a test strategy. Especially if it’s repeated more than once.
The traditional notion of the testers needing to be independent of the developers does not fit well in agile… or any modern software delivery activity where team collaboration is key. (as it should be).