Scenario based QA interview questions

Use a short structure: context, your role, what you did, results, what you learned.

1. Reproduce the bug and collect evidence. Check the impact: who is affected, how often, is there a workaround, is there data loss or a security risk.
2. Tell the product owner, dev lead and release manager right away. Do not only write it in the ticket.
3. Show the options: fix and retest, release with a workaround...

Start with risk and scope:

1. Analyse: key flows (browse, search, product, cart, checkout, payment, orders, returns), integrations (payment gateway, shipping, email), and expected traffic.
2. Strategy: functional, API, compatibility (browsers, mobile), performance (sale peaks), security (auth, payments),...

Open the page, fill in the credentials with locators based on what the user sees, and submit. Then assert the result. Do not just click and stop.

Steps:

1. Choose a stack that fits the team and the app. For example Playwright or Selenium, a test runner (Playwright Test, pytest, TestNG), reporting (Allure or HTML) and an assertion library.
2. Structure: tests, page objects, fixtures and helpers, test data, config per environment, and utilities (API...

1. Set goals and workload from real data: key transactions, user count, think time, ramp-up, duration and SLAs (for example p95 under 2 seconds).
2. Build a test plan: Thread Group, HTTP Request samplers, config elements (headers, cookies, CSV data), timers, assertions, and correlation for dynamic tokens.
3. Run in non-GUI mode, in an environment like production, with separate load generators.
4. At the same time, watch server CPU, memory, database and connections.

An unstable test passes and fails on the same code. Common causes: timing and hard waits, shared or leftover test data, and tests that depend on order. Others are an unstable environment, async UI, and calls to third-party services.

• Ask: talk to the product owner, BA and developers. Clear up doubts and write down your assumptions
• Learn from similar features, current behavior, competitor products and user stories
• Use exploratory testing with charters. Test against common sense, standards and consistency
• Draft test scenarios and share them for review, so gaps show up
• Log questions as defects or notes against the requirement
• Confirm your findings and update the documents afterward

Stay factual and keep it non-personal. Read the requirement or acceptance criteria again. Check the steps again on the latest build. Share evidence (steps, logs, video) and talk in person or on a quick call. If you still disagree, ask the product owner or BA to decide the expected behavior. If it turns out to be as designed, update the test case. Also ask whether the requirement or UX should change. The aim is the right product, not winning the argument.

Reprioritize by risk. Run critical-path and high-impact tests first. Drop or delay low-risk ones. Tell stakeholders early, with numbers (tests run, tests left, open defects) and the risk of what stays untested. Ask for help or more time. Automate where you can, and use exploratory sessions on high-risk areas. Write down the untested scope and get clear acceptance of the risk. Never quietly mark tests as passed.

Sign-off is a risk decision based on evidence, not a feeling:

• Planned test cases are run, with the pass rate and any blocked tests explained
• No open critical or high-severity bugs. Remaining medium and low bugs are reviewed and accepted
• Regression and smoke suites pass on the release candidate
• Non-functional checks are done (performance, security basics) where in scope
• UAT is approved
• Rollback plan and monitoring are ready

• Read the integration contract: endpoints, message formats, auth, error codes, retry rules.
• Use the vendor sandbox with test credentials. Mock or stub the dependency for unit and API tests, so they are fast and give the same result every time.
• Test the happy path, declined cases and timeouts. Test duplicate...

Give the tool cleaned inputs: raw notes, error logs, stack traces and the failing test output. Ask it to do four things. (1) Draft a title, steps, expected result and actual result. (2) Group similar failures and spot likely duplicates. (3) Suggest the likely component and severity. (4) Shorten a long log to the first failing line and the probable cause.

Give a clear start: a product walkthrough, access to environments, a glossary and a buddy. Begin with small, real tasks (retest bugs, run regression, write cases for a simple story). Review their work and give specific feedback. Then widen the scope to exploratory sessions and API tests. Pair with them on a first bug report and a first automation script. Share checklists and templates. Encourage questions. Hold a weekly one-to-one on growth goals. Praise good catches in public.

A blocker stops further testing of a feature or build. For example, login is broken, so no other flow can be reached. Report it right away with high priority. Tell the developer and the lead directly. Mark dependent test cases as Blocked, not failed. Meanwhile, test other areas that are not affected. Once it is fixed, retest it and continue with the blocked cases.

I would start small, measure the benefit and keep humans responsible for quality.

Positive

• A valid email and password logs in and opens the dashboard
• "Remember me" keeps the session after the browser restarts
• The Enter key submits the form
• Email is not case-sensitive ([email protected] works)

Negative

• Wrong password or unknown email: show one general error ("Invalid email or password"). Do not say which one is wrong
• Empty email, empty password, or both empty: show a message at each field
• Wrong email format (abc@, no @)
• Spaces at the start or end, very long input, SQL or script characters: handled safely
• Account locked or disabled after N failed attempts

Edge and non-functional

• Password is hidden, no autocomplete leak, paste is allowed
• HTTPS only, and the password is never in the URL
• The Back button after logout does not show private pages
• Works on Chrome, Safari and mobile; tab order and screen reader labels are correct
• Response time is under 2 seconds

What they are checking: A clear plan with positive, negative, edge and security cases

Assume these fields: name, email, password, confirm password, terms checkbox.

Positive

• Valid data creates the account and sends a verification email
• The verification link turns the account on

Negative and validation

• Each required field left empty
• Wrong email formats; an email that is already registered (show a clear message, but follow the policy on not revealing which emails exist)
• Password shorter than the minimum, or missing an uppercase letter, number or symbol that the rules need
• Confirm password does not match
• Terms box not ticked: submit is blocked
• Name with digits, emoji or very long input

Boundary

• Password at exactly the minimum length, and one less; at the maximum length, and one more
• Name with 1 character, and with the maximum length

Other

• Double click on Submit creates only one account
• Expired or already used verification link
• Password is stored as a hash (check the database) and is not in the logs

What they are checking: Field-level validation and boundary thinking

Positive

• An exact keyword returns the right results; a partial keyword works (if the product supports it)
• Search is not case-sensitive; multiple words work; the best matches come first
• Result count and pagination are correct; clicking a result opens the right item
• Suggestions (autocomplete) show while typing

Negative

• Empty search or only spaces: show a message or do nothing
• No match: show a friendly "no results" page with suggestions
• Special characters, quotes, %, <script>, SQL pieces: no error and no injection
• Very long text (1,000 characters)

Other

• Filters and sorting work together with search; the URL can be shared
• Search with a typo or accented letters
• Performance: results come in under 2 seconds for a large catalog
• Recent searches, a clear button, and the "Search" key on a mobile keyboard

What they are checking: Covers both normal use and hard cases

• Add one item; adding the same item again raises the quantity (or adds a second line, as the spec says)
• Change the quantity: 1, the maximum allowed, 0 (removes the item), negative, decimal, not a number
• Remove an item; an empty cart shows a message and checkout is disabled
• Price math: line total, subtotal, tax, shipping and discount, rounded to 2 decimals
• Item goes out of stock or stock drops after adding: show a warning at the cart or checkout
• Price changed since the item was added: the cart shows the latest price
• The cart stays after a refresh, after logout and login, and across devices for logged-in users
• A guest cart joins the account cart after login
• Apply a valid, expired and invalid coupon; a coupon used with sale items
• Update the cart in two tabs at the same time
• Mobile layout and quantity buttons

What they are checking: Thinking about business rules and calculations

Flow: cart -> address -> shipping -> payment -> review -> confirmation.

• Happy path as a guest and as a logged-in user; order number and confirmation email
• Address checks: required fields, postcode format, saved addresses, different billing and shipping address
• Shipping options change the total and the delivery estimate
• The order summary matches the cart (items, tax, discount, shipping)
• Payment methods: card, wallet, cash on delivery
• Back button or refresh in the middle of checkout keeps the data and does not create a second order
• Double click on "Place order" creates one order
• Stock drops to zero during checkout: show a clear error and do not charge
• Session expires on the payment page
• The order shows in "My orders", stock goes down, and the invoice is correct
• Failure paths: payment declined, gateway timeout, email service down

What they are checking: The full flow from start to end, with failures handled

Positive

• Valid card, expiry and CVV: payment succeeds, and the receipt and status update
• Different card types (Visa, Mastercard) are found from the number

Negative

• Wrong card number (fails the Luhn check), expired card, wrong CVV length, past expiry date
• Not enough money, card declined, 3-D Secure failed or cancelled
• Empty fields, letters in number fields

Edge

• Gateway timeout: the user is not charged twice, and the order stays "pending" until it is checked against the bank record
• Double click or refresh after submit: the request is idempotent (running it twice gives the same result), so there is one charge
• Amount and currency sent to the gateway match the order
• Browser Back after success does not send the payment again

Security

• Card details are not logged or stored, the page uses HTTPS, the CVV is hidden
• Changing the amount in the request is rejected on the server

What they are checking: Handling money safely, idempotency and security

Positive

• Upload allowed types (jpg, png, pdf) within the size limit; preview and download work
• Many files, drag and drop, replace a file and delete a file

Negative

• Types that are not allowed, a renamed extension (.exe renamed to .jpg), a file with zero bytes
• A file 1 byte over the limit, and a file exactly at the limit
• A very long file name or one with special characters; the same name twice
• Cancel the upload half way, network drops, resume or retry

Security

• Files with harmful content, a script inside an SVG, path traversal in the file name (../../x): all rejected
• File links cannot be guessed; downloads need permission

Other

• Progress bar and error messages
• Upload on a slow network; upload from a mobile camera; a large file does not freeze the screen

What they are checking: Limits, checks and security of uploads

Authentication

• A valid card and PIN opens the menu
• Wrong PIN once, twice and three times: the card is blocked or kept after the limit
• An expired, damaged or non-bank card is rejected; the card is removed during a transaction

Withdrawal

• Amount that fits the available notes, is within the balance and is within the daily limit
• Amount above the balance, above the daily limit, not a multiple of the note value, zero, or negative
• The machine does not have enough cash
• The receipt is printed with the right details; the balance goes down only once

Other functions

• Balance check, mini statement, PIN change, deposit, transfer
• Timeout when no one uses it: the card is returned
• Power or network failure during a withdrawal: the transaction is reversed and no money is lost
• Cancel at any step; privacy (PIN is hidden); access for people with poor sight

What they are checking: Testing a real-world device, including failures

Add

• Add a task with valid text; the Enter key and the Add button both work
• An empty task or a task with only spaces is rejected
• Very long text, emojis, HTML tags (shown safely), duplicate names

Complete, edit and delete

• Mark a task done and undo it; the strike-through and the counter update
• Edit the text, cancel the edit, save an empty edit
• Delete a task, ask for confirmation, undo if the app has it
• Clear completed tasks

List behavior

• The filters All / Active / Completed show the right items
• Task order, drag to reorder, priority and due date if present
• Tasks stay after a refresh and show in another tab (local storage or server)
• 500+ items still run well

Other

• Keyboard use, mobile layout, text direction, page title and counters

What they are checking: The whole create, read, update, delete flow plus saved data

Positive

• A registered email gets a reset link; the link opens the reset form; the new password works; the old password stops working
• The user is logged out of other sessions after the reset

Negative

• Unknown email: show the same neutral message ("If an account exists...") so no one can find out which emails exist
• Expired link (for example after 15 minutes), a link that was already used, a changed token
• New password breaks the rules; confirm password does not match; same as the old password, if that is blocked
• Many requests in a row: the system limits them

Security

• The token is random, works once, and cannot be guessed; the link uses HTTPS
• The email does not contain the password; the reset does not show account details

Other

• The email arrives in a reasonable time, with the right branding and link
• Two reset requests: only the latest link is valid

What they are checking: Testing a flow with security in mind

• Positive: the correct OTP within its valid time (for example 5 minutes) completes the login
• Wrong OTP: an error shows, attempts are counted, and the user is locked out after the limit (say 3 or 5)
• Expired OTP: rejected, with a "Resend" option
• Resend: the new OTP makes the old one invalid; the...

1. Look around (3 minutes): browse the pages and find the main flows (browse, search, product, cart, checkout, account).
2. Write scenarios first (5 minutes), by area: registration and login, product list and filters, product detail, cart, checkout, order history, responsive layout.
3. Explore each flow...

• First 2 minutes: use the happy path (add, complete, delete) to learn how the app works.
• Next, attack the input: empty, spaces, 1,000 characters, emoji, <b>bold</b>, <script>alert(1)</script>, duplicates.
• State and saved data: refresh, open a second tab, clear storage, go offline.
• Controls: filters...

Stop exploring, reproduce the issue, cut the steps to the fewest, then write one bug per report.

Positive

• Valid receiver and an amount within the balance: debit and credit happen once, with a reference number and an SMS or email confirmation

Use test design techniques to cut the number of tests:

• Equivalence partitioning and BVA (boundary value analysis) for each field: one valid group, invalid groups, and the boundaries.
• Group fields by type: use one reusable checklist for all text fields, all number fields, all date fields.
• **Decision...

Valid: [email protected], [email protected], uppercase letters, numbers, subdomain. Invalid: no @, two @, missing domain (a@), missing user (@x.com), spaces inside. Also invalid: no dot in the domain if required, dot at the end, comma instead of dot, Unicode spaces. Boundary: very short...

Show that you can test an object with no spec by asking questions first (purpose, type: ball point, gel, fountain; users).

Ask first: capacity, number of floors, single lift or a group of lifts.

• Each filter alone (category, brand, price range, rating) shows only matching products and the right count
• Different filters combine with AND; values in the same group (two brands) combine with OR
• Price range: min greater than max, min equal to max, negative, empty, not a number
• Clear filters resets the list;...

• A valid name, email, subject and message submit; a success message shows; the email reaches the support inbox
• Each required field empty on its own, and all empty together
• Wrong email; phone with letters; message at the minimum and maximum length (and over)
• HTML or script input is made safe; emoji and...

• A valid code lowers the total correctly (percentage and fixed amount), rounded to 2 decimals
• Wrong code, expired, not active yet, already used, wrong letter case, spaces around the code
• Minimum cart value, only some categories or products, sale items left out
• One use per user vs unlimited use; total usage...

• Update name, phone, address and profile photo: saved, and shown after a refresh and on other pages
• Required fields empty; wrong phone or email format; maximum length
• Photo: allowed types and size, very large dimensions, cropping
• An email change needs verification; the new email is already used
• A password...

• Search by date or route, choose seats, pay, and get a ticket with a unique ID or QR code
• Seat map: booked seats cannot be chosen; a maximum number of seats per booking; select and unselect
• Two users choose the same seat at the same time: one succeeds and the other sees a clear message
• A seat hold timer (for...

• Send and receive text in real time; delivery ticks (sent, delivered, read)
• An empty message is blocked; a very long message; emoji, links, code, text in many languages
• Media: image, file, voice; size limits; preview and download
• Group chat: add or remove members, admin rights, messages seen only by members -...

• Basic operations: 2+3, 9-12 (negative result), 6x7, 8/2
• Division by zero: show an error and do not crash; 0/0
• Decimals: 0.1+0.2 shows 0.3 (rounding is handled); long decimals; zeros at the start; more than one dot is rejected
• Very large numbers and overflow, scientific notation, negative numbers
• Chained...

• Set pickup and drop; fare estimate; choose a vehicle type; a driver is assigned with a live arrival time
• Invalid location, same pickup and drop, location not available, outside the service area
• GPS permission denied; poor accuracy; the map and driver position update
• Cancel before and after a driver is...

• 200 and a token for valid credentials; the response has no password hash
• 400 for missing or bad JSON or empty fields; 401 for a wrong password or unknown user, with the same message
• 415 or 400 for the wrong content type; extra or unexpected fields are ignored
• Token expiry, format and claims are correct; the...

• A valid 10-digit number is accepted (for example 9812345678)
• 9 digits and 11 digits are rejected (boundary); exactly 10 digits is the boundary
• Letters, symbols, spaces, + and country code, zero at the start: follow the spec
• Paste with spaces or dashes: cleaned or rejected
• Empty field when it is required;...

Build a table of roles and actions, and test each cell.

• Admin: create, edit and delete users, change settings. Editor: edit content but cannot manage users. Viewer: read only
• A direct URL or API call to a forbidden action returns 403, even if the button is hidden in the UI
• A role change works without a new login...

• The first page loads with the expected number of items; Previous is disabled on the first page, and Next is disabled on the last
• Next, Previous, a page number, and First/Last go to the right page
• Exactly one page of data, zero results, N+1 items (the last page has one item)
• Changing the page size (10, 25, 50)...

• Pick a date from the calendar and by typing; the format matches the locale (DD/MM/YYYY vs MM/DD/YYYY)
• Boundaries: minimum and maximum allowed date, today, tomorrow, yesterday
• Invalid dates: 31 Feb, 30 Feb, 00/00/0000, letters, empty
• Leap day (29 Feb 2024 is valid, 29 Feb 2023 is invalid)
• Month and year...

• Logout goes to the login or home page and clears the session cookie or token
• The Back button does not show protected pages; pages ask for login again
• The token is not valid on the server after logout (call an API with the old token: 401)
• Logout in one tab logs out the other tabs; logout on one device vs on all...

• Star rating from 1 to 5, submit with and without text; the average rating and count update
• Rating 0, 6, or half-stars if not supported; empty review
• Only verified buyers can review; one review per user per product; edit and delete your own
• Review length limits, bad-word filter, HTML and links made safe -...

• Download for a chosen date range; the file opens correctly; the file name has the date range
• Contents match the screen and the database: totals, dates, currency format, order
• An empty range gives a file with only a header, or a message
• A very large range (100,000 rows): it finishes, or runs as a background job...

• The default value or placeholder shows; the list opens and closes; choosing an option updates the field
• All options are there, in the right order, with no repeats and with the right labels
• Keyboard: arrow keys, Enter, type to jump, Escape
• Search inside long dropdowns; multi-select adds and removes chips -...

• All fields valid: the address is saved; choosing a saved address fills the form
• Required fields: name, street, city, postcode, country, phone
• Postcode formats for each country; the state list changes with the country
• Phone: country code, letters, spaces and dashes
• Maximum lengths; apostrophes and non-English...

• An event triggers the notification once, with the right content, link, time and user
• Channels: push, email, SMS, in-app badge; each follows user preferences and opt-out
• Read and unread state, mark all as read, the badge count is right
• An offline device gets it later; old notifications are dropped
• Repeated...

• The balance equals the ledger or database value after deposits, withdrawals and pending transactions
• The difference between available and current balance when money is on hold
• After a transaction, the refresh updates within the SLA (agreed time)
• Currency format and rounding; a negative balance shows for an...

• Scan a valid code: the right merchant and amount show, and payment is confirmed
• Invalid, damaged, blurred, expired, or non-payment QR: show a clear message
• Low light, angle, distance; flashlight button; scan from a gallery image
• Camera permission denied or blocked: guide the user to settings
• Static QR with...

• Missing required fields, one at a time, and an empty body
• Wrong types (age as a string, email as a number) and nulls
• Invalid formats (bad email, bad date), very long strings, limit values
• Duplicate unique value (email already exists): 409
• Broken JSON, wrong Content-Type (415), unsupported method (405) -...

1. Open the browser dev tools and the Network tab. Compare the failing request with the Postman one (URL, method, headers, body, cookies).
2. Check the Console for CORS errors. Look at the preflight OPTIONS response.
3. Look for a missing or different Authorization, Content-Type, or cookie setting (SameSite,...

Call the API, then query the database for the same record and compare field by field (grey box testing).

Run one chained scenario and check the state at each step:

1. POST create: expect 201 and save the id
2. GET by id: 200 and the same data
3. PUT/PATCH update: 200/204, then GET shows the new values
4. GET list: the resource appears (and filters work)
5. DELETE: 204
6. GET again: 404
7. DELETE again: 404 or 204 (idempotent, no 500 error)

Find the documented limit (for example 100 requests per minute per key). Then:

1. Send requests in a loop until you pass the limit. Confirm 429 Too Many Requests.
2. Check the response headers: Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.
3. Wait for the time window to end and...

Use the API contract (OpenAPI/Swagger) and a mock server. Postman mock servers, WireMock, Mockoon or json-server return example responses. Testers can then write requests, checks and schema tests. Frontend developers can also work at the same time. Design test cases from the contract, including error responses. When the real service is ready, point the same collection at it by changing the baseUrl environment variable. Then fix any differences between the mock and the real behavior.

Cover the themes of the OWASP API Security Top 10:

• Broken object-level authorization (IDOR): change IDs in the path or body to read another user's data
• Broken authentication: weak tokens, no lockout, token reuse after logout
• Too much data in responses: password hashes or internal fields appear in the...

Measure response time (average and percentiles p90/p95/p99), throughput, error rate and resource use. Tools: JMeter, k6, Gatling, and Postman monitors for simple checks.

First compare the environments: base URL, versions, config and secrets. Then check the test data. Was it already created? Do tests depend on each other or on order? Do parallel runs share data?

• Upload allowed types with multipart/form-data: expect 201, and the stored file can be fetched
• Wrong type, fake extension, empty file, file over the size limit (and exactly at the limit)
• Missing file part, wrong field name, many files
• Auth is required, and a user cannot read other users' files
• File name...

A webhook is an HTTP callback. The system sends it to your URL when an event happens.

• Set up a receiver (webhook.site, a local server with a tunnel, or a mock) and trigger the event.
• Check the payload fields, the headers, and the signature (HMAC). The receiver uses the signature to trust the sender.
• The receiver...

Use mocks to test your own logic in a fast and reliable way. Mock these cases: a normal response, a slow response, error codes (4xx/5xx), a broken body, a timeout, and a partial outage. Add a small set of integration tests against the real sandbox to confirm the contract.

I would treat unstable tests as a defect, not as noise. First I find the category.

1. Collect evidence: rerun the failing test 20 times. Capture screenshots, page source, browser console and network logs. Note the pass rate for each environment.
2. Find the cause:
   • Timing: missing waits, animations, async rendering. Fix with explicit conditions, not sleeps.
   • Test data: shared accounts, order dependence, leftover state. Create data for each test and clean it up.
   • Locators: unstable ids, stale elements.
   • Environment: slow CI, shared test server, third-party calls. Mock external services.
   • A real race condition in the product. Report it as a bug.
3. Fix the root cause. Then put any still-unstable test in quarantine with a tag so it stops blocking the pipeline. Keep a list of quarantined tests.
4. Prevent it: run new tests many times before merging. Track the failure rate on a dashboard.

Automatic retries only hide the problem. I allow one retry at most while the root cause is being fixed.

What they are checking: Whether you have a clear method and do not hide unstable tests with retries

I compare the two environments and make the CI failure easy to see.

It means another element covers the target at the click point. Examples are a cookie banner, spinner, sticky header or modal.

The element is in the DOM but cannot take the action. It may be hidden, zero size, disabled, off-screen, or not yet drawn.

I would measure first. Then I would fix the biggest costs.

The assertion runs before the page finishes updating. So the test races the application.

You do not automate the CAPTCHA itself. You remove it from the test path.

I would recommend it when the team has unstable tests (tests that pass sometimes and fail other times) and slow suites on modern JavaScript apps. It also fits when the team needs built-in tracing, network mocking, and fast parallel runs, and is happy with Chromium, Firefox and WebKit only.

Log in once, save the cookies and storage to a file, and load that file in every test context. This removes the login screen from most tests and saves minutes.

// auth.setup.ts
import { test as setup, expect } from '@playwright/test';
setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.USER_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page).toHaveURL(/dashboard/);
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

In playwright.config.ts, define a setup project. Make the browser projects depend on it with use: { storageState: 'playwright/.auth/user.json' }. Add the .auth folder to .gitignore. For different roles, save one file per role. Keep one separate test that uses the real login form.

What they are checking: Whether you can speed up a suite by reusing login

Find the cause before you add retries.

Start with simple tools and move to detailed ones.

The locator matched more than one element. For actions like click or fill, Playwright will not guess which one you mean.

Use the API for setup and checking. Use the UI only for what you are testing. This makes tests faster and less fragile.

Keep the test apart from that dependency.

Use getByRole and getByLabel first. They test what users and assistive tools (like screen readers) see, and they also catch accessibility problems. Use getByTestId when:

• The element has no accessible role or name (a canvas, a chart, an icon button that cannot be named).
• The text changes with language or A/B experiments.
• Many identical elements need a stable handle.

Move step by step. Do not rewrite everything at once.

I would start from goals, not tools.

1. Clarify scope: app type (web, API, mobile), team skills, release speed, environments, and what must run on each pull request.
2. Choose a stack that fits the team. For example, Playwright with TypeScript, or Selenium with Java and TestNG. Add a runner and an assertion library.
3. Define layers: tests, page objects or API clients, shared helpers, config, and test data factories.
4. Build in common needs from day one. These are environment config, secrets handling, logging and a retry policy. Add reporting (Allure or HTML), screenshots and traces on failure, and tags for smoke and regression.
5. Set up CI with a fast smoke suite on each PR and a nightly regression. Run them in parallel in containers.
6. Write coding rules. Review tests like production code. Document how to add a test.
7. Start with a small suite of high-value tests. Prove it is stable, then grow it.

Success means people trust the results: few unstable tests (tests that pass sometimes and fail other times), quick feedback and low maintenance cost.

What they are checking: Whether you design for easy maintenance and team use

I measure, find the cause, fix and prevent.

1. Measure: track how often each test fails and passes from CI history. Mark the unstable tests. Do not guess.
2. Find the root cause. It may be timing and waiting problems, shared or old data, or tests that depend on order. It may be an unstable environment or third-party services. It may also be a real product bug that appears only sometimes.
3. Fix the cause: waits based on conditions, unique data per test, mocks for unstable services, stable locators, and isolation.
4. Quarantine (set aside) tests that cannot be fixed quickly, so the pipeline stays trusted. Give each one an owner and a deadline.
5. Prevent: review new tests. Run them many times (for example 20) before merging. Allow at most one retry.

If the team ignores unstable tests, people learn to ignore red builds.

What they are checking: Whether you treat unstable tests as an engineering problem

Use a clear structure: context, your role, actions, result.

I would use a risk-based plan, ordered by business impact.

I would use AI to reduce routine work. A person confirms the decisions.

I give structure, early wins and feedback.

Sign-off is a risk decision based on evidence. The team agrees the exit criteria (the conditions to release) in advance.

Explore in an organised way and report clearly.

Reduce how much the tests depend on UI details.

Win back trust first, then improve.

Use risk-based priorities.

I would test at several levels, because I do not control the other system.

I decide using criteria, then I run a short proof of concept.

Criteria: app type and browser needs, team language skills, stability and speed, parallel runs and CI fit, and debugging tools. Also community and long-term support, cost, and fit with existing reporting.

There is no single best tool. Pick by your constraints.

• Selenium: the widest language and browser support (including real Safari and old browsers). It has a huge ecosystem. But you build the waits, runner, reporting and parallel runs yourself.
• Cypress: the best developer experience for front-end teams. It has time-travel debugging, automatic retries and built-in network stubbing. Limits: JavaScript/TypeScript only, one tab per test, cross-origin needs cy.origin, and parallel runs are easiest with Cypress Cloud.
• Playwright: many languages (JS/TS, Python, Java, .NET). It supports Chromium, Firefox and WebKit, multiple tabs and contexts, built-in parallel runs and tracing, and free sharding (splitting tests across machines).

For a new JS/TS web project I would pick Playwright and Cypress as the two finalists. Then I would run a one-week trial on the three hardest flows (login with SSO, file upload, multi-tab). If the app needs multi-tab or multi-user flows, or testers who do not write JS, Playwright wins. If the team is front-end heavy and likes component testing and the interactive runner, Cypress is a good fit.

What they are checking: Decisions based on trade-offs and a test plan, not loyalty to one tool

A fixed cy.wait(5000) is a guess. It is too short on a slow day and wastes time on a fast day. cy.wait('@alias') waits exactly until one request finishes, then goes on at once.

Fix for the unstable table test (it passes sometimes and fails other times):

cy.intercept('GET', '/api/customers?*').as('getCustomers');
cy.visit('/customers');
cy.wait('@getCustomers');
cy.get('[data-cy="row"]').should('have.length.greaterThan', 0);

Steps I would take:

1. Find the request that fills the table. Give it an alias before you open the page.
2. Wait for the alias. Then assert on the DOM, so Cypress retries until the page has finished drawing.
3. If the page shows a spinner, assert cy.get('[data-cy=spinner]').should('not.exist').
4. Remove all fixed waits. Keep one only when there is no signal to watch, and add a comment to say why.

What they are checking: Replacing sleeps with waits that give the same result every time

Treat login as setup, not as the thing you test. Test the login form in one or two special specs. Skip it everywhere else.

1. Log in with cy.request to the auth endpoint, which sets the cookie. Or put the token in localStorage.
2. Wrap it in cy.session, so it is saved across tests and specs.
3. Add a validate step, so an expired session logs in again by itself.
4. Use one test user per role, with known data. Create them with a seed script or an API.

cy.session('admin', () => {
  cy.request('POST', '/api/auth', { user: 'admin', pass: Cypress.env('ADMIN_PASS') })
    .then(({ body }) => window.localStorage.setItem('token', body.token));
});
cy.visit('/dashboard');

This usually saves several seconds per test. It also removes a common cause of unstable tests. Keep passwords in environment variables or CI secrets, never in the repo.

What they are checking: Practical ways to make a test suite faster

Work from evidence, not guesses.

1. Reproduce: run without a visible browser, in the same browser and screen size as CI. Run the single test in a loop (--spec and a repeat loop) to measure how often it fails.
2. Read the artifacts: failure screenshot, video, Cypress Cloud or console logs, and the network log. Use the time-travel snapshots in cypress open.
3. Find the type of cause:
   • Timing: asserting before data loads, fixed waits, animations. Fix with cy.intercept aliases and a retrying .should.
   • Shared state: tests depend on order or leftover data. Make each test add and clean its own data.
   • Selectors: changing classes, duplicate elements, detached DOM.
   • Environment: slower CI, different data, third-party scripts.
4. Fix the root cause. Do not just add retries. Use retries: { runMode: 2 } only as a safety net, and track retried tests as unstable.
5. If a test cannot be fixed quickly, quarantine it (tag it, or skip it with a ticket). Then it does not block the pipeline.

What they are checking: A clear method for unstable tests, the most common QA automation question

Run without a visible browser, with a fixed Node and Cypress version and a built app.

I compare environment, timing and data, in that order.

Measure first, then remove waste.

No. Cypress controls a single tab and cannot switch to a new one. Common workarounds:

• Remove the target attribute so the link opens in the same tab:

Conditional testing means choosing a path based on the current DOM (if element exists, click it). It is discouraged because the DOM changes over time. Checking at one moment creates a race condition. The test then gives different results on different runs.

An incremental load processes only the records that are new or changed since the last run. It usually uses a watermark (a timestamp or id) or change data capture.

Trace the number backwards, layer by layer. Split the problem in half each time.

Matching counts only prove the number of rows. Move to row-level and column-level comparison.

Find what is duplicated, then find out why.

1. Define the duplicate. Is it the same business key, or a whole-row copy?

A green job does not prove the data is correct. Work outward from the symptom.

Migration testing checks that data moved from an old system to a new one is complete, correct and usable.

This is schema drift. Approach:

Do not pull everything into one place. Compare summaries first. Look closely only where they differ.

Timeliness: data must be available by the SLA time.

• Check the latest load time and compare it with now. Alert if the lag is above the limit.
• Test the job's start and end time against the time window with realistic volume.

You need a stable snapshot that you can compare against.

I follow a repeatable process:

1. Define goals: critical transactions, user counts and targets (for example p95 under 500 ms, error rate under 1 percent, 300 requests per second).
2. Build a workload model from production analytics: transaction mix, peak users and think times.
3. Prepare a production-like environment and test data. Make sure the load generator is not the bottleneck.
4. Script in JMeter: samplers, correlation, parameterisation, assertions and timers.
5. Run a smoke test, then baseline, load, stress and soak runs in non-GUI mode.
6. Monitor servers, application and database (CPU, memory, GC, connection pools, slow queries).
7. Analyse and report.

Metrics to report: throughput, average and p90/p95/p99 response times per transaction, error rate and error types, active users over time, and server resource use. Also add what you saw, the bottlenecks found, risks and advice.

What they are checking: Can you plan and report a complete test?

I work from the symptom down to the layer.

Plan capacity from the expected peak and test beyond it.

Low CPU with a throughput ceiling means the system is waiting, not computing. Likely causes:

• Connection pool exhausted (database or HTTP client), so threads queue.
• Thread pool or worker count too small, with requests waiting in the server.
• Lock contention, synchronised sections, or a single-threaded component. -...

That pattern suggests a memory leak or a cache with no size limit.

First, sort the errors into types.

Use Little's Law with the full user cycle.

• Requests per second per user = 1 / (response time + think time).
• Say the average response time is 0.4 s and think time is 3.6 s. A cycle is 4 s, so one user makes 0.25 requests per second.
• Users needed = 500 / 0.25 = 2000 virtual users.

Performance results are valid only if the environment is like production. This covers hardware, configuration, database size, network and third-party setup.

Test at several levels. The slowest service or dependency often limits the whole chain.

Stay calm, put numbers on the problem and give options.

Database testing checks that the data layer is correct and reliable:

• Data integrity: values are stored correctly, there are no orphan rows, and the FK, PK, unique, check and NOT NULL rules work
• Data mapping: actions in the UI or API change the right tables and columns. Check insert, update and delete with...

1. Do the action or open the page. Note the values you see and the record ID.
2. Query the database for the same record. Join the tables the page reads from.
3. Compare field by field. Allow for formatting: dates, currency, rounding, trimmed spaces, and status codes like 1 = Active.
4. Check counts and totals....

Compare the source and the target by key.

• Before: study the source data (row counts, nulls, duplicates, min and max, different values). Read the mapping document. Take a backup. Test on a copy.
• After: row counts match. Checksums or sums of number columns match. Sample records match field by field. Keys and relationships (FK) are intact, with no...

1. Reproduce the problem and measure it. Then run EXPLAIN (or EXPLAIN ANALYZE). It shows full table scans, row estimates and join order.
2. Add or fix indexes on columns used in WHERE, JOIN and ORDER BY. Put the columns of a composite index in the right order.
3. Avoid SELECT *, functions on indexed columns,...

SQL injection happens when user input is joined into a query as plain text. An attacker can then change what the query means. An example is ' OR '1'='1 in a login field.

Export or fetch the API data. Load it into a staging table, or compare IDs and key fields with a query on the database side. Check counts first. Then check totals (SUM(amount)). Then find row differences with LEFT JOIN ... IS NULL in both directions. Group the differences by type: missing, extra, or changed values. Put the checks in a script that runs after each deployment and reports mismatches. Look for timing causes (replication lag, caching) before you log a bug.

Take a snapshot before the fix. Save row counts, checksums or sums of key columns, and a copy of some rows. Apply the fix, run the scenario, then compare. Check these points:

• Only the rows you meant to change were changed. Compare by primary key and by timestamp columns like updated_at.
• Related tables and FK relations are still correct.
• Totals still add up.
• No new NULLs or duplicates appeared.
• Audit or history tables recorded the change.