14 Ways testers can be technical without writing code

In testing we can fall into the trap of thinking (or being told that) only certain things are technical. These are usually the closer to the code and automation tasks.

But there are additional technical testing skills that aren’t automation based. Testing skills around what should we test, risk analysis and strategy are all technical skills, so is exploration by chasing data through the stack or using tools for benchmarking and testing.

Technical just means “RELATING TO A CRAFT”. If we (or the industry) get too hung up on one part of the testing craft at the expense of the others then of course we can be made to feel “not technical enough”. We need to, as a profession, talk more about the craft of testing and the technical skills we have in this domain.

1. Design & architectural reviews

Get stuck in to looking at the artefacts that come out of a design process, check for integrations that might fail or workflows that might have error points. Make a risk analysis based on UX designs that highlight usability and accessibility issues.

2. Threat modelling

Threat modelling is a risk analysis of potential security vulnerabilities that could occur for a workflow or software. As testers we can support our teams in thinking of the ways that bad actors could elevate privilege for access or access data.

3. Chasing the data

We can look under the hood of web apps by using developer tools to chase input data through APIs to the back end and check their responses. Find out whether that data ends up transformed correctly, saved to the database properly and retrieved and saved well afterwards.

4. Ruber ducking / Pairing

This is the art of sitting with a developer to talk through ideas and use questioning to improve quality as they’re building a thing. It’s a bit like using Triforce to define ACs where you talk about risks and what we can do to fix those potential problems. You can also pair to do TDD or explore what’s being developed as it’s being written!

5. Supporting Debugging

Working with your team to help understand problems, be it through chasing data, looking at logs or pairing (see above) to explore issues and uncover information. This might mean working with an engineer to chase data whilst they add stop points to understand what the code is trying to do.

6. Using tools

Non functional benchmarking tool, API tooling (like Postman) or vulnerability scanners (like OWASP ZAP). Using tools to help uncover information related to more technical risks can really help your team.

Using tools to benchmark non functional requirements.

7. Risk analysis & reporting

One of the key technical skills testers have is our ability to uncover and talk about risks. We can share these early to prevent issues happening and to reduce uncertainty of what needs to be developed (I share risk analysis mind maps on tickets before development starts).

Risk reporting can be risks to development, the project or even to engineering. That does mean having some knowledge of what’s happening within the engineering part of your projects, so why not talk to your teams about that to find out more?

8. Capturing test evidence

Supporting the organisation in understanding how things have been tested so that they can be auditors or aide inheritance of software is important. The way we trace back tests, show how business asks  have been met and demonstrate the testing we’ve done is a technical ask on testers. This can include showing how we’ve chased data and tester through the stack at different layers in a way that others can understand and follow.

9. Test strategy

Strategy means understanding the state of play across engineering and business domains at the organisation to articulate how testing can help. This can be at a high level or lower level, covering all different types of testing as needed (manual, exploratory, automated, non functional…). You don’t have to be able to implement the coding that makes this work, but instead you need a technical appreciation of how these things can help and where to use them (and how to champion and sell these into teams).

10. Exploring

When exploring the system for information we can test through the stack, chasing data (see above) and looking to explore the logic of the system. Exploration can also bring human factors into testing, understanding multiple types of users needs and wants for software.

The ability to identify risks, experiment to uncover information related to them and document them in a meaningful way is also a technical skill.

11. API testing

Whether it’s using the dev tools or directly interactive with the API using something like Postman, API testing is a great technical skill to have. API testing is a great way to start your technical journey as a tester and isn’t as scary as people think (if you can check a database after you’ve input something, you can probably check an API).

Testing at the API layer also lets you test before a UI has been developed (testing headlessly) which helps you start testing sooner.

12. Shifting right

Testing after we deploy something and helping to identify what we need. What metrics and logs will be helpful to ensure system uptime? How do we test that deployments made are fast and safe (hot fixes anyone?) How about making sure that logging is meaningful and helps us point towhere issues are quickly in a meaningful way?

As well as observability, there’s user testing to consider to help feed back into the team knowledge of what customers really want. How do we test for this, what are the techniques and tooling we use to capture meaningful information out of users and pull them together into meaningful reports / actions.

13. Enterprise Architecture

How do systems, software and workflows come together alongside business processes and people? the ability to ask who and what would be impacted by a change to our software, do they need different training or support to work with this change? Testers are best placed to support wider organisational enterprise architecture as they frequently talk to teams as well as engineers to knit the wider picture together and spot weaknesses and risks in that mapping.

14. Teaching, Coaching & Mentoring

The ability explain technical or engineering concepts to others, or to explain business concepts to engineers is a highly technical skill. Knowing enough about topics to find different ways to bring them to life for people, or to use them in a meaningful and contextual way (see strategy above).

Working with other testers to show them how technical skills are not daunting and they they can do them too!

More Blogs

LinkedIn