Summary:
Where do you find new testers? For the most part, the answer is typically not "from your local university computer science or software engineering department." Testing just isn't taught as a subject in most university curricula. Here, James Whittaker suggests ways to get testing into your university.
IN THIS ISSUE
Picture the faces around the conference table at your last project meeting. How many women were in the room? And how many of them were testers? Alyn Wambeke explores whether the traditionally male-dominated landscape of testing is changing.
Robin Sahner looks at generating test code with Teradyne TestMaster. His group evaluated TestMaster on two projects. It did what they hoped it would, and now they're using TestMaster on all of their projects. They're not employing it to shorten their test development time or use fewer people; instead they plan to use it to get a more complete, more easily maintained set of functional tests using the same resources. Editors Note: Teradyne SST has become a new company called Empirix.
It's wasteful, more often than not, to reinvent the wheel. Christopher Meisenzahl explains how he solved a high-tech automation challenge through the sharing of resources. When faced with similar problems, this sort of collaboration with others may be your most valuable tool—and one that every tester should take advantage of.
Analysis of bug reports from previous projects tells us about our most frequent errors, and can help us improve. But very few companies spend the time to analyze bugs from completed projects. Otto Vinter and Soren Lauesen explore using bug reports to improve the software development process.
Technical Editor Brian Lawrence explains four types of costs of quality: prevention, appraisal, internal failure, and external failure.
Tracking your project goals lets you know how well your improvement program is going, provides visibility early to detect problems, and gives you data to make your future plans more effective. Here's how to measure improvement based on your project's goals and problems.
Every day you are faced with juggling resources and attention between customer escalations, current development projects, and planning for the future. With development cycles measured in weeks, you have at least three releases for each product. Multiply that by the number of projects under your responsibility, and you have a dozen or more releases to manage simultaneously.
A QA manager is often faced with measuring the impossible. Here is a simple, post-ship metric to help judge the test effort's effectiveness. The Quality Barometer method uses the bug counts found during testing, calculates a percentage, and then uses that percentage as the defect target number that can be tolerated after shipment.
Esther Derby's opening comments set up the thrust of her enlightening article: "Have you ever managed a project that went directly, hopelessly, and irretrievably to hell? Would you like to avoid some of the traps so your project doesn’t end up there?"
Unlike traditional scripted testing, exploratory testing is an ad hoc process. Everything we do is optimized to find bugs fast, so we continually adjust our plans to refocus on the most promising risk areas; we follow hunches; we minimize the time spent on documentation. That leaves us with some problems. For one thing, keeping track of each tester’s progress can be like herding snakes into a burlap bag. Every day I need to know what we tested, what we found, and what our priorities are for further testing.
Pat Wegerson recommends software configuration management resources AntiPatterns and Patterns in Software Configuration Management and the online CM Yellow Pages.