JSTQB Foundationのシラバスと用語集をもっと整備してほしい。(2)
【2011/05/17追記】この記事はちょっと古いのできれば
「FLシラバスのレビューメモ」も合わせて参照ください。
JSTQB Foundationの模擬問題を360問ほど作成し、ソフトウェアテスティング基礎コース(http://squaring.jp/EC03-JSTQB/)として提供を開始した。当然、JSTQBが公開しているシラバスと用語集をベースにしており、これらをかなり読み込んだ。その際に気づいたシラバス(V1.1.0、2009年改訂版)と用語集に関する問題を提示しておくことにした。以下の記事の続きだ。
【1】JSTQB Foundationの模擬問題360問(過去問100問を含む)を作成してみた。
【2】JSTQB Foundationのシラバスと用語集をもっと整備してほしい。
(1) シラバスが古い。
(2) IEEE 829標準の参照も古い。
(3) 用語集が不十分だ。
では、引き続いて気づいた点を挙げておく。
(4) 同義語が多い。
JSTQB Foundationのシラバスや用語集では、やたらと同義語が多い。冒頭の不正(anomaly)の用語である欠陥や誤りの定義でさえ、多くの同義語を許している。同義語はある程度はしかたないが、同じものを指していても捉える観点が異なる場合には、もう少し丁寧な説明があってもいいと思う。シラバス上で目立つものを列挙しておこう。用語集まで含めるとさらに同義語は増える。
- 誤り(mistake)＝エラー(error)
- 欠陥(defect)＝フォールト(fault)＝バグ(bug)
- コンポーネントテスト＝ユニットテスト＝モジュールテスト＝プログラムテスト
- 統合テスト＝結合テスト
- テストシナリオ＝テスト手順
- ユースケース＝シナリオ
- ブラックボックステスト＝仕様ベースのテスト
- ホワイトボックステスト＝グラスボックステスト＝構造ベースのテスト＝構造テスト
- 運用受け入れテスト＝運用テスト (※追記)
- ベータテスト＝フィールドテスト＝工場受け入れテスト＝サイト受け入れテスト
- 確認テスト＝再テスト(re-testing)
- ブランチ＝分岐
- デシジョン＝判定
- ブランチカバレッジ＝デシジョンカバレッジ(※ほぼ同等扱い)
- テストリーダ(test-leader)＝テストマネージャ
- プロジェクト管理者＝プロジェクトマネージャ
- レビューア＝インスペクタ＝チェッカー
- 書記＝記録係＝スクライブ(scribe)
- インシデント管理ツール＝欠陥追跡ツール
注意を必要とするのは、まずブラックボックステストとホワイトボックステストだ。対象の内部を透過して行うかどうかの観点と、仕様・構造・経験といった観点を混同して語ることは個人的には避けたほうがいいと思う。実際、シラバスV1.1.0では、ブラックボックステスト＝仕様ベースのテストとしながら、経験ベースのテストもブラックボックステストであるとしている。シラバス2010では、その曖昧性を回避するためか、ブラックボックステスト＝仕様ベースのテストとだけ明示し、経験ベースのテストはブラックボックスともホワイトボックスとも語らない方針に変わった。個人的には、ブラックボックス、ホワイトボックス(グラスボックス)、グレーボックスを語る部分と、仕様・構造・経験ベースで語る部分は明確に分けて説明すべきだと思う。
また、シラバスV1.1.0では、確認テスト＝再テスト(re-testing)としていたが、シラバス2010では、再テスト(re-testing)の方を強調し、あまり確認テストとは呼びたくないようだ。確認テストは死語になるだろう。
ブランチカバレッジ(ブランチテスト)とデシジョンカバレッジ(デシジョンテスト)は、厳密には定義が異なるはずだが、シラバス上ではほぼ同義として扱っている。しかし、単なる言い換えでなく、概念としては両者は異なることも意識はしているようだ。100%のデシジョンカバレッジは100%のブランチカバレッジを達成する、といった表現も過去の出題に見られる。(ちなみに、100%のデシジョンカバレッジは100%のステートメントカバレッジでもある。)
(5) テストプロセスが分かりにくい。
テストプロセスを分かりにくくしている理由として、用語の曖昧さ、シラバス上の構成のまずさ、不明瞭なテスト集合の扱いの3つがあると言える。基本的なテストプロセスは、計画とコントロール、分析と設計、実装と実行、終了基準の評価とレポート、終了作業の5つで構成されている。シラバスでは、この5つをフェーズと呼んでいる。ちなみに公式レビューのプロセスも6つのフェーズで構成されるとされている。個人的にはどうも違和感がある。基本的なテストプロセスで表現しているものは「プロセス領域」であるといえる。たとえば、計画とコントロールには、テスト計画という基本プロセスと、テストコントロールという支援プロセスで構成され、テスト計画には、テスト全体に対するマスターテスト計画と、各テストレベルごとのレベルテスト計画というアクティビティがあることが語られるべきである。テストコントロールは、計画だけでなく、設計・実行・終了判定も含めて監視制御するプロセスである。これらを含めたプロセス領域が「計画とコントロール」であるはずだ。現状のシラバスでは、計画とコントロールという活動の後に、分析と設計という活動がくると勘違いしてしまう人も多いのではないだろうか。
シラバス上の構成においても、計画とコントロールは後述の「テストのマネジメント」の章を参照するようになっている。テストの立ち上げと、モニタリングとコントロールを集めたもののようだ。それならば、テストの終結(＝終了作業)もそこに移動すべきであったかも知れない。
テストの単位(かたまり)として、シラバスでは3段階を想定している。テスト全体、各テストレベルでのテスト、特定の目的をもったテストの集合(テストセット)の3つである。これらは階層構造をしている。この構成の場合、テスト終了基準は、それぞれ設定する必要がある。テストセットが満たされれば、それはテストレベルの終了判定に反映される。通常、最後のテストレベルが満たされれば、テスト全体の終了作業に移行できる。ただしプロジェクトの打ち切りのようにテストレベルの途中でも終了作業に移行せざるを得ない場面もある。この部分は、市販の教科書本においても、シラバスとの対応関係をきちんと説明されているものはないように見える。シラバスの構成のまずさに原因があると思われる。
(6) リスク管理と動的リスクベースアプローチの扱いがはっきりしない。
テストのマネジメントでは、テスト計画、テスト進捗の監視とコントロール、構成管理、リスク管理、インシデント管理が語られている。テスト計画以外は、ほぼテストのライフサイクルの間、並行して行われるプロセスである。テスト進捗の監視とコントロール、構成管理、インシデント管理は明らかだろう。しかし、リスクに関してはタイトルも「リスクとテスト」として、概念だけを語り、プロセスとしての記述が足らない。これは計画時に事前に想定されるリスクを分析して明示しておくことのみにフォーカスしているからだ。一方では、動的なリスクベースアプローチもあることが語られている。これは、テストのライフサイクルの間、新たに浮上したリスクに対して、随時分析を行い、計画の見直しを行いながら進めるものだ。これについては詳細は一切ないのだ。
(7) 機能テスト(functional test)と機能性テスト(functionality test)がはっきりしない。
機能テストなのか、非機能テストなのか。機能テストなのか、機能性テストなのか。セキュリティテスト、相互運用性テストは、機能テストなのか非機能テストなのか。これにはいつもいらいらさせられる。ISTQBでもぐらついているようだ。ISO 9126のソフトウェア品質特性をベースにしているための弊害ともいえる。
ISO 9126のソフトウェア品質特性(非機能要件)を扱っている。その筆頭に機能性(functionality)があり、サブカテゴリとしてセキュリティ(security)や相互運用性(interoperability)がある。これは、本来、機能そのものではなく、機能充足性というべき非機能要件だ。"ility(=性)"が付くように性質を程度で示している。機能をどの程度満たしているかを示している。機能性(functionality)には正確性(accuracy)なども含まれる。これら機能性のテストを機能テスト(functional test)に含めるか、機能テストとは別の非機能テスト(non-functional test)としてまとめるかという問題なのだ。個人的には弊害があるため、セキュリティ、相互運用性、正確性などを含む機能性のテストは非機能テストにまとめたほうがいいと、いまだに思っている。
用語集では、セキュリティテスト(security test)は「ソフトウェア製品のセキュリティを判定するテスト。functionality test参照」、相互運用性テスト(interoperability test)は「ソフトウェア製品の相互運用性を判定するテスト手順。functionality test参照」、そして機能性テスト(functionality test)は「ソフトウェア製品の機能性を判定するためのテストの手順」とある。これらはISO 9126のソフトウェア品質特性を踏襲していることが分かる。
しかし、ISTQB/JSTQBのシラバスV1.1.0では、セキュリティテストは機能テストの一部とされ、相互運用性テストは非機能テストとされていた。それが最新のシラバス2010で、相互運用性テストも機能テストの方に移動させられることになった。ぐらついている状況がわかる。相互運用性テストと呼んでいいのだろうか。「ility(=性)」をつけたままだと非機能テストを感じさせるが、JSTQBはどう訳すのだろうか。相互運用テストに改称するかもしれない。
個人の思いとは別に、ISTQB/JSTQBでは、セキュリティテスト、相互運用性テストは機能テストとみなした訳だ。機能するがちょっとセキュリティに弱い、機能はするがちょっとつながりにくい、機能はするがちょっと精度が悪いというのは、非機能のような気がする。10数年前なら非機能で許されたが、現在は明確に機能として表現されるようになったのだろうか。
今日はここまでとしておこう。続きは後日。
