Software Testing Interview Questions

Interview Questions

You can test the software in many different ways. Some types of testing are conducted by software developers and some by specialized quality assurance staff. Here are a few different kinds of software testing, along with a brief description of each.

Type Description
Unit Testing A programmatic test that tests the internal working of a unit of code, such as a method or a function.
Integration Testing Ensures that multiple components of systems work as expected when they are combined to produce a result.
Regression Testing Ensures that existing features/functionality that used to work are not broken due to new code changes.
System Testing Complete end-to-end testing is done on the complete software to make sure the whole system works as expected.
Smoke Testing A quick test performed to ensure that the software works at the most basic level and doesn’t crash when it’s started. Its name originates from the hardware testing where you just plug the device and see if smoke comes out.
Performance Testing Ensures that the software performs according to the user’s expectations by checking the response time and throughput under specific load and environment.
User-Acceptance Testing Ensures the software meets the requirements of the clients or users. This is typically the last step before the software is live, i.e. it goes to production.
Stress Testing Ensures that the performance of the software doesn’t degrade when the load increases. In stress testing, the tester subjects the software under heavy loads, such as a high number of requests or stringent memory conditions to verify if it works well.
Usability Testing Measures how usable the software is. This is typically performed with a sample set of end-users, who use the software and provide feedback on how easy or complicated it is to use the software.
Security Testing Now more important than ever. Security testing tries to break a software’s security checks, to gain access to confidential data. Security testing is crucial for web-based applications or any applications that involve money.

Software testing is governed by seven principles:

  • Absence of errors fallacy: Even if the software is 99% bug-free, it is unusable if it does not conform to the user’s requirements. Software needs to be bug-free 99% of the time, and it must also meet all customer requirements.
  • Testing shows the presence of errors: Testing can verify the presence of defects in software, but it cannot guarantee that the software is defect-free. Testing can minimize the number of defects, but it can’t remove them all.
  • Exhaustive testing is not possible: The software cannot be tested exhaustively, which means all possible test cases cannot be covered. Testing can only be done with a select few test cases, and it’s assumed that the software will produce the right output in all cases. Taking the software through every test case will cost more, take more effort, etc., which makes it impractical.
  • Defect clustering: The majority of defects are typically found in a small number of modules in a project. According to the Pareto Principle, 80% of software defects arise from 20% of modules.
  • Pesticide Paradox: It is impossible to find new bugs by re-running the same test cases over and over again. Thus, updating or adding new test cases is necessary in order to find new bugs.
  • Early testing: Early testing is crucial to finding the defect in the software. In the early stages of SDLC, defects will be detected more easily and at a lower cost. Software testing should start at the initial phase of software development, which is the requirement analysis phase.
  • Testing is context-dependent: The testing approach varies depending on the software development context. Software needs to be tested differently depending on its type. For instance, an ed-tech site is tested differently than an Android app.

The dictionary definition of regression is the act of going back to a previous place or state. In software, regression implies that a feature that used to work suddenly stopped working after a developer added a new code or functionality to the software.

Regression problems are pervasive in the software industry, as new features are getting added all the time. Developers don’t build these features in isolation, separate from the existing code. Instead, the new code interacts with the legacy code and modifies it in various ways, introducing side effects, whether intended or not.

As a result, there is always a chance that introducing new changes may negatively impact a working feature. It’s important to keep in mind that even a small change has the potential to cause regression.

Regression testing helps ensure that the new code or modifications to the existing code don’t break the present behaviour. It allows the tester to verify that the new code plays well with the legacy code.

Imagine a tourist in a foreign city. There are two ways in which they can explore the city.

  • Follow a map, itinerary, or a list of places they should visit
  • Explore randomly, following the streets as they lead them to new places

With the first approach, the tourist follows a predetermined plan and executes it. Though they may visit famous spots, they might miss out on hidden, more exciting places in the city. With the second approach, the tourist wanders around the city and might encounter strange and exotic places that the itinerary would have missed.

Both approaches have their pros and cons.

A tester is similar to a tourist when they are testing software. They can follow a strict set of test cases and test the software according to them, with the provided inputs and outputs, or they can explore the software.

When a tester doesn’t use the test scripts or a predefined test plan and randomly tests the software, it is called exploratory testing. As the name suggests, the tester is exploring the software as an end-user would. It’s a form of black-box testing.

In exploratory testing, the tester interacts with the software in whatever manner they want and follows the software’s instructions to navigate various paths and functionality. They don’t have a strict plan at hand.

Exploratory testing primarily focuses on behavioural testing. It is effective for getting familiar with new software features. It also provides a high-level overview of the system that helps evaluate and quickly learn the software.

Though it seems random, exploratory testing can be powerful in an experienced and skilled tester’s hands. As it’s performed without any preconceived notions of what software should and shouldn’t do, it allows greater flexibility for the tester to discover hidden paths and problems along those paths.

End to End testing is the process of testing a software system from start to finish. The tester tests the software just like an end-user would. For example, to test a desktop software, the tester would install the software as the user would, open it, use the application as intended, and verify the behavior. Same for a web application.

There is an important difference between end-to-end testing vs. other forms of testing that are more isolated, such as unit testing. In end-to-end testing, the software is tested along with all its dependencies and integrations, such as databases, networks, file systems, and other external services.

Unit testing is the process of testing a single unit of code in an isolated manner. The unit of code can be a method, a class, or a module. Unit testing aims to focus on the smallest building blocks of code to get confidence to combine them later to produce fully functioning software.

A unit test invokes the code and verifies the result with the expected result. If the expected and actual outcomes match, then the unit test passes. Otherwise, it fails.

A good unit test has the following characteristics:

  1. It should test a single piece of functionality.
  2. It is fully automated and repeatable.
  3. It should run quickly and provide immediate feedback.
  4. It should be isolated and shouldn’t interact with external dependencies such as network, database, or file system unless needed. You can use the mocking technique to simulate the external dependencies and isolate the code under test

API stands for Application Programming Interface. It is a means of communication between two software components. An API abstracts the internal workings and complexity of a software program and allows the user of that API to solely focus on the inputs and outputs required to use it.

When building software, developers rarely write software from scratch and make use of other third-party libraries. An API allows two software components to talk to each other by providing an interface that they can understand.

Another use of an API is to provide data required by an application. Let’s say you are building a weather application that displays the temperature. Instead of building the technology to collect the temperature yourself, you’d access the API provided by the meteorological institute.

A test environment consists of a server/computer on which a tester runs their tests. It is different from a development machine and tries to represent the actual hardware on which the software will run; once it’s in production.

Whenever a new build of the software is released, the tester updates the test environment with the latest build and runs the regression tests suite. Once it passes, the tester moves on to testing new functionality.

When software is being tested, the code coverage measures how much of the program’s source code is covered by the test plan. Code coverage testing runs in parallel with actual product testing. Using the code coverage tool, you can monitor the execution of statements in your source code. A complete report of the pending statements, along with the coverage percentage, is provided at the end of the final testing.

Among the different types of test coverage techniques are:

  • Statement/Block Coverage: Measures how many statements in the source code have been successfully executed and tested.
  • Decision/Branch Coverage: This metric measures how many decision control structures were successfully executed and tested.
  • Path Coverage: This ensures that the tests are conducted on every possible route through a section of the code.
  • Function coverage: It measures how many functions in the source code have been executed and tested at least once.

  • Black-box testing in software testing: In black-box testing, the system is tested only in terms of its external behaviour; it does not consider how the software functions on the inside. This is the only limitation of the black-box test. It is used in Acceptance Testing and System Testing.
  • White-box testing in software testing: A white-box test is a method of testing a program that takes into account its internal workings as part of its review. It is used in integration testing and unit testing.
  • Grey-box testing in software testing: A Gray Box Testing technique can be characterized as a combination of a black box as well as a white box testing technique used in the software testing process. Using this technique, you can test a software product or application with a partial understanding of its internal structure.

It is extremely beneficial to use automation testing when using the agile model in software testing. It helps in achieving maximum test coverage in a lesser time of the sprint.

  • Test Case: Test Cases are a series of actions executed during software development to verify a particular feature or function. A test case consists of test steps, test data, preconditions, and postconditions designed to verify a specific requirement.
  • Test Scenario: Usually, a test scenario consists of a set of test cases covering the end-to-end functionality of a software application. A test scenario provides a high-level overview of what needs to be tested.
  • Test Scripts: When it comes to software testing, a test script refers to the set of instructions that will be followed in order to verify that the system under test performs as expected. The document outlines each step to be taken and the expected results.

Bugs and errors differ in the following ways:

Bugs Errors
Software bugs are defects, which occur when the software or an application does not work as intended. A bug occurs when there is a coding error, which causes the program to malfunction. Errors in code are caused by problems with the code, which means that the developer could have misunderstood the requirement or the requirement was not defined correctly, leading to a mistake.
The bug is submitted by the testers. Errors are raised by test engineers and developers.
Logic bugs, resource bugs, and algorithmic bugs are types of bugs. Syntactic error, error handling error, error handling error, user interface error, flow control error, calculation error, and testing error are types of errors.
The software is detected before it is deployed in production. The error occurs when the code is unable to be compiled.

A test plan is basically a dynamic document monitored and controlled by the testing manager. The success of a testing project totally depends upon a well-written test plan document that describes software testing scope and activities. It basically serves as a blueprint that outlines the what, when, how, and more of the entire test process.

A test plan must include the following details:

  • Test Strategy
  • Test Objective
  • Test Scope
  • Reason for Testing
  • Exit/Suspension Criteria
  • Resource Planning
  • Test Deliverables

Test report is basically a document that includes a total summary of testing objectives, activities, and results. It is very much required to reflect testing results and gives an opportunity to estimate testing results quickly. It helps us to decide whether the product is ready for release or not. It also helps us determine the current status of the project and the quality of the product. A test report must include the following details:

  • Test Objective
  • Project Information
  • Defect
  • Test Summary

Test deliverables, also known as test artifacts, are basically a list of all of the documents, tools, and other components that are given to the stakeholders of a software project during the SDLC. Test deliverables are maintained and developed in support of the test. At every phase of SDLC, there are different deliverables as given below:

Before Testing Phase

  • Test plans document.
  • Test cases documents.
  • Test Design specifications.

During Testing Phase

  • Test Scripts
  • Simulators.
  • Test Data
  • Test Traceability Matrix
  • Error logs and execution logs

After testing Phase

  • Test Results/reports
  • Defect Report
  • Installation/ Test procedures guidelines
  • Release notes

Different categories of debugging include:

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