QA gatekeeping is an interesting problem to think through. I've been the lead or senior quality assurance engineer for a few companies and I've encountered the scenarios you have written about.
Quality as a culture is an important step in getting whole team buy-in to assess and make changes to the development and release process to ensure there is no QA bottleneck. It is a smart choice and one I always advocate for. For some teams the maturity level of the QA team, the siloed nature of teams outside of QA, and timelines can be a problem if you don't structure the QA team according to the companies needs rather than the software developers needs.
QA should be working with product, business development units, and developers to assess testing needs per code cycle. They should be involved in sprint planning and be a major voice in the discussions. Scope creep is the product of not enough questions being asked during planning, not enough developers and QA engineers assessing risk and timeline to do their jobs appropriately.
For me, an average planning to release window (I also serve as the release manager) cycle looks like this. Attend the planning sessions, bring up any concerns dealing with bug backlog that could slow development down. If not spoken of bring up technical debt that would be required to be worked around. Speak to the amount of time testing will take to be completed for a happy path, assuming no bugs found. Discuss with stakeholders if the features or work are going to be customer focused, used for demos of the site for business, or are silent deploys that upgrade micro services or backend work. From there the tolerance for bugs found verses bugs fixed and prioritized can be found.
Lastly, understanding how many unit tests, in what system are created, if the crunch for time to release code leaves systems vulnerable from lack of tests, and seek to create integration or e2e tests in tandem with the development process to mitigate risk. When all of that is done, testing charters - test cases - automation - UAT - load - and exploratory testing is finished creating a risk profile for the code being released.
Based on the agreed upon risk that product and engineering have assumed we can use bug densities and other quality metrics to track systems that may need post production testing to make up for the slack of a quick release. Reading what you wrote in your post and looking at my own experiences I have acted as a QA gateway but that gateway was constantly being updated to be useful, to solve problems for product and engineering and to speed up the feedback cycle between code and test so that those risk factors were looked at early and often enough to make an impact in code that would be released.
QA gatekeeping is an interesting problem to think through. I've been the lead or senior quality assurance engineer for a few companies and I've encountered the scenarios you have written about.
Quality as a culture is an important step in getting whole team buy-in to assess and make changes to the development and release process to ensure there is no QA bottleneck. It is a smart choice and one I always advocate for. For some teams the maturity level of the QA team, the siloed nature of teams outside of QA, and timelines can be a problem if you don't structure the QA team according to the companies needs rather than the software developers needs.
QA should be working with product, business development units, and developers to assess testing needs per code cycle. They should be involved in sprint planning and be a major voice in the discussions. Scope creep is the product of not enough questions being asked during planning, not enough developers and QA engineers assessing risk and timeline to do their jobs appropriately.
For me, an average planning to release window (I also serve as the release manager) cycle looks like this. Attend the planning sessions, bring up any concerns dealing with bug backlog that could slow development down. If not spoken of bring up technical debt that would be required to be worked around. Speak to the amount of time testing will take to be completed for a happy path, assuming no bugs found. Discuss with stakeholders if the features or work are going to be customer focused, used for demos of the site for business, or are silent deploys that upgrade micro services or backend work. From there the tolerance for bugs found verses bugs fixed and prioritized can be found.
Lastly, understanding how many unit tests, in what system are created, if the crunch for time to release code leaves systems vulnerable from lack of tests, and seek to create integration or e2e tests in tandem with the development process to mitigate risk. When all of that is done, testing charters - test cases - automation - UAT - load - and exploratory testing is finished creating a risk profile for the code being released.
Based on the agreed upon risk that product and engineering have assumed we can use bug densities and other quality metrics to track systems that may need post production testing to make up for the slack of a quick release. Reading what you wrote in your post and looking at my own experiences I have acted as a QA gateway but that gateway was constantly being updated to be useful, to solve problems for product and engineering and to speed up the feedback cycle between code and test so that those risk factors were looked at early and often enough to make an impact in code that would be released.
Super nice reply, thanks for this!