Introduction: Why Everyone Searches for Manual Testing Interview Questions
- If you are preparing for a QA or software testing interview, one of the first things you search online is manual testing interview questions.
- Why? Because manual testing is the foundation of software testing, and almost every company starts interviews with manual testing concepts.
- Whether you are:
- A fresher
- A manual tester with 1–5 years of experience
- Switching from automation to QA
- Preparing for MNCs or product-based companies
- You will face basic + real-time manual testing interview questions.
- This article is a complete, beginner-friendly, job-oriented guide covering:
- Top questions to manual testing
- Scenario-based questions
- Real company interview rounds
- Best answers to manual testing interview questions
- Final revision sheet
What Is Manual Testing? (Simple Explanation)
Manual testing is the process of testing software manually without using automation tools.
It Simple Definition
Manual testing means:
A tester checks the application by hand, acting like a real user, to find bugs.
Real Example
Suppose you are testing a login page:
Enter valid username + password → Should login
Enter wrong password → Error message should appear
Leave fields empty → Validation message should appear
All this testing is done manually, without writing any code.
Why Companies Ask Manual Testing Interview Questions?
Companies use interview questions for QA because:
Manual testing shows testing fundamentals.
It proves your logical thinking
It checks project experience in real time.
Automation is useless without strong manual basics
Bugs are first identified manually in real projects
Most interviewers believe:
“A good automation tester must first be a good manual tester.”
Top Manual Testing Interview Questions with Answers
Below are top manual testing questions asked in real interviews.
1. What is Software Testing?
Answer:
Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that software product is Defect free. It involves execution of software/system components using manual or automated tools to evaluate one or more properties of interest. The purpose of software testing is to identify errors, gaps, or missing requirements in contrast to actual requirements.
Some prefer Software testing definitions such as White Box and Black Box Testing. In simple terms, Software Testing means the Verification of Application Under Test (AUT). This Software Testing course introduces testing software to the audience and justifies the importance of software testing. As per ANSI/IEEE 1059, Testing in Software Engineering is a process of evaluating a software product to find out whether the current software product meets the required conditions or not.
2. What are the types of testing?
Answer:
Types of Software Testing
- The different types of software testing are listed below −
- 1. Manual Testing
- It is done to verify the software using its functionalities and features. It is performed with a defined group of test cases which are created and executed with human intervention. It helps to give quick and visual feedback on the dynamically changing elements of the software. It is less expensive, as it does not require many skilled resources. It can be done without any coding or programming knowledge. It is usually useful in scenarios where accidental updates need to be made on the software.
- 2. Automation Testing
- It is done by creating test scripts with the help of automation tools. It is mostly useful for manual test cases which are lengthy and contain redundant test steps. It does not require manual intervention until the test results are generated. Thus, it enhances the productivity of the testing process. This type of testing is more reliable as there are no chances of human error. It improves the test coverage and detects more issues in the software.
3. What is SDLC?
Answer:
- The software development lifecycle (SDLC) is a structured and iterative methodology used by development teams to build, deliver and maintain high-quality and cost-effective software systems.
- The SDLC breaks down software development into distinct, repeatable, interdependent phases. Each phase of the SDLC has its own objectives and deliverables that guide the next phase. Taken together, the phases of the SDLC form a roadmap that helps development teams create software that meets stakeholder needs, project requirements, and customer expectations.
- There are various SDLC models, and each approaches the phases of the SDLC in its own way. In some models, such as the waterfall model, the phases are completed sequentially. In other words, more iterative processes, such as agile, phases can be worked in parallel.
- Software development involves the balancing of many factors, such as competing stakeholder needs, resource availability, and the larger IT environment into which the software fits. The SDLC provides a framework for managing and aligning these factors, facilitating a more streamlined development process.
- The SDLC helps stakeholders estimate project costs and time frames, identify potential challenges, and address risk factors early in the development of lifecycle. It also helps measure development progress, enhance documentation and transparency, and better align software projects with organizational goals.
4. What is STLC?
Answer:
- The Software Testing Life Cycle (STLC) is a structured framework that guides testing from initial requirements through final validation and retrospective. Instead of treating testing as an afterthought, STLC makes it a disciplined, repeatable process that catches issues before they reach users. Its core phases stay consistent across Scrum, Kanban, and Waterfall, making it adaptable to virtually any team.
- For modern teams building AI-driven systems, execution depends on having the right people in place. Platforms like Fonzi AI help companies quickly hire experienced engineers and QA specialists who can implement automated, STLC-aligned workflows, so recruiters and technical leaders can build reliable systems without sacrificing speed.
5. What is a Test Case?
Answer:
A test case is a set of actions performed on a system to determine if it satisfies software requirements and functions correctly. The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.
Test cases are typically written by members of the quality assurance (QA) team or the testing team and used step-by-step instructions for each system test. The testing process begins once the development team has finished a system feature or set of features. A sequence or collection of test cases is called a test suite.
6. Difference Between Verification and Validation?
| Key | Verification | Validation |
| Definition | Verification is the process in which product or system is evaluated in the development phase to find out whether it meets the specified requirements or not. | Validation is the process in which a product or system is evaluated at the end of the development process to determine whether software meets the customer’s expectations and requirements or not. |
| Objective | The main objective of Verification process is to make sure that the system being developed is as per the requirements and design specifications of the customer and if it deviates from it then make it correct in the development phase itself. | The objective of Validation is to make sure that the product which has been developed actually meets the user’s requirements or not. And if it is not then making it to the level of acceptance in the development phase. |
| Activities | Main activities which define the Verification process are Reviews of specification and product development, Meetings about diversification and inspections. | Activities under Validation process are typically different types of testing such as Black Box testing, White Box testing, grey box testing etc. which ensure the defect free delivery of product as per specification document. |
| Type | Verification is the process where execution of code is not taking place and hence it comes under static testing. | During Validation, execution of code takes place and thus it comes under dynamic testing. |
| Sequence | Verification is carried out before the Validation. | Validation is carried out just after the Verification |
| Performer | Verification is carried out by the Quality Assurance team. | Validation is executed on software code with the help of the testing team. |
7. What is a Bug / Defect?
Answer:
A bug in software testing refers to an error in the code that causes the software to behave differently than expected. It occurs when the actual result of a function does not match the expected result during any stage of development.
In simpler terms, a bug is an issue that prevents a software system from working correctly. These errors can be found at any phase, from coding to integration testing, and they can lead to major issues if not detected early.
8. Bug Life Cycle (Defect Life Cycle)
- The defective life cycle (also called bug life cycle) is the sequence of states a software defect passes through from initial discovery until final closure. Every defect follows a defined path: it gets reported, assigned, fixed, verified, and closed.
- Understanding this cycle matters because it directly affects how quickly your team resolves issues and how reliably your software performs. Teams that manage defects well ship better products faster. Teams that do not end up with confused developers, frustrated testers, and buggy releases.
- This guide covers everything you need to manage defects effectively: the standard states and transitions, how to distinguish severity from priority, writing defect reports that developers can use, and selecting the right tools for your team.
9. What is Severity and Priority?
The impact of the bug on the application is known as severity.
It can be a blocker, critical, major, and minor for the bug.
Blocker: if the severity of a bug is a blocker, which means we cannot proceed to the next module, and unnecessarily test engineer sits ideal.
There are two types of blocker bug, which are as follows:
A major feature is not working Login to HDFC, amount transfer is not working
The major flow is not working Login and signup not working in HDFC applications.
Critical: if it is critical, that means the main functionality is not working, and the test engineer cannot continue testing.
Major: If it is major, which means that the supporting components and modules are not working fine, but test engineers can continue the testing.
Minor: If the severity of a bug is major, which means that all the U.I problems are not working fine, but testing can be processed without interruption.
Priority
Priority is important for fixing the bug or which bug to be fixed first or how soon the bug should be fixed.
It can be urgent, high, medium, and low.
High: it has a major impact on the customer application, and it must be fixed first.
Medium: In this, the problem should be fixed before the release of the current version in development.
Low: The flow should be fixed if there is time, but it can be deferred with the next release.
10. What is Regression Testing?
Answer:
Regression Testing is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features. We can also say it is nothing but a full or partial selection of already executed test cases that are re-executed to ensure existing functionalities work fine.
This type of testing is done to ensure that new code changes do not have any side effects on existing functionalities. It ensures that the old code still works once the latest code changes are done.
Real-Time Manual Testing Interview Questions
These real-time manual testing questions are commonly asked.
11. What documents do you prepare for a project?
Answer:
- Software testing is not just about running test cases anymore; it’s about having the right documentation to guide, track, and validate the testing effort. Testing documents helps to create transparency, streamline communication, and help teams manage quality in a predictable, repeatable way.
- In this article, we’ll go through the testing documents every project should consider, what purpose each serves, how to create them, and whether they are required or optional depending on the project’s size and complexity.
- 1. Test Strategy — Required
- What It Is
- A high-level document which defines the overall approach to testing across the entire project or organization.
- Why It Matters
- It ensures everyone understands how testing will be carried out: methodologies, tools, levels of testing, environments, exit criteria, risks, and responsibilities.
- Gist of the Document
- Clarifies testing types (functional, non-functional, regression, performance, etc.)
- Defines testing scope
- Outlines test environments and tools
- Highlights risk-based areas
- Standardizes testing processes
- How to Create
- Identify project goals and risks
- Choose testing models (Waterfall, Agile, Hybrid)
- Document environments, tools, test levels, and responsibilities
- Keep it concise — usually 3–5 pages
- 2. Test Plan — Required
- What It Is
- A detailed, project-specific plan that describes what will be tested, how, when, and by whom.
- Why It Matters
- It makes the testing process executable. The plan transforms the high-level test strategy into concrete actions.
- Gist of the Document
- Testing timeline and milestones
- In-scope & out-of-scope features
- Roles and responsibilities
- Entry & exit criteria
- Test deliverables
- Resource and environment requirements
- How to Create
- Break down project features/modules
- Map test types to modules
- Estimate effort & timelines
- Include risks & mitigations
- Use templates to maintain consistency
- 3. Test Scenarios — Optional but Highly Recommended
- What They Are
- High-level descriptions of what needs to be tested, written from the user or system perspective.
- Why They Matter
- They provide a big-picture view of test coverage without going into step-by-step detail.
- Gist of the Document
- Clear, user-focused scenarios
- Mapped to requirements or user stories
- Helps catch coverage gaps early
- How to Create
- Translate acceptance criteria or requirements into flows
- Write in simple language
- One scenario per behavior or interaction
- 4. Test Cases — Required (for Formal Testing)
- What They Are
- Step-by-step instructions defining how to validate a given functionality.
- Why They Matter
- They ensure repeatable and consistent validation, especially for regulated, enterprise, or long-term projects.
- Gist of the Document
- Prerequisites
- Test steps
- Expected results
- Actual results
- Pass/fail status
- How to Create
- Break each test scenario into actionable steps
- Aim for clarity, not verbosity
- Add visual references or data samples were useful
- Version control them, especially in Agile projects
- 5. Test Data Document — Optional
- What It Is
- A repository of the data sets used during testing.
- Why It Matters
- Poor test data often leads to incomplete testing or inconsistent results.
- Gist of the Document
- Valid and invalid data sets
- Boundary values
- Mock/stub data for unavailable integrations
- Security and masking guidelines
- How to Create
- Derive data from test cases
- Include edge cases explicitly
- Mask real data or use synthetic data
- Store in a shared tool (Excel, GSheet, database)
- 6. Requirements Traceability Matrix (RTM) — Required
- What It Is
- A matrix mapping requirement to test scenarios/cases.
- Why It Matters
- It ensures that every requirement has corresponding test coverage and helps during audits.
- Gist of the Document
- Requirement ID
- Scenario/Case ID
- Status mapping
- Coverage view: fully, partially, or untested
- How to Create
- Pull requirement IDs from BRD, PRD, or user stories
- Link them to test cases
- Automate if possible (Jira, TestRail, Zephyr)
- 7. Defect Report — Required
- What It Is
- A detailed account of a defect found during testing.
- Why It Matters
- It ensures developers understand what’s wrong, how to reproduce it, and how critical it is.
- Gist of the Document
- Steps to reproduce
- Expected vs actual behavior
- Screenshots or logs
- Severity & priority
- Environment info
- How to Create
- Reproduce before logging
- Keep descriptions factual
- Use templates for consistency
- Include system logs if available
- 8. Daily/Weekly Test Status Reports — Optional
- What They Are
- Regular updates that summarize testing progress, blockers, and risks.
- Why They Matter
- Great for stakeholder alignment, especially in large or distributed teams.
- Gist of the Document
- Completed tests
- Pending tests
- Defects summary
- Risks/blockers
- Planned work
- How to Create
- Automate from your test management tool
- Keep it to one page or a dashboard
- Highlight critical issues, not everything
- 9. Test Summary Report / Test Closure Report — Required
- What It Is
- A final document summarizing the entire testing effort after the cycle is complete.
- Why It Matters
- It validates whether the product is ready for release and provides a historical reference for future projects.
- Gist of the Document
- Testing coverage results
- Defects summary & unresolved issues
- Environment comparisons
- Metrics (pass rate, defect density, test execution rate)
- Sign-off statement
- How to Create It
- Extract metrics from test management tools
- Summarize — not repeat — details
- Document lessons learned
12. How do you write test cases?
Answer:
- How to Write Test Cases: A Step-by-step Process
- Follow these steps to write test cases that are both thorough and practical.
- Step 1: Understand the Requirement
- Before writing anything, read the requirement, user story, or acceptance criteria. Ask:
- What is the feature supposed to do?
- Who is the user?
- What are the edge cases?
- If you don’t understand the requirement, ask questions early. A test case based on a misunderstanding waste everyone’s time.
- Step 2: Identify Test Conditions
- Break the requirement into testable conditions. For a login feature, conditions include:
- Valid username and password.
- Invalid username.
- Invalid password.
- empty fields.
- Case sensitivity.
- Password visibility toggle.
- Each condition will become one or more test cases.
- Step 3: Write Clear and Concise Test Steps
- Test steps should be so clear that another tester (or a robot) can follow them without interpretation. Use imperatives and numbered lists.
- Poor: Enter username and password and click login.
Good:
- Enter john.doe@example.com in the Username field.
- Enter P@ssw0rd in the Password field.
- Click the “Login” button.
- Tips for writing good test steps:
- Start each step with an action verb (Enter, Click, Select, Verify, Navigate).
- Specify exact UI element names (e.g., “Login button” not “the button”).
- Include specific test data values.
- Avoid combining multiple actions in one step.
- Step 4: Define Expected Results
- For each step (or for the test case as a whole), state what should happen. Expected results must be observable and verifiable.
- Good, expected result: “After clicking Login, the dashboard page loads with a welcome message ‘Hello, John’ and no error messages appear.”
- Bad expected result: “System works correctly.”
- Step 5: Use Appropriate Test Data
- Test data is the specific input you provide. When you write test cases, avoid vague data like “enter a valid email.” Instead, write “enter user+test@example.com” This makes the test more repeatable.
- For negative tests, use clearly invalid data, e.g., “enter not-an-email” or “enter a password with 5 characters where minimum is 8.”
- Step 6: Keep Test Cases Independent
- One test case should test one thing. If you have a test case that covers “valid login” and “profile update” and “logout,” it’s too large. When it fails, you won’t know which part broke.
- Good practice: Each test case has a single, clear objective. This also makes it easier to reuse test cases for regression.
- Step 7: Review and Peer Review
- After you write test cases, ask a colleague to review them. A fresh set of eyes will spot ambiguous steps, missing preconditions, or incorrect expected results.
- Step 8: Maintain and Update
- Test cases are living documents. When the software changes, update your test cases. Otherwise, they become technical debt that confuses future testers.
- Real Test Case Examples
- Let’s look at three concrete examples of how to write test cases for different scenarios.
- Example 1: Positive Login Test
| Field | Value |
| ID | TC_LOGIN_001 |
| Title | Valid user login with correct credentials |
| Preconditions | Test user account exists (username: testqa@testunity.com, password: Test@2026). Browser is on login page https://example.com/login. |
| Steps | 1. Entertestqa @testunity.com in the Email field. 2. Enter Test@2026 in the Password field. 3. Click the “Sign In” button. |
| Expected Result | User is redirected to the dashboard page. URL contains /dashboard. Welcome message “Welcome back, testqa” appears. No error messages are shown. |
| Postconditions | User sessions are active. Logout options are available in the navigation menu. |
13. What if requirements are unclear?
Answer:
- One of the most common real-world challenges a QA engineer faces is unclear or incomplete requirements.
In interviews, this is often asked as a scenario question, but in real projects, it happens more often than we expect.
- As a QA, how we handle unclear requirements directly impacts product quality, timelines, and team trust. Handling this situation well is one of the strongest indicators of a mature QA mindset.
A good QA understands that asking questions is not a weakness — it is a responsibility.
Step 1: Identify what is unclear
The first step is to clearly identify what is unclear.
Examples:
What should happen if the input is empty?
What is the expected behavior of failure?
Are there limits (minimum / maximum values)?
Is this behavior the same on all platforms?
Instead of saying “the requirement is unclear”, a QA should point out specific gaps.
Step 2: Ask the right questions
Once the gaps are identified, the QA should ask questions from the right stakeholders, such as:
Business Analyst (BA)
Product Owner (PO)
Team Lead
Developer (for technical clarification)
The questions should be:
Clear
Specific
Based on scenarios
For example:
“What should happen if the payment fails after money is deducted?”
“Should this field be mandatory or optional?”
This helps avoid misunderstandings later.
Step 3: Refer existing sources
If direct clarification is not immediately available, a QA can refer to:
Requirement documents
User stories and acceptance criteria
Design mockups or wireframes
Existing similar features
Previous system behavior
Sometimes, past behavior gives strong clues about expected behavior, especially in enhancement tasks.
Step 4: Communicate and document
Once clarification is received, it is important to:
Document the agreed behavior
Update test cases
Align with developers
This ensures that everyone in the team is on the same page and avoids future confusion.
Clear documentation also helps new team members understand the feature quickly.
Step 5: Use exploratory testing wisely
Press enter or click to view image in full size
When requirements are partially unclear, exploratory testing becomes very useful.
Exploratory testing helps QA:
Understand system behavior
Identify hidden scenarios
Prepare better questions for stakeholders
However, exploratory testing should not replace requirement clarification. It should support it.
14. How do you decide on test coverage?
Answer:
Here are proven ways to improve test coverage without adding unnecessary work:
- Start with a Coverage Report: Use tools to find untested parts of your code.
- Automate Regression Tests: Automated tests save time and increase consistency.
- Prioritize High-Risk Areas: Don’t try to test everything equally. Focus on what matters most.
- Write Better Test Cases: Think about edge cases, boundary values, and real usage.
- Use Pairwise Testing: It helps cover combinations of inputs with fewer tests.
- Review Tests Regularly: Keep them aligned with code changes.
- Test Across Devices and Browsers: This is key for web and mobile apps. Incorporate browser testing to ensure consistent user experiences across different browsers and use compatibility testing to verify your software works correctly on various devices, operating systems, and environments.
- Leverage Code Reviews: Encourage devs to write tests alongside features.
- Train Your Team: Help them understand what good coverage looks like.
Scenario-Based Manual Testing Interview Questions (Most Important)
These scenario-based questions are asked in almost every interview.
1. Login button works but nothing happens. What will you do?
Answer:
Troubleshooting when clicking the Sign In button fails to initiate the login process
If you encounter an issue were clicking the “Sign In” button does not initiate the login process, this could be due to network restrictions placed by your institution or a third-party web filtering platform.
Here’s what you can do to resolve this issue.
Step-by-step troubleshooting guide:
Check browser console
- Open your browser’s developer tools (usually accessed by pressing F12 or right-clicking and selecting “Inspect”).
- Navigate to the ‘Console’ tab to check for any errors related to network requests.
Verify network requests
- Look for a network request to https://auth.digitaltheatreplus.com.
- If this request fails or is blocked, this indicates a network issue that is preventing the Sign In process.
Contact local IT support
- Report the issue to your local IT team. Provide them with the details of the blocked network request.
- Ask IT to check for any active web filtering settings that might be blocking access to authentication URLs.
Web filtering adjustments
- If a web filtering platform is in use, request that your IT team or filtering provider allow traffic to https://auth.digitaltheatreplus.com and consider whether any of our other domains need to be permitted.
Retry Sign In
- Once adjustments are made, retry the Sign In process. If the issue persists, further investigation by IT might be necessary.
By following these steps, you should be able to overcome any network-related barriers that prevent the Sign In process from starting, ensuring a smoother and more reliable access to our services.
Updated Application Behavior (14 May 2024)
DT+ now detects when a Sign In initiation fails due to a failed network request. If such a failure occurs, an error message will be displayed advising users to contact their local IT for assistance. This proactive measure helps in identifying and resolving access issues more quickly.
The error displayed is “An error occurred fetching the authentication configuration. This may be due to network restrictions. Please contact your IT support for assistance.”
2. Developer says, “It’s working on my machine”. What will you do?
Answer:
- When a developer says, “It’s working on my machine”, you should take the following steps:
- Verify the environment: Ensure that the developer has correctly set up the environment to match the production environment.
- Check for dependencies: Verify that all necessary dependencies are installed and correctly configured.
- Review the code: Look for any potential edge cases or conditions that might cause the code to behave differently in the production environment.
- Test the code: Conduct thorough testing to identify and fix any issues that might arise in the production environment.
- Communicate the issue: Clearly communicate the problem to the developer and provide guidance on how to resolve it.
- Document the solution: Document the solution to the issue to prevent it from happening again in the future.
- By following these steps, you can help ensure that the developer’s code works correctly in the production environment and that the team can ship reliable software
- 3. No requirements document available. How will you test?
Answer:
Testing without Requirements:
- Testing without clear guidelines might seem like an impossible task, but it’s an opportunity to sharpen our critical thinking skills.
- Instead of following a checklist, we become investigators, uncovering issues that might have otherwise gone unnoticed.
- We just got assigned to test an application, but there are no requirements, no documentation, and no clear guidelines.
- It might seem overwhelming at first, but the good news is that software testers deal with this challenge more often than anyone would think.
- The key is to approach testing strategically, using a mix of curiosity, logic, and structured thinking.
Understanding the Application:
- Before jumping into testing, we must take some time to explore and gather information.
- Even without formal documentation, there are always clues about how the application is supposed to work.
- We can start by asking team members-developers, product managers, or customer support – about the app’s purpose and main functionalities.
- They may not give you a detailed specification, but even a few insights can be useful. If the team uses a test management tool like JIRA, we can check if there are any past testcases that could provide context.
- Next, we can analyze the application’s interface. UI elements like buttons, forms, and menus often suggest the intended functionalities. If the application is like others in its industry,
- We can look at competitors to understand common features and expected behavior.
Identify Core Features and Users Scenarios:
- Since we don’t have predefined requirements, we need to determine what is important on our own. The easiest way to do this is by thinking about the typical user journey.
- Ask ourselves what the product’s primary function is. If it’s a shopping app, users will likely need to browse products, add them to a cart, and complete a purchase. If it’s a messaging app, sending and receiving messages will be key. Break down the main workflows and consider what could go wrong at each step.
- At this stage, it can also be helpful to note any unexpected behaviors.
- Are there areas where the UI is unclear?
- Do certain actions lead to errors or crashes?
- These observations will guide test planning.
Perform Exploratory Testing:
- Without formal test cases, exploratory testing is our best approach.
- Instead of following a strict script, we can interact with the application like a real user, observing how it behaves.
- We can also Try different types of inputs – valid and invalid – to see how the system handles them. Navigate through the application in different ways, including actions users might take
- by mistake, like refreshing a page during a transaction.
- Test how the application responds to slow internet connections, interrupted actions, and unexpected user behavior.
- Look for consistency across the application. Do buttons with similar functions behave the same way?
- Are error messages clear and helpful?
- Keep track of anything that seems off.
- Using a tool like JIRA can help document findings efficiently, even during exploratory testing.
Create Test Scenarios Based on Observations:
- Once we have a good understanding of the application, we can start defining test scenarios. These don’t have to be as detailed as traditional test cases, but they should outline the key
- areas to cover.
- Focus on core functionality first.
- If the product requires authentication, test different login methods, including valid credentials, incorrect passwords, and edge cases like an expired session. If it processes payments, verify how it handles different payment methods, incorrect card details, and refunds.
- Next, we can consider usability.
- Is the product intuitive?
- Are common actions easy to complete?
- If certain areas are confusing, that’s a usability issue worth reporting.
- Finally, test the application’s stability and compatibility.
- We can try it on different devices, browsers, and screen sizes. If it integrates with third party services, verify that those connections work smoothly.
Communicate Findings Clearly:
- When reporting issues, we should be as specific as possible. Include steps to reproduce, expected vs. actual results, and any supporting screen shots or logs.
- Developers will appreciate well-documented bug reports that help them fix issues faster.
- If we notice patterns – such as frequent UI inconsistencies or repeated crashes in certain scenarios – we should highlight these as broader concerns. Sometimes, identifying common themes in defects is just as valuable as reporting individual bugs.
- Without official requirements, our insights carry even more weight.
- Our findings may help shape the development process, influence future decisions, and improve the overall user experience.
4. How do you test a text box?
Answer:
Text boxes serve numerous purposes in software applications. Here are some common use cases:
- Data Input: Text boxes are widely used in forms to capture user input such as names, addresses, and other essential information.
- Password Entry: For security, text boxes can be configured to hide input characters, allowing users to enter passwords safely during account logins.
- Search Functionality: Many websites implement text boxes for search purposes, enabling users to enter queries and retrieve relevant results quickly.
- Comments and Descriptions: Text boxes facilitate the entry of longer text, allowing users to provide detailed comments, reviews, or descriptions relevant to their submissions.
- Username/Email Entry: Essential for account creation and login processes; text boxes are used to capture usernames and email addresses in a user-friendly manner.
- Numeric Input: Certain applications may require numeric data entry, for which a text box can be validated to restrict input to numbers only.
- Date and Time Input: Specialized text boxes can help users enter dates and times consistently, often employing format restrictions to ensure proper data entry.
- Surveys and Form Fields: Text boxes play a critical role in surveys and forms, gathering feedback, preferences, and other data from users.
- Text Editing in Documents and Editors: In text editors and word processing applications, text boxes are integral for editing and formatting text, allowing users to create documents effectively.
- Chat Interfaces: Enabling real-time communication through message input.
- Configuration Settings: Letting users specify values for preferences or settings.
5. How do you test a payment page?
Answer:
1. Functional Testing
- Valid card details → Payment should be successful
- Invalid card details → Proper error message
- Expired card → Payment should be declined
- CVV/OTP validation
- Different payment methods (Card, UPI, Net Banking, Wallets)
2. Negative Testing
- Wrong card number format
- Empty fields submission
- Special characters in input fields
- Invalid OTP entry
3. Edge Cases
- Payment interruption (user closes browser/app)
- Multiple clicks on “Pay” button (duplicate transaction check)
- Session timeout during payment
- Refresh during transaction
4. Network & Performance Testing
- Network failure during transaction
- Slow internet handling
- Payment gateway timeout
- System response under heavy load
5. Security Testing
- Data encryption (HTTPS)
- No card details stored in plain text
- PCI-DSS compliance
- Protection against SQL injection, XSS
6. Integration Testing
- Payment gateway integration (like Razorpay/Stripe/PayPal)
- Correct status update after payment (Success/Failure/Pending)
- Order creation after successful payment
7. UI/UX Testing
- Proper error messages
- Clear instructions for users
- Responsive design (mobile + desktop)
8. Post-Payment Validation
- Payment receipt generation
- Email/SMS confirmation
- Correct transaction status in database
6. Production bug reported. What will you do?
Answer:
1. Stay Calm
- If a bug arises in production, the first thing a tester should do is stay calm. It is critical not to panic and to take your time assessing the situation before taking any action.
- Following the identification of the problem, immediate action must be taken to address the issue and prevent further damage or disruption of services. It’s also important to keep track of any changes made and test them thoroughly before releasing them into production.
2. Identify the Severity of the Bug
- It is important to Identify the Severity of the Bug, this could help in determining how quickly it should be addressed and what resources are required for resolution. After determining the severity of the bug, testers should document every relevant detail about it, including steps taken to reproduce it, environment details, expected versus actual results, and so on.
- They should then report their findings to developers so that they can investigate further and work on resolving any issues that have been identified.
3. Document the Bug
- If a bug is found in production, the first thing a tester should do is document the bug. This includes taking detailed notes on what happened and how it happened so that developers can quickly identify and resolve this issue.
- It’s also a good idea to include any relevant screenshots or videos of the bug in the activity, if possible. Following the documentation of the bug, it should be reported to the development team for further investigation and resolution.
4. Isolate the Bug
- If a bug is discovered in production, the important step for a tester is to isolate it. This means that all other factors must be eliminated, leaving only the bug as the source of any problems.
- Once isolated, further investigation can be conducted to determine what caused the problem and how to best resolve it. The goal should always be to address the root causes of similar bugs to prevent them from recurring in future releases.
5. Communicate with the Team
- It is essential that everyone is aware of the issue and that it is addressed as soon as possible. After speaking with my team, I would carry out additional research by replicating the steps that led to the discovery of the bug and documenting any findings manually or with any bug reporting tool like Shake bug. This will assist us in determining what caused the bug so that we can fix it appropriately.
6. Rollback (if possible)
- If a bug occurs in production, the first thing a tester should do is roll back (if possible). This helps in improving the system to its original state and avoiding further damage. After rolling back, it’s critical to investigate what caused the issue and how it can be avoided in the future. The next step would be to write tests that are specifically designed for this type of bug and can be used in future testing scenarios.
7. Implement a Quick Fix
- If a bug is found in production, The first thing a tester should do is implement a quick fix. This involves identifying what caused this issue and then ensuring that it does not occur again. The following step would be to document the steps taken to resolve the issue so that future issues can be avoided or quickly resolved if they arise. Finally, before releasing changes to production, testers must ensure that all tests are run on them.
8. Prioritize and Plan
- If a bug is found in production, a tester must prioritize and plan the best action. First, find the type of bug discovered and its severity. Then, depending on how serious the problem is, you can decide whether to fix it right away or wait until more resources are available. Once you’ve made that decision, you’ll need to develop a test plan to validate any changes before they go live again.
9. Test the Fix
- If a bug is found in production, the essential thing a tester must do is test the fix. This involves verifying that all the changes made by developers have been applied correctly and are working properly. It is also necessary to ensure that any new features or functions introduced because of this change do not introduce any new bugs into the system. To ensure proper coverage of all areas affected by the fix, testing should include both manual and automated tests.
10. Deploy the Fix
- If a bug arises in production, the first thing a tester should do is deploy the fix. This means that all necessary changes should be made and thoroughly tested before being deployed into production. Following deployment, it is critical to ensure that any regression tests on the new code have been performed so that no new bugs or issues are introduced. Finally, once everything has been checked and verified, the fix can be made available to users.
11. Post-Mortem Analysis
- A tester should conduct a post-mortem analysis. This entails investigating all aspects of the system, such as the code, architecture, and environment, to determine what caused the problem. Once identified, steps can be taken to ensure that similar issues do not occur in future releases.
- Furthermore, testers must document their findings to share them with other team members and stakeholders who may require this information when making decisions about future projects or changes.
12. Communicate with Users
- It is essential to understand what happened and how it affected testers to determine the best course of action for resolving the issue. Once you’ve identified the issue, you need to figure out why it occurred and create tests to ensure that similar issues don’t occur in future releases.
- Finally, once everything has been thoroughly tested, ensure that all stakeholders are informed of any changes or fixes made before returning anything to production.
13. Update Monitoring and Logging
- If a bug occurs in production, the first step for a tester is to update monitoring and logging. This will enable us to track any changes made before or after the issue occurred. This information can then be used to determine what caused the bug and how it could have been avoided.
- Furthermore, we should look for similar issues in other environments, such as staging or development, so that they can be addressed as soon as possible if necessary.
7. How do you prioritize test cases?
Answer:
When prioritizing test cases, it’s important to categorize them based on their impact and importance. Here are five common test case priority levels:
- Priority Level 0: Critical
These are the most important test cases. They test features that are crucial to the system’s core functionality. If these tests fail, the application may become unusable or unstable, which can delay releases.
- For example, sanity checks, login systems, payment processing, and end-to-end critical flows fall under this category. These tests should always be run first and immediately.
- Priority Level 1: High
Test cases in this level are important but not as critical as Level 1. Their failure won’t immediately break the application or block release, but it can still impact the user’s experience.
- Regression suites for key modules, such as user profile management or product search functionality, would fall into this category. These tests should be run after the critical tests are verified.
- Priority Level 2: Medium
Medium priority test cases focus on features that are important or standard functional tests but have less immediate impact if they fail.
- These may include non-essential UI elements or features that users interact with less often, such as API validations. While their failure won’t break the application, it can still affect the overall user experience.
- Priority Level 3: Low
These are low-priority or edge-case test cases. They cover minor features or edge cases that are rarely used.
- Examples include cosmetic changes, settings, or rare error-path scenarios that don’t impact core functionality. You can execute these tests last or when time permits, as they are least likely to affect the application.
- Priority Level 4: Trivial/Informational
- Trivial or informational priority test cases are executed on a “nice to know” basis and not on “must know before release”. The nature of P4 test cases is non-blocking, exploratory, and future-oriented, with resource flexibility.
- These test cases may include data migration validation to verify all customer records are migrated from legacy systems to the new systems with correct mappings, spot check large-volume data loading, check data stability on 24-hour soak testing for customer analytics pipeline, or trying out an unreleased feature branch to see how the new UI components might behave.
8. Build received late. The deadline is tomorrow. What will you do?
Answer:
1. Smoke Testing First
Start with smoke testing to check whether the build is stable. Verify basic functionalities like login, navigation, and core flows. If smoke fails, immediately report and stop further testing.
2. Critical Functionality Testing
Next, focus only on high-priority and business-critical features (e.g., payments, data saving, main workflows). Skip low-priority or cosmetic test cases for now. The goal is to ensure that the most important parts of the application are working.
3. Communicate Risks to Manager
Clearly inform your manager/stakeholders about:
Limited testing due to time constraints
Areas not tested
Potential risks or defects found
This ensures transparency and helps in making release decisions.
9. What if a bug is rejected?
Answer:
- Common Reasons for Bug Rejection
- Not a bug (expected behavior as per requirement)
- Duplicate issue (already logged earlier)
- Works as designed
- Cannot reproduce
- Environment issue (not occurring in dev/test setup)
- What You Should Do
- 1. Recheck the Bug
Verify the issue again:
- Follow exact steps
- Test in correct environment
- Ensure its reproducible
- 2. Validate with Requirements
Check BRD / SRS / user stories.
If the behavior matches the requirement, then it’s not a bug.
- 3. Provide Strong Evidence
If you still believe it’s a valid bug:
- Attach screenshots / videos
- Add logs or error messages
- Clearly mention steps to reproduce
- 4. Discuss with Developer / Team
Have a quick discussion instead of long back-and-forth comments. Many rejections happen due to misunderstandings.
- 5. Escalate if Needed
If you’re confident and it impacts functionality, discuss with QA lead or manager.
10. How do you test without test cases?
Answer:
How to Approach
1. Quickly understand the application
Explore the UI, requirements, or user stories.
Identify main features (login, dashboard, payments).
2. Identify critical flows.
First focus on high-impact areas:
core business functionality
End-to-end user journey
Frequently used features
3. Use exploratory testing.
Test like a user
Try valid, invalid, and edge-case inputs.
Navigate randomly and find unexpected issues.
4. Apply Test Scenarios
Without written test cases, think:
Positive scenario (valid inputs)
Negative scenario (invalid inputs)
Boundary cases.
5. Take notes while testing.
Write down what you tested.
Immediately record bugs
Keep track to avoid missing areas
6. Use past experience & checklists.
Use mental or saved checklists.
UI Validation
Error messages
Basic performance
Security basics (input validation)
7. Communicate coverage
Inform your team at the end:
The areas you tested
What couldn’t you cover?
Risks involved.
Real Company Interview Round Format (QA Manual Testing)
Typical Interview Rounds
- HR Round
- Background
- Role understanding
- Technical Round 1
- Manual testing interview questions
- Scenario-based questions
- Technical Round 2
- Real-time project discussion
- Defect handling
- Managerial Round
- Communication
- Ownership mindset
How to Answer Manual Testing Interview Questions Like a Pro
Use the STAR Framework
- Situation
- Task
- Action
- Result
Example:
“When a critical bug appeared in production, I analyzed logs, reproduced the issue, coordinated with developers, and verified the fix successfully.”
Common Mistakes Candidates Make
Avoid these mistakes:
- Giving bookish answers
- No real examples
- Not knowing defect life cycle
- Poor communication
- Blaming developers
Final Revision Sheet – Quick Prep
Must-Remember Topics:
- SDLC & STLC
- Test Case Writing
- Bug Life Cycle
- Severity vs Priority
- Regression, Smoke, Sanity
- Real-time scenarios
FAQs – Manual Testing Interview Questions
Q1. Is manual testing still in demand in 2026?
From industry data from leading analysts, over 65% of critical vulnerabilities in complex digital infrastructures still have to be detected by human intuition before they are put in production by 2026. While the push for total automation is relentless, the most resilient global enterprises have realized that relying solely on scripts often leads to high defect leakage in specialized sectors like Finance and Pharma. Manual Testing isn’t a relic of the past; it’s a sophisticated, strategic necessity for any organization that values precision over mere speed.
You’ve likely experienced the tension between the need to accelerate release cycles and the fear of sacrificing quality during a high-stakes digital transformation. We recognize that finding specialized testers who understand the nuances of regulated environments is a significant hurdle for your internal teams. This article provides a robust framework for a hybrid testing model that integrates human intelligence directly into your 2026 roadmap, aligning with our core philosophy of Technology, Talent, and Transformation. You’ll discover how to optimize your ROI and mitigate risks by balancing technical execution with the cognitive depth that only a Trusted Partner can provide.
Q2. Can freshers get QA jobs with manual testing?
Yes, manual testing jobs in QA are open for new employees. The demand for skilled testers, including those with manual testing experience, remains high in the tech industry. Manual testing is a key component of the Quality Assurance (QA) role, and companies are actively looking for fresh talent to join their teams. Entry-level QA positions, which often serve as a springboard to specialized roles in automation, performance testing, or QA leadership, are often secured by fresh recruits using their manual testing skills.
Q3. How many manual testing questions should I prepare?
There’s no fixed number but be properly prepared is more essential than have too many questions.
Ideal Range
40–60 questions for starters
60–80 questions for one to three years of experience
3 or more years of experience: 80–120 questions
What Is More Important Than Numbers
Focus on covering the following subjects rather than just counting questions:
1. Fundamentals (must be robust)
Bug Life Cycle: SDLC, STLC, Severity vs. Priority
2. Fundamental Testing Ideas
Test scenarios and cases
Testing methods (smoke, sanity, regression, etc.)
Black box methods
3. Situations in Real Time (Very Important)
Situation of a late build
Rejection of bugs
Absence of test cases
Strict deadlines
4. Useful Information
Creating test cases
Identifying errors in sample apps
Describe previous project work
5. Instruments & Procedure
Jira and tools for tracking bugs
Fundamentals of Agile Methodology
Astute Approach
Make 50–70 well-thought-out questions with concise responses.
Practice describing things in a straightforward language.
Incorporate real-time examples to impress interviewers.
Q4. Is automation mandatory for QA jobs?
Automation is not mandatory for QA jobs, but it is increasingly becoming a necessity. As companies continue to prioritize mechanization in their testing processes, the demand for skilled experts in this sector is expected to rise. Automation testers typically advance into automation roles, which generally show faster salary progression due to the technical depth and demand for hybrid testing-development expertise.