Foundations Of Software Testing - Chapter 1

Front 1

Development Teams consist of:

Back 1

Business Analysts (BA)

Testers

Technical Specialists

Technical Writers

Trainers

Project Managers

User Representatives

- audience who uses product

Front 2

Successful Software Development Projects include:

Back 2

- User involvement

- Clear Requirements

- Solid Planning

- Realistic Expectations

- Support from Management

- Trained Professionals

- People who strive for a job well done & quality work

Front 3

How Do We Sell Testing

Back 3

- Cold Calling

- Networking

- Responding to RFPs

- Request for Proposals

- Typically Crown Corporations

Front 4

Analysts do what

Back 4

Define the features to include in scope of project

Front 5

Developers

Back 5

- create application

- code

Front 6

Project Managers

Back 6

- Ensure dates and timelines are met

- Adhere to budget

- Define what the scope is and stay within it

Front 7

Testers

Back 7

- Review the requirements

- Perform tests to ensure product runs as it was designed to

Front 8

PQA

Back 8

Founded in 1997 in Fredericton NB

Privately owned
CEO Keith Mcintosh

Canada's leading independent provider of quality assurance QA and testing solutions

110 employees testing professionals

6 offices across Canada

Fredericton - head office 40

Miramichi 1?

Moncton 10

Halifax 10

Vancouver 25

Calgary 15

Front 9

PLATO

Back 9

founded 2015

one head office in Fredericton 20

one head office in Mirimichi 12

Front 10

PQA/PLATO
Consulting

Back 10

QA and testing assessments

Training

Mentoring/coaching

Front 11

Phase Containment

Back 11

The extent to which defects are removed in the phase of introduction

Front 12

False-fail result

Back 12

A test result in which a defect is reported although no such defect actually exists

Front 13

False-positive result

Back 13

A test result in which a defect is reported although no such defect actually exists

Front 14

Error/mistake

Back 14

A human action that produces an incorrect result

Front 15

Defect (bug, fault)

Back 15

A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system

Front 16

Failure

Back 16

Deviation of the component or system from its expected delivery, service or result.

Front 17

Quality

Back 17

The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations

Front 18

Test Design Specification

Back 18

A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases

Front 19

Test Control

Back 19

A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows as deviation from what was planned.

Front 20

Test Case

Back 20

A set of input values, execution preconditions, expected results and execution preconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

Front 21

Test Objective

Back 21

A reason or purpose for designing and executing a test.

Front 22

Testing

Back 22

The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

Front 23

Requirement

Back 23

A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document.

Front 24

Review

Back 24

An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walk through.

Front 25

Debugging

Back 25

The process of finding, analyzing and removing the causes of failure in software.
Typically carried out by dev/programmer.

Front 26

Confirmation Testing

(re-testing)

Back 26

Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
While the glossary uses re-testing as the preferred term, this preference is out of step with ordinary usage and with the actual English-language definition of re-testing

Front 27

Test Strategy

Back 27

A high level description of the test levels to be performed and the testing within those levels for an organization or program (one or more projects)

Front 28

Seven Testing Principles

Back 28

1. Testing shows the presence of defects

2. Exhaustive testing is impossible

3. Early testing

4. Defect clustering

5. Pesticide Paradox

6. Testing is Context dependent

7. Absence of errors fallacy

Front 29

Complete Testing

AKA Exhaustive Testing

Back 29

A test approach in which the test suite comprise all combinations of input values and preconditions

Front 30

Zeno's Paradox

Back 30

Testing reduces possibility of defects found but it cannot be proven that no defects will be found.

Front 31

Principle 1

Testing shows presence of defects

Back 31

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.

Front 32

Principle 2

Exhaustive Testing is Impossible

Back 32

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.

Front 33

Principle 3

Early Testing

Back 33

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.

Front 34

Principle 4

Defect Clustering

Back 34

Testing effort shall be focused proportionally to the expected and later 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.

Front 35

Principle 5

Pesticide Paradox

Back 35

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.

Front 36

Principle 6

Testing is context dependent

Back 36

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

Front 37

Principle 7

Absence-of-errors Fallacy

Back 37

Finding and fixing defects does not help if the system built is unusable and does not fulfil the users' needs and expectations.

Front 38

Test Execution

Back 38

The process of running a test on the component or system under test, producing actual results.

Front 39

Test Approach

Back 39

The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project's goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed.

Front 40

Test Plan

Back 40

A document describing the scope, approach, resources and schedule of intended test activities. It identifies among others, test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used and the rationale for their choice and any risks requiring contingency planning. It is a record of the test planning process.

Front 41

Test Monitoring

Back 41

A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned.

Front 42

Test Condition

Back 42

An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element.

Front 43

Test Basis

Back 43

All documents from which the requirements of a system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a FROZEN TEST BASIS.

Front 44

Test Data

Back 44

Data that exists (for example in a database) before a test is executed, and that affects or is affected by the component or system under test.

Front 45

Coverage (test coverage)

Back 45

The degree expressed as a percentage, to which a specified coverage item has been exercised by a test suite.

Front 46

Test Procedure Specification

test procedure

test script

manual test script

Back 46

A document specifying a sequence of actions for the execution of a test.

Front 47

Test Suite

Back 47

A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.

Front 48

Incident

Back 48

Any event occurring that requires investigation

Front 49

Testware

Back 49

Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up, and clear-up procedures, files databases, environment, and any additional software or utilities used in testing.

Front 50

Regression Testing

Back 50

Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.

Front 51

Exit Criteria

Back 51

The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing.

Front 52

Test Log

Back 52

A chronological record of relevant details about the execution of tests.

Front 53

Test Summary Report

Back 53

A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria.

Front 54

Error Guessing

Back 54

A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as s result of errors made, and to design tests specifically to expose them.

Front 55

Independence Testing

Back 55

Separation of responsibilities, which encourages the accomplishment of objective testing.

Front 56

Test Policy

Back 56

High level document describing the principles, approach, and major objectives of the organizations regarding the testing.

Front 57

Code of Ethics

Public

Back 57

Public:
Certified software testers shall act consistently in the public interest.

Front 58

Code of Ethics

Client and Employer

Back 58

Certified software testers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.

Front 59

Code of Ethics

Product

Back 59

Certified software testers shall ensure that the deliverables they provide (on the products and systems they test) meet the highest professional standards possible.

Front 60

Code of Ethics

Judgement

Back 60

Certified Software Testers shall maintain integrity and independence in their professional judgement.

Front 61

Code of Ethics

Management

Back 61

Certified software testers and leaders shall subscribe to and promote an ethical approach to the management of software testing.

Front 62

Code of Ethics

Profession

Back 62

Certified software testers shall advance the integrity and reputation of the profession consistent with the public interest.

Front 63

Code of Ethics

Colleagues

Back 63

Certified software testers shall be fair to and supportive of their colleagues and promote cooperation with software developers.

Front 64

Code of Ethics

Self

Back 64

Certified Software Testers shall participate in lifelong learning regarding the practice of their profession and shall promote and ethical approach to the practice of the profession.