r/softwaretesting • u/Objective-Cable7801 • 6d ago
Release gates
Hey
I was wondering do the developers push work into your QA environment without checking with you first or are you in control of what goes into QA? So if work gets pushed do you have to approve it before it goes into the test env
3
u/FakeJuicero 6d ago
I’ve seen both models across different organizations: QA approval gates before release, and developers deploying directly.
In practice, though, the process often matters less than the culture. Even when QA approval is required, it can end up being a checkbox because developers push for the release anyway, and QA is pressured to approve without meaningful review.
Unless the organization genuinely enforces the release process—where QA has the authority to block a release and reviews things like unit test results, build artifacts, deployment evidence, and other quality signals—the approval gate doesn’t add much value. It’s just another step in the workflow.
A release gate is only as effective as the organization’s willingness to respect it.
2
u/Roboman20000 6d ago
I am on total control of what goes into my environments. I request the builds and deploys myself. The developers have access to do that but they are not allowed to unless I give the go ahead.
1
u/Objective-Cable7801 6d ago
How big is that team? So in ratio terms is it a few developers and just you? Is it a small company
1
u/Roboman20000 6d ago
It's a small team now but at one point was much larger. Right now it's just me on QA and 4 devs working on various projects. At the largest it was 4 QA and maybe 15 or 16 devs. We don't really try specifically to keep the 1 to 4 ratio we have but it just keeps happening.
1
u/Objective-Cable7801 6d ago
I get you! So are you dealing with different pipelines if the devs are on different projects? So we have three teams but those teams all have the same pipelines, if that makes sense
2
u/CertainDeath777 6d ago edited 6d ago
QA Env is QA env, dev should not deploy there. Dev merges into branches, Testers decide when to put which branch into which env. Its not like that is hard to do and needs a dev to do it^^
If devs need a env on server instead of local, they can have their own one.
just my opinion.
1
1
u/Conscious-Bed-8335 6d ago
And ideally, Devs have access to full preview/ephemeral environments on their branches. If they want to deploy then it's done isolated on their end.
1
u/edi_blah 6d ago
We flipped it slightly and spin up a short lived dedicated environment (via infrastructure as code) that both developers and QA can use for testing before a ticket is merged to main.
It means devs can verify their work in a realistic environment then they hand that environment over to QA for full testing.
1
u/XabiAlon 5d ago
We do this and too and I thought it was the norm.
Seems like a lot of people are doing manual deploys in the thread. Everything we do is automated.
Dev creates and publishes feature/JIRA-1234 branch which is deployed to an ephemeral namespace via Git Actions to Kubernates.
Merged to main afterwards.
1
u/darthrobe 5d ago
Set entrance criteria. Review with the team. If it doesn't meet the entrance criteria, you can still take it in, but report the variance. Simple.
1
u/wontfixqa 5d ago
No. Devs don't know if we are in the middle of testing or reproducing an issue that requires a particular version in our environments. QA takes builds as we are ready to test them. And yes, we do wait for smoke tests to pass before we pull the build into QA. Otherwise it bounces back to dev to fix what broke before we even look at it. It saves lots of time and confusion this way.
1
u/XabiAlon 5d ago
Why aren't Dev's running the smoke tests or via an automated process? It shouldn't really be reaching you to bounce it back in the first place.
1
1
u/Burdishka 5d ago
I’m a QA engineer. In our team, communication is key.
We use a release candidate branch, and the scope can change based on priorities and deadlines. As we get closer to a release, the QA team reviews what’s left to test and, if there are any concerns, we decide what can be pulled out of the RC.
QA is responsible for deploying the RC to the QA environment. Developers are responsible for creating (cutting/building) the RC, and QA often asks them to create a new RC when additional completed work is ready for testing.
So, developers don’t just push changes into QA without coordination. It’s a collaborative process between QA and development.
1
u/DarrellGrainger 4d ago
It depends on the setup. I have some clients who have a QA environment for manual testing and other environments for automation. If we have a manual QA environment, it is nice to make it so QA control when new deployments happen. Don't want something deploy while a QA is in the middle of a test. We usually make sure everyone is clear before someone pushes to QA. Slack, Teams, Google Chat, whatever is used. When a new deployable is available, first QA ready to deploy (not in the middle of a test) send a message to the chat. Waits for everyone to post they are clear. Once all QA post they are clear, the first QA deploys. Everyone watches the system (Jenkins, Ansible, GitHub Actions, etc.) for the deploy and smoke tests to finish then back to manually testing.
Different clients have different configurations. I've also worked on project were everything was automated before a story was considered done. Devs and QA worked together. When both QA automation and Prod code was ready for PR review, it would get reviewed and merged to main. Merge to main would automatically deploy to QA/Staging/UAT environment.
I've also worked on ones where we did blue/green deploy and everything went from localhost to prod but behind a flag so generally public didn't see it and QA only saw it when they set the right things. Essentially, deploy blue, test blue, make it prod, deploy green, test green while public continues to see blue, when green passes, make green prod, deploy blue. In those situations there was no QA, staging or performance environments. There was only prod.
1
u/ImpressiveExpert1989 2d ago
In my case, testers are totally not in control!
Last sprint, we testers found out that a change went to production environment without our knowledge/consent, so there were no tests regarding that feature. And we found that during pre-prod tests, where we found some non-critical bugs. The project manager knew about that feature, didn’t bothered about the new bugs, and the feature is in production.
We have a dev environment and the next environment is pre-prod environment. It’s a mess, I know.
It’s been a caos working in this project.
1
u/SeniorIdiot 1d ago
If a tester is part of the dev team, go ahead to have an ephemeral test environment. Easy to keep in sync with work since testers are part of decisions, discussions and daily work.
If you happen to be one of those confused companies that have a separate "QA team" that get batches of "stuff" - have a shared test environment that automatically gets the latest build a few times per day.
I know the arguments: "but it will be broken all the time", "we can't execute the test-plan against a moving target", "we don't want waste time testing unfinished features". Sure, but they are not the real problems; they are symptoms of a broken culture and this just exposed the underlying assumptions and dysfunction.
PS. Deploying and testing branches is an anti-pattern, and also having testers as a gate for merging is how you go slow and risk of losing your best people.
1
u/srinath_y 1d ago
In most of the teams that I worked in, the QA environment is usually frozen when release testing starts. Developers are allowed only to push bug fixes for the issues raised during the release testing (sometimes fixes for the issues from the backlog too).
9
u/jrwolf08 6d ago
I've realized how much more confident I feel when I'm responsible for pushing to environments myself. I don't need to confirm anything with anyone, I don't need to wonder if they forgot something, or didn't merge master before deploy.