ISO/IEC TR 29119-13:2022 ソフトウェアおよびシステム工学 — ソフトウェア テスト — Part 13: 生体認証システムのテストにおける ISO/IEC/IEEE 29119 シリーズの使用 | ページ 8

5.5.1 ISO/IEC/IEEE 29119 シリーズ以前の試験規格

2013 年までは、いくつかのソフトウェア テスト標準が利用可能でした。たとえば、BS 7925-2 はソフトウェア コンポーネントの動的テストを対象とし、IEEE 829 はテスト ドキュメントを対象としていました。ただし、ソフトウェア テストのほんの一部しか標準でカバーされておらず (たとえば、テスト管理はカバーされていませんでした)、一部の標準はトピックのカバー範囲が重複しており、しばしば矛盾するガイダンスを提供していました。

5.6.1 ソフトウェアテストの核となるリスクベースのテスト

リスクベース テスト (RBT) は、ISO/IEC/IEEE 29119 シリーズの中心的な概念であり、テスト戦略の内容を決定するための主要なドライバーとしてリスクが使用されることを期待しています。

テストによるリスク管理 (RBT) のプロセスは、他のほとんどのリスク管理プロセスと似ています。最初に潜在的なリスクが特定され、場合によっては ISO/IEC 25010 で定義されているような品質特性に基づくチェックリストが使用されます。それらは発生することになっていました。要件の品質、スタッフの能力、システムの複雑さ、履歴情報などの要因に基づいて、各リスクの可能性が判断されます。次に、各リスクの影響と可能性の組み合わせに基づいて、リスク エクスポージャ レベルが確立されます。それに応じてリスクに優先順位を付け、適切な (または可能な場合) 場合は治療法を決定します。あるリスクの治療法が別のリスクの原因になったり、別のリスクにさらされる可能性が高くなったりする可能性があることを常に念頭に置いてください。

附属書 C は、一般的な生体認証システムに適用される一連のリスクを提供します (つまり、特定の生体認証特性に固有のものではありません)また、生体認証システムのテストのためのテスト戦略 (およびテスト計画) に含まれる、これらのリスクを処理するために使用できるソフトウェア テスト アクションの例も提供します。

5 Introduction to software testing

5.1 Software testing in context

Software testing has been a fundamental part of software development since well before life cycle models were defined, with references to a separate software testing activity being made as early as 1954.^[46] Today, estimates for the proportion of life cycle costs spent on testing vary from below 20 % up to 80 % for safety-critical systems.

Software testing is a form of quality control, which, together with quality assurance comprise quality management. Verification and validation are both quality control concepts supported by software testing; verification focuses on the conformance of a test item with specifications, specified requirements, or other documents, while validation focuses on the value of the test item in respect to the intended use by the stakeholders.

5.2 Static and dynamic testing

Software testing can take two forms; static and dynamic.

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). Reviews, as defined in ISO/IEC 20246, 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 and can be performed manually or using test tools. The test cases are generated using test design techniques, as defined in ISO/IEC/IEEE 29119-4 and can be black-box (based on a specification), white-box (based on the source code) or some mix of the two (grey-box). The requirement to create test cases tends to make the cost of dynamic testing far higher than static analysis.

5.3 Systematic software testing

To prove 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 dynamically tested. This activity is referred to as “exhaustive testing”, but, in practice, test items tend to be complex enough that the application of exhaustive testing is not possible. For this 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 but is helped by the use of test case design techniques, which provide a systematic means of deriving this subset.

5.4 Purpose of testing

Testing usually serves more than one purpose. Typical purposes include, but are not restricted to, the following.

• Detecting defects - this allows for their subsequent removal thus increasing software quality.
• 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 assess the project situation.

• 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.

5.5 Standardization and software testing

5.5.2 The ISO/IEC/IEEE 29119 series

In 2007 the proposal for a new set of standards on software testing was approved by ISO, to be based on existing IEEE and BSI standards (e.g. IEEE 829, BS 7925-1 and BS 7925-2). The ISO/IEC/IEEE 29119 series is intended to support testing in a wide variety of application domains, for varying levels of criticality and in any life cycle; thus, the standards are generic and can be applied to:

• the full range of quality characteristics, both functional and non-functional;
• all industrial domains;
• safety critical and non-safety critical systems;
• exploratory and scripted testing;
• any life cycle model, including traditional (e.g. waterfall, V-model) and agile (e.g. Scrum, Kanban, hybrid);
• automated testing.

The underlying model used as the basis for the ISO/IEC/IEEE 29119 series is shown in Figure 1, with the test processes at the core. The test documentation is produced by executing the test processes; thus, the test documentation describes the outputs of the test processes. The requirement to use techniques to design the test cases is specified by the test processes in ISO/IEC/IEEE 29119-2, while the different test design techniques are defined separately in ISO/IEC/IEEE 29119-4. The overall concepts used by the other parts are defined in ISO/IEC/IEEE 29119-1.

Figure 1— ISO/IEC/IEEE 29119 software testing standards

Soon after work on the first four parts of the ISO/IEC/IEEE 29119 series started, ISO/IEC 33063 on test process assessment (assessing against the test processes defined in ISO/IEC/IEEE 29119-2) was created by a separate proposal and this was followed by the development of ISO/IEC/IEEE 29119-5 on keyword-driven testing. The first three parts were initially published in 2013, ISO/IEC/IEEE 29119-4 in 2015 and ISO/IEC/IEEE 29119-5 was published in 2016. A separate standard on reviews (ISO/IEC 20246) was subsequently developed to complement the dynamic testing covered by the other standards and was published in February 2017. Updated second editions of ISO/IEC/IEEE 29119-2, ISO/IEC/IEEE 29119-3 and ISO/IEC/IEEE 29119-4 were published in 2021.

5.5.3 ISO/IEC JTC 1/SC 7/WG 26 (software testing)

The ISO/IEC/IEEE 29119 series was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering, in cooperation with the Software and Systems Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development Organization cooperation agreement between ISO and IEEE. WG 26 was set up in 2007 to develop the standards.

5.6 Risk-based testing

5.6.2 Risk categories

Risks can be categorized as either product or project risks.

Product risks are concerned with the deliverable product (in this case the biometric system) and include possible losses or harm to users or other stakeholders due to the product not performing as required.

Project risks are concerned with how the product is developed and include the threat that developers, testers, and other project members lack the necessary skills or time to perform their required activities, or that the product will be delivered late or over budget.

Bibliography