Is it necessary to track changes made to test cases and test documentation?
That is a question that makes me wonder about the underlying question, or maybe the discussion that led to this question. In some shops where I worked, once it was clear that test cases or other documents needed to change, they were changed. Not a big deal.
Depending on the way the shop handles test documentation, which for me includes test cases, there may be a “Reason for Change” field somewhere and a quick note, identifying who made the change, when and why, is often adequate.
Some shops are less formal and may have far less in the way of documentation in general, not just documentation around testing. In those shops, that they were changed is almost never recorded. About the only way to know if there was a change in test cases is to compare the sets of executed test cases from one version, or project, to another.
My current shop uses a tool where the administrator (me) can keep a history of changes made to the test cases. Usually the changes are quite minor -- correcting misspellings or clarifying something nebulous. Sometimes, they are more significant. Our usual practice, when the change is significant, is to note a reason for the change in a “comments” or “description” tab (depending on what type of document is changing.) Most of my team finds this really helpful after the fact -- like the next time they need to refer to the documentation or run the test cases, they can see if anything significant has changed since the last time they were in there.
To me, that is the greatest benefit as a tester. Mind you, when I’m in the middle of a project and realize I need to change the test cases, I’m usually feeling quite pressured to get done as quickly as possible and see this as an inconvenience. However, I usually am glad I did in a few weeks or months when I need to revisit the test suite for another project on the same software product.
Perhaps that is the key. If the test documentation is strictly throw-away and will never be referenced again, then updating it is likely a waste of time and effort. Then again, if it is throw-away, then why create it?
So, is it necessary to track changes? I don’t really think it is, unless there is a specific and valid reason to do so. For me, I like to track the changes for my own understanding and enlightenment, but it is not a requirement for me.
Having said that, there is another possibility I’d like to briefly consider. In one shop I worked, such changes were unofficially tracked. That is, as things changed in other areas of the project, sometimes test documentation would change to reflect those changes, sometimes they did not need to be changed. Certain people retained copies of each version of the documentation for later use. If there were problems with the project later, they would pull out a version supporting their arguments, usually pointing the blame away from them and toward someone else. The upshot was that they would then argue that the problems found or not found in testing were the result of the documents being changed. Such disingenuous behavior points to far greater problems than the abilities of testers or the test team.
Dig Deeper on Software Test Design and Planning
Related Q&A from Peter Walen
Veteran software quality pro Peter Walen explains what software tester skills are really necessary in today's enterprise organizations. Continue Reading
Software testing veteran Peter Walen explains how software testers can write test scripts that others can follow without having to test by rote. Continue Reading
Crowd sourcing can be a key piece of a test strategy for enterprise mobile apps aimed at customers, not employees. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.