JSTQB Foundationのシラバスと用語集をもっと整備してほしい。

【2011/05/17追記】この記事はちょっと古いのできれば
FLシラバスのレビューメモ」も合わせて参照ください。

JSTQB Foundationの模擬問題を360問ほど作成し、ソフトウェアテスティング基礎コース(http://squaring.jp/EC03-JSTQB/)として提供を開始した。当然、JSTQBが公開しているシラバスと用語集をベースにしており、これらをかなり読み込んだ。日本語版だけでなく、ISTQBの原本であるシラバスとも対照している。また、ISTQBで公開されているサンプル問題を大いに活用している。

以前は、JSTQB Foundationのシラバスと用語集は、非常によく体系化されていて、内容に乏しいSWEBOKのソフトウェアテスティングの知識領域を補完する目的でよく利用していた。今回、これらを読み込んでみると、以前の感想とは反対に、ずいぶんといい加減な記述があるなと感じてしまった。この変化は、細部までじっくり確認したためではある。しかし、JSTQB Foundationのシラバスと用語集には本質的な欠陥があるといわざるを得ない。原本自体での曖昧さ、さらに翻訳した際の誤りが結構あるのだ。どんな点が問題なのか、気づいた点を列挙しておこうと思う。JSTQB Foundation試験を目指して学習されている方、シラバスや用語集をなんらかのベースに活用されている方に役立てばと思う。

(1) シラバスが古い。

現在、JSTQB Foundationのシラバスは、2007年5月にISTQBが公開したバージョンV1.1.0を訳したもの(2009年改訂)である。ISTQBの最新は2010年に公開されたバージョン2010というものだ。JSTQBは、昨年8月にAdvancedのトライアル試験を実施して今後の本格的なAdvancedの準備に忙しいのか、Foundationのバージョン2010への対応が遅れているように見える。それでも、おそらく次々回(第11回)にはバージョン2010に対応されることだろう。

ISTQBのバージョン2010で何が改訂されているかは、また別途取り上げることにする。これを語り出すと収拾が着かないかもしれない。バージョンV1.1.0でNGであったものが、バージョン2010ではOKになったりするものがある。大きな改訂のポイントのみ挙げておこう。

  • テストの目的が変更された。
  • 相互運用性テストは非機能テストではなく、機能テストとした。
  • 各テストレベルごとにテスト対象とテストベースが明示された。
  • 経験ベースはブラックボックスに分類しない。
  • 予防的アプローチ、対処的アプローチは除外された。
  • 開始基準(Entry Criteria)が明確にされた。
  • 行動指針(Code of Ethics)が追加された。
  • 公式レビューでレビューミーティングの範囲が拡大された。
  • テストツールの目的と意義が追加された。
  • 要求される知識レベルの表現が3段階から4段階(K4の追加)に変わった。
なんということか、根幹であるべき「テストの目的」まで変更されたのだ。目的の1つとして「意思決定のため情報を提供すること」がさらに明確化されている。また、これまでコードはテストベースであるともテスト対象であるとも曖昧に表現されていたが、今回、テストベースと明言された。ブラックボックステストは仕様ベースと経験ベースとされてきたものが、経験ベースはブラックボックステストとは呼ばないようになった。これらの変更は、試験問題でこれまでOKだったものがNGになるような変更を含んでいる。第10回試験が終了したら、模擬問題も次期バージョン2010に合わせて改訂しなければならない。

話を戻す。JSTQB Foundationのシラバスはまだバージョン2010に対応していない。古いのだ。

(2) IEEE 829標準の参照も古い。

ISTQB/JSTQBシラバスが、もっとも外部参照しているものにIEEE 829標準「Standard for Software Test Documentation」がある。テスト計画書、テストサマリーレポート、インシデントレポートのテンプレートなどはこれを参照している。しかし、IEEE 829の最新版は2008年版であるが、ISTQB/JSTQBが参照しているものは1998年版(2005年改訂)のものだ。これは、ISTQBバージョン2010においてもまだ古いものを参照しているとある。ネットでIEEE 829をダウンロードすると、ほとんど2008年の最新版となるので注意が必要だ。

IEEE 829標準が古いと、大きく2つの問題がある。1つは、テスト計画で必要と唱っているテストの開始基準と終了基準をテスト計画書のテンプレートのどこに記述すべきががはっきりしない。もう1つは、インシデントレポートでの再現手順(attempts to repeat)と再現性(reproducibility)の記述の要否がはっきりしないということだ。古いものでは再現手順(attempts to repeat)という項目で実は再現性を記述するようになっている。再現させるための試行回数や毎回起きるか稀に起きるかといった再現頻度に関するノートを記述するように指示されている。この状況で過去、再現手順と再現性についての問題は何度も出題されているのだ。

ちなみに開始基準だが、バージョン2010で明確化される。バージョンV1.1.0では開始基準を計画に記述することを推奨しているが、何をどこに記述すればいいかは明示されていなかった。唯一の記述が、テストコントロールにおいて「修正をビルドに反映させる前に、再テスト(確認テスト)を実施することを開始基準とする」という1例を挙げているに過ぎなかったのだ。

(3) 用語集が不十分だ。

JSTQB Foundationの試験範囲は、シラバスだけでなく、用語集も含んでいる。例えば、過去の出題でシラバスに記述されておらず、用語集のみに情報があるものを列挙してみる。モンキーテスト、ビッグバンテスト、スモークテスト、バック・ツー・バックテスト、データフローテスト、パステスト、デザインベーステスト、ビジネスシナリオやビジネスルール、ファンクションポイント法などがあった。ISTQBでは、さらに用語集に依存した設問が出題される傾向が高いことも分かっている。ちなみに、モンキーテスト、ビッグバンテスト、スモークテストは複数回出題されているので、要チェックだ。

ところが用語集の完成度はどうだろうか。まず見出しだけで説明のないものが多い。説明があっても丁寧ではなく良く分からない。シラバスとの表現が異なっているものもある。一例だが、sanity testやconfidence testをみると、smoke testを参照せよとしか記述されていない。smoke testを見ると、intake testも見ろとある。これらのテストの差を明確に説明できていないのだ。mutation test(変異テスト)をみると、back-to-back testを見ろとあるが、変異テストとバック・ツー・バックテストでは明らかに観点が異なるが、なんの説明もない。arc testとは何だ。誰か説明してくれ。operational profileを操作プロファイルと訳したり、運用プロフィールと訳したりして一貫性がない。などなどだ。

今日は、ここまでとします。続きは次回に。