Ruby at Work - Internet access through a Proxy Server

While reviewing Brian Marick's book "Scripting for Testers" (due out later this year or early next), I discovered that some of the internet access RUBY commands and scripts always failed when I tried them from work. Here's the weird thing - the same commands and scripts worked from my home computer. So what gives?

I found the answer when I googled comp.lang.ruby and tinkered around in IRB from my work computer. It turned out to be the Proxy Server at work. For lack of a better place to store this nugget of knowledge, this seems like a good place for now.

THE PROBLEM:

Open a command prompt on a Windows machine, and launch IRB. Issue the following commands:
----
irb(main):001:0> require 'open-uri'
=> true
irb(main):002:0> url = 'http://www.amazon.com/gp/product/0974514055'
=> "http://www.amazon.com/gp/product/0974514055"
irb(main):003:0> page = open(url)
Errno::EBADF: Bad file descriptor - connect(2)
from c:/ruby/lib/ruby/1.8/net/http.rb:562:in `initialize'
from c:/ruby/lib/ruby/1.8/net/http.rb:562:in `connect'
from c:/ruby/lib/ruby/1.8/timeout.rb:48:in `timeout'
from c:/ruby/lib/ruby/1.8/timeout.rb:76:in `timeout'
from c:/ruby/lib/ruby/1.8/net/http.rb:562:in `connect'
from c:/ruby/lib/ruby/1.8/net/http.rb:555:in `do_start'
from c:/ruby/lib/ruby/1.8/net/http.rb:544:in `start'
from c:/ruby/lib/ruby/1.8/open-uri.rb:245:in `open_http'
from c:/ruby/lib/ruby/1.8/open-uri.rb:629:in `buffer_open'
from c:/ruby/lib/ruby/1.8/open-uri.rb:167:in `open_loop'
from c:/ruby/lib/ruby/1.8/open-uri.rb:165:in `open_loop'
from c:/ruby/lib/ruby/1.8/open-uri.rb:135:in `open_uri'
from c:/ruby/lib/ruby/1.8/open-uri.rb:531:in `open'
from c:/ruby/lib/ruby/1.8/open-uri.rb:86:in `open'
from (irb):3
----

THE SOLUTION:

You need to add the Proxy Server address (and user & password, if required) to the URL you are trying to access. Here's an example of something that worked for me from my work machine (replacing the relevant proxy address as required, of course):
----
require 'net/http'
host = 'www.amazon.com'
path = '/gp/product/0974514055'

proxy_addr = 'your.proxy.host'
proxy_port = 8080

response = Net::HTTP::Proxy(proxy_addr, proxy_port).get_response(host,
path)
----

=> response.body now returns the page source, just like it does from my home computer. (Response '200')

The second problem I had accessing a remote page was fixed with the following:
----
require 'open-uri'
url = 'http://www.amazon.com/gp/product/0974514055'

proxy_addr = 'http://your.proxy.host:'
proxy_port = 8080

page = open(url, :proxy => (proxy_addr + proxy_port.to_s))

text = page.read; nil
----

Note that the proxy_addr is slightly different here than with the 'net/http' commands above. (You could probably put it all in one variable here.)

If your Proxy server requires Username and Password, then the open command will be longer. (Luckily I don't need to enter that here at my work.)

I don't have any RUBY scripts that do this sort of thing yet, but I was happy to figure out the solution anyway. Nice change of pace. Ruby totally rocks. I have yet to find something that I can't do with it for testing automation.

Read More

"The Effects"

Patterns are funny things. Sometimes it is so easy to jump to silly conclusions because we notice the obvious even if we know there might be valid explanations for them.

Take for example patterns of behaviour. Here are a few things that I see on a regular basis:

• The Developer Effect - The software application always works as expected on a Developer's computer.
• The IT Effect - Any weird or unexpected computer behaviour (e.g. unable to print) will suddenly start to work correctly when you call an IT Helpdesk person over and they are looking over your shoulder as you retry the steps.
• The QA Effect - Any normally working system will suddenly stop working as expected when a Tester starts to look at something.
  

The "QA Effect" was my most recent addition to this list. A programmer sent me a link to a web site today and when I followed the link from the email message a new browser window appeared with the message: "We're sorry - an error has occurred. It has been logged and will be attended to shortly."

Ha ha. Is that Murphy's Law, or what?

I wonder how many other "Effects" there are in this industry? Write back a Comment to this Blog entry to let me know if you've come across any other immediate patterns. I'd be very interested to hear them.

Cheers!

Read More

I Know What I'm Doing!

This will sound weird but I had a strange realisation the other day. I thought to myself: "I know what I'm doing!"

Okay, this didn't just come up out of the blue and I wasn't practicing some sort of confidence-building exercise. It all started when I happened to notice a bug in the software I was testing and I decided not to report it.

What?! But you're a tester, man! Report the bugs you find!

Ah, well, yes, I plan to. But you see, I was busy at that particular moment thinking about something else, and I didn't want to distract myself by following up on a different thread that might make me lose my train of thought. To justify not reporting it I had to reflect for a moment as to how likely it would be that I would find the bug again. I had absolute confidence that I would find the bug again, so I simply forgot about it and went back to what I was working on.

I think it was later that night that the event started to settle in my mind and it started to make synapse connections with other memories in my brain. One particular memory came to me from my teenage years, some 20 years ago.

I recall one time when I was at a party and was talking to some of my older sister's friends. Coincidentally enough I think the topic of conversation was (creepy, crawly) bugs. There was this one guy who said that he was playing a video game in his home when he saw a millipede scurry across the floor. He said that his reaction was to pause for a moment, smile, and then keep playing his game. Someone asked him why he didn't just drop what he was doing and catch the icky bug right away?

His reply? He said that he knew those bugs and that he would easily find it later and take care of it then. He wasn't worried, so he didn't let it interrupt his game since there was no pressing need to take care of it right away.

I remembered that story for a long time and I always thought that if I ever saw an undesired bug I would simply take care of it then and there. Too many variables in life to let opportunities pass you by.

And so I have. For many years, I have always taken care of the bugs that I've found right away - both the creepy crawly kind, and the software kind.

So then, what happened this time? Why did I let a software bug go and not report it right away?

I realised that I was absolutely confident that I would find that bug again, and since there was no immediate need to take care of it, I let it go for the time being.

Sure enough, I got around to testing that particular area of the application and I had the opportunity to properly focus on the bug and report it with sufficient detail (it was a tricky one). I felt really great about it too.

When you do Exploratory Testing you are faced with the reality that none of your tests are pre-scripted. Exploratory Testing is kind of like what improvisation is to acting: there's no script. It certainly doesn't mean that the Improv people don't know how to act. In fact, it's quite the opposite. They are very talented actors. They just happen to know how to react to the circumstances that arise and can adapt to it with style.

I must confess that I've still been a bit nervous about Exploratory Testing. It doesn't help that I am bombarded with doubt by every other tester in the profession still doing it the traditional way: What if you miss something? How can you be sure of coverage? How do you know when to stop testing? and so on.

Well, I now *know* that I know what I'm doing. If I can totally forget about a bug and then stumble upon it again at a later date, then there must be something to this "improvisation" stuff after all.

Read More

Do you feel like the Stanford Bear?

I was asked just now if I felt like the Stanford Bear. I had to laugh, because sometimes I do.

What's the Stanford Bear, you ask? That's a good question. I'll tell you what I know..

I heard a story recently of an introductory computer class at Stanford University where the Teaching Assistants were so tired of answering the same questions over and over again that they programmed a machine to answer all the commonly asked questions. They added voice-recognition software to it and packaged it up nicely in a large teddy bear that sat on a shelf at one end of the class. Now, when a student had a problem or question, the TA's wouldn't help the student unless they knew that they had gone to the bear first. This relieved much of the workload from the TA's so that they could focus on the problems that really required their attention.

I'll admit that I don't know how much truth there is in this story. I spent some time scanning the internet and I couldn't find any pages to corroborate the tale. I'd like to think that it's true though.

True or not, it got me to wondering as to whether or not you could program something to give out canned answers on Software Testing to commonly asked questions.

I don't think that you could do it so that it would recognise every possible context and provide you with an appropriate response for every situation. (While a cool idea, let's be realistic here!) However, within a particular context - say revolving around the particular testing procedures for a particular class or industry, I'd think this might be do-able.

Better yet, I think it might be cool to program a Testing Bear that's hooked up to a central database somewhere. That way, people could program the Bear to answer all the common questions within their context, but then people all over the world would have access to the same questions and answers.

Now that might be something! Hmm.

Read More

Software Testing is more like Fencing

I got into a discussion with my colleague at work the other day about Martial Arts and Fencing. He asked me if they were similar and I said that based on my experiences with both that I didn't think so.

Martial Arts is about the harmony between mind and body. Different Martial Arts stress different skills and techniques but there is always the spiritual side, and with your mind focussed and at peace you can do almost anything. I remember some of my first Kung Fu lessons as a teenager when I was taught that my first reaction to a fight situation should always be to find a quick way out of it. Fighting should only be the last resort.

Fencing, on the other hand, is like both a Science and an Art. I remember learning the blocks (the "parries"), the lunges, and all the other technical maneuvers, but I also remember that when I was in an actual duel my mind almost forgot everything and I went with my instincts. You see, an actual duel is *much* faster than you can imagine. You almost don't have time to think or you're toast. With lots and lots of practice the technical moves become part of your instincts and then you become better at fencing.

So what about Software Testing? Despite the fact that some people amicably refer to it as a Martial Art, I don't see the spiritual side of it. When I see a bad application my first reaction isn't to run away. ;-) I dive in and go with my instincts. And project schedules are almost always faster than you'd like them to be.

With lots and lots of practice, my testing techniques have become part of my gut reaction now, so I usually make my own luck when it comes to dealing with bad programs.

Perhaps Quality Assurance is more like Martial Arts. You need a belief system to keep you motivated when you do *real* QA. You need to believe that you can eliminate the defects, the inefficiencies and the variances from the development process by applying certain methods and models.

I don't believe that. Not for a moment. We could stand here and talk about how we're going to do something or we could just do it and tweak things as we go along. Me? Let's dive in and do the best we can because time is running out. =)

En garde!

Read More

A bit about Software Testing Certifications

Recently I was asked about my "certification". Here, more or less, is the response that I gave. I thought I'd note it here in case I was asked again.

Back in June 2002 I received my certification through the American Society for Quality (ASQ) as a "Software Quality Engineer". While I may use the term "Certified Software Quality Engineer" in the US, due to Canadian laws, I may only refer to myself as an ASQ-CSQE here in Canada.

Here is a link where you can find out more information about this certification: http://www.asq.org/certification/software-quality-engineer/

Of particular interest to you may be the Requirements for this certification and the Body of Knowledge covered by it. (FYI: Note that "Software Testing" is merely a subset of section "VI - Software Verification and Validation" to the "QA" folk. Many people use "QA" and "Testing" interchangeably, but to me they are quite different.)

This ASQ certification covers many different aspects of Software Quality throughout a Software organisation (i.e. from defining Quality in the Business Goals, through to the Engineering methods, Requirements, Development, Testing, and Configuration Management). The exam itself was interesting in that many of the questions were designed in such a way as to demonstrate application of knowledge. (So people without experience who can memorise well may not pass the exam.) I spent about 4 years preparing for the ASQ exam by applying the principles, techniques and advice from the reading list materials into my regular work duties.

Why did I get this certification? It was applicable to what I was doing at the time.

Over the last few years I have changed my focus from Quality Assurance to Software Testing.

Most of my energy is currently on the Software Testing profession and I am an active member of the Association for Software Testing (AST). You can find out more about the AST at their web site: http://www.associationforsoftwaretesting.com/

I find it interesting that my ASQ involvement has provided me with a good knowledge of Quality-related issues that are, in general, quite difficult and complex to apply and manage on a day-to-day basis in a Software organisation. By contrast, the AST aims to provide us with the knowledge and support we need to be effective Software Testing practitioners. (i.e. the former is laden with bureaucracy and paperwork while the latter aims to make us useful employees.)

There are several Software Testing certifications available to the public, but none of them are particularly meaningful right now. The AST does not yet have any certification program, but we have discussed the development of a certification that would be based on demonstration of skill and not just one's ability to memorise the terms and definitions from an assigned reading list (which is what all of the current Testing certifications are based upon).

In the past, when I have interviewed candidates for Tester positions, I have used "Testing certifications" as an indicator that someone has more than a passing interest in this profession. Unfortunately, I can confirm to you that the certification itself has absolutely *no correlation* to testing ability whatsoever.

Too bad.

Read More

Team Leads need to be Potion Masters

Okay, maybe it's because I just read the latest Harry Potter book, but in discussing Test Team leadership recently with someone, I used this as an analogy.

I'm always surprised to meet people who think that the stages of team development (i.e. "Forming, Storming, Norming, and Performing") are some kind of kiddie joke or else they may not have heard of them at all. That's too bad. I believe that anyone who's serious about team leadership/management should take these stages very seriously.

If you are not prepared to recognise the moments when your team members start to pick each other apart or are challenging and questioning everything you do (in a bad way), then your team will never grow into a constructive, cohesive whole. As a team lead, you need to detect the poisons and provide the antidotes.

Most importantly of all, if you at least notice the poisons, but if you don't know what to do then ASK FOR HELP!! I'm tired of meeting people with EGOs so large that it prevents them from asking for help from others. ("Pride" is one of the Seven Deadly Sins, isn't it?) If you had seen someone fall but didn't know what to do you would call an emergency number (like "911"), wouldn't you? After all, that would be the right thing to do.

So why is it different when it comes to team management? If you notice that your team is falling apart and you don't know what to do to make it better, ask for help.

The biggest problem that I've noticed in this industry is not the managers who don't ask for help though - it's the managers who don't even notice that there's a problem. I've seen many teams just completely fall apart because the team members picked each other apart by getting on each others' nerves right in front of an oblivious team lead/manager.

Perhaps there's only a certain type of person who makes a good manager. Perhaps there's something in the MBTI that correlates with the traits of a good leader or manager. Perhaps I'll have a chance to look into this some more in the near future. Something to think about.

Read More