ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

I/JSTQBで述べられている「テストの目的」のちょっとした変化について

JSTQB エンジニア

Business of Software - DJ Wasabi

　I/JSTQBのシラバスで述べられている「テストの目的」が、Version2018の3.0と3.1で微妙に変わっていることに気づきました。
　まずシラバスへのリンクを貼っておきます。

jstqb.jp www.istqb.org

　このシラバスの1.1.1は「Typical Objectives of Testing」（テストの典型的な目的）を列挙しています。
　2018年6月のバージョンでは、以下の9つです。

2018r3.0

  • B1. To evaluate work products such as requirements, user stories, design, and code
  • B2. To verify whether all specified requirements have been fulfilled
  • B3. To validate whether the test object is complete and works as the users and other stakeholders expect
  • B4. To build confidence in the level of quality of the test object
  • B5. To prevent defects
  • B6. To find failures and defects
  • B7. To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the level of quality of the test object
  • B8. To reduce the level of risk of inadequate software quality (e.g., previously undetected failures occurring in operation)
  • B9. To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test object’s compliance with such requirements or standards

2019年11月のバージョンでは、以下のように、9つから7つに減っています。

2018r3.1

  • C1. To prevent defects by evaluate work products such as requirements, user stories, design, and code
  • C2. To verify whether all specified requirements have been fulfilled
  • C3. To check whether the test object is complete and validate if it works as the users and other stakeholders expect
  • C4. To build confidence in the level of quality of the test object
  • C5. To find defects and failures thus reduce the level of risk of inadequate software quality
  • C6. To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the level of quality of the test object
  • C7. To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test object’s compliance with such requirements or standards

　変更内容を確認するとともに、その意図を推測してみましょう。
　まず、B2・B4・B7・B9はそのまま、C2・C4・C6・C7に引き継がれていますね。
　これ以外の箇所で、大きく分けて2つの変更があります。

validateの意味を明確にしている・・・？

　まずC3は、B3のアップデートです。

  • B3: 「テスト対象が完成したことと、期待通りに動くこと」を validate する。
  • C3: 「テスト対象が完成したこと」を check し、「期待通りに動くこと」を validate する。

　この変更は、ソフトウェアテスト/品質の文脈で、validateという言葉が独特の意味を持っていることを意識しているように思えます。
　ISO/IEC 25000:2014 Systems and software Engineering の定義では、一つ目にこう説明されています。

validation.
(1) confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

　たとえば「仕様書通りに作った」ことをもって、「完成」はcheckできるかもしれません。でもこれはvalidateではありません。
　ユーザの要件を仕様に落とし込めていないかもしれない。暗黙の要件を拾い切れていないかもしれない。できたものが、「顧客が本当に必要だったもの」になっているかを確認するのがvalidateです。
　そういう意図から、checkとvalidateを分けたのかなと思いました。

note.com

　なお ISO/IEC/IEEE 24765 では、V&Vを以下のように定義しています。

verification and validation (V&V).
(1) process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements

　この定義とC3は、かなり似ているように思えますね。

テストにより積極な意味を持たせている・・・？

　B1「評価する」とB5「欠陥を予防する」が、C1「評価することによって欠陥を予防する」と統合されています。
　同様に、B6「故障と欠陥を見つける」、B8「リスクを下げる」が、C5「欠陥と故障を見つけることで、リスクを下げる」に統合されています。

　これは単に統合したというものではないとわたしは考えています。
　「評価する」「見つける」という段階で終わるのではなく、品質を上げるための積極的なアクションにつなげることも含めてテストの目的である、という意志の表明だと感じます。

　「テストは品質を上げない」という意見もあります。テストでは「バグが見つかった」「バグが見つからなかった」ということがわかるだけで、それに対しアクションを起こさなければ、品質なんて変わらないだということでしょう。
　それは一理あるのですが、「アクションを起こす」まで含めてテストエンジニアの役割なんじゃないの？と思っているわたしには、この皮肉めいた言い方があまり好きではありませんでした。
　完全に自己流解釈ですが、今回の3.1での改訂は、そのモヤモヤを解消してくれるな！と感じています。

日本語版への反映について

　なお、マイナーチェンジのローカライズ（つまり日本語版への反映）については、JSTQBの中のひとである湯本さんから教えていただきました。