This age: we made the thing that codes faster before we made the thing that does QA faster.

Nothing new here. Except for the most trivial of bugs, finding and reliably replicating the bug is almost always harder than fixing it.

▲

gaigalas 2 days ago | parent [-]

I lived in a short period of time in which QA was really good. Early Jenkins era, before GitHub. People engineered a lot of ingenious stuff to prevent bugs.

One team I worked with had tests for the product we made ranging from IE6 to IE11, for example. We did demos in-company where people would poke at the products before launch, play with it. When it reached production, it was rock solid stuff. Our motto was "quality is non-negotiable": we were willing to cut scope but never rush things.

I think things changed since then. "Move fast and break things" was a change, and the bill always comes.

	▲	__MatrixMan__ 2 days ago \| parent [-]
		Agreed, which is a shame. I'd love to see people with highly developed QA skills using AI to push the envelope. There's so much that's possible now that wasn't 15 years ago. For instance "formal verification" has been a dirty word, but now that you can write a proof in lean and have an AI generate an implementation which satisfies it, it seems the bounds of what's economical has changed in a very pro-QA direction. Not to say that that's the silver bullet, but there are many similar examples worth exploring. But I've been interviewing SDETs lately and maybe I've just been unlucky but I don't see a lot of candidates that are ready to rise to meet this challenge. We stopped tending to that garden and now that we have a recipe that calls for it's fruits, they're underripe.