Preface

We live in an age where software is everywhere. It is inescapable at this point. Some of it is trivial, meant for entertainment or passing time, while some software is the most mission-critical possible, maintaining the delicate balance between life and death for a person. Most software that we will interact with will fall somewhere within that continuum. It may be on the web, on our phone, on our watch, or measuring the weight of our workout water bottle, reminding us to hydrate ourselves at important times. Even if we don’t interact with it directly, software runs in many areas of our lives that we don’t even consider, including our financial institutions, our power plants, medical imaging systems, or in running continuous trials to find the best way to synthesize chemical reactions or fight deadly viruses.

What do all of these areas of software interaction have in common? Someone has to create them and deploy them but perhaps most importantly, someone has to test them. Over the past couple of decades, there has been a move away from that “someone” and more towards “something”, meaning automated tests in some capacity doing all of the testing work. Surely, software can do the work of a thousand testers, right? Yet it has come back in the news media and in high profile cases that maybe, just maybe, having people who truly understand testing is important, necessary, and should be prepared to do that work. That person does not need to have the title of “tester” to do testing. They can be a software developer, a lone hobbyist working on a passion project, or someone working with a server farm running systems, making sure they are operable, and people are able to access them. Testing happens at many levels and over the entire software development life cycle.

At its most basic level, testing is the actual experimentation that takes place in the scientific method. It’s the asking of “What if?” questions. It’s the joy of being sneaky and difficult with software, to try to find areas where the software is vulnerable and open to attack, where the person doing the testing can either support or refute the ideas at hand. Is the software fit for use, or is there a problem here?

Our goal with this book, Software Testing Techniques, is to help you, our esteemed reader, take hold of the fun and adventure that is software testing (and yes, it most certainly can be fun, and it is often quite literally an adventure). We want to give you skills, processes, techniques, and perhaps some novel ways of looking at the puzzle pieces of software testing. If that sounds like fun to you, buckle in and join us.