ISTQB 1.1 - What is Testing?

Requirement

A provision that contains criteria to be fulfilled.

What is a valid goal for a test team?

Cause as many failures as possible so that faults can be identified and corrected.

Unit testing

Component testing

Defect (K)

Synonyms: bug , fault An *imperfection or deficiency in a work product* where it *does not meet its requirements or specifications*.

Component testing

Synonyms: module testing , unit testing The testing of individual hardware or software components. (The *first level of testing*. - to find as many failures as possible to get them fixed early - to increase code coverage of the component test)

Testing (K)

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*. (Execute the software and find the failures that are caused by defects in the software.)

Examples of "work products"

- Requirements - User stories - Design - Code - Source code

Testing includes what activities?

- Test execution (including checking of results) - Test planning - Analyzing, designing, and implementing tests - Reporting test progress and results - Evaluating the quality of a test object

What is an example of a defect that causes harm?

A defect that causes raw sewage to be dumped in the ocean.

Test Case (K)

A set of - preconditions, - inputs, - actions (where applicable), - expected results and postconditions, developed based on test conditions. (The steps that we are following as we test.)

What is testing? (O)

A way to *assess the quality* of the software and *reduce the risk of* software *failure* in operation.

Failure (K)

An event in which a component or system *does not perform a required function* within specified limits.

Verification (K)

Confirmation by examination and through provision of objective evidence that *specified requirements* have been fulfilled. Checking whether the system meets *specified requirements*; what is on paper. Following what is written in the - requirements, - user stories, - other specifications.

Validation (K)

Confirmation by examination and through provision of objective evidence that *the requirements for a specific intended use or application* have been fulfilled. Checking whether the system meets *user and other stakeholder needs* in its operational environment. Going the extra step of making sure (beyond verifying with written requirement documents) that this is what the customer wants.

What best describes the difference between testing and debugging?

Dynamic testing shows failures caused by defects. Debugging finds, analyzes, and removes the causes of failures in the software.

When test cases are designed early in the lifecycle, verifying the test basis via the test design, which common test objective is being achieved?

Preventing defects

An important objective of testing activities in the software development lifecycle is...

Providing decision making information.

User Story

See Also: Agile software development, requirement A *high-level user or business requirement* commonly used in Agile software development, typically consisting of one sentence in the everyday or business language *capturing what functionality a user needs and the reason behind this, any non-functional criteria, and also includes acceptance criteria*.

Acceptance Testing

See Also: user acceptance testing Formal testing with respect to *user needs, requirements, and business processes* conducted to determine *whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system*. (Testing to confirm that the system works as it's supposed to and satisfies the requirements.) (The *last level of testing*. Object can be released once completed. Let the Stakeholders know the risks of releasing it at this time. Stakeholders will decide if they are ready or not.)

Confirmation Testing

Synonyms: re-testing *Dynamic testing* conducted after fixing defects with the objective *to confirm that failures* caused by those defects *do not occur anymore*. (To confirm that the developer debugged the code and solved the problem.)

Static Testing

Testing that *does not involve the execution* of the component or system being tested. Includes reviewing work products such as - requirements - user stories - source code

Dynamic Testing

Testing that *involves the execution* of the software of a component or system being tested.

Quality (K)

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

Debugging (K)

The *process of finding, analyzing and removing the causes of failures* in software. (This is done by the developer. He finds and fixes the defects. In Agile, testers may also be responsible for this.) (Identifying the cause of a defect, repairing the code and checking the fix is correct.)

Business Analyst and Tester

The Business Analyst sits with the customer and gathers requirements. The Tester reviews if they testable and achievable.

Test Object (K)

The component or system to be tested.

Typical Objective of Testing 4 (O)

To *build confidence in the level of quality* of the test object. (make sure that the quality of the test objects are satisfying.)

Typical Objective of Testing 9 (O)

To *comply with contractual, legal, or regulatory requirements or standards*, and/or to *verify the test object's compliance with such requirements or standards*. (Make sure what you are testing doesn't have any legal or contractual problems and that it complies with the laws of the country you're living in and with the contract that you signed with the customer.)

Typical Objective of Testing 1 (O)

To *evaluate work products* such as - requirements, - user stories, - design, and - code (by doing static testing).

Typical Objective of Testing 6 (O)

To *find failure and defects*.

Typical Objective of Testing 5 (O)

To *prevent defects*. (Done by static testing.)

Typical Objective of Testing 7 (O)

To *provide sufficient information to stakeholders* to allow them to make informed decisions, especially regarding the level of quality of the test object. (Provide the stakeholders sufficient information so that they can make the decision of whether they are ready to release the software or if it needs more development.)

Typical Objective of Testing 8 (O)

To *reduce the level of risk of inadequate software quality* (e.g. previously undetected failures occurring in operation). (Finding failures and defects in testing reduces the risk of them occurring in operation.)

Typical Objective of Testing 3 (O)

To *validate whether* the test object is *complete* and *works as* the users and other stakeholders *expect*. (You have something that you're testing, you need to ensure that - it is complete, - all the requirements are done, - validate it, whether or not it satisfies the users.)

Typical Objective of Testing 2 (O)

To *verify whether all specified requirements have been fulfilled*... (open the requirements document, compare it to the software that has been developed, find any differences between them. Are the requirements fulfilled or not?)