My First Thirty Days as a Test Lead: Expectations and Reality

Starting a new job is a little stressful but a lot exciting. Whether I left a job because of something positive or negative, there are high hopes for what I might learn and work on in my new role.

I recently started with a new company, filling a role I have never had in title: test lead. I wrote this over a thirty-day period while observing what really happens when changing jobs, not just what you’ll see in the new-hire paperwork. My goal during this month is to become as effective as possible in a short period of time without draining resources by having someone sit with me constantly.

Defining Your Role and Setting Expectations

What you see in the job listing you applied to, what you’re told you might be doing during the interview, and what you actually end up doing are all a little bit different. A typical tester job advertisement will say something about writing and executing test cases, maybe with a list of desirable skills. That doesn’t tell you a whole lot about the conditions you’ll be using that stuff in, though.

Defining your role is finding where what was written down and what you were told intersect with how you will actually work. Maybe you excel at a certain type of testing; maybe you want to work paired up with a developer; maybe you have a mind for usability and want to work with the design team a lot; maybe there is a group of developers you groove with. The first thirty days is a great time to explore where you fit and how you can be useful to the team.

My new job was described as a lead for an existing test group. I’ve never been in a lead position before and companies seem to have varying expectations for this role, so I spent a lot of time learning about and setting requirements.

To move this process along, I set up a weekly one-on-one meeting with my supervisor to talk about what I’m doing and what I plan to do and see how that matches up with his vision. This was a nice, informal chat, and the end result was both of us having a good understanding of each others expectations.

When I applied, there were actually no job specifications. A friend saw a Twitter post and generously mentioned me. I sent an email to the company giving a brief introduction along with an invitation to chat on the phone. Because there was no description of what the position required, we spent a lot of time talking and figuring out what each party wanted.

My expectation for this (or any) job is that I would get to do self-directed work on challenging projects with motivated teams, with the possibility of jumping between projects as needed because I really like variety in work. My new employer had the expectations that I would do some coaching and training and bring fresh perspectives and ideas to the organization, in addition to my normal testing work.

One potential conflict was that they were looking for someone to fill a management role. I love doing hands-on testing and was not really interested in managing people 100 percent of the time at that point. Knowing expectations on both sides saved them from being disappointed and me from being unhappy.

I had similar chats with my new test team to see how their test lives were going, what they wanted to learn about, and how I could help them be awesome. I make it a point to see how they are doing every few days, but not so often as to crowd them. These conversations are fun. The test group is two people at this point. Both of them are interested in learning about testing as a craft, so I started planting seeds of ideas like moving from traditional test cases to session notes, using mind maps to develop test ideas, and bug reporting as a skill. A culture that welcomes positive change made these talks easy.

Getting Friendly with the Team

Developing a good rapport with the folks you’ll work closely with is really important. Being on a friendly level helps your coworkers get more comfortable with your giving a critical eye to their work. It puts you in a sort of nonthreatening comfort zone and can be helpful to your credibility as a tester. I spent a good bit of time doing this.

It was important for me to get comfortable with the test group quickly, so on my third day we had an hour session where they talked about stuff they thought was going well and stuff they thought wasn’t going so well. In the end we picked a few things to do differently. Caring and doing work that affects them in a positive way helped these relationships.

Each of us is embedded on a project team, not exactly a multidisciplinary agile team, that focuses on some part of the project. I’m doing testing about 70 percent of the time. The rest of my time is spent merging code to the test environment, facilitating work for the other two testers, and the normal email, meetings, and miscellaneous stuff.

When I saw a group of developers going to lunch, I’d ask if they’d mind if I joined. This can be tough for those on the more introverted or shy side of the human scale, especially with all the other stuff going on, but it is completely worthwhile. Aside from developing a good work environment, you might get a new friend or two out of it. This social interaction pays off in the form of credibility when you are working with developers.

I’m not implying working people in the political sense or in the Gervais Principle power talk sense; I’m suggesting taking a genuine interest in the people you work with because it is beneficial for everyone. Michael Church describes this sort of behavior as that of the technocrat. This is a person who focuses on work that is mutually beneficial.

Becoming a Consultant

Part of what a consultant does when going into a new environment is closely listening to what people have to say. I framed myself as a consultant by being available to listen and offer an outsider’s perspective to anyone who was interested.

One example was the two testers I worked with telling me how they often feel pressed for time toward the end of a sprint. It turned out that they were having two-week sprints: one week of development and one week of testing. The first test build was not available until the second week even though there was testable stuff that could get merged. As an outsider, it was easy to ask why builds weren’t getting to the test phase earlier. This turned out to be a resource problem. Doing builds was a little complicated and normally done by a developer. Early in the sprint, developers’ time is highly constrained. I volunteered to learn how to merge code and get builds to test earlier so we could test with less time pressure.

Over time, I suspect this will be harder as I move from being new and different to becoming “just Justin.” It might be easier to maintain this a little longer at a larger company where you can potentially switch between completely independent groups.

Reflecting on Thirty Days

After thirty days, I’m getting pretty settled into my job and getting a better feel for the team. My current understanding of my role is a mixture of software testing (hands-on and programmatic), a little coaching on test topics, a little facilitating work, and a little risk management.

Toward the end of this thirty-day period, the person who hired me left the company and a new boss stepped in. The new boss is very proactive and scheduled meetings with everyone on the dev team. In my meeting, he asked me to describe my dream job. I detailed a role that consists of moving between projects, getting challenging testing tasks, and mentoring and coaching testers. He grinned and said he had just the project.

Everyone’s experience when changing jobs will be a little different. Maybe some of this will be ironed out for you ahead of time and you’ll have your own adventure and set of things to learn. I’d love to hear about some of your experiences!