Joining a new team as an experienced QA professional comes with an interesting disadvantage: you already have opinions.
You’ve seen test strategies that worked and others that existed mainly for audit purposes. You’ve dealt with unstable environments, unreliable automation, poorly defined requirements and releases where the confidence expressed in meetings was rather stronger than the evidence behind it. You’ve learned to recognise certain warning signs.
That experience is valuable. It’s also surprisingly easy to misuse.
Within the first few days, you might notice that the team doesn’t maintain detailed test cases, that defect priorities seem inconsistent, or that nobody produces a formal test summary before a release. Perhaps the Jira workflow looks unnecessarily complicated, or the automation coverage seems unusually low.
It’s tempting to start identifying improvements immediately. After all, recognising problems and making things better is part of what experienced QA professionals are hired to do.
But there’s a difference between noticing something unfamiliar and understanding why it exists.
A team without detailed test cases may have excellent acceptance criteria, strong developer testing and an effective exploratory testing practice. A complicated Jira workflow might accommodate regulatory requirements or dependencies that aren’t immediately visible. A release process without formal QA sign-off may still have clear ownership and well-established readiness controls.
Of course, any of these could also indicate a genuine problem. That’s precisely why it’s worth investigating.
The first month in a new QA role is an opportunity to understand how the team builds, tests and delivers software, where its confidence comes from, and what might be missing. You don’t need to suspend your professional judgement. You need enough context to use it properly.
Day one: Understand where you’ve landed
The first day is rarely productive in a technical sense. There are accounts to activate, systems to access, people to meet and enough unfamiliar terminology to fill a small dictionary.
Still, there’s useful work to be done beyond getting your development environment and Jira access sorted out.
Start with the product. What does it do, who uses it, and what happens when something goes wrong? Even a basic understanding of the business context changes how you interpret quality risks. An inconvenience in an internal reporting tool has different consequences from a failure affecting customer transactions or a critical integration.
You won’t understand the entire product on day one. You’re looking for an initial picture of what the team is responsible for and how its work fits into the wider system.
The same applies to the delivery model.
Some teams deploy continuously. Others work toward fixed release dates, coordinate dependencies across multiple applications, or operate within formal change-management processes. Deployment and release may be separate activities. A feature might reach production behind a feature flag long before customers can use it.
These differences affect what QA is expected to provide, when testing needs to happen and which decisions depend on its results.
It’s also worth establishing what your role actually means in this particular organisation.
Job titles are notoriously inconsistent. One company’s Senior QA Engineer is another company’s Test Lead. A QA Engineer might own automation, exploratory testing, release validation or some combination of all three. A Test Manager might coordinate several teams or work hands-on alongside developers.
Find out what you’re expected to contribute, which decisions you own, and what the immediate delivery priorities are. Your responsibilities should become clearer through conversations with your manager and colleagues, not simply through the job description.
And pay attention to the people.
Who understands the product’s difficult areas? Who can explain the architecture? Who knows why a particular regression test exists? Who makes decisions when requirements are ambiguous? These people won’t necessarily be the ones with the most senior titles.
You don’t need to conduct a formal investigation. Normal conversations, introductions and an interest in how other people work will tell you quite a lot.
One thing I’d avoid is treating every difference from your previous organisation as something worth commenting on immediately.
You might eventually recommend changing how the team handles testing, reporting or release readiness. On your first day, you probably don’t know enough to explain what those changes would improve, or what they might inadvertently disrupt.
The first week: Follow the work
Once the initial onboarding is out of the way, the most useful thing you can do is understand how a change moves through the team.
Not how the documented process says it should move. How it actually moves.
Pick a recent feature, bug fix or reasonably representative change and follow its history.
Look at the original requirement or user story. How was the expected behaviour established? Were acceptance criteria clear enough to test? Did developers and QA discuss ambiguities before implementation, or were those discovered later?
Then look at how the change was tested.
Perhaps there are detailed test cases linked to the story. Perhaps the evidence is distributed between automated checks, pull requests, exploratory testing notes and conversations in the ticket. Perhaps QA isn’t involved until development is complete.
Each arrangement tells you something, although none is automatically good or bad.
Follow the change further. Was it included in regression testing? Were external dependencies involved? How did the team know the relevant environments were suitable? What happened when tests failed? Did the change go straight to production, or was it included in a larger release?
If possible, find out what happened after deployment. Were there smoke checks, monitoring, customer feedback or production incidents associated with the change?
This exercise can reveal more about the team’s quality practices than spending a week reading process documentation.
It also gives you something concrete to discuss with colleagues. Instead of asking why the team doesn’t follow a particular testing methodology, you can ask how it establishes confidence in a particular change.
Read the existing evidence before judging its quality
Test repositories, automation pipelines, defect histories, release records and technical documentation are useful sources of information, even when they’re imperfect.
An extensive test suite might suggest thorough coverage. It might also contain years of redundant checks, outdated assumptions and tests that nobody trusts.
A smaller suite might be carefully selected around high-risk functionality and supported by effective exploratory testing.
Similarly, an impressive automation pass rate doesn’t necessarily tell you much until you understand what the tests cover, how reliable they are, and what remains untested.
Defect history is particularly revealing.
Look beyond the number of open bugs. How are defects reproduced and communicated? What determines priority? Are recurring problems investigated? How are disagreements about severity resolved? What happens to defects that won’t be fixed before release?
The answers can tell you a great deal about the relationship between QA, engineering and delivery.
Pay attention to the environments, too. Test results have limited value if the environment differs materially from production in ways that affect the behaviour being tested. But a shared or imperfect environment isn’t necessarily evidence of negligence. There may be infrastructure, cost, data protection or operational constraints that explain the setup.
Understanding those constraints is part of understanding the risk.
You may find gaps. You may also discover that something you initially considered a weakness is compensated for elsewhere.
A team with little formal test documentation might rely heavily on experienced individuals who understand the product and its failure modes. That knowledge can be effective in day-to-day delivery, while still creating a continuity risk if it isn’t shared.
Both observations can be true.
Participate rather than observe indefinitely
Learning the environment doesn’t mean waiting until you understand everything before doing useful work.
If you’re joining as a hands-on QA engineer, start testing. Take a manageable story, reproduce a defect, explore an existing feature or help with regression testing. Working with real functionality exposes assumptions that onboarding documents rarely mention.
You may find that a requirement has an unwritten exception, that a test environment needs particular data, or that a supposedly simple feature depends on several services.
These discoveries are part of onboarding, and they often make you productive faster than passive observation.
The same applies to ceremonies and team discussions.
Attend refinement, planning, defect triage and release meetings where relevant. Notice how people respond when someone identifies a risk or says they don’t know something. Watch how competing priorities are resolved.
A team’s quality culture becomes much easier to understand when something doesn’t go according to plan.
The important distinction is between asking questions to understand a decision and questioning decisions because they differ from what you’re used to.
There will be time for the latter, when you have enough evidence.
The first month: Start forming an informed opinion
By the end of a few weeks, you’ll probably have encountered a range of practices that seem effective, questionable or simply unfamiliar.
This is where your experience becomes particularly useful.
You can begin comparing what you’ve observed with what the team needs to achieve. Perhaps the test coverage doesn’t adequately address a critical integration. Perhaps defects frequently remain untriaged until the end of a sprint. Perhaps the regression suite takes so long to execute that teams routinely skip parts of it under delivery pressure.
Those are worth examining.
But the quality of your conclusions still depends on the quality of your information.
Before recommending a change, establish whether the problem is recurring, how it affects delivery, and whether the team has already attempted to address it.
There’s a reasonable chance that somebody has identified the same issue before you.
Maybe the proposed solution was rejected because it created another problem. Maybe an improvement is already in progress. Or perhaps the team knows about the risk but has deliberately accepted it because other work has higher priority.
That doesn’t mean the existing decision is necessarily correct. It means you can have a more informed discussion about it.
It also helps to separate what you’ve observed from what you’ve inferred.
For example, you may have noticed that regression results aren’t consistently recorded in the test management tool. That’s an observation.
Concluding that the team has no reliable regression evidence is an inference. Before accepting it, find out whether results are captured in CI pipelines, release records or another system.
If they aren’t, you may have identified a genuine traceability issue. If they are, the immediate problem may simply be that the information wasn’t easy for a newcomer to find.
The distinction matters.
Make improvements that solve an understood problem
After a month, you should have enough context to start contributing beyond your immediate assignments, although the scope will depend on the role and delivery environment.
That doesn’t necessarily mean introducing a new test strategy or redesigning the defect workflow.
Sometimes a useful improvement is much smaller.
You might clarify an ambiguous acceptance criterion that keeps causing rework. Improve the diagnostic information produced by a failing automated test. Document a dependency that repeatedly delays regression. Identify an important scenario that isn’t covered and work with the team to address it.
These improvements are valuable because they respond to something you’ve observed and can explain.
Larger changes require more care.
If you believe the team’s approach to test planning is inadequate, you need to understand the consequences before proposing a replacement. What information is missing? Which decisions are affected? Who would benefit from a different approach, and who would have to maintain it?
Introducing more documentation, another approval step or a new quality metric can look like progress while making delivery slower and adding very little useful information.
Equally, avoiding change entirely isn’t a sign of maturity.
If you discover an immediate, credible risk to customers, data integrity or a production release, you should raise it. A lack of historical context doesn’t justify ignoring a serious problem. You can be explicit about what you’ve observed, what you haven’t yet verified and what needs attention.
The principle is to be proportionate. Some findings deserve urgent escalation. Others need investigation, discussion or simply more time.
The role changes what you should focus on
Not every QA professional enters a new team with the same responsibilities. The first month should reflect that.
For a QA Engineer, the most immediate priorities are usually understanding product behaviour and becoming effective at testing it.
That means learning the relevant user journeys, requirements, test data, environments and tools. It means understanding how defects are reported, how changes are validated and how to communicate useful test results. Being able to investigate a feature independently and explain what was tested, what failed and what remains uncertain is a meaningful early contribution.
A Senior QA Engineer will often be expected to look beyond individual test assignments.
Coverage across features and integrations becomes more important, as do risk-based testing, automation reliability, testability and the quality of feedback reaching developers. A senior QA should be able to recognise weaknesses in these areas, but also understand the engineering choices and constraints behind them.
For example, recommending more automated regression tests is reasonable only after establishing which risks need protection, whether those tests can provide useful feedback, and what maintenance burden they introduce.
Seniority should improve the quality of the questions and recommendations, not simply increase the number of changes proposed.
A Test Manager or QA Lead has another layer of responsibility.
Alongside understanding the testing itself, they need to establish how quality is coordinated and represented across the delivery organisation.
Are responsibilities clear? Do teams share a consistent understanding of readiness? Are test results sufficient to support release decisions? Can stakeholders distinguish accepted risks from unresolved questions? Are dependencies, environments and resource constraints visible early enough for someone to act?
There may also be immediate management responsibilities: supporting the team, addressing delivery commitments, handling escalations and understanding individual capabilities.
In this role, waiting a month before making any decisions may be neither possible nor appropriate. However, significant changes to governance or ways of working still deserve an understanding of what the existing process is trying to achieve.
These distinctions aren’t rigid. A senior QA in a small team might own release readiness. A Test Manager might spend much of the first week investigating defects. An experienced QA joining an unfamiliar product may initially need the same hands-on orientation as someone less senior.
The role determines your responsibilities. It doesn’t exempt you from learning the environment.
What you should know after the first month
Thirty days is an arbitrary boundary. It can cover several releases in one organisation and barely a fraction of a delivery cycle in another.
You might spend most of that time learning a complex product, or you might already be responsible for substantial testing and delivery decisions.
Either way, there are useful questions to revisit.
Do you understand the team’s immediate priorities and the quality risks associated with them? Can you explain where test evidence comes from and how it’s used? Do you know who owns important decisions, especially when testing is incomplete or a release carries known defects?
Have you worked closely enough with the team to understand why it follows its current practices?
And, perhaps more importantly, can you distinguish the things you know from the things you still suspect?
You won’t have a complete understanding after a month. There may be parts of the architecture you haven’t encountered, failure scenarios you haven’t seen, or organisational constraints that only become visible during a difficult release.
That’s normal. A month is enough to establish a useful working understanding, not to acquire years of institutional knowledge.
Experienced QA professionals are often hired because they can recognise patterns, challenge weak assumptions and improve how teams approach quality. That experience should make onboarding easier, but it shouldn’t replace curiosity.
Some of the practices you encounter will need improving. Some will turn out to be better than the approaches you’ve used before. Others will be reasonable compromises shaped by constraints that aren’t immediately obvious.
Knowing the difference takes more than a familiar toolset and a few meetings.
And sometimes the most useful thing you can bring to a new team is the willingness to understand a decision before deciding it was wrong.
A note on context: This article draws on my experience working across different QA and delivery environments and does not refer to any particular employer or team. The first-day, first-week and first-month timelines are illustrative, not prescriptive. Priorities and expectations will naturally vary depending on the role, organisation and delivery context.