1. Can you explain the PDCA cycle and where testing fits in?
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.
big fix
Let’s review the four steps in detail.
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/Test 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.
So developers and other stakeholders of the project do the “planning and building,” while testers do the check part of the cycle. Therefore, software testing is done in check part of the PDCA cyle.
2. What is the difference between white box, black box, and gray box testing?
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.
29-1
The above figure shows how both types of testers view an accounting application during testing. Black box testers view the basic accounting application. While during white box testing the tester knows the internal structure of the application. In most scenarios white box testing is done by developers as they know the internals of the application. In black box testing we check the overall functionality of the application while in white box testing we do code reviews, view the architecture, remove bad code practices, and do component level testing.
3. Can you explain usability testing?
Usability testing is a testing methodology where the end customer is asked to use the software to see if the product is easy to use, to see the customer’s perception and task time. The best way to finalize the customer point of view for usability is by using prototype or mock-up software during the initial stages. By giving the customer the prototype before the development start-up we confirm that we are not missing anything from the user point of view.
4. What are the categories of defects?
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.
5. How do you define a testing policy?
The following are the important steps used to 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.
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.
6. On what basis is the acceptance plan prepared?
In any project the acceptance document is normally prepared using the following inputs. This can vary from company to company and from project to project.
Requirement document: This document specifies what exactly is needed in the project from the customers perspective.
Input from customer: This can be discussions, informal talks, emails, etc.
Project plan: The project plan prepared by the project manager also serves as good input to finalize your acceptance test.
The following diagram shows the most common inputs used to prepare acceptance test plans.
