1.2System Reconnaissance
Your first task in any new role is not to write code. It is to gather intelligence.
Think of your first two weeks as an anthropological field study. You are observing a complex system -- part technical, part social -- and your job is to build an accurate mental model of how it works before you attempt to contribute. This is not passive. Good reconnaissance is deliberate, structured, and exhausting.
The Codebase
Before you open a single test file, you need to understand what you are testing. This sounds obvious, but the number of QA engineers who start writing tests against an application they barely understand is staggering.
Start with architecture. Ask your manager or a senior developer for a system architecture diagram. If one does not exist -- and it often does not -- that is your first data point about the organization's documentation culture. Sketch one yourself. Identify the major services, their responsibilities, how they communicate (REST, GraphQL, message queues, gRPC), and where the data lives. You do not need to understand every endpoint on day one. You need the big picture.
Then move to the codebase itself. Clone the main repositories. Read the README files -- if they exist. Look at the directory structure. Identify the tech stack: what languages, what frameworks, what build tools. Find the test directories. Are there unit tests? Integration tests? End-to-end tests? How many? When were they last modified? Are there tests that have been commented out? Tests with names like test_login_BROKEN_DO_NOT_RUN? Every detail tells a story.
In 2026, you have AI-powered tools that can accelerate this process dramatically. Feed the repository to an AI coding assistant and ask it to summarize the architecture, identify the main entry points, map the API endpoints, and list the external dependencies. This is not cheating. This is using the tools available to you. A senior engineer who joined the same team would do exactly the same thing.
The API and UI Structure
Map the application from the user's perspective. Open the application and use it. Click through every major flow. Submit forms. Break things. Note which flows are smooth and which feel fragile. Pay attention to error handling -- or the lack of it.
Then map the API surface. If there is an OpenAPI/Swagger specification, read it cover to cover. If there is not, use browser DevTools to observe the network traffic as you use the application. Build a mental catalog of the main API endpoints, their request/response shapes, and their authentication requirements.
This dual perspective -- UI behavior and API contracts -- is your testing foundation. Everything you do later builds on this understanding.
The CI/CD Pipeline
Find the CI/CD configuration files. They are usually in the root of the repository: .github/workflows/, Jenkinsfile, .gitlab-ci.yml, bitbucket-pipelines.yml, or similar. Read them carefully.
What triggers a build? Every push? Only pull requests? Only merges to main? What stages does the pipeline have? Which tests run where? How long does a full pipeline take? Is there a separate nightly test run? What happens when tests fail -- does the build break, or does someone get a notification they ignore?
The CI/CD pipeline is the truth about what the organization actually tests, as opposed to what it says it tests. If the pipeline only runs unit tests and skips integration tests, that tells you where the gaps are. If the pipeline takes 45 minutes and developers routinely skip it, that tells you about the friction in the development process.
Flaky Test Culture
Every organization has a relationship with flaky tests. Your job is to figure out what it is.
Ask these questions, directly or by observation:
- How many tests fail on any given run without a code change?
- Does the team have a process for investigating flaky failures, or do they just re-run the build?
- Is there a "quarantine" list of known-flaky tests?
- When was the last time someone fixed a flaky test versus disabling it?
- Do developers trust the test results, or do they merge despite failures?
The answers reveal more about the organization's quality culture than any mission statement. A team that actively investigates and fixes flaky tests is a team that takes quality seriously. A team that has a "just re-run it" culture is telling you that their test infrastructure is a liability, not an asset.