ISTQB Chapter 1 Summary
ISTQB Chapter 1 Summary
ISTQB Chapter 1 Summary
Describe why testing is part of Quality Assurance and give examples of how
testing contributes to higher quality.
Quality in terms of defects found, for both functional and non-functional software requirements and
characteristics (reliability, usability, efficiency, maintainability and portability. Improving quality of
future systems.
Explain and compare the terms error, defect, fault, failure, and the
corresponding terms mistake and bug, using examples.
Error - Human action that produces incorrect result.
Fault - defect
Mistake - Error.
4. Preventing defects
acceptance testing: to confirm that the system works as expected, that it meets requirements, to assess
the quality of the software, to determine the risk of releasing the software at a given time.
Maintenance testing: no new defects have been introduced during development of the changes
Dynamic testing (done by testers) can show failures that are caused by defects.
Debugging (done by developers) is the development activity that finds, analyzes and removes the cause of
the failure.
Recall the five fundamental test activities and respective tasks from planning to closure.
Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to
detail, good communication with development peers, and experience on which to base error guessing.
The tester and test leader need good interpersonal skills to communicate factual information about defects,
progress and risks in a constructive way. For the author of the software or document, defect information
can help them improve their skills. Defects found and fixed during testing will save time and money
later,and reduce risks.
Testing activities
These activities include planning and control, choosing test conditions, designing and executing test cases,
checking results, evaluating exit criteria, reporting on the testing process and system under test, and
finalizing or completing closure activities after a test phase has been completed. Testing also includes
reviewing documents (including source code) and conducting static analysis.
Software testing may also be required to meet contractual or legal requirements, or industry-specific
standards.
Testing and Software Quality
Testing can give confidence in the quality of the software if it finds few or no defects. A properly
designed test that passes reduces the overall level of risk in a system. When testing does find defects, the
quality of the software system increases when those defects are fixed.
Deciding how much testing is enough should take account of the level of risk, including technical, safety,
and business risks, and project constraints such as time and budget.
Testing should provide sufficient information to stakeholders to make informed decisions about the
system.
Designing tests early in the life cycle can help to prevent defects from being introduced into code.
Reviews of documents (e.g.,requirements) and the identification and resolution of issues also help to
prevent defects appearing in the code.
Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects
are found, it is not a proof of correctness.
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases.
Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.
Testing effort shall be focused proportionally to the expected and late r observed defect density of
modules. A small number of modules usually contains most of the defects discovered during pre-release
testing, or is responsible for most of the operational failures.
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find
any new defects. To overcome this “pesticide paradox”, test cases need to be regularly reviewed and
revised, and new and different tests need to be written to exercise different parts of the software or system
to find potentially more defects.
The activity of defining the objectives of testing and the specification of test activities in order to meet the
objectives and mission. It takes into account the feedback from monitoring and control activities.
Test Control
The ongoing activity of comparing actual progress against the plan,and reporting the status, including
deviations from the plan. It involves taking actions necessary to meet the mission and objectives of the
project. In order to control testing, the testing activities should be monitored throughout the project.
The activity during which general testing objectives are transformed into tangible test conditions and test
cases.
The activity where test procedures or scripts are specified by combining the test cases in a particular order
and including any other information needed for test execution, the environment is set up and the tests are
run.
The activity where test execution is assessed against the defined objectives.
- Checking test logs against the exit criteria specified in test planning
- Assessing if more tests are needed or if the exit criteria specified should be changed
These activities collect data from completed test activities to consolidate experience, testware, facts and
numbers. They occur at project milestones such as when a software system is released, a test project is
completed (or canceled), a milestone has been achieved, or a maintenance release has been completed.
Levels of Independence
(Low to High)
Tests designed by:
- a person(s) from a different organizational group (e.g. independent test team) or test specialists (e.g.
usability, performance, or security test specialists)
- Try to understand how the other person feels and why they react as they do
- Confirm that the other person has understood what you have said and vice versa
Rigorous testing of systems and documentation can help to reduce the risk of problems occurring during
operation and contribute to the quality of the software system, if the defects found are corrected before the
system is released for operational use.
Describe with examples, the way in which a defect in software can cause harm to a person, to the
environment or to a company.
Software that does not work correctly can lead to many problems, including loss of money, time or
business reputation, and could even cause injury or death.