A fork in the Road

Aaron Hodder
Mar 6, 2018 · 5 min read

A thread by Aaron Hodder

A fork in the road.

This thread is through a #testing lens because that’s the domain I’m most familiar with. But I believe it applies to most domains in IT. There is a lot of pressure on testers to be “more technical”. The term “technical” is ambiguous and means different things to different people. Let’s explore that briefly:

In many places testing looks like this:
A tester executing step-by-step scripts, and marking them pass or fail.

Image for post

When confronted with this idea of testing, it’s natural to want to replace these expensive human executors with seemingly cheaper robotic executors:

Image for post

In these situations, “Testers need to be more technical” means “Testers need to learn to code so they can get a machine to execute their test cases.” It’s these situations that are the birthplaces of the “Testing is dead” mantra. I’m not going to talk about this. I define “technical testing” as testing the structural aspects of the software and the delivery infrastructure. It is inward-focussed, and helps discover risks to how value is delivered to end users. Things like Performance, Security, Automated functional checks, etc. Regardless of what the product /does/, it’s good that it’s performant, securable, maintainable, extendable, testable, etc. In other words, I am defining “technical testing” as the activities that support testing the quality of the technology underlying the product solution. A non-exhaustive collection of the skills, knowledge, and activities in this domain might look like this:

Image for post

As organisations look to continuously deliver value in a way that’s rapid, scalable, and agile, then these technical testing skills are critical in helping teams deliver stuff. These skills are specialist skills, and are important. We now know we can continuously deliver /something/ that is performant, secure, and beautifully architectured.

But…

It’s only one part of the picture. It doesn’t mean that what the teams are delivering is actually valuable.

Image for post

#Siri is a wonderful piece of engineering. It still has its quirks though:

Image for post

Sometimes the quirks border on irresponsible:

Image for post

And sometimes they just walk right into being dangerous:
(For more information on why this might be a problem, start here: ) (medium.com/talking-microc…)

Image for post
Image for post

Here’s a message someone received from a smart scale. Pretty delightful.

Image for post

Unless you have cancer.
Unless you’ve just lost a pregnancy.
Unless you have an eating disorder.

Just another quick example: A racist algorithm that sends black people back to prison more often than white people, all things being equal: (propublica.org/article/machin…) (theatlantic.com/technology/arc…)

As software becomes more deeply ingrained in our daily lives, as it is now integrated into our homes, cars, and hospitals, and as it becomes applied to increasingly complex domains, the need for deep technical testing ability increases. But…. what is a tester’s role again?

To analyse risk and uncover unintended consequences? All risks? All unintended consequences?

I think so. This tweet sums it up wonderfully:

“Silicon Valley is run by people [who] want to be in the tech business, but are in the people business. They are way, way in over their heads.”

Sometimes people say that testers break things.
I think the testers ought not just try to break the technology.

Testers should be breaking the design decisions, and discovering the consequences on /all/ people for those decisions (not just your “target” users). Who is going to question and analyse the consequences of the algorithm in the autonomous vehicle that decides it’s better to save the driver, rather than the bystander? Who questions the decision to incorporate cupcakes into Google Maps? () (washingtonpost.com/news/morning-m…)

It is absolutely a tester’s job! But this sounds complex and difficult. You’d need to understand ethics, and psychology, and probably need skills from anthropology, and UX. A non-exhaustive collection of the skills, knowledge, and activities in this domain might look like this:

Image for post

As organisations look to continuously deliver value in a way that’s safe and ethical, then these humanistic testing skills are critical in helping teams deliver stuff. These skills are specialist skills, and are important. We now have two broad domains of important specialist testing skills and activities. Those that focus inwards on the technology, and those that focus outwards on the people. If the technology-focussed skills are called “engineering” skills, shall we call the people-focussed skills “#humaneering” skills? I’m not sure. But here’s a diagram illustrating what I mean:

Image for post

At the moment, there is a lot of value placed on the engineering domain, but I suggest that we give the humaneering domain the value it deserves too. Each domain requires a lifetime of study, so I see a future where dedicated testers will need to choose one fork or another in order to specialise.

Aaron Hodder

Written by

Service Lead at Assurity Consulting with focus on Lean testing | Co-Founder @WeTestNZ | http://Inclusive-Collaboration.org contributor. Neurodiversity advocate

Aaron Hodder

Written by

Service Lead at Assurity Consulting with focus on Lean testing | Co-Founder @WeTestNZ | http://Inclusive-Collaboration.org contributor. Neurodiversity advocate

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store