[motorest]

> The reason those meetings exist is because of risk! The more changes in a deployment, the higher the risk that one of them is going to introduce a bug or operational issue.

Having worked on projects that were perfectly full CD and also projects that had biweekly releases with meetings with release engineers, I can state with full confidence that risk management is correlated but an indirect and secondary factor.

The main factor is quite clearly how much time and resources an organization invests in automated testing. If an organization has the misfortune of having test engineers who lack the technical background to do automation, they risk never breaking free of these meetings.

The reason why organizations need release meetings is that they lack the infrastructure to test deployments before and after rollouts, and they lack the infrastructure to roll back changes that fail once deployed. So they make up this lack of investment by adding all these ad-hoc manual checks to compensate for lack of automated checks. If QA teams lack any technical skills, they will push for manual processes as self-preservation.

To make matters worse, there is also the propensity to pretend that having to go through these meetings is a sign of excellence and best practices, because if you're paid to mitigate a problem obviously you have absolutely no incentive to fix it. If a bug leaks into production, that's a problem introduced by the developer that wasn't caught by QAs because reasons. If the organization has automated tests, it's even hard to not catch it at the PR level.

Meetings exist not because of risk, but because organizations employ a subset of roles that require risk to justify their existence and lack skills to mitigate it. If a team organizes it's efforts to add the bare minimum checks to verify a change runs and works once deployed, and can automatically roll back if it doesn't, you do not need meetings anymore.

[vegetablepotpie]

This is very well said and succinctly summarizes my frustrations with QA. My experience has been that non-technical staff in technical organizations create meetings to justify their existence. I’m curious if you have advice on how to shift non-technical QA towards adopting automated testing and fewer meetings.

[blackjack_]

Hi, senior SRE here who was a QA, then QA lead, then lead automation / devops engineer.

QA engineers with little coding experience should be given simple automation tasks with similar tests and documentation/ people to ask questions to. I.e. setup a pytest framework that has a few automated test examples, and then have them write similar tests. The automated tests are just TAC (tests as code) versions of the manual test cases they should already write, so they should have some idea of what they need to do, and then google / ChatGPT/ automation engineers should be able to help them start to translate that to code.

People with growth mindsets and ambitions will grow from the support and being given the chance to do the things, while some small number will balk and not want anything to do with it. You can lead a horse to water and all that.

[phatskat]

We are in the early stages of something like this in my org. QA has been writing tests in some form for a while, and it’s mostly been at a self-led level. We have a senior engineer per-application responsible for tooling and guidance, and the QA testers have been learning Java/script (depending on the application, teams we don’t interface with are writing theirs in C# iirc). With the new year, we are starting a phased initiative to ramp up all of QA to be Software Engineers in Testing - each phase will teach and guide and impart the skills needed to be fully sufficient to write automation tests in tandem with engineers writing features.

It’s an interesting and bold initiative imo, as I’ve often worked at places that let QA do whatever felt best which is good from the standpoint of letting them work within their comfort zone, and it also means that testing will largely plateau. I haven’t seen a real push for automation _not_ come out of the engineering department personally (because I’m the one pushing it every time), though I know this place has at least done some work with various automation systems in the past.

[gavmor]

> The main factor is quite clearly how much time and resources an organization invests in automated testing.

For context, I think it's worth reflecting on Beck's background, eg as the author of XP Explained. I suspect he's taking even TDD for granted, and optimizing what's left. I think even the name of his new blog—"Tidy First"—is in reaction to a saturation, in his milieu, of the imperative to "Test First".

[sourceless]

I think we may be violently agreeing - I certainly agree with everything you have said here.