A test case is a kind of container. You already know that counting the containers in a supermarket would tell you little about the value of the food they contain. So, why do we count test cases executed as a measure of testing's value? The impact and value a test case actually has varies greatly from one to the next. In many cases, the percentage of test cases passing or failing reveals nothing about the reliability or quality of the software under test. Managers and other non-testers love test cases because they provide the illusion of both control and value for money spent. However, that doesn't mean testers have to go along with the deceit. James Bach stopped managing testing using test cases long ago and switched to test activities, test sessions, risk areas, and coverage areas to measure the value of his testing. Join James as he explains how you can make the switch-and why you should.

Test coverage of application functionality is often poorly understood and always hard to measure. If they do it at all, many testers express coverage in terms of numbers, as a percentage or proportion-but a percentage of what? When we test, we develop two parallel stories. The "product story" is what we know and can infer about the software product-important information about how it works and how it might fail. The "testing story" is how we modeled the testing space, the oracles that we used, and the extent to which we configured, operated, observed, and evaluated the product. To understand test coverage, we must know what we did not test and that what we did test was good enough.

Does your test process need to pass regulatory audits (FDA, SOX, ISO, etc.)? Do you find that an endless queue of documentation and maintenance is choking your ability to do actual testing? Is your team losing good testers due to boredom? With the right methods and attitude, you can do interesting and valuable testing while passing a process audit with flying colors. It may be easier than you think to incorporate exploratory techniques, test automation, test management tools, and iterative test design into your regulated process. You'll be able to find better bugs more quickly and keep those pesky auditors happy at the same time. John McConda shares how he uses exploratory testing with screen recording tools to produce the objective evidence auditors crave. He explains how to optimize your test management tools to preserve and confidently present accountability and traceability data.

When a tester uncovers a defect, it usually gets fixed. The tester validates the fix and may add the test to a regression test suite. Often, both the test and defect are then forgotten. Not so fast-defects hold clues about where other defects may be hiding and often can help the team learn to not make the same mistake again. Dawn Haynes explores methods you can use to generate new test ideas and improve software reliability at the same time. Learn to use powerful analysis tools, including FMEA-failure modes and effects analysis-and cause/effect graphing. Go further with these techniques by employing fault injections and forensically analyzing bugs that customers find. Discover ways to correct the cause of a problem rather than submitting a "single instance defect" that will result in a "single instance patch" that fixes one problem and does nothing to prevent new ones.