100% and I’m a software developer and have been for ~30 years. Good QA people know how to find regression and bugs _that you didn’t think about_ which is the whole reason why it shouldn’t be under “engineering” and that it should exist. One of the QA people I work with currently is one of my favorite people. They don’t always make me happy (in the moment) with their bugs or with how they decide to break the software, but in the end it makes a better, more resilient product.

▲

jeremyjh 4 hours ago | parent | next [-]

Agreed. QA specialists are there to think about what the engineer didn't think about. Unless the engineer is incompetent or the organization is broken, the engineer has already written tests for everything they could think of, but they can't think of everything.

More importantly, it is almost impossible for engineers to be as well incentivized to spend extra time exploring edge cases in something they already believe to work than to ship a feature on time.

Like everything else though, its contextual. Complexity of domain, surface area and age of product, depth of experience on team and consequences of failure are all so variable that there cannot be only one answer.

I have done it both ways for many years. I have worked on teams where QA is a frustrating nuisance, and teams where they were critical to success. I have worked on teams that did pretty good without them, and probably those were the highest throughput, most productive teams because the engineers were forced to own all the consequences - every bug they shipped was a production issue they were immediately forced to track down and resolve.

But those were very small teams, and eventually I was the only founding engineer left on the team and far too many mistakes by other people made it to my desk because I was the only person who could find them in review or track them down quickly in production. That was when I started hiring QA people.

▲

MoreQARespect 39 minutes ago | parent | next [-]

Ive almost never worked on a project where there was the right number of QAs who were doing the right thing.

Usually there either arent any in which case bugs get missed or there are 5 very cheap ones running mindless scripts who are standing in for the devs' inability or unwillingness to write decent automated tests but dont catch the really deep level thorny stuff.

▲

9wzYQbTYsAIc 3 hours ago | parent | prev [-]

> More importantly, it is almost impossible for engineers to be as well incentivized to spend extra time exploring edge cases in something they already believe to work than to ship a feature on time.

Personal liability and professional insurance works for all the actual “professions” in the US, to some extent, right?

It might be time to start the considerations for professional licensing for platform scale or commercially published software.

▲

ivan_gammel 3 hours ago | parent [-]

More like certified products. New ISO standard may require professional liability for software products, which will be adopted as requirement by big consumers and will pull the industry into certification loop, because insurers will ask for it. This will obviously put a high entry barrier to many product categories, slowing down innovation.

▲

9wzYQbTYsAIc 3 hours ago | parent [-]

Yes, but slowing down to avoid hazards is sometimes important.

Medical devices and such are the only places I’d expect to see the need for certified products. By extension, in the new era, we really ought only expect certified software where we expect a duty to care from the software system (or any other assigned duty)

▲

ivan_gammel 3 hours ago | parent [-]

In development of medical devices existing quality controls are already working well, right?

	▲	9wzYQbTYsAIc 3 hours ago \| parent [-]
		My point exactly, embedded devices are the closest software gets to actually being built by licensed engineers. The expectation can often be that you are an electrical engineer by training, where licensure is a viable path, unlike in software engineering.

▲

LatencyKills 4 hours ago | parent | prev | next [-]

Exactly. I spent 20 years split between MS and Apple. Some of the best people I ever worked with were in QA. One guy in particular was an extremely talented engineer who simply didn't enjoy the canonical "coding" role; what he did enjoy was finding bugs and breaking things. ;-)

▲

MoreQARespect an hour ago | parent [-]

Really? The best people I worked with were never QA.

Moreover, the best QAs would almost always try to be not QA - to shift into a better respected and better paid field.

I wish it werent so (hence my username) but there is a definite class divide between devs and QA and it shows up not just in terms of the pay packets but also who gets the boot in down times and who gets listened to. This definitely affects the quality of people.

I think it's overdue an overhaul much like the sysadmin->devops transition.

	▲	LatencyKills an hour ago \| parent [-]
		We have differing experiences, which shouldn't be surprising. My example explicitly referred to someone who was a good engineer who enjoyed the QA role. This might have been an Apple/MS thing, but we always had very technical QA people on the dev tools team. For example, the QA lead for the C++ compiler had written their own compiler from scratch and was an amazing contributor.

▲

canpan 4 hours ago | parent | prev | next [-]

Yes, QA is important. My code will always "work" in that everything I tested is bug free. But having someone other test, especially someone who knows the service is gold.

But there is also bad QA: The most worthless QA I was forced to work with, was an external company, where I, as developer, had to write the test sheet and they just tested that. Obviously they could not find bugs as I tested everything on the sheet.

My most impressive QA experience where when I helped out a famous Japanese gaming company. They tested things like press multiple buttons in the same frame and see my code crash.

▲

Ekaros 4 hours ago | parent [-]

I do think the type of testing where QA just follows pre-generated script has place. But it is about long term regression. The first round absolutely should not find anything. But with complex system it also should find nothing in a year or three or five years... Offloading this to dedicate resource could be useful in certain industries.

	▲	canpan 4 hours ago \| parent [-]
		I did not think of that. Maybe for some industries, it might make sense. But if I want a regression test, I would probably set it up as automated test. In the case I mentioned above it was the only test beside my own for a new service.

▲

stingraycharles 4 hours ago | parent | prev [-]

> Good QA people know how to find regression and bugs _that you didn’t think about_ which is the whole reason why it shouldn’t be under “engineering”

I don’t understand the reasoning here why QA shouldn’t be engineering.

▲

9wzYQbTYsAIc 4 hours ago | parent | next [-]

> I don’t understand the reasoning here why QA shouldn’t be engineering.

Who watches the watcher, right?

That aside, the core idea is the same as the principles of independent audit, peer review, or even simply just specialization.

Red team / Blue team?

▲

stingraycharles 4 hours ago | parent [-]

Yes but both the red team and blue team would still be engineering.

	▲	9wzYQbTYsAIc 4 hours ago \| parent \| next [-]
		Yes, but police and military are both law enforcement, on one level, but each are very different from the other. Even the military have police, right? edit: ultimately, it comes down to the importance of independent audit, the builders and the breaker/fixers are very different groups in engineering.
	▲	IAmBroom 3 hours ago \| parent \| prev [-]
		The red team and blue team should not share supervisors. Nor, in the case of QA, should the audit team be engineers trained to act and think like the ones who wrote the software. A fresh perspective is useful. But in the long run, supervisory independence is the real deal. I know of a QA manager who shut down an entire factory's output until a major safety issue (that had been kicked down the road several times) was addressed. It took chutzpah, and serious power, to do that. The Dir. of Engrg. would NEVER have allowed it.

▲

liampulles 4 hours ago | parent | prev [-]

Frankly, calling software development engineering is quite debatable. We should be calling less things engineering that aren't actually engineering qualifications.