A few years back, I invested time to learn how to write test scripts in Ruby using Everyday Scripting with Ruby by Brian Marick as a guide, and I took advantage of help offered by a knowledgeable teammate. I didn’t know Rails going into this new job, but my Ruby knowledge has provided a good starting point. The code has a familiar look, and the Rails features I’ve learned about immediately made sense to me. Since I started my new job, a couple of my teammates have collaborated on Ruby scripts to help test the product’s API. My grounding in Ruby means I can get up to speed and use these scripts productively much faster than if I were starting from scratch.
Several years ago, I started maintaining automated test code in the same integrated development environment (IDE) as my programmer teammates. Thanks to that, I’ve had little trouble navigating in the IDE my new team uses, RubyMine. The ability to explore in both the production and test code is a big boost in learning about the product we’re developing.
My only exposure to GitHub has been through reading about it and participating in conference sessions that discuss it. Jeff Morgan did a lightning talk about GitHub at the Telerik Testing Summit last May. Afterward, he was kind enough to walk me through the basics of Git. This has helped me learn how to use Git for my new job much faster than if I had no prior exposure to it.
Back in the early ‘90s, when I worked for another software company, I volunteered to test our products in Unix operating systems. I was rewarded with a lot of good training in Unix. I’ve benefited ever since from the resulting competence in Unix shell scripting. One of my main activities in my new job is to test our product’s API. One way to do this is with cURL. I haven’t used cURL before but, thanks to my Unix experience, I could use a shell script to easily exercise cURL commands.
Naturally, I’m keen to work with my new teammates to develop additional test automation, both for regression testing and to assist with manual exploratory testing. I’m lazy, so I like anything that helps me avoid repetitive, tedious tasks. Though I’ve written automated test code since the early ‘90s, in the past year or so I’ve collaborated more with coder and tester teammates to write maintainable, DRY, automated test code. In this new job, I’m pairing with developers on my team to explore ways to speed up exploratory testing as well as provide regression testing.