Lisa Crispin shares some helpful tools she has come across in her software career. Although Lisa has written automated test code since the early '90s, in the past year she's collaborated more with coder and tester teammates to write maintainable, DRY, automated test code.
During my software career, I’ve spent a lot of time and effort learning new thinking and technical skills. I’ve encouraged my peers to do the same. The series that Janet Gregory and I wrote on Rails and makes heavy use of JavaScript. I’ve worked on Java-based web applications for the past fifteen years, and my experience testing JavaScript is not as extensive as I’d like. But, I’ve had to learn a lot of new skills in my career, so I have a few helpful tools in my toolbox.
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.
Thinking Skills
My passion is working together with a team to deliver the best-possible-quality software product. I’m not a team lead or manager. I’m “just” a tester. Nevertheless, I feel all of us can and should be leaders in our own way. I recently participated in a Problem-Solving Leadership course led by Esther Derby, Johanna Rothman, and Jerry Weinberg. I took this course on my own time, using my vacation time from work. It’s an investment in both my personal and professional growth. The experience has given me more confidence that I can collaborate with the rest of my team to experiment with more ways to “bake quality” into our product.
Though I depend on my more “formal” learning—attending conferences and classes, reading magazines and blog posts—to keep my skills relevant, it’s also important to take time for reflection and introspection. Just as our teams inspect and adapt our process, I try to look at my own practices to understand what has worked well and not so well.
I’ve realized that good relationships with teammates are key to my enjoyment of my work. This may sound like a small thing, but it isn’t. I’ve always brought my lunch to work and eaten at my desk to save time so I can go home earlier. But, that means that I’ve missed out on going to lunch with my teammates. Those lunches out may not be the healthiest thing for one’s body, but getting to know one’s coworkers is priceless. Besides that, when you work intensely all day—especially if you pair—it’s really helpful to get away from the office for a bit each day. So, now, I keep my ears tuned to “lunch talk” and join a group lunch at least a couple of days each week.
I enjoy writing, and I have had plenty of practice at it! Learning new things at a new job means taking boatloads of notes. In my experience, the person who can best teach a new team member is the previous “new person,” who has most recently learned all the same stuff. I’m putting my communication and organizational skills to work, enhancing existing documentation and writing additional notes that may be helpful to others. My teammates and I are experimenting with using a wiki to host a knowledge base instead of the existing documentation system.
I started my software career in a programmer trainee position where I had to learn on the job. I’ve seen the return of similar investments that I’ve made over the years, culminating in my latest rewarding job. I bet that you, as a reader of this website, are making similar investments. How have they paid off for you? How will you invest in your own future learning?
