or
Can You explain the PDCA cycle and Where Testing Fits in
Ans: Software testing is an important part of 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.
a) Plan: Define the goal and the plan for achieving that goal.
b) Do/Execute: Depending on the plan strategy decided during the plan stage we do execution accordingly in this phase.
c) Check: Check/Test to ensure that we are moving according to plan and are getting the desired results.
d) Act: During the check cycle, if any issues are there, then we take appropriate action accordingly and revise our plan again.
The answer to the question is Check part of the cycle
b) Do/Execute: Depending on the plan strategy decided during the plan stage we do execution accordingly in this phase.
c) Check: Check/Test to ensure that we are moving according to plan and are getting the desired results.
d) Act: During the check cycle, if any issues are there, then we take appropriate action accordingly and revise our plan again.
The answer to the question is Check part of the cycle
2. What is the difference between white box, black box, and gray box testing?
Ans : Black box testing is a testing strategy based solely 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.
There is one more type of testing called gray box testing. In this we look into the “box” being tested just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.
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.
There is one more type of testing called gray box testing. In this we look into the “box” being tested just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.
3. W hat is the difference between a defect and a failure?
Ans : 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.
There are three main categories of defects:
Wrong: The requirements have been implemented incorrectly. This defect is a variance from the given specification.
Missing: 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.
Extra: 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.
Wrong: The requirements have been implemented incorrectly. This defect is a variance from the given specification.
Missing: 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.
Extra: 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.
4. W hat is the difference between verification and validation?
Ans: 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.
5. How does testing affect risk?
Ans: 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.
6. D oes an increase in testing always improve the project?
Ans : No an increase in testing does not always mean improvement of the product, company, or project. In real test scenarios only 20% of test plans are critical from a business angle. Running those critical test plans will assure that the testing is properly done.
7. How do you define a testing policy?
Ans: The following are the important steps used define a testing policy in general. But it can change according to your organization. Let’s discuss in detail the steps of implementing a testing policy in an organization.
Software Testing Basics
Definition: The first step any organization needs to do is define one unique definition for testing within the organization so that everyone is of the same mindset.
How to achieve: How are we going to achieve our objective? Is there going to be a testing committee, will there be compulsory test plans which need to be executed, etc?.
Evaluate: After testing is implemented in a project how do we evaluate it? Are we going to derive metrics of defects per phase, per programmer, etc. Finally, it’s important to let everyone know how testing has added value to the project?.
Standards: Finally, what are the standards we 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
Software Testing Basics
Definition: The first step any organization needs to do is define one unique definition for testing within the organization so that everyone is of the same mindset.
How to achieve: How are we going to achieve our objective? Is there going to be a testing committee, will there be compulsory test plans which need to be executed, etc?.
Evaluate: After testing is implemented in a project how do we evaluate it? Are we going to derive metrics of defects per phase, per programmer, etc. Finally, it’s important to let everyone know how testing has added value to the project?.
Standards: Finally, what are the standards we 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
8. Should testing be done only after the build and execution phases are complete?
Note: This question will normally be asked to judge whether you have a
traditional or modern testing attitude.
traditional or modern testing attitude.
Ans : In traditional testing methodology (sad to say many companies still have that attitude) testing is always done after the build and execution phases. But that’s a wrong way of thinking because the earlier we catch a defect, the more cost effective it is. For instance, fixing a defect in maintenance is ten times more costly than fixing it during execution.
Testing after code and build is a traditional approach and many companies have improved on this philosophy. Testing should occur in conjunction with each phase .In the requirement phase we can verify if the requirements are met according to the customer needs. During design we can check whether the design document covers all the requirements. In this stage we can also
generate rough functional data. We can also review the design document from the architecture and the correctness perspectives. In the build and execution phase we can execute unit test cases and generate structural and functional data. And finally comes the testing phase done in the traditional way. i.e., run the system test cases and see if the system works according to the
requirements. During installation we need to see if the system is compatible with the software. Finally, during the maintenance phase when any fixes are made we can retest the fixes and follow the regression testing.
generate rough functional data. We can also review the design document from the architecture and the correctness perspectives. In the build and execution phase we can execute unit test cases and generate structural and functional data. And finally comes the testing phase done in the traditional way. i.e., run the system test cases and see if the system works according to the
requirements. During installation we need to see if the system is compatible with the software. Finally, during the maintenance phase when any fixes are made we can retest the fixes and follow the regression testing.
9. A re there more defects in the design phase or in the coding phase?
Note: This question is asked to see if you really know practically which phase is the most defect prone.
Ans: The design phase is more error prone than the execution phase. One of the most frequent defects which occur during design is that the product does not cover the complete requirements of the customer. Second is wrong or bad architecture and technical decisions make the next phase, execution, more prone to defects. Because the design phase drives the execution phase it’s the most critical phase to test. The testing of the design phase can be done by good review. On average, 60% of defects occur during design and 40%
during the execution phase.
during the execution phase.
10.W hat is the difference between latent and masked defects?
Ans : A latent defect is an existing defect that has not yet caused a failure because the exact set of conditions were never met.
A masked defect is an existing defect that hasn’t yet caused a failure just because another defect has prevented that part of the code from being executed.
The application has the ability to print an invoice either by laser printer or by dot matrix printer. In order to achieve it the application first searches for the laser printer. If it finds a laser printer it uses the laser printer and prints it. If it does not find a laser printer, the application searches for dot matrix printer. If the application finds a dot matrix printer (DMP) the application prints using or an error is given.
Now for whatever reason this application never searched for the dot matrix printer. So the application never got tested for the DMP. That means the exact conditions were never met for the DMP. This is called a latent defect. Now the same application has two defects: one defect is in the DMP search and the other defect is in the DMP print. But because the search of the DMP fails the print DMP defect is never detected. So the print DMP
defect is a masked defect.
defect is a masked defect.
