Spend your time testing, not documenting

Every time I need to write a test plan or document test cases, I consider the role of documentation in testing. If you are in an industry segment that requires a lot of documentation, things are easy, produce the docs. If you aren't required by law to produce a certain level of documentation, it becomes harder.

The most consistent advice I've found is to document to the extent that you need to so you can give as good an accounting of the testing as you are required to.

When your project leadership asks what the state of the software is, can you give a good answer based on test data?

Do you know if you have addressed the risks in your dev cycle as best you can given your resources?

As I've mentioned previously, I'm building a new team and we are finding our way on processes. Documentation came up very early as something we would need to figure out. I keep spreadsheets and notebooks of my testing. Along with emails, bug reports, and a lean test plan, I feel like my work is adequately documented for our project. However, the other tester on my team wasn't documenting as much. So, when a chunk of functionality he had recently tested came back around after a major refactoring, I asked him to document his test cases in a spreadsheet. Basic, lightweight test documentation I'm sure most testers are familiar with. We are using Microsoft Team Foundation Server, but I'm not yet comfortable with the test documentation features to use it yet. I want some flexibility to enable us to learn more about how we are going to work with our test case assets.

Anyway, a few days passed and I went to check up on the testing progress from my other tester. He hadn't gotten very far.

"How much testing and how much documenting are you doing?"

"About 50/50".

Oh.

That struck me as too much documentation for our team. 80/20 seemed better. Our job is to give timely feedback to the dev team and get as much testing as we can get done. I'd like to think 80% testing and 20% documenting is a good balance. Analyzing the software and coming up with test cases is a separate activity that falls outside of this time recommendation. The 20% spent on documentation is actually writing out the tests, filing bugs, taking notes, etc. as you test.

I don't yet know how this will work out, but for now this is the heuristic I'm going to use.