The book Lessons Learned in Software Testing: A Context-Driven Approach was published at the beginning of 2002 (December 31, 2001, to be exact) by authors Cem Kaner, James Bach, and Bret Pettichord.
While thinking to review this book, two questions come to mind: is it worth our time to read or write about such a 'veteran' book? Is it at all fair to write a review?
I think it is fair because all authors are featuring the book on their sites, so at least they think reading it is useful even today.
Is it worth our time? That is the mission I took upon myself. I better know Cam and James, and on my part, I was sure that at least some of the points would be useful.
The book is built as "a series of short, readable descriptions of a few hundred lessons." The book states very clearly that it is NOT a book for beginners, but for someone who "has been testing for a few years and might recently have been promoted to a supervisory role."
I think this point is very important because this statement sort of saves the book. But I'm getting ahead of myself.
The book is divided into topics, all are important to our profession, for example, The Role of the Tester. "Lesson Learned" is full of great advice, on various subjects, from how to approach testing and how to test to how to behave in front of your managers and peers, e.g. programmers.
Most lessons are excellent and relevant, and as claimed - from the real world. For example Lesson 5: Find important bugs fast, in which the order of testing is suggested. This is so important and relevant. Some lessons are ahead of their time. For example, the lesson that says "You can’t avoid bias, but you can manage it." I thought the bias about testing is a new topic from recent years. Moreover, there are some great testing lists for example about domain testing.
There is important information about Test Strategy, and - as may be expected - many useful heuristics, especially about test planning.
Having said that, there are some issues that I believe we should consider. Although the book is written after the publication of the Agile Manifesto and is aware of it, it still assumes "older" built organizations with test managers and project managers, etc., and doesn't refer for example to multidisciplinary self-organized development groups.
Related or not, it is also treating (between the lines but from my POV felt strongly) programmers with kid gloves. To avoid annoying programmers and thus creating "resentment or anger" before release, it is said, you should avoid reporting minor bugs or report them to a "hidden" bugs DB (Lesson 78). BTW how to treat minor bugs is confusing. First, " It’s your job to find and report significant bugs.". Then it says it is important to report all bugs, then - well, sometimes.
Also, the term Manual Tester appears a few times. Today they perhaps would say that there are no "manual testers", but each tester uses tools, one of which could be an automation tool.
On the other hand, some principles that we now associate with Agile exist here. The authors talk about lean documentation in lesson #46.
So why was the claim that this is no book for beginners important? Because if you have experience AND you read articles/other books/watched videos about modern testing you will not find it hard at all to decide for yourself what is relevant and what is not. And for me, I found many good pointers (if you would see the number of highlights in the Kindle edition of the book you would see how serious I am).
To sum things up: if you are somewhat of an experienced tester, buy this book. you will find it very helpful, fun, and easy to read.
Book review list: https://www.testerschoice.pro/book-review
Comments
Post a Comment