Introduction: Why Candidates Search for Basic Manual Testing Interview Questions
If you are a fresher, student, or beginner preparing for a QA or software testing interview, the first thing you usually search online is basic manual testing interview questions.
Why?
Because almost every QA interview starts with basic concepts.
Brief Explanation
Companies want to evaluate whether candidates understand the foundation of software testing before moving to advanced topics.
What Companies Check in Fresher QA Interviews
Companies hiring freshers or junior testers usually focus on fundamental skills and logical thinking.
Interviewers Check Whether You
- Understand fundamental testing concepts
- Can think logically
- Can explain answers in simple language
- Can handle basic real-time scenarios
Brief Explanation
These areas help interviewers evaluate communication skills, problem-solving ability, and basic testing knowledge.
Why Basic Manual Testing Questions Are Important
Basic concepts form the foundation of both manual and automation testing.
Importance of Strong Basics
If your basics are strong, you can confidently answer:
- Top manual testing questions
- Interview questions for QA roles
- Real-time manual testing questions
Brief Explanation
Strong fundamentals help candidates handle both theoretical and scenario-based interview questions effectively.
What This Article Covers
This article is a complete, SEO-optimized job preparation guide designed for beginners preparing for QA interviews.
Topics Included
- Basic manual testing interview questions with answers
- Scenario-based questions explained simply
- Real company interview round questions
- Easy frameworks to answer confidently
Brief Explanation
The guide helps freshers and beginners prepare step-by-step for manual testing and QA interviews with clear and simple explanations.
What is Manual Testing? (Simple Definition with Example)
Manual Testing is the most fundamental approach in the Software Testing Life Cycle (STLC). It is the process of manually testing software applications without the use of automation tools. The tester acts as the end-user and validates whether the software behaves as expected. Despite the growth of automation testing, manual testing remains essential because it helps in identifying usability issues, visual inconsistencies, and unexpected behavior that automation tools may miss.
In this article, we’ll cover the basics of manual testing, different types of manual testing, and examples to understand how it works in real-life projects.
Basics of Manual Testing
Manual Testing focuses on ensuring that the application is functioning correctly based on the given requirements. Here are the core fundamentals:
1. No Automation Tools Used
Testers execute test cases manually, step by step.
Tools like JIRA, Bugzilla, and Trello are used for tracking defects, but execution is done without code/scripts.
2. End-User Perspective
The tester plays the role of the actual user.
Validates both functionality and user experience.
3. Test Documentation
Includes Test Plan, Test Cases, Test Scenarios, and Bug Reports.
Example of a simple test case format:
4. Validation and Verification
Verification: Making sure the product is constructed appropriately (in accordance with specifications).
Validation: Making sure the appropriate product is created for the final consumer.
Manual Testing Types
Depending on the requirements of the project, manual testing uses a variety of testing techniques. The most typical kinds are listed below:
1. Unit Testing
Performed individual components or modules.
Developers usually do it, but manual testers may validate test data.
2. Integration Testing
ensures to work together two or more units.
Example: Testing that the user dashboard and login page work together.
3. System Testing
validates the application as a whole.
An e-commerce app’s overall testing, from login to checkout, is an example.
4. Smoke Testing
Build Verification Testing be another word on it.
A quick check to make sure the fundamental features are operational.
For example, checking if an app installs correctly and opens without crashing.
5. Sanity Testing
narrow and targeted testing after small changes.
Example: The tester only rechecks login after resolving a login bug.
6. Regression Testing
ensures that new changes do not cause problems with existing features.
Example: The tester rechecks the dashboard and login after adding an “Forgot Password” feature.
7. Usability Testing
emphasizes experience and user-friendliness.
Example: Verifying that the “Sign Up” button is accessible and visible.
8. Acceptance Testing
This is done to confirm that the application satisfies business needs.
often carried out during the User Acceptance Testing (UAT) stage.
9. Exploratory Testing
No predefined test cases; the tester explores the app.
Helps in finding unexpected defects.
10. Ad-hoc Testing
informal testing that is not recorded.
Example: Randomly trying invalid inputs to check system stability.
Instances of Manual Testing in Actual Projects
Example 1: Testing a Login Page
Scenario: A banking application login page.
Test Cases:
Enter correct username & password → Should login successfully.
Enter wrong password → Should show error message.
Leave fields empty → Should not allow login.
Check “Forgot Password” link → Should redirect properly.
Example 2: E-Commerce Checkout Flow
Scenario: Online shopping cart.
Test Cases:
Add items to cart → Items should be reflected in cart.
Apply discount coupon → Correct discount applied.
Enter invalid credit card → Show payment error.
Successful payment → Generate order confirmation email.
Example 3: Social media mobile app testing scenario.
Test Cases:
App installation on Android & iOS.
Navigation in portrait & landscape mode.
Upload image/video functionality.
push alerts and notifications.
Why Companies Ask Basic Manual Testing Interview Questions
1. Real project exposure
They want to know: Have you actually worked on real applications?
Not just theory. You should be able to explain:
- What project you worked on
- What features you tested
- What problems you faced
Basically: “Have you seen real bugs, real deadlines, real pressure?”
2. Defect analysis and communication
Not just finding bugs — but:
- Can you understand why the bug happened?
- Can you explain it clearly to developers without confusion or fights?
Good QA = clear communicator, not just bug reporter.
3. Test planning ability
They expect you to think ahead:
- What should be tested first?
- What can be skipped if there is less time?
- What is critical vs optional?
This shows you’re not blindly testing — you’re thinking.
4. Ownership mindset
This is very important.
Instead of saying: “I tested my part”, you should think:
- “Is this feature really ready for user?”
- “Did we miss any edge cases?”
You act like the feature is your responsibility, not just a task.
5. Risk-based testing skills
You won’t have time to test everything. So:
- Focus on high-risk areas (payments, login, core features)
- Less focus on low-impact areas
This shows maturity and smart decision-making.
At this level, companies expect you to act like a feature owner, not a test executor.
Real Workplace Angle
In real projects:
- Requirements are unclear
- Developers push urgent fixes
- Clients change expectations
Interviewers want testers who can think practically, not just reciting definitions.
Basic Manual Testing Interview Questions with Sample Answers
Below are the most asked basic manual testing interview questions, especially for freshers and beginners, with easy-to-understand answers.
1. What is Software Testing?
Answer:
Software testing is the process of evaluating a system with the intent of finding bugs. It is performed to check if the system satisfies its specified requirements and quality standards. It evaluates the system to validate its functionality.
Testing measures the system’s overall quality in terms of correctness, completeness, usability, performance, and other functional and non-functional attributes.
Software testing is not associated with uncovering potential bugs or defects. It also involves finding measures to improve the system’s efficiency and accuracy.
Basically, software testing is the combination of verification and validation.
2. What is Manual Testing?
Manual Testing is the most fundamental approach in the Software Testing Life Cycle (STLC). It is the process of manually testing software applications without the use of automation tools. The tester acts as the end-user and validates whether the software behaves as expected. Despite the growth of automation testing, manual testing remains essential because it helps in identifying usability issues, visual inconsistencies, and unexpected behavior that automation tools may miss.
In this article, we’ll cover the basics of manual testing, different types of manual testing, and examples to understand how it works in real-life projects.
Basics of Manual Testing
Manual Testing focuses on ensuring that the application is functioning correctly based on the given requirements. Here are the core fundamentals:
1. No Automation Tools Used
Testers execute test cases manually, step by step.
Tools like JIRA, Bugzilla, and Trello are used for tracking defects, but execution is done without code/scripts.
2. End-User Perspective
The tester plays the role of the actual user.
Validates both functionality and user experience.
3. Test Documentation
Includes Test Plan, Test Cases, Test Scenarios, and Bug Reports.
Example of a simple test case format:
4. Validation and Verification
Verification: Making sure the product is constructed appropriately (in accordance with specifications).
Validation: Making sure the appropriate product is created for the final consumer.
Manual Testing Types
Depending on the requirements of the project, manual testing uses a variety of testing techniques. The most typical kinds are listed below:
1. Unit Testing
Performed individual components or modules.
Developers usually do it, but manual testers may validate test data.
2. Integration Testing
ensures to work together two or more units.
Example: Testing that the user dashboard and login page work together.
3. System Testing
validates the application as a whole.
An e-commerce app’s overall testing, from login to checkout, is an example.
4. Smoke Testing
Build Verification Testing be another word on it.
A quick check to make sure the fundamental features are operational.
For example, checking if an app installs correctly and opens without crashing.
5. Sanity Testing
narrow and targeted testing after small changes.
Example: The tester only rechecks login after resolving a login bug.
6. Regression Testing
ensures that new changes do not cause problems with existing features.
Example: The tester rechecks the dashboard and login after adding an “Forgot Password” feature.
7. Usability Testing
emphasizes experience and user-friendliness.
Example: Verifying that the “Sign Up” button is accessible and visible.
8. Acceptance Testing
This is done to confirm that the application satisfies business needs.
often carried out during the User Acceptance Testing (UAT) stage.
9. Exploratory Testing
No predefined test cases; the tester explores the app.
Helps in finding unexpected defects.
10. Ad-hoc Testing
informal testing that is not recorded.
Example: Randomly trying invalid inputs to check system stability.
Instances of Manual Testing in Actual Projects
3. Why is Software Testing Important?
Software testing is important because it ensures a software application works correctly before users interact with it. Without testing, a software product may contain hidden defects that affect functionality and reliability.
Testing software helps development teams confirm that the software system performs according to specified requirements. It also prevents costly errors and improves overall software reliability.
Thorough testing allows organizations to deliver a high quality product that meets user expectations. In modern software development, testing has become a critical part of the development process.
4. What is a Bug or Defect?
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.
5. What is a Test Case?
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. What is the Software Testing Life Cycle (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.
7. What is 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. |
8. What is Smoke Testing?
Smoke testing checks the basic functionality of a software program. Its purpose is to test whether the software can perform the tasks it’s designed to carry out without “smoking,” or failing.
Ideally, teams should run smoke tests at key checkpoints in the QA workflow (for example, after a new build or deployment to a test environment). Together with sanity testing, smoke testing is a great way to make sure that the software performs its basic functions after each update.
9. What is Regression Testing?
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.
10. What is Sanity Testing?
Sanity Testing
Sanity testing is a narrow, high-level check performed after small code changes such as bug fixes or minor enhancements. This focused testing helps verify that the specific functionality affected still works correctly.
Purpose of Sanity Testing
- Verifies that recent changes have not broken the related functionality
- Ensures the application is stable enough for further testing
- Acts as a quick validation step before proceeding
Role in Testing Process
- Serves as a checkpoint to decide whether deeper testing (like full regression) is necessary
- Helps teams avoid wasting time on unstable or broken builds
- Supports efficient test execution by focusing only on impacted areas
11. Difference Between Severity and Priority
- We have talked about various forms of both terms. Now, let’s look at the key differences which make them distinct.
- The term severity defines, to what degree the system is impacted. Whereas priority is all about scheduling or urgency.
- Usually, it is the test engineer who determines severity. While the product owners decide the priorities of defects.
- It is very unlikely that severity might change. Whereas the priorities change from time to time.
- Severity is usually determined from a technical point of view. Whereas priority depends upon the user experience.
- The severity affects the technical working of the system. Whereas the latter affects business.
- Severity and Priority Real-time Examples
- The priority and severity are combined in four different ways to determine which defect needs immediate attention and which one the least. Let’s look at some real-time examples to make this concept even more clear.
- High Priority and High Severity Examples
- The products added to the cart of an e-commerce website are not visible on the payment page.
- The login button of the application is not working.
- High Priority and Low Severity Examples
- The logo of the company’s welcome page is distorted.
- The action buttons are not visually appealing, or the information on the page appears hazy.
- Low Priority and High Severity Examples
- If the application is crashing on passing very large input for processing (which is very rarely done).
- There are some buttons on the website which are overlapping. Although clickable, create a fuss.
- Low Priority and Low Severity Examples
- A spelling mistake on the page of the site which is not frequently visited.
- The color of any text does not match the theme of the website.
12. What is Black Box Testing?
Black box testing examines software functionality without examining its internal code structure. In this approach, testers interact with applications just as end users would, verifying that the system behaves according to requirements.
Also known as closed-box testing, this technique ensures applications fulfill their functional expectations regardless of how they’re coded.
Consider a simple login page black box testing example:
- You enter a username and password, then click the login button
- You then see what happens next
- If credentials are correct, the system should grant access and display the dashboard
- If details are incorrect, it should present an appropriate error message (like “Invalid credentials”)
Throughout this process, testers never examine the underlying authentication code or password verification logic.
Instead, they focus exclusively on what goes in (input) and what comes out (output). This forms the essence of black box testing: treat the application as a sealed box, provide various inputs, and assess whether the outputs align with expected results.
13. What is White Box Testing?
The white box testing is a procedure that includes verification of the internal structure, and logic of the software. A tester who is in charge of this has complete access to the source code. He uses his knowledge of the internal working of the software, and his technical skills to create tests that can validate the code. The software for white box testing is also called transparent testing, open box testing, structural testing, or code-based testing.
The verification of the software interior algorithm, flow, and structure is the main objective of the white box testing. The white box test cases cover the different paths of the code, and logic to ensure that the user’s specifications are met.
14. What is Retesting?
Retesting in Software Testing
Retesting is a crucial software testing process where specific test cases are executed again to ensure that defects identified in previous tests have been fixed correctly. It helps verify that the modifications or bug fixes have not introduced new issues.
Retesting guarantees the reliability and quality of the software before its release.
Purpose of Retesting
- Ensures that previously identified defects are fixed correctly
- Verifies that bug fixes have not introduced new issues
- Confirms the stability of the affected functionality
- Improves overall software quality before release
Role in Defect Life Cycle
- Retesting is part of the defect life cycle
- It involves testing of failed test cases that were non-functional during earlier testing
- These test cases are executed again after developers fix the defects
- Ensures that the defect is completely resolved before closure
15. What is a Test Scenario?
A high-level description of a functionality that must be tested is called a test scenario. Sometimes referred to as a test situation, it represents a possible user interaction or system behavior. Put yourself in the end user’s position as a tester and identify the application under test’s (AUT) real-world scenarios and use cases.
Test scenarios can be classified based on what aspect of the application they aim to verify. Understanding these types ensures full coverage of all functionality and user interactions.
Various Test Scenario Types
Functional Scenarios: These verify if particular modules or features (such as login, signup, or checkout) work according to requirements. They focus on “what it should do.”
Non-Functional Scenarios: These assess the system’s performance, scalability, usability, and reliability rather than what it does.
Security Scenarios: These evaluate how well the program guards user information and stops vulnerabilities or illegal access.
UI (User Interface) Scenarios: These ensure the interactive elements, navigation, and visual layout work naturally on various screens and devices.
End-to-End Scenarios: These simulate real -world workflows and verify that several modules cooperate smoothly. An eCommerce app search, cart addition, and payment completion are a few examples.
Real-Time Manual Testing Questions for Beginners
These real-time manual testing questions are simple but very common in interviews.
16. How will you test a login page?
Testing a login page is one of the most common manual testing interview questions.
The goal is to verify whether the login functionality works correctly, securely, and provides a good user experience.
Important Login Test Scenarios
Valid Login
Test the application using the correct username and password credentials.
Brief Explanation
This verifies whether authorized users can successfully log in and access the application.
Invalid Login
Test the login functionality using incorrect username or password combinations.
Brief Explanation
This ensures the application properly rejects invalid users and displays appropriate error messages.
Empty Fields
Try logging in without entering username or password values.
Brief Explanation
This checks whether mandatory field validations are working correctly.
Password Masking
Verify whether the password field hides entered characters.
Brief Explanation
Password masking protects sensitive user information and improves security.
Forgot Password Link
Click the forgot password link and verify the reset password process.
Brief Explanation
This ensures users can recover their accounts if they forget their password.
17. How do you report a bug?
1. Remain composed
The first thing a tester should do when a bug appears in production is to remain composed. It’s crucial to be calm and take your time to evaluate the circumstances before acting.
As soon as the problem is identified, it must be addressed to stop additional damage or service interruptions. Additionally, it’s critical to monitor any modifications and thoroughly test them before reintroducing them into production.
2. Determine the Bug’s Severity
Determining the bug’s severity is crucial since it can assist in determining how soon it should be fixed and what resources are needed to fix it. Once the bug severity has been assessed, testers should record any pertinent information about it, such as the methods used to replicate it, the environment, the expected and actual outcomes, and so forth.
After that, they ought to inform developers of their results so that they can conduct additional research and try to fix any problems that have been found.
3. Record the defect
The first thing a tester should do when a bug is discovered in production is to document it. This entails making thorough notes about what transpired and how it happened so that developers may promptly locate and fix the problem.
If you can, it’s also a good idea to incorporate any pertinent screenshots or videos of the bug within the activity. The bug should be submitted to the development team for more research and fixing after it has been documented.
4. Separate the Bug
Isolating a bug is a crucial step for a tester if one is found in production. This implies that the defect must be the only cause of any issues once all other variables have been removed.
After the issue has been isolated, more research can be done to identify the root cause and the most effective solution. To stop similar defects from happening again in subsequent versions, the objective should always be to address their underlying causes.
5. Interact with the Group
Everyone must be aware of the problem, and it must be resolved as quickly as feasible. After consulting with my team, I would conduct further research by repeating the procedures that resulted in the bug discovery and manually or using a bug reporting service like Shakebug to record any findings. This will help us figure out what caused the bug so that we can properly solve it.
6. Rollback (if feasible)
The first action a tester should take if a bug arises in production is to roll back (if possible). This aids in restoring the system to its initial condition and preventing additional harm. Investigating what caused the problem and how to prevent it in the future is crucial after rolling back. Writing tests that are especially made for this kind of defect and can be applied to other testing contexts would be the next step.
7. Put a Fast Fix in Place
The first thing a tester should do if they discover a bug in production is to quickly repair it. This includes figuring out what caused the problem and making sure it doesn’t happen again. To prevent future problems or promptly address them if they do occur, the next step would be to record the actions taken to address the problem. Lastly, testers must make sure that all tests are performed on modifications before releasing them to production.
8. Set priorities and make plans
A tester must prioritize and determine the best course of action if an issue is discovered in production. First, determine the kind of bug found and how serious it is. You can then choose whether to address the issue immediately or wait for additional resources to become available, depending on how critical it is. After making that choice, you’ll need to create a test strategy to confirm any modifications before they go live once more.
9. Examine the Solution
Testing the repair is the most important thing a tester needs to do once a bug is discovered in production. This entails confirming that every modification made by developers has been applied appropriately and is functioning as intended. Additionally, it’s important to make sure that any new features or functionalities brought about by this modification don’t introduce any new bugs into the system. Both human and automated testing should be used to provide adequate coverage of every area impacted by the patch.
10. Implement the Fix
The first thing a tester should do when a bug occurs in production is to implement the fix. This implies that before being put into production, all required modifications must be made and carefully tested. To prevent the introduction of new faults or problems, it is crucial to make sure that any regression tests on the new code have been completed after deployment. The repair can then be made accessible to users after everything has been examined and confirmed.
11. Analysis After Death
A post-mortem analysis ought to be carried out by a tester. To find out what caused the issue, this means looking into every facet of the system, including the environment, architecture, and code. Once found, actions can be done to make sure that similar problems don’t arise in subsequent releases.
To share their results with other team members and stakeholders who might need this information while making decisions about upcoming projects or modifications, testers must also record their findings.
12. Interact with Users
To figure out the ideal way to fix the problem, it is crucial to comprehend what went wrong and how it impacted testers. After you’ve located the problem, you must determine why it happened and develop tests to make sure that similar problems don’t arise in upcoming versions.
Lastly, before putting anything back into production, make sure that all parties involved are aware of any modifications or adjustments made once everything has been completely tested.
13. Revise Logging and Monitoring
A tester’s first course of action when a bug arises in production is to update monitoring and logging. This will allow us to monitor any modifications made either prior to or following the problem. The cause of the bug and ways to prevent it can then be ascertained using this information.
In addition, we should search for comparable problems in other settings, such development or staging, so that they may be resolved as quickly as possible if needed.
18. What will you do if you don’t understand requirements?
1. Learn to understand the system
You can learn more about the system by using it as an end-user and comprehending its purpose. In this case, you can simply grasp its primary features or conduct some exploratory testing, which is “an approach to software testing that is often described as simultaneous learning, test design, and execution.” It emphasizes discovery and depends on the individual tester’s instruction to find flaws that are difficult to find. All you have to do is become familiar with the system, create a few test cases, and run them.
2. Search for related projects
Look for projects that do comparable tasks to the system you plan to test. For instance, if you are testing an e-commerce system, look for some e-commerce sites and test them out. If the “Add to Cart” button doesn’t make sense to you, try it on another project.
3. Attending meetings and asking questions
Asking questions and holding meetings with the project manager, developers, designers, and other stakeholders can help you learn a lot. It’s best to prepare your system-related questions in advance so you can learn more in less time.
Questions may include, but are not restricted to:
What is the system’s primary goal?
Who are the primary users?
Do any personas exist?
Which are the system’s primary modules? and what is expected of them all?
Inquire about the anticipated behavior of a certain function with the project manager, product owner, or developer.
You can ask a lot of questions here to learn important details about the system.
4. Any document would be helpful.
No requirements, no problem, but you might benefit from other documents instead of the requirements, such as:
You can better comprehend the system’s primary items and their relationships by using the database schema.
The schematics of data flow
Your eyes will be opened to the entire system via the business model.
In this situation, use cases are crucial since they illustrate the primary users and how they engage with the system.
5. Apply your prior knowledge and common sense
Based on your prior work expertise or your experience using certain systems, you can easily define the expected behavior of many functions. Common sense will also be helpful.
As a tester, you can steer clear of such issues in the future by honing your skills by experimenting with and exploring various applications in various domains. Even if this is a new project for you, doing so will broaden your experience and provide you with practical experience in various domains, making it easier for you to handle a project without requirements.
For the most common projects and functions, try to make your own checklists beforehand. For example, the Login function’s expected behavior is very common, so defining it beforehand will save you a lot of time in your upcoming projects and give you more time to concentrate and learn new functions. This also applies to your previous projects; recording your experience after each project will be invaluable in the future.
Lastly, testing without requirements isn’t that hard, but it requires more tolerance and adaptability to develop your own resources and expertise so that it can be managed with ease.
19. How do you prioritize test cases?
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.
20. What documents are prepared in manual testing?
Important Documents in Manual Testing
Test Plan
A Test Plan is a document that defines the testing scope, strategy, objectives, resources, schedule, and testing approach.
Brief Explanation
It helps the team understand how testing will be performed and managed throughout the project.
Test Cases
Test Cases are detailed step-by-step instructions used to verify application functionality.
Brief Explanation
They help testers validate whether the application works as expected under different conditions.
Bug Reports
Bug Reports are documents used to record defects found during testing.
Brief Explanation
A bug report usually includes:
- Steps to reproduce
- Expected result
- Actual result
- Severity and priority
- Screenshots or logs
These details help developers understand and fix the issue.
Test Summary Report
A Test Summary Report provides an overview of testing activities and final testing status.
Brief Explanation
It includes:
- Test execution results
- Number of passed and failed test cases
- Defect summary
- Overall quality status
This report helps stakeholders understand testing progress and release readiness.
Purpose of Testing Documents
These documents help:
- Maintain proper testing process
- Improve communication between teams
- Track defects and testing progress
- Ensure better product quality
Proper documentation is an important part of manual testing projects.
Scenario-Based Manual Testing Interview Questions (15 Easy Examples)
Scenario-based questions check logical thinking, even for beginners.
1. Login Button Is Not Working
If the login button is not functioning properly, the issue should be analyzed step-by-step.
Check the Following
- Button click
- Browser console
- Network connection
Brief Explanation
These checks help identify whether the issue is related to UI behavior, frontend errors, or connectivity problems.
2. Application Crashes After Clicking Submit
Application crashes should be reproduced and documented clearly.
Actions
- Reproduce the issue
- Note exact steps
- Report defect
Brief Explanation
Proper reproduction steps help developers identify and fix the issue efficiently.
3. Password Is Visible Instead of Masked
Displaying passwords as plain text is a security concern.
Answer
This is a security defect.
Brief Explanation
Password masking protects sensitive user information and improves application security.
4. Page Loads Very Slowly
Slow page loading affects application usability and performance.
Check the Following
- Internet speed
- Page size
Brief Explanation
These checks help determine whether the issue is caused by network conditions or heavy application resources.
5. Data Not Saved After Refresh
If data disappears after refresh, save functionality should be validated.
Verify the Following
- Save button
- Database update
Brief Explanation
This ensures that the application correctly stores and retrieves data.
6. Mobile Number Field Accepts Alphabets
Invalid input acceptance indicates a validation problem.
Answer
This is a validation defect.
Brief Explanation
Mobile number fields should accept only numeric values to maintain data accuracy.
7. Forgot Password Email Not Received
Forgot password functionality should be tested carefully.
Check the Following
- Email trigger
- Spam folder
Brief Explanation
These checks help verify whether the issue is related to the application or email delivery system.
8. Logout Not Working
Logout functionality is important for user security.
Check the Following
- Session handling
Brief Explanation
Proper logout should clear the user session completely and prevent unauthorized access.
9. Application Works in Chrome but Not Firefox
Different behavior across browsers indicates compatibility issues.
Answer
This is a browser compatibility issue.
Brief Explanation
Cross-browser testing ensures consistent application behavior across supported browsers.
10. Dropdown Values Are Incorrect
Dropdown values should match requirements and backend data.
Check the Following
- Requirement
- Backend data
Brief Explanation
This helps ensure users see correct and expected options.
11–15. More Scenario-Based Questions
Interviewers may ask additional real-time scenario-based questions to evaluate practical thinking and troubleshooting ability.
Common Topics
- Broken links
- UI alignment issues
- Duplicate data submission
- Incorrect error message
- Session timeout issues
Brief Explanation
These scenarios help assess how candidates handle common application issues in real projects.
Real Company Interview Round Format + Preparation Tips
Typical QA Interview Rounds
QA interviews usually include multiple rounds to evaluate technical and communication skills.
Common Interview Rounds
- HR round
- Basic manual testing interview questions
- Scenario-based questions
- Attitude and communication check
Brief Explanation
These rounds help interviewers understand testing knowledge, logical thinking, and communication ability.
Preparation Tips
Proper preparation improves confidence and interview performance.
Important Preparation Tips
- Revise basics daily
- Practice explaining answers aloud
- Use simple language
- Be honest if you do not know something
Brief Explanation
Interviewers prefer candidates who explain concepts clearly and confidently instead of memorizing answers.
How to Answer Basic Manual Testing Interview Questions Like a Pro
Using a simple structure helps candidates answer questions more effectively.
Simple Answer Framework
Definition
Explain the concept clearly.
Example
Provide a practical example.
Practical Usage
Mention how it is used in real projects.
Example
“Regression testing means checking existing features after changes. For example, after fixing a login bug, I test signup and dashboard.”
Brief Explanation
This approach shows both theoretical understanding and practical testing knowledge.
Common Mistakes Beginners Make in Interviews
Many beginners make avoidable mistakes during QA interviews.
Common Mistakes
- Memorizing answers without understanding
- Not giving examples
- Using complex technical words
- Being afraid to say “I don’t know”
- Low confidence
Brief Explanation
Interviewers usually prefer logical thinking and clear communication over memorized answers.
Final Revision Sheet – Quick Preparation
Before the interview, revise the most important manual testing topics.
Must-Revise Topics
- Manual testing basics
- STLC
- Test cases and defects
- Smoke vs regression testing
- Scenario-based questions
Brief Explanation
These topics are commonly asked in beginner-level QA interviews.
One Day Before Interview
The final day should focus on revision and confidence building.
Last-Minute Preparation Tips
- Read definitions
- Practice scenarios
- Stay calm
Brief Explanation
Good preparation and calm communication help candidates perform better during interviews.
FAQs – Basic Manual Testing Interview Questions
Q1. Are basic manual testing interview questions asked for freshers?
Yes, basic manual testing interview questions are very commonly asked for freshers in QA and software testing interviews.
Most companies start fresher interviews with basic concepts to evaluate the candidate’s foundation in testing.
Why Companies Ask Basic Questions to Freshers
Interviewers want to check whether candidates:
- Understand manual testing fundamentals
- Can think logically
- Can explain concepts clearly
- Have basic knowledge of real-time testing scenarios
Freshers are usually not expected to have deep project experience, so companies focus more on fundamentals and communication skills.
Q2. Do I need coding for manual testing?
Freshers do not need coding to start a career in manual testing.
Manual testing mainly involves:
- Understanding requirements
- Writing and executing test cases
- Finding and reporting bugs
- Validating application behavior
These activities focus more on logic, observation, and understanding, not programming.
However, having basic coding knowledge is a plus, even for manual testers. It helps in:
- Understanding how the application works internally
- Communicating better with developers
- Learning automation later
Basic knowledge like:
- Simple programming concepts
- SQL for database validation
- Understanding APIs
can give an advantage but it is not mandatory at the beginning.
Q3. How many questions are usually asked?
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. What is the best way to prepare?
The key is to avoid trying to learn everything and instead concentrate on high impact topics, real scenarios, and clear communication.
Understand Core Concepts
Start with the basics of manual testing such as SDLC, STLC, defect life cycle, and types of testing. The goal is not memorization but clarity. Make sure each concept can be explained in simple words.
Learn Scenario-Based Questions
Focus on real-time situations like handling unstable builds, rejected defects, tight deadlines, and missing requirements. Practice answering in a structured and practical way.
Project Explanation Preparation
Prepare a strong explanation of the current or past project. Cover domain, application type, responsibilities, tools used, and challenges faced. This is one of the most important areas in interviews.
Test Case & Real Feature Testing
Practice writing test scenarios and test cases for common features like login page, payment page, and mobile app behavior. This improves practical thinking.
Defect Handling & Communication
Revise how to report bugs, handle conflicts with developers, and communicate critical issues. Focus on clarity and professionalism.
Tools & Basic API Knowledge
Review tools like Jira, TestRail/Excel, and Postman. Understand how they are used in real projects rather than just knowing their names.
Mock Interviews & Revision
Revise all topics and practice answering questions aloud. Take mock interviews or self-practice to improve confidence and fluency.
Q5. Can I get a job with only basic manual testing knowledge?
Yes, it is possible to get an entry-level QA or software testing job with basic manual testing knowledge, especially as a fresher or beginner.
Many companies hiring junior testers first check:
- Understanding of manual testing basics
- Logical thinking ability
- Communication skills
Willingness to learn