Top 150+ Software Testing Interview Questions & Answers

In this post, we see Software Testing Interview Questions. Our main focus is on questions asked in Real-World Based Manual Testing Interview Questions And Answers.

Before going ahead, let’s see some unavoidable Interview Questions such as Why did you choose Software Testing As Your Career. I don’t want to take much time of yours but I couldn’t move further without mentioning this inevitable question in an interview i.e., Tell Me About Yourself. Click on the link to get some ideas on how to answer general interview questions. So, Let’s move on to the actual post.

Manual Testing Interview Questions

Before Starting, Check these Related Posts:

Software Testing Interview Questions

1. What is Software Testing?

According to ANSI/IEEE 1059 standard – A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item. Learn more about Software Testing.

2. What is the difference between SDET, Test Engineer, and Developer

SDET Vs Test Engineer Vs Developer

Test EngineerSDETDeveloperTest Engineer thinks only in the terms of pass or fail of a test case and how to break the softwareSDET knows system functional objectives as well as quality objectivesDeveloper thinks how to develop a system and make a functionality workTest Engineer works only for test life cycle, like design of test cases, and executionSDET is involved in Designing, development, and testingDeveloper is limited to Coding part and release to testing teamNo coding knowledge is requiredDynamic skill sets, like knowledge of quality and testing and good in coding tooOnly coding knowledge is requiredTest Engineers know where repetitive work or simple data entry is present but they are not expected to minimize the repetitive tasksSDET understands automation needs, they can code and provide a solution to the team where repetitive kind of work is killing the time. They can design framework which can help testing team to reduce repetitive test cycle or simple data entry task.Developers don’t deal with such tasksTest Engineers are not expected to reach up to code level and tune the performanceWell aware of Performance tuning and security threats , they can suggest and reach to the code and suggest where application is poor in performance, plus they can optimize the codeDevelopers are only expected to code the functionality which is expected by customer

3. What are the best practices for writing test cases?

• Write test cases with end-users perspective
• Write test steps in a simple way that anyone can follow them easily
• Make the test cases reusable
• Set the priority
• Provide a test case description, test data, expected result, precondition, postcondition.
• Write invalid test cases along with valid test cases
• Follow proper naming conventions
• Review the test cases regularly and update them if necessary.

4. How many test cases you can execute in a day?

Be practical while answering these kind of real time manual testing interview questions. You can say like it totally depends on the test case complexity and size. Some test cases have few test steps and some have more test steps.

A sample answer is “In my previous project, we generally execute 30-40 simple test cases (like login functionality) per day, 10-20 medium test cases (like Assigning user roles) per day, and 5-10 complex test cases (complete purchase flow) per day.

5. How many Test cases you can write in a day or how much time is required to write a test case?

Same strategy applies here too. It depends totally on the complexity of the functionality.

6. How many defects did you detect in your last project?

Before saying how many defects you detected in your last project, first start saying about the type of project you worked and how many test cases you executed.
I have worked for an ecommerce website where I have executed overall of 200 test cases and found around 45 defects.

7. What is configuration management?

Configuration management (CM) is a process of systems engineering to maintain system resources, computer systems, servers, software, and product’s performance in a consistent state. It helps to record all the changes made in the system and ensures that the system performs as expected even though changes are made over time.

Some of the popular configuration management tools are Ansible, Chef, Puppet, Terraform, Saltstack, etc.

9. What is Modification Request?

Modification request (MR) in software development is used by clients to change the existing functionality of a software.

10. What is Enhancement report?

Enhancement report (ER) in software development is used by clients to add a new feature in a software.

11. What if the software is so buggy it can’t really be tested at all?

If the software is so buggy, the first thing we need to do is to report the bugs and categories them based on Severity. If the bugs are critical bugs then it severely affects schedules and indicates deeper problems in the software development process. So you need to let the manager know about the bugs with proper documentation as evidence.

12. What is the difference between Quality Assurance vs Quality Control in Testing?   

Quality Assurance: Quality Assurance involves in process-oriented activities. It ensures the prevention of defects in the process used to make Software Applications. So the defects don’t arise when the Software Application is being developed.

Quality Control: Quality Control involves in product-oriented activities. It executes the program or code to identify the defects in the Software Application.

Now that you know what is Quality Assurance and what is Quality Control. As a software test engineer, you need to know the difference between Quality Assurance vs Quality Control.

Check this post, where we clearly discussed QA vs QC in Testing.

13. What is Verification in software testing?

Verification is the process, to ensure that whether we are building the product right i.e., to verify the requirements which we have and to verify whether we are developing the product accordingly or not. Activities involved here are Inspections, Reviews, Walk-throughs. Click here for more details.

14. What is Validation in software testing?

Validation is the process, whether we are building the right product i.e., to validate the product which we have developed is right or not. Activities involved in this is Testing the software application. Click here for more details.

15. What is Static Testing?

Static Testing involves reviewing the documents to identify the defects in the early stages of SDLC. In static testing, we do code reviews, walkthroughs, peer reviews, and static analysis of a source code by using tools like StyleCop, ESLint, etc.,

16. What is Dynamic Testing?

Dynamic testing involves the execution of code. It validates the output with the expected outcome.

Read more: How To Perform Static Testing, How To Perform Dynaic Testing, and Static Testing vs Dynamic Testing

17. What is White Box Testing?

White Box Testing is also called as Glass Box, Clear Box, and Structural Testing. It is based on applications internal code structure. In white-box testing, an internal perspective of the system, as well as programming skills, are used to design test cases. This testing usually was done at the unit level. Click here for more details.

Various white-box testing techniques are:

1. Statement Coverage
2. Decision Coverage
3. Condition Coverage
4. Multiple Condition Coverage

18. What is Black Box Testing?

Black Box Testing is a software testing method in which testers evaluate the functionality of the software under test without looking at the internal code structure. This can be applied to every level of software testing such as Unit, Integration, System and Acceptance Testing. Click here for more details. 

19. What is Grey Box Testing?

Grey box is the combination of both White Box and Black Box Testing. The tester who works on this type of testing needs to have access to design documents. This helps to create better test cases in this process.

20. What is Positive and Negative Testing?

Positive Testing: It is to determine what system supposed to do. It helps to check whether the application is justifying the requirements or not.

Negative Testing: It is to determine what system not supposed to do. It helps to find the defects from the software.

21. What is Test Strategy?

Test Strategy is a high-level document (static document) and usually developed by the project manager. It is a document that captures the approach on how we go about testing the product and achieve the goals. It is normally derived from the Business Requirement Specification (BRS). Documents like Test Plan are prepared by keeping this document as a base. Click here for more details.

22. What is Test Plan and contents available in a Test Plan?

Test plan document is a document which contains the plan for all the testing activities to be done to deliver a quality product. Test Plan document is derived from the Product Description, SRS, or Use Case documents for all future activities of the project. It is usually prepared by the Test Lead or Test Manager.

1. Test plan identifier
2. References
3. Introduction
4. Test items (functions)
5. Software risk issues
6. Features to be tested
7. Features not to be tested
8. Approach
9. Items pass/fail criteria
10. Suspension criteria and resolution requirements
11. Test deliverables
12. Remaining test tasks
13. Environmental needs
14. Staff and training needs
15. Responsibility
16. Schedule
17. Plan risks and contingencies
18. Approvals
19. Glossaries

Click here for more details. 

Learn Difference Between Test Plan vs Test Strategy

23. What is Test Suite?

Test Suite is a collection of test cases. The test cases which are intended to test an application.

Next we will see the difference between test scenarios, test cases, and test script.

24. What is Test Scenario?

Test Scenario gives the idea of what we have to test. Test Scenario is like a high-level test case.

25. What is Test Case?

Test cases are the set of positive and negative executable steps of a test scenario which has a set of pre-conditions, test data, expected result, post-conditions and actual results. Click here for more details.

Learn Difference Between Test Case vs Test Scenario

26. What is Test Script?

Test scripts are a line-by-line description of the system transactions that should be performed to validate an application or system under test. Test scripts provide a clear, step-by-step description of the transactions that should be performed, with expected results for each step.

27. What is Test Bed?

An environment configured for testing. Test bed consists of hardware, software, network configuration, an application under test, other related software.

28. What is Test Environment?

Test Environment is the combination of hardware and software on which Test Team performs testing.

Example:

• Application Type: Web Application
• OS: Windows
• Web Server: IIS
• Web Page Design: Dot Net
• Client Side Validation: JavaScript
• Server Side Scripting: ASP Dot Net
• Database: MS SQL Server
• Browser: IE/FireFox/Chrome

29. What is Test Data?

Test data is the data that is used by the testers to run the test cases. Whilst running the test cases, testers need to enter some input data. To do so, testers prepare test data. It can be prepared manually and also by using tools.

For example, To test a basic login functionality having a user id, password fields. We need to enter some data in the user id and password fields. So we need to collect some test data.

30. What is Test Harness?

A test harness is the collection of software and test data configured to test a program unit by running it under varying conditions which involves monitoring the output with the expected output.

It contains the Test Execution Engine & Test Script Repository

31. What is Test Closure?

Test Closure is the note prepared before test team formally completes the testing process. This note contains the total no. of test cases, total no. of test cases executed, total no. of defects found, total no. of defects fixed, total no. of bugs not fixed, total no of bugs rejected etc.,

32. What are the tasks of Test Closure activities in Software Testing?

Test Closure activities fall into four major groups.

Test Completion Check: To ensure all tests should be either run or deliberately skipped and all known defects should be either fixed, deferred for a future release or accepted as a permanent restriction.

Test Artifacts handover: Tests and test environments should be handed over to those responsible for maintenance testing. Known defects accepted or deferred should be documented and communicated to those who will use and support the use of the system.

Lessons learned: Analyzing lessons learned to determine changes needed for future releases and projects. In retrospective meetings, plans are established to ensure that good
practices can be repeated and poor practices are not repeated

Archiving results, logs, reports, and other documents and work products in the CMS (configuration management system).

33. What is test coverage?

Test coverage helps in measuring the amount of testing performed by a set of tests.

Test coverage can be done on both functional and non-functional activities. It assists testers to create tests that cover areas which are missing.

34. Explain how does a test coverage tool work?

Code coverage testing is a process of running tests on software to ensure that the code plan covers all aspects of the software’s source code. This type of testing runs parallel with actual product testing. The code coverage tool allows you to track which statements of your source code are being executed. At the end of testing, you will receive a report that details which statements were not covered and what percentage of your overall test coverage is.

35. What is Code coverage?

Code coverage is different from Test coverage. Code coverage is about unit testing practices that must target all areas of the code at least once. It is usually done by developers or unit testers.

Refer Test Metrics.

36. List out Test Deliverables?

1. Test Strategy
2. Test Plan
3. Effort Estimation Report
4. Test Scenarios
5. Test Cases/Scripts
6. Test Data
7. Requirement Traceability Matrix (RTM)
8. Defect Report/Bug Report
9. Test Execution Report
10. Graphs and Metrics
11. Test summary report
12. Test incident report
13. Test closure report
14. Release Note
15. Installation/configuration guide
16. User guide
17. Test status report
18. Weekly status report (Project manager to client)

Click here for more details.

37. What is a Test Report?

A test report is a document that provides an overview of testing objectives, activities, and results. It is necessary to summarize testing results and compare them against expectations. It helps us determine if the product is ready for release or not. Additionally, it allows us to see the current status of the project and assess the quality of the product

38. What are the most common components of a defect report?

The most common components of a defect report format include the following

• Project Name
• Module Name
• Defect ID
• Defect detected on
• Defect detected by
• Priority
• Severity
• Defect resolved on
• Defect resolved by

39. What are different categories of debugging?

Debugging is the act of finding and solving errors in a computer program that stops it from running properly.

There are several categories of debugging, which include:

• Brute force debugging
• Backtracking
• Cause elimination
• Fault tree analysis
• Program slicing

40. Write some common mistakes that lead to major issues.

Some of the most common mistakes include:

• Ignoring small issues
• Poor Scheduling
• Underestimating
• Improper resource allocation
• Not following the exact process

Manual Testing Interview Questions for freshers

41. What are the levels of testing?

In software testing, there are four testing levels.

1. Unit Testing or component level testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

42. What is Unit Testing?

Unit Testing is also called Module Testing or Component Testing. It is done to check whether the individual unit or module of the source code is working properly. It is done by the developers in the developer’s environment. Learn more about Unit Testing in detail.

43. What is Integration Testing?

Integration Testing is the process of testing the interface between the two software units. Integration testing is done in three ways. Big Bang Approach, Top-Down Approach, Bottom-Up Approach. Learn more about Integration Testing in detail.

Click here for more details.

44. What is System Testing?

Testing the fully integrated application to evaluate the system’s compliance with its specified requirements is called System Testing AKA End to End testing. Verifying the completed system to ensure that the application works as intended or not.

Check this post Difference Between System Testing and Integration Testing

45. What is Big Bang Approach?

Combining all the modules once and verifying the functionality after completion of individual module testing.

Top-down and bottom-up are carried out by using dummy modules known as Stubs and Drivers. These Stubs and Drivers are used to stand in for missing components to simulate data communication between modules.

46. What is Top-Down Approach?

Testing takes place from top to bottom. High-level modules are tested first and then low-level modules and finally integrating the low-level modules to a high level to ensure the system is working as intended. Stubs are used as a temporary module if a module is not ready for integration testing.

47. What is Bottom-Up Approach?

It is a reciprocate of the Top-Down Approach. Testing takes place from bottom to up. Lowest level modules are tested first and then high-level modules and finally integrating the high-level modules to a low level to ensure the system is working as intended.  Drivers are used as a temporary module for integration testing.

48. In manual testing what are stubs and drivers?

In software testing, Stubs and drivers are used in manual testing to test the functionality of a system without having to use the actual system.

A stub is a small piece of code that is called by the Module under Test. A driver is a small piece of code that calls the Module to be tested.

49. What is the difference between integration testing and system testing?

Integration Testing vs System Testing

INTEGRATION TESTINGSYSTEM TESTINGIt is a low level testingIt is a high level testingIt is followed by System TestingIt is followed by Acceptance TestingIt is performed after unit testingIt is performed after integration testingDifferent types of integration testing are:
• Top bottom integration testing
• Bottom top integration testing
• Big bang integration testing
• Sandwich integration testing
Different types of system testing are:
• Regression testing
• Sanity testing
• Usability testing
• Retesting
• Load testing
• Performance testing
• Maintenance testingTesters perform functional testing to validate the interaction of two modulesTesters perform both functional as well as non-functional testing to evaluate the functionality, usability, performance testing etc.,Performed to test whether two different modules interact effectively with each other or notPerformed to test whether the product is performing as per user expectations and the required specificationsIt can be performed by both testers and developersIt is performed by testersTesting takes place on the interface of two individual modulesTesting takes place on complete software applicationHere, we validate the interace between the individual modules.Here, we validate the finished product.Testers need to understand the interlinked modules and their interaction.Testers need to understand the internal structure and programming language.It covers only functional testing.It covers both functional and non-functional testing.

50. What is End-To-End Testing?

In simple words, end-to-end testing is the process of testing software from start to end. Check this End-To-End Testing guide for more information. Also, refer System Testing tutorial.

51. What is Functional Testing?

In simple words, what the system actually does is functional testing. To verify that each function of the software application behaves as specified in the requirement document. Testing all the functionalities by providing appropriate input to verify whether the actual output is matching the expected output or not. It falls within the scope of black box testing and the testers need not concern about the source code of the application.

Learn more about Functional Testing here

52. What is Non-Functional Testing?

In simple words, how well the system performs is non-functionality testing. Non-functional testing refers to various aspects of the software such as performance, load, stress, scalability, security, compatibility etc., Main focus is to improve the user experience on how fast the system responds to a request.

53. What is the difference between functional and non-functional testing?

Functional Testing vs Non-functional testing

Functional TestingNon-functional TestingWhat the system actually does is functional testingHow well the system performs is non-functionality testingTo ensure that your product meets customer and business requirements and doesn’t have any major bugsTo ensure that the product stands up to customer expectationsTo verify the accuracy of the software against expected outputTo verify the behavior of the software at various load conditionsIt is performed before non-functional testingIt is performed after functional testingExample of functional test case is to verify the login functionalityExample of non-functional test case is to check whether the homepage is loading in less than 2 secondsTesting types are
• Unit testing
• Smoke testing
• User Acceptance
• Integration Testing
• Regression testing
• Localization
• Globalization
• InteroperabilityTesting types are
• Performance Testing
• Volume Testing
• Scalability
• Usability Testing
• Load Testing
• Stress Testing
• Compliance Testing
• Portability Testing
• Disaster Recover TestingIt can be performed either manual or automated wayIt can be performed efficiently if automated

54. What is Acceptance Testing?

It is also known as pre-production testing.  This is done by the end-users along with the testers to validate the functionality of the application. After successful acceptance testing. Formal testing conducted to determine whether an application is developed as per the requirement. It allows the customer to accept or reject the application. Types of acceptance testing are Alpha, Beta & Gamma.

55. On what basis is the acceptance plan prepared?

The acceptance test plan is prepared using the following inputs.

• Requirement Document: The requirement document specifies what exactly is needed and not needed in the existing project from the customer’s perspective.
• Input from customer: Input from the customer will be in the format of formal emails, informal talks, discussions, etc.,
• Project plan: Project plan document prepared by the project manager.

All the above three inputs act as good inputs to prepare the acceptance test plan.

56. What is Alpha Testing?

Alpha testing is done by the in-house developers (who developed the software) and testers before we ship the software to the customers. Sometimes alpha testing is done by the client or outsourcing team with the presence of developers or testers. It is a part of User Acceptance Testing. The purpose of doing this is to find bugs before the customers start using the software.

57. What is Beta Testing?

Beta testing is done by a limited number of end-users before delivery. It is done after the Alpha Testing. Usually, it is done in the client’s place. Learn more about Beta Testing here.

58. What is Gamma Testing?

Gamma testing is done when the software is ready for release with specified requirements. It is done at the client place. It is done directly by skipping all the in-house testing activities.

59. What is Smoke Testing?

Smoke Testing is done to make sure if the build we received from the development team is testable or not. It is also called as “Day 0” check. It is done at the “build level”. It helps not to waste the testing time to simply testing the whole application when the key features don’t work or the key bugs have not been fixed yet.

Don’t miss this detailed Smoke Testing guide.

60. What is Sanity Testing?

Sanity Testing is done during the release phase to check for the main functionalities of the application without going deeper. It is also called as a subset of Regression testing. It is done at the “release level”. At times due to release time constraints rigorous regression testing can’t be done to the build, sanity testing does that part by checking main functionalities.

Don’t miss this detailed Sanity Testing guide.

61. What is the difference between Sanity and Smoke Testing?

Sanity vs Smoke Testing

SMOKE TESTINGSANITY TESTINGSmoke Test is done to make sure if the build we received from the development team is testable or notSanity Test is done during the release phase to check for the main functionalities of the application without going deeperSmoke Testing is performed by both Developers and TestersSanity Testing is performed by Testers aloneSmoke Testing exercises the entire application from end to endSanity Testing exercises only the particular component of the entire applicationSmoke Testing, build may be either stable or unstableSanity Testing, build is relatively stableIt is done on initial builds.It is done on stable builds.It is a part of basic testing.It is a part of regression testing.Usually it is done every time there is a new build release.It is planned when there is no enough time to do in-depth testing.

Manual Testing Interview Questions For Experienced

62. What is Retesting?

To ensure that the defects which were found and posted in the earlier build were fixed or not in the current build. Say, Build 1.0 was released. Test team found some defects (Defect Id 1.0.1, 1.0.2) and posted. Build 1.1 was released, now testing the defects 1.0.1 and 1.0.2 in this build is retesting.

Complete Guide: Retesting

63. What is Regression Testing?

Repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the changes in the software being tested or in another related or unrelated software components.

Usually, we do regression testing in the following cases:

1. New functionalities are added to the application
2. Change Requirement (In organizations, we call it as CR)
3. Defect Fixing
4. Performance Issue Fix
5. Environment change (E.g., Updating the DB from MySQL to Oracle)

Read a detailed guide on Regression Testing

64. What do you mean by regression and confirmation testing?

Regression Testing: Testing team re-execute the tests against the modified application to make sure whether the modified code breaks anything which was working earlier.

Confirmation Testing: Usually testers report a bug when a test fails. Dev Team releases a new version of the software after the defect is fixed. Now the testing team will retest to make sure the reported bug is actually fixed or not.

65. What is GUI Testing?

Graphical User Interface Testing is to test the interface between the application and the end user.

66. What is Recovery Testing?

Recovery testing is performed in order to determine how quickly the system can recover after the system crash or hardware failure. It comes under the type of non-functional testing.

67. What is Globalization Testing?

Globalization is a process of designing a software application so that it can be adapted to various languages and regions without any changes.

68. What is Internationalization Testing (I18N Testing)?

Refer Globalization Testing.

69. What is Localization Testing (L10N Testing)?

Localization is a process of adapting globalization software for a specific region or language by adding local specific components.

70. What is Installation Testing?

It is to check whether the application is successfully installed and it is working as expected after installation.

71. What is Formal Testing?

It is a process where the testers test the application by having pre-planned procedures and proper documentation.

72. What is Risk Based Testing?

Identify the modules or functionalities which are most likely cause failures and then testing those functionalities.

73. What is Compatibility Testing?

It is to deploy and check whether the application is working as expected in a different combination of environmental components.

74. What is Exploratory Testing?

Usually, this process will be carried out by domain experts. They perform testing just by exploring the functionalities of the application without having the knowledge of the requirements. Check our detailed guide on Exploratory Testing and also don’t miss these popular Exploratory Testing Tools.

75. What is Monkey Testing?

Perform abnormal action on the application deliberately in order to verify the stability of the application. Check our in-depth guide on Monkey Testing.

76. What is Usability Testing?

To verify whether the application is user-friendly or not and was comfortably used by an end-user or not. The main focus in this testing is to check whether the end-user can understand and operate the application easily or not. An application should be self-exploratory and must not require training to operate it. Check this guide to learn how to perform Usability Testing.

77. What is Security Testing?

Security testing is a process to determine whether the system protects data and maintains functionality as intended. 

78. What is Soak Testing?

Running a system at high load for a prolonged period of time to identify the performance problems is called Soak Testing.

79. What is Endurance Testing?

Endurance testing is a non-functional testing type. It is also known as Soak Testing. Refer Soak testing.

80. What is Performance Testing?

This type of testing determines or validates the speed, scalability, and/or stability characteristics of the system or application under test. Performance is concerned with achieving response times, throughput, and resource-utilization levels that meet the performance objectives for the project or product.

Complete Tutorial: Performance Testing

81. What is Load Testing?

It is to verify that the system/application can handle the expected number of transactions and to verify the system/application behavior under both normal and peak load conditions.

82. What is Volume Testing?

It is to verify that the system/application can handle a large amount of data

83. What is Stress Testing?

It is to verify the behavior of the system once the load increases more than its design expectations.

84. What is Scalability Testing?

Scalability testing is a type of non-functional testing. It is to determine how the application under test scales with increasing workload.

85. What is Concurrency Testing?

Concurrency testing means accessing the application at the same time by multiple users to ensure the stability of the system. This is mainly used to identify deadlock issues.

86. What is Fuzz Testing?

Fuzz testing is used to identify coding errors and security loopholes in an application. By inputting a massive amount of random data to the system in an attempt to make it crash to identify if anything breaks in the application.

87. What is Adhoc Testing?

Ad-hoc testing is quite opposite to the formal testing. It is an informal testing type. In Adhoc testing, testers randomly test the application without following any documents and test design techniques. This testing is primarily performed if the knowledge of testers in the application under test is very high. Testers randomly test the application without any test cases or any business requirement document.

88. What is Cross-Browser Testing?

Cross Browser Testing is a type of non-functional test which helps us ensure that our website or web application works well in various browsers.

Web applications rely on browsers like Google Chrome, Mozilla Firefox, Internet Explorer and Safari to function. Even though they all support web standards to some extent, there are still slight differences between them. This can pose a problem for developers who have to test their software on multiple browsers and take note of any inconsistencies.

Different browsers display websites differently due to styling, and it’s not possible to have every browser installed on one machine. Each browser is designed by a different company. Every browser has its own individualized features to make it stand out from the rest. When testing a website, we have to confirm that our site looks the same on all browsers.

89. What is meant by browser automation?

Browser automation is the process of testing a web application’s functionality in a browser automatically, using a script. The script launches the browser, navigates to the site, and then interacts with it like an normal end user would. This involves clicking buttons or links.

Browser automation with automation tools like Selenium, Katalon, Cypress, etc., is significantly quicker than testing it manually because these tools can test many scenarios in a very short amount of time.

QA Interview Questions And Answers

90. What is Interface Testing?

Interface testing is performed to evaluate whether two intended modules pass data and communicate correctly to one another.

91. What is Reliability Testing?

Perform testing on the application continuously for long period of time in order to verify the stability of the application

92. What is Bucket Testing?

Bucket testing is a method to compare two versions of an application against each other to determine which one performs better.

93. What is A/B Testing?

A/B testing is the process of comparing two versions of a webpage or other marketing asset to see which one performs better. The comparison doesn’t stop with web pages – it can be app interfaces, landing pages, email marketing, etc. To learn more check A/B Testing Guide

94. What is Split Testing?

Refer A/B testing.

95. What are the principles of Software Testing?

1. Testing shows presence of defects: Although testing can discover software defects, it cannot ensure that the product is free of errors. Testing may reduce the quantity of glitches, but it will never be able to eliminate them all.
2. Exhaustive testing is impossible: Since it’s impossible to test the software exhaustively, we can only run a few select tests and we assume that the software will always produce correct output. More comprehensive testing would be too costly and time-consuming.
3. Early testing: It’s crucial to test software early on to find defects. In the early stages of SDLC, it’s easier and less expensive to identify defects. Software testing should begin in the first phase of software development, during requirement analysis.
4. Defect clustering: According to the Pareto Principle, 80% of software defects arise from 20% of modules. In other words, most project defects are found in only a few sections of code.
5. Pesticide Paradox: If you want to find any new bugs, you can’t just keep running the same test cases repeatedly. You need to add or update your existing test cases.
6. Testing is context depending: Depending on the software development context, the testing approach will differ. Based upon its type, different software requires variations in testing.
7. Absence of error fallacy: Not only does the software need to be bug-free 99% of the time, but it must meet customer requirements if it is ever going to be used.

Click here for more details.

96. What is Exhaustive Testing?

Testing all the functionalities using all valid and invalid inputs and preconditions is known as Exhaustive testing.

97. What is Early Testing?

Defects detected in early phases of SDLC are less expensive to fix. So conducting early testing reduces the cost of fixing defects.

98. What is Defect Clustering?

Defect clustering in software testing means that a small module or functionality contains most of the bugs or it has the most operational failures.

99. What is Pesticide Paradox?

Pesticide Paradox in software testing is the process of repeating the same test cases, again and again, eventually, the same test cases will no longer find new bugs. So to overcome this Pesticide Paradox, it is necessary to review the test cases regularly and add or update them to find more defects.

100. What is Defect Cascading in Software Testing?

Defect cascading in Software testing means triggering of other defects in an application. When a defect is not identified or goes unnoticed while testing, it invokes other defects. It leads to multiple defects in the later stages and results in an increase in a number of defects in the application.

For example, if there is a defect in an accounting system related to negative taxation then the negative taxation defect affects the ledger which in turn affects other reports such as Balance Sheet, Profit & Loss etc.,

101. What is the difference between Outsourced Testing and Crowdsourced Testing

Outsourced Testing vs Crowdsourced Testing

Outsource TestingCrowdsourced testingA dedicated team is present to handle your testing Needs we can say it’s a third party which is unknown to you, test your application or product with a fresh set of mind.A completely unknown pool of testing resources test your application, you can judge the quality of your product on the basis of number of bugs reported.Payment is done on the basis of hours spent in testing, this estimation is done prior to the testing cycle. As an example testing outsourcing costs around 20 to 40$ per hour.Payment is done on the basis of bug reported, no of severe bugs and low priority bugs. For example severe bug cost is 15$ and low priority bug is 3$ whereas medium priority bugs are costing 5$.Application data is kept confidential and this is one of the code of ethics of every testing provider company.Since there are n number of testers working on your application and they are not legally bound with Crowd source provider company, they are not bound to keep application data confidential. There are chances of data leakage if crowd source testing is done and no assurance of data privacy.Communication is quite easy, because there is one representative always present to handle to share testing status, quality of your product.Communication is bit tricky, because you have to understand the product quality on the basis of bugs logged by testers, you have to understand the bug by talking to the tester individually.Quality is not compromised, since the objective is to identify all the bugs, within time and within budget. Entire team works to achieve this milestone, They present potential and valid bugs and organization is confident enough to fix only those bugs and get assured about their product quality.Since there is no team concept, here focus is more on Quantity rather than quality. There are chances that your application is tested by 1000 of testers of different experiences. They may log 5K bugs of different severity. So its organization’s responsibility to identify the real bugs and fix them.Testing platform and environment is completely owned by outsourced company, they are well settled with all useful software, tools, management tools, OS and Devices.Testing environment is totally dependent on individual tester, some testers are on testing on MAC machine or some are testing on Windows, some are testing on Android or some are testing on Apple.Skilled testers are in the team, there are fixed no of testers in the team. Each tester is well skilled in a particular area like mobile testing, performance testing, automation testing, functional testing.Huge no of testers, with different expertise and different years of experiences, so chances of quality bugs depends of expertise of testers. Which may be surprisingly good or bad too.One team, one time zone, restricted deadline, and planned budget, in this way testing cycles are complete.No team concept, Different time zones, no deadlines but bugs are reported very fast.Bugs reported are generally predictive in nature because testers work within a scope of testing.
They don’t touch few areas because it may not in their budget.Here no limitations of testing scope, N no of testers, n no of directions of breaking the system, Due to this testing cycle goes through a real scenario, for example n number of users are accessing application they might get some security flaw in the application.High paid in comparison to Crowd sourced testing but lesser than Inhouse Testing team.Budget friendly, quick results some time real and unexpected issues are identified.

102. What is Walk Through?

A walkthrough is an informal meeting conducts to learn, gain understanding, and find defects. The author leads the meeting and clarifies the queries raised by the peers in the meeting.

103. What is Inspection?

Inspection is a formal meeting lead by a trained moderator, certainly not by the author. The document under inspection is prepared and checked thoroughly by the reviewers before the meeting. In the inspection meeting, the defects found are logged and shared with the author for appropriate actions. Post inspection, a formal follow-up process is used to ensure a timely and corrective action.

104. Who are all involved in an inspection meeting?

Author, Moderator, Reviewer(s), Scribe/Recorder and Manager.

105. What is a Defect?

The variation between the actual results and expected results is known as a defect. If a developer finds an issue and corrects it by himself in the development phase then it’s called a defect. Click here for more details.

106. What is a Bug?

If testers find any mismatch in the application/system in testing phase then they call it as Bug. Click here for more details.

107. What is an Error?

We can’t compile or run a program due to a coding mistake in a program. If a developer unable to successfully compile or run a program then they call it as an error. Click here for more details. 

108. What is a Failure?

Once the product is deployed and customers find any issues then they call the product as a failure product. After release, if an end user finds an issue then that particular issue is called as a failure. Click here for more details.

109. What is Bug Severity?

Bug/Defect severity can be defined as the impact of the bug on customer’s business. It can be Critical, Major or Minor. In simple words, how much effect will be there on the system because of a particular defect. Click here for more details.

110. What is Bug Priority?

Defect priority can be defined as how soon the defect should be fixed. It gives the order in which a defect should be resolved. Developers decide which defect they should take up next based on the priority. It can be High, Medium or Low. Most of the times the priority status is set based on the customer requirement. Click here for more details.

111. Tell some examples of Bug Severity and Bug Priority?

High Priority & High Severity: Submit button is not working on a login page and customers are unable to login to the application

Low Priority & High Severity: Crash in some functionality which is going to deliver after couple of releases

High Priority & Low Severity: Spelling mistake of a company name on the homepage

Low Priority & Low Severity: FAQ page takes a long time to load

Click here for more details.

112. What is a Critical Bug?

A critical bug is a show stopper which means a large piece of functionality or major system component is completely broken and there is no workaround to move further.
For example, Due to a bug in one module, we cannot test the other modules because that blocker bug has blocked other modules. Bugs which affects the customers business are considered as critical.

Example:

1. “Sign In” button is not working on Gmail App and Gmail users are blocked to login to their accounts.
2. An error message pops up when a customer clicks on transfer money button in a Banking website.

113. What do you mean by Latent Defect and Masked Defect?

Latent Defect:

When users perform a particular task in an unusual or rare situation or without the presence of usual scenarios, latent defects are revealed.

A latent defect is a defect in the system that has been there for some time but have not yet been invoked because the conditions required to invoke them have not been met.

This systematic defect encompasses the entire software production process, from pre-production testing to extended post-release testing.

Latent defects are those which only become apparent under special circumstances – for example, when users try to perform a task in an unusual way or without the usual conditions present.

Masked Defect:

Although these defects have not led to a failure yet, they eventually will because another defect is preventing that section of the code from being executed. It can only be found when the defect hiding it is exposed by the user through a specific operation. Some defects are hidden by other, more predominant ones and go undetected until the latter is found.

114. What is the difference between a Standalone application, Client-Server application and Web application?

Standalone application:

Standalone applications follow one-tier architecture. Presentation, Business, and Database layer are in one system for a single user.

Client-Server Application:

Client-server applications follow two-tier architecture. Presentation and Business layer are in a client system and Database layer on another server. It works majorly in Intranet.

Web Application:

Web server applications follow three-tier or n-tier architecture. The presentation layer is in a client system, a Business layer is in an application server and Database layer is in a Database server. It works both in Intranet and Internet.

115. What is Bug Life Cycle?

Bug life cycle is also known as Defect life cycle. In Software Development process, the bug has a life cycle. The bug should go through the life cycle to be closed. Bug life cycle varies depends upon the tools (QC, JIRA etc.,) used and the process followed in the organization. Click here for more details.

116. What are the different stages in a defect life cycle?

The different stages in a bug life cycle are:

• New
• Assigned
• Open
• Test
• Moved to QA / Ready to test
• Verified
• Fixed
• Closed
• Retested
• Reopen
• Duplicate
• Deferred
• Rejected
• Cannot be fixed
• Not reproducible
• Need more information

117. What is Bug Leakage?

A bug which is actually missed by the testing team while testing and the build was released to the Production. If now that bug (which was missed by the testing team) was found by the end user or customer then we call it as Bug Leakage.

118. What is Bug Release?

Releasing the software to the Production with the known bugs then we call it as Bug Release. These known bugs should be included in the release note.

119. What is Defect Age?

Defect age can be defined as the time interval between date of defect detection and date of defect closure.

Defect Age = Date of defect closure – Date of defect detection

Assume, a tester found a bug and reported it on 1 Jan 2016 and it was successfully fixed on 5 Jan 2016. So the defect age is 5 days.

120. What is Error Seeding?

Error seeding is a process of adding known errors intendedly in a program to identify the rate of error detection. It helps in the process of estimating the tester skills of finding bugs and also to know the ability of the application (how well the application is working when it has errors.)

121. What is Error Guessing?

Error guessing is also a method of test case design similar to error seeding. In error guessing, testers design test cases by guessing the possible errors that might occur in the software application. The intention is to catch the errors immediately.

122. What is Showstopper Defect?

A showstopper defect is a defect which won’t allow a user to move further in the application. It’s almost like a crash.

Assume that login button is not working. Even though you have a valid username and valid password, you could not move further because the login button is not functioning.

123. What is HotFix?

A hotfix is a build aimed at resolving a severe issue found in production.

At times, a build executed in the production evironment would have some critical errors and it would be rolled back. Now development team kept all their work aside and focus on fixing these errors immediately and release a new build to fix that in the production. This build is referred as a hotfix.

Patches and hotfixes are two distinct types of software updates. Patches are available to the public, while hotfixes are not.

Hotfixes are also known as quick-fix engineering updates (QFE updates)

124. What’s a bugfix?

A bugfix is a build aimed at resolving a bug which is detected by the testers in the testing cycle.

125. What is a bug bounty?

A bug bounty program lets an organization offer reward to a person who find errors in their software and report them.

Bug bounty is a concept that has existed since the internet was created. Companies started to understand how expensive it is for them to hire experts in penetration testing every time they want to find vulnerabilities on their website or application. So recently, bug bounty programs become mainstream.

The first company to catch on to this concept was Google . It launched its “Vulnerability Reward Program” in 2010 and has paid out over $4 million since then.

126. What are the different strategies for rollout to end-users?

There are four strategies to be followed for the rollout of any software testing project are as follows:

• Pilot
• Gradual Implementation
• Phased Implementation
• Parallel Implementation

127. What is Boundary Value Analysis?

Boundary value analysis (BVA) is based on testing the boundary values of valid and invalid partitions. The Behavior at the edge of each equivalence partition is more likely to be incorrect than the behavior within the partition, so boundaries are an area where testing is likely to yield defects. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition. A boundary value for a valid partition is a valid boundary value. Similarly, a boundary value for an invalid partition is an invalid boundary value. Click here for more details.

128. What is Equivalence Class Partition?

Equivalence Partitioning is also known as Equivalence Class Partitioning. In equivalence partitioning, inputs to the software or system are divided into groups that are expected to exhibit similar behavior, so they are likely to be proposed in the same way. Hence selecting one input from each group to design the test cases. Click here for more details.

129. What is Decision Table testing?

Decision Table is aka Cause-Effect Table. This test technique is appropriate for functionalities which has logical relationships between inputs (if-else logic). In the Decision table technique, we deal with combinations of inputs. To identify the test cases with a decision table, we consider conditions and actions. We take conditions as inputs and actions as outputs. Click here for more details.

130. What is State Transition?

Using state transition testing, we pick test cases from an application where we need to test different system transitions. We can apply this when an application gives a different output for the same input, depending on what has happened in the earlier state. Click here for more details.

131. What is an entry criteria?

The prerequisites that must be achieved before commencing the testing process. Click here for more details.

132. What is an exit criteria?

The conditions that must be met before testing should be concluded. Click here for more details.

133. What is SDLC?

Software Development Life Cycle (SDLC) aims to produce a high-quality system that meets or exceeds customer expectations, works effectively and efficiently in the current and planned information technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.

Click here for more details.

134. What are the different available models of SDLC?

135. Can you do System testing at any stage of SDLC?

We can do System Testing only when all the units are in place and working properly. It can only be done before User Acceptance Testing (UAT).

136. What is the procedure of manual testing?

Manual testing is crucial for testing software applications more thoroughly. The procedure of manual testing comprises of the following.
1. Planning and Control
2. Analysis and Design
3. Implementation and Execution
4. Evaluating and Reporting
5. Test Closure activities

Refer Software Development Life Cycle (SDLC) & Software Testing Life Cycle (STLC)

137. What is STLC (Software Testing Lifecycle)?

STLC (Software Testing Life Cycle) identifies what test activities to carry out and when to accomplish those test activities. Even though testing differs between Organizations, there is a testing life cycle. Click here for more details.

138. What are the stages in the software testing lifecycle?

Following are the stages in the STLC.

• Requirement Analysis
• Test Planning
• Test Design
• Test Environment Setup
• Test Execution
• Test Closure

139. What is RTM?

Requirements Traceability Matrix (RTM) is used to trace the requirements to the tests that are needed to verify whether the requirements are fulfilled. We have to ensure that every requirement has atleast 1 test case. Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix. Click here for more details.

140. What is Test Metrics?

Software test metrics is to monitor and control process and product. It helps to drive the project towards our planned goals without deviation. Metrics answer different questions. It’s important to decide what questions you want answers to. Click here for more details.

141. When to stop testing? (Or) How do you decide when you have tested enough?

There are many factors involved in real-time projects to decide when to stop testing.

1. Requirement coverage reaches a specified point
2. Testing deadlines or release deadlines
3. When the complete testing budget is exhausted
4. By reaching the decided pass percentage of test cases
5. The risk in the project is under an acceptable limit
6. All the high priority bugs, blockers are fixed
7. When acceptance criteria is met
8. After the Alpha and Beta testing period ends
9. Depends on Management decision

Don’t miss: ISTQB Quiz

142. What is an API?

The term API stands for Application Programming Interface. In other words, it is a method of communication between two software components. An API shields the internal process and complexity of a software program while allowing users to focus only on the inputs and outputs required to use it. Consequently, this makes life much easier for everyone involved!

When developers are building software, they usually don’t write the code from scratch. Instead, they use other libraries that have been created by third parties. An API allows two separate components of software to communicate with each other by providing an interface for them to understand.

APIs can also provide the data an application needs. For example, pretend you’re building a weather app that displays temperature. You would rather access the meteorological institute’s API for this information instead of developing the technology to collect it yourself.

143. What is API Testing?

API testing is a type of software testing that involves testing APIs directly and also as a part of integration testing to check whether the API meets expectations in terms of functionality, reliability, performance, and security of an application. In API Testing our main focus will be on a Business logic layer of the software architecture. API testing can be performed on any software system which contains multiple APIs. API testing won’t concentrate on the look and feel of the application. API testing is entirely different from GUI Testing.

Learn API Testing

144. Which test cases are written first white boxes or black box?

The simple answer is black-box test cases are written first.

Let’s see why black-box test cases are written first compared to white box test cases.
Prerequisites to start writing black-box test cases are Requirement documents or design documents. These documents will be available before initiating a project.
Prerequisites to start writing white box test cases are the internal architecture of the application. The internal architecture of the application will be available in the later part of the project i.e., designing.

145. What is the workbench concept in Software Testing?

Workbench is a practice of documenting how a specific activity must be performed. It is often referred to as phases, steps, and tasks.

In every workbench there will be five tasks such as Input, Execute, Check, Production Output, and Rework.

146. What is Random testing?

In random testing is a form of black-box software testing technique where the application is testing by generating random data.

147. What are the different types of testing?

There are various ways to test software. Software developers conduct some types of testing while other kinds of software testing are done by QAs. The following are several types of software testing

148. What is a user story?

In software development, a user story is a description of a functionality that will be delivered to the end user. It is typically written from the user’s perspective and captures what the user needs or wants. A good user story should be small and self-contained, so that it can be easily implemented by the development team.

User stories are a key part of agile software development, and help to ensure that the final product will meet the needs of the end users. They also help to break down complex functionality into smaller, more manageable pieces.

149. What is SPICE in software testing?

SPICE is an acronym for Software Process Improvement and Capability dEtermination. It is a set of guidelines and practices that aim to improve the quality of software development and implementation. The main goals of spice are to improve the quality of software products, reduce development costs, and improve customer satisfaction.

150. What are the different HTTP status codes that a server can return?

The HTTP status code is a three-digit number that tells you the status of an incoming HTTP request. It indicates whether or not the request has been completed.

The five types of responses a server can send for an HTTP request are as follows.

• Information (100 – 199): Status code 1XX provides a brief response that includes the status line, some optional headers, and terminates with an empty line.
• Success (200 – 299): Status code 2XX means that the incoming HTTP request was successfully received, understood, and accepted. 
• Redirect (300 – 399): Status code 3XX are signs that tell the client what further actions to take in order to satisfy the HTTP request. The resource may have been moved temporarily or permanently, and the client may need to be redirected to another URL.
• A client error (400 – 499): Status code 4XX means a problem with the client who initiated the HTTP request.
• Server error (500 – 599): Status code 5XX means that the server had a problem processing the request.

151. Should you write white box test cases or black box test cases first?

Black-box test cases are usually written first, followed by white-box test cases. To write black box test cases, you need an outline of the design or project plan and the requirements document; both readily available at the beginning of a project.

White box testing requires more architecture clarification that isn’t initially available during the initial phase of a project.

Therefore, white-box test case development typically happens after black-box tests have been completed.

152. What effect does removing a defect during the latter stage, as opposed to the initial stage, have on cost?

It is crucial to fix any defects found in the beginning stages of a project because it will be much more expensive to do so later on. The cost of fixing a defect grows exponentially as time goes by.

Eliminating defects is cheaper during the design phase than waiting until maintenance, but if you wait, it’ll cost you twenty times more.

153. What is Use Case Testing?

Use case testing is a functional testing technique that helps testers to identify test scenarios based on the functionality of the software from start to finish.

In use case testing, the tester works through each step in a scenario, or use case, to ensure that the software behaves as expected. A use case is a description of how a user interacts with the software to achieve a goal.

For example, consider a scenario where a user wants to buy a product from an online store. The steps in this scenario would be:

• The user browses the store and adds the product to their shopping cart.
• The user goes to the checkout page and enters their payment information.
• The user confirms their order and clicks the “submit” button.
• The software processes the order and displays a confirmation message to the user.

To test this scenario using use case testing, the tester would carry out each step in the scenario and check that the software behaves as expected at each step.

Use case testing is a powerful technique for finding functional defects in software. It is especially useful for testing complex applications with many user interactions.

In Conclusion

Here I am going to conclude the post “Software Testing Interview Questions And Answers”. Final words, Bookmark this post “100 Software Testing Interview Questions” for future reference. After reading this Interview Questions for Manual Testing, if you find that we missed some important questions, please comment below we would try to include those with answers.

Here I have hand-picked a few posts which will help you to learn more interview related stuff along with these interview questions on manual testing.

If you have any more manual interview questions, feel free to ask via comments. If you find this post useful, do share it with your friends on Social Networking.