Software Testing Interview Questions and Answers-1

In this article, we will cover questions, which can help you prepare well for an interview for software testing jobs.

What is difference between Test Scenario and Test case?

In layman terms, Test scenario is any functionality which can be tested. It is a high-level condition or a set of conditions which need to be tested to verify a functionality. It might result into one or many test cases. The test cases which need to be created to fulfill the test scenario might be positive or negative.

While Test scenario is a high-level condition, test case gives us a set of actions which need to be done in a sequential manner to test the condition in the application. A Test Case contains test steps, test data, precondition, post-condition developed for specific condition or scenario to verify any given requirement. The test case includes expected results while it is designed and on execution, actual results are used to determine whether a software product is functioning as per the requirements or not.

What is Test Basis?

All documents from which the requirements of a component or system can be inferred i.e., the documentation on which the test cases are based. In most formal projects, like for defense or healthcare, a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis.

What is a Latent Defect?

A Latent defect, as the name suggests, is a defect which is hidden or concealed. Since it could not be discovered with reasonable amount of software testing, it accompanies the software into production system as well. It may not be discovered until a very specific set of conditions is met. It can even lead to failure of system if the specific conditions are met. Latent defects are usually very difficult to identify since the conditions required to product them are very difficult to be met and might not be part of usual test conditions.

What is the difference between Latent Defect and a Masked defect?

As explained above, Latent defect is a defect which is hidden and not yet identified by the course of testing. However, a masked defect is a defect remains unidentified as another defect has prevented that part of the code from being executed.

In case of a Latent defect, the conditions causing the defect are not yet met and hence it can occur whenever the conditions are met. In case of masked defect, it will occur if the masking defect is fixed, and the masked code gets executed eventually.

What is entry and exit criteria?

Entry Criteria gives the prerequisite items that must be completed before testing can begin.

Example – All the test cases must be reviewed and approved by product team before a sprint execution can begin.

Exit Criteria defines the items that must be completed before testing can be concluded.

Example – 95% of the tests should be passed and there is no critical bug open before we can close the sprint.

What is requirement traceability matrix and why is it must to maintain?

A traceability matrix is a document that corelates two baseline documents which can have many to many relationships. It helps to identify the completeness of relationship.

RTM or requirement traceability matrix is a document that maps and traces user requirement with test cases. It captures all requirements proposed by the client and covered test cases in a single view, usually delivered as a deliverable, at the conclusion of the Software development life cycle.

It is usually maintained in a test case management tool or sometimes in excel sheets.

The main purpose of Requirement Traceability Matrix is to validate that all requirements are covered via test cases such that no functionality is left uncovered during software testing phase.

RTM is very important to maintain to know what requirements have been covered via test cases and executed. If there are defects, we can know which requirements are failing. If they are business critical requirements, it can help push for prioritizing the defects.

What is Horizontal Traceability and Vertical Traceability?

As explained in above question, test conditions should be able to be linked back to their sources in the test basis - this is called traceability. Traceability can be either horizontal through all the test documentation for a given test level (e.g. system testing, from test conditions through test cases to test scripts) or vertical through the layers of development documentation (e.g. from requirements to components).

Give an example of bug which is high severity and low priority.

This is a tricky question and requires practical knowledge on behalf of the candidate. This question requires that tester understands the concepts of severity and priority clearly.

Example – A link in footnote is not working and as per analytics, it is not very highly used by customers.

Reasoning - This defect although impacts the application and is causing functionality to be hindered but there is no real impact as customers of application rarely use the link.

Give an example of bug which is low severity and high priority.

Example – A spelling mistake in name of the client/application/major information on the application.

Reasoning - This defect although does not have functional impact and is cosmetic if looked in isolation. However, when looked from the customer perspective, this kind of bug will leave a very bad impression and customer might not even return to the application. Hence, it must be fixed asap.

What is Fault seeding or Defect Seeding?

The process of intentionally adding known defects to those already in the component or system to monitoring the rate of detection and removal and estimating the number of remaining defects is called fault seeding or defect seeding.

What is Test Closure Report?

Test closure report is basically a document that provides the summary of all the tests that are performed during SDLC. It gives full detailed analysis reports of the bugs that are discovered and removed. It is usually performed prior to the end of the testing process and is a formal documentation for handing over the application to production support or run teams.

Continued..