Journals by RSS
Journals by EmailIn the project portfolio where I work, we have several applications in maintenance mode. A number of developers and testers, some previously assigned to dev projects and others relatively new, may work on bugs from any application at any time, and most aren’t familiar with the applications yet.
My cubicle is next to that of Matt, one of the testers. One day he was trying to follow instructions in some test cases and hit a wall because of lack of detail. He called over Nathan, another tester in a neighboring cube. They launched into a discussion of how much detail should be included in test cases.
Matt’s problem was steps that assumed prior knowledge. It would be a general step like “Create a payment to a landlord.” Well, how do I do that? he wondered. A number of steps are involved in creating a payment, and he didn’t know what they were. The test case was obviously written for someone with a certain level of knowledge about the application. Matt needed more detailed steps.
On the other hand, if the testers were to include granular steps for every test case, they’d have to spend more time writing each test case, and it may be hard to know what level of detail is too much.
As you may have guessed, I started listening in on their conversation. What I was hearing in snatches sounded like discussions that go on between technical writers, so I paid more attention.
We ask questions like “How much prior knowledge does my audience have? How detailed do my steps need to be?” Matt was asking similar questions.
Nathan’s answer was a good one: include fairly specific steps, but if you have to complete a subtask as part of the larger test case, add them as substeps. That way, someone who knows how to complete the subtask can read the first line and then just do it, skipping over the substeps. Someone who needs instructions for the subtask has them available.
This approach is a good one for technical, end user instructions too. It helps procedures look shorter and therefore the task easier.
I’ve usually thought that the aims of quality assurance engineers can be different than those of tech writers; we care about how the users will complete tasks, while testers care more about making sure the product meets functional requirements. These may not be quite the same goals. However, in this case, I found that testers have some of the same concerns as the writers, even when as in this case the audience is different.
I mentioned these testers’ discussion on Twitter, and Julio Vazquez pointed out this is why tech writers could write test cases. We would make sure that tasks users want to complete can be done with the product. Where I work, where we have few tech writers to many testers, we could spend all our time writing and updating test cases. But I see Julio’s point, especially in an Agile team: the user stories are supposed to be written around the user’s ability to complete some task. The tricky part in our portfolio is the practice of creating development tasks underneath user stories. Each task is supposed to be a testable piece of code. Perhaps one route to take in this situation is to have the tech writer create a test case that must pass in order for the overall story to be considered complete.
Related posts (auto-generated):
Ben Reply:
September 18th, 2010 at 6:26 pm
The carpenter and nail analogy is an interesting one. If you know your audience well, then you do know what level of detail is too much. Now, if you’ve never done any carpentry, do you know how to properly hammer a nail? Maybe, maybe not.
This reminds me of an example I saw where the first person had a second person tell him how to make a peanut butter sandwich. The first person followed the verbal instructions literally and ended up making a mess. It was interesting how much the second person took for granted, which was the point of the demonstration.