This is a guest posting by Justin Rohrman.
Career paths are a myth — a set of blinders we put on to make navigating an organization feel simple. Someone in tech could jump from development, to testing, to product ownership, back to testing, and then on to something else, and only be better for it. But if you stick in a role long enough, chances are your title will change. If you are competent and people like you, maybe a few people will see you as a mentor and seek you out for advice and guidance. Sometimes, at this point, the title of “lead” will be foisted on you.
Some companies will have no official description and let you figure out what the role means for you. Others will have a thorough description of the role, although it may be completely useless in practice. If you are new to the test lead title and are looking for some guidance about what that means, here are some of factors that are important to the role of test lead.
I have a hard time ordering these responsibilities, but if I had to, skill development would be one of the top duties a test lead should perform. Most companies where I have worked want their employees to work on skill improvement: test techniques, describing and reporting on test work, programming, build and deploy pipeline work, and tooling. Companies want all of this, but they generally don’t want it learned on their time. This puts employees, especially those who really do want to improve, in a difficult situation.
I like to approach this goal with consistency — and during company hours.
A recent example would be taking a test team through the BBST Foundations of Software Testing workbook. Each week I would assign a section of text to read, a couple of videos, and a few articles or blog posts to supplement the other materials. And each week the group would read the text, watch the videos and then meet to discuss everything. We also would have a hands-on exercise designed to relate the material we covered back to work we do every day. Each person would do the exercise, and people would volunteer to go over their work.
As each person described how they approached and worked on the exercise, others would draw out lessons they had learned but not initially realized. After we discussed the exercise, we talked as a group about how to apply what we learned to our job. This type of skill development was a sort of zooming out and in. We started with theory about software testing, then slowly closed in on applying that theory to how we do day-to-day work.
Long-term skill development is one of the most important areas of focus for test leads.
Coaching is the other top responsibility that should fall to a test lead. While skill development is a long-term activity that should, in my opinion, span months and years, coaching is more short-term, immediate and practical.
I like to handle coaching through regularly scheduled one-on-one meetings with other testers. I will usually do this on a cadence that is long enough so that there is something new to talk about each meeting; every other week seems just about right. That gives enough time for new sprints to begin and new testing problems to surface. I like to leave the content of these meetings entirely up to the person I am talking with.
Sometimes they might want to talk about how to approach a testing problem. Before I was in leadership positions, I was working on a change that helped calculate discounts. There were several different variables in play, and I didn’t know where to begin. My lead and I took a walk and talked about isolating variables, deciding which to approach at a given time and how to combine them into tests.
Other people tend to want career advice. A tester might want to specialize in a certain area of expertise and focus on a testing niche such as security, load and performance, or usability. When I am familiar with the area they want to specialize in, I recommend things to read and places they can go to learn more, and we talk about what that path looks like in our company and out in the rest of the world. When I am not familiar, I reach out to my network and suggest who they might talk with to get better advice or skill development.
A tester might have more technical leanings and want to learn to write code so they can focus on automation or toolsmithing, or eventually become a developer full time. I ask two questions of these people: Where are you now, and where do you want to be? This helps them move in a direction they will be happy with.
Coaching requirements will change and develop over time as your ability to do it improves, and as the needs and interests of the people you are coaching change.
Facilitation and Unblocking
Test work can be blocked just like development work. Sometimes we are at the end of a stream of work and can’t do anything until a developer has produced some new code to look at. Sometimes there are technical concerns, such as building data or writing code for tooling and testing, that prevent us from moving forward.
Facilitating and getting into the work yourself are usually the two main ways of dealing with blockers.
The facilitating lead sees a problem and finds the people or resources needed to get things moving again. We had a problem with broken builds at one company. Developers would write large amounts of (mostly untested) code, commit and then fire it off to a build. We should not have been surprised at the number of breaking builds and builds failing to install. Our lead would generally go to a developer and get them to pause their work to fix the build so that we could move on. Consequently, the facilitation option generally works better at bigger companies with resources to spare.
Smaller companies might need a lead who can get into the work when needed. My last project had constrained resources. We had a hard deadline for an important customer and not enough people to get the work done in time. Rather than shuffling staff, our lead took a look at the work queue and found the team that had to get the most work done. He joined this team as a combination tester and toolsmith. When new changes were ready to review, he tested them. When nothing was ready to look at yet, he worked on building test harnesses so that the developers could design better code and refactor with less worry.
Keeping the team moving forward has real financial impacts. A skilled lead knows when to facilitate, when to jump in and help a team, or when both are needed.
Leadership requires no title. The minute someone comes to you for help, you are a leader. Having a model of what you think a leader can do will make you more effective at helping those people. I think skill development, coaching, and facilitation and unblocking are crucial to the role. What do you think a lead does?
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.