These manual testing interview questions for 1 year of experience are for testers with roughly 6 months to 1.5 years in the job. At this level interviewers stop asking for definitions and start asking how you work: test plans and RTMs, estimation, regression and UAT, Agile ceremonies and user stories, test environments and data, and the SQL you use to check results. Answer from your own project wherever you can.

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

Test Planning and Documentation

1. What is a Test Plan? What does it contain?

A Test Plan is a formal document created by the QA Lead that defines the complete testing approach for a project.

It contains: scope (what is and is not tested), objectives, test approach, schedule, resources, entry/exit criteria, test deliverables, risks and mitigations, and defect management process.

It acts as the testing bible for the project — everyone on the QA team follows it.

Interview tip: Interviewers often follow this with 'Who creates it?' — QA Lead creates it, team follows it.

2. What is the difference between a Test Plan and a Test Strategy?

Test Strategy is a high-level, organisation-wide document covering overall testing approach, tools, and standards. It is created once by the QA Manager and rarely changes.

Test Plan is project-specific. Created by the QA Lead for each release — covers scope, schedule, resources, and entry/exit criteria for that specific project.

Relationship: The Test Plan is derived from the Test Strategy.

Interview tip: A common trick question. Remember: Strategy is HIGH level (org-wide), Plan is LOW level (project-specific).

3. What is RTM? Why is it important?

RTM stands for Requirement Traceability Matrix. It is a document that maps every business requirement to its corresponding test cases.

It is important because it: ensures 100% test coverage (no requirement is missed), provides proof of coverage to clients and stakeholders, helps identify gaps during test review, and makes impact analysis easy when requirements change.

Without RTM, you cannot confidently say every requirement has been tested.

Interview tip: Always mention the business value — proof of coverage and client confidence. Don't just define it.

4. What is a Test Summary Report? What does it include?

A Test Summary Report is written at the end of a testing cycle to communicate the testing results to stakeholders.

It includes: total test cases executed/passed/failed/blocked, defect summary by severity, test coverage percentage, overall quality assessment, known open risks, lessons learned, and stakeholder sign-off.

Its purpose is to give decision-makers the information they need to decide: is this product ready to release?

5. How do you estimate testing effort for a project?

Test effort estimation is one of the most challenging tasks in testing. Here are the most widely used techniques, with detailed explanations:

1. WORK BREAKDOWN STRUCTURE (WBS) ESTIMATION:

  • Break down ALL testing activities into individual tasks.
  • Estimate time for each task.
  • Sum all estimates for total effort.

Example breakdown for a login feature

  • Requirement analysis: 2 hours
  • Test case creation: 4 hours
  • Test case review: 1 hour
  • Test environment setup: 2 hours
  • Test execution (first cycle): 6 hours
  • Defect logging and retesting: 3 hours
  • Regression testing: 4 hours
  • Test reporting: 1 hour
  • Buffer (20%): ~5 hours

Total: ~28 hours for login feature testing.

2. FUNCTION POINT ANALYSIS:

  • Count functional units: Inputs, Outputs, Queries, Files, Interfaces.
  • Apply complexity weights.
  • Calculate test effort as a ratio of Function Points.
  • Formula: Test Effort = FP × Complexity Factor × Historical Rate.

3. THREE-POINT ESTIMATION (PERT):

  • Get three estimates from experienced team members:

O = Optimistic (best case, everything goes right)

P = Pessimistic (worst case, everything goes wrong)

M = Most Likely (realistic scenario)

  • Formula: E = (O + 4M + P) / 6
  • Example: O=3 days, M=5 days, P=10 days → E = (3 + 20 + 10)/6 = 5.5 days

4. USE CASE POINT METHOD:

  • Count Use Cases, classify by complexity (Simple, Average, Complex).
  • Apply weights and productivity factors.
  • Formula: Test Effort = Total Use Case Points × Effort per Point

5. HISTORICAL DATA / ANALOGY ESTIMATION:

  • Compare with similar past projects.
  • "This project is similar to Project X but 20% larger."
  • Most accurate when good historical data exists.

Factors that affect estimates

  • Complexity of the application.
  • Clarity of requirements.
  • Tester experience level.
  • Environment stability.
  • Automation coverage.
  • Number of integrations.
  • Regression scope.
  • Available test data.

Estimation best practices

  • Never estimate alone — involve the team.
  • Add buffer (15–20%) for unexpected issues.
  • Break large tasks into smaller ones for better accuracy.
  • Document assumptions used in estimation.
  • Revisit estimates if scope changes.
  • Track actuals vs estimates for future reference.
Interview tip: Interviewers want to know you don't just give numbers off the top of your head. Mention that you use techniques like WBS or Three-Point estimation, factor in complexity and risk, add buffer, and document assumptions. Show maturity by mentioning that estimates are revised as more information becomes available.
Advertisement

Testing Types in Practice

6. What is Regression Testing? When do you perform it?

Regression Testing is re-executing existing test cases after any code change — bug fix, new feature, or enhancement — to ensure the change has not broken existing functionality.

Perform it after: every bug fix, every new feature deployment, every code refactor, and before every major release.

It is the best candidate for automation because the same test cases are run repeatedly over many cycles.

Interview tip: Always mention automation when discussing regression — it shows maturity.

7. What is System Testing? How is it different from Integration Testing?

System Testing tests the ENTIRE application end-to-end as a complete system against all specified requirements. It is performed by the QA team in an environment similar to production.

Integration Testing tests the INTERACTION between two or more modules when they are combined. It does not test the full system — only specific integration points.

Order: Integration Testing happens before System Testing. System Testing is broader and more comprehensive.

8. What is Exploratory Testing? How is it different from Ad-hoc Testing?

Exploratory Testing is a structured approach where the tester simultaneously learns the application, designs tests, and executes them without pre-written scripts. Sessions are time-boxed and documented with session notes and charter.

Ad-hoc Testing is completely unstructured and unplanned — random testing with no documentation at all.

Key difference: Exploratory testing is disciplined and documented. Ad-hoc testing is random and leaves no records. Most professionals prefer exploratory over ad-hoc because it produces repeatable insights.

9. What is End-to-End Testing?

End-to-End Testing validates complete business workflows across the entire application from start to finish, simulating real user scenarios.

Example: On an e-commerce app — E2E test would cover: user registers → logs in → searches for product → adds to cart → makes payment → receives order confirmation email. Every step is tested in sequence.

It is the most realistic form of testing because it mirrors exactly how a real user would interact with the system.

10. What is compatibility testing? Give an example from your experience.

Compatibility Testing verifies that the application works correctly across different browsers, operating systems, devices, and screen resolutions.

Example from my project experience: On a sales-management project, I tested the web application on Chrome, Firefox, and Edge to ensure all UI elements rendered correctly and all functionality worked the same across browsers. We found a specific date picker that worked on Chrome but was broken on Firefox — a CSS compatibility issue that was raised as a bug.

Interview tip: Always give a project-specific example. 'From my project' answers always score higher than generic ones.

11. What is the difference between Alpha and Beta Testing?

Alpha Testing is done by INTERNAL employees (developers, QA, internal users) at the developer's site before releasing to external users. It is the first real user testing of the product.

Beta Testing is done by EXTERNAL, real end users in their own environment after Alpha. It is the last stage before full public release.

Order: Alpha testing first → Beta testing → Final release.

12. What is the difference between Functional and Non-Functional Testing?

Functional Testing verifies WHAT the system does — whether features work as per requirements. Examples: login, search, checkout, calculations. Asks: does the feature work correctly?

Non-Functional Testing verifies HOW the system performs. Examples: performance (response time), security (data protection), usability (ease of use), compatibility (browser/OS), and reliability (uptime). Asks: how well does it work?

Both are required for a complete quality assessment.

Agile, User Stories and Jira

13. What is a User Story? How do you write test cases from it?

A User Story is a requirement written from the end user's perspective: As a [user type], I want [feature], so that [benefit].

To write test cases from a user story, I use the Acceptance Criteria. Each GIVEN-WHEN-THEN scenario in the AC becomes a test case.

Example: AC says 'GIVEN user is on login page, WHEN valid credentials are entered, THEN redirect to dashboard.' I write a test case: precondition = login page open, steps = enter valid credentials + click Login, expected = dashboard loads.

I also write negative test cases for each AC — what happens with invalid inputs or missing data.

14. What is the Definition of Done?

The Definition of Done is a team-wide agreement that defines the exact conditions a user story must meet before it can be marked complete.

From a QA perspective, DoD typically includes: all test cases written and executed, all critical/high bugs fixed and closed, feature reviewed by Product Owner, and regression passed.

DoD is important because it prevents the word 'done' from meaning different things to different team members.

Interview tip: If asked 'what if a developer says done but QA is not finished?' — answer: DoD is the shared standard, QA's sign-off is part of DoD, so it is not done until QA closes it.

15. How do you handle a situation where requirements change mid-sprint?

First, I assess the impact — how many test cases are affected and how much effort is needed to update them.

I raise it in the daily standup immediately so the team is aware. If the change is significant, I flag it to the QA Lead and Scrum Master so it can be discussed with the Product Owner.

If the change is accepted, I update the affected test cases, update the RTM, and check if any previously passed test cases need to be re-executed.

In Agile this happens — the key is communicating the impact clearly and adjusting without blocking the sprint.

Interview tip: This tests your communication and adaptability. Show you handle it professionally, not defensively.

16. What Jira workflow do you follow when raising a defect?

When I find a bug, I create a new defect in Jira with: a clear title, environment details, reproduction steps, expected vs actual result, severity, and an attached screenshot or recording.

The bug moves through: New → Assigned (to developer) → In Progress → Fixed → Ready for Retest → Retested → Closed (or Reopened if the fix fails).

I also link the defect to the user story it belongs to so the traceability is maintained in Jira.

Test Environments, Test Data and Execution

17. What are the different test environments? What is the difference between QA and Staging?

Test environments used in a typical project: Development (dev), QA/Testing, Staging/Pre-prod, UAT, and Production.

QA environment is used by the QA team for functional testing. It may have incomplete data and more frequent deployments.

Staging environment is a near-exact replica of production — same data volume, same configurations, same infrastructure. It is the final gate before go-live and is much more controlled than QA.

18. What is test data? How do you manage it?

Test data is the input data used to execute test cases.

I manage test data by: creating static baseline data for common scenarios, using data masking for any production-like data, ensuring each test case has independent data so tests don't affect each other, and refreshing or resetting data before each test cycle.

On data-heavy projects, I would maintain a test data sheet in Excel or a seed script in the database to quickly reset data before each sprint's test run.

Interview tip: Mention data independence — test cases should not depend on each other's data. This shows maturity.

19. What do you check before starting test execution?

I follow an environment readiness checklist: confirm the correct build version is deployed, verify the application is accessible, confirm test data is set up, check all integrations are working, ensure required browsers and devices are available, and run a smoke test to verify the build is stable.

Starting execution without this check wastes effort — bugs found on a wrong build or bad environment are not real bugs.

Interview tip: This shows professionalism and process thinking — something junior testers often miss.

20. A bug you found in QA cannot be reproduced in Staging. What do you do?

First, I document everything precisely — exact steps, build version, browser, OS, test data used, and a screenshot or recording from QA.

Then I compare the QA and Staging environments — are they on the same build? Same configuration? Same test data?

If the environments differ, I identify what is different and raise it as a configuration issue rather than a defect.

If environments are identical and the bug still cannot be reproduced in Staging, I investigate whether it is a data-dependent issue — try to recreate the exact data conditions from QA.

I never close a bug just because it cannot be reproduced in another environment. I investigate first.

Interview tip: This tests your problem-solving and attention to detail. Show methodical thinking, not frustration.

21. You receive a new build. What is the first thing you do?

The first thing I do is check the release notes to understand what has changed — new features, bug fixes, known issues.

Then I verify the build version matches what was expected.

Then I execute the Smoke Test — quickly check the most critical paths: can the app launch, can users log in, do the core features load without errors.

If the smoke test passes, I proceed with full test execution. If it fails, I immediately raise a blocker and return the build to the developers.

Interview tip: This answer shows you have a real process. Interviewers love candidates who follow a structured approach.

22. How do you prioritise which test cases to execute when you have limited time?

I use risk-based testing to prioritise. I focus on: high severity/high frequency features first, areas that have historically had the most defects (defect clustering), features that were recently modified or have new code, and core business-critical workflows.

I use the RTM to ensure all high-priority requirements are covered first.

I communicate the coverage and risk to the QA Lead so stakeholders understand what was and was not tested within the time available.

Interview tip: This tests maturity and business awareness. Show you think about risk, not just execution speed.

Database Testing with SQL

23. What SQL queries do testers commonly use and how do you use them for validation?

SQL (Structured Query Language) is an essential skill for testers. It allows you to verify that data is correctly stored, updated, and maintained in the database after UI or API actions.

Basic select queries

Fetch all records from a table

SELECT * FROM users;

Fetch specific columns with a condition

SELECT id, email, status FROM users WHERE status = 'active';

Count records

SELECT COUNT(*) FROM orders WHERE customer_id = 123;

Testing use case: After submitting a registration form, verify the user was created:

SELECT * FROM users WHERE email = 'newuser@test.com';

Expected: One record exists with correct name, email, and default status='pending'.

Joins for relationship validation

INNER JOIN — Verify related records exist in both tables:

SELECT o.order_id, u.email, o.total_amount
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.email = 'customer@test.com';

LEFT JOIN — Find records in left table with NO match in right (useful for finding orphaned data):

SELECT u.id, u.email, o.order_id
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.order_id IS NULL;

Use: Find users who have never placed an order.

Aggregation queries

Group by and count

SELECT category, COUNT(*) as product_count
FROM products
GROUP BY category
HAVING COUNT(*) > 10;

Use: Verify product distribution across categories.

Sum and avg

SELECT customer_id, SUM(total_amount) as lifetime_value
FROM orders
WHERE status = 'completed'
GROUP BY customer_id
ORDER BY lifetime_value DESC;

Use: Verify total spend calculations.

Finding duplicates

SELECT email, COUNT(*) as count
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Use: Data integrity check — no duplicate email addresses should exist.

Date queries

SELECT * FROM orders
WHERE created_at >= '2024-01-01'
AND created_at < '2024-02-01';

Use: Verify records created in January 2024.

SELECT * FROM sessions
WHERE expires_at < NOW();

Use: Find expired sessions — verify cleanup is working.

Null checks

SELECT * FROM users WHERE phone_number IS NULL;

Use: Verify all users have a phone number (or find those that don't).

UPDATE (use carefully in testing — always within transactions):

-- In test environments only -- never on production
BEGIN TRANSACTION;
UPDATE orders SET status = 'cancelled' WHERE order_id = 9999;
-- Verify your test scenario

ROLLBACK; -- Always rollback test data changes

Subqueries

SELECT * FROM products
WHERE price > (SELECT AVG(price) FROM products);

Use: Find products priced above average.

Testing workflows using SQL

After creating an order via UI

1. SELECT * FROM orders ORDER BY created_at DESC LIMIT 1; — Verify new order exists.

2. SELECT * FROM order_items WHERE order_id = [new_order_id]; — Verify items are correct.

3. SELECT stock FROM inventory WHERE product_id = [product_id]; — Verify inventory decreased.

After cancelling an order

1. SELECT status FROM orders WHERE order_id = [id]; — Verify status = 'cancelled'.

2. SELECT stock FROM inventory WHERE product_id = [id]; — Verify inventory restored.

3. SELECT * FROM refunds WHERE order_id = [id]; — Verify refund record created.

Important SQL tips for testers

  • Always query BEFORE and AFTER an action for comparison.
  • Use specific conditions to avoid retrieving too many records.
  • Never update production data — use test environments.
  • Document your SQL queries in test cases for repeatability.
  • Learn the database schema of your application — it makes testing much more effective.
Interview tip: Practice SQL on websites like SQLZoo, HackerRank, or LeetCode. Common interview questions: Find second highest salary, find duplicates, use of JOIN vs subquery. Be ready to write queries without assistance.

Experience and Metrics

24. Have you ever found a bug that was marked as 'Not a Bug' but you were sure it was wrong? What did you do?

Yes, this happens. My approach is to never argue without evidence. I go back to the requirement document and find the specific section that defines the expected behaviour.

If the requirement clearly supports my finding, I reopen the bug and attach the requirement reference with a clear explanation of why the behaviour is incorrect.

If the requirement is ambiguous, I involve the Business Analyst or Product Owner to get a definitive answer before either closing or keeping the bug open.

I treat the requirement as the single source of truth — not personal opinion.

Interview tip: This is a common behavioural question. Show data-driven, professional behaviour — not ego.

25. What metrics do you track as a QA engineer?

Key QA metrics I track: Test case execution rate (planned vs actual), Pass/fail ratio, Defect density (bugs per module), Defect removal efficiency (% of bugs found before production), Test coverage (% of requirements covered), Defect resolution time (average time to fix and close a bug), and Reopened defect rate.

These metrics help me identify problem areas, track progress, and communicate quality status to stakeholders objectively.

Interview tip: Metrics knowledge separates junior from mid-level candidates. Know at least 5 metrics by name.

How to Prepare with 1 Year of Experience

  • Prepare one real example each for a bug you found, a requirement you clarified and a regression you planned.
  • Be ready to draw your team's defect workflow in Jira and explain who moves each status.
  • Revise the fresher questions too: interviewers often start there to warm up.
  • Then look ahead to the questions for 3 years of experience: API and database testing usually come next.
📖 Related tutorials