The Beauty of Serious Work by Andreas Meichsner

"The Beauty of Serious Work" – project (2011–2013) of photographer Andreas Meichsner about product testing by the German Association for technical inspections. This association is responsible for certifying the safety, performance, and quality of consumer goods and technical equipment.

Before going into mass production, prototypes of most consumer products will undergo a wide range of certification tests to ensure the required standards, which may vary, depending on the type of product and the country where the product is to be distributed. An aspect, that increasingly has to be taken into consideration in nowadays' globalized mass production processes.

Hackers: Heroes of the Computer Revolution by Steven Levy

Hackers: Heroes of the Computer Revolution by Steven Levy – very interesting book, which is not about testing, but about hardware and software history.

By sheer dint of hacking, the TX-0 no, the PDP-1 hackers had turned out a program in a weekend that it would have taken the computer industry weeks, maybe even months to pull off. It was a project that would probably not be undertaken by the computer industry without a long and tedious process of requisitions, studies, meetings, and executive vacillating, most likely with considerable compromise along the way. It might never have been done at all. The project was a triumph for the Hacker Ethic.

It is full of charming stories about how some things were invented and how hackers were dealing with problems.

One of Minsky's contributions to the growing canon of interesting hacks was a display program on the PDP-1 called the Circle Algorithm. It was discovered by mistake, actually while trying to bum an instruction out of a short program to make straight lines into curves or spirals, Minsky inadvertently mistook a "Y" character for a "Y prime," and instead of the display squiggling into inchoate spirals as expected, it drew a circle: an incredible discovery, which was later found to have profound mathematical implications.

He would help develop a program called "The Dictionary," which corrects an Apple user's spelling, but then would place a magazine advertisement for the product which contained ten spelling errors, including a misspelling of the word "misspell."

The joke is, if Draper were writing math routines for addition and he came up with the answer 2 + 2 = 5, he would put a clause in the program, if 2 + 2 = 5, then that answer is 4. That's generally the way he writes programs."

The book describes in great detail the Hacker Ethic and raises a lot of philosophical questions.

He'd [Ricky Greenblatt] twist back in his chair, looking not as rumpled as he did back as an undergraduate, when he was cherub-faced and dark-haired and painfully awkward of speech; the question, he figured, came down to whether hackers were born or made, and out came one of the notorious non sequiturs which came to be known as Blattisms: "If hackers are bom, then they're going to get made, and if they're made into it, they were bom."

The perfect algorithm. You'd have hacked right into the sweet spot, and anyone with half a brain would see that the straight line between two points had been drawn, and there was no sense trying to top it. "The Right Thing," Gosper would later explain, "very specifically meant the unique, correct, elegant solution ... the thing that satisfied all the constraints at the same time, which everyone seemed to believe existed for most problems."

"The technology has to be considered as larger than just the inanimate pieces of hardware," said Felsenstein. "The technology represents inanimate ways of thinking, objectified ways of thinking.

"To me, the best teachers tell me what I know is already right," Lee would later explain

Reading this book you may understand better why today's world is such as it is.

BASIC had spread all over the country, all over the world. And it helped Gates the fact that everybody had Altair BASIC and knew how it worked and how to fix it meant that when other computer companies came on line and needed a BASIC, they went to Gates' company. It became a de facto standard."

This book is filled with love for computers. If you ask yourself not only how, but also why – you may like it.

Les Solomon would speak in hushed terms of the project he was about to introduce to his readers: "The computer is a magic box. It's a tool. It's an art form. It's the ultimate martial art... There's no bullshit in there. Without truth, the computer won't work. You can't bullshit a computer, God damn it, the bit is there or the bit ain't there." He knew of the act of creation that is a natural outgrowth of working with the computer with a hacker's obsessive passion. "It's where every man can be a god," Les Solomon would say.

Perfect Software And Other Illusions About Testing by Gerald Weinberg

Perfect Software And Other Illusions About Testing – I am a little bit confused by this book and can't decide did I like it or not. Some chapters are good, some are too obvious. Obvious, of course, for me, maybe not for others, but I value books according to what new they can give to me.

First of all – version for Kindle on the Ebay is awful. All content is in one chapter (actually there are several chapters, but they are not formatted properly), which makes navigation harder:

There are some concrete characters in the book, with whom are made some examples. A lot of them are quite trivial and overdone, so they seemed pointless for me:

Some claims are doubtful. For example, claim, that the most important value of review is learning – for me it sounds like learning is the very last excuse why you should do review, because all other reasons doesn't fit. Usually (and I think in that case also) learning is a good side effect, not the purpose.
Update: see discussion in the comments about this item.

Another example – author categorically thinks that tester should not answer the question "Is the software ready to ship?" – I think that good tester definitely should answer this question and in modern projects roles are not so strictly divided:

But some claims are good and interesting:




Seems like this book is good for developers, who want to test and for testers, who are involved in testing for many-many years and they need to learn again how to test (with up-to-date tools and approaches). But for young testers, who are learning to test from scratch there are too many obvious and out-of-date recipes.

And beautiful parallel in the end:

The Psychology of Software #Testing by John Stevenson

The Psychology of Software #Testing by John Stevenson – great book for all testers. It's useful for beginners, full of resources for further advanced study and full of great quotations.


"Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn't really do it, they just saw something. It seemed obvious to them after a while." Steve Jobs – Wired Magazine
Basically the book is collection of references to interesting articles and books and brief analysis of them. At the same time it contains all necessary information, so themes are developed and there is no need to look into referenced articles for explanations.


As one of my previous post stated I think to be creative we need to think about finding problems than trying to solve them. Continuing on the path of our focus being only to solve problems restricts our creative thinking.
I was looking for this kind of book for a while. A book about testing, but not about techniques, methodologies, reports and other skills. There are psychology books and articles that are useful for testers, but there aren't many books, which connects psychology with concrete testing cases and possible situations.


Testing is not just about finding defects it is about asking questions and forming theories based on the answers (evidence) given while experiencing the software.
<...>
Finding defects is a side effect of this approach, a very useful side effect, however, it is not the sole purpose of testing.
Book asks not only psychological but also philosophical questions.

if testers should be problem solvers or problem finders

They like to know that, say, a dog will bite a man. That is what dogs do. They don't want to know that man bites a dog, because the world is not suppose to happen like that. In short, what people think they want is news, but what they really crave is olds.

"I would like to remind people involved in testing that – after and engaged brain – one of our most useful testing tools is... the pause..." Michael Bolton
The book is quite small and you can read it in one evening.

The Cartoon Tester Vol. I by Andy Glover

The Cartoon Tester – pretty good book of Andy Glover's cartoons about software testing. All cartoons can be found in his blog, but book is cooler: more organized and more pleasant to read.


"I've checked every square foot in this house. I can confidently say there are no mice here."
Making fun of serious things is always healthy and good for the field, so I am glad, that there exists such book about testing. Sad, that there is no paperback version – it would be a great gift for tester.


It's very nice to have this book on my e-reader, so I can always read/see some comics when I don't have much time for reading, but need to somehow entertain myself.


"Look! They've got it all wrong. Mice can get into the house in many ways. Through windows, drains, the cellar, need I go on?"
You can buy book at LeanPub or Amazon, download free sample there or read comics at Andy Glover's blog Cartoon Tester.

Secrets of a Buccaneer-Schoolar by James Marcus Bach

The complete title of the book is Secrets of a Buccaneer-Schoolar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success. The book is not about the testing or even software, but about self-education. However there are a lot of examples from testing area.


Shortly - I really-really liked it. First of all, as we all know, the author dropped high school - me too. So the philosophy about schools and universities is very familiar to me. I want to give this book to all people who make surprised face about that fact in my biography. In my case, I was very successful in middle school (graduated with honors) and people just don't understand why I don't want to get a paper about high education. Answer is actually very simple - because there isn't such profession as tester or even software engineer, there is only IT (which is much wider). So I want to go deeper, not wider. And this book proofs that this is a normal decision (sometimes I wasn't sure about how smart this decision was).


"Perhaps the secret to happiness is finding the games we love to play, instead of learning how to win a games we hate."
The book is full of very bright and simple statements, that I understand intuitively, but was never able to put them in words. So it sorts some thoughts and puts them in right places.


"Intelligence is just a tool. Love is the point."
Great metaphor: you should encourage your mind to wander - like keeping dog on a long leash:

The text itself is very simple, but it's full of weird words - I was looking for definitions in dictionary all the time. And this is actually quite fun, because all these strange words are understandable through context, so the meaning of text is not lost, but English is improved.

In this case I wanted to look up a word in dictionary from explanation itself (unfortunately you can't do that in Kindle)
Sometimes even dictionary didn't know the word. For example, unjammed:

So, I strongly recommend read this book to all testers (actually all people). It makes your mind wider and more open.

One more magic idea that I really liked - "the most wonderful thing I do in my entire life may happen in the next ten seconds."

How Google Tests Software by James Whittaker, Jason Arbon, Jeff Carollo (2012)

I read it in Russian translation

I really-really liked it. It's the most interesting book about software testing that I've ever read (considering the style of language and the amount of useful or enjoyable information).

It gives very good picture about what does it mean to be a good tester no matter where or in what conditions.

«A tester finds a bug and takes a moment or two to savor it. Seriously, this is important. Not only are we allowed to take a moment to enjoy the fruits of our labor, it’s important to understand subtle nuances of the bug and the circumstances of its appearance.» (James Whittaker)

The cover of Russian edition is brilliant: it shows fundamentals of Google quite precisely

Sometimes seemed that there is too much text about roles, hierarchs and responsibilities in Google. The idea about structure of workers is too detailed and takes a lot of space.

But the list of things that I liked is much longer:

• short interviews with key people – you can find there interviews of google people with different roles and positions (which are connected to the testing) and with different experiences and opinions. Reading these interviews I had an idea that it would be interesting to read a book about unsuccessful projects and experiences in Google.
• parts about interviewing candidates on different testing roles – very useful information which helps to understand who big company (not necessarily Google, but actually every normal company) wants to hire and what they are waiting from the good candidate.
• Design Docs chapter – good chapter with nice suggestions such as grammar correctness: «sloppy work that does not bode well for the code they will write later. Don’t set a precedent for sloppiness.»
• the idea that «Testers are there to make developers more productive» – actually my previous post All Participants Work For The Benefits Of The Project is about it (which was written just before reading this book).
• the idea, that testing is privilege that can afford only big and important projects – «quality is not important until the software is important» (Alberto Savoia)

I agree with authors that this book is useful for experienced testers (not for juniors). It assumes that reader has already thought about some software quality problems and maybe even have found some solutions – only then you can do justice to Google's solutions.

«Quality has to be built in, not bolted on, and as such, quality is a developer task. Period. This brings us to fatal flaw number 1: Testers have become a crutch for developers.»
«The second fatal flaw is also related to developers and testers separated by organizational boundaries. Testers identify with their role and not their product.»

About other fatal flaws you can read in Google Docs: How Google Tests Software.

Lessons Learned in Software Testing by Cem Kaner, James Bach, Bret Pettichord (2002)

I like it.
It's a long-play book, that you can (and want) to read from time to time. It is designed for coming back: it has 293 lessons with very clear topic and with some thoughts about this topic. So, if you want to read something about specific problem, then it is quite easy to find thoughts about it.

I like that authors don't afraid of short explanations - for example, lesson 4 have only 5 rows and it's nice, because there is no unnecessary information in it. There is a lot of big books with big chapters where concentration of useful information is actually very low. Not in this book.
I am agree with Tim Lister, who said (on page XVIII of this book): "If you have never participated in a serious software effort, this book will be too heady for you." This book is for experienced testers, not for juniors. It can be useful for those who have already encountered with some problems in testing and have been already thought about them.

But I am not quite agree with further "rule of using" this book (also from Tim Lister on same page): "Don't drink the entire bottle" Meaning "don't read this book in one sitting". I've read it in one sitting for the first time, which gave me general overview of it's content. For me it is not very important to understand all things in first time, it is more important to know what sort of information you can find there so you can return to it later.

So I think every tester should have their own copy of "Lessons Learned in Software Testing" - it is not that kind of book that you can borrow. It is very useful when you can come back to it whenever you want.

Testing Applications on the Web by Hung Q. Nguyen, Bob Johnson, Michael Hackett (2003)

I've just finished to read this book and decided to write an opinion about it.

In short - I didn't like it. It's too obvious, too direct, too general and too big.

Examples of why obvious:
There are multiple browsers and browser versions available for PCs, Macintosh computers, and UNIX computers. (page 130)
Remember, for any valid condition, there is always an invalid condition. (page 259)

Examples of why direct:
In testing for DLL-related errors, do the following: ... (page 143)
In a server-side installation, the user (usually an administrator) must, at a minimum, be able to specify the following: ... (page 374)

Example of why general:
Simply put, an effective UI design is one that provides the highest usability to the users. (page 247)

Why big? I think, all information that is written on 644 pages could be shortened to 100 pages, or even less.

So, I can't suggest this book for experienced testers, because I don't think they find anything that expands their knowledge or makes them think in a new way. And I also can't suggest this book for new unexperienced testers, because normal person can't keep in mind 644 pages of todo lists and document templates and, again, because it doesn't make reader to think.

Also some things are not valid nowadays: for example, chapter about response time (internet is way more faster now); or some suggested tools; or some links are broken now (and there are lots of links in the book).

But there are a few things that I liked. First of all, it's a first book where I've read about The Combinatorial Method (page 78, Chapter 3).
Basically, with that method you can extract from, for example, 27 unique combinations 9 that are worth testing (I've even thought about using that algorithm in my next extension).

Also chapter 18 "Web Security Testing" is not bad. It is very long chapter (maybe that's why it seems to be quite thorough). And I think that it's introduction explains quite well why this topic is interesting:
Security issues are becoming the gravest concern of many companies. Despite this fact, security testing often remains the least understood and least well-defined testing activity.

In conclusion, I would like to tell that this book is not worth the time that it requires.

The Sience Of Debugging by Matt Telles and Yuan Hsieh

I strongly recommend to read this book - The Science Of Debugging by Matt Telles and Yuan Hsieh. I really like how and what authors are writing about bugs. Especially I liked the Chapter 2: Case Studies of Famous (and Not So Famous) Bugs with summaries and points what we should learn from the others' mistakes. Don't be confused with the "debugging" word in the title - book is also interesting and useful for the testers who just find the bugs, not reduce them.

Also I recommend to read a short article History's Worst Software Bugs by Simson Garfinkel, which shortly describes some of the cases.