- This topic has 4 voices and 5 replies.
-
AuthorPosts
-
-
James Whittaker is well known in software testing circles, even a bit of a rockstar, as they say. His most recent book, “How Google Tests Software”, is quite good, though its relevance to a small, primarily text-based site such as HBL is perhaps questionable. I look forward to reading more of his works, starting with http://www.amazon.com/How-Break-Software-Practical-Testing/dp/0201796198
-
This looks like a very interesting book. I have moved this comment over to the book & movie recommendations forum.
-
This book does indeed sound interesting. Even though I am no longer in the business of testing software, after looking at the description on Amazon I might like to have a look at it. I like the fact that Whittaker stresses ‘intelligence, insight, experience and a “nose for where the bugs are hiding” ‘ to guide the tester.
-
A “nose for where the bugs are hiding” does not sound right to me as most of the time the bug is not simply a line of concrete code, but more of an abstract problem; universal variables always screw up my local variables and vice versa — programmers will know what I mean.
-
Mr. Barnes seems to suggest that “a nose for where the bugs are hiding” implies that a bug is “a line of concrete code”. A bug can be anywhere in a single line of code, conflicts in the naming of variables as Mr. Barnes suggested, or in the whole approach to a section of the code, or in the absence of some needed code, etc. It can be small or large, abstract or concrete. In testing, you need both a general idea of where the problems might exist, and also the ability to put yourself somewhat in the mind of the potential user and the mistakes that he might make, which could put the code into a situation for which the programmer did not plan.
-
You said: conflicts in the naming of variables as Mr. Barnes suggested
Conflicts not so much in the naming of the variables (or perhaps by naming you meant assigning a class to each variable), but in the fact that in more complex programs a universal variable (I guess otherwise called a global variable, I am bad for remembering the nomenclature) will not work in a localized context, and vice versa. I program games so this is a common problem.
Your intrepretation of Whittaker s quote makes more sense, but I would venture it takes more than intelligence, insight and experience, which really could apply to any profession, and would have to add tenacity and the ability to think abstractly as well as concretely — I would venture to say both sides of the brain would have to fire simultaneously.
-
-
AuthorPosts
- You must be logged in to reply to this topic.