You’ve been in the team for two weeks. The next release is on Thursday. Regression is green, a few defects remain open, and you’re told those have already been accepted. Someone asks whether QA is happy to proceed.
You’ve been in release meetings before. You understand the sort of assessment being requested. You are still learning what this team’s regression covers, which dependencies matter, and what people mean when they say a risk has been accepted. Your experience helps you investigate those questions, but it cannot supply the missing product knowledge.
In Joining a New QA Team, I wrote about understanding how a team works before proposing changes. The first release puts that learning into a live decision. It can arrive well before you feel ready to give an opinion, and delivery will rarely pause until your onboarding feels complete.
Understand what you are being asked to confirm
“Are QA happy?” is a surprisingly imprecise question to ask at a release meeting.
It might mean that the agreed testing has finished. It might mean that the remaining defects have been assessed. Someone else may hear your answer as a recommendation covering the entire release, including applications and dependencies outside your team’s responsibility.
Before answering, establish what your contribution is expected to cover. If you’ve assessed one application, say so. A broader recommendation needs evidence from the other areas it includes.
It also matters whether the discussion concerns deploying a change, enabling it for users, or both. Testing may support one decision while questions remain about the other.
Find out how your assessment feeds into the release decision and who can accept outstanding risks. Your organisation may give QA a formal approval role or ask it to provide evidence and advice within a wider decision. Neither arrangement can safely be inferred from your job title.
These responsibilities may be obvious to colleagues who have worked together for years. Asking them to make the scope explicit is reasonable, particularly before your first recommendation becomes part of the release record.
Use the evidence that already exists
The testing completed before you arrived remains relevant. Experienced colleagues may understand failure modes you haven’t encountered, and their judgement deserves attention. You don’t need to repeat their work simply because you weren’t there to observe it.
You do need to understand enough about the evidence to explain the assessment you’re making.
Start with the actual release scope. A familiar feature name can conceal a change to configuration, an integration contract or a shared component. Follow a significant change through the evidence supporting it and see whether the explanation holds together.
For example, regression may have passed against an earlier build. That doesn’t automatically make the results unusable. Subsequent changes might affect a narrow area that has since been retested. Alternatively, a late fix may have changed behaviour on which several earlier results depended. The build history and change impact matter more than the colour of the regression status.
An accepted defect needs context too. A decision made for an internal pilot may not cover a wider rollout. The original acceptance might remain appropriate, but someone needs to establish whether its assumptions still apply.
Evidence may be distributed across CI results, defect discussions and release records. Being unable to find it immediately is not proof that it doesn’t exist. Ask the people who produced or used it to explain what it demonstrates and where its limitations are.
A useful conversation might resolve your concern completely. It might also reveal that the confidence expressed in a meeting rests on an assumption nobody has checked. Both are valuable findings.
Work out which unknowns need attention now
Being new can make different kinds of uncertainty feel much the same.
You might not know why a particular test is sufficient, while the team has a sound explanation and relevant results. Or the team might have no evidence for a material part of the release. The first situation calls for learning. The second may require additional testing, a scope change or a release decision about the remaining exposure.
Suppose a changed integration was tested against a stub based on an earlier API version. That may be entirely appropriate for the behaviour those tests were designed to check. Compatibility with the downstream version due to be released is a separate question. Before concluding that coverage is missing, establish whether current contract tests or another integration environment already provide it.
If they don’t, the remaining time should go toward resolving that uncertainty. A focused compatibility check may be more useful than rerunning an unrelated regression suite.
Some questions cannot be answered through more test execution. If nobody can establish the intended behaviour, you need a product decision. If the relevant environment is unavailable, repeating tests elsewhere won’t establish the behaviour that depends on it. Be specific about what is preventing an assessment and involve someone who can resolve it.
There will also be unfamiliar areas that don’t materially affect this release. Capture those for continued learning. Trying to close every gap before Thursday can consume time the team needs for the questions that could change the decision.
History helps, provided the comparison is relevant. “We’ve always released this way” may lead to an explanation of effective controls or a deliberately accepted constraint. It may also describe a practice whose assumptions no longer hold. Find out which before relying on it.
Give a recommendation people can use
By the time you contribute to the release discussion, your assessment should have a clear scope and a position someone can act on. A long list of caveats can leave everyone else to work out what you actually recommend.
For the integration example, that might sound like this:
Regression passed against the release candidate. The changed integration was tested against a stub of the previous API version, so compatibility with the downstream release remains unverified. I recommend completing that check before proceeding. If it cannot be completed in time, we need to establish whether the integration can be safely deferred.
That recommendation leaves room for new information. An engineer may produce relevant compatibility evidence you haven’t seen. You should be willing to revise your assessment when it answers the concern.
If the gap remains, saying that the risk is “accepted” needs to refer to an actual decision by someone with the relevant authority. It should be clear what exposure they are accepting and why proceeding is considered reasonable. In some cases, the missing information will make the consequences too uncertain to assess sensibly. Be explicit about that too.
You may recommend delaying a release that subsequently goes ahead. The record should accurately preserve your assessment and the decision made, including any conditions attached to it. Otherwise, someone investigating a problem later may reasonably mistake a general green status for agreement that was never given.
Your limited time in the team doesn’t prevent you from raising a credible concern. Equally, it doesn’t make every concern a reason to stop delivery. The substance of the issue should determine the response. When you identify something material, raise it while there is still time to investigate rather than waiting for the final meeting to complete your understanding.
After the release, some of what you learned will belong in your own notes. Other findings may deserve action: a risk acceptance record that omitted its conditions, for example, or integration results that nobody outside one team could locate. Discuss those specific problems with the people involved while the release is still recent.
You may still have considerable product knowledge to acquire. You should nevertheless be able to explain what supported your recommendation, where it stopped, and how the unresolved questions were handled. That is a useful contribution from someone who is still learning the environment.
A note on context: This article draws on my overall experience across QA and delivery environments. It does not describe any particular role, team or company, past or present. The examples are illustrative.