Most managers would consider management far too complicated to script. But the five key components of management—planning, staffing, organizing, directing, and controlling—are practiced just as often in testing. So, let's see some of those management scripts.
Recently, I had the privilege of attending the Software Quality Association of Denver (SQuAD) biennial software testing conference. While I’m the program chair of STAR EAST and STAR WEST—big testing conferences that attract delegates from all over the world—I’m also a fan of smaller, regional conferences, such as SQuAD, and think they deserve our support.
For me, the highlight of the conference was Michael Bolton’s keynote presentation, “Testers: Get Out of the Quality Assurance Business,” noting that since we have no control over schedule, budget, staff, product scope, development model, customer relationships, contractual obligations, and other vital items, there’s no way we can assure anything, especially quality.
Michael explained the difference between checking (verifying that which we already believe is true) and testing (exploration, discovery, investigation, and learning to find new information). He suggested we consider giving these responses in the following common situations:
- When your manager demands to see your test cases, demand to see her management cases.
- When your manager demands to see your test scripts, demand to see his management scripts.
- When your manager demands that every test have a single, precise, and expected result, ask her if every management action has a single, precise, and expected result.
The manager would, of course, be incredulous at such requests, responding that “management” can’t possibly be reduced to a set of unvarying sequential steps. Management deals with complex, interlocking, nonlinear, ever-changing interactions among goals, people, resources, and priorities. It’s far too complicated to script.
The manager would carefully explain (perhaps using small words for our benefit) the five key components of management—planning, staffing, organizing, directing, and controlling. Planning consists of establishing goals, objectives, and tasks for our work. Staffing is the process of gaining access to people with the right skills, competencies, time, inclination, and interest to participate in our work. Organizing consists of allocating resources, both human and physical, to accomplish our work within the constraints imposed on us. Directing is the process of coordinating all the ongoing activities to produce the best possible results using our resources. Finally, controlling is the process of measuring and evaluating our work and making necessary adjustments to our goals, objectives, and tasks when required. Does that sound like something that could be pre-scripted by an expert and later executed by someone of lesser skills?
As testers, we are quite familiar with these five components—we practice them in our work every day. Testers establish goals, objectives, and tasks to fulfill their testing mission. And, as tests are performed and software defects emerge, we often revise our objectives and tasks to focus our testing efforts on higher-risk areas. Testers are always seeking the right people to perform testing, whether they are part of the test team or external, such as developers, users, customers, conscripts, or volunteers. Selecting and motivating the right mix of people from such a pool is a highly dynamic activity. Testers organize and balance their work using different types of testing, at different periods of time, and over changing circumstances and priorities. Testers direct their own investigations of software products and coordinate the work of others doing the same. Testers measure their work in terms of coverage achieved, defects found, time spent, defects escaped, and testing and repair costs, and then adjust their processes to become more effective and efficient. When interruptions occur and knowledge is gained, new problems are identified and new opportunities emerge. Does this sound like something that could be pre-scripted by an expert and then later executed by a person of lesser skills?
So, why have testers fallen into the “script trap”? Because, as Bolton
|Ask To See His ...||927.93 KB|