Author: Christopher Gaspard, Quality Control Analyst
So I was busy doing some of the old click/look-click/look, like you do when you’re a Quality Control Technician, when I was told that the guy in charge of scripting our automated website testing, let’s call him Meich, had put in his notice to move closer to his family.
“I guess I have two weeks to learn everything Meich knows about automated testing,” I said, which was absolutely the correct response considering that this had already been decided on my behalf.
So I spent the next several days with Meich learning how he used Selenium IDE. In short, Selenium IDE allows you to record all of the clickings and typings you do on a website so that you can play them back later, right there in the browser. You play back the recording, and if the recorded actions produce the expected results, congratulations, it ain’t broke! If your results are unexpected, then something on your site has changed and an investigation is suddenly pending. This is excellent regression testing. Press the record button, click all the links, type in all the fields, push all the buttons, and rare is the change you won’t find when you run that test after the next push to production.
However, I found some limitations pretty quickly. I was trying to build a test for a site that had a drop-down menu. All of my clicks were recorded, but when I played back the test, it kept skipping the part where I had hovered over the menu title to get the list to appear. One of the nice things about Selenium IDE is that you can manually tweak the script it puts together by inserting additional actions. The downside is that it’s a limited set of actions from which you get to choose. It’s a long list, but it is definitely finite. That finite list, it turns out, did not have an action that would accomplish what I was trying to accomplish. I don’t take “you can’t do that” for an answer very well. What I could do, though, was export the whole test into a script written in the programming language of my choice. I chose Ruby.
I chose Ruby because I’ve always wanted to learn Ruby! I tried to teach myself Ruby years ago. It reminds me of when I first tried to teach myself to play guitar.
Did I tell you about the time I first tried to teach myself to play guitar?
I was 12 years old and found an old guitar in my grandmother’s garage. With explicit permission, I began to make noise after terrible noise. Unsatisfied, which is my natural state, I sought to learn how to tame these six wild strings. I got the Mel Bay Book of Chords. I learned chords. I learned A and C, G and D, the almighty E and the twisted, evil F. There are pages and pages of chords in that book I still haven’t even seen, but the major chords, I had those down.
“OK,” I said to myself, “now what?”
I had hit a wall. I had all of these pieces, and no idea what order to put them in. I didn’t have an application with which to apply the things I’d learned. The same thing happened the first time I tried to learn Ruby. But I’ve got an application now, oh boy: I’ve got automated testing!
Ruby is amazing. I’m like a kid in a dang candy store. Selenium lets me interact with the website through a browser, and Ruby lets me tell it exactly how to do exactly what. I’ve been writing tests in Ruby for over six months now, two months more than six to be exact, and the only thing that’s gotten in my way while trying to figure out new ways to test website functionality is my own imagination. And I have plans for a three-story Velcro/trampoline room when I get around to building my dream house, so…
Ultimately, I was able to get Selenium to find the links hidden in the drop-down on that first site, and that was just the beginning. Ask me sometime, and I’ll tell you about how you can talk a database into incriminating itself, how to bang all the forms on a site against a wall to see if they can take it, or how to make sure labels on a map page aren’t so close together that they overlap.
And the trampoline room! Ask me about that, too.