Hello, I'm Noah Sussman
Please stop trying to sell me on management positions while offering a “QA Engineer” title and salary
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.
- Traditional QA is necessary BUT NOT SUFFICIENT for safe systems. —Dr. Nancy Leveson
- Empirical success… is not proof of safety. Past success does not guarantee future safety. —Sidney Dekker
- Test Automation Zombies
- Classic Testing Mistakes
- The disturbingly thin line between a “passing” test and a no-op
- Even a “simple” test scenario can have a surprising level of complexity. —Trish Khoo
- What should I do if my boss won’t fix her broken unit tests?
I’ve been studying the design and maintenance of software systems for a while now, and these 14 articles have helped me to attain a higher level of understanding of the domain. I thought I’d share them with you.
- "Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart."
- Always deploy from the HEAD revision of trunk and never roll back. Here’s why.
- Etsy Code Deployment, Monitoring and Failure Procedures
- Code Review with GitHub pull requests
- "You can’t really declare something a standard until it has already become a de facto standard."
- "We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy."
- Netflix engineers continuously run destructive automated tests in PRODUCTION.
- "A bug with a one in a million chance of occurrence is likely to happen in the next day or so."
- All software projects exhibit a fractal level of complexity. Proof by example.
- The Addiction Model of Technology Adoption.
- Enforcing Strict Model-View Separation in Template Engines
- Better tools can improve efficiency by about 10%. The other 90% is hard work and cooperation. —Fred Brooks
- Software Systems As Big Balls Of Mud
- The Selfish Class (sequel to Big Ball of Mud!)
Here are 6 great articles to help you get started as a technical software tester!
- Teach Yourself Programming in Ten Years
- How To Introduce Testing Into Your Workflow
- What kind of automated testing should a startup have?
- Why does Kent Beck refer to the “rediscovery” of test-driven development?
- User stories as finite state machines
- "Devops == testing all the time"
You might also want to take a look at the previously published 6 QA Automation resources for self-learners
8 things to think about before attempting to enforce a code style standard for your Engineering team
- Gresham’s Law
- "You should be coding for readability and error resistance."
- Douglas Crockford on coding standards
- coding style at NASA/JPL: “The Power of Ten – Rules for Developing Safety Critical Code”
- Linux kernel coding style
- Why “80% code coverage!” is a BAD goal: “ratchet effects, threshold effects and output distortions”
- Goodhart’s Law: measures of performance will be gamed to the point that they are no longer useful
- "All numerical targets are arbitrary because there is no scientifically-accepted method of setting one."