- Documentation as Discipline
- Documentation Gone Wrong
- A Clear Departure from the Past
- Finding the Right Balance
- Staying Focused on Discipline
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Staying Focused on Discipline
Let's revisit that idea of using documentation to exercise discipline when approaching a problem. On this project, we focused some time on documentation for auditing purposes, but I handled most of that documentation in my role as the test manager. The team focused on documentation to help solve problems or to help communicate their findings more clearly.
We followed a few principles that I believe are worth sharing:
- Make sure that you focus on the end goal. What are you trying to accomplish? If you're focused on communicating something complex to other people, the documentation is likely to consist of more pictures than words. If you're focused on making sure that nothing is missed while testing, lists of ideas are better than detailed test cases.
- For historical information to be useful, it needs some sort of consistent structure and/or location. If your historical information goes into a tool (such as JIRA, VersionOne, or RequisitePro), make sure that all information goes into that tool. Don't put some of it into the tool and some into Word documents. Get it all in one place. In addition, make sure that everyone knows what the information should look like, what's required, and what's optional. That doesn't necessarily mean templates, but it does mean that the documentation should be audited for the same look and feel on a regular basis. Formatting is less important than content, but formatting is helpful if the information truly needs to be used again in the future.
- The way you manage your documentation should support the way you manage your ideas. For software testers, overproduction, abandonment, and recovery are tactics for how to manage your ideas, as shown in the following table.
Tactic
Description
Documentation
Overproduce ideas for better selection
Produce many different speculative ideas and make speculative experiments—more than you can elaborate upon in the time you have. Examples: Brainstorming, trial-and-error, genetic algorithms, free market dynamics, etc.
Lists, spreadsheets, notecards, software that generates test data automatically. Anything that doesn't take much time to generate, but allows you to compare and contrast ideas.
Abandon ideas for faster progress
Let go of some ideas in order to focus on and make progress with others.
Document management systems that let you archive, or spaces where you can move documents once you think you're "done" with them. You need to be willing to dump documents that are incomplete.
Recover or reuse ideas
Revisit your old ideas, models, questions or conjectures. Discover ideas by someone else.
Wikis or document management systems that index content in documents stored there.
- Our team talked about all these tactics, but we tried to overproduce test charters, and we abandoned lower-priority charters in favor of higher-priority charters. We kept the charters indexed in one spreadsheet with a consistent naming convention on the wiki so that we could recover them months later, if necessary. It was easy to find (and forget about) our test charters. That made them easy to manage.
- Make sure that documentation that's being written is also being reviewed. If it's not worth getting a peer review, it probably isn't worth writing. If no one's reading the documentation or it doesn't need to be accurate, then why write it? When we wrote test charters in a sprint, the developers reviewed the detailed charter for the features they were coding, so they knew what the tester was expecting. The test team reviewed the high-level charters listing as a team, to ensure that no key aspect of testing was overlooked. As the test manager, I reviewed the execution notes to ensure that I understood the testing that was actually taking place.
Take 10 minutes to think about all the documentation you do today. Who looks at it? Are you getting value out of it? Think about how long it takes you to write that documentation. Could the process be faster? When you've done your thinking, talk with your team to see whether there might be better ways of fulfilling the goals of your current documentation. Make sure that you're focusing on the most valuable (and most fun) aspects of your job.