Important Software Testing Interview Questions: Part 1

While preparing for Interview in Software Testing a good basic knowledge of software Testing fundamentals is always better than complex things because your knowledge about Testing will be reflected through the work you have done and the basics you have followed while doing the Testing. 
Below are some of the important testing questions which you'll find being asked in almost each interview. The interviewer might ask them in a different way but more or less basic things are the same. Lets have a look at some questions:

Q1. Where does Software Testing fits in the software development process?

In normal software development there are four important steps, also referred 
to, in short, as the PDCA (Plan, Do, Check, Act) cycle.

Plan:Define the goal and the plan for achieving that goal.
Do/Execute:Depending on the plan strategy decided during the plan stage we do execution accordingly in this phase.
Check:Check to ensure that we are moving according to plan and are getting the desired results.
Act:During the check cycle, if any issues are there, then we take appropriate action accordingly and revise our plan again.

As you can see clearly that testing fit in the check part of the cycle. So developers and other stakeholders of the project do the “planning and building,” while testers do the check part of the cycle.

Q2. What is the difference between White box, Black box, and Gray Box testing?

Black box testing is a testing strategy based on requirements and 
specifications. Black box testing requires no knowledge of internal paths, 
structures, or implementation of the software being tested.

White box testing is a testing strategy based on internal paths, code 
structures, and implementation of the software being tested. White box testing generally requires detailed programming skills. So in most scenarios white box testing is done by developers as they know the internals of the application like unit test.

Gray box testing is a different type where we just check long enough to understand how the system has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.

Q3. what is the difference between a defect and a failure?

When a defect reaches the end customer it is called a failure and if the defect 
is detected internally and resolved it’s called a defect.

Q4. Why does the defect occur?

There are three main reasons for occurrence of defects:

The requirements have been implemented incorrectly. This defect 
is a variance from the given specification.

There was a requirement given by the customer and it was not done. 
This is a variance from the specifications, an indication that a specification was not implemented, or a requirement of the customer was not noted properly.

A requirement incorporated into the product that was not given by 
the end customer. This is always a variance from the specification, but may 
be an attribute desired by the user of the product. However, it is considered 
a defect because it’s a variance from the existing requirements.

Q5. what is the difference Between verification and validation?

Verification is a review without actually executing the process while validation 
is checking the product with actual execution. For instance, code review and 
syntax check is verification while actually running the product and checking 
the results is validation.

Verification:  Are we building the product right?
Validation:   Are we building the right product?

Q6. How does testing affect risk?

A risk is a condition that can result in a loss. Risk can only be controlled in 
different scenarios but not eliminated completely. A defect normally converts 
to a risk. For instance, let’s say you are developing an accounting application 
and you have done the wrong tax calculation. There is a huge possibility that 
this will lead to the risk of the company running under loss. But if this defect 
is controlled then we can either remove this risk completely or minimize it. 
The following diagram shows how a risk gets converted to a risk and with 
proper testing how it can be controlled. 

Q7. How can we implement a testing Policy ?

Test Policy describes about the organization definition of testing or its philosophy towards testing. This is generally developed by the top level management(IT Dept. Managers). It contains:

1. Definition of testing
2. The process or procedure or standard we need to follow for good quality 
3. The quality level to be achieved 
4. Cost to fix the issues

For implementing the Testing Policy an organization needs to understand:

How are they going to achieve their objective? Is there going 
to be a testing committee, will there be compulsory test plans which need to 
be executed, etc.?

After testing is implemented in a project how will they evaluate it? Are they going to derive metrics of defects per phase, per programmer, etc. It’s important to let everyone know how testing has added value to the project?

Finally, what are the standards they want to achieve by testing. For 
instance, we can say that more than 20 defects per KLOC will be considered 
below standard and code review should be done for it. 

You Might Want to Read
Important Software Testing Interview Questions: Part 2

No comments: