Lessons Learned in Software Testing
A Context-Driven Approach
Cem Kaner, James Bach, Bret Pettichord
- English
- ePUB (mobile friendly)
- Available on iOS & Android
Lessons Learned in Software Testing
A Context-Driven Approach
Cem Kaner, James Bach, Bret Pettichord
About This Book
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
Frequently asked questions
Information
The Role of the Tester
- 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.
- 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.