Manual testing interviews are common for freshers and QA engineers in IT companies. These manual testing interview questions cover SDLC, STLC, test cases and types of testing for beginners, then test design techniques, the defect life cycle, test planning, risk-based testing and agile QA practices for experienced testers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Software testing checks that software works as expected and finds defects before users do. It reduces the risk and cost of failures, since bugs found early are much cheaper to fix than in production, improves quality and confidence in releases, and checks that the software meets business requirements and user needs.
Verification asks "are we building the product right?" It checks documents, designs and code against specifications through reviews, walkthroughs and inspections, without running the software. Validation asks "are we building the right product?" It checks the actual software against user needs by executing it, through functional, system and acceptance testing.
Requirement analysis (understanding what to test), test planning (scope, approach, resources and schedule), test case design (writing test cases and preparing data), test environment setup, test execution (running tests and logging defects), and test closure (reports, metrics and lessons learned).
The waterfall model moves through requirements, design, development, testing and deployment in strict order, so testing happens late.
The V-model pairs each development stage with a testing stage, such as requirements with acceptance testing.
Agile delivers working software in short iterations with continuous testing and feedback, and is used by most teams today, often with Scrum or Kanban.
Functional testing checks what the system does against requirements, such as whether login, search and checkout work correctly.
Non-functional testing checks how well it works: performance, load, security, usability, compatibility, reliability and accessibility.
Both are needed for a quality product.
Black box testing checks behaviour through inputs and outputs without knowing the internal code, which is how most manual testers work.
White box testing uses knowledge of the code to design tests that cover statements, branches and paths, usually done by developers.
Grey box testing uses partial knowledge, such as the database structure or API design, to design better black box tests.
Unit testing checks individual functions or components, usually by developers.
Integration testing checks that modules work together, such as the frontend with an API.
System testing checks the complete application against requirements.
User acceptance testing (UAT) is done by business users or clients to confirm the software meets their needs before release.
Positive testing checks that the system works with valid input, such as logging in with a correct username and password. Negative testing checks that it handles invalid input and unexpected actions gracefully, such as wrong passwords, empty fields, special characters, very long input or expired sessions, showing clear errors without crashing.
A test scenario is a high-level description of what to test, such as "verify user login".
Test cases are detailed steps with test data and expected results for that scenario, such as login with valid credentials, with a wrong password and with a locked account.
A test script is usually an automated set of instructions that executes test cases.
An error is a human mistake, such as a developer misunderstanding a requirement.
It causes a defect (bug) in the code or document.
When the defective code runs and the system behaves incorrectly, that is a failure.
Not every defect causes a failure, for example if the faulty code is never executed.
Retesting checks that a specific defect has been fixed, by running the failed test case again with the same steps.
Regression testing checks that the fix or any other change has not broken features that worked before, by running a wider set of existing tests.
Retesting is planned for fixed bugs; regression testing is done after every change.
Applied problems, trade-offs and questions about your own projects.
A good test case has a unique ID, a clear title, preconditions, test data, precise steps, and an expected result for each step.
It tests one thing, is easy for anyone to execute and repeat, is traceable to a requirement, and covers positive, negative and edge cases.
It should be independent of other test cases.
Equivalence partitioning divides inputs into groups that should behave the same, and tests one value from each group.
For an age field accepting 18 to 60, the partitions are below 18, 18 to 60 and above 60.
Boundary value analysis tests values at and around the edges, such as 17, 18, 19, 59, 60 and 61, because bugs often occur at boundaries.
Smoke testing is a quick, broad check that a new build's main functions work and it is stable enough for detailed testing.
Sanity testing is a narrow check that a specific fix or change works correctly.
Regression testing re-runs tests to make sure recent changes have not broken existing features, and is a common target for automation.
A defect starts as New when logged, is Assigned to a developer, becomes Open while being worked on, then Fixed.
The tester retests it: if it works it is Verified and Closed, and if not it is Reopened.
Other statuses include Rejected (not a bug), Duplicate, Deferred (to be fixed later) and Not Reproducible.
Decision table testing lists combinations of conditions and the expected action for each, which suits business rules with several inputs. For example, a loan approval might depend on salary above a limit, a good credit score and existing loans; the table lists every combination and the expected result, making sure none is missed and revealing gaps in the requirements.
State transition testing checks how a system moves between states in response to events, such as an account that becomes locked after three wrong passwords, or an order moving from placed to paid to shipped to delivered. You draw a state diagram and design tests for valid transitions and for invalid ones that should be blocked, such as shipping an unpaid order.
Exploratory testing is simultaneous learning, test design and execution, guided by a charter (a goal such as "explore checkout with discount codes") and time-boxed sessions, with notes on what was tested and found.
Ad hoc testing is informal, unplanned testing without documentation.
Both find bugs that scripted tests miss, especially in new features.
A requirements traceability matrix maps each requirement to the test cases that cover it, and often to test results and defects. It shows that every requirement is tested, helps find which tests to run when a requirement changes, and gives evidence of coverage for audits and sign-offs.
Break the work into tasks (understanding requirements, writing test cases, preparing data and environments, execution, retesting and regression, reporting) and estimate each, using past data from similar projects.
Techniques include work breakdown structure, three-point estimation (optimistic, most likely, pessimistic), test case point analysis and, in agile, story points.
Add a buffer for retesting and environment issues.
Functional checks: valid login, wrong password, unregistered user, empty fields, case sensitivity, password masking, remember me, forgot password, logout and session expiry.
Security checks: account lockout after failed attempts, error messages that do not reveal whether the username exists, HTTPS, protection against SQL injection and brute force.
Also usability, accessibility (labels, keyboard use), different browsers and devices, and performance under load.
From ISTQB: testing shows the presence of defects, not their absence; exhaustive testing is impossible; early testing saves time and money; defects cluster in a few modules; repeating the same tests stops finding new bugs (the pesticide paradox), so tests must be updated; testing depends on context; and an absence of errors does not mean the system is useful (the absence-of-errors fallacy).
System design, deep internals, leadership and tough follow-ups.
A test plan defines the objectives, scope (in and out), test approach and types of testing, entry and exit criteria, environment and tools, roles and responsibilities, schedule and milestones, deliverables, risks and mitigations, and how defects will be tracked and reported. It is agreed with stakeholders before testing starts.
I use risk-based testing: I prioritise features by business impact and likelihood of failure, focusing on critical user journeys such as login and payment, recently changed areas, and areas with a history of defects. I run smoke tests first, then high-priority cases, use exploratory testing to cover gaps, and clearly communicate what was not tested and the remaining risk.
In agile, testers are involved from the start: refining user stories and acceptance criteria with the product owner, identifying risks and edge cases early, testing stories within the sprint, pairing with developers, doing exploratory testing, contributing to automation, and taking part in stand-ups, reviews and retrospectives. Quality becomes the whole team's responsibility, with testers leading it.
Read the API documentation, then send requests with the right method, headers, authentication and body, and check status codes, response bodies, headers, response times and error handling for invalid input, missing fields and unauthorised access. Collections organise requests, environments store variables such as base URLs and tokens, scripts chain requests and add assertions, and Newman runs collections in CI.
Mobile testing must cover many devices, screen sizes and operating system versions, touch gestures, portrait and landscape orientation, interruptions such as calls and notifications, poor or changing network conditions and offline mode, battery and memory usage, permissions, background and foreground behaviour, app updates and installation. Real devices and cloud device farms are used alongside emulators.
Database testing checks that the application stores and retrieves data correctly. Testers use SQL to verify that records are created, updated and deleted as expected after actions in the UI or API, that constraints and data types are enforced, that transactions roll back on failure, that stored procedures and triggers work, and that migrations preserve existing data.
For performance, understand load, stress, spike and endurance testing, key metrics such as response time, throughput and error rate, and tools such as JMeter or k6, so you can spot slow pages and plan tests. For security, know the OWASP Top 10, check authentication, authorisation (can one user see another user's data by changing an ID in the URL?), input validation and session handling, and report issues to specialists.
Test execution progress (planned, executed, passed, failed and blocked), requirement coverage, defects found by severity and status, defect density per module, defect leakage to production, defect removal efficiency, reopen rate and average time to fix. Metrics should support decisions, such as whether the release is ready, and be presented with context, not used to judge individuals.
See all QA Engineer interview questions, covering Manual Testing, Test Cases & Test Plans, Selenium, Cypress, Playwright and more.