Lessons Learned in Software Testing: A Context-Driven Approach

By Cem Kaner, James Bach and Bret Pettichord

Decades of software testing experience condensed into the most important lessons learned.

The world's leading software testing experts lend you their wisdom and years of experience to help you avoid the most common mistakes in testing software. Each lesson is an assertion related to software testing, followed by an explanation or example that shows you the how, when, and why of the testing lesson. More than just tips, tricks, and pitfalls to avoid, Lessons Learned in Software Testing speeds you through the critical testing phase of the software development project without the extensive trial and error it normally takes to do so. The ultimate resource for software testers and developers at every level of expertise, this guidebook features:
* Over 200 lessons gleaned from over 30 years of combined testing experience
* Tips, tricks, and common pitfalls to avoid by simply reading the book rather than finding out the hard way
* Lessons for all key topic areas, including test design, test management, testing strategies, and bug reporting
* Explanations and examples of each testing trouble spot help illustrate each lesson's assertion

• Language: English
• Publisher: Wiley
• Release date: Aug 2, 2011
• ISBN: 9781118080559

Book preview

CHAPTER 1

The Role of the Tester

c01f001

What are testers supposed to do for a project? That’s the question we address in this chapter. Like many things about testing, the answer may seem obvious or trivial at first glance, but it’s not.

A role is a relationship. That means you don’t control your role, but you can negotiate it. People expect things from you that might not be reasonable. When you find yourself blamed for a low-quality product (and that will happen), whoever is blaming you probably suffers from role confusion. Maybe they think your job is to beat the product with the Magic Mallet of Quality before it ships, and they think you didn’t hit it hard enough.

When you’re clear about your role—when you have negotiated it—you have a foundation for setting expectations in any situation that may arise. However, even a clear and appropriate testing role is a demanding one.

lesson1 You are the headlights of the project.

A project is like a road trip. Some projects are simple and routine, like driving to the store in broad daylight. But most projects worth doing are more like driving a truck off-road, in the mountains, at night. Those projects need headlights. As the tester, you light the way. You illuminate the road ahead so the programmers and managers, however they bicker over the map, can at least see where they are, what they’re about to run over, and how close they are to the cliff. The detailed mission of the testing group varies from company to company. Behind those details, though, is a common factor.

Testing is done to find information. Critical decisions about the project or the product are made on the basis of that information.

lesson2 Your mission drives everything you do.

Your mission might depend on your industry, company project, or the personalities on the team. Test projects vary greatly from place to place. A challenge for the evolution of testing as a craft has been the difficulty of creating a conversation about test practices that will span the cultural and technical differences among us. Many of these differences amount to different missions for the test team. For instance, in some testing organizations, a test plan is just a tool to help the testers. It could be written on a napkin and still be effective. Other organizations create test plans as products that must be delivered along with the software. Their test plans may have to follow strict format and content guidelines.

Any of the following requirements might define your mission. Which ones are expected of you?

Find important bugs fast.

Provide a general assessment of the quality of the product.

Certify that the product meets a particular standard.

Help your clients improve product quality and testability.

Assure that the test process meets accountability standards.

Educate your clients about testing and how to work with testers.

Follow a particular set of methods or rules.

Help predict and control the costs of support.

Help your clients improve their processes.

Perform your work in a manner that minimizes cost, time, or undesirable side effects.

Do whatever is necessary to satisfy particular clients.

If you spend time and effort on requirements that your clients don’t care about, you risk being treated as irrelevant or counterproductive. Negotiate your mission with your manager. Clarify it. If you can’t come to agreement on the mission, you won’t have a good foundation for anything you do.

What should you do when you don’t know what to do? One answer is review your mission. It identifies the core problems that you own. When you’re clear on your testing mission, you can defend your work and determine specifically what to do next. You can also explain your role to other people, in simple terms. If you can’t work toward your mission for some reason, take the matter to management right away.

What should you do when you know exactly what to do? Once in a while, revisit your mission to make sure that your clear plan hasn’t focused you so much on one part of the testing problem that you’ve forgotten about the rest.

lesson3 You serve many clients.

Testing is a service role. Feel good about that. The service you provide is vital. Service implies clients—the people you serve. Your success is measured primarily by how well you serve your clients’ desires and best interests. That might not be so hard, except that testing has many clients. They all have their own needs, and their collective needs don’t necessarily align:

The project manager. Project managers are entitled to know your process and influence it. You serve the project manager by reporting your status on demand, reporting important problems fast, and not being a bottleneck to the project. It’s the project manager’s prerogative to direct the project. It’s your job to tell him what you are able to do, what you can’t do, and what the impact on testing will be of any given decision or condition on the project.

The programmer. You make the programmer’s job easier by providing good bug reports, as soon as possible. Strive to know your craft and know the product so you don’t waste the programmer’s time with mistaken or frivolous reports. If you can do that, you’ll have a lot more credibility, and that will translate into support and influence.

The technical writer. Like you, the people who write the manuals and the online help get incomplete information about the product. You can help them understand how the product really works, and you can alert them to errors in the documentation. Writers can help you, too. As they do their research on the product and how the people who have to read the documentation will use the product, they will learn things that you don’t know. If you have a good relationship with the writers, they’ll alert you to new features, new uses, holes in your test plan, and to the bugs they find. Some of those bugs would never be reported unless a particular writer knows that a particular tester cares.

Technical support. Whatever problems are left in the product become a burden for the people who provide technical support. You serve the support group by alerting them to aspects of the product that may trouble the user. If you work with them during development, sometimes the support staff will help you make the case that a bug should be fixed. You should also offer to help investigate difficult problems found in the field. Doing so will bring you into closer contact with support people and, therefore, with the customer.

Marketing. Marketing needs to know whether anything in the product is inconsistent with the key benefits the product is supposed to provide to customers. A bug that seems minor to programmers might be critical to marketers. They might recognize that the bug makes it harder for the customer to do an important task. Also, by reviewing planned marketing documents or statements, you can help marketing promote an accurate account of the product’s capabilities.

Top management and stockholders. You serve the business. That’s why you must be careful not to sound or act like a quality fanatic instead of a reasonable person. Especially near the end of the project, perform your work in a way that takes into account the short-term and long-term interests of the company. Express test status reports in crisp, operational terms, so that executives feel they have a basis on which to make decisions.

The user. In your heart, you serve the people who will make use of the product. Their satisfaction is in the best interests of your project, of course. But there is also a special satisfaction that goes with being the primary user advocate on the project team.

This list is in no particular order, but your project may have a pecking order, so look into it. Find out who matters on your project. Discover whom you serve. This is the first step to great testing.

lesson4 You discover things that will bug someone whose opinion matters.

Your group’s mission includes (or should include) informing clients about anything that threatens the value of the product, according to your clients’ definition(s) of value. If you can show that the product will not be valued even if it works as intended, it’s your duty to report your concerns. If your clients choose to dismiss the report, that’s their prerogative.

lesson5 Find important bugs fast.

Most likely, your mission includes finding bugs that are important (as opposed to insignificant) and finding them quickly. If so, what does this mean in terms of the tests you run?

Test things that are changed before things that are the same. Fixes and updates mean fresh risk.

Test core functions before contributing functions. Test the critical and the popular things that the product does. Test the functions that make the product what it is.

Test capability before reliability. Test whether each function can work at all before going deep into the examination of how any one function performs under many different conditions.

Test common situations before esoteric situations. Use popular data and scenarios of use.

Test common threats before exotic threats. Test with the most likely stress and error situations.

Test for high-impact problems before low-impact problems. Test the parts of the product that would do a lot of damage in case of failure.

Test the most wanted areas before areas not requested. Test any areas and for any problems that are of special interest to someone else on the team.

You will also find important problems sooner if you know more about the product, the software and hardware it must interact with, and the people who will use it. Study these well.

lesson6 Run with the programmers.

Supporting the programmers is probably a key part of your mission. When you test the things that the programmers are building right now, or have most recently built, your feedback will help them work more efficiently. When they deliver it, you test it. When they make a change, you test the change. Aim for the shortest, quickest feedback loop you can. While the programmers are chewing on the bugs you’ve just found, you are off finding more bugs. The ideal situation (for testers) is one in which they’re so busy fixing the problems you’ve found that they, not you, are the bottleneck of the project.

lesson7 Question everything, but not necessarily out loud.

It’s possible to test without questioning, but it’s not possible to test well. Questions are fundamental to your role on the project. If you do not question, your testing will be aimless and mechanical. However, explicit questions can be provocative. They often put people on the defensive.

Questions can be like strong medicine—best asked in low doses or taken with a meal (i.e., other kinds of communication). Fortunately, the value of questions is not limited to those that are asked out loud. Any question that occurs to you may help provoke your own thoughts in directions that lead to vital insights.

If you ever find yourself testing and realize that you have no questions about the product, take a break.

lesson8 You focus on failure, so your clients can focus on success.

Testing is the only role on the project that does not directly focus on success. Everyone else creates something or creatively guides its creation. But testers are negative. This can be a depressing job, almost like a parody of a Greek myth: On the island of the testers, they were doomed forever to search for what could not and should not exist, knowing that to succeed would bring misery to the Gods.

It would be a mistake to redefine your mission more positively, as someone who verifies that the program works. Even if verify that the program works is handed to you as your mission, advise your client that such verification is impossible. It’s hideously expensive. Unless you run every possible test, you can’t prove the product works. The best you could say is For the tests I performed, I didn’t notice that the product didn’t work. The opposite, however, is marvelously economical: With as little as one test, you can show that the product doesn’t work.

Testers focus on failure because it improves their chances of finding it. Look for key problems in the product with all your creativity and skill. If you don’t find them, they can’t be fixed, and then the users may find them for you. By finding what’s there to find in the product, you help the project team learn more about their own skills and the product’s risks, and you help them make the product better, more supportable, and probably more successful in the marketplace.

lesson9 You will not find all the bugs.

It’s your job to find and report significant bugs. But you won’t find all of them. To find all of them, you’d have to look everywhere there could be a bug, you’d have to look there under every different situation that could arise, and you’d need a foolproof way of recognizing every different kind of bug when it occurred. If you think you can do that, you have either a very simple product or a very limited imagination.

You have to make choices about how to spend your time, knowing and accepting that you can’t do everything.

lesson10 Beware of testing completely.

Some testers who agree they can’t know they’ve found all the bugs in a product still talk loosely about what it means to be finished testing. Saying it will take me five days to test that can be interpreted to mean that you think you will have completely tested that part of the product in five calendar days. And that might be taken to mean you will find every bug in five days. Completeness is more often implied than stated. Either way, it’s a concept you must treat with great care. Think about what complete testing might mean:

Completed the discovery of every bug in the product.

Completely examined every aspect of the product.

Completed the testing that you believe is useful and cost-effective to perform at this time.

Completely fulfilled the stated objectives of the project to the best of your