Taking Testing Seriously (eBook)

The Rapid Software Testing Approach

James Bach, Michael Bolton (Autoren)

eBook Download: EPUB

2025
843 Seiten
Wiley (Verlag)
978-1-394-25320-3 (ISBN)

Infos

Elevate your software testing approach with a methodology from industry leaders who dedicated their careers to studying, practicing, and teaching the craft of testing.

Dive into the world of expert software testing with Taking Testing Seriously: The Rapid Software Testing Approach. This book arms software professionals with the knowledge required to master the Rapid Software Testing (RST) methodology. Written by two co-creators of the RST approach and supplemented by material from respected testers who offer valuable insights, it is an essential read for anyone seeking excellence in the craft of testing.

Taking Testing Seriously offers a rich exploration of the RST methodology through insightful interviews, expert discussions, practical case studies, and real-world examples. It thoroughly covers key topics such as the psychology of testing, the science behind it, the fundamental processes and heuristics of test design, and much more. This book provides concrete strategies for addressing common software testing challenges and integrating new solutions with existing systems.

You will:

• Gain insights from experienced software testers through in-depth interviews and expert advice
• Learn how to the skills of testing are needed more than ever in an AI-powered IT industry
• Discover strategies to leverage the latest automation technologies to refine and expedite your testing processes
• Escape from the echo chamber of 'best practices' and learn to think critically about testing

Focusing on the mindset and skillset of excellent testing, Taking Testing Seriously is a must-have resource for software engineers and technical leaders eager to improve their testing proficiency. Whether you are looking to advance your career or simply want to ensure your next project meets the highest standards of quality, this book provides the tools you need. Order your copy today and start transforming the way you and your team approach software testing.

JAMES BACH is the creator of the Rapid Software Testing methodology, founder and CEO of software testing and training company Satisfice, and the co-author of the critically acclaimed bestseller Lessons Learned in Software Testing (Wiley 2001).

MICHAEL BOLTON has over 30 years of experience testing, developing, managing, and writing about software. For over 20 years, he has led DevelopSense, a Toronto-based testing and development consultancy. In 2006, he became co-creator (with creator James Bach) of Rapid Software Testing (RST).

Textauszug

CHAPTER 1
Why Another Book About Testing?

—By James Bach and Michael Bolton

Many Cultures of Testing

We have a cultural problem in testing: too many of them. Too many testing cultures, that is. (National or ethnic cultures are not a problem for testing but rather a benefit.)

We could start this book like everyone else does—writing as if all the testing experts in the world agree on what good testing is. They don't agree, so let's not do that.

This is a book written by two guys, James and Michael, plus some close colleagues who have some different takes, yet still share a testing culture. We are full of opinions about the best ways to think about testing. But we are not authorities on software testing, because no one is an authority on software testing. It's just a bunch of people and their beliefs.

By “culture,” we mean “the distinctive ideas, customs, social behavior, products, or way of life of a particular nation, society, people, or period,” after our favorite dictionary, the Oxford English. There are different cultures of software testing in the English-speaking world, all using mostly the same words to describe the testing craft—but not meaning the same things by those words!

It can be a bit maddening because the various cultures rarely label themselves—or even admit that others exist. Instead, we talk past each other. In 1999, Cem Kaner, James Bach, and a few other friends declared ourselves a distinct “school” of testing thought. We named it Context-Driven. By establishing a school, we sought to differentiate ourselves from the other schools, as we saw them. There was never widespread consensus about how the schools should be identified and named, but we (Michael and James) currently break them out as follows:

• Factory School: Believes that testing should be centered on artifacts and algorithms rather than testers—like a big factory where the workers could be replaced with robots, at least in principle. This school dominates the industry, especially the government sector and regulated contexts.
• Quality School: Believes that creating quality should be the central concern, and that testing is a minor and somewhat distasteful activity compared to quality advocacy. This school tends to advocate against having a dedicated tester role because the “whole team owns quality.”
• Agile/DevOps School: Like the Quality School but dominated by imperatives and mechanisms of product delivery. This school believes that testing should be done by developers and automated as part of the continuous delivery pipeline. It holds that full-time testers should not exist, except as a temporary expedient.
• Analytical School: Found almost exclusively in academia. This school believes testing is a part of computer science. It sees testing as an algorithmic process and seeks theories and methods to mathematically model and optimize testing under controlled conditions.
• Context-Driven School: Believes there are no best practices and that all professional testers should cultivate the skills to design and justify test practices that fit their projects. This school holds that testing is a social, psychological, and heuristic process. Rapid Software Testing (RST) is a Context-Driven methodology.

Each of these schools of thought is a paradigm—that means an all-encompassing worldview. The concept of paradigms in science was developed originally by Thomas Kuhn in his seminal work The Structure of Scientific Revolutions.1 We say these schools of thought, above, are paradigms because when we encounter thinkers from other schools, we don't recognize that what they are speaking about is testing. That's how different they are from us. It's notoriously difficult to have conversations between paradigms, not only because words are used differently, but because an important problem for one side may not exist for the other. For instance, Factory School testing practitioners worry about getting their test cases right, whereas a Context-Driven tester may go through an entire project without even thinking about test cases. When a Factory Schooler misses a bug, he thinks, “I missed it because I didn't have a certain test case. The solution is to add that test case.” When we miss a bug in RST, we think, “What can I learn from this? Only then will I know what to do about it.” From the Factory point of view, RST looks like vainglorious philosophizing; from the RST point of view, Factory looks like a ritual to please the bosses.

Ludwig Wittgenstein used the term “form of life” to describe the totality of practices, behaviors, rules, patterns, etc. that comprise human social life. He famously claimed that all language is grounded in a form of life and cannot be understood apart from the activity from which it emerges. You can't understand what words truly mean unless you are immersed in the culture of those words.

Why are we writing about all this philosophical stuff? To prepare you. The culture of testing described in this book is likely to be different from what you will pick up by watching people on typical software projects or watching testing demos online. The Context-Driven way is not just a method: it's also a paradigm, a culture, a form of life.

Check the title of this book. Prepare to take testing seriously. If you want to develop yourself into an expert in software testing, we want to help you be a discerning customer in the marketplace of testing ideas.

But if paradigms are all-encompassing worldviews, how can it be possible for someone to change paradigms? Why would anyone want to pick and choose ideas from different paradigms? After all, each paradigm covers everything in the world. Thomas Kuhn's answer was that paradigms compete based on the puzzles they leave unsolved. If you get tired enough of those puzzles, you become open to other ways of being and working. This is what leads to scientific revolutions.

Other paradigms of testing look for the perfect set of best practices. The unsolvable puzzle of puzzles comes down to that. The authors of this book believe they will never succeed. The Factory School has dominated the field since the 1960s, and what they have to show for it is the V-model, ISTQB certifications handed out to anyone who can memorize rote answers, and a testing industry that is even less respected at the time of this writing than it was 40 years ago. The Agile/DevOps crowd is now ascendant, which is making nobody want to be a tester. (They want you to be a “team member” and not focus on testing.) AI-based test tools, some of which are intriguing and others astonishingly bad, are confusing managers into thinking they can test at the push of a button. The industry lurches from trend to trend and tool to tool, yet too many software products are unreliable and unsatisfying to use, and users are being conned into believing they ask too much to expect their products to work as promised.

We in the Context-Driven paradigm believe that people, heuristics, skills, and ethics should be our focus, because that leads to finding more bugs and better bugs; it attracts more talented people into the testing field; and it makes for a better society. The tough puzzle for us is how to train and manage testers to operate in a world that mainly cares about making a quick buck and that wishes testing were a fixed algorithm rather than an open investigation.

Again, Rapid Software Testing is one example of a Context-Driven test methodology. It's not the only one out there, but it's ours, and we offer it to you.

Why Us?

We said, above, that the authors of this book are just a bunch of people with beliefs. That's not quite right. We intended the word “just” in that sentence to emphasize that we have no authority. But the whole truth is that we are more than merely people with beliefs.

We are people who love testing.

We profess our love by studying testing and practicing it, not only professionally, but on our own time. Everyone who contributed to this book has embraced testing in some way, during a substantial part of their working lives, and won the respect of their peers for doing so.

We think good testing is fun to do, fun to talk about, and fascinating to study. Good testing touches upon deep elements of philosophy and humanity. It causes us to ponder, like Socrates, how we can know anything, and suspect, like Pyhrro, that we can't know anything for sure—that we must learn to live with uncertainty. We love testing partly because it turns philosophy into a working tool.

If you want to get good at testing, consider learning about it from people who aren't madly grasping for any excuse not to do it, wishing that their robots or AI agents would do it instead. Learn about it from people who aren't openly craving to write code instead of finding bugs. Yes, James and Michael write code; we do it because testing with tools is a powerful way to find bugs—not because it's a way to avoid having to interact with and experience the product.

Learn from people who affirm your agency. Yes, you will see our strong opinions in this tome. No, we don't expect you to shut up and obey us. When James and Michael were young, we challenged the graybeards of testing, and now that we are gray, we encourage people to challenge us. You will notice that the contributed chapters...

Produkt-Details

• Erscheint lt. Verlag: 21.10.2025
• Sprache: englisch
• Themenwelt: Informatik ► Software Entwicklung ► Qualität / Testen
• Themenwelt: Technik ► Elektrotechnik / Energietechnik
• Schlagworte: Automated Software Testing • software testing approach • Software Testing Automation • software testing book • software testing guide • software testing methodology • software testing playbook • software testing strategies • Software Testing Techniques
• ISBN-10: 1-394-25320-6 / 1394253206
• ISBN-13: 978-1-394-25320-3 / 9781394253203