I heard that in some companies QA not only gets to approve a release, but can also block it if needed or is at least asked for their inputs. It looks like usually only Product managers and Business people get to block a release.
So, is it a bad sign if a QA has never been in a situation where they got to block a release? Assume that the QA has worked for many years in multiple companies.
Does it suggest that the QA is probably just a rubber stamp and not a critical thinker?
When interviewing for a job, should a QA ask a company if their QA’s have the option to block a release if needed? If the company answers no, then does it reflect badly on career prospects for QA at the company?
i’d ask who owns the release decision and what evidence can stop it, not whether QA has a veto. a healthy team lets QA surface a risk, tie it to an agreed release criterion, and require explicit acceptance if product or business ships anyway.
for a browser failure, that means more than saying “QA says no.” show the affected path, starting state, expected and actual result, impact, and what remains untested. then the decision and risk owner are visible.
the bad sign is not that QA lacks a formal block button. it’s that serious evidence can be ignored without anyone naming and accepting the risk.
If you talk about testers, no a testing should never have an option to block a release, there job is to make sure those making that decision are as informed as they can be to make that decision well.
Here is a quick example I ran into, a QA manager called for the release to be blocked due to a couple of key important failures, the product owner overruled and released anyway. What the QA manager did not know at the time was there was a contractual release date and if that was missed it would cause much greater losses than those important failures would.
So testers, contribute, can give views on this but really should not be given authority to block, they would end up getting overruled anyway by someone either more risk aware or more risk acceptable than the testers often beyond “good enough” standards.
Now a QA may be different, to have any chance of assuring quality they ideally have authority over the whole development cycle, that pretty much never occurs so they could go with this hard gated approach, you cannot release until these standards are met approach. Highly regulated environments or potentially life threatening apps could fall into this QA as a gate category with good reason.
Now if you are called a QA but you are actually doing testing you fall into the tester setup, never a release blocker and by being so you will create disfunction.
Not a tester but a QC type QA that has gates then perhaps but still be prepared to be overruled on occasion, the first time you get overruled remove that release decision from your remit completely, continuing even after just a single time being overruled is dysfunctional.
When I started in test, I worked at a company with a separate Systems Test department where we were supposed to be able to block a release. It sounded like a good idea at the time, but the reality of it ended up being software tennis and a bit too much us vs them. It’s easy to forget that everyone should share the same goal in that kind of environment (e.g. a successful business and a decent annual bonus).
Testing provides a statement on the quality of a product. The role of releasing software is the job of the Release Manager not of the testers. Sometimes software is being released despite Testing saying that the quality is bad.
Testing provides an assessment and insight into the quality of the product. If a tester or test team has reasons to caution against or stop individual tickets from releasing, they need to share that information along with the risks of continuing with the relevant stakeholders.
Now I’ve been at many companies where the CTO or Dev Manager wants my insight, or my teams insight on a release. In that case they aren’t looking for sign off per say and we aren’t gating releases but we are trying to assess risk. In these situations, if I have concerns about releasing a ticket that’s enough to concern the others and it doesn’t go.
At my current company, as a QA Manager, I also own release management. In theory I could stop (or just not start) any release. Rather I try to work with all of our development team members and product owners to understand release risk and go from there.
As @dwaynesamuels says I’d ask about the release decisions, what risks and evidence they like to see that might stop a release. A good question might be: has anyone recently blocked an item from being releasing and why?
curious whether the failure distribution has changed as the coding agents got better?
I’d expect syntax/implementation bugs to drop while behavioural regressions become a bigger percentage - things where every individual component looks correct but the actual user journey isn’t.
would be interesting to see your numbers across a few audits.
In my experience I wouldn’t expect QA to have the power to unilaterally block a release. There should be some process whereby the thoughts and findings of QA are shared with whichever person or group is responsible for making a decision about the release. There may be reasons why blocking a release would be more damaging than going ahead that QA wouldn’t necessarily be aware of.
The biggest red flag for me would be if my findings were not being taken into account. I’d ask a company about the chain of reporting for QA and to describe the role of QA in the decision making process, rather than whether QA has the power to block releases.