What Does It Mean To Be A Technical Tester?

‘I want to be more technical!’

is something I’ve heard from a few testers, those I’ve spoken to at conferences, worked with, interviewed, and interacted with on Twitter. Many are concerned about not being technical enough, and that they can only be valuable and have career longevity if they are technical. What does this even mean though? It seems a little ambiguous, and one can end up lost and confused trying to learn the skills to attain some arbitrary technical status. Mark Winteringham recently did an Ask Me Anything session on technical testing where he said he views it as ‘deep diving’ into a particular subject, be that code, or anything else.

Technicality Is In The Eye Of The Beholder

Technical is something of a relative term. To someone who has never used a computer, being able to switch one on and use one might seem unbelievably technical, something Mel talked about in her interview with Gem. Many people have become the go-to IT support person for their family members because they are the ‘technical one’, showing how technical a person is perceived to be is dependent on the perspective of the person perceiving them. To many of my friends, I’m super technical, but to some of you, I would most certainly be less so.

In the context of testing, the use of the word technical triggers an almost immediate association with test automation, it feels almost instinctive to make that connection. When many testers say they want to be more technical, what they really mean is that they want to be involved in writing test automation or writing code, but this feels like a narrow view. Much of this can stem from the pedestal on which developers are placed. Think about the terms which are thrown around, ‘rockstar developers’ anyone? Someone who can code would almost always be described as technical, but that doesn’t mean someone who can’t, is not.

If you aren’t involved in automation, this can lead to feelings of inadequacy, but there are so many other facets to being a technical tester.

Understanding How It’s Built

In my view, understanding how an application is put together, what it’s made of, and how everything interacts, is a great place to start if you want to become more technical. You don’t necessarily need to know anything about coding to be able to do this. I’ve worked with a number of fantastic technical support teams who have to have an extremely in-depth understanding of everything the product is doing in order to support their customers successfully. Maybe they aren’t looking at or writing the code, but no one would ever label them as ‘non-technical’.  

A great place to start is to model out the application or feature you are looking at on a piece of paper or a whiteboard. By this I mean, draw out the different component parts of the system, and the types and direction of communication between them, perhaps the trust boundaries, you could even indicate where your users interact with it. It doesn’t have to be a fancy architectural diagram, even a series of boxes and lines is enough to start with. If you don’t know how your application hangs together, ask your developers.

These kinds of diagrams are often the basis of how technical testers identify risks, come up with tests they need to carry out, and start to think about what tools might help them. They are also used by security testers when carrying out threat modelling exercise. They are a tool I often use when interviewing new testers as I always like to see that a candidate has a good understanding of what they are working on.

Getting Under The Hood

A widely held view seems to be that ‘manual testing’ = non-technical, that testers think only from the user or business perspective, and that testers navigate the front end only with no knowledge or insight into the inner workings of the application. When we click on that shiny button on the UI, we want to know what happens next, don’t we? Just caring about what happens at the beginning and what we see at the end is like reading the first and last chapter of a book and assuming you know everything that happens in between.

I don’t know about you, but some of the great testers I know are what could be described as ‘professionally nosey’, as Gem Hill describes it. They have a sense of curiosity and asking questions like ‘How?’, ‘What if?’ and ‘Why?’ all the time. It’s this that can also help lead people to build the understanding they need to become great technical testers, and as a result, much more T-shaped.

‘Why is it built like that?’

‘How does that request work?’

‘What if that part of the system isn’t there?’

Looking Beyond the UI

Once you have a model of your application, you can work out what to look at beyond the UI.  Is an API request triggered when you click on a button on your web front end? Great! Now it’s time to go and find out what that request looks like, maybe your developers have implemented API documentation like Swagger which could help you with this. Katrina Clokie has a fantastic API and web services testing pathway to help you learn more. Danny Dainton also has a fantastic GitHub repository to help you get started with Postman for API testing.  

From there you can continue to look at what happens to responses from API requests. It may be that data is written to a backend database, or information returned to the user via the front end. If the information returned contains errors you can investigate if and how these are represented to your users, that they are handled gracefully, and don’t leak information which could be misused.

I find the key to understanding different layers of an application is by always asking ‘What next?’, ‘What happens then?’ In the same way that the 5 Why’s can help you to get to the root of a problem, ‘and then?’ helps you trace the flow or sequence through a system. Once you know this, you can start to identify risks, come up with tests relating to those risks, and think about what tools could help you.

Sometimes this task can be made easier if your developers or architects have created sequence diagrams. Generally, these are a series of boxes and directional arrows indicating the order things happen in. If you don’t currently have one you could use what you learn to try and create one.

Exploratory Testing Can Be Technical

Often, exploratory testing is associated with manual, or non-technical testers, but these associations can be misleading. Exploratory testing can be a very technical activity. Maaret’s article on Exploratory Testing an API provides some great information on exploring APIs. You can explore anything around an application, and this technique isn’t limited to the UI.

A great way of making exploratory testing of web applications more technical is by using inbuilt browser tools. These are often accessed by pressing F12 in your browser and you’re presented with a whole bunch of tools to help you explore further. Alan Richardson, aka Evil Tester, has a great Technical Web Testing course which guides you through how to use these tools. He also publishes numerous videos focusing on technical testing topics including recorded exploratory testing sessions using some of these techniques.

Proxy Tools

Once you know the basic flow around your site or application, a proxy tool can give you even more detailed information. A proxy will capture the traffic flowing between your web browser and the site or service you are browsing to. You can also use proxies to capture traffic between services, or network traffic.

There are a variety of options, including:

• Fiddler
• Burpsuite
• Charles Proxy
• JMeter

Similarly, if you want to look at the traffic flowing around your network, you can use a tool like Wireshark. This enables you to capture packets being sent to and from a specified network interface. While the UI may not be the most intuitive, it’s an extremely powerful tool. Joe Colantonio has a great podcast episode which goes into how to get started with Wireshark.

Security Testing

Penetration testing or Security testing can be viewed as extremely technical exploratory testing. Specialised security testers and penetration testers have a significant amount of technical knowledge, and this isn’t just confined to coding. They need to know, amongst other things, about networking, architecture, operating systems, and the details of vulnerabilities. A great many of them use some of the tools I’ve already mentioned.

While stepping into a new field of study, like security testing, can be a bit intimidating at first, there are many resources and communities online to help you. Open Web Application Security Project (OWASP)

OWASP is an organisation dedicated to improving the security of software. Their site contains a wealth of resources to assist beginners to get started with security.

• OWASP Top 10, a list of the most critical vulnerabilities, something which professional security testers frequently use.
• Cheat sheets
• OWASP testing guide
• Tools, like OWASP Zed Attack Proxy, to help you identify security vulnerabilities
• OWASP juice shop - a training environment to help you learn how to explore an application for different vulnerabilities.

Aside from OWASP, there are other resources which you might find useful if you have an interest in application security.

• Troy Hunt - a security researcher and speaker, has some great videos and courses, as well as his own vulnerable training site, HackYourselfFirst.org.
• Dan Billing recently did an AMA on Security Testing.

Automation

Being able to write test automation, or create tools to help you test, can be a helpful skill. If that skill is applied incorrectly, if we automate the wrong things, if we automate when we don’t need to, we are setting ourselves up for failure, or at the very least a lot of hard work further down the line.

Having an understanding of where automation can add value, solve problems, support testers and the development of the application as a whole, is one of the most important skills to have relating to automation. Yet we seem to focus solely on the technical aspects. In my most recent role, this is where I’ve been involved. I don’t spend my days writing automation test code. Understanding where automation adds value requires technical knowledge, of the application, of the risks, and of what automation can do to help the team maintain a high quality project.

If you are looking to improve your coding and test automation skills there is a wealth of resources to help. Ministry of Testing’s own Richard Bradshaw and Mark Winteringham have created Automation In Testing, which includes a number of online courses covering coding concepts, as well as specific languages like Java, and C#.

But I Don’t Test Web Applications!

Even if the application you are testing isn’t a web application or website, for example, if you are testing desktop applications, the same principles still apply. Understand the architecture, data flows, and technologies used to build the application. This will enable you to dig deeper during testing.

Defining ‘Technical Enough’

There is no bar for what constitutes as technical enough. We know that no one can know everything there is to know about testing, technical or otherwise. Even the brightest minds in the testing and development world will admit this. It’s likely you’ll work on projects where you need to learn new technical concepts, but being technical doesn’t mean you use a particular tool, or automation framework, or dictate that you automate at all. It doesn’t need to mean that you wrote those tools yourself.

Non-Technical Isn’t Inferior

Ultimately, labels like “Technical,” and “Non-Technical,” can be quite unhelpful. They are full of ambiguity and end up causing people to feel bad about not meeting some imaginary standard, feeling like they aren’t good enough, and like second class citizens. Instead, why not focus on developing the skills you need to test your software at a deeper level. Maybe you’ll use tools, maybe you’ll write tools, the absence of either doesn’t indicate a lack of technical skill.

I have always labelled myself as ‘not creative’, in that I don’t think I have any artistic or creative talent. It doesn’t come naturally to me. A post from Constance made me reconsider this. People with creative talent spend hours of hard work, dedication and practice to cultivate this. As Constance says, it’s not a fixed attribute. Well, neither is the state of being technical, or not. Maybe you don’t have those technical skills right now, or consider yourself non-technical, but that is not a permanent state of being.   

For all the technical traits that you can possess, the non-technical ones are equally as important. If the thing you are building isn’t what your customers want, contains features which might not work for certain groups of users, or if your team cannot work well together, no amount of technical skills will help. Cultural and people problems can be infinitely trickier to solve than technical ones, and not enough people consider these kinds of issues when developing software. So, avoid putting people in boxes, and stop limiting yourself by labelling yourself either technical or non-technical.

References

• Why you shouldn’t label team members as “technical” or “non technical” - Jennifer Kim
• API and Webservices testing pathway - Katrina Clokie
• AMA - Technical Testing - Mark Winteringham
• AMA - Security Testing - Dan Billing
• Let’s Talk About Tests Baby : The Novella of Testing - Gem Hill ft Melissa Eaden
• OWASP : Threat Modelling
• Exploratory Testing An API - Maaret Pyhäjärvi
• Test Talks - Joe Colantonio
• Automation In Testing - Richard Bradshaw and Mark Winteringham
• Creativity Is Not An Innate Talent - Constance Armitage