QA interview questions for freshers

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

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. Unit testing: one function or class. Developers do it. It is fast and isolated.
2. Integration testing: modules or services working together (API to database, service to service).
3. System testing: the complete application against the requirements, in an environment like production.
4. Acceptance testing (UAT): business users or the client confirm it meets their needs. Alpha (inside the company) and beta (real users) are forms of it.

Entry criteria are conditions that must be true before a test phase starts. Examples: requirements signed off, build deployed and passing the smoke test, test environment and data ready, test cases reviewed.

User Acceptance Testing (UAT) is the final check that the software meets business needs and is ready for release. The client, product owner, business analysts or end users do it. They work in a staging environment with realistic data and real business scenarios. QA usually prepares the environment, helps the users and logs defects. When UAT passes, the business gives its formal sign-off.

Typical fields:

• ID and title
• Module / requirement link
• Preconditions (user exists, logged out)
• Test data
• Steps (numbered, one action each)
• Expected result (clear and specific)
• Actual result, status (Pass / Fail / Blocked), tester, date
• Priority and type (positive or negative)

• Load: normal and peak user volume, to check response times and throughput.
• Stress: load above capacity, to find the breaking point and see how the system fails and recovers.
• Spike: a sudden sharp rise and drop in users (for example a flash sale).
• Endurance / soak: steady load for hours or days, to find memory leaks and used-up resources.

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.

QA is about process and prevention. QC is about the product and finding defects.

Test data is the input and the system state that a test needs. Prepare it to cover valid, invalid, boundary and empty cases, and different user roles. Sources: hand-built sets, scripts or API calls that create records before the test, anonymized copies of production data, and generators. Keep the data separate for each test. Never use real personal data. Clean up or reset it afterward. Write it down with the test case so runs can be repeated.

Pseudocode: create an empty result. Walk the input from the last character to the first and add each one to the result. Then return the result. Or swap characters from both ends, moving toward the middle.

Name the tools you have really used and explain the workflow, not only the product names. Common ones are Jira with Zephyr or Xray, TestRail, Azure Test Plans, and a spreadsheet for small teams.

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

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

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.

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.

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

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

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

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

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

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

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

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

• Status code: correct for success and for failure
• Response body: fields, types, values, nulls, schema, and data that matches the DB
• Headers: Content-Type, Cache-Control, CORS, security headers
• Validation: required fields, types, lengths, limits, invalid JSON
• Negative cases: missing or wrong auth, wrong method, bad ID, 404 and 400 messages
• Authorization: roles, access to other users' data
• Business logic and state changes (create then read, update then check, delete then 404)
• Idempotency and concurrency
• Performance: response time, load, rate limiting
• Security: injection, leaking sensitive data, HTTPS
• Error handling: no stack traces, same error format everywhere
• Pagination, sorting, filtering

What they are checking: A full checklist in your head

Postman is a tool to design, send, test and document HTTP requests. A collection is a saved group of requests, optionally in folders. The requests share auth, variables, pre-request scripts and tests. You can run a collection in order with the Collection Runner, and use data files to repeat it with many inputs. You can export it as JSON, share it with a team, and run it in CI with Newman. A normal layout has one folder per module (Auth, Users, Orders). A login request saves a token for the other requests.

What they are checking: Tool basics

Variables help you avoid fixed values. Scopes go from widest to narrowest: global, collection, environment, data (runner file) and local. The narrowest scope wins.

An environment is a set of variables for one target, for example dev, staging, prod. Each has its own baseUrl and login details. You can switch environments without editing requests.

Use: {{baseUrl}}/users/{{userId}}.

Set from scripts:

pm.environment.set("token", pm.response.json().token);
pm.collectionVariables.set("userId", 42);

Never commit real secrets. Use the "secret" variable type or the vault.

What they are checking: Reusable collections

Write JavaScript in the Tests tab (it runs after the response). It uses pm.test and Chai-style pm.expect.

pm.test("Status is 200", () => pm.response.to.have.status(200));

pm.test("Response time under 500 ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("Content-Type is JSON", () => {
  pm.response.to.have.header("Content-Type", /application\/json/);
});

const body = pm.response.json();
pm.test("Has expected fields", () => {
  pm.expect(body).to.have.property("id");
  pm.expect(body.email).to.be.a("string").and.include("@");
  pm.expect(body.items).to.be.an("array").that.is.not.empty;
});

Put one check in each pm.test, so a failure is easy to read.

What they are checking: Can you write assertions without help?

Save the token from the login response, then reuse it through a variable.

Login request, Tests tab:

const res = pm.response.json();
pm.environment.set("token", res.access_token);

Other requests: open the Authorization tab, choose Bearer Token, and use the value {{token}}. Or set it once at collection level so every request inherits it.

A pre-request script on the collection can get a new token when the old one expires. To control the order in a run, use pm.execution.setNextRequest("Get order") (or postman.setNextRequest in older versions).

What they are checking: How data moves between calls

401 Unauthorized (really "unauthenticated") means the server does not know who you are. The token is missing, invalid or expired. The response often includes WWW-Authenticate. 403 Forbidden means the server knows who you are, but you have no permission for this resource.

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)

OpenAPI (formerly Swagger) is a standard way to describe a REST API in a form a machine can read. It lists endpoints, methods, parameters, request and response schemas, and auth. Swagger UI shows it as live documentation where you can try calls.

• Path parameter: points to one resource: /users/42
• Query parameter: filters, sorts and pages: /users?role=admin&page=2
• Request body: the data to create or update, usually JSON, with POST/PUT/PATCH
• Headers: extra information such as auth and content type

• 200 OK: success with a body (GET, or PUT/PATCH that returns the updated resource).
• 201 Created: a new resource was created (POST). It should include a Location header or the created object.
• 204 No Content: success with no body (DELETE, or an update that returns nothing).

500 Internal Server Error means the server failed in an unexpected way. Causes are an unhandled exception, bad data or a failing dependency. If client input triggers it, it is always a bug, because invalid input should give a 4xx code.

A 200 does not mean the answer is right. Also check:

• the response body (fields, types, values, nulls)
• headers and response time
• that data was saved correctly in the database
• side effects (emails, events, other services)
• that no sensitive data is exposed
• that it matches the documentation

Check for these points:

• A steady, structured format (for example { "code": "INVALID_EMAIL", "message": "...", "field": "email" }).
• A message people can read. It should help, but it must be safe.
• The right status code.
• No stack trace, SQL, file paths or internal hostnames.
• The same format on all endpoints.
• Translations, if the API supports them.

Selenium WebDriver is an API that controls a real browser from test code. Your script never talks to the browser directly. It goes through a driver.

Flow:

• Test code (Java, Python, C# and others) uses the language bindings.
• The bindings send commands as HTTP requests using the W3C WebDriver protocol.
• A browser driver (chromedriver, geckodriver, msedgedriver) receives them.
• The driver controls the real browser and sends back a JSON response (success, element, or error).

Since Selenium 4, the protocol is the W3C standard. There is no JSON Wire translation layer, so browsers behave more the same way.

What they are checking: Whether you understand the full chain of client, protocol, driver and browser, not just the API

Selenium 4 moved fully to the W3C WebDriver standard. It also added these features:

• Relative locators (above, below, toLeftOf, toRightOf, near).
• newWindow(WindowType.TAB / WINDOW) opens and switches to a new tab or window in one call.
• Chrome DevTools Protocol access (network interception, console logs, geolocation, performance) for Chromium browsers.
• A redesigned Selenium Grid with Hub, Node, Router, Distributor, Session Map and Event Bus. It also has Docker support and better monitoring.
• Element screenshots, and full page screenshots in Firefox.
• Selenium Manager (4.6 and later) downloads the matching drivers for you.
• A better Actions API and updated documentation.

What they are checking: Whether you follow changes in the tool's versions and know what is really new

Selenium has eight strategies: id, name, className, tagName, linkText, partialLinkText, CSS selector and XPath.

My order of preference:

• id when it is unique and stable. It is the fastest and the clearest.
• A dedicated test attribute such as data-testid through CSS ([data-testid='submit']). It does not change when the styling changes.
• CSS selectors for most other cases. They are fast and easy to read.
• XPath only when I need text matching, parent or sibling search, or something CSS cannot do.

I avoid long absolute paths, auto-generated ids and class names that come from a styling framework.

What they are checking: Whether you pick locators for stability and easy maintenance, not out of habit

Both find elements. They differ in power and speed.

Use CSS by default. Use XPath when you need to go to a parent or match visible text.

What they are checking: Whether you can explain your choice with real trade-offs

• Implicit wait: a global timeout. For any element search, the driver keeps trying up to that time before it throws NoSuchElementException. Set it once with driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)).
• Explicit wait: WebDriverWait with an ExpectedCondition for one specific case (visible, clickable, text present). It works only where you write it.
• Fluent wait: an explicit wait with your own polling interval and a list of exceptions to ignore.

Best practice: use explicit waits to sync with the page. Do not mix them with implicit waits, because the total wait time becomes hard to predict.

What they are checking: Whether you can sync tests reliably and know the risk of mixing waits

It means the element you hold is no longer attached to the DOM. The page may have re-rendered, moved to another page, or JavaScript replaced the node. The old reference is dead, even if an identical element is visible.

Fixes:

• Find the element again just before you use it. Do not keep it for a long time.
• Wait for the condition that shows the refresh is done, for example ExpectedConditions.refreshed(ExpectedConditions.elementToBeClickable(locator)).
• Store locators (By) instead of WebElement objects. Page Object Model with lazy lookups does this.
• As a last resort, add a small retry. Do not add a blanket sleep.

What they are checking: Whether you understand why it happens, not only how to retry

Page Object Model (POM) puts each page or component into a class. The class gives actions and hides locators. Tests call methods like login_page.sign_in(user, pwd) and never use locators directly.

Benefits:

• When the UI changes, you edit one class, not 50 tests.
• Tests read like business steps.
• Less repeated code and better reuse.

class LoginPage:
    USER = (By.ID, "username")
    PWD = (By.ID, "password")
    SUBMIT = (By.CSS_SELECTOR, "button[type=submit]")
    def __init__(self, driver): self.driver = driver
    def sign_in(self, user, pwd):
        self.driver.find_element(*self.USER).send_keys(user)
        self.driver.find_element(*self.PWD).send_keys(pwd)
        self.driver.find_element(*self.SUBMIT).click()

Keep assertions in tests, not in page objects.

What they are checking: Whether you can design test code that is easy to maintain

Avoid the attribute that changes. Use something stable instead.

• Partial match: //input[starts-with(@id,'user_')], contains(@id,'email'), or CSS input[id^='user_'], [id$='_email'], [id*='email'].
• Use a stable parent, label or text: //label[text()='Email']/following-sibling::input.
• Use test attributes (data-testid) and ask developers to add them.
• Use aria-label, name, or placeholder when they are stable.
• Combine conditions: //button[contains(@class,'primary') and normalize-space()='Pay'].

Always find the element again after the page updates. Wait for the element to be present.

What they are checking: Whether you can write locators that do not break easily

import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    URL = "https://the-internet.herokuapp.com/login"
    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)
    def open(self):
        self.driver.get(self.URL)
        return self
    def login(self, user, pwd):
        self.driver.find_element(By.ID, "username").send_keys(user)
        self.driver.find_element(By.ID, "password").send_keys(pwd)
        self.driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
    def flash(self):
        return self.wait.until(EC.visibility_of_element_located((By.ID, "flash"))).text

@pytest.fixture
def driver():
    d = webdriver.Chrome()
    yield d
    d.quit()

def test_valid_login(driver):
    page = LoginPage(driver).open()
    page.login("tomsmith", "SuperSecretPassword!")
    assert "You logged into a secure area" in page.flash()

def test_invalid_login(driver):
    page = LoginPage(driver).open()
    page.login("tomsmith", "wrong")
    assert "Your password is invalid" in page.flash()

What they are checking: Whether you can write a clean test that runs, during a live exercise

Absolute XPath starts at the root with a single slash and lists every node, for example /html/body/div[2]/form/input[1]. Any small layout change breaks it.

A fixed sleep waits the full time even when the page is ready. It still fails when the page is slower than the sleep. That makes test suites both slow and unstable (tests that pass sometimes and fail other times).

For a standard <select> element, use the Select class:

Switch to the alert and act on it. After that, control goes back to the page automatically:

The driver cannot see elements inside an iframe until you switch context.

Each window has a handle. Save the original handle, open the new window, and wait for it. Then switch to it, and switch back at the end.

• findElement returns the first matching WebElement. It throws NoSuchElementException if there is none.
• findElements returns a list of all matches. If nothing matches, it returns an empty list and throws no exception.

• close() closes only the current window or tab that the driver is focused on.
• quit() closes all windows and ends the driver session. It also shuts down the driver process.

Order from outermost to innermost: @BeforeSuite -> @BeforeTest -> @BeforeClass -> @BeforeMethod -> @Test -> @AfterMethod -> @AfterClass -> @AfterTest -> @AfterSuite.

Useful attributes of @Test: priority, dependsOnMethods, enabled, groups, invocationCount, retryAnalyzer, dataProvider.

Both open a URL and wait for the page load event. The difference is that navigate() returns a Navigation object. It also supports back(), forward() and refresh(). get() only loads a URL. get() is simpler for the first load. Use navigate() when you need browser history actions in the same flow.

• It works with web browsers only. For native desktop or mobile apps, you need Appium.
• It has no built-in reporting, test runner or parallel framework. You add them yourself.
• It cannot directly automate CAPTCHAs, OS-level dialogs, or barcode and OTP flows.
• It has no native image comparison.
• Dynamic pages need explicit waits. So it needs more sync code than newer tools like Playwright.
• Driver and browser versions must match (Selenium Manager reduces this problem).

Playwright is a free, open source tool from Microsoft for end-to-end testing. One API controls Chromium, Firefox and WebKit. You can write tests in TypeScript, JavaScript, Python, Java and .NET. It also comes with its own test runner (@playwright/test).

Reasons teams pick it:

• Auto-waiting: it checks the element is ready before acting, so you rarely need explicit waits.
• Isolated browser contexts make tests fast and independent.
• It has built-in parallel runs, retries, HTML reports, a trace viewer, codegen and network mocking.
• Web-first assertions retry until they pass or time out.
• It handles multiple tabs, iframes, shadow DOM and API testing in the same tool.

What they are checking: Whether you can explain the tool with clear, real advantages

Choose Playwright for modern web apps. Choose Selenium when you need many languages or already have a large suite. Choose Cypress for JavaScript teams who like its interactive runner.

What they are checking: Whether you can compare tools in a fair way

Prefer user-facing locators. They find elements the way people do:

• page.getByRole('button', { name: 'Sign in' }) (the best default, and it also checks accessibility)
• page.getByLabel('Email'), getByPlaceholder, getByText, getByAltText, getByTitle
• page.getByTestId('submit') (uses data-testid, and you can change the attribute name)
• page.locator('css=...') or XPath only as a last choice.

You can chain and filter: page.getByRole('listitem').filter({ hasText: 'Pro plan' }).getByRole('button', { name: 'Buy' }). Locators are lazy. They find the element again on every action. So they do not go stale like Selenium elements.

What they are checking: Whether you pick locators that do not break easily

Before an action such as click, Playwright checks that the element is attached, visible, stable (not moving), not covered and enabled. It retries until all of these are true or the action timeout (30 seconds by default) ends.

So you write await page.getByRole('button', { name: 'Save' }).click(); and add no sleeps or explicit waits. Assertions such as expect(locator).toBeVisible() also retry. You still wait yourself for things that are not elements, for example await page.waitForResponse(...) or await page.waitForURL('**/dashboard').

What they are checking: Whether you understand the checks Playwright runs before an action

import { test, expect } from '@playwright/test';

test.describe('login', () => {
  test('valid user reaches the secure area', async ({ page }) => {
    await page.goto('https://the-internet.herokuapp.com/login');
    await page.getByLabel('Username').fill('tomsmith');
    await page.getByLabel('Password').fill('SuperSecretPassword!');
    await page.getByRole('button', { name: 'Login' }).click();

    await expect(page).toHaveURL(/\/secure/);
    await expect(page.locator('#flash')).toContainText('You logged into a secure area');
  });

  test('invalid password shows an error', async ({ page }) => {
    await page.goto('https://the-internet.herokuapp.com/login');
    await page.getByLabel('Username').fill('tomsmith');
    await page.getByLabel('Password').fill('wrong');
    await page.getByRole('button', { name: 'Login' }).click();
    await expect(page.locator('#flash')).toContainText('Your password is invalid');
  });
});

Run it with npx playwright test. Each test gets a fresh browser context, so you need no cleanup.

What they are checking: Whether you can write a clean test that runs, live in the interview

Fixtures give tests the objects they need for setup and cleanup. A test gets a fixture by name, and it is created only when a test asks for it. Built-in ones include page, context, browser and request.

Here is a custom fixture that gives the test a login page object:

import { test as base, expect } from '@playwright/test';
import { LoginPage } from './pages/LoginPage';

type Fixtures = { loginPage: LoginPage };

export const test = base.extend<Fixtures>({
  loginPage: async ({ page }, use) => {
    const lp = new LoginPage(page);
    await lp.goto();
    await use(lp);      // test runs here
    // teardown code goes after use()
  },
});
export { expect };

Fixtures replace beforeEach and afterEach hooks. They are typed, can depend on each other, and are created only when needed. You can scope them per test or per worker.

What they are checking: Whether you know how fixtures differ from hooks

Make one class per page. The class holds the Page, defines locators as properties and offers actions. Then tests read like steps.

import { Page, Locator, expect } from '@playwright/test';

export class LoginPage {
  readonly username: Locator;
  readonly password: Locator;
  readonly submit: Locator;
  constructor(private page: Page) {
    this.username = page.getByLabel('Username');
    this.password = page.getByLabel('Password');
    this.submit = page.getByRole('button', { name: 'Login' });
  }
  async goto() { await this.page.goto('/login'); }
  async login(u: string, p: string) {
    await this.username.fill(u);
    await this.password.fill(p);
    await this.submit.click();
  }
}

Give the page object to tests through a fixture. Set baseURL in the config. Keep assertions in the tests, or in clearly named expect... helpers. Locators are lazy, so it is safe to define them in the constructor.

What they are checking: Whether you can structure test code that is easy to maintain

These are expect(locator) assertions that retry on their own until the condition is true or the timeout (5 seconds by default) ends.

• Browser: one browser instance (for example a Chromium process). It is slow to start and is shared by a worker.
• BrowserContext: an isolated, incognito-like profile inside a browser. It has its own cookies, storage and cache. It takes only milliseconds to create.
• Page: a single tab inside a context. A context can hold many pages.

Each test runs in its own BrowserContext with clean cookies, local storage, session storage and cache. Nothing carries over between tests. So they can run in any order and at the same time.

• testDir, timeout, expect.timeout: where tests live and the time limits.
• fullyParallel, workers, retries: speed and stability.
• reporter: html, list, junit, json, or several.
• use: shared options such as baseURL, trace, screenshot, video, viewport, locale, storageState,...

Make tests from an array in a loop. Each turn of the loop adds its own test with a unique title.

Add entries to projects in the config. Every test runs once for each project.

page.waitForTimeout(ms) is a fixed sleep. It is slow and still makes tests unstable. Playwright's own docs discourage it, except while debugging.

Hooks run setup and cleanup around tests, inside a describe block or a file. They are test.beforeAll, test.beforeEach, test.afterEach and test.afterAll.

npx playwright codegen <url> opens a browser and a recorder window. The recorder writes test code as you click, and it uses role-based locators. You can also use it to pick locators and assertions.

Start waiting for the event before the action that causes it.

Upload: await page.getByLabel('Upload').setInputFiles('files/report.pdf');. You can also pass an array, or [] to clear the files. If a button opens a file chooser and there is no input, listen for filechooser.

Register a handler before the action. If no listener exists, Playwright closes the dialog on its own.

Put tags in the title (or use the tag option) and filter with --grep.

There are several layers:

• Test timeout: 30 seconds by default for the whole test (timeout).
• Expect timeout: 5 seconds for each assertion (expect.timeout).
• Action timeout: no limit by default, except the test timeout (actionTimeout).
• Navigation timeout: for goto and page loads (navigationTimeout).

Playwright has bindings for TypeScript/JavaScript, Python, Java and .NET. The Node version includes @playwright/test. It is a full test runner with fixtures, parallel runs, retries, reporters, snapshots and a UI mode. In Python you use pytest-playwright. In Java and .NET you pair it with JUnit, NUnit or MSTest.

A test automation framework is a set of structure, libraries, rules and tools. It makes automated tests easy to write, run, report and maintain. It is more than a pile of scripts.

Common types:

• Linear (record and playback): simple, but no reuse and hard to maintain.
• Modular: tests are built from reusable page or function modules.
• Data-driven: the same test logic runs with many rows of data from files.
• Keyword-driven: test steps are written as keywords (login, search) that map to code.
• Hybrid: a mix of these. Most real projects use this.
• BDD: scenarios are written in Gherkin (Cucumber, SpecFlow, Behave) and linked to step code.

What they are checking: Whether you see a framework as a design, not just a set of tools

Data-driven testing means fewer copied scripts. Keyword-driven testing lets manual testers help, but you must maintain the extra layer that turns keywords into code. Hybrid is the practical choice. Use page objects for structure, parametrised data for coverage, and readable test names.

What they are checking: Whether you can tell the approaches apart and pick one

Behaviour-driven development (BDD) describes behaviour in plain language. Product, QA and developers all share it. Cucumber runs Gherkin scenarios. It matches each line to a step definition in code.

Feature: Login
  Scenario: Valid user signs in
    Given the user is on the login page
    When they sign in with valid credentials
    Then they see the dashboard

from behave import given, when, then   # same idea as Cucumber step definitions
@when("they sign in with valid credentials")
def step(context):
    context.login_page.sign_in("demo", "demo-pass")

Benefits: the scenarios work as living documentation, and everyone understands the feature the same way. Costs: you maintain an extra layer. It also fits poorly if business people never read the files. Keep scenarios short and about intent, not click-by-click.

What they are checking: Whether you understand the value and the cost of BDD

The test pyramid says to have many fast unit tests at the base. Have fewer integration or API tests in the middle. Have few UI end-to-end tests at the top.

• Unit tests: take milliseconds, show exactly what failed, and are cheap to maintain.
• API / integration tests: check business rules and contracts without a browser.
• UI tests: the slowest and the easiest to break. Keep them for the most important user journeys.

An upside-down pyramid (mostly UI tests) gives slow pipelines, unstable builds and high maintenance cost. Check each thing at the lowest level that can catch the bug.

What they are checking: Whether you understand cost and speed of feedback

Automate tests that repeat often, are stable, matter a lot and give the same result every time:

• Regression and smoke checks that run on every build.
• Data-heavy checks with many input combinations.
• API and integration tests, and cross-browser checks of key flows.
• Anything that needs exact timing or large volumes that people cannot do.

Do not automate:

• Features that still change every day.
• One-off tests and exploratory testing.
• Usability, look-and-feel checks and anything that needs human judgement.
• Tests that cost more to maintain than the time they save.

A simple rule: automate when the test will run many times, rarely changes, and a failure matters.

What they are checking: Whether you think about return on effort (ROI)

Check more than the status code.

Severity is the technical impact of the defect (crash, data loss, cosmetic). Priority is how soon it should be fixed. That is a business decision. A typo in the company name on the home page is low severity but high priority. A crash in a rarely used admin screen is high severity but may be low priority.

Group by job, so people know where code goes:

Reports should quickly answer "what failed, why, and where".

Explore in an organised way and report clearly.

Swap the characters from both ends. Or build the result backwards.

Pseudocode:

A test strategy is a high-level document that lasts a long time. It describes the overall approach: test levels, types, tools, environments, automation approach, risk handling, metrics and roles. It applies across projects or the whole product.

Compare two things. One is the cost of building and maintaining automation. The other is the manual effort and bug cost that it removes.

Simple view: savings = (manual run time x number of runs) minus (build time + maintenance time).

Core commands: git clone, git status, git add, git commit, git pull --rebase, git push, git branch. More: git switch -c feature/x, git merge, git diff, git log --oneline, git stash.

Good logging lets you find the cause of a failure without running the test again.

Keep the code the same in every environment. Change only the configuration.

Cypress is a JavaScript/TypeScript tool for end-to-end and component testing. It runs tests inside the browser, next to the app you are testing.

• Used for UI end-to-end tests, API checks (cy.request), and component tests for React, Vue, Angular and Svelte.
• It comes with its own test runner (a time-travel UI with snapshots), an assertion library (Chai, plus Sinon and jQuery helpers) and automatic waiting.
• It runs on Node.js. Tests are written only in JavaScript or TypeScript.
• It runs without a visible browser in CI with npx cypress run. It runs with a visual window using npx cypress open.

Typical use: a team tests login, checkout or search flows on every pull request. They get screenshots and videos when a test fails.

What they are checking: Whether you know what the tool covers, beyond 'a UI automation tool'

The main difference is where the test code runs. Selenium controls the browser from outside, through the WebDriver protocol. Cypress runs inside the browser, in the same loop as the app.

Choose Cypress for fast, developer-friendly front-end testing of a web app. Choose Selenium when you need many languages, real cross-browser coverage or multi-window flows.

What they are checking: Whether you can compare by architecture and trade-offs, not just say 'Cypress is faster'

Prefer selectors that survive UI changes and show intent.

• Best: special test attributes such as data-cy, data-testid or data-test.
• Good: accessible roles and text, using cy.contains('button', 'Sign in') (or testing-library's findByRole through @testing-library/cypress).
• Avoid: long CSS or XPath chains (div > div:nth-child(3) > span). Also avoid class names made up by CSS-in-JS tools, and indexes that depend on order.

cy.get('[data-cy="email"]').type('[email protected]');

Agree on the data-cy rule with developers. Add the attributes during code review. The official Cypress best practices guide suggests this. Tests then do not break when the styling changes.

What they are checking: Whether you think about keeping tests easy to maintain

A login test with stable selectors, a stubbed failure, and an assertion on the result.

cy.request() sends an HTTP request straight from Cypress, without the browser UI. Use it for API tests, for setting up and removing test data, and for fast login. It shares cookies with the browser.

Each command in a chain passes a subject to the next command. Take cy.get('.row').find('a').click(). get gives the matched row elements. find searches inside them and gives the links. click acts on that subject.

Main defaults:

• defaultCommandTimeout: 4000 ms (queries and assertions)
• pageLoadTimeout: 60000 ms (cy.visit)
• requestTimeout: 5000 ms (waiting for a request in cy.wait('@alias'))
• responseTimeout: 30000 ms (cy.request and waiting for a response)
• execTimeout and taskTimeout: 60000 ms

.should() retries. .then() runs once.

• .should('have.text', 'Paid') or .should(($el) => { ... }) re-runs the earlier query and the assertion until it passes or times out.
• .then(($el) => { expect(...) }) gets the subject at that moment. If the page has not updated yet, the assertion fails at once.

• cy.get(selector) searches the whole document (or the current root) and starts a chain.
• .find(selector) searches only inside the children of the previous subject. It needs a subject.
• cy.contains(text) finds an element by its text. It prefers the deepest element that holds the text. cy.contains(selector, text) narrows it by selector.

Fixtures are fixed data files (usually JSON) in cypress/fixtures. They keep test data out of specs.

Add the command in cypress/support/commands.ts. Also declare its type, so the editor and compiler know about it.

Test retries run a failed test again by themselves, a set number of times, before reporting failure.

Cypress uses the Mocha structure: describe, it, and the hooks before, beforeEach, afterEach, after.

Upload: use .selectFile() (built in since Cypress 9.3).

Before actions like click or type, Cypress waits until the element is:

• visible (not display: none or zero size)
• not disabled
• not detached from the DOM
• not covered by another element at its click point
• scrolled into view and not moving

Honest limits I would name:

After npm install cypress --save-dev and the first npx cypress open, you get:

Cypress accepts alert and confirm dialogs by itself (it clicks OK). It also listens to them through window events. So you check the message instead of clicking.

• Screenshots: taken by themselves when a test fails in cypress run. Add your own with cy.screenshot().
• Videos: turn them on with video: true in the config (off by default in recent versions). They are useful to attach when a test fails.
• Reports: use Mocha reporters. Common choices are mochawesome (HTML/JSON) and cypress-junit-reporter, or the built-in junit reporter for CI dashboards.

ETL testing checks that data is pulled from the sources correctly. It also checks that the business rules are applied and that all the data reaches the target. The target is usually a data warehouse or a data lake.

It is needed because:

• Silent data errors (missing rows, wrong joins, cut-off text) do not crash anything. They still give wrong reports and wrong decisions.
• The transformation logic is complex and changes often.
• Data volumes and sources keep changing, so manual spot checks miss problems.

Main checks: record counts, data completeness, transformation correctness, data type and format, duplicates, referential integrity (keys match between tables), load speed, and error handling. The test basis is the source-to-target mapping document and the business rules.

What they are checking: A clear definition linked to business impact.

A typical flow:

1. Understand requirements: mapping document, business rules, source and target schemas, and how often the load runs.
2. Plan and design tests: scope, test cases for each rule, test data, environments, and entry/exit criteria.
3. Prepare test data: normal, boundary, null, duplicate and invalid records.
4. Source checks: profile the source data. Confirm counts and quality before the run.
5. Run the ETL and check the logs, rejected rows and job status.
6. Validate: counts, source-to-target comparison, transformation logic, duplicates, integrity, data types and totals.
7. Report defects with the query, sample rows, and expected vs actual result.
8. Retest and regression: after each fix and each release. Include incremental runs and re-runs.
9. Sign-off: a summary of coverage and open risks.

What they are checking: Can you explain a process that can be repeated?

Group by customer. Then filter the groups with HAVING. Do not use WHERE, because it filters rows before grouping.

SELECT c.customer_id,
       c.name,
       COUNT(o.order_id)   AS order_count,
       SUM(o.amount)       AS total_amount
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.name
HAVING COUNT(o.order_id) > 1
ORDER BY total_amount DESC;

Points to say aloud:

• JOIN (inner) drops customers with no orders. Use LEFT JOIN if you also need them with a zero count.
• Every selected column that is not aggregated must be in GROUP BY.
• COUNT(o.order_id) ignores NULLs. COUNT(*) counts all rows.

What they are checking: This is the basic live SQL task that many candidates fail.

Six common dimensions:

Automate them as SQL checks or rules in a tool (Great Expectations, dbt tests). Run them on every load, with thresholds and alerts.

What they are checking: Do you know the terms, and can you turn them into tests?

Run count queries on both sides. Use the same filters that the ETL applies.

-- source
SELECT COUNT(*) FROM src.orders WHERE order_date >= DATE '2026-01-01';
-- target
SELECT COUNT(*) FROM dw.fact_orders WHERE order_date >= DATE '2026-01-01';

If the counts differ, investigate:

• Missing rows: find them with EXCEPT / LEFT JOIN ... WHERE t.key IS NULL.
• Extra rows: duplicates from a bad join, or rows not removed after a delete in the source.
• Legitimate filtering: rejects, deduplication, status filters. Check the reject table and the mapping rules.
• Timing: the source changed after the extract. Compare at the same cut-off time.

A matching count is needed but not enough. It can hide one missing row and one duplicated row.

What they are checking: Do you understand the limits of count checks?

Group by the columns that define a duplicate. Keep the groups with more than one row.

SELECT email, COUNT(*) AS cnt
FROM customers
GROUP BY email
HAVING COUNT(*) > 1;

To see the full duplicate rows, use a window function:

SELECT *
FROM (
  SELECT c.*,
         COUNT(*) OVER (PARTITION BY email) AS cnt
  FROM customers c
) t
WHERE cnt > 1
ORDER BY email;

Say what counts as a duplicate: the primary key, or a business key (email, or customer_id + order_date). A table can have no duplicate primary keys and still have duplicate business records with different surrogate ids (system-made ids).

What they are checking: The live query that candidates fail most often.

Test for NULLs with IS NULL / IS NOT NULL. = NULL never matches.

SELECT COUNT(*) FROM dw.dim_customer WHERE email IS NULL;

Behaviour to know:

• Any comparison with NULL gives unknown. So col <> 'X' leaves out NULL rows too.
• COUNT(col) skips NULLs. COUNT(*) counts all rows.
• SUM and AVG ignore NULLs. AVG divides by the count of non-NULL values.
• NULL = NULL is not true. Use IS NOT DISTINCT FROM or COALESCE when you compare source and target.
• NOT IN with a subquery that returns a NULL returns no rows. Prefer NOT EXISTS.

Check against the mapping. Mandatory columns must have zero NULLs. Optional columns should show NULL (not an empty string or 'N/A') exactly as the rule says.

What they are checking: Do you know the classic SQL traps?

Two standard SQL approaches. Both use the business key.

-- Anti-join
SELECT s.order_id
FROM src.orders s
LEFT JOIN dw.fact_orders t ON t.order_id = s.order_id
WHERE t.order_id IS NULL;

-- Set difference (EXCEPT in PostgreSQL/SQL Server, MINUS in Oracle)
SELECT order_id FROM src.orders
EXCEPT
SELECT order_id FROM dw.fact_orders;

Swap the tables to find extra rows in the target. If the databases are on different servers, load the keys into a staging table. Or use a comparison tool or script (pandas merge with indicator=True). Check the reject table before you raise a defect. The row may have been rejected on purpose.

What they are checking: A basic reconciliation query.

SCDs describe how a dimension handles changes in its attributes over time.

Check that what users see is right, from the data to the display.

• INNER JOIN: only rows that match on both sides.
• LEFT JOIN: all rows from the left table, and the matched rows from the right (NULLs where there is no match).
• FULL OUTER JOIN: all rows from both tables, with NULLs where there is no match.

Both move data into an analytics store. They differ in where the transformation happens.

Common categories:

• Source-to-target (data completeness) testing: all expected records arrive.
• Data transformation testing: business rules are applied correctly.
• Data quality testing: duplicates, nulls, formats, ranges.
• Data integrity / referential testing: keys and relationships stay correct. -...

Boundary testing applies boundary value analysis to data. Test the minimum, the maximum, and values just inside and just outside the allowed range.

• Full load: wipe and reload the whole dataset each run. It is simple and consistent. It gets slow and heavy as data grows.
• Incremental (delta) load: load only the records inserted or changed since the last run. It uses timestamps, version numbers, or change data capture.

Common data defects:

• Missing or extra records, and duplicates
• Wrong transformation (calculation, mapping, case, trimming)
• Cut-off text, rounding and data type conversion errors
• Wrong NULL/default handling
• Referential integrity breaks and orphan keys
• Date and time zone mistakes
• Wrong history handling (SCD) or gaps in incremental loads
• Rejected records not logged
• Slow performance and job failures

Two common live tasks.

Compare the metadata with the mapping document. Do not just look at it by eye.

• Database (OLTP): normalised, transactional, current data. Test CRUD, constraints and transactions.
• Data warehouse (OLAP): joined, historical data, modelled (facts and dimensions) for analytics. Test ETL correctness, history (SCD), totals, query speed and report accuracy.
• Data lake: raw files of any...

Start with a baseline load test. Then add stress, spike and soak tests based on risk.

What they are checking: Do you know the test types and what each one is for?

Performance testing measures how a system behaves under a given workload. It looks at speed, stability, scalability and resource use. It does not look for functional bugs. It looks for slow responses, errors and capacity limits.

It matters because slow or unavailable systems lose users and money. Some problems show up only when many users connect at once. Examples are connection pool limits or missing indexes. Testing before release helps you choose the right server size. It also helps you set realistic service level objectives (targets for speed and errors). And it helps you avoid production incidents.

What they are checking: Can you explain the purpose in business terms?

• Response time: the total time from sending a request until the full response is received. This is what the user sees.
• Latency: the delay before the first byte arrives (network time plus server wait time). It is often reported as time to first byte.
• Throughput: how much work is done in a set time, such as requests per second or transactions per second.

They affect each other. As load grows, throughput rises until the system is full. After that, response time climbs and throughput stays flat or drops. Always report them together.

What they are checking: Do you use the terms correctly?

Averages hide slow outliers. Say 95 percent of requests take 200 ms and 5 percent take 8 seconds. The average looks fine, but one user in twenty has a bad experience.

• p50 (median): the typical experience.
• p95 / p99: what the slowest 5 or 1 percent of users get.
• Max: the worst case. It is often noisy.

Service level objectives are normally set on percentiles. For example: "p95 under 500 ms and error rate under 1 percent". Also look at the full spread of results, not just one number.

What they are checking: Do you know why averages can mislead?

• Thread Group: sets the virtual users, the ramp-up period, and the loop count or duration.
• Samplers: send requests (HTTP Request, JDBC, JMS).
• Config Elements: shared settings (HTTP Request Defaults, HTTP Cookie Manager, CSV Data Set Config, Header Manager).
• Logic Controllers: control the flow (Loop, If, Transaction, Random).
• Timers: add a delay or think time between requests.
• Pre/Post Processors: prepare or extract data (Regular Expression, JSON Extractor).
• Assertions: check that responses are correct.
• Listeners: collect and show results (Summary Report, Aggregate Report, Backend Listener).

Execution order: config elements, pre-processors, timers, sampler, post-processors, assertions, listeners.

What they are checking: Do you know the JMeter building blocks?

Key settings:

• Number of Threads: the virtual users.
• Ramp-up period: the number of seconds JMeter takes to start all threads.
• Loop Count: how many times each thread repeats the plan, or infinite.
• Optionally Duration and startup delay, using the scheduler.

Ramp-up avoids hitting the server with all users at the same moment. With 100 threads and a 50 second ramp-up, JMeter starts two users per second. Each thread then runs the plan until the loops or duration end. For steady-state tests, use a long enough duration. Leave the ramp-up out of your analysis.

What they are checking: Can you set up realistic load?

Parameterisation replaces fixed values with variable data. Each virtual user then sends different input, such as usernames, search terms or product ids.

Use CSV Data Set Config:

• File: users.csv with header username,password.
• Variable names: username,password, then use ${username} and ${password} in samplers.
• Recycle on EOF and Stop thread on EOF: choose based on whether the data may be reused.
• Sharing mode: all threads, so each user takes the next row.

Other options: __Random, __RandomString and __UUID functions, User Defined Variables, and the Counter element. Use enough unique data so that caching does not change the results.

What they are checking: Can you create realistic load data?

Assertions confirm that a fast response is also a correct one. A server that returns quick 500 errors would otherwise look great.

The GUI uses a lot of CPU and memory. This limits the load you can create and makes measurements wrong. Use the GUI only to build and debug scripts. Run real tests from the command line.

Think time simulates the pause real users take between actions. Without it, each virtual user sends requests back to back. This creates far more load per user than in real life. So the results are not realistic.

k6 tests are written in JavaScript. A test defines options and a default function. Each virtual user runs that function again and again.

Monitor every tier. Match the data to the test timeline.

Start with the conclusion, then give the evidence.

Concurrent users is how many users are active in the system at the same time. Requests per second is how much work reaches the server each second.

Use post-processors on the sampler:

A baseline is the measured performance of the system under a set load at one point in time. It is usually the current release. You compare later builds to it to find regressions (things that got worse) or improvements. A benchmark is a standard or target to compare against. It can be an industry figure, a competitor, or an agreed service level objective.

• INNER JOIN: returns only the rows that match in both tables.
• LEFT JOIN: returns all rows from the left table. It adds matching rows from the right table. Where nothing matches, the right side is NULL.
• RIGHT JOIN: the same as LEFT, but from the other side.
• FULL OUTER JOIN: returns all rows from both tables. Unmatched sides are NULL. MySQL does not have it. You can copy it with a UNION of a LEFT and a RIGHT join.

SELECT e.name, d.dept_name
FROM employees e
LEFT JOIN departments d ON d.id = e.dept_id;   -- employees without a department still appear

A tester can use LEFT JOIN with WHERE d.id IS NULL to find orphan records (rows with no parent).

What they are checking: How joins work

WHERE filters single rows before grouping. It cannot use aggregate functions like COUNT. HAVING filters groups after GROUP BY. It can use aggregate functions.

SELECT dept_id, COUNT(*) AS cnt, AVG(salary) AS avg_sal
FROM employees
WHERE salary > 20000          -- row filter
GROUP BY dept_id
HAVING COUNT(*) > 5;          -- group filter

The order the database runs the clauses: FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT.

What they are checking: Order in which a query runs

The simple case uses GROUP BY:

SELECT product_id, MAX(amount) AS highest_bid
FROM bids
GROUP BY product_id;

If you also need the bidder (the whole row), use a window function:

SELECT product_id, bidder_id, amount
FROM (
  SELECT b.*, ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY amount DESC) AS rn
  FROM bids b
) t
WHERE rn = 1;

Or join back to the max value with this query. JOIN (SELECT product_id, MAX(amount) m FROM bids GROUP BY product_id) x ON x.product_id = b.product_id AND x.m = b.amount. This returns ties. To keep ties, use RANK() instead of ROW_NUMBER().

What they are checking: Max per group, and getting the whole row

SELECT email, COUNT(*) AS cnt
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

To see the full duplicate rows:

SELECT * FROM users
WHERE email IN (SELECT email FROM users GROUP BY email HAVING COUNT(*) > 1);

To delete duplicates and keep the lowest id (PostgreSQL / MySQL 8):

DELETE FROM users WHERE id IN (
  SELECT id FROM (
    SELECT id, ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn FROM users
  ) t WHERE rn > 1
);

Always run the SELECT first. Take a backup before you delete.

What they are checking: A common data quality query

The second highest salary, using a subquery:

SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

The nth highest, using DENSE_RANK (it handles ties; N = 3 here):

SELECT DISTINCT salary FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS r
  FROM employees
) t
WHERE r = 3;

Using an offset (MySQL/PostgreSQL):

SELECT DISTINCT salary FROM employees ORDER BY salary DESC LIMIT 1 OFFSET 2;

Note: if there are fewer than N different salaries, the result is empty. It is not an error.

What they are checking: Ranking and equal values

DELETE with no WHERE removes all rows. It keeps the table structure and the identity counter.

What they are checking: Basic SQL commands

• Primary key: identifies each row. It cannot be NULL. A table has only one.
• Unique key: values must be different. It may allow NULL (one or more, depending on the database). A table can have many.
• Foreign key: a column that points to a primary or unique key in another table. It keeps data linked correctly (referential integrity), so there are no orphan rows. On delete it can do actions like CASCADE, RESTRICT or SET NULL.

Testing: try to insert a duplicate PK (you get an error). Try an order for a customer that does not exist (FK error). Try to delete a parent that has children. It should be blocked or cascade, as designed.

What they are checking: Knowledge of constraints

SELECT d.dept_name,
       COUNT(e.id)            AS emp_count,
       ROUND(AVG(e.salary),2) AS avg_salary
FROM departments d
LEFT JOIN employees e ON e.dept_id = d.id
GROUP BY d.id, d.dept_name
ORDER BY avg_salary DESC;

Points to say: LEFT JOIN keeps departments with zero employees. COUNT(e.id) gives 0 because it ignores NULLs, but COUNT(*) would give 1. Every column in SELECT that is not an aggregate must also be in GROUP BY. Give the tables short alias names so the query is easy to read.

What they are checking: Writing a join with an aggregate live

NULL means unknown or missing. It is not zero or an empty string. Comparing with NULL using = or <> gives UNKNOWN, so WHERE col = NULL returns nothing. Use IS NULL or IS NOT NULL instead.

SELECT * FROM customers WHERE phone IS NULL;
SELECT name, COALESCE(phone, 'N/A') FROM customers;   -- replace NULL

Aggregates ignore NULL (except COUNT(*)). NULL + 1 is NULL. NOT IN returns no rows if the list has a NULL, so prefer NOT EXISTS.

What they are checking: Common NULL mistakes

Three correct ways:

-- LEFT JOIN anti-join
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

-- NOT EXISTS (safe with NULLs)
SELECT c.id, c.name FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

-- NOT IN (avoid if the subquery can return NULL)
SELECT id, name FROM customers WHERE id NOT IN (SELECT customer_id FROM orders WHERE customer_id IS NOT NULL);

Testers also use this to find orphan rows or missing related data.

What they are checking: Anti-join pattern (find rows with no match)

• Atomicity: a transaction is all or nothing.
• Consistency: a transaction moves the database from one valid state to another and follows all the rules.
• Isolation: transactions that run at the same time do not see each other's unfinished work.
• Durability: once a transaction is committed, the data is kept even after a crash.

GROUP BY puts rows with the same values into groups. Then aggregates (COUNT, SUM, AVG, MAX, MIN) work on each group. ORDER BY only sorts the final rows, from low to high or high to low. You can use both together: group first, then sort the groups.

• COUNT(*): counts all rows, including rows with NULLs.
• COUNT(column): counts the rows where the column is not NULL.
• COUNT(DISTINCT column): counts the different values that are not NULL.

Both join the results of two SELECTs. The two SELECTs need the same number of columns, with matching types. UNION removes duplicates, which takes extra work. UNION ALL keeps all rows and is faster. Use UNION ALL when duplicates cannot happen or you want them. Use UNION when you need only different rows.

A subquery is a query inside another query. A non-correlated subquery runs on its own, only once. A correlated subquery uses columns from the outer query. It runs once for each outer row.

Normalization organizes tables to reduce repeated data and update errors.

• 1NF: each column holds one simple value. There are no repeating groups, so no comma-separated lists in one cell.
• 2NF: it follows 1NF, and every non-key column depends on the whole primary key. No column depends on only part of a composite key.
• 3NF: it follows 2NF, and no non-key column depends on another non-key column. For example, city should not be set by zip.

Constraints make the database follow rules: PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT.

CHAR(n) has a fixed length and is padded with spaces. VARCHAR(n) stores any length up to n. DATE holds only a date. DATETIME holds a date and time without a time zone. TIMESTAMP is stored in UTC and converted to the session time zone. In MySQL it has a limited range of years. Test the edges: maximum length plus one, trailing spaces, Unicode (emoji needs a charset like utf8mb4), and time zone changes around midnight and daylight saving.

• LIKE 'A%': matches a text pattern (% is any length, _ is one character).
• IN (1,2,3): matches any value in a list or a subquery.
• BETWEEN 10 AND 20: a range that includes both ends (10 and 20 are included).
• EXISTS (subquery): true if the subquery returns at least one row. It stops at the first match and is safe with NULLs.