You don't have to be Giorgio Armani to fashion effective use cases. Use case patterns can provide you with a vocabulary to help you describe and judge the quality of your use cases. Find out how you can use these patterns to improve your requirements modelin
Fashioning a new requirements method is an almost impossible task, given budget and time constraints. But that doesn't mean you have to be stuck with an ill-fitting process. Learn about seven alterations that almost any organization can make.
Having a close relationship with the customer is always a good idea. But with that relationship comes risks. Most projects could use a knight in shining armor to protect their product's future. Discover how a product champion can help your organization stay focused on the customer without losing sight of the big picture.
If you buy a hammer, you are not considered a master carpenter automatically. The same holds true for tool knowledge alone solving requirements problems. Kelley Schmidt shares the biggest lesson she learned on a project: commercial process and tools alone cannot lead to project success.
Steve March discusses problems experienced by the Mars Pathfinder. He imparts the following lessons: 1) design defensively in the face of complexity; 2) design defensively for post-shipment problems; and 3) beware of best cases.
While working at a telecommunications company, Linda Hamm had the task of developing and automating tests in a very short time with high-quality expectations. One of the projects was a rule-based expert system for switch maintenance. To help nail down the requirements, the group wrote state diagrams. This article is about what they are and how the group used them.
A use case is a sequence of actions performed by a system, which combined together produce a result of value to a system user. Use cases describe the "process flows" through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Here is an example of how a use case is used to derive and prioritize test cases.
Appreciating differences is critical for productive teams. Different approaches aid in finding solutions, and mutual respect dramatically improves group problem solving. Testers should not be judged according to developer criteria.
Elfriede Dustin has worked on many projects at various companies where automated testing tools were introduced to a test program lifecycle for the first time. In reviewing these projects, she has accumulated a list of "Automated Testing Lessons Learned," taken from actual experiences and test engineer feedback. In this article, she will share examples of this feedback, hoping that this information will help you avoid some typical false starts and roadblocks.