One of my first concerns when I got into testing was moving from a junior, the lowest person in the organizational chart, up to a lead. Leads always seemed so cool to me. They were respected, people came to them with important questions, they had responsibility for their own work as well as the work of other people on the test team, and, well, leads made more money, too. I wanted all of that.
The problem was—and this exists for all members of technical teams—there is no clear way to get there. When I talked with managers about my aspirations, most would say, “You need to be doing the job for a while, and then you’ll get the title.”
Most testers I know want career advice on what to do next and how to get there. Some see the next step in automation; others, in moving up the organizational chart. I want to talk about what a lead or test architect role looks like in my experience, and what people can do to chart a course to get there.
Get TestRail FREE for 30 days!
Moving through the ranks requires more than testing skill, but I think it is important to start there. Most testers won’t go very far without at least being competent. I started working in software during the dark ages of testing, in the early 2000s. Testing was thought of as following a series of steps, and not much more. The bar for people to see someone as a competent tester was pretty low.
I found a niche on my team, and on the development team, by being mildly technical. Instead of stopping to grab a developer when a button click didn’t do anything, I’d open the browser developer tools and log into the server via SSH to look at the application logs. After a few weeks of trying, I managed to butt my way into code review meetings. This got me familiar with how features were developed and what the unit test coverage looked like, and I learned about why developers tend to make certain types of mistakes.
Over the course of a year or so, this strategy significantly improved my ability to read and understand what was going on in a block of code, and it also built a lot of credibility with developers. It was easy to be a standout then because most testers were pretty restricted in what they did on a daily basis. Today, this would look a little different.
Software teams I work with today are either moving toward being highly collaborative or already there. One company I worked with recently was doing Extreme Programming (XP). Not all, but most code changes are worked on by two developers and a tester—not through handoffs, but all working on the change at the same time. The developers trade control of who is writing the code (driving) and who is helping to improve that code (navigating). The tester’s role in this triple is to ask questions that guide code design and test design and to build automation when appropriate. When the triple agrees that a bit of code is done and that change has been demoed, it is ready to ship to production.
The criteria for being thought of as a skilled tester in this sort of environment is different from my first experiences. Testers who are pairing with a developer or working in a triple are expected to help discover quality information much earlier in the development process—ideally, while the code is being written. These testers can shape strategy by understanding when and where it is appropriate to use automation and how that coverage shapes testing done once the product is usable in a browser.
Still, you have to assess the context you work in and provide a service that is useful to the development team. There are plenty of skilled testers who never move into a leadership role. You also need to be able to influence people around you in a positive way.
Before we talk about the road to becoming a test lead, we have to talk for a minute about what it means to be a leader. The easiest way to think about it is to look around and see if anyone is following. This is also a little dismissive, and not what most people are looking for when they ask about being a lead. This scope of the role will vary from company to company, of course, but let’s talk in generalities for a minute.
Managers have power through their title and role. When someone is a manager, that means an entire organization is granting them the power to make important decisions about who works on which project, about who should be hired, about who should be fired. For the most part, we don’t question this authority. Everyone on a team agrees that the person with the ‘manager’ title has more say-so than the next person without that title.
My favorite experience working as a test lead had a sort of trendsetter feel. I was hired as a senior tester at a local startup with the understanding that I would help shape their testing strategy. I wasn’t a lead in title, and I had never been one before at this point in my career.
After about a month at this company, I had some ideas about what I liked and what I didn’t like about the way they approached testing and quality. We were a pretty lean and flat organization, so I could do new things without permission and without anyone complaining too much. So I’d do a little less documentation, work with developers to learn the build and deploy system so that we could get new code more often, and test before the UI was ready, sometimes pairing with developers to make a shorter feedback loop. Eventually, a couple of questions came from my teammates: How did you find that bug, or, how do you finish testing so fast? I’d show them how I approached the problem and offer to teach them what I was doing.
Seeing something different made people interested in what I was doing. My being open and willing to take some time to talk about it made them comfortable.
Eventually, my title became lead software tester. My road there was paved with experimenting with my own process and then being open about what worked and what went terribly with anyone who was interested enough to ask. Of course, this won’t work for everyone. Some people only want to hear success stories, and that’s fine; you don’t have to lead everyone. Your own leadership approach, whatever that may be, will work great for some people and not at all for others.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
If you are just starting out and have some ambition, what you want to do tomorrow is focus on developing deep skills, both technical and interpersonal. You don’t have to be the best at everything; just find some work that fascinates you and dig in.
If you are at a point in your career where you want to move beyond being a technical contributor, take a look at your gravity well. Does the work you do influence the people around you by accident or on purpose? Leadership is a skill that can be developed with practice. Spending some time educating yourself on how to better be a leader (I recommend the work of Virginia Satir and Jerry Weinberg) might make that practice a little faster.
Or, who knows—maybe you are already a leader and you just had to look around to notice.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime
Help us improve this page!
What problem are you trying to solve?
By integrating Global App Testing with TestRail, you can launch unscripted and scripted tests and receive results in as little as 15 minutes.
Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.
Organizations need conceptual and QA has crucial strengths to effect that change. Here are three winning action plans to change your QA culture and integrate it with the rest of your SDLC.