Term
| Identify the common reasons for testing |
|
Definition
To find and prevent defects - or faults - so serious failures do not occur after shipment.
Showing that software continues to work properly after a change to an existing system.
Predicting quality by measuring results of tests.
Legal requirements and contractual agreements |
|
|
Term
| Describe the causes of software failures |
|
Definition
People -> Errors -> Defects
Defects in requirements lead to bad design
Developers not testing while coding
Inappropriate use of a system
External environmental conditions |
|
|
Term
| Illustrate the possible impacts of software defects |
|
Definition
Defects in requirements can create a design flaw
Defects in design result in redesign and recoding
Defects in programming results in defects in the executable that is built/deployed
Defects in deployments are from environmental conditions that were not anticipated (hardware/improper use of a system) |
|
|
Term
| Explain how testing relates to software quality |
|
Definition
They are not the same.
Software quality is about big picture things - organizational policies, objectives, best practices, process improvements and measurement
QA testing is about evaluating software and providing info to stakeholders about the quality during the software lifecycle |
|
|
Term
| Identify the seven principles common to all testing |
|
Definition
1. Testing shows the presence of defects, not the absence of them
2. Exhaustive testing is impossible
3. Early testing is valuable
4. Defects cluster (Pareto Principle)
5. Pesticide paradox - running the same tests over and over won't find any new bugs
6. Testing is context dependent
7. Absence-of-errors fallacy - testing is pointless if the software doesn't fulfill the users' needs and expectations (or if it's unusable) |
|
|
Term
| List the standard test types |
|
Definition
Functional testing
Non-functional testing
Structural (white-box) testing
Change-related (maintenance) testing
Specification-based (black-box) testing |
|
|
Term
| Describe each of the test types |
|
Definition
Functional testing - usually checks against requirements. Examines from a user's perspective/expectations - inputs and outputs. Ie. interoperability testing
Non-functional testing - checks Reliability, Efficiency, Usability, Maintainability and Portability. Should be based on quantifiable requirements. ISO 9126
Structural testing - based on design and program code. Measured by code coverage. NOT debugging.
Change-related testing - performed after changes are made to an existing systems. This includes, but is not limited to regression testing
Specification-based testing - based on specifications and requirements and does not rely on the system's structure and code. Can include both functional and non-functional requirements. |
|
|
Term
| Identify the viewpoints of developers and testers |
|
Definition
Testing and developing should be separate in order to encourage more objective testing.
Developers are viewed as "constructive" and tend to test "what they did". They can take things personally when defects are discovered.
Testers are viewed as "destructive" and test against requirements. They can throw interpersonal skills out the window when documenting bugs. |
|
|
Term
| List ways testers can work effectively with developers |
|
Definition
| Testers should: communicate findings in a fact-focused way; include positive feedback; collaborate with developers. |
|
|
