Supporting Testers: A Structural Approach
Over the course of my career, I’ve worked with many different companies at various points in their journeys toward quality. A common theme I’ve encountered in my travels is organisations superficially buying into the idea of Testers and Quality as a general concept, especially when the organisation is in a growth phase and wants to expand. They believe it’s the right time to introduce some checks and balances, and bring a bit more rigour into their development practices. They’d like to release more frequently, and believe that test automation will solve all of their problems. So, they hire a test specialist with strong coding skills and ask them to “set up automation frameworks from scratch”, “shift testing left” and all of that good stuff. Problem solved, right?
Wrong.
Parachuting in a person from the test discipline and expecting them to slot into established processes which were made without their role in mind simply won’t work. Here’s some reasons why:
- Unchallenged misconceptions about the role may exist due to biases, lack of knowledge/exposure to the role
- The value of the testing role isn’t familiar to the company, both at the coal face and on the leadership team
- Workflows/processes weren’t built with testing activities in mind
- Changes to accommodate the test role will seem like “extra work” and will face pushback
- Test work in practice may be disruptive and uncomfortable
But it’s not all doom and gloom! It is well within the power of folks at an organisation to tackle these challenges. Let’s explore them in more depth, and outline what teams can do to get the best out of their testers, and what actions testers can take to empower themselves.
Unchallenged misconceptions
A lot of folks are stuck in the mindset that “testers just find bugs”, “testers are gatekeepers” and “testers aren’t very technical”, which prevents organisations from truly unlocking the enormous value that testers can provide. It’s quite a bizarre state of affairs when test specialists can sit on a development team wiriting code every day, designing and building test applications from scratch and maintaining complex frameworks, even having the word “developer” in their job title, only to be considered non-technical in comparison to product developers. In the past, I’ve been incredulously asked what I thought I could bring to the table in a code review, because folks just assumed I wasn’t code literate.
What can be done?
- Manager: Before the tester arrives, discuss with the team why they are being brought on board. Let them know the complexity of the problems they’ll be trying to solve, and be clear about where they will sit on the team.
- Developers: Get yourself up to date with the cutting edge of testing — perhaps explore the Ministry of Testing website as it has some amazing resources!
- Developers: Invite your tester to come pair with you on a bug fix. Their problem solving skills might surprise you!
- Tester: Be happy to educate your team through blogs, talks and coaching.
Their work is undervalued
Testers very frequently have to be salespeople as well as technologists. They are in a rather unique position within a development team where they often find themselves having to sell the value of their work to their colleagues. Their work may be seen as a bonus which can be dropped at any time, if need be. Worse, some folks actively undermine the value of the testing role, stating that developers getting involved in testing tasks “is a waste of their time” or visa-versa, testers being involved in development tasks “adds no value”. This spells out a larger cultural problem, and can be quite the uphill battle to turn around, requiring a lot of effort to recalibrate the team’s perception of the value of their discipline.
What can be done?
- Manager: Communicate with the development team about the benefits the tester will bring before they join.
- Developers: Actively get involved with testing work. You will learn a lot, as it’s harder than you think, and your involvement will elevate the importance of testing work to the wider team.
- Developers: Push back if you see testing tasks on the chopping block, or if you see quality being descoped. Your tester will be very grateful.
- Tester: Shout loudly about any wins that test work provides. It’s always good to celebrate!
Workflows/process issues
Many smaller companies start off not having testers on their teams at all, hiring them later on in their “scale-up” phase of growth, but will hang onto their ways of working from before testers were around. This means that the structures needed to support the tester simply won’t be there, which can lead to them not being able to be as effective as they could be. There may be workflows on the team which actively prohibit the test specialist from being able to carry out their work.
The team may think that testers only get involved once code is merged, and a task is in the “In Test” column. These attitudes may mean that the tester may not get invited to refinement meetings, technical discussions, or architectural design meetings. QA may even exist as a separate entity to the development team, which can lead to lack of collaboration and siloing of skills.
What can be done?
- Manager: Be prepared to make space for process changes, and help support the team through this change. This could mean running Ways of Working workshops, or bringing in a speaker.
- Developers: Consider re-evaluating your current processes. Understand that someone with a different skillset and workflow could have different process needs to yourselves.
- Developers: Pull testers into architectural and implementation discussions. Request testers review your pull requests. You might be surprised at the questions that are raised.
- Tester: Let the team know exactly what you need to be effective, and be patient as they adjust.
- Tester: When changes are made and they do help, let the team know and thank them.
Pushback!
It is all too common that the test specialist is expected to “fight the good fight” and encounter pushback to many ideas they try to push forward. All of this pushback can make it difficult and even unpleasant for the tester to carry out the work the business hired them to do.
Imagine if every single suggestion you made was likely to be dismissed because “it’s too much extra work”, “it’ll slow us down”, “but that will never happen in real life” — you’d probably just give up trying. This can lead to the work environment feeling hostile, and can result in a very demotivated tester who doesn’t feel like the team values their input.
What can be done?
- Manager: If you notice a lot of pushback against ideas which will help achieve the team’s objectives, try to dig into why this is happening.
- Developers: Give some of the changes a go for a sprint, the results may surprise you. You can trash them the sprint after if they don’t work.
- Developers: Consider the possibility that this additional pre-work might make life easier for you in the long run. Spending time preventing bugs means you don’t have to fix them later, and it reduces context switching!
- Tester: Suggest changes incrementally so that they’re not going to overwhelm the team.
- Tester: Be clear about the specific benefits of the proposed changes for the team.
Test work is disruptive and uncomfortable
Test work is generally concerned with reporting on the state of a system, and delivering that information to members of development teams to help inform the decisions they make next. If you follow the Modern Testing Principles, you also believe that part of a tester’s remit is to report on the state of the processes, workflows and teams which create the system under test, and propose improvements and solutions.
Sometimes, the results of this work can be uncomfortable for people to hear. It’s not always easy when someone starts to highlight areas for improvement, and the proposed solutions can require significant cultural change. There needs to be a level of trust from the leadership team toward the tester that their intentions are good. If there is not this bond of trust, suddenly these useful insights and problem-highlighting abilities start to look like nitpicking or worse, personal attacks on the leadership.
What can be done?
- Manager/Developers: Remember that the tester is likely trying to make your life easier by sharing their findings with you. They’re trying to help make things better! Check in with them if you’re not sure.
- Developers: Join the tester in looking deeply at the problems they’ve spotted. Ask them questions about their perspective and open up the dialogue.
- Tester: Be conscientious in the way you deliver your message. Remember the first bug you ever found, and how you might not have known how to approach the developer to tell them. You might be battle hardened now, but it could be someone’s feeling on the line if you’re clumsy with your words.
In conclusion, the job of a tester can be a rough ride. These days, it’s much more than giving an app a kick to find bugs. It’s evolved into a role which can enact real cultural change, with the goal of improving the quality of teams and the products they produce. Naturally, this is a disruptive role and it’s the joint responsibility of the rest of the team and the tester to ensure they get the most out of each other. It’s really important to communicate with each other and be curious, and only then can we see our teams truly flourish. Hopefully this article will give you some inspiration to get to know your friendly tester a little bit better!
