We all are told constantly not to think like a programmers.
We’ve told other people dozens of times “Don’t you think like a programmer. We don’t care why the software does it – it is still wrong”.
For testers, thinking like developers is evil. If you think like a programmer, you’ll start excusing the software and will forgive the system’s bugs.
I am reading the very cool book “Dreaming in Code” by Scott Rosenberg, and I just understood a little bit more on why’s so bad sharing the developers mindset.
Scott starts its book with Chapter 0, a common practice in computer literature. When enumerating the reasons, he explains that “Programmers count from zero, not from one. (…) Why do programmers count from zero? Because computers count from zero!” and that developers are taught to think like computers.
This is a very interesting and basic concept.
Dr. Parnas in his “Strategic Defense System” paper (a real favorite of mine ;)) has a whole chapter called Why conventional software development does not produce reliable programs, in which he clarifies this problem — developers thinking (or trying to think) like a computer:
As we continue in our attempt to “think like a computer”, the amount we have to remember grows and grows. The simple rules defining how we got to certain points in a program become more complex as we branch there from other points. (…) Because one needs to remember so much (…), new problems are created when old problems are corrected.
The beauty in all this is that Testers should not exercise the programming rationale (when analyzing a software) because they’ll be mimicking the rationale of the very same software they are testing. They are limiting themselves to what the program knows about itself, instead of expanding their logic to people-centered matters — i.e. how the software will be used and what it is really meant to do.
Back to “Dreaming in Code”, Scott has an almost poetical way of writing the concepts developed by Dr. Parnas.
Because computers think from zero, “programming include little offsets, translations of ‘+1’ or ‘-1′”, he says. So:
There’s a space between (…) the way the machine counts and thinks and the way we count and think. When you search for explanations for software’s bugs and delay and stubborn resistance to human desires, that space is where you’ll find them.
Poetry. 🙂
Pingback: Testers don’t think like Developers think like Computers | Qualidade de Software
Pingback: Should/Need Testers know how to Program (a Testing Question from Brazil) – Testing Thoughts
#1 by Shmuel Gershon on October 20, 2009 - 15:18
Warning: Undefined variable $my_comment_count in /home/public/wp-content/themes/arclite/functions.php on line 682
Quote
Dear Anon,
Coding isn’t a required background for testers. Coding skills will help on coding tasks, and sometimes with system understanding. But a diverse background will make the team thrieve and explore the system in fruitful ways.
A domain expert can bring much more value than a B.S. in Computer science. For example, when building an application for trading stocks, a tester with a buying/selling stocks background will find valuable information.
(See lesson 235 in “Lessons Learned in Software Testing” by Cem Kaner, James Bach and Bret Pettichord – “Staff the testing team with diverse background”).
Of course, there is no 1-size-fits-all, and different projects may require a different team profile. Just as different managers or different contexts may.
In essense, I would agree that teams should be encouraged to hire non-coder testers. Or, if not encouraged, the practice should be considered perfectly acceptable.
Thanks for stoping by and commenting! 🙂
#2 by Anon on October 12, 2009 - 15:47
Warning: Undefined variable $my_comment_count in /home/public/wp-content/themes/arclite/functions.php on line 682
Quote
So it sounds testing teams should be encouraged to hire people *without* any coding background.