Annotations from day 24/06/2008 of the Sigist conference on Software Testing.
When not from a lecture focus, then from a side comment or explanation. Below you’ll find some insights I gained from today’s lecture. When not from a lecture focus, the ideas come from a side comment or explanation:
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.
I’ve started a quote collection. Many times I want to quote someone but I just don’t remember how exactly the phrase was. Or remember the quote but am not certain on the source…
I am fond of quoting.
Not sure why, but I like to quote. I guess it gives some legitimating to what I am saying. 
So, the quote collection is available at this address: http://testing.gershon.info/quote-collection/. It will grow slowly, please check it regularly.
Do you use MS Office 2007?
Well, then you probably noticed that Excel multiplies “850 x 77.1″ as “100,000″ instead of “65,535″.
Uh, you didn’t notice? Well neither did I until I read it all over the internet.
See the post on SlashDot for scoop, and see its comments for some good laughs.
There are explanations all around about how this bug came to appear in Excel.
The best one is probably Joel’s one (you may remember Joel from this post). (more…)
When I started the blog, I planned on at least one post per month.
I managed pretty well, with 15 posts in a year, plus a handfull of draft wanderings that maybe will se the light someday…
But then the new year came and everything wreaked havoc. 
I had hosting issues (of which I am to blame for most) and then had to make a new and different account and restore everything, from the WordPress system to the posts databases, including tweaking the code to look for everything in the new locations. Too much work, too little coffee.
So that’s the reason.
And new year is coming, this time, in April .
Happy New Testing Year, then!
Let’s see if I can continue with the post a month this time
I was once talking with a friend about automation and when it should be done. I commented with him about the excellent “When Should a Test Be Automated?” paper by Brian Marick, and told him that “this is one of the three texts that changed my testing life”. I surprised myself by the fact these three texts were categorized in my head as such, and with the promptness I could think of them at the spot.
So I want to share with you these articles, with a bit of background on them, and hyperlinks wherever I can find them. They are presented in the (chronologic) order they came to my attention.
Now, here is more about testing untestable systems.
Please read “He Who Can Not Be Tested” and “He Who Will Be Tested!” before you continue, if you want to be in the mood.
I found an article about this subject, which is called “Testing the Untestable: Reliability in the 21st Century“.
Hi Again!
My past post on ‘apparently untestable systems‘ turned out to be a very cool experience. I talked with a lot of friends about it, and also had a very informative thread running on the comp.software.testing usenet group. The discussion was called “Is every single program testable? How do you deal with ‘untestable’ software?”
That thread was so helpful to further my understanding of testing, that I’ll put here a summary. It surely will make a good reference for me on the future, and I hope this will be useful for others too.
So, in order to continue and understand, read the ‘He Who Can Not Be Tested‘ post. All the discussion started from the questions in there:
- Do you think there are types of software which cannot be tested to a satisfactory degree?
- So how would you test software like this (of Dr. Parnas)? Or would you, as was his approach, just refuse to write and test it?
I’ll condense the responses here, and will add a note (and maybe a link) about each person. Note: The responses are edited and rearranged from the original replies, not really verbatim (although I changed the wording very little). (more…)
Well… No, you won’t get this prize either.
Read the previous BotT (about a bug in the lottery software) in order to be in the mood for this one.
This BotT tells a story. A story about a car dealership that had the great idea of mailing thousands of scratch-off games to promote their business. What they did not know is that, by mistake, all of the 50000 cards had a winning notice behind the scratch-off layer. Instead of having to pay a US$1.000 prize, they soon discovered that they had to pay US$50.000.000!!
Go to this link to read the story, or at least to see the videos of the angry customers that came to demand their US$1.000: Koat News link.
I am not pointing a finger at any culprit, it is clear that it was a big confusion. And although it is an interesting story, the point that I want to emphasize is: How do you test a system that can not be executed?
Welcome!
If you are an avid reader, and read the first post of this blog, you know that this blog is was password protected.
Since last week, the page is accessible to all, and may be read by everyone. As of now, no other page on the net links to Testing Thoughts, so it will be a calm place for a while. (more…)
Annotations from day 11/0702007 of the Sigist conference on Software Testing. (more…)
Annotations from day 10/0702007 of the Sigist conference on Software Testing. (more…)
In 1979 (yes, I am that young 
), Glenford J. Myers
Called “The Art of Software Testing
Well, it turns out the principles of software - from writing it to testing it - are still pretty much the same. Software is still written on sort of punchcards, the punchcards just got more complex and flexible… The book content is surprisingly relevant for today’s testers - so much, that it was updated only once in almost 30 years.
If you haven’t, read the book. Unfortunately, I have read it only partially meanwhile.
Maybe the most known contribution of Mr. Glenford in this book is the testing self-assessment challenge in the introduction.
On our BooT of this time, a silly and expensive bug.
Do you play lottery? Did you ever win?
No?? Well, maybe the reason of you not being yet a millionaire may be a nasty bug in your favorite lottery system…
Joel says that nothing improves morale and efficiency like private walled offices. I’ve worked in both way, and in two occasions companies I worked switched methods (from closed environments to open spaces) - in this experience, the gains of working on wall-less and open spaces are visible. Suddenly, everything is quick and everything is clear. No more leaving things to deal later. No more company-wide procrastination.
My advice: break those doors and those walls.
Everybody loves Joel.
Everybody loves his articles, his jokes and his books.
More than that, people love to disagree with him, so they can look smart and judgmental. The funniest part is seeing the judgmental faces they do.
In 2000, Joel wrote a cool article on “Top Five (Wrong) Reasons You Don’t Have Testers“.
He’s got some great information there, and in this post I’ll just comment it (see the ‘Annotations’ tag?).
Ok, so go on (link) and read the paper.
In his paper, Joel debunk 5 miths of companies who won’t hire testers: