The software industry is changing fast. More and more teams put testing up front and center; they use tests to drive development. New and improved automated test frameworks and drivers burst onto the scene every month. Teams with more automated regression suites need testers with sharp exploratory testing skills. But most people do not learn the needed skills in university: where will these testers come from?
At the same time, I find that some people are struggling to find good testing jobs. Testers often ask me how to ‘break in’ to agile development, or what they need to do to find a good job. If they don’t have programming experience, they’re concerned they aren’t technical enough to be hired on an agile team. My view is that while skills are important, attitude is everything. If you’re eager to learn, and willing to take on any activities needed to help the team deliver a good product, you have a bright future as a tester. My advice is to volunteer for every learning opportunity that comes your way, and work on your own to gain new skills.
I find many of us learn best from examples, so I’d like to share some stories from my own journey, to show you how well my drive to learn has translated into career growth. I hope it will give you ideas for your own professional growth.
Programmer, Tester, or Domain Expert?
Testers come from a wide variety of backgrounds. During the past ten years, as more programmers get interested in testing, I’ve met lots of programmers who now identify themselves more as testers. I also know lots of testers that come from the business side; their domain expertise makes them valuable on the development side. Technical writers, who must verify how the application behaves so they can document, often make awesome testers. Lots of us just fall into it by chance, as did I!
Let me tell you a bit about myself. I started my career as a programmer, and I enjoy coding. Test automation, essentially a programming activity, is one of my favorite jobs. Still, testing is my passion. I love learning about the business and finding ways that I can contribute to its success. Having a technical background lets me fit in well with the development team as well as with the business side. Here is the story of my own learning journey from my early programming days to working with agile teams.
Early Lessons in Testing
Like many people, I got into software development by accident. I landed a “programmer trainee” position at the University of Texas at Austin Data Processing Division.
I was trained by programmers who had themselves been trained on the job only weeks earlier. Remembering how they had just learned to program, they knew just how to teach it. Before long, I knew the basics of Easytrieve, Cobol and a 4GL, as well as a hierarchical database. We all coded exactly the same way, so it’s easy to work on each others’ programs. Looking back, it was collective code ownership at its finest!
After a few months of this on-the-job training, I was offered, and gladly accepted, the post of Education Coordinator, overseeing not only the programmer training, but training our end users. We held classes to teach academic faculty and staff how to do simple queries and reports themselves, a wildly successful effort that saved us programmers lots of work. I learned a lot in my allotted one-year term (during which I still did my normal programming duties) by figuring out good ways to teach others.
I was surprised to discover how much I learned from customers, as well as from the other programmers. We “programmer/analysts” sat down with the end users, talked about what they wanted, and prototyped it on the spot. We showed them each attempt until they had what they needed. I joined a team to prototype an online catalog for the library, sitting with librarians to learn how the card catalog system works. Learning about all the different domains was the most fun part of my job. We didn’t know anything about testing, but all the pairing with customers helped us get the software in good shape before we released it to production.
In this first programming/analyst job, I learned how to lead. My supervisor once told me that being a leader means making sure other people know about the contributions that my team has made. I learned how to lead by example. I remembered this with every subsequent job, learning good ways to let managers and others in the business know the value my team and I added.
Learning Through Transitions
A few years later I was working in technical support for a large software company, that at the time seemed unaware of the concept of testing or QA. My coworkers and I did a lot of testing in self-defense: it’s good to find the bugs in the software before the customers do. One day our supervisor asked, “Who wants to go to DB2 training?” None of us had any idea what DB2 was, but I volunteered. Soon, I was the team expert on SQL and DB2.
Seeing the benefits of our catching bugs before the customers did, the company created its first testing team. I volunteered for that, too. Since I knew SQL, I got to work on projects using Oracle and Sybase databases, which were growing much more popular in the world than our own database product.
In this new job, I started learning the art and science of testing. I attended a testing conference to learn more. We started experimenting with test automation. Our software worked on all operating systems, so I jumped at the chance to learn them all: VAX/VMS, Wang, OS2, AS400, and eight different Unix flavors. These didn’t all turn out to look good on a resume, but learning to maintain test environments on all of these was invaluable experience.
Our team was also responsible for packaging releases. I learned the importance of release notes and accurate documentation, how to manage alpha and beta testing, even how to cut release tapes. A lot of these activities were intimidating at first. Automating tests can still be scary to me, even now! But I was lucky to get the training I needed both from outside courses, self-guided tutorials, and helpful coworkers. I tried to take setbacks in stride, and kept looking for ways to master new skills.
With a wide range of experience in testing, automation, database, and operating systems, I had highly marketable skills. That really wasn’t my goal, starting out – I just liked learning new things! Whether it’s a technical skill or something about the business, I enjoy adventures into new territory. It sure paid off in this case. When the company started to struggle financially, I was able to find a great new opportunity.
Personal Relationships Create Opportunities
My new job was fun, and provided a chance to learn more new skills. For example, I became the team’s Powerbuilder expert. I was able to spend several months learning a test tool and building an automated GUI test suite. Best of all, some of my former coworkers also joined the new company. I learned what a small world we work in – a valuable lesson!
A few years later, during the Internet boom, and I joined a web startup. I didn’t know a thing about testing web applications, but as I’d been using various test automation tools for several years, I poked around on the Internet looking for a tool that works with web apps.
As I looked at a tool list website, the letters “OCLC” catch my eye. I learned all about OCLC when I worked on the online library catalog, because OCLC catalogs books and provides services to libraries everywhere. Strangely, they marketed a test tool called WebArt, which I decided to buy. Its developer, Tip House, came out to train us in testing web applications as well as automating tests.
Like many testers, I’m always wondering how we can do a better job of delivering the right software in a timely manner. The internet world is much faster-paced than the database product world, and I was frustrated by our slow, waterfall process. An opportunity to try a different approach soon arose. When our startup was bought by a big company, several of my programmer coworkers went off to start their own shop. They gave me a book called Extreme Programming Explained and say, “Hey, we are going to try this XP thing.” Once I read the book, I knew I had to try it, and begged them to take me on.
Joining my buddies on our first XP team, I struggled to learn what testers on XP teams are supposed to do, and reached out to the growing online agile community (though we didn’t call it “agile” yet). I was amazed how welcoming and helpful the XP gurus and other agile practitioners were. When Uncle Bob Martin came to give us a training course, he suggested I call Ward Cunningham for answers to my testing questions, and gave me his phone number. Ward talked to me for more than an hour! If I heard that someone such as Ron Jeffries or Kent Beck would be in town, or at a conference I was attending, I arranged to meet with them, and they were generous with their time. Brian Marick helped me start the agile-testing mailing list, where I got yet more help.
Contributing to the Community Creates Opportunities
When my team, and those that I met via conferences, user groups and mailing lists, found agile testing techniques that worked, I decided that other testers and teams shouldn’t have to reinvent the wheel. With encouragement from the XP community, Tip House and I wrote a book (Testing Extreme Programming). Lots of people helped with reviewing drafts and giving us ideas, including Janet Gregory. Janet and I started developing conference workshops and tutorials together.
Extreme Programming is all about the people, and so is career success. I leveraged my personal relationships and ended up as a presenter, coach and published author. Not only have I become a better tester, I’ve learned good ways to communicate. I get to go to conferences, learn from others, and present my ideas in workshops and tutorials. All because I wanted to learn, and took time to develop good working relationships with smart people.
I also learned the joy and value of giving back. My first XP team of mine joined with others to start a local XP user group. I present a talk at the very first meeting! I’ve met so many wonderful people and learned so much in ten years with this user group, and all it took was some of my time. I try hard to “pay forward” all the help I’ve gotten. I participate in my local user groups, volunteer to help organize conferences, moderate a testing mailing list, do “Lunch ‘N Learn” sessions with other companies, do free webinars and teleconferences with teams that have questions about testing and agile development. I find that the more I try to help other people, the more I learn myself. It’s kind of cool – helping out is its own reward.
It Never Stops: Broadening Horizons
I’ve been a software tester for many years now, but it never gets old for me. I truly learn something new every day: either a technical skill, or some fact about how our business operates. Collaborating with my teammates, and with colleagues I’ve met through user groups, conferences and even Twitter, I experiment with new open source tools and learn new scripting languages. It can be scary, but it’s rewarding.
For example, I struggled to learn Ruby, because I’d never mastered an object-oriented language. I worked through books and got help from coworkers, and was rewarded with scripts that freed up my time for more interesting testing. I’ve joined groups that work to improve test tool offerings, such as the Austin Workshop on Test Automation and the Agile Alliance Functional Test Tools committee. Not only does this make me aware of more tool alternatives, but also I meet plenty of helpful people.
Why Is This Important?
I hope it’s obvious to other testers reading this how much I enjoy what I do (though there are days when I get frustrated , wishing I had more skills than I do!). Friends from that early technical support job remark on how I can seemingly just get a new job easily, where they are stuck in jobs they don’t like. I’m not any smarter than they are: I spent time learning and taking advantage of new opportunities! A small investment of one’s own time in learning and participating in technical community activities pays back in career advancement.
Here’s what I want readers to take away from my own learning journey: Take responsibility for your own professional development. Don’t limit your learning to technical or testing skills, either. Gain expertise on your company’s business domain so you can better help them make good choices. Get out of your cube right now and see what you can do to help your team and your company work a little bit better. Join an online testing club, or volunteer to help with your local testing user group. Buy a new book or start working through an online tutorial. Do something today to get a little further on your learning journey. You’ll enjoy your job more, you’ll enjoy more fun opportunities, and you’ll make all of us proud to be your peer.
Here are just a few places for testers to learn:
- Collaboration Explained: Facilitation Skills for Software Project Leaders, Jean Tabaka, Addison-Wesley 2006. These skills will serve you even if you aren’t a ‘project leader’.
- Everyday Scripting with Ruby: For Teams, Testers and You, Brian Marick, Pragmatic Bookshelf, 2007
- “Writing Maintainable Automated Tests”, Dale Emery, 2009,
- Continuous Integration and Testing Conference
- “Google’s ’20 percent time’ in action”, Alex K.
- Exploratory testing articles and blog posts, Jonathan Kohl,
- Agile user groups
- Software Testing Club
- Weekend Testers
- Articles about agile testing
About the author
Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and a contributor to Beautiful Testing (O’Reilly, 2009). She has worked as a tester on agile teams for the past ten years, and enjoys sharing her experiences via writing, presenting and participating in agile testing communities around the world. For more about Lisa’s work, visit www.lisacrispin.com.