Manual Testing Interview Questions and Answers

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

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

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

A defect moves through states from discovery to closure:

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

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

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

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

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

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

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

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

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

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

Example: an age field accepts 18 to 60.

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

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

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

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

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

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

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

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

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

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

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

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

What they are checking: Basic classification of test techniques

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

Non-functional examples:

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

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

What they are checking: Basic grouping with real examples

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

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

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

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

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

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

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

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

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

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.

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.

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

Shift-left means moving testing earlier in the life cycle. Practices:

• QA reviews requirements and acceptance criteria.
• Test cases are written before the code is finished.
• Developers write unit and API tests.
• Static analysis and linting run on each commit.
• Automated tests run in CI on every pull request.

Use AI as an assistant, not as the final judge:

• Draft test cases and edge cases from a requirement, then review and fix them
• Generate test data and SQL or JSON payloads
• Summarise logs and failures, and suggest likely root causes
• Draft bug reports from rough notes, and help with triage and finding duplicates
• Help write and clean up automation scripts

Fixtures give isolated, reusable setup that tests ask for by name. Built-in ones are page, context, browser, request. You can add your own (logged-in page, API client, seeded data). They also clean up automatically.

Defect leakage is the share of defects found after release (by customers) out of all defects: leaked / (found in testing + leaked) x 100. It measures how well testing works. Defect density is defects per size unit, such as per 1,000 lines of code or per module. It shows which parts of the code have the most problems. Use leakage to judge the QA process. Use density to decide where to focus effort.

Do manual checks and tool-assisted checks on the OWASP Top 10 themes:

• Authentication: weak passwords, lockout, session expiry, logout makes tokens invalid
• Authorization: reading other users' data by changing IDs (IDOR), role escalation
• Input handling: SQL injection and XSS payloads in fields and URLs
• Sensitive data: HTTPS only, no secrets in URLs or logs, secure cookie flags
• Headers and wrong settings, error messages that show stack traces
• File upload limits

Risk-based testing sets the order of work by risk. Risk = chance of failure x business impact. Find the risks with stakeholders (complex code, new technology, past defects, money or legal exposure). Score them. Then test high-risk areas deeper and earlier, and give low-risk areas lighter coverage. It is a sensible way to test when time is short. It also makes release decisions easy to explain.

• Test execution progress and pass, fail and blocked rates
• Defects by severity, status, module and age; defect leakage; defect removal efficiency
• Requirement and test coverage; automation coverage
• Mean time to fix and retest
• Rate of unstable tests (tests that pass sometimes and fail other times) and how long the automation suite takes
• Reopen rate (shows the quality of fixes)

A test or staging environment copies production but uses test data and can be reset. Production holds real users and real data. Testing there can damage data, send real emails or payments, and show users unstable behavior. Staging must be like production (same versions, configuration and data shape) to give results you can trust. Controlled checks in production are fine as a final safety net. Examples are smoke tests after release, canary releases and monitoring.

• Driver: calls the code under test when the real caller does not exist yet.
• Stub: a fake replacement for a dependency that returns fixed answers.
• Mock: a stub that also records calls, so the test can check how it was used.

A mobile app needs these extra checks:

• Many devices and OS versions
• Screen sizes and orientation
• Interruptions (calls, notifications, low battery)
• Network changes (offline, 2G, wifi to mobile data)
• Permissions (camera, location)
• Install, upgrade and uninstall
• App store rules
• Gestures
• Background and foreground behavior
• Battery and memory use
• Deep links

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

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

Start with risk and scope:

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

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

Steps:

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

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

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

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

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

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

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

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

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

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

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

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

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