“How do other teams handle/manage these more detailed testing documents?”
Often, we spend a lot of time thinking about testing and testing documentation when we would be better served thinking about QUALITY.
Quality is not something that can be easily added at the end of a development cycle. It is better added as part of the development cycle itself.
Most projects’ testing hiearchy looks like this, with mostly manual testing with some integration testing.
You can remove a lot of the overhead associated with needing to create detailed test plan documentation by engaging in aggressive Test Driven Development/Unit Tests and Automated Acceptance Test Driven Development.
1. It tends to make developers have the mindset that they are not responsible for testing.
2. It defers the quality risk to the end of the development cycle, where it costs the most to fix.
Test Driven Development/Unit Testing forces your developers to think about testibility up front, in terms of code as well as design, and makes them responsible for ensuring that the individual units/functions/methods are verified working as part of the build.
Acceptance Test Driven Development, with a tool such as cucumber, is a wonderful way to test the software in aggregate, automatically. Automated ATDD tests can be written by ANYBODY (PO, QA, Devs, SM, Stakeholders, etc) and the automation of the acceptance test criteria can be decoupled from the code, meaning they can be written in parallel.
As a result, an Agile testing hierarchy looks more like this:
With unit tests as a foundation and manual testing at the very top.
If you go down the road of automating unit tests and automating acceptance tests in parallel with the code being developed, you will gain a few things:
- Quality as part of the process, as part of the design, as a shared responsibility
- Quality not saved as a step near the end of the development cycle
- Less of a need for rote test plans, as most of the rote stuff will be automated, meaning that your human testers can do the kind of testing humans are good at, exploratory testing.
- Less of a need for a large manual regression cycle, since every build and every change can be automatically regressed at both the unit level and the acceptance level multiple times a day.
If you move toward unit test->acceptance test automation then the documentation becomes a lot more lightweight and less of a chore to “manage”.