Some updates and promises for posts-to-come

Been away for a while - funny thing of broken habbits: our wireless router broke down, and I didn't manage to fix it (or get myself to get a new one), so I stopped connecting to the internet with my laptop when I am home. Immediate result: lost my home-internet habbits. Call it vacation. (BTW, I write this post from the kids PC).

Things that I need to update about in posts-to-come:

1. ISTQB self study group: certification exam is next week (July 10th). I feel ready, and got things to say about the ISTQB sylabus.
2. Ruby: had some progress (thanks for the reference to Aptana studio Rich!), need to share something I don't get in Ruby, as well as rcov - a nice (too?) simple code coverage tool.
3. SIGIST conference: been to the Israeli Special Interest Group In Software Testing (SIGIST) conference. I gave a presentation about how to extract test cases from UML.
4. Mind maps: I am hooked up on mind maps, using them as my new external brain and memory. Is this a passing thing?

Cool things in Ruby

I have been using Ruby for quite some time now, but only now I begin to see what I missed...

It started when we began using WATIR for shooting HTTP transactions to test our application. WATIR is based on Ruby, activating Internet Explorer's COM object - I recommend it for quick useful scripting.

What caught my attention was the Ruby under WATIR - the scripts were easy to write, readable, and contained clever "tricks" that saved a lot of scripting time (I'll give examples later).

Well, as they say: "I came for WATIR and stayed for Ruby".


cc Tom Goskar

Ruby is a cute scripting language that gives a much nicer feeling from a usability perspective than perl. For starters, it is OO. It is very flexible in regard to syntax. It is rich with functionality and extensibility options.

Don't worry, there are down sides too (remember that I am only starting to understand Ruby, so there is a high chance I am BSing here). For example, I still do not have a convenient working environment for scripting and debugging. The editor that comes packed with Ruby for Windows (SciTE) colors keywords and lets you run the script from the editor, and the interactive Ruby command line (irb) is a nice option that let's you script and run interactively, but this is not enough for me - I am used to the rich coding experience of Eclipse, so what I did now is to install the Ruby plug-in for Eclipse, and I'll update later about how convenient it is.

Well, I want to give a few examples for why I like Ruby and why it is cool.

I like Ruby's arrays. They come with many services built in as methods and let you use the array as stack or queue with no effort. Also, you can add arrays, subtract them, keep only unique elements, sort, etc. - ultra convenient.
myArray = [1,2,3,4,5]
myOtherArray = [2,4]
myDiffArray = myArray - myOtherArray # result will be [1,3,5]

I also like Ruby's built-in iterators, allowing you to split anything (more or less) into pieces and operate on each piece until you do them all:
myArray = [1,2,3,4,5]
myArray.each do |element| # element isa variable that gets each array element by turn
puts element # puts prints to the console
end

Another thing I like about Ruby is its rich core library and even richer extensions collection, covering (probably) everything I need. As in other user contributed libraries, the quality and completeness is not guaranteed and you are required to work hard to differentiate the good things from the bad.

I just started climbing the learning curve here, so I'll update later on things I find.

If you want to see Ruby in action in a few minutes, do the Ruby in 20 minutes tutorial.

Back from family trip to the USA

Back from a ten days tour of New York City and Orlando - now I understand why some say that Disney World is a "once in a life-time" experience - it will take me a long time to recover from the masses of people and the long lines.

But enough crying, got a bug and a feature to share.

Bug:
See if you can spot the bug in this postcard (click to enlarge):


Feature:
The ride I enjoyed most in Disney World was Epcot's "Test Track". It is simulating a General Motors test department, with loads of displays telling the story of automotive testing industry, and its silent heroes - the crash-test dummies. Among the things I enjoyed to see were test result cards, formatted as you would expect with test ID, test scenario, expected result, actual result, passed/failed, etc. - the entire story! I felt at home.



When you get to the actual ride, you sit in a car and participate in a test session directed by a test manager and a test engineer, that take you and the car through a series of challenges, including steep hills, extreme weather, emergency braking (with and without ABS) and extreme speed drive around the facility.

What more can a tester want? (hint: not to find real bugs in the ride :-#)

"Error Guessing" as a software testing method

I admit that good testers can guess where bugs will be found (or at least say "I told you!" after they find them). BUT, I don't like seeing "Error Guessing" listed as a test technique in software testing books. If it can't be taught, it is not a technique (IMHO).

Look at ISTQB glossary definition (pdf!):
error guessing: A test design technique where the experience of the tester is used to
anticipate what defects might be present in the component or system under test as a result
of errors made, and to design tests specifically to expose them.

So, the tester should apply the old intuition to draw on her past and guess where the errors will hit this time. This sounds trivial on the one hand (learning from experience should be a basic human feature), but also very vague: suppose I have a tester with zero experience - can I teach her to guess errors? If I have 2 testers with the same experience - will they guess the same errors?

So, what can be done to improve your error guessing techniques?

• Improve your memory:
• List interesting error-types you come across
• Use existing bugs lists (I like the huge one provided as an appendix in Testing Computer Software, 2nd Edition)
  
• Improve your technical understanding:
• Go into the code, see how things are implemented, understand concepts like buffer overflow, null pointer assignment, array index boundaries, iterators, etc.
  
• Learn about the technical context in which the software is running, special conditions in your OS, DB or web server.
  
• Remember to look for errors not only in the code
• Errors in requirements
• Errors in design
• Errors in coding
• Errors in build
  
• Errors in testing (we never make mistakes, do we?)
  
• Errors in usage

An error-guessing story (wake up ego!):
A new team member was asked to plan tests for a web application screen that displayed items in batches of 25. I reviewed his test cases and asked him to add a test to search for missing items, or duplicated items around the "stitch" between the batches. After executing the tests, he came to me, saying that indeed the last item in each batch was duplicated, and appeared again as the first item in the next batch. He looked at me with awe and said "how did you know that this will happen?" I knew, because this is exactly what I missed when testing a paged-list a few years back - a customer found it for me... (Ego, back to sleep).


(CC)

ISTQB self-study group

We started an ISTQB self-study group at work last week. We got around 18 people on the interested-leads list, I expect the actual number will be much lower.

The idea is to use this book "Foundations of Software Testing: ISTQB Certification" as a study guide, meeting once a week to discuss current sections/chapters.

I read the first 3 sections, which cover the basic questions "what is testing" and "why testing is necessary". I felt the book was oversimplified and naive. To give you an example, the authors tend to go into lengthy analogs that bring little value (for example, comparing software product to a tomato in order to discuss definitions of "quality".

On the other hand, I think that for beginners it may do the trick, and serve as a clear introduction to software testing. I will write more as we progress.

bug/feature: dusty BSOD, Many Eyes

Bug:
Lengthy and detailed report of analyzing a Blue Screen Of Death situation, ends up with cleaning dust off the CPU fan and radiator, and presto! BSOD is gone.
Memo to myself - try it on my laptop (got a couple of BSODs last week).

Feature:
Many Eyes is a wonderful site that let's you upload data to share with others and use visual analysis in order to study your data and bring out points about it to the world in a persuasive way. You can also play around with data provided by others, to see what you can extract from it.
The collaborative nature of this site allows users to discuss the data itself, and the statistical inferences made by data users.

Innovative data visualization tools are a must in this age of accelerating data accumulation. The best example I saw Hans Rosling presentation in TED - I suggest to invest 20 minutes in this entertaining and genius presentation. Done? Go play with data in Gapminder website.

Amazing art/tech: animatic sculptures

Go see this genius in action, building impossible animal-like sculptures.
So we got animatic inputs from military-industry (see post) and art.