Testing is an area of software engineering that
does not historically draw the widespread respect
accorded to "normal" software
engineers. QA and test automation have
historically been seen as less-skilled, more junior roles, perhaps
even drudge work that could be replaced with adequately sophisticated
Industry standard: A QA Manager generally gets paid the same as a Senior Software Engineer
It says something that it’s considered a perk to be hired into a
position where, as a software engineer, one can work on testing tools
but not be publicly identified as “in test.” Believe me, in
my travels as a consultant this is a theme I
have heard a lot with regard to why engineers do/don’t choose to
work with various organizations.
It is demonstrably impossible to build and run a reliable
system without engineers who excel at “maintenance,” also known as
“keeping the site up.” Testing (aka debugging) makes up the better
part of maintenance.
However for historical reasons the software industry suffers from a
persistent condition in which QA doesn’t get the respect it deserves
for the most part, in most organizations. As a corollary,
organizations that do value and reward testing professionals, wind
up recruiting all the (already rare) competent people in the field.
And this is the state of the (Web and mobile) software industry right
now: everyone who is good at being an engineer “in test” already
works for a company that is willing to pay above the industry mean
for testing expertise.
Escaping the stigma associated with being a tester
Once hired, these “engineers who test” have no incentive to publish
publicly nor to be publicly seen as a voice in the testing community
— remember the industry standard is to pay testers less than
other kinds of engineers.
The result is a stagnating industry where almost no one with deep
technical testing knowledge is motivated to share it.
So… does your organization ignore industry standard
salaries and pay testers like their expertise is a rare and valuable
software engineering specialty?
Punctuated equilibrium is a theory in evolutionary biology which proposes that most species exhibit little evolutionary change for most of their history. When significant evolutionary change occurs, it is generally restricted to rare and rapid (on a geologic time scale) events of branching speciation.
It is a commonly accepted principle that software systems evolve, much like biological ecosystems. And in general the crossovers between programming and genetics are well-known.
A large system that works is invariably found to have grown from a small system that worked —Anonymous
Erik Hollnagel’s concept of Tractable Systems and Intractable Systems assumes that in general there is a an unknown but relatively discrete inflection point for a simple system beyond which the system has become so complex that it must now be considered intractable.
Large intractable systems evolve from simple, tractable systems. A transition point between tractable and intractable exists somewhere along the timeline of an organization’s life.
Once a system flips over to being intractable, then it stops mattering how “big” the system is — your concept of system complexity on some objective scale stops being relevant once system behavior has become non-deterministic.
One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
— Fred Brooks￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼
Recently I was sent a job posting that embodied what I will call the Pernicious Myth of the QA Automation Engineer. Here’s just one line:
Own automated testing capabilities across Web, mobile and production processes.
An engineer cannot by definition take responsibility (that’s what “ownership” means — right?) for features that cut across multiple groups. In all but the smallest companies, Web and mobile would be managed by different teams. With different MANAGERS.
Engineers don’t take responsibility for the behavior of MULTIPLE managers across different teams.
This is a Director’s job.
Managing software capabilities across multiple teams is the job of a mid-level Engineering manager such as a director or (in larger organizations) a VP.
Why not? Because decades of computer engineering experience show that it never works.
Management (with all its wondrous hierarchical levels) is responsible for behavior of people within and across teams. Engineers and designers are responsible for the behavior and organization of the product. Not the people. People are a management problem. Especially at scale. Organizations that forget this fail.
Takeaway: do not sign on for a director’s job at an engineer’s salary
I’m not saying no one should take responsibilty for the “tests and testability” of an application or service.
What I am saying is that someone should be explicity responsible for testing across the whole organizaiton and that person should be at the director or executive level. Never at the engineer or team lead level. Ever.
There is a widespread misconception that QA should own testing. This is false. Not only is it false but it doesn’t even make sense. You cannot have a discrete group that “owns” testing because testing is integral to the activities of both engineers and designers. Organizations often make a choice to ignore this, but the choice is based on cultural inertia rather than science.
Engineering and Product always owns testing because testing is a design process. If QA performs all testing and devises test plans, then that’s an explicit decision by Engineering and Product groups to try not to own testing.
As an engineer-or-designer, you can try not to own testing, but it doesn’t work. Because testing is part of the engineering and design process. Testing is not an activity in itself. Rather it is an aspect of the larger activity of designing and building software systems.
The problem with asking where testing/qa “fit in” to devops is that testing/qa is part of dev.
It’s a historical mistake that test/qa was marginalized to the point it’s now seen as a separate discipline.