1

I bought Binder's "Testing Object-Oriented Systems" book.

I'm a technical QA, and wanted to both strengthen my test automation skills and become more thorough. However, I found the book so abstract and difficult to understand, that I cannot make any practical use of it. I though it might be my opinion only but I found there are more similar views of experienced software engineers, so maybe there are objective hurdles to read and "apply" this book.

  1. How do you read this book?
  2. What problems have you solved thanks to this book?

There are people here who read this book and recommended it, so I believe the book can be useful in practice. I just need to hear how.

I've read a lot of technical literature, research papers, documentation so I was expecting this book will be both useful and legible to me. I am used to literature and research papers that are problem-driven. Books that follow a bottom-up approach, where a reader can build his or her own model of solving certain class of problems, by reading about those problems. This particular book does the opposite, so if someone can show me connection between real problems and the theory laid in this book, I might learn or motivate myself to grab for this book again.

Community
  • 1
dzieciou
  • 10,512
  • 9
  • 47
  • 100

1 Answers1

3

I agree that this is a difficult read, and quite different than other books that walk you through specific testing techniques applied to a sample problem step-by-step. Binder wrote "This book is more of a reference and handbook then it is a sequential tutorial."

Additionally, Binder (and B. Beizer) tend to approach software testing from the class level below the GUI. Having spent much of my career focused on API testing books by Binder and Beizer make a lot of sense. I guess if a person spends his/her career looking at software primarily through some graphical user interface (or web interface) then the book may be too abstract.

Part II discusses models. The chapter on state machine models provides a solid foundation for Model Based Testing and how to model a system. I thought his presentation of modeling is similar to how developer class diagrams.

Part III discusses patterns. Test design patterns are similar to the many design patterns used by developers in OOP. Test design patterns discuss the application of various testing techniques applied to OOP systems versus a procedural program.

I like the book because it made me think of test design patterns, and how to consider test designs . I agree it doesn't provide concrete directives on how to write a test case, but that is not its intended purpose.

I would also say that this is not a book that one should buy or read in preparation for an interview. I agree with the Amazon reviewer's statement "I don't recommend people who is new to testing, or who is trying to grap [sic] a basic view of testing in a short period of time."

But, for those who are experienced, and well versed in OOP programming this book may offer a different perspective on how to approach software testing.

Bj Rollison
  • 5,187
  • 16
  • 23
  • +1 Your answer's motivated me to sit and start reading a chapter because I'm not a GUI-only tester (in fact, I test mostly backend APIs), so no excuse. Happily, I found the chapter practical rather than abstract: I could relate some conclusions made in the book to my own experience. For instance, working on mocking at unit test level I understand that: "Attempting to test a class in isolation is often an exercise in futility". – dzieciou Sep 01 '13 at 20:50
  • Wow, reading more I'm finding Binder has a sense of humour: "Big Band Integration typically creates more problems than it solves. It is a common recourse under schedule pressure, but this is usually as effective as trying to put out a fire with gasoline". Make's reading easier. – dzieciou Sep 01 '13 at 21:47