|
Document Why as Well as What: Finding the Purpose of Your Software Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
|
|
|
Slim Down Your Test Plan Documentation Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.
|
|
|
The Unspoken Requirement: Testing for Consistency It's easy to see that style consistency is important when discussing the user interface. But there are other areas where being consistent is just as important, even though they are not as visible. Consistency is one of the quality attributes of a product—any product—even if it is not stated clearly in the requirements documents, and testers have a responsibility to check for it.
|
|
|
Just Enough Test Documentation Many options are available for test teams to help them document how a system should work. A test strategy, test plan, test charter, test cases, test scenarios, and automation scripts are examples. This article has a matrix comparing the types of test documents you might choose and can help you pick which is right for you based on project characteristics.
|
|
|
I Go Back: Valuable Lessons in Quality Engineering Terry Wiegmann noticed that in certain conversations with clients and team members, a single phrase can take her back to some “aha” moments when she grasped fundamental quality concepts. She shares some of these major learning moments throughout her career and how they can apply to quality engineering.
|
|
|
Comprehensive Documentation Has Its Place Kent McDonald shares some tips on documentation approaches that he and his team used on a recent project. The key is to find the bare minimum of documentation that you need from both a project documentation and system documentation perspective and only add additional documentation when it hurts not to add it.
|
|
|
Lean Test Documentation Forcing testers to slog with document creation is a foolish thing to do for any organization, especially those that believe that keeping customers happy is their foremost goal. In this article, Parimala Hariprasad writes that adopting lean test documentation saves lot of time and energy for the tester.
|
|
|
Specification by Example: Collaborating on a Scope without High-Level Control Understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter. In this excerpt from Gojko Adzic's book Specification by Example, the author offers some tips for effectively collaborating on the project scope when you don’t have high-level control of the project.
|
|
|
Inspecting Requirements Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how.
|
|