top of page
  • Writer's pictureCraig Risi

Transitioning to technical testing – Part 1 – Setting Expectations

What is Technical Testing?

We have heard the phrase automation tester, test engineer or even the more generic backend or frontend tester. So where does technical testing fit into the landscape and why should you look to transition your company towards it?

I’ve written many times before about the evolving nature of software testing and how it is moving in the direction of low level testing, automation and continuous integration. It’s essentially the encompassing of testing and quality into the entire software development process and having strong technically minded testers and engineers who can contribute to the architecture and design of the software while building suitable, scalable test and automation systems to ensure its speedy delivery.

The biggest problem facing most companies though is that they have traditionally focused on testing as a more nontechnical role and so often never approach testing from this angle or have left it to the domain of the architects and development team to resolve who may not having the right quality focus to get it right. This is obviously dangerous for companies who want to move with the times and build innovative software that scales without compromising quality. If you don’t build a team of technical testers, you run the risk of either getting stuck with aging infrastructure or test systems that perhaps don’t quite scale as well as you would like. Which is why it is imperative for companies, even big ones with hundreds of software testers, to start working on making the migration to technical testing.

In fact we can talk a lot about testing and architectural solutions to improve the quality of our software, but the truth is that the technical solutions to these challenges are actually the easiest part. The difficult aspect to changing the quality of your software and improving you testing systems is the people aspect. And in particular, moving people from nontechnical, to technical.

While many start-ups and relatively young tech companies will probably be unable to relate to this need, I’ve been in a position a couple of times where I’ve had to work with companies that are migrating from the traditional manual testing or tool-centric UI testing approach to the new technical and automation approach of testing. And the challenge to assist in adapting the skills of the less technical testers is certainly a difficult and challenging one.

…Not to mention a lengthy one, which is why I’ve split this article up into multiple sections as well, because there is a lot to discuss and perhaps even more to contemplate and strategise once you’ve committee to the path of technical testing and helping to move your team along on the journey.

Non-technical testers can still be great at what they do

Now from the outset I want to state that there is nothing wrong the people who are not technically inclined. Many great non-technical testers have a keen ability to understand the bigger picture of the software they are working with and find ways of mitigating risks and defects without needing to get too technical. This makes these people vital members of any software development team. However, with the push towards high automation and continuous integration, it means that these skills are going to become increasingly redundant as more technical people develop the technical skills. My approach to trying to move a team from non-technical to technical is not to get rid of these people, but rather enhance them with technical training and find ways to use their great skills and domain knowledge to good use without isolating their effectiveness. Pairing them with more technical people or using them in some form of oversight or analysis role often comes to mind. Though the scope for these roles is obviously limited and so can’t apply to everyone except only your best non-technical testers.

I would like to also state that the biggest challenge in moving to a more technical team is balancing the needs of the technical people and ensuring the work environment is challenging enough to make it an exciting space for them while isolating the non-technical folk. It’s not an easy thing to achieve and requires a lot of deliberate focus and effort to get right. But it can be done and companies can make the transition to a technical testing team without needing to radically change their staff or compromise on their technical abilities or quality.

Make a clear statement

If you are going to make the movie to technical testing – the move needs to be made clear that this is where you are going. The “whats” and “hows” might not always be in place, but people need to know it’s coming as early as possible so they can start the learning process while all the details are ironed out. Sending a message that manual non-technical testing is still okay and that the company will accept it indefinitely won’t move teams forward. While you definitely don’t want people to feel like their jobs are threatened, you should be clear on where things are headed. How the learning process is handled and message is delivered should still be dealt with much grace and this should hopefully give people the opportunity to develop effectively.

Create a safe space

To the technically astute, technical testing makes a lot of sense, but it is a significant change to those who have not developed those skills. Which is why the first step to helping people develop these skills is to create a space where these broad skill spectrums are accepted. What this means is that communication needs to be as non-technical as possible and that people who are learning to be technical are given a platform to make mistakes, ask the silly questions and not feel judged for not knowing certain things. It’s easier said than done, but the example starts at the top and management needs to embrace the message of failure. I want to add here though that creating a safe space doesn’t make the standard that you want to move towards any lower, it simply allow people to have the space to learn. If failure is not tolerated people are more likely not to try and that is dangerous when you want people to be enhancing and improving their skillset.

Part of creating a safe space is also the realisation that not everyone is necessarily going to be able to make the transition and it’s also helping to identify other opportunities, such as a business analyst or scrum master where their skills could come in handy. Granted, this might not always be possible and some people may not want this, which makes team losses unavoidable. However, giving people the platform to at least develop and grow goes a long way to incentivising their learning and development.

Another mistake companies make is in changing job titles to differentiate between technical and non-technical people. While this makes recruiting easier because the more technical person gets a different title, in my experience it leads more to animosity and exclusivity than it does to helping the entire workforce get more technical. Remember to keep the bigger picture in mind and rather keep the titles standard across the board with all roles needing to involve technical skills – just some people might be in transition to get there.

Be realistic

Change takes time and you can’t hurry progress. At the same point in time, you can’t wait forever and so you need to be realistic on both sides of the equation that change will take time, but also that if you don’t make some uncomfortable decisions and press a little harder, it’s unlikely to change behaviour quick enough.

Now, if you’re reading all this and thinking surely there is more to it than this – then you would be correct. As I’ve said, this is part 1 of many and there is a lot to look into, including many difficult things like recruitment, mentoring for technical growth and measuring success. All these aspects are incredibly important, but it starts by laying a platform that will allow this change.  



Thanks for subscribing!

bottom of page