Software Testing Interview Questions for Manual Testers – Part1

Probably you landed on this blog as you were looking for some authentic sources for QA interview preparation. We’ve assembled here some of the most relevant Software testing interview questions to help in your preparations.

You’ll certainly enjoy all the testing questions that we’ve laid down in this post. The interviewer may ask you questions on core testing areas, which you can find here.

We’ve tried this online questionnaire to be as useful as it could be for Software testers and QA engineers. You can use this list as a quick reference and revise the basic principals of Software testing in your free time.

The questions like equivalence partitioning, boundary value analysis, state transition testing, decision table, traceability matrix and risk analysis are still relevant and will always be. Here, we’ve answered them all in a simplified manner so that you can understand the concepts instead of just memorizing the answers.

Software Testing Interview Questions for Manual Testers - Part1

Software Testing Interview Questions for Manual Testers – Part1.

Software Testing Interview Questions for Manual Testers.

1. What is equivalence partitioning? Explain by example.

It’s a famous black box testing technique which defines the effectiveness of manual test cases. You can apply it to a range of testing areas like unit testing, acceptance testing, integration testing and so on. It works by breaking the test data into different sets and selecting one input value from each range.

Since it’s not possible to validate all data points from the domain, because any attempt to do so would result in huge no. of test cases. Hence, you should apply this technique in such situations. It classifies the data into different classes where each class lays the input criteria from the equivalence class.


Assuming an application which accepts dates from the calendar year. If we apply the above technique, then we can break the inputs into classes. For example, one for valid dates and another for invalid dates. We’ll now create test cases from each class.

TC#1. Valid date class would allow cases with dates from the current calendar year.

TC#2. Dates from years other than the current calendar year would belong to the invalid class.


2. What is boundary value analysis? Explain by example.

Most of the errors emanate either from the head or the tail ends of the test data. The values at these extreme ends are the boundary values. And the process to analyze them is Boundary value analysis. We may sometimes call it as <range checking>.

It’s one more black box testing approach which focuses on finding errors at the terminating ends of the input domain. You can use this technique at all levels of testing.

While designing test cases using BV, you should consider both valid and invalid boundary values for the edges. Usually, we pick one test case from each boundary.

Let’s see some examples to demonstrate the use of BV analysis.

TC#1. The first test case will analyze exact boundary values from the input data. Considering the example in Q:1, it would be the dates from the January and the dates from the December.

TC#2. For invalid values, you may consider using the dates from months other than the Jan or Dec.


3. What is state transition testing? Explain by example.

This approach is best suitable where there is a possibility to view the whole system as a <finite state machine>. It works on the notion that a system can be in a finite no. of distinct states. And it’s the rules of the machine that drive the transitions from one state to another.

It’s the model on which is the basis for the system and the test cases. Any system which produces a different output for the constant input, depending on what has happened before, is a finite state system.


For example, you can consider a bank account. If you use it regularly, it’ll stay active. If you don’t make any transaction for over a period of 12 months, then your account will become inactive. You can though choose to close your account. Once it’s closed, you can not use it until you reopen. So, a bank account can have the following states.

1. Open,
2. Inactive,
3. Close,
4. Reopen.

Hence, you can design cases to test all transitions around the states mentioned above. In this model, you measure coverage in terms of switches, see below.

1. <0-switch> => You are testing every valid transition.
2. <1-switch> => You’ve covered the pair of two valid transitions.
3. <2-switch> => You need to test the sets of 3 transitions for this coverage.


4. What is the difference between a white box, black box, and gray box testing?

4.1. Black box testing is a testing approach which depends completely on the product requirements and specifications. The knowledge of internal paths, structures, or implementation of the software isn’t a prereq for it.
4.2. White box testing is a testing mechanism which covers the internal paths, code structures, and implementation of the software under test. It generally demands that a tester should possess serious programming skills.
4.3. Last but not the least is the gray box testing. It allows looking into the “box” being tested to understand the implementation. Finally, you close the box and apply knowledge to choose more effective black box tests.


5. What are the categories of defects?

There are three main categories of defects:

5.1. Wrong: It indicates a mismatch in the requirement and the implementation. It implies a variance from the given specification.
5.2. Missing: The end product doesn’t have a feature matching the requirement. It’s a variance from the specifications and represents that you didn’t document the requirement properly.
5.3. Extra: You added a feature which the customer didn’t ask for. It’s again a variance from the specification. And the users of the product may like this feature. But it’s still a defect because it’s not the part of the specs.


6. What is the basis to prepare for an acceptance plan?

First of all, you need inputs from the following areas to prepare for the acceptance document. These may vary from company to company and from project to project.

6.1. Requirement document: This document specifies what exactly is needed in the project from the customer’s perspective.
6.2. Customer Input: It could be discussions, informal chats, email addresses, etc.
6.3. Project Plan: The project plan from the project manager (PM) also serves as a good input to conclude your acceptance test.


7. What is Requirement Traceability Matrix?

It’s a common Software testing interview question which you might get asked during an interview. The Requirements Traceability Matrix (RTM) is a requirement tracking tool that ensures the requirements are same for the whole development process. There are following reasons to use it:

7.1. To determine whether the developed project is meet the requirements of the user.
7.2. To determine all the requirements given by the user.
7.3. To make sure the application requirement can be fulfilled in the verification process.


8. Describe how to perform Risk analysis during software testing?

Risk analysis is the process of foreseeing the risk in an application and prioritizing them to test. Following are some of the risks:

8.1- New Hardware.
8.2. New Technology.
8.3. New Automation Tool.
8.4. The sequence of code delivery.
8.5. Availability of application and test resources.

You can prioritize them into three categories in the following manner:

i. High magnitude: Impact of the bug on the other functionality of the application.
ii. Medium: It can be tolerable in the application but not desirable.
iii. Low: It can be bearable. This type of risk has no impact on the company business.


9. How to deal with a bug which is intermittent and not reproducible?

Again, it’s one of the practical software testing interview questions. A bug might not be reproducible for a variety of reason. Some of these are as follows.

9.1. Low memory.
9.2. Addressing an unavailable memory location.
9.3. Things happening in a particular sequence.


10. When do you perform decision table testing?

We may use the <decision table testing> for testing systems for which the specification takes the form of rules or cause-effect sequence. In a decision table, the input gets listed in a column, with the outputs in the same column but below the inputs. The remainder of the table examines the different sets of inputs to define the outputs produced.


Summary – Software Testing Interview Questions for Manual Testers.

We hope you would have liked this tiny list of Software testing interview questions and answers. If you’ve any query to ask, then please use the comment box and share with us.

You can also submit questions which you think are relevant for the Software testing interviews. We’ll review them and add to the list. It’ll benefit all of our readers.




Leave a Reply