“The Art of Software Testing”: book review

Hello and welcome to my first-ever book review :)
Today I’d like to discuss with you a book called “The Art of Software Testing”, 3rd edition by Glenford J. Myers, Tom Badgett, and Corey Sandler

Introduction

I am a software developer, so the book choice might seem a little uncommon to you.
The main reason that caused me to read this book is that I am a big proponent of software testing. I think testing, when done right, is one of the most important factors in the success of the project. And I’m not talking only about the work of QA engineers. The development of automated test suits is an integral part of the work that software engineers do. For me, tests probably bring the most joy in the whole software development cycle, especially when I used TDD. Seeing that tests that initially failed, cause they were running against the “empty” class or method, actually start to pass is very nice. It might have something to do with my competitive programming past :)

What did I like about the book?

1. Description of what a successful test is. A successful test shows that your program does NOT work as expected, not the other way around. Changing the mindset around that seems pretty important to me.
2. Discussion of the psychological aspects of testing. We, as creators of our programs, on a deeply psychological level do not want them to fail. We have to fight this. And also this shows why the program should not only be tested by those who created it.
3. Definition and examples of the types of software testing (white-box and black-box testing; unit, integration, function, system, acceptance, and installation testing)
4. A detailed description of the main techniques of software testing and the design of the test cases.
5. Description of how to know when to stop testing a program. A thorough discussion of several code coverage metrics.
6. Special chapters that appeared in the 3rd edition that discuss testing of web and mobile systems
7. Discussion about debugging.

What I did not like about the book?

I think some of the techniques described in the book are too complex to apply to a real-world project. It probably sounds like a lame excuse for my laziness, but I can hardly imagine how, for instance, cause-effect graphing can be applied to a project with thousands of requirements and hundreds of thousands of lines of code.

What are my main takeaways?

1. Software testing is hard. Like, really hard.
2. Almost every, if not every software product contains bugs.
3. Bugs’ severity for the user differs greatly.
4. Because of 2 and 3, it is a challenge to determine when the software is not likely to have bugs that are vital for a smooth user experience.
5. Software testing can not be done only by developers.
6. Psychology matters
7. Debugging is a non-trivial process. Think first, use “brute-force” debugging methods second. Once again, from the psychological point of view, it seems like a waste of time. Why think if you can simply run your favorite debugging tool, watch some variables and find the issue? The argument here is that thinking first might save a lot of time and also help find errors on a deeper level.

Would I recommend reading this book?

I think, yes. It is not the most eye-opening book ever, but it is still good. I’d give it 4 out of 5 stars.

Who should read this book?

First of all, developers and QA engineers. But I think people who manage software projects might also deepen their understanding of how to supervise the team successfully.
The book is not hard from a technical point of view. If you are a strong junior engineer (or even a more experienced specialist) and interested in the topic, the book might be a good read for you.

What are your thoughts on software testing? What books on this topic would you recommend? Feel free to share your suggestion in the comments and thanks for reading!