Situational questions — Manual QA

There are no requirements or they are incomplete. What do you do?

Gather what exists: the ticket, mockups, correspondence, similar features, competitors' behaviour, Swagger.
Draw up a list of questions and open assumptions and go through it with the PM or an analyst.
Write the agreements in the ticket: that is what the requirements are.
Test based on risks and experience, marking which expectations are my assumptions.

In an interview: I gather everything there is: the ticket, mockups, correspondence, Swagger, similar features. I draw up a list of questions and my assumptions and go through it with the PM, and I record the agreements in the ticket. In parallel I test based on risks, marking where the expected result is my assumption.

The release is tomorrow and there's no time for full testing. What do you do?

Prioritise by risk: what changed, what is most critical for the business, where things broke most often.
Test in this order: the release's changes → critical scenarios (money, login) → the rest of the regression.
Transparently report what was tested and what wasn't, and what the risks are.
The release decision is made by the team and the business, and QA gives information for that decision.

In an interview: I prioritise by risk: first what changed in the release, then the critical scenarios, money and login, and then the rest. And I honestly report what we managed to check, what not, and what the risks are. The release decision is made by the team with the business, and my job is to give them truthful information for it.

Users found a critical bug in production. What do you do?

Quickly reproduce and assess the scale: how many users, how much money, whether it is ongoing.
Tell the team and the responsible people immediately, with all the details.
Help with the decision: rollback, a feature flag, a hotfix, and test the fix.
After the incident, work it out without looking for someone to blame: why the tests missed it, and add a case to the regression or automated tests.

In an interview: First I reproduce it and assess the scale, and immediately tell the team with the details. Then I help choose a solution: a rollback, turning the feature off, or a hotfix, and I test the fix. After the incident we analyse why the tests missed it, and I add that scenario to the regression so it doesn't happen again.

How would you test a login form?

Positive: valid data, "remember me", login after logout.

Negative: a wrong password, a nonexistent email, empty fields, spaces, a wrong format, email case.

Security: blocking after N failed attempts, the same message for a wrong login and a wrong password (so as not to reveal which emails exist), the password masked and not in the URL, HTTPS, SQL injections and XSS in the fields, the session expiring after inactivity.

Other: Enter instead of a click, browser autofill, several tabs, "Back" after logout, localisation of errors, the mobile version.

In an interview: I split checks into positive, negative, security and usability. Besides the obvious invalid data, I always check blocking after several attempts, the same error message for login and password so as not to reveal existing accounts, session termination, and that the Back button after logout doesn't return to the personal account.

How would you test a money transfer between cards?

Validation: the card number (format, the Luhn checksum), the amount (boundaries, fractional parts, zero, negative), your own card as the recipient.
Business rules: sufficient funds, limits, the fee per tariff, the recipient's currency.
Result: the sender's and recipient's balance, the operation history, notifications, the receipt.
States and failures: a decline by the bank, 3-D Secure, a timeout, a dropped network.
Duplicates and races: a double click, "Back" and resubmission, two tabs.
Security: number masking, access to other people's transfers, logs without card data.
Data: records in the DB and in the audit log, reconciliation.

In an interview: I check field validation, including the card checksum and amount boundaries, business rules (balance, limits and fee), and the result on both accounts and in the history. Separately, failures and timeouts, double submission, card data security, and that everything is recorded correctly in the database and the audit log.

You are the only QA on a new project. What do you do in the first 30 days?

Week 1: understand the product and the people: go through the product as a user, meet the PM, the dev lead and the analyst, find out what hurts: where there are the most complaints, incidents, returned tasks.

Week 2: assess the current state: what tests and documentation exist, how the release goes, which environments there are, how bugs are handled in Jira, what is already automated.

Week 3: quick wins: a smoke checklist of critical scenarios, a bug report template, taking part in grooming with acceptance criteria.

Week 4: a plan: a risk-based test strategy, priorities for regression and automation, 2–3 health metrics. Agree it with the team.

The main thing is not to break the process in the first week, but first to understand why it is the way it is.

In an interview: The first week I study the product and talk to the PM and developers to understand where it hurts most. The second I assess what already exists: tests, documentation, the release process. The third I deliver quick results: a smoke checklist of critical scenarios and taking part in grooming. And in the fourth I propose a risk-based test strategy and agree it with the team. The main thing is to understand the process first and only then change it.

A developer says "it works for me", and the bug reproduces for you. What do you do?

Compare conditions: the environment (local vs staging), the build version, configs and feature flags, the user's data, the browser.
Show, don't argue: a video, a HAR file, the exact time for searching server logs, the request ID.
Reproduce together: 5 minutes on a shared call often save a day of correspondence.
If the difference is in the environment, that is also a finding: a config mismatch between environments may repeat in production.

In an interview: First I look for a difference in conditions: environment, build, configs, feature flags, the user's data. I give evidence, a video, a HAR and the exact time for searching the logs, and suggest reproducing it together on a call. If the cause is a mismatch of environments, that is a separate important defect, because it may repeat in production.

The PM wants to release with a known critical bug. What is your position?

The release decision belongs to the business, and QA's job is to make it a conscious one.

Describe the impact clearly: how many users, which scenarios, what financial, legal or reputational consequences, the probability.
Offer options: releasing without this feature (a feature flag), a workaround, a hotfix in the next few days, monitoring and a rollback plan.
Record the decision in writing: who made it, with which risks and conditions.

If the bug breaks the law or data security, escalate higher rather than just agreeing.

In an interview: The release decision is made by the business, and my job is to make it a conscious one. I explain the bug's impact clearly, offer options, such as turning the feature off with a flag, a workaround, a quick hotfix with monitoring, and I record the decision in writing. But if the bug affects data security or regulatory requirements, I escalate higher.

Tasks arrive for testing on the last day of the sprint. How do you fix it?

This is a process problem, not a QA speed problem. Solutions:

Split stories into smaller ones, so they reach testing during the sprint.
Limit the number of tasks in progress (WIP), so the team finishes tasks instead of starting new ones.
Test earlier: test cases before development, API before UI, testing on the feature branch.
Developers do a basic check against a checklist before handing over.
Show the problem with data: time in the "Ready for QA" status, how many tasks arrive in the last two days, and bring it to the retro.

In an interview: It is a process problem, so I bring data to the retro: how many tasks arrive in the last days of the sprint. I suggest splitting stories into smaller ones, limiting the tasks in progress so they get finished, and testing earlier: cases before development, API before UI. Testing is the team's work, not a stage at the end.

Requirements changed after you had already tested the feature. What do you do?

Record the change in the ticket: what changed, who decided, when.
Assess the impact: which cases are outdated, what needs retesting, which related functions are affected.
Update the test cases and automated tests.
Tell the team if the change affects the testing timeline.

If this keeps happening, it is a topic for the retro: requirements must be stable at the moment a task is taken into the sprint (Definition of Ready).

In an interview: I record the change in the ticket, assess which cases are outdated and what needs retesting, update the documentation and automated tests, and tell the team if it affects the timeline. If this happens often, I raise it at the retro: requirements must be stable when a task is taken into the sprint.

Regression takes three days, and releases are weekly. What do you do?

Prioritise: split regression into levels: a critical smoke (hours), the main regression, a full one (rarely).
Risk-based selection: for each release, the critical scenarios plus the areas touched by changes.
Clean up the suite: delete duplicates and outdated cases, merge small ones.
Automate: first of all stable, repeatable, critical scenarios and API checks.
Parallelise: distribute manual regression among people, and automated tests among workers.

The goal is for the most important part of regression to take hours, not days.

In an interview: I split regression into levels: a quick critical smoke for every release, the main regression by change areas, and a full one rarely. I clean the suite of duplicates and outdated cases, and I automate stable critical scenarios and the API. The goal is for the most important part of the checks to take hours, not days.

A flaky automated test blocks a merge, and the team wants to just turn it off. What do you do?

You may turn it off, but as a temporary step with accountability:

Mark the test as quarantine or skip with a ticket, an owner and a deadline.
Check that the scenario isn't left with no coverage at all: check it manually for the time being.
Investigate the cause: the test, test data, the environment, or a real race in the product. Sometimes flakiness is a real bug.
Track the number of tests in quarantine: if it grows, the suite loses value.

In an interview: I agree to turn a test off temporarily, but only with a ticket, an owner and a deadline, and in the meantime I check the scenario manually. Then I investigate the cause: the test, data, the environment or a real race in the product, because sometimes flakiness reveals a real bug. And I make sure there are not more tests in quarantine over time.

The test environment keeps going down, and the deadline is close. What do you do?

Tell the team immediately and record the downtime: it is a blocker, not QA's personal problem.
Test what you can: the API on another environment, bringing it up locally in Docker, requirement review and preparing cases and data.
Reprioritise: with limited time, critical scenarios first.
Transparently update the release risks: what wasn't checked because of the environment.
After the deadline, raise environment stability as a separate task with data on downtime.

In an interview: I tell the team immediately and record the downtime, because it is a blocker for everyone. While the environment is down, I test what I can, the API and local bring-up in Docker, and I prepare cases and data. I reprioritise to the critical scenarios and honestly update the release risks. And after the deadline I bring data on the downtime, so that environment stability becomes a separate task.

The customer asks to skip testing to make the release. What do you do?

In outsourcing the decision belongs to the customer, but they must make it understanding the consequences.

Don't argue "you can't do that", but offer a minimal check: a smoke of the critical scenarios in a few hours.
Name the specific risks: what exactly isn't checked and what may happen.
Record the decision in writing, in an email or a ticket.
Offer a check right after the release and a ready rollback plan.
Inform your manager or lead on the company's side.

In an interview: I don't just say "you can't do that", but offer a minimal smoke of the critical scenarios in a few hours and clearly name the risks. The decision is the customer's, but I record it in writing, suggest a check right after the release with a rollback plan, and keep my manager informed.

During testing you found a bug unrelated to your task. What do you do?

File it as a separate ticket, don't stay silent and don't add it to the current task.

Check that there isn't already such a bug.
Write a full report with severity.
If the bug is critical, tell the team right away, not just create a ticket.
Note whether it blocks the current task and link the tickets.

In an interview: I check that there isn't already such a bug, and file a separate ticket with a full report instead of adding it to the current task. If it is critical, I tell the team at once. And if it blocks my task, I link the tickets and mention it at the daily.

How do you estimate the time for testing a task?

I break it into components and take risks into account:

Requirements analysis and questions.
Test design: cases, data.
Execution: positive, negative, integrations, cross-browser.
Retest after fixes: I usually allow a cycle or two.
Regression of the affected areas, automated tests.

Coefficients: new or familiar functionality, the quality of requirements, environment stability. I check against the history of similar tasks. I give the estimate as a range and say what it depends on, and if the requirements are unclear, I first allocate time for clarifying.

In an interview: I break the work into requirements analysis, test design, execution, retests and regression, and check against the history of similar tasks. I take into account how new the functionality is and whether the environment is stable. I give the estimate as a range and explain what it depends on, and if the requirements are vague, I first allow time for clarifying them.

How would you test exporting a statement to PDF or CSV?

Data: operations for the period match the history and the database; amounts, currencies, dates; totals add up.
Filters: period boundaries (inclusive or not), an empty period, a very large period, the time zone.
Format: the CSV opens in Excel without broken characters (UTF-8 encoding, Cyrillic), separators, the decimal sign; the PDF: layout, page breaks, details.
Volume: thousands of operations: generation time, file size, asynchronous generation with a notification.
Security: only own accounts, masking of card numbers, access to the file by link.
CSV injection: values starting with =, +, -, @ aren't executed as formulas in Excel.

In an interview: I check that the data in the statement matches the history and the database and the totals add up, the period boundaries and time zones, the format: Cyrillic and separators in the CSV, the layout in the PDF. Separately, large volumes, access only to own accounts, card masking, and CSV injection, where a value with an equals sign is executed in Excel as a formula.

Incomplete or contradictory requirements

First I analyse the requirements and record specific questions, not a general "it's unclear". I clarify with the PO, a business analyst or a developer, preferably in writing, in a ticket or Confluence, so that the decision stays documented. I show contradictions with the example of a specific scenario.

If there is no answer yet, I rely on sources of implicit requirements: the behaviour of similar functionality in the product, competitors, UX standards and common sense. I explicitly record my assumptions in test cases or comments. Questions that block work I raise at the daily.

It is best to ask such questions at the grooming or refinement stage, before development starts. This is part of the shift-left approach: a defect in requirements is cheapest to fix before any code is written.

Testing a login form

Positive checks: login with valid data, session persistence, the "Remember me" option, redirect to the right page, logout. I also check login with Enter, browser autofill and working on different devices.

Negative: a wrong password, a nonexistent email, empty fields, an invalid email format, spaces at the start and end, case in the email and password. The error message must not hint which exactly is wrong, the login or the password.

Security: the password is hidden and doesn't end up in the URL or logs, transmission only over HTTPS, blocking or CAPTCHA after several failed attempts. Also SQL injections and XSS in the fields, the HttpOnly and Secure flags for cookies, session invalidation after logout. Separately, the UI, keyboard accessibility and password recovery.