I. M. Testy

I would have loved to see some of Jerry Weinberg's books including the most recent one

"Perfect software and other illusions about testing"

1. Introduction to General systems Thinking

2. 3 volumes of "Quality software Management"

The beauty of these books is that first they shatter many myths about testing ... so for someone who is new to this field - Jerry's book would be right beginning... then they can easily understand other software testing books well. For many so called experienced testers, these books can be "eye-openers"

I agree that each of these books are written for some serious reading and are not for day-today tactical,prescriptive recipes (as you find in the books you mentioned especially Beizer and Copeland - how do I do boundary testing? What tool should I use etc).

I my opinion, book on General systems thinking is a must ... if you can read and understand the stuff in that book... you are ready for any real challenges in the world of testing ...

Shrini

>>> Gerald Weinberg's books are good books; especially for managers.

I beg to disagree of the second part. In the contrary they are like learning alphabets for every software engineer (more so for a tester). While managers can really benefit from them, it is required for those newbies. Reading Jerry's books would protect them from being brain washed by lots of testing folklore and other false notions of about software testing. It is like getting vaccinated against common diseases at the time of birth of a new kid.

>>>But, to me there is a big difference between strategic metaphysical discourses software engineering and the tactical and pragmatic application of software test design and execution.

Yes there is a difference. To me, those strategic metaphysical discourses and other philosophical perspectives are like "root" and are as important as foundation to a building. Once you conquer them, understand and assimilate them - you have won more than half of the battle. From that point, a tester will not only be able to quickly understand the tactical and pragmatic application of software test design and execution but also be able to go beyond and be able to design new things and critique them as well. I have personally experience these things so I am writing from that experience. Reading and understanding books like Beizer, Copeland and Binder will be lot more quicker and easier once you can digest the heavy yet basic stuff from Jerry.

>>> I suspect the part that you are missing from Beizer, Binder, Copeland, et. el. is that they provide examples of test design based on historical patterns of failures.

While I do not deny the value of reading books from these folks ... what they teach you "test design" and I am looking first learning from a very high level (general systems thinking in simplistic terms helps one to understand and tame the beast of complexity) at modeling the problem space, understanding interacting parameters, non linearity of the system, sociological interactions, software team dynamics, psychology of software people and many more. Armed with an analysis of this magnitude, test design is a some where deep down the line that I can easily pick up - well I can understand (and critique at times) the concepts better. And, you would know that I am not one of these testers who would view testing only from GUI.

>>> You ask "how do I do boundary testing?" I would recommend that you read chapter 5 in How We Test Software at Microsoft or any of my previous blog posts on the subject.

Yes, I am eager to read your book ... BTW my question of "how do I do boundary testing" was posed with an intention of showing an example where books that you quoted will be helpful (including your book probably).

>>> I know that some 'experts' promote the notion of testers sitting around debating such trivialities as whether or not the down arrow in a drop down control is 'correct.'

While I have not worked with or aware of any such experts who focus "ONLY" on trivialities (real experts will also look at trivialities among other things). You must also agree that in some contexts it might be really matter of serious concern when bug around such trivialities might cost the business millions of dollars. So I would not generalize any thing associated with test observations as "trivial". Moreover, as tester my job never is to pass a judgment about "correct/wrong", "important/trivial" - that would the decision product owners make, I can only highlight the inconsistencies.

>>> their employer via their cognitive abilities and skills, not by their incessant philosophical diatribes and completely out-of-context 'what-if' scenarios.

We have debated this times before on this blog... I must say that you can not see incessant philosophical diatribes as necessarily bad and unwanted things and term them always as "out of context". Thinking about philosophical perspectives, creative modeling of problem space, thinking about "in context" what-if scenarios is very important way to hone and improvise cognitive abilities and skills. You seem to value technical and tactical knowledge, in-depth understand of software systems over Philosophy and other abstract forms of thinking. That is OK ... we are different in our approaches to software testing ...

Shrini