ISO IEC IEEE 29119-1-2022 pdf download

ISO IEC IEEE 29119-1-2022 pdf download.Software and systems engineering — Software testing Part 1: General concepts
4.1.4 Test item
The term “test item” describes a work product that is an object of testing. Other terms used for “test item” are “test object”, “software under test” and “system under test”. A test item can be either a complete system or a part of a larger system, including hardware, software, and related documentation.
A test item can be either executable (e.g. binary code, some models) or not executable (e.g. a documented specification). If the test item is executable, then dynamic testing can be performed, otherwise (it is not executable) only static testing can be performed by means of reviews, static analysis and model verification, as shown in Figure 1. While the focus of the ISO/IEC/IEEE 29119 series is on software and related documents, many of the described concepts are also applicable to other test items, such as complete systems comprising both hardware and software.
4.1.5 Static and dynamic testing
Testing can take two forms: static and dynamic, as shown in Figure 1. Static testing is evaluation of a test item where no execution of the code takes place and can be performed manually (e.g. reviews) or by using tools (e.g. static analysis). For static testing, the test item can take the form of documentation or source code, and it can be performed anywhere in the life cycle. Reviews and example review types are described in detail in ISO/IEC 20246. Reviews range in formality and include inspections, technical reviews, walkthroughs, and informal reviews. Static analysis involves the use of tools to detect anomalies in code or documents without execution (e.g. a compiler, a cyclomatic complexity analyser, or a security analyser for code). Dynamic testing involves executing code and running test cases. Dynamic testing can thus only occur in the parts of the life cycle when executable code is available.
4.1.6 Exhaustive testing and sampling
To prove – by dynamic testing – that a specific test item meets all requirements under all given circumstances, then all possible combinations of input values in all possible states would need to be tested.
This impractical activity is referred to as “exhaustive testing”. For a simple software program, the number of combinations of input values is very large (e.g. a program processing two 64‑bit numbers would require 2 128 tests just to cover all possible input combinations). In practice, test items tend to be more and more complex, and so the application of exhaustive testing is not possible.
For that reason, in practice software testing derives test suites by sampling from the (extremely large) set of possible input combinations and states. Choosing the subset of possible tests that are most likely to uncover issues of interest is one of the most demanding tasks of a tester. The ISO/IEC/IEEE 29119 series recommends the use of risk‑based testing (see 4.2.2) as the basis for selecting the tests to be used.
4.1.7 Testing as a heuristic In engineering (and software engineering) a heuristic is an experience‑based (trial and error) method that can be used as an aid to problem solving and design. However, while heuristics can be used to solve problems, they are fallible in that sometimes they may not solve, or only partially solve, a problem. Much of systems and software testing is based on heuristics. For instance, they are useful when creating models of the system to be tested; however, they may fail to fully model the system and so defects in the system may not be found even though the testing appears to be complete. Recognition that the manner in which testing is undertaken may be fallible makes it possible to partially treat the risk of an ineffective test approach by employing multiple approaches in the test strategy.
4.1.8 Purpose of testing Testing usually serves more than one purpose.
Typical purposes include, but are not restricted to:
a) detecting defects – this allows for their subsequent removal thus increasing software quality;
b) gathering information on the test item – testing generates information; this information can serve different purposes, such as:
— developers can use the information to remove defects, increase the code quality or learn to create better code in the future;
— testers can use the information to create better test cases;
— managers can use the information to decide when to stop testing;
— users eventually benefit from a higher product quality.
c) creating confidence and taking decisions – by providing evidence that the test item performs correctly under specific circumstances, the stakeholders’ confidence that the test item will perform correctly operationally increases; with sufficient confidence, stakeholders can decide to release the test item. Testing may be performed for some or all of the above purposes; and additional purposes not listed may also exist; these purposes should be identified and agreed as a starting point to any testing activity.ISO IEC IEEE 29119-1 pdf download.ISO IEC IEEE 29119-1-2022 pdf download