Top Manual Testing Interview Questions 2023

1. What is Defect Logging and Tracking?

Defect logging and tracking refers to the process of identifying, documenting, and managing software defects or issues encountered during the testing phase. It involves capturing detailed information about each defect, such as its description, steps to reproduce, severity, priority, and associated test case.

2. What are some essential qualities an experienced QA or Test Lead must possess?

Some essential qualities for an experienced QA or Test Lead include:

• Strong understanding of testing principles, methodologies, and best practices.
• Excellent analytical and problem-solving skills.
• Effective communication and collaboration abilities.
• Attention to detail and ability to think critically.
• Leadership qualities to guide and mentor the testing team.
• Adaptability to changing project requirements and priorities.
• Thorough knowledge of testing tools and technologies.
• Domain knowledge relevant to the software being tested.
• Continuous learning mindset to stay updated with industry trends and advancements.

3. What is the average age of a defect in software testing?

The average age of a defect in software testing refers to the time elapsed between the detection of a defect and its resolution. It is important to minimize the defect age to ensure timely bug fixes and maintain software quality.

4. What is Silk Test Tool and why should you use it?

Silk Test is a functional and regression testing tool used for automating software testing processes. It provides a comprehensive set of features for testing various application types, including web, mobile, desktop, and enterprise applications.

Silk Test offers capabilities such as test script recording, test script development in multiple languages, cross-browser testing, data-driven testing, and test execution on different platforms.

Some reasons to consider using Silk Test:

• Efficient automation of repetitive and time-consuming testing tasks.
• Increased test coverage and accuracy.
• Faster test execution and reduced time-to-market.
• Improved reliability and consistency of test results.
• Seamless integration with other testing and development tools.
• Support for testing a wide range of application technologies.

5. What are the key elements to consider while writing a bug report?

When writing a bug report, it is important to include the following key elements:

• Title/Summary: A concise and descriptive title that summarizes the issue.
• Description: Detailed explanation of the problem, including its symptoms, expected behavior, and actual behavior observed.
• Steps to Reproduce: Clear and step-by-step instructions to reproduce the bug.
• Environment Details: Information about the software version, operating system, hardware, and any other relevant configurations.
• Attachments: Screenshots, log files, or any other supporting evidence that can help in understanding and resolving the bug.
• Severity and Priority: Assessment of the bug's impact and urgency.
• Expected: Desired outcome or solution for the issue.

Example:

• Title: Error Message Displayed When Submitting Form
• Description: When submitting the contact form on the website, an error message is displayed instead of the success message. The error message states "Invalid email format" even though a valid email address is entered.
• Steps to Reproduce:
  1. Go to the website's contact page.
  2. Fill in the required fields with valid information.
  3. Enter a valid email address format.
  4. Click on the "Submit" button.
  5. Observe the error message displayed instead of the success message.
• Environment Details: Website version 2.1.3, Windows 10, Chrome 91.0.4472.124
• Attachments: Add the screenshot or attachments
• Severity and Priority: May be Low, Medium, High, depends upon requirement
• Expected: Error Message should be displayed.

6. Is there any difference between bug leakage and bug release?

Yes, there is a difference between bug leakage and bug release:

• Bug Leakage: Bug leakage refers to a situation where a defect or bug goes undetected during the testing phase and is discovered by the end-user or customer after the software is released.

• Bug Release: Bug release refers to a situation where a known defect or bug is present in the software at the time of its release.

7. What is the difference between performance testing and monkey testing?

The difference between performance testing and monkey testing is as follows:

• Performance Testing: Performance testing focuses on evaluating the software's responsiveness, stability, scalability, and resource usage under different workload conditions. It aims to assess the system's performance metrics, such as response time, throughput, and resource utilization, to ensure it meets the desired performance requirements.

• Monkey Testing: Monkey testing, also known as random testing, involves generating random inputs or events to the software without following any specific test scenarios or predefined paths. The purpose is to test the system's robustness and error-handling capabilities by subjecting it to unexpected or invalid inputs.

8. What is exploratory testing?

Exploratory testing is a testing approach that emphasizes learning, discovery, and investigation. It involves test execution, and test evaluation without predefined test cases. Testers explore the software system, learn its functionalities, and actively design and execute tests based on their understanding and intuition.

9. What is meant by latent defect?

A latent defect, also known as a dormant defect, is a defect or issue present in the software that remains undetected during testing and only manifests itself after the software is deployed and being used by end-users. Latent defects may arise due to complex interactions, specific usage scenarios, or rare conditions that were not covered during testing.

10. What does Defect Removal Efficiency (DRE) mean in software testing?

Defect Removal Efficiency (DRE) is a testing metric used to measure the efficiency of the development team in fixing issues before the release. It quantifies the effectiveness of defect identification and removal during the testing process.

DRE is calculated as the ratio of defects fixed to the total number of issues discovered:

$$DRE = \left(\frac{{\text{Defects Fixed}}}{{\text{Total Defects}}}\right) \times 100$$

For example- Let's consider a software testing project where a total of 75 defects were discovered during the test cycle or tester. Out of these, the development team successfully fixed 62 defects before the measurement. The DRE would be calculated as:

DRE = (62 / 75) x 100 = 82.6%

This means that the development team was able to fix and resolve 82.6% of the identified defects before the release.

Note-: Defect Removal Efficiency provides insights into the effectiveness of the testing and development process. A higher DRE indicates a more efficient team in identifying and fixing defects, reducing the risk of issues reaching end-users.

It is important to note that DRE is just one of many metrics used in testing. While it helps assess the effectiveness of defect removal.

11. What is Defects Find Rate (DFR)?

Testing metrics provide quantitative measures to evaluate various aspects of the testing process and the quality of the software being tested.

12. What is defect detection percentage in software testing?

Defect detection percentage (DDP) is a testing metric that measures the effectiveness of the testing process in discovering defects before and after the release. It is calculated as the ratio of defects detected during the testing cycle to the total number of defects reported, including those reported by customers after the release.

For example, if the QA team detected 70 defects during testing and an additional 20 defects were reported by customers after the release,

the DDP would be 70/(70 + 20) = 72.1%.

13. Difference between Bug, Defect, Error, and Fault.

• Bug: An unexpected flaw or malfunction in the software identified during development or testing.
• Defect: A deviation from the expected behavior or functionality of the software, impacting its intended purpose.
• Error: A mistake or incorrect action by a human during the software development or testing process that results in unintended behavior.
• Fault: An underlying flaw in the software's design, code, or implementation that causes it to produce incorrect or unexpected results.

14. What do you understand by STLC?

STLC stands for Software Testing Life Cycle. It is a framework that outlines the activities and phases involved in testing a software system. The typical stages of STLC include:

1. Requirement Analysis: Understanding and analyzing the software requirements to define the scope of testing.
2. Test Planning: Creating a comprehensive test plan that outlines the testing objectives, test approach, test environment setup, resource allocation, and test schedules.
3. Test Case Development: Designing and documenting test cases based on the requirements and test objectives.
4. Environment Setup: Setting up the necessary test environments, including hardware, software, and network configurations.
5. Test Execution: Executing the test cases, recording the results, and comparing the actual outcomes with expected results.
6. Test Cycle Closure: Analyzing the test results, preparing test reports, defect tracking, and assessing the overall testing process. Lessons learned from the testing cycle are documented for future improvements.

STLC helps ensure a systematic and structured approach to testing, leading to improved software quality and efficient delivery.

15. Is there any difference between retesting and regression testing?

Yes, there is a difference between retesting and regression testing:

• Retesting: Retesting is performed to verify that a previously failed test case or a defect has been fixed and the associated functionality is now working as expected. It focuses on validating the fix and ensuring that the issue has been resolved without introducing new problems.

• Regression Testing: Regression testing is conducted to ensure that changes or modifications made to the software do not introduce new defects or negatively impact existing functionalities. It involves retesting the impacted areas as well as other related areas to ensure that the system as a whole is functioning correctly after the changes.

16. How do you test a product if the requirements are yet to be frozen?

Testing a product when the requirements are not yet finalized can be challenging. In such a scenario, the following approaches can be considered:

• Exploratory Testing: Perform exploratory testing to gain insights into the product and uncover potential issues based on your expertise and experience. This approach relies on skilled testers' ability to explore the software and provide valuable feedback.

• Agile Testing: Adopt an agile testing approach that allows for frequent collaboration and iterative feedback. As requirements evolve, conduct iterative testing cycles to validate the changing functionalities and provide early feedback on any issues or concerns.

• Prototyping: Develop prototypes or mock-ups of the software based on the available requirements.

Test these prototypes to gain a better understanding of the expected functionalities and identify potential improvements or gaps in the requirements.

• Collaboration with stakeholders: Engage in active communication and collaboration with stakeholders, such as business analysts, product owners, and developers, to gather information about the evolving requirements. Participate in discussions, clarify ambiguities, and provide inputs based on your testing perspective.

While testing without frozen requirements can be challenging, it is important to adapt and stay flexible in order to contribute effectively to the software's quality.

17. What will you do when a bug turns up during testing?

When a bug is discovered during testing, the following steps can be taken:

1. Reproduce the bug: Try to reproduce the bug by following the steps provided in the bug report or by identifying a specific set of actions that trigger the issue.

2. Document the bug: Write a detailed bug report that includes all relevant information about the issue, such as its description, steps to reproduce, expected behavior, observed behavior, and any supporting attachments like screenshots or log files. Provide clear and concise information to facilitate the bug's understanding and resolution.

3. Prioritize the bug: Assess the severity and impact of the bug to determine its priority. Consider factors such as the bug's impact on functionality, potential risks, and customer impact.

4. Assign the bug: Assign the bug to the relevant team or individual responsible for fixing it. Ensure clear communication and provide any additional information or context required to understand and resolve the bug effectively.

5. Follow up and track the bug: Monitor the bug's progress throughout its lifecycle. Communicate with the development team regularly to obtain updates on the status of the bug and its resolution.

6. Verify the fix: Once the bug has been fixed, perform regression testing or retesting to ensure that the issue has been resolved and no new issues have been introduced as a result of the fix.

7. Close the bug: After verifying the fix and ensuring the bug is resolved, close the bug report. Provide necessary details and update the bug's status accordingly.

Proper bug reporting, tracking, and collaboration with the development team are crucial to ensure timely and effective bug resolution.

18. The probability that a server-class application hosted on the cloud is up and running for six long months without crashing is 99.99 percent. To analyze this type of scenario, what test would you perform?

To analyze the scenario of a server-class application hosted on the cloud running without crashing for six months with a 99.99% probability, the relevant test to perform would be reliability testing.

Reliability testing focuses on evaluating the system's ability to perform a required function under specific conditions for a prolonged period. It aims to identify potential issues related to stability, availability, and fault tolerance.

By performing reliability testing, you can gain insights into the application's stability and robustness, identify and mitigate potential points of failure, and ensure its ability to meet the desired uptime and performance targets.

19. What is agile testing and why is it important?

Agile testing is an approach to software testing that aligns with the principles of Agile development methodologies, such as Scrum or Kanban. It emphasizes iterative and incremental testing throughout the software development lifecycle to provide fast and continuous feedback.

Agile testing is important because it promotes flexibility, adaptability, and customer-centricity. By integrating testing into each iteration, it allows for quick identification and resolution of issues, reduces the risk of defects going unnoticed, and helps deliver a higher-quality product in shorter development cycles. It also fosters collaboration and continuous improvement, leading to better alignment between customer needs and the delivered software.

Key aspects of Agile testing include:

• Early involvement: Testers actively participate in the requirements gathering and user story creation, ensuring that testability aspects are considered from the beginning.

• Continuous testing: Testing is performed continuously throughout the development process, enabling frequent feedback and faster bug detection and resolution.

• Test automation: Agile testing heavily relies on test automation to enable quick and repetitive testing, ensuring faster feedback and reducing the overall testing effort.

• Collaboration: Close collaboration and communication between testers, developers, and stakeholders are crucial to ensure shared understanding, resolve issues efficiently, and deliver high-quality software.

20. What do you know about data flow testing?

Data flow testing is a white-box testing technique that focuses on analyzing and testing the flow of data within a software application.

The key aspects of data flow testing include:

• Def-Use Coverage:
• Use-Def Coverage:
• Node Coverage:
• Edge Coverage:

Example: In a banking application, data flow testing can be used to verify that customer account balances are correctly updated when deposits or withdrawals are made. It can help identify scenarios where the data flow is incorrect, resulting in incorrect balance calculations or inconsistencies in account transactions. By systematically testing the data flow paths, potential defects can be uncovered, ensuring the accuracy and reliability of the application's financial calculations.

21. Is it possible to achieve 100% testing coverage? How would you ensure it?

Achieving 100% testing coverage is extremely challenging and often not feasible in practical scenarios. Testing every possible combination of inputs, paths, and scenarios in a complex software system is nearly impossible.

While it may not be possible to achieve 100% testing coverage, you can strive for maximum coverage by following these practices:

• Requirement-based testing: Ensure that your test cases cover all the functional and non-functional requirements specified for the software. This helps in validating the intended behavior and features.

• Risk-based testing: Prioritize your testing efforts based on the identified risks and potential impact on the system. Focus more on critical functionalities and areas with higher chances of failure.

• Test case optimization: Optimize your test cases by eliminating redundant or overlapping scenarios. Ensure that each test case provides unique value in terms of coverage.

• Exploratory testing: Conduct exploratory testing to uncover unexpected behaviors and scenarios that were not explicitly defined in the requirements. This helps in discovering additional defects and improving overall coverage.

• Test automation: Leverage test automation tools and frameworks to automate repetitive and time-consuming tests. Automated tests can be executed more frequently and cover a larger portion of the system.

• Continuous testing: Implement a continuous testing approach, where tests are integrated into the development pipeline and executed on every code change. This ensures that tests are continuously running and providing feedback throughout the development process.

By applying these practices, you can achieve a higher level of test coverage and increase the confidence in the quality of your software.

22. What is meant by test coverage?

Test coverage is a metric used to measure the extent to which a software application has been tested. It indicates the percentage of code or system components that have been exercised by the executed tests. Test coverage helps assess the thoroughness of testing and identifies areas that have not been adequately tested.

There are different types of test coverage:

• Statement coverage: Measures the percentage of code statements that have been executed by the tests. It ensures that each line of code has been exercised at least once.

• Branch coverage: Measures the percentage of decision points (branches) that have been taken during test execution. It aims to cover all possible branches within conditional statements, loops, or switch statements.

• Path coverage: Measures the percentage of unique paths through the code that have been executed by the tests. It aims to cover all possible combinations of control flow paths.

• Function coverage: Measures the percentage of functions or subroutines that have been called during test execution.

• Condition coverage: Measures the percentage of Boolean conditions that have been evaluated to both true and false during test execution.

Test coverage provides insights into the adequacy of testing and helps identify areas that may require additional testing. However, it is important to note that achieving high test coverage does not guarantee the absence of defects, as it does not consider the quality or effectiveness of the tests themselves.

23. What is a test plan and what does it include?

A test plan is a document that outlines the approach, objectives, scope, and schedule of testing activities for a software project. It serves as a roadmap for the testing process and provides a comprehensive overview of how testing will be conducted.

A test plan typically includes the following key components:

1. Introduction:
2. Test objectives:
3. Scope:
4. Test strategy:
5. Test deliverables:
6. Test environment:
7. Test schedule:
8. Test resources:
9. Test risks and mitigation:
10. Test execution and reporting:
11. Approvals and sign-offs:

A well-defined test plan helps ensure that testing is conducted systematically, effectively, and in alignment with project goals and requirements.

24. When should you stop the testing process?

Knowing when to stop the testing process can be a challenging decision, as testing can theoretically continue indefinitely. However, several factors can influence the decision to stop testing:

1. Completion of test objectives: Testing can be stopped when the defined test objectives have been met. This includes achieving the desired test coverage, validating critical functionality, and ensuring that the major risks have been addressed.

2. Exhaustion of test budget or timeline: Testing may need to be halted if the allocated budget or timeline is fully utilized or exceeded. Practical constraints and project deadlines may require making a decision to stop testing and move forward with the available results.

3. Stability and quality criteria: Testing can be halted when the software reaches a sufficient level of stability and quality. This means that the critical defects have been addressed, and the software is deemed ready for release based on predefined acceptance criteria.

4. Risk assessment: If the identified risks have been adequately addressed through testing and the residual risks are within acceptable limits, the testing process can be stopped. This requires a comprehensive risk assessment to determine if the remaining risks are acceptable for the intended use of the software.

5. Business priorities: In some cases, business priorities and market demands may necessitate releasing the software even if testing is not fully completed. The decision to stop testing and release the software is a business-driven decision that considers the trade-offs between time-to-market, customer expectations, and the level of risk associated with releasing the software.

Ultimately, the decision to stop the testing process should be made based on a careful evaluation of the project context, objectives, risks, and available resources. It should be a collaborative decision involving the project stakeholders, including the development team, testers, product owners, and management.