QA interview questions and answers

Severity is how badly a defect hurts the system (technical impact). Priority is how soon it must be fixed (business urgency). Testers usually set severity. The product owner or manager sets priority.

A misspelled logo or brand name is the classic low severity, high priority case. Nothing breaks, but the business wants it fixed right away.

What they are checking: Can you explain technical impact and business urgency with examples

A defect moves through states from discovery to closure:

1. New: the tester logs the bug.
2. Assigned / Open: the lead or triager accepts it and gives it to a developer.
3. In progress: the developer works on a fix.
4. Fixed: the code change is done and merged.
5. Ready for retest: the fix is deployed to the test environment.
6. Retest: the tester checks the fix. If it passes, the bug becomes Verified and then Closed. If not, it is Reopened and goes back to the developer.

Side paths: Rejected / Not a bug, Duplicate, Deferred (fix moved to a later release), Cannot reproduce / Need info. Names differ per tool (Jira workflows can be changed), but the idea is the same.

What they are checking: Do you know the full flow, including the reopen, duplicate and deferred paths

SDLC (Software Development Life Cycle) covers the whole product journey: requirements, design, development, testing, deployment, maintenance. STLC (Software Testing Life Cycle) is the testing-only sequence inside it:

1. Requirement analysis
2. Test planning
3. Test case design and test data preparation
4. Test environment setup
5. Test execution and defect reporting
6. Test closure (reports, lessons learned)

QA is not only a phase after development. In a good process, QA reviews requirements early (called shift left). QA plans while design happens and tests during development. QA also supports the release and production monitoring.

What they are checking: Do you see QA as a continuous activity and not a final gate

Retesting confirms one known defect. Regression looks for unknown side effects.

What they are checking: Can you tell these four apart without mixing them up

Equivalence partitioning (ECP) splits inputs into groups that the system should treat the same. Then you test one value per group. Boundary value analysis (BVA) tests at the edges of those groups, where bugs are common.

Example: an age field accepts 18 to 60.

• Partitions: below 18 (invalid), 18 to 60 (valid), above 60 (invalid). ECP tests values like 10, 35, 70.
• BVA tests 17, 18, 19 and 59, 60, 61.

Together they give good coverage with few cases. You need 6 boundary tests plus one per partition, instead of 40+ values. Also add non-numeric, empty and negative inputs as separate invalid groups.

What they are checking: Can you pick real values and explain why the test count is smaller

Verification asks "Are we building the product right?" It checks work against the specification without running the final product. Examples are reviews, walkthroughs, inspections and static analysis. Validation asks "Are we building the right product?" It checks the running software against user needs. Examples are functional testing and UAT.

Example: reviewing the requirement document and design is verification. Running the app and confirming a customer can place an order is validation. Verification is usually earlier and cheaper. Validation needs software that can run.

What they are checking: Do you know the classic definition and can you give an example

A good report lets a developer reproduce and fix the bug without asking questions:

• Title: short and specific ("Checkout fails with 500 when coupon has lowercase code")
• Environment: build or version, OS, browser or device, URL, test data
• Preconditions and steps to reproduce (numbered)
• Expected result and actual result
• Severity and priority
• Evidence: screenshot, video, logs, HAR, API request and response
• Frequency: always, or sometimes (for example 3 of 5 tries)
• Reporter, assignee, linked requirement or test case

Write one bug per report, with no opinions. Also say what you already ruled out.

What they are checking: Can you write a report that a developer can act on

• Black box: the tester knows only the inputs and expected outputs, not the code. Examples: functional testing, UAT, BVA, ECP.
• White box: the tester uses knowledge of the code and its structure. Examples: unit tests, statement, branch and path coverage. Developers usually do this.
• Grey box: the tester has partial knowledge, such as the database schema, API contracts or architecture. This helps design better black box tests. Examples: API testing, checking the database after a UI action.

Rule of thumb: black box checks what the system does. White box checks how it does it. Grey box mixes both.

What they are checking: Basic classification of test techniques

Functional testing checks what the system does against the requirements. Examples: login works, a discount is applied, an email is sent. Non-functional testing checks how well it does it.

Non-functional examples:

• Performance: load, stress, spike, endurance
• Security: authentication, injection, access control
• Usability and accessibility
• Compatibility: browsers, devices, OS
• Reliability, recovery, scalability, localization

Functional asks "does the button submit the form". Non-functional asks "does it still submit when 5,000 users click at once".

What they are checking: Basic grouping with real examples

Exploratory testing means learning, designing tests and running them at the same time, without written scripts. The tester uses experience and curiosity. It is usually a time-boxed session (for example 60 minutes) with a charter such as "explore the cart with unusual quantities and coupons".

Use it when requirements are thin, a feature is new, or time is short. Also use it when scripted tests have stopped finding bugs. It adds to scripted tests. It does not replace them.

Good practice: take notes and record bugs with steps as you go. At the end, give a short debrief of what was covered, the risks and the open questions (this is called session-based test management).

What they are checking: Do you test with a plan and not at random

Regression testing checks old features again after a change, to make sure nothing broke. How to choose what to include:

• Key business flows (login, checkout, payment), always
• Areas touched by the change, and the modules that depend on them
• Areas with many past defects
• Recently fixed bugs

A test scenario is a high-level idea of what to test ("verify login"). A test case is a detailed instruction for one scenario that you can run. It has an ID, title, preconditions, steps, test data, expected result, actual result and status.

In agile, QA is part of the team. QA tests all the time inside each sprint, not at the end. In Scrum, a tester:

• Joins backlog refinement, asks questions and helps write acceptance criteria
• Writes test cases while developers build
• Tests stories as soon as they are done in the sprint
• Automates regression checks and looks after the CI suite
• Joins planning, daily stand-up, review and retrospective
• Owns the "tested" part of the definition of done

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

Page Object Model (POM) is a design pattern. Each page or component is a class that holds its locators and the actions on it (login(user, pass)). Tests only call those methods and hold the assertions.

A locator tells automation how to find an element. Common types: id, name, CSS selector, XPath, link text, role and text locators.

1. Make the tests run from a single command (npx playwright test, pytest, mvn test). Take config from environment variables.
2. Add a pipeline stage (GitHub Actions, GitLab CI, Jenkins). It installs dependencies and browsers, deploys or points to the test environment, and runs the suite headless.
3. Split the...

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...

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...

API testing sends requests straight to the application's interfaces (endpoints) and checks the responses. It checks the status code, headers, body, data correctness, speed and security. It skips the browser and tests the business logic layer.

A good rule is many API tests and fewer UI tests (the test pyramid).

What they are checking: Basic understanding and the value of API tests

Groups: 2xx success, 3xx redirect, 4xx client error, 5xx server error.

What they are checking: Do you know more than 200 and 404?

PUT replaces the whole resource with the data you send. Fields you leave out are reset or removed. It is idempotent (sending it twice gives the same result). PATCH changes only the fields you send. It is not always idempotent (for example "increase by 1").

PUT /users/7        {"name":"Asha","email":"[email protected]","phone":"98..."}   # full object
PATCH /users/7      {"phone":"98..."}                                    # one field

Test points:

• PUT with a missing field
• PATCH with an invalid field
• PUT on an ID that does not exist (404 or create, based on the design). Also check the response code, 200 or 204.

What they are checking: REST rules and what they mean for testing

Authentication answers "who are you?". It checks identity with a password, token, certificate or OTP. Authorization answers "what are you allowed to do?". It checks permissions or roles for the action.

Order: authenticate first, then authorize. In API terms, a missing or invalid token gives 401. A valid token without rights gives 403.

Test ideas: no token, expired token, changed token, and a valid user opening another user's resource (IDOR). Also test role-based actions (admin vs normal user).

What they are checking: Core security words and status codes

Safe means no change to data. Idempotent means calling it many times has the same effect as calling it once. To test it, send the same PUT or DELETE twice and check the final state. Send POST twice to see if it creates a duplicate.

What they are checking: REST basics