EXPERT RESPONSE
Since the term test case means different things to different people, let me clarify my use of the term in this response. A test case would identify a series of steps or actions and the expected system response. Given this description, there may be multiple advantages to document expected and actual results. Here are a few:
In the case of developers performing testing up until user acceptance testing (UAT), it may be unclear what was tested and what results were perceived as acceptable or not. In other words documenting expected and actual results would be one way someone other than the developer who executed the testing could review the testing and understand what results were viewed as acceptable. I could envision an opportunity where a developer thinks the actual results were acceptable but someone else on the team (including customers) might not agree. How would the results be understood if the information wasn't documented or wasn't provided through an extensive debriefing session? The benefit is clarity and documentation. The documentation will provide an opportunity for a test review that might be impossible otherwise.
The fact that there has been low turnover is great but doesn't mean it's been no turnover or that multiple people in the environment couldn't change jobs. The reality is that we have to plan on people not staying at the same job for extended periods, which drives the need for documentation up -- not away. If you consider someone or multiple people on the development team leaving, would you be able to replace that knowledge painlessly? If not, then it might be a good time to begin documenting test actions, expected results and actual results.
An audit isn't the only reason to document information, but an audit is a good reason. The expected benefit is that an auditor will be able to step into the environment and make assessments of the testing that has been executed. If a product must comply with audit regulations, then documented test cases is a requirement. Whether it's a benefit or not is not the relevant point or primary concern. If your test cases are required, then you might as well put solid effort into making the test cases clear and reusable.
|
|
 |
Another reason to document expected and actual results is to help your customers. I've seen end users equipped with full knowledge of a product, but when it comes time to test they freeze. They're not used to testing, they're not sure what to do and in these instances, documented test cases provide guidance. These are the testers that will view a test case and continue to add their own ideas as they test for product acceptance. If your customers who perform UAT could view what's already been tested then they can jump ahead and test other areas. In this case, overall test coverage could be improved by each person knowing what the other person has already accomplished.
|
