What is a principal tester and how can they improve your quality culture and team efficiency?

Many people look at testers in engineering teams as glorified bug hunters there to catch developers’ mistakes. While stopping issues from getting into production is a worthwhile cause, preventing those issues from occurring in the first instance would be a much more effective use of time. 

Levels of experience 

Principal testers usually have ten-plus years of industry experience, either going deep into one technology stack or being more generalist. 

As a result of their exposure to the field, principal testers develop a deep understanding of how multidisciplinary agile software teams work, with some also having leadership experience. While certain testers tend to take the management track, principal testers have chosen to stay technical and remain individual contributors (ICs) within organizations. 

Most principal testers fall into two broad categories, experts and quality engineers.

• The experts are heavily focused on their tech domain and will embed themselves into engineering teams. They work with test and engineering managers, getting hands-on with testing or quality issues. Typically, they support groups that need immediate assistance and that cannot do the work without guidance. 
   
• Quality engineers are similar to experts in terms of experience. They have strong domain knowledge of their chosen area and perhaps technical specialism such as automation skills; however, they can also be more generalist. 

  Quality engineers also have a solid background working in agile software teams, with an excellent grasp of concepts such as Scrum, Kanban, Lean, DevOps, Extreme programming, and others. While they, too, will work with test and engineering managers, their focus will be different, likely collaborating with many teams and concentrating on the more socio-technical aspects. 

Socio-technical systems theory

The socio-technical systems theory states that companies can be understood and improved if an organization’s social and technical aspects are considered interdependent components of complex systems. Components include people, processes, goals or metrics, technology, infrastructure, and culture. 

One way you could look at these components is with the following statement: people work towards goals guided by metrics. They will use processes to obtain those goals with the aid of technology. At the same time, they are working with infrastructure – this may be physical buildings or digital infrastructure (Zoom or Slack). In addition, they adhere to certain cultural norms and assumptions. These components are all interconnected but not linearly related, which is what causes organizational complexity. 

The quality engineering model is about appreciating these relationships and how pulling and pushing in one area will have subsequent knock-on effects on others. Therefore, principals working in teams following the quality engineering model will operate differently to experts. They will assist the team in solving their problems and navigating the organization’s social and technical aspects. These sort of principals will primarily do this by mentoring more junior team members and working in collaborative support with more senior members. 

Collaborative support

Collaborative support is about giving people 1:1 time to discuss their individual situations and their teams. These meetings should be a time when people talk through what they are working on or experiencing in the team, allowing space for some external feedback. 

I call it collaborative support because it’s a two-way conversation. As well as a team member sharing what’s happening in their space, it’s an opportunity for the quality engineer to share what’s happening in the broader department. These meetings are great ways to cross-pollinate ideas and help others build connections with people they may not regularly interact with. 

Deciding which model to use

Principal operating in the expert model 

Deciding which model to use depends on what types of issues you are trying to solve. Experts are great to be deployed into situations that need immediate attention. For example, a principal operating in the expert model would be able to efficiently and easily assess a situation with minimal support, find the best way forward, and make it happen.

The downside of this model, though, is that it focuses on getting things done very quickly. It’s not attempting to improve the situation for the people involved but rather only helping them solve it and move on.

Principal operating in the quality engineering model

Principals operating to the quality engineering model are best in situations that seek more long-term benefits (6-12 months and beyond). Quality engineers build quality into your systems. They do this by looking to work with the team rather than doing it for the team. In other terms, quality engineers cultivate a learning culture of wanting to do more within an organization’s existing infrastructure.  

The downside of this model is that it can take a long time for the benefits to be seen and it often can be challenging to attribute the work to the principal. If the principal is operating effectively in this model, all the attribution to the improvements will go toward the entire team; the principal’s support does not really count as a factor that enabled the team to improve. 

Which is best, the expert or the quality engineer?

Most organizations are complex and typically have various issues that teams attempt to work through. While improving things for the long term helps everyone, there will be times when focusing on short-term benefits would be more suitable. A team struggling with unreliable automation tests blocking releases would best benefit from getting to a reliable point as quickly as possible – the risk here being that there is every chance the problem will reoccur.

A solution to this problem is to have experts and quality engineers pair up and work with the teams together. Both approaches allow the principals to decide the best course of action for the team. For instance, the expert working with the team to help them fix their unreliable automation tests is likely to establish a positive relationship with the team. The quality engineer could then leverage this relationship to refine the team’s test strategy or introduce more reliable automated testing types, improving things for the long term.  

Conclusion  

Principal testers are often underutilized in organizations and will typically default toward the expert model. This is understandable if it’s how they’ve been encouraged to work for most of their careers. But leadership can change this by engaging principals to work differently such as encouraging them to improve the team’s capability to do the work, supporting them to work cross-functionally, and rewarding long-term continuous improvement above short-term delivery. 

By adopting the quality engineering mindset, principal testers can begin laying the foundations of a culture that empowers teams to build quality into their organization’s products, processes, and people.