Review “Lessons learned in Software Testing”

I became aware of James Bach through the Google Techtalk “Becoming a Software Testing Expert”. Then I quickly got his book “Lessons Learned in Software Testing”.

In this book Bach presents with his colleagues Cem Kaner and Bret Pettichord 293 tips and tricks (“lessons”) from the test practice.

Divided into 10 chapters, this book covers almost every aspect that can be encountered in daily SW test work.

Similar to Rework, the strength of this book lies in the small, self-contained chapters. You can individually rate and apply each tip individually or not. The authors are advocates of the context-based test strategy; So there is no all-encompassing concept / strategy that works for every kind of SW product.

Therefore, the recommendations are sometimes deliberately contradictory, e.g. whether SW tests according to IEEE 829 should be documented or not. Just as a doctor only makes a diagnosis after a detailed medical history and then treats the patient, “lessons” are tools that are only to be used after a detailed analysis of the situation (industry, company, team, project, product).

At the beginning of this analysis, the tester must scrutinize himself and his mission in the development process. Insights such as that you can never find all the mistakes and therefore never completely test, sound obvious, but should always be kept in mind to get your own motivation.

The tester does not verify that the product is working, but shows that the product has a defect at a certain point. Word!

The fact that the tester primarily supports or relieves the developers is an idea that is far too rarely taken into account in practice. Test departments are often perceived as opponents rather than as partners.

The following chapters cover the handling of test techniques, bug reports, automated tests, test documentation, the exchange with the developers, as well as the management of the own test team.

The conclusion of the book are the two topics career in SW-test and creation of a test strategy.


If you are looking for a strict roadmap that simply has to be implemented one-to-one to ensure software quality, you will not find it here. On the other hand, if you are looking for suggestions and critical questions to continuously improve yourself and your work, you will find enough material in this book to deal with it for several weeks to months.

Review “Rework” by Jason Fried und David Heinemeier

Today I introduce you to one of my favorite books, “Rework – Business Smart and Simple” by Jason Fried and David Heinemeier Hansson. The two authors are the founders of 37signals and have developed the framework Ruby on Rails, on which most of their products are based. After devouring their first work Getting Real in the online edition (, it’s time to spend the money on a hardcover. I like books that pragmatically approach the topic of business start-ups / company founding, so get straight to the point:

On a total of 281 pages, Fried and Hansson reiterate their experiences from the founding of their company and the projects they have implemented.

The chapters are very clear. Normally between one and two pages. So you can read this book well in small doses – keyword: bathroom reading. Fine!

A small selection of exciting theses:

Why grow?

One of the core themes in the book is the principle of simplicity. Applied to the company, this means: why does the company have to grow?
Especially in the field of IT, there is a reflex of the sort “more projects – more people” to watch, although “better tools, more cooperation and clever (time) management” may be more the answer.

Start a business, not a startup

As I wrote in my article “15 Steps to Successful Bootstrapping – Part 4”, startups are not exactly realistic. Cash burn rate and exit strategy, but often not a solid business model with profit, that complain Fried and Hansson.

Get to bed / Send your employees home at five / Workaholics

These chapters clear up the prejudice that only total expenditure leads to remarkable benefits. The opposite is often the case: Permanent overtime, lack of sleep and a “What are you going to do now?” – culture in the long run only to exhaustion and at worst burnout. Stop it.

Meetings are poison

Meetings should be as short as possible, or completely eliminated, as they often bring astonishingly little insight, but at a high cost. A one-hour meeting with 10 people is actually a ten-hour meeting.

Bottom Line

Relaxing to read, translation into German also fits. Entertaining, humorous and often provocative. This is how management literature works today.

P.S .: Incidentally, the German new edition means Meetings are poison: plea for a new business culture, so do not be surprised.