ISTQB Chapter 1 Summary

Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

ISTQB Chapter 1 summary Notes

Distinguish between the root cause of a defect and its effects.


A human being can make an error (mistake), which produces a defect (fault, bug) in the program code, or
in a document. Defects in software, systems or documents may result in failures, but not all defects do so.

Give reasons why testing is necessary by giving examples.


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. Testing may also be required to meet contractual or
legal requirements.

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.

Defect - a flaw to cause failure.

Fault - defect

Failure - deviation from its expected delivery.

Mistake - Error.

Recall the common objectives of testing.


1. Finding defects

2. Gaining confidence about the level of quality

3. Providing information for decision-making

4. Preventing defects

Provide examples for the objectives of testing in different phases of the


software life cycle.
development testing: to cause as many failures as possible

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

operational testing: to assess system characteristics such as reliability and availability.

Differentiate testing from debugging.

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.

1. Test planning and control

2. Test analysis and d design

3. Test implementation and execution

4. Evaluating exit criteria and reporting

5. Test closure activities


The activities in the process may overlap or take place concurrently.

Recall the psychological factors that influence the success of testing.

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.

Contrast the mindset of a tester and of a developer.

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.

Testing and Quality


With the help of testing, it is possible to measure the quality of software in terms of defects found, for
both functional and non-functional software requirements and characteristics (e.g., reliability, usability,
efficiency, maintainability and portability) (Ref 1.1.4)

Role of Testing in Software Development, Maintenance and Operations


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.

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.

How Much Testing is Enough?

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.

How to prevent defects?

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.

Explain the seven principles in testing.


Principle 1: Testing shows presence of defects

Principle 2: Exhaustive testing is impossible

Principle 3: Early testing

Principle 4: Defect clustering

Principle 5: Pesticide paradox

Principle 6: Testing is context dependent

Principle 7: Absence-of-errors fallacy

Principle 1: Testing shows presence of defects


Testing can show that defects are present, but cannot prove that there are no defects.

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.

Principle 2: Exhaustive testing is impossible

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.

Principle 3: Early testing


To find defects early, testing activities shall be started as early as possible in the software or system
development life cycle, and shall be focused on defined objectives.

Principle 4: Defect clustering

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.

Principle 5: Pesticide paradox

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.

Principle 6: Testing is context dependent


Testing is done differently in different contexts. For example, safety-critical software is tested differently
from an e-commerce site.

Principle 7: Absence-of-errors fallacy


Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’
needs and expectations.
Test Planning

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.

Test Analysis and Design

The activity during which general testing objectives are transformed into tangible test conditions and test
cases.

Major Tasks of Test Analysis and Design:

- Reviewing the test basis

- Evaluating testability of the test basis and test objects

- Identifying and prioritizing test conditions

- Designing and prioritizing high level test cases

- Identifying necessary test data

- Designing the test environment

- Identifying required infrastructure and tools

- Creating bi-directional traceability between test basis and test cases

Test Implementation and Execution

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.

Major Tasks of Test Implementation and Execution:


- Finalizing, implementing and prioritizing test cases

- Developing and prioritizing test procedures

- Creating test suites


- Verifying that the test environment has been set up correctly

- Updating bi-directional traceability

- Executing test procedures

- Logging the outcome of test execution

- Comparing actual against expected results

- Reporting and analyzing discrepancies

Evaluating Exit Criteria and Reporting

The activity where test execution is assessed against the defined objectives.

Major Tasks of Evaluating Exit Criteria:

- 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

- Writing a test summary report for stakeholders

Test Closure Activities

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.

Major Tasks of Test Closure Activities:


- Checking which planned deliverables have been delivered

- Closing incident reports

- Documenting the acceptance of the system

- Finalizing and archiving testware

- Handing over the testware

- Analyzing lessons learned

- Using the information gathered to improve test maturity.

Levels of Independence

(Low to High)
Tests designed by:

- the person(s) who wrote the software under test

- another person(s) (e.g. from development team)

- a person(s) from a different organizational group (e.g. independent test team) or test specialists (e.g.
usability, performance, or security test specialists)

- a person(s) from a different organization or company (outsourcing)

Ways to improve communication between testers and others:

- Start with collaboration rather than battles

- Communicate findings on the product in a neutral, fact-focused way without criticizing

- 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

Describe the Role of Testing in Software Development, Maintenance and Operations.

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.

You might also like