These manual testing interview questions for 3 years of experience target mid-level testers (about 1.5–3 years). Expect deeper test design (pairwise, error guessing, risk-based and exploratory testing), manual API testing with Postman, database validation with SQL, and the basics of performance and security testing. Interviewers want to hear how you decide what to test, not just how you execute it.

Manual testing interview questions by experience: Freshers · 1 year · 3 years · 5 years
Planning your preparation? Follow the manual testing roadmap.

Advanced Test Design

1. What is Pairwise Testing? When do you use it?

Pairwise testing ensures every combination of any two input parameters is covered at least once, with minimum test cases.

Use when: multiple independent parameters exist and exhaustive combination testing is impractical. Example: Browser (3) × OS (3) × Language (3) = 27 cases exhaustively. Pairwise reduces to ~9 while still covering all pairs.

It is especially useful for configuration testing and feature testing with multiple input options.

Interview tip: Give the number example. Abstract answers don't score well.

2. What is Error Guessing? Give examples of what you would test.

Error guessing uses experience and intuition to identify likely bug locations and design targeted test cases.

I always test: empty/null inputs on required fields, zero and negative values in numeric fields, extremely large values, special characters (!@#$%^), duplicate data submissions, boundary values, whitespace-only inputs, and concurrent user actions on shared records.

On real projects, data-processing modules and log parsing are areas I would focus error guessing on because they involve complex logic and format handling.

3. How do you apply risk-based testing in a sprint?

In sprint planning I identify risks by: checking defect history for high-bug modules, flagging recently changed code as higher risk, asking developers about complex logic areas, and identifying business-critical workflows like payment and authentication.

I then order my test execution accordingly — critical risk areas tested first, low risk areas tested last or deferred if time runs short.

Most importantly, I document and communicate what was skipped and why in the test summary report — so stakeholders can make an informed release decision.

Interview tip: The communication part is what separates mid-level from junior. Always mention it.

4. What is an Exploratory Testing Charter? Write one for a login feature.

A charter is a mission statement for a time-boxed exploratory testing session. Format: 'Explore [area] with [resources] to discover [risks].'

Example charter for login: 'Explore the login module with valid, invalid, and edge-case credentials across Chrome, Firefox, and Edge browsers to discover authentication bypass risks, session management gaps, and error message information leakage.'

The charter gives focus without scripting every step — the tester uses expertise to decide what to explore within the defined mission.

5. What is Session-Based Test Management?

SBTM is a framework for managing exploratory testing with structured, documented, time-boxed sessions.

Each session has a charter (mission), a time box (60–90 mins), and produces session notes documenting: areas covered, bugs found, open questions, and areas not yet explored.

After each session a debrief with the QA Lead reviews findings and plans the next charter. This makes exploratory testing measurable and accountable — not just 'random clicking'.

Advertisement

Manual API Testing

6. How do you comprehensively test a REST API? Walk through your complete approach.

Comprehensive API testing goes far beyond just sending a request and checking the status code. Here is a complete methodology:

Phase 1: UNDERSTAND THE API

Before testing, collect

  • API Documentation (Swagger/OpenAPI spec, Postman collection, or wiki).
  • Endpoint URLs for each environment (dev, QA, staging, prod).
  • Authentication method (API Key, Bearer Token, OAuth 2.0, Basic Auth).
  • Request/Response schemas (expected data structure and types).
  • Business rules and validations.
  • Rate limits and throttling rules.
  • Error codes and their meanings.

Phase 2: TEST CATEGORIES

1. FUNCTIONAL TESTING:

  • Positive Tests: Valid inputs → correct response.

Example: POST /users with valid JSON body → 201 Created with user object in response.

  • Negative Tests: Invalid inputs → correct error response.

Example: POST /users with missing required field "email" → 400 Bad Request with descriptive error.

  • Boundary Tests: At and around data limits.

Example: Username with 1 character (min), 50 characters (max), 51 characters (exceeds max).

  • Business Rule Tests: Specific business logic validation.

Example: POST /orders with out-of-stock product → 422 Unprocessable Entity with "Product out of stock" error.

2. RESPONSE VALIDATION (for every test):

  • Status Code: Is it the correct HTTP code?
  • Response Body: Check every field:

- All expected fields are present (no missing fields).

- No unexpected extra fields (data leakage).

- Correct data types (string not number, etc.).

- Correct values match the request data.

- Correct format (dates, phone numbers, enums).

  • Response Headers: Content-Type, Cache-Control, security headers.
  • Response Time: Is it within acceptable performance threshold?

3. AUTHENTICATION AND AUTHORIZATION TESTING:

  • Test without any token → should return 401 Unauthorized.
  • Test with expired token → should return 401 Unauthorized.
  • Test with invalid/malformed token → should return 401 Unauthorized.
  • Test with valid token but insufficient permissions → should return 403 Forbidden.
  • Test that user A cannot access user B's data using user A's valid token (IDOR testing).
  • Test each role: Admin can do X, Regular User cannot do X.

4. ERROR HANDLING TESTING:

  • Verify each error code returns a meaningful, non-technical error message.
  • Verify errors don't expose internal server details (no stack traces in production).
  • Test 404: Request non-existent resource.
  • Test 409: Create duplicate resource.
  • Test 422: Submit data that fails validation.
  • Test 500: Simulate server errors (if test environment allows).

5. DATA INTEGRITY TESTING:

  • After POST: Verify data is correctly saved in the database (SQL query).
  • After PUT/PATCH: Verify only intended fields were updated.
  • After DELETE: Verify record is removed or soft-deleted (status='deleted').
  • Test idempotency: PUT/DELETE same request twice → same result, no duplicates.

6. PERFORMANCE TESTING OF APIS:

  • Response time under normal load.
  • Behavior when called with large payloads.
  • Rate limiting: Make requests exceeding the limit → expect 429 Too Many Requests.

Postman testing approach

Set up environment variables

  • base_url: https://api.example.com
  • token: {{auth_token}} (populated dynamically after login)

Pre-request Script (get auth token automatically)

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

Test Script (assertions after response)

pm.test("Status code is 201", () => {

pm.response.to.have.status(201);

});

pm.test("Response has user ID", () => {

pm.expect(pm.response.json()).to.have.property('id');

});

pm.test("Email matches request", () => {

pm.expect(pm.response.json().email).to.equal(pm.request.body.raw.email);

});

Common API bugs to look for

  • Incorrect status codes (200 instead of 201 for creation).
  • Missing validation on required fields.
  • Inconsistent field names (user_id vs userId vs UserId).
  • Incorrect data types (age returned as string "25" not number 25).
  • Missing pagination on lists (returning 10,000 records at once).
  • Sensitive data in responses (passwords, full credit card numbers).
  • CORS configuration issues blocking legitimate browsers.
Interview tip: Walk through a real example from your experience. Describe how you used Postman collections and environments. Mention that you not only tested the API response but also verified the database state — this shows depth. Senior testers combine API testing with DB verification.

7. What is API Testing? Why is it important?

API Testing verifies the API layer directly — without going through the UI — checking that it handles requests correctly, returns proper responses, manages errors gracefully, and enforces security.

It is important because: APIs are the backbone of all modern apps, API bugs affect everything built on top, it is faster than UI testing, and many bugs only exist at the API layer and are invisible through UI testing.

As a mid-level QA I verify: correct status codes, response body structure and values, data types, authentication, error handling, and response time.

8. What is the difference between GET, POST, PUT, and PATCH?

GET: Retrieve data. No body. Idempotent — calling multiple times returns same result. Example: GET /users/5.

POST: Create new resource. Has body. Not idempotent — calling 3 times creates 3 records. Example: POST /users.

PUT: Replace entire resource with new data. Has body. Idempotent. Example: PUT /users/5 replaces ALL fields.

PATCH: Partially update a resource — only the fields provided are changed. Example: PATCH /users/5 with just { email } only updates email.

9. What does 401 mean vs 403? Give an example of each.

401 Unauthorized: The client is NOT authenticated. The server does not know who the caller is. Fix: provide a valid auth token or log in.

403 Forbidden: The client IS authenticated but does NOT have permission for this action. The server knows who you are but says no.

Example: Calling admin/users with no token at all = 401 (who are you?). Calling admin/users while logged in as a regular user = 403 (I know you, but you are not an admin).

Interview tip: Always give both examples. The contrast makes your answer clear and memorable.

10. What do you verify in a POST API response after creating a record?

Status code is 201 Created — not 200. POST success should return 201.

Response body contains the created object with all expected fields populated correctly.

Auto-generated fields are present: id, created_at, updated_at.

Data types are correct: id is integer, name is string, active is boolean.

No sensitive data is exposed in the response — passwords, internal IDs, system paths.

I also verify in the database directly: SELECT * FROM users WHERE email = 'test@test.com' — confirm the record was actually saved with correct values.

11. How do you test an API that has no documentation?

I speak with the developer to understand: available endpoints, request format, expected auth method, and known error conditions.

I check for a Swagger/OpenAPI spec file — most modern APIs have one at /api/docs or /swagger.

I start with basic GET requests to explore what endpoints exist and what they return.

I build a Postman collection as I explore, documenting each endpoint's behaviour, and raise any unclear behaviours as Jira tasks.

I treat the exploration itself as a form of charter-based exploratory testing.

12. What is the difference between REST and SOAP APIs?

REST uses HTTP, is stateless, returns lightweight JSON or XML, and is easy to test with Postman. Widely used in modern web and mobile applications.

SOAP is a protocol using strict XML with a defined envelope structure. Can work over multiple protocols. Requires a WSDL file. Common in older enterprise systems — banking, insurance, government.

From a QA perspective: REST testing uses Postman. SOAP testing uses SoapUI. REST is far more common in modern projects.

Database Testing

13. Why do we do database testing if UI testing already passes?

UI testing verifies what is displayed. Database testing verifies what was actually stored. These are not the same.

Example: A registration form may show 'Account created successfully' on the UI. But without DB testing, we cannot confirm: was the record actually saved? Was it saved to the correct table? Are all fields correct? Is the password hashed?

DB bugs are often silent — no visible error to the user. They only surface when someone runs a report or when data is corrupted and a user notices something wrong weeks later.

14. Write SQL to verify a user was created correctly after registration.

SELECT id, name, email, role, status, created_at, password FROM users WHERE email = 'testuser@example.com';

I then verify: record exists, name and email match the form input, role is the correct default (e.g. 'user'), status is 'active' or 'pending_verification', created_at is the current timestamp, and the password column shows a hash — NOT the plain text password.

If password is plain text, that is a Critical severity, High priority security defect — reported immediately.

Interview tip: SQL questions are asked at mid-level interviews. Know SELECT, WHERE, JOIN, COUNT, and ORDER BY.

15. What is referential integrity? How do you test it?

Referential integrity ensures foreign key relationships are always valid. A child record cannot reference a parent record that does not exist.

Example: An orders table has a user_id column referencing the users table. If user_id=999 does not exist in users, the insert should fail with a foreign key constraint error.

Testing: (1) Try inserting a child record with a non-existent parent ID — expect FK violation error. (2) Try deleting a parent record that has child records — expect either an error (restrict) or cascade delete per requirement. (3) Verify no orphan records exist after test data cleanup.

16. How do you test that a delete operation worked correctly at the DB level?

After triggering a delete through the UI or API, I run: SELECT * FROM users WHERE id = 123; — expect zero rows returned if hard delete.

For soft delete (where records are marked as deleted but not removed): SELECT * FROM users WHERE id = 123; — should show deleted_at is not null and status = 'deleted'.

I also verify: child records are handled correctly per requirement — either cascade deleted or rejected with FK error. No other records were accidentally affected by the delete operation.

17. What SQL would you use to find all orders placed in the last 30 days with their user names?

SELECT u.name, u.email, o.id, o.total, o.status, o.created_at FROM orders o JOIN users u ON o.user_id = u.id WHERE o.created_at >= NOW() - INTERVAL 30 DAY ORDER BY o.created_at DESC;

This uses a JOIN to combine orders and users tables, WHERE to filter the last 30 days, and ORDER BY to show most recent first. In a real project I would also add a LIMIT to avoid returning millions of rows during testing.

18. Write SQL queries for common testing validation scenarios.

Here are advanced SQL queries testers commonly need for thorough data validation:

Scenario 1: Find the second highest salary (Classic Interview Question):

Method 1 - Subquery

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

Method 2 - Using limit/offset (MySQL/PostgreSQL)

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

Method 3 - Using DENSE_RANK (SQL Server, PostgreSQL):

SELECT salary FROM (
SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) as rnk
FROM employees
) ranked
WHERE rnk = 2;

Scenario 2: Find records created in the last 7 days:

SELECT * FROM orders
WHERE created_at >= NOW() - INTERVAL 7 DAY
ORDER BY created_at DESC;

Testing use: Verify only recent records appear in the "Recent Orders" dashboard.

Scenario 3: Verify referential integrity (no orphan records):

-- Find order items that reference non-existent orders:
SELECT oi.*
FROM order_items oi
LEFT JOIN orders o ON oi.order_id = o.id
WHERE o.id IS NULL;

Expected: Zero rows (no orphan order items should exist).

Scenario 4: Verify data consistency across tables:

-- Total amount in order vs sum of order items:
SELECT
o.order_id,
o.total_amount as order_total,
SUM(oi.quantity * oi.unit_price) as calculated_total,
o.total_amount - SUM(oi.quantity * oi.unit_price) as discrepancy
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
GROUP BY o.order_id, o.total_amount
HAVING ABS(o.total_amount - SUM(oi.quantity * oi.unit_price)) > 0.01;

Testing use: Critical for e-commerce — order total must match sum of items.

Scenario 5: PIVOT-style query — orders by status:

SELECT
COUNT(CASE WHEN status = 'pending' THEN 1 END) as pending_count,
COUNT(CASE WHEN status = 'completed' THEN 1 END) as completed_count,
COUNT(CASE WHEN status = 'cancelled' THEN 1 END) as cancelled_count,
COUNT(*) as total
FROM orders;

Testing use: Dashboard metrics validation.

Scenario 6: Find users who haven't logged in for 90 days:

SELECT id, email, last_login_at
FROM users
WHERE last_login_at < NOW() - INTERVAL 90 DAY
AND status = 'active';

Testing use: Verify inactive user notifications are sent correctly.

Scenario 7: Running total (Cumulative Sum):

SELECT
order_date,
daily_revenue,
SUM(daily_revenue) OVER (ORDER BY order_date) as cumulative_revenue
FROM (
SELECT DATE(created_at) as order_date, SUM(total_amount) as daily_revenue
FROM orders WHERE status = 'completed'
GROUP BY DATE(created_at)
) daily_totals;

Testing use: Verify financial reports show correct cumulative totals.

Scenario 8: Compare before and after states:

-- Store state before action:
SELECT COUNT(*) as before_count, SUM(quantity) as before_stock
FROM inventory WHERE product_id = 101;
-- [Execute the test action: purchase 5 units]
-- Verify state after action:
SELECT COUNT(*) as after_count, SUM(quantity) as after_stock
FROM inventory WHERE product_id = 101;
-- Expected: after_stock = before_stock - 5

Scenario 9: Check for proper data masking in non-production:

-- Credit card numbers should be masked:
SELECT card_number FROM payment_methods
WHERE card_number NOT LIKE '****-****-****-%';

Expected: Zero rows (all cards should be masked except last 4 digits).

Scenario 10: Verify cascade delete worked correctly:

-- After deleting user ID 500:
SELECT COUNT(*) FROM users WHERE id = 500; -- Expected: 0
SELECT COUNT(*) FROM orders WHERE user_id = 500; -- Expected: 0 (cascaded)
SELECT COUNT(*) FROM sessions WHERE user_id = 500; -- Expected: 0 (cascaded)
Interview tip: SQL knowledge differentiates testers significantly. Practice writing queries from memory. Know the difference between WHERE and HAVING, understand JOINs visually (draw Venn diagrams), and always explain the business testing purpose of each query — it shows you think like a tester, not just a coder.

Performance and Security Testing

19. What is the difference between Load Testing and Stress Testing?

Load Testing verifies the system performs within acceptable limits under EXPECTED normal load. Goal: confirm performance meets SLA at peak business usage.

Stress Testing deliberately pushes the system BEYOND normal capacity to find the breaking point and observe how it fails. Goal: understand limits and ensure graceful failure — no silent data corruption or crash without error.

Example: Load test = 1000 users (expected peak). Stress test = increase to 5000, 10000 users until something breaks. Load tests run every release. Stress tests run periodically.

20. What is Soak Testing? What does it find?

Soak Testing runs the system at NORMAL load for an EXTENDED period — typically 8 to 24+ hours — to find problems that only appear over time.

It specifically finds: memory leaks (RAM usage grows slowly and eventually causes crash), connection pool exhaustion (DB connections leak and run out), gradual performance degradation (response time slowly increases over hours), and file handle or thread leaks.

These bugs are completely invisible in a 10-minute load test and only surface under sustained real-world usage.

Interview tip: Soak testing is an advanced concept. Knowing it shows genuine performance testing depth.

21. What is SQL Injection? How do you test for it?

SQL Injection is a security attack where malicious SQL code is entered in an input field, causing the application to execute unintended database commands.

Classic example: Enter ' OR '1'='1 in the username field. If vulnerable, the login query becomes WHERE username='' OR '1'='1' — which always returns true — bypassing authentication.

How I test: Enter these patterns in all input fields: ' OR 1=1--, '; DROP TABLE--, ' UNION SELECT null--. Expected result: input treated as a literal string, not SQL. No DB error message exposed. Authentication not bypassed.

Interview tip: Give the actual SQL string in your answer. Abstract answers about 'injecting code' don't score well.

22. What is XSS? How do you test for it?

XSS (Cross-Site Scripting) is a vulnerability where an attacker injects malicious JavaScript into a web page through an input field. The script executes in other users' browsers.

Stored XSS: the script is saved to the database (e.g. in a comment or profile field) and runs for every user who views that page.

How I test: Enter <script>alert('XSS')</script> in text input fields — name, comment, address, search. If an alert box appears, the application is vulnerable. Expected: input is HTML-escaped and displayed as plain text, not executed.

23. What are the key metrics you report after a performance test?

Five key metrics I always report: (1) Response Time — average and 95th percentile, compared against the SLA target (e.g. under 2 seconds). (2) Throughput — transactions per second. (3) Error Rate — should be under 1% at normal load. (4) Concurrent Users supported — at what user count does performance degrade? (5) CPU and Memory utilisation — should stay under 80% at peak load.

I also look for trends: is response time increasing over time (possible memory leak)? At what user count do errors start appearing? These guide the developer to the root cause.

24. How do you test that a regular user cannot access admin functionality?

First I identify all admin endpoints and pages — typically /admin, /dashboard/admin, or admin-only API endpoints.

I log in as a regular user (non-admin role) and try to access these URLs directly via browser navigation.

Expected result: 403 Forbidden (or redirect to login/unauthorised page). If I can access admin content as a regular user — that is a Broken Access Control vulnerability, severity Critical.

For APIs: I use the regular user's auth token in a Postman request to an admin-only endpoint. Expected: 403 Forbidden.

How to Prepare with 3 Years of Experience

  • Practise API testing hands-on in Postman: status codes, auth, negative cases and chaining requests.
  • Write the SQL answers yourself against a sample database instead of memorising them.
  • Prepare a story where risk-based or exploratory testing found something scripted tests missed.
  • Read the questions for 5 years of experience as well: leadership questions often start at this level.
📖 Related tutorials