Testing

Better Software Magazine Articles

Use Cases, Ten Years Later

Use cases have experienced a long and sometimes rocky history. Look back on the evolution of use cases to better understand how to use them today.
Alistair Cockburn's picture Alistair Cockburn
July 30, 2002
Gathering Users for Great Requirements

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.
Kelley Schmidt
July 11, 2002
Learning from Pathfinder's Bumpy Start

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.
Steve March
June 26, 2002
An Effective Technique for Verifying Software Design

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.
Linda Hamm
June 26, 2002
Test Design: Developing Test Cases from Use Cases

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.
Ross Collard's picture Ross Collard
June 26, 2002
Testers and Developers Think Differently

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.
Bret Pettichord's picture Bret Pettichord
June 26, 2002
Lessons in Test Automation

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.
Elfriede Dustin's picture Elfriede Dustin
June 26, 2002

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.