|
|
The Awful Truth About Logic-Testing This presentation covers conditions and expressions; truth tables; normal form patterns; modified condition/decision coverage; constructing an MC/DC test set; tools for checking MC/DC coverage; unique cause coverage; basic unique cause design; and logic coverage references.
|
Dave Gelperin, Software Quality Engineering
|
|
|
Manage Testing by the Numbers Telcordia's Software Quality Assurance Testing Organization Business Model was developed to assist its SQA Testing Management Team in becoming more effective and productive in managing SQA testing. Learn how the implementation of this model can help raise the overall technical expertise of your test management team.
|
Sharon Burrell, Telcordia Technologies
|
|
|
Software Test Automation Spring 2002: Test Automation on a Shoestring: Doing More with Less Want to automate your tests but don't have the budget for big-league tools? Elisabeth Hendrickson offers case studies where test automation was accomplished with simple tools for small budgets. She delivers practical advice for creating the automation you need from the tools you already have or can easily get your hands on. Fact is, everything you need to get started is probably right in your "kitchen drawer."
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
|
Lessons Learned in Test Automation Can test automation really advance your testing mission? The answer to that question is a resounding "That depends!" But to make it happen you have to provide value to development and find new ways of testing. Bret Pettichord offers lessons from the the trenches in building powerful test suites. He shares his experiences as well as those of other test automators to help you avoid the pitfalls others have already stumbled onto.
|
Bret Pettichord, Pettichord Consulting
|
|
|
Thinking About People, Process, and Product: A Principle that Works at Work All projects involve the three P's: people, process, and product. People includes everyone who influences the project. Process is the steps taken to produce and maintain software. Product is the final outcome of the project. To keep these three in harmony, you must observe who is trying to do what to deliver what. Usually, two of the three P's are mandated, and the third one is chosen appropriately. Although this is common sense, it is not common practice. Dwayne Phillips discusses the issues and challenges that affect us all on every project. Learn about the ideas and questions to consider to help you work through these issues.
|
Dwayne Phillips, U.S. Department of Defense
|
