Off the script: What I didn’t expect to learn from Ruby
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.