Stepin2it.COM Call 416-743-6333 for software testing training Toronto, Brampton, Scarborough,Mississauga.
Software Testing training Toronto Basics
The following diagram shows the most common inputs used to prepare acceptance test plans.
Source :http://www.indiabix.com
Software Testing training Toronto Basics
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.
Let's review the four steps in detail.
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.
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.
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.
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.
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.
Source :http://www.indiabix.com
No comments:
Post a Comment