r/softwaretesting • u/Objective-Cable7801 • 1d 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 1d 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 1d 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 1d 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 1d 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 1d 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 1d ago edited 1d 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 1d 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/Material-77 1d ago
It depends on the team's release process, but in my experience QA should at least be aware of what is being deployed.
A workflow that has worked well is:
• Dev marks the ticket ready for QA.
• CI/CD deploys only approved changes to the QA environment.
• QA verifies the deployment and starts testing.
• QA signs off only after testing is complete, not before deployment.
I generally wouldn't want developers pushing random changes into the QA environment without communication because it makes testing and bug tracking much harder. Having a controlled release gate with clear ownership avoids a lot of confusion.
If you're interested in how QA fits into the overall release workflow, this video explains the SDLC/STLC process and where QA activities fit in real projects:
SDLC vs STLC Explained in Hindi | Real Project Software Testing Workflow for QA Testers
https://
1
u/edi_blah 1d 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 1d 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 1d 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 1d 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 1d 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 1d 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 7h 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.
6
u/jrwolf08 1d 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.