Skip to content

Off the script: What I didn’t expect to learn from Ruby

July 20, 2011

In turns out that writing code can help me as a tester as much as the code I write.

Over the past week or so, I have been working on my first ever (useful) Ruby script (and a few related scripts). It uses Selenium WebDriver and compares our product’s data export (CSV) with its data in the browser and Lotus Notes; there are over 500 fields captured in the export for 500+ records and we are frequently adding to and changing the fields. It seemed to make sense to have a tool that would let us quickly check for signs of problems each time such updates are made.

But this post isn’t about what I learned from the technology. Maybe another time. For now I am more interested in what it was like to play the role of programmer. I’ve seen behind the project management curtain a bit in the last year, and that was very eye-opening; it helped me see our projects from a different perspective and view the project manager’s role in a more sympathetic light. Doing the programming for this Ruby script, though not a major development project by most measures, has gifted me similar benefits with respect to the programmer role.

Some examples of what I experienced and what I learned:

Interruptions. I found that when I’m working on a difficult coding problem, it is not easy to take my head in and out of that problem. There can be a lot of assumptions and threads of logic that I hold in my mind at once until I come upon a solution; being asked to do something even as quick and simple as sign a form or answer an easy question while I’m in that state could turn out to be very disruptive. Answering the question “Now, where was I?” becomes an unexpected chore. Think of it as a high hurdle that you need to clear: If you have to stop halfway down the track to tie your shoes, you won’t be able to just get up and resume running; you’ll need to back up a bit and regain your momentum to get clearance.

Can this make me a better tester? Perhaps I can avoid untying the programmers’ shoes by learning to recognize when a sprint is on and using non-disruptive emails for requests and questions.

Completion. I found great joy in getting small parts of my code to do what I wanted it to do. This may have been because I am inexperienced and most tricks seemed brand new to me, but I suspect there is more to it than that. Completion, no matter the size, meant a lot to my confidence and momentum. I suspect that it is a phenomenon common to the creative process; it reminded me of completing a scene in a story or perfecting a stanza of a poem.

Can this make me a better tester? Perhaps when a programmer wants to show the team a piece of functionality they just got working I can join in the celebration rather than point out what else still needs to be done.

Requirements, design, loop. Designing a program is hard; a program has to solve a problem and provide value. If, in very general terms, the requirements are “what we need” and the design is “how we get what we need,” it’s no wonder that the two stay in a close relationship throughout development; and that is exactly what I found during my own script development. In my case, the needs of the testing team on this project drove the requirements while I stumbled through the design. The interactions in my head went something like this:

“The scripts needs to be able to do this.”
“Okay, then I’ll design it like this. But, you know… it would be quite a bit easier if I could design it like THIS instead. That’s going to mean that it can’t do this other thing.”
“Oh, alright… That’s fine, but if it can’t do that, then it needs to at least do THIS.”
“Awesome, that’s no problem.”
“Oh, hey… also, the script really needs to be able to handle this scenario.”
“Gotcha.  But, you know, if I design it like THIS, then we don’t even have to worry about that scenario…”
“Aha! Very good. Well, carry on…. talk to you in thirteen, fourteen seconds.”

Can this make me a better tester? Perhaps I can enter a project and embrace the idea of dynamic requirements that will be frequently revisited by the programmers for clarification and exploration of alternatives.

Configuration breakdown. Coding comes pretty easy for me; at least, it feels easy, because it’s fun. But dealing with architecture is hard. Setting up programs to work together, researching how to install this and fit it with that, shaving a few yaks… those activities wear me out quickly. And just think if I actually worked on a project with mild complication. (Burn.) All I found myself wanting to do was write the direct code to make something happen. Do other programmers go through this? Or is it like writing fiction? Some folks love getting in the weeds to write dialogue, rearrange clauses, and edit syntax (me); while others prefer to piece together scenes, tease out an emerging theme, and develop characters (not me). 

Can this make me a better tester? Perhaps I can get to know the programmers and what they find fun and not fun, and learn to anticipate what they will find a nauseating bug or requirement.

Copy/paste. I’ve heard warnings before of copying and pasting code. I get it now. It’s a little bit like bringing a picture from a magazine to a barber and saying “I want this haircut the next seven times I come in here. Do it exactly the same way every time. I mean, look at it! It’s a beautiful haircut. No, no… I don’t need to wait for the first cut to decide this. Do you not see how great it looks??”  My favorite mistake recently was when I pasted “mistmaches” throughout a method. Message received.

Can this make me a better tester? Perhaps I can understand why sometimes a bug happens “just because” by remembering how good a haircut can look before hitting Ctrl+C…


Taking advantage of a different role for awhile is great for new perspectives in your “daily” role; in this case,  I learned a bit more about what gets programmers excited, frustrated, and sidetracked. I should rephrase that: I learned a bit more about what gets a programmer like me excited, frustrated, and sidetracked.

I’ll add this: I’m looking forward to reading this post again in a few weeks, a few months, and a year, to see how much more my perspective changes as I continue to develop scripting skills.

Advertisements

Staring Down the Barrel of the Pen

July 11, 2011

I’ve had a series of blog posts brewing in my head for the last month or so. I think they could be really interesting (or at least unique), but I just haven’t had time to pursue them with the intensity I’d like to devote; lately I’ve taken the BBST Bug Advocacy course, have been preparing a brown bag to share said course with my coworkers, traveling for work, learning and practicing Ruby and Selenium, and, well, enjoying the summer (read: surviving the heat). The blog has just had to sit quietly and wait its turn for my attention over the last two months.

(You buying any of that malarkey?)

Me neither.

It’s easy to blame my lack of production on a lack of time, but there’s always time for the things you really want to do, and I really do want to write and I really do want to try these ideas. But I’m afraid.

(Ha!)

No, really. It’s the most honest explanation I can come up with. I’m afraid to sit down and start writing because I might get four lines in and realize it’s awful and that the whole concept won’t work. Or I might write the whole first post and decide it’s awful, then hear from readers that they agree.

Good ideas can be paralyzing. Like a countertop full of tempting ingredients, a good idea can make my mouth water while it’s still unformed in my mind, but I know there’s a chance that, when I put everything together and bake it, what comes out of the oven might taste like cat vomit. This is where folks will say things like, “You can’t succeed if you don’t try,” “Failure is the best way to learn,” or “Just write!” But how often are those glib sentiments actually motivating for writers (or any other person working on something creative)? How often do they actually address the legitimate fear of filling a blank page with garbage? How often do Homer Simpson’s words seem to ring much truer? “Trying is the first step towards failure.”

(D’oh.)

Ok, let’s regroup. Sometimes it helps to take baby steps. I’m not ready to try my special series of blog posts? Then I’ll write a post about why that might be. Next time, another toddle: Perhaps a post about seeing a project through a programmer’s eyes.

(After that?)

Hey. What did I just say about baby steps?

Referees, testers, and bias

May 15, 2011

There’s one day until the scheduled release day of Make-Or-Break (MOB) software. You’ve been working long hours testing MOB, to the point that it visits you in your dreams (where everything is broken and the developers are all on vacation). You keep pushing yourself though, because you haven’t hit that warm, fuzzy “Let’s ship it!” feeling. (Or as I like to think of it, the point where you’re willing to “Put your name on it!“) You’re testing the print functionality of MOB, a piece that everyone on the product team has been lauding as well-tested and successful.

But something doesn’t seem right here.

For a brief moment you think you might have a bug to investigate, but no… it’s fine. We’ve tested this piece already. We’re shipping tomorrow. You didn’t really see anything. You move on.


I’ve been reading a lovely little book called Scorecasting. (I recommend it to anyone interested sports, statistics, or just the interesting factors that influence people. Or anyone ready for a good argument, because I’ve found a few of the chapters to be flawed in their approaches.) There is a great chapter that examines the influences behind home field advantage, and it basically uses statistics to boil away things like travel and crowd influence on players, and settles mainly on referee bias as the primary factor. (I imagine Mark Cuban has this chapter printed out and framed in his office with the authors’ autographs.) The authors then discuss some of the psychology behind the referee bias; they suggest that they aren’t biased out of any kind of conscious favoritism, but:

In trying to make the right call, they are conforming to a larger group’s opinion, swayed by tens of thousands of people witnessing the exact same play they did.

In addition, there is the possibility that the referees are swayed by a suggestion from the league that when the home team wins, that organization makes more money in sales, and it’s therefore better for the league. That seems like a bit of a stretch, I know, but then they put it in terms that any one of us can understand:

If your boss sent a subtle but unmistakable message that Outcome A was preferable to Outcome B, when you were forced to make a difficult, uncertain, and quick decision, how would you be inclined to act?


In this light, it sounds like you missed that print functionality bug in MOB because of home team bias. The crowd thought the product worked. Your bosses wanted the product shipped. Bias — not a conscious decision — in the heat of the moment led you to make what seems like a bad decision to an impartial (and less pressured) observer.

My point — if I have one other than sharing a snippet of Scorecasting — is that bias is real and it is not limited to software testers. Even folks paid to be completely impartial imposers of rules like referees are subject to bias’s skewed grasps. The question is how do we limit bias? In sports, it will remain mostly fact; there will always be paying fans attending sporting events, and influencing referee calls in various, often indirect, ways.

It seems that once you are exposed to factors that cause bias, there’s no avoiding it completely. If you’ve been on the product team for MOB and have been hearing about the schedule and praise for the print functionality, you can’t unhear those things and shed the bias they spawned. But you can be aware of it and talk about it. Maybe you shouldn’t test that piece; find someone on another project. Maybe you should discuss your concerns with the team instead of testing it alone. And, maybe, if the bugs gets to production, you just have to explain the bias that contributed to the miss.

For now, all this talk of bias is making me hungry for sports. And, oh look, Game 7 of Thunder vs. Grizzlies is on…

Dipping my toes in the pool

May 12, 2011

Is the water warm? Cool? Hot? Intensely, bitterly cold? I’m about to dip my toes in this pool and answer these questions, but what do I already know before I do that?

I don’t see any steam rising up from the water. I don’t see any ice forming over the surface. I also don’t see a temperature gauge on the pool. But I do see some other people already mostly submerged in the pool water. They’re all wearing regular swimsuits, no wetsuits or other temperature-sensitive apparel. Nobody appears to be shivering, and I hear no teeth chattering. Everyone appears to be active, as well, playing with no sluggishness, no flush faces.

But they’re on the other side of the pool. What about right in front of me here? Am I about to step into a heated cove? (A hot pocket, if you must?) I don’t see any unusual water streams beneath the surface, at least that I can see from here at the edge of the pool, nor any divisions or ridges in the pool floor; the water seems calm and uniform.

Combining all of these observations with my previous experiences in, and what I’ve read and been told about, pools and other bodies of water, I have a pretty good idea of what the water is going to feel like when I dip my toes in the pool.

But, wait–why did I go through this exercise just now? I could have immediately dipped my toes in the pool and answered my questions right away. Perhaps that action would have been off script? Was there a lack of confidence? Did it seem too obvious?  In making those other observations, was I metaphorically dipping my toes in the water before I metaphorically dipped my toes in the water as a part of this greater metaphor I’m working out here about both software testing and starting a blog? (I think that was a meta metaphor there. But let’s move on.)

Turns out, there’s a sign next to the pool that says “$15 to enter pool. Includes dipping toes!” and a clipboard in my hand with a form titled “Effects of intensely, bitterly cold pools on the human body.” I just saved myself 15 metaphorical dollars. Thanks, context.