QA Handbook · Daily Life of a QA Engineer

Daily Life of a QA Engineer

A practical view of a QA Engineer’s working day: understanding product risk, testing with the team, maintaining automation and communicating evidence.

The timeline below is illustrative, not a mandatory routine. Priorities change with the Sprint, release schedule, incidents, production support and the needs of the team.

FocusQuality feedbackUseful evidence throughout delivery

BalanceManual + automatedThe mix changes by risk and stage

ExampleREQ-AUTH-001Secure User Logout from story to status

A working day in QA

Use the day as a rhythm, not a timetable. A production incident or release risk can change the order immediately.

Start by understanding what changed and what needs attention before choosing the first test.

What to include

Review Jira stories, bugs, comments and assigned tasks.
Check team email or agreed channels for release notes, incidents and blockers.
Review CI pipeline results and identify failures that may affect the Sprint or release.

QA Engineer’s tips

Begin with risk and urgency, not only with the oldest task.
Confirm the build, environment and owner before spending time investigating a failure.

Example · Secure User Logout

Morning snapshot

Jira: Story acceptance criteria and open defects reviewed
CI: One failed authentication check needs investigation
Plan: Retest a logout fix before starting lower-risk exploratory work

Common mistake Opening the test suite immediately without checking whether the build or environment has changed.

Give the team a short, factual view of progress, the next focus and anything that needs help.

What to include

State what you completed, what you will do next and any blocker.
Mention important defect or CI risk with its ID and current owner.
Move detailed technical discussion to a follow-up with the right people.

QA Engineer’s tips

Say “I cannot retest BUG-LOGOUT-002 because build 1.4.2 is not deployed” rather than “testing is blocked.”
Raise critical risk as soon as it is known; do not wait for the next ceremony.

Example · Secure User Logout

Example update: “Yesterday I reproduced the logout issue on build 1.4.1 and filed BUG-LOGOUT-002. Today I will review the developer’s fix and retest it. I am blocked until the authentication service is available in QA.”

Common mistake Using the stand-up as a long status report without naming the decision or help needed.

Find ambiguity and testability gaps before implementation makes them expensive to change.

What to include

Read the user story, acceptance criteria, designs and API notes.
Ask what should happen on success, failure, permissions, data boundaries and recovery.
Link requirements to scenarios and clarify open questions with the Product Owner or Business Analyst.

QA Engineer’s tips

For Secure User Logout, ask what happens to the server session, browser Back, other tabs and failed logout requests.
Treat review as QA work; testing does not start only when a build arrives.

Example · Secure User Logout

Secure User Logout · story review

The QA Engineer traces REQ-AUTH-001 to AC-01…04, confirms that protected routes must reject the old session and records questions about cache, other tabs and failed requests.

Common mistake Writing tests from the screen alone while missing API, session, permission or failure requirements.

Turn agreed behaviour into useful checks, then combine scripted and exploratory testing according to risk.

What to include

Prepare test scenarios and cases, including happy paths, negative paths and edge conditions.
Perform functional, exploratory, smoke, sanity and regression testing when each is appropriate.
Record actual results, build, environment and evidence; report confirmed defects.

QA Engineer’s tips

Manual testing is valuable for learning, new behaviour and uncertain risk.
Use automation for repeatable, stable, high-value checks; do not assume every QA Engineer has the same split of manual and automated work.

Example · Secure User Logout

Secure User Logout · first pass

Design TC-LOGOUT-001…005 from the acceptance criteria.
Run the smoke path, then replay the old session and try a protected route after logout.
Capture a sanitised response, screenshot or trace when the result differs from the expectation.

Common mistake Treating a test type as a label rather than choosing it for a clear risk or question.

Turn a failure into shared understanding, then confirm fixes on the correct build.

What to include

Reproduce the issue, check for duplicates and report steps, expected and actual results.
Discuss impact and evidence respectfully with the developer and Product Owner.
Retest the failed case after the fix and select related regression checks.

QA Engineer’s tips

Describe the observation before guessing the root cause.
Ask a developer to pair on a reproduction when timing, session or data state is difficult to explain.

Example · Secure User Logout

Secure User Logout · defect loop

The tester identifies that a protected page remains available after logout, creates BUG-LOGOUT-002, discusses the session state with the developer, retests the fixed build and updates the status with evidence.

Common mistake Closing a defect because a developer says “fixed” without running the original check on the new build.

Keep automated feedback trustworthy and use pipeline results to find product, test or infrastructure problems.

What to include

Maintain UI, API or integration checks and review failures in context.
Separate a product failure from a flaky test, data issue, environment issue or pipeline problem.
Use traces, logs, screenshots and reruns carefully; a passing rerun does not erase an unexplained failure.

QA Engineer’s tips

Prefer stable locators and isolated test data.
Ask what changed in the product and the pipeline before changing an assertion just to make CI green.

Example · Secure User Logout

CI analysis

Automation: TC-LOGOUT-002 checks that the old session receives 401
Evidence: Playwright trace and API response are reviewed with the build number
Decision: A session-revocation defect is reported; a flaky-test label is not used without evidence

Common mistake Silencing or retrying a failing test until it passes without understanding the first failure.

Make the current quality picture visible so the team can make an informed delivery decision.

What to include

Summarise executed, passed, failed, blocked and not-run checks.
Report open defects, coverage limits, release risks and the next owner or action.
Leave a clear handover for another shift, team or release window.

QA Engineer’s tips

Use evidence and scope, not only a pass percentage.
State what was not tested, such as other browsers or device sessions, when that is a real limitation.

Example · Secure User Logout

Example status: “5/5 logout cases executed on build 1.4.2. BUG-LOGOUT-002 confirmed fixed; targeted regression passed. Other device sessions were not covered and remain a release risk for the agreed owner.”

Common mistake Ending the day with a private note that the rest of the team cannot use to make a decision.

Daily QA reference

QA responsibilities in practice
Area	Typical contribution
Requirements	Analyse stories, review acceptance criteria and raise ambiguity early.
Test design	Prepare scenarios, cases, data and traceability based on risk.
Execution	Run functional, exploratory, smoke, sanity and regression checks.
Defects	Reproduce, report, discuss, retest and update evidence.
Automation & CI	Maintain useful checks and investigate failures without hiding risk.
Release support	Validate the candidate build, report remaining risks and support handover.

Who QA works with

Collaboration map
Partner	Practical QA collaboration
Developers	Clarify behaviour, reproduce issues, review testability and discuss fixes.
Product Owner / Business Analyst	Clarify value, acceptance criteria, priority and release risk.
Scrum Master	Raise blockers and improve the team workflow.
DevOps / Platform	Coordinate environments, CI pipelines, data and deployment evidence.
Other QA Engineers	Review cases, share coverage, pair on investigation and hand over work.

Scrum ceremonies and QA contribution

Sprint Planning: estimate testing work, dependencies and risk.
Backlog Refinement: improve acceptance criteria and testability before the Sprint.
Daily Scrum: share progress, next action and blockers.
Sprint Review: explain evidence, coverage and known limitations.
Retrospective: improve the team’s quality process, not assign blame.

Common mistakes and practical tips

Do not wait until the end of the Sprint to start test design.
Do not equate automation with quality; people still choose risks and interpret evidence.
Keep evidence reproducible and remove secrets or personal data.
Communicate early, factually and respectfully. A blocker is useful information, not a personal failure.

Related topics: SDLC · STLC · Agile & Scrum · Test Scenarios · Test Execution.