Quality Assurance Engineers are testers. Sure, as much as mathematicians and accountants are calculators, surgeons are cutters, chefs are cookers & etc. Testing is one of the activities that a QAE does. Nothing more and nothing less. It is a required activity. Just like if you are a surgeon you are required to cut but that does not make you a cutter.
Quality Assurance Engineers own and are responsible for the Quality. Nope. They neither own nor are responsible for the Quality on their own. Quality is a shared responsibility. Given that Quality is an experience, it is the sum up of the work that everybody does, regardless of role and position. QAEs own their portion, are accountable and responsible for it just like Developers, UI designers, UA, DevOps, SecOps, Infrastructure, PM & etc.
When everybody owns something, nobody owns it. Just as with most sayings this one is mostly false. In the context of Quality, the saying is not even wrong.
You always have to do tradeoffs between Speed, Cost and Quality. You can have only two. That comes from the “Iron triangle”, the “Project Management” triangle, “Triple constrains”, “Allergic Threesome” or whatever it is called. If one puts some thinking, then one inevitably would “discover” that Quality, done right, increases Speed while lowers the Cost. Another popular image is a tripod or a three legged stool where the legs are Cost / Time / Scope and the the top is Quality. It gives the wrong impression that Cost / Time and Scope support Quality while it is Quality that lowers the Cost, saves Time and enables for bigger Scope.
Quality Assurance Engineers are a bottleneck. Sure. So is border control. So are the developers and everybody else. Anyone is the bottleneck when an organization is unable to define the What and the How. Most organizations fail precisely there > disregarding the details around execution. Poor leadership never comes cheap.
We can do it without Quality Assurance Engineers. That’s not a misconception really. It’s a delusion. You can disperse QAE responsibilities and activities throughout but you can’t do so in a scalable or effective way. Not that it is impossible, but in general devs do not like to focus on Quality, they like to focus on the code and those are two different things. Quite different. You can cover the small overlap / intersection and that’s it. From that point on this approach does not scale.
Quality Assurance Engineering will disappear. Yup, it is gonna happen next Thursday. Rest assured, it’s gonna go bye bye. Anytime now. The only thing disappearing are good people. People who are curious, wish to understand how technology works, are interested, want to do things better, quicker. People who want to learn and help, assist and serve the customers. QAE will remain.
We don’t need QAEs, we do shift-left! Dear children of Summer. Shift-left is something of a common sense. Literally. For instance having Unit, Integration, Component, Contract tests as part of Definition of Done for a story, or whatever you use. That’s shifting left. Why do we need to call it that? I dunno. Guess it sounds cool and presentable to the “higher management”. Problem is that it is still not enough. Shifting-left can get you only so far. Just like readable and maintainable code can. You still need somebody to figure out the testing scenarios, the end to end ones, you know – the ones that the customer would face. Shifting-left can help you have green pipelines (or really red), stable builds, predictability, ensure certain basic level of Quality and that’s it. It is not one size fits all and it can’t be.
We can and should automate everything. You really can’t and you really shouldn’t. Instead – think it through. Not everything is worth automating. You don’t want to end up with an automation suite of million, mindless and unmanageable tests that take forever to execute and add little to no difference to the desired outcome. One should automate smart, identify the most critical, important and valuable tests to have – then start with them. Cover up the holes along the way. Automating for automation sake is like eating for eating’s sake. Pointless and more often than not – harmful.
Quality Assurance Engineers are very expensive. Truffles are expensive. Gold, nuclear weapons and extreme ultraviolet lithography machines are. How much does it cost to lose a customer’s trust? To demo, do early-bird-access to something that does not work or is like cr@p? How much does it cost to gain a customer and lose a customer? Few dare to calculate this. Most QAEs are in fact underpaid. Those who aren’t – they do cover their wages many times over. The only thing expensive is not having Quality Assurance Engineers.
Our Developers are our QAEs! They are. Question is how good they are at being QAEs? How much time did they spent on that? In what way? What’s the trade-off ratio? With what Quality to what end? Do you envision your developers thinking about testing scenarios, figuring out what and how should be tested & etc as part of their daily activities? You do? Great! Then your Devs are your QAEs and it is all good…in Wonderland.
Security and penetration testing are not part of Quality. Are they not really? They truly, really are, because Security is also shared responsibility. Strangely the concept of Security is much better understood than the concept of Quality.
QAEs do not need to bother with infrastructure. Except that they do. They are the ones that know what is needed, they must be able to set it up and install it, to maintain it. At certain point there could be need for dedicated team but it’s good practice to have the QA environments maintained by the QA.
Quality can be measured. Nope. It can’t. You can’t measure it, you can’t quantize it. You can record the number/type/severity of bugs, you can measure the execution time of automation test suits, you see how fast you can send emails, do file transfers & etc but that’s that. It is not measuring Quality. It is measuring certain indicators that tell you certain things about certain parts of the bigger picture. Sometimes they tend to obscure it. You can measure code coverage, you can check automated end to end tests, you can do all this but Quality can’t be measured. Just like you can’t measure the speed of light in just one direction (always in two), like you can’t measure love or hate.
There are many more misconceptions and myths. The list is endless. No need to add all. Those should be enough to show that too many people, for quite too long, continue to follow those misconceptions and myths. Not an opinion. A fact. Sad one.