Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

What is technical software testing anyway?


Stemming from our recent article 6 Technical Testing Skills that Have Nothing to do With Automation - I got involved in a debate on Twitter about what actually constitutes technical testing.

Danny Dainton says “It’s not all about being able to code.”

Lim Sim reckons “There’s much more. Viewing and creating dashboards, monitoring, using analytics tools.”

Bill Matthews says it’s “not about having technical skills, it’s about a focus on testing against technical risks with a product.”

I say it’s about “using the techniques of the craft.” Using the right tools for the job, or context.

What do you say?


All of the above. Thing is I’m a System Tester not a Technical Tester, not an Automation Engineer but I’m writing API Tests using Cucumber to the Java level, I’m writing GUI Tests in QTP & Selenium/Cucumber. I’m using Linux and greping logs and using cURL commands, I’m using Postman and SOAP UI and I can hold my own in SQL. While being a domain expert (someone elses words not mine). Is this Technical testing or is it just what’s expected of a tester now. I’d love to hear more about Bill’s comment on technical risks that’s an area I personally feel weak in.


Thinking that my percieved weakness supports Bill’s definition :slight_smile:


@AlaineM - sounds a lot like my role, where I test everything and write automation & tooling to help; and support end users including troubleshooting by way of interrogating databases and log files, adjusting configuration and carrying out deployments etc where required. The amount of time I spend carrying out traditional testing tasks like writing test scripts etc is quite minimal.

I stand by my definition - having the skills and depth of knowledge to be able to use or at least learn the right tools for the right jobs at the right time is mission critical, I would say. But in addition, to be able to translate the information generated by all of the testing/probing/troubleshooting/monitoring/etc activities into actionable insights (i.e. recommendations) is a key part of being ‘technical’ also, in my view anyway.


@sjpknight - Yeah our roles do sound similar and I find the scope of my role growing constantly. In any direction that is useful to the team. I agree fully with your comments.

Bill commented on twitter “To me ‘Technical Testing’ is not about having technical skills, it’s about a focus on testing against technical risks with a product. Technical Risks related to the technology stack for instance. This may mean you require so.e technical skills to achieve this” .

I’ve been exploring the areas detailed by yourself, Danny and Lim but haven’t looked at formally assessing the product in the way Bill mentions. It resonates though. I have advised based on previous experience but I’d like to know how it is done formally. Is it a case of learning the applicable stack and understanding the risks? Is it feasible if you aren’t an Architect and if there are any resources that are helpful?