シラバス2011とシラバスV1.1.0の違いを説明してみる。
【2011/05/17追記】この記事は「FLシラバスの改訂のポイント」の方にまとめておきました。
JSTQBは今月4/07にFoundationのシラバス2011を公開しました。次回8/27に実施される第11回FL試験から適用されます。あわせて用語集も4/22に改訂されています。前回第10回FL試験まではシラバスV1.1.0(2009年改訂版)が使われてきました。以前のシラバスや教科書本で学習されてきた方で、次回第11回FL試験にも挑戦しようと考えられている場合、今回の改訂に戸惑われることもあるかと思います。dentakurouさんのブログで当方のプログをトラックバックしていただいたにも関わらず、今回の改訂については情報をまとめきれずに、過去記事に分散したままの状況でした。改めて、シラバス2011が以前のシラバスV1.1.0からどのように変化したかのポイントを説明しておきたいと思います。
なお、その前にISTQBとJSTQBではバージョンの遷移がことなることを説明しておく必要があるでしょうか。ISTQBのシラバスは、V1.1.0から、2010、2011と進化してきました。JSTQBはV1.1.0からいきなり2011になりました。途中の2010が飛ばされたことになります。バージョン2010は日本語で公開されたことはありませんので、ほとんどの方はV1.1.0からバージョン2011に進化したと思われているかもしれません。私のように趣味でISTQBのシラバスもチェックしている方はごく少ないとは思います。実は、シラバス2011の改訂の大半は、2010で既に対応されており、2010から2011への改訂は、わずかなケアレスな間違いの修正程度です。ほばシラバス2010＝シラバス2011と考えてよいでしょう。
試験問題の観点で捉えると、今回の改訂には重要な修正もあります。例えば、「相互運用性テストは非機能テストか」という設問があった場合、V1.1.0ではOKですがバージョン2011ではNGとなります。「経験ベースの技法はブラックボックスか」という設問があった場合、V1.1.0ではOKですがバージョン2011ではNGとなります。「対処的アプローチ」という概念は出題されなくなります。各テストレベルごとにテスト対象とテストベースが明確化されたので、これに関する出題が多くなると予想されます。
では、シラバスV1.1.0からシラバス2011への改訂のポイントです。個人的に重要だと思うものに(■)をマークしています。(□)は軽微なものです。ここに取り上げるものは個人的に大切だろうと思うものであって、JSTQBやISTQBが主張するものではありません。JSTQBやISTQBの主張は、シラバス巻末のリリースノートを参照してください。なお、シラバス2011の日本語訳はまだ完成度が高くないようです。ここでの解説は、ISTQBのシラバス2011をべースにさせていただきます。用語が若干JSTQBのものと違う場合がありますが、読者で補完ください。
(■) テストの目的が変更された。
(■) 各テストレベルごとにテスト対象とテストベースが明示された。(※非常に重要)
(□) テストベースとテストケースのトレーサビリティについて補足された。
(□) 経験ベースはブラックボックスに分類しない。
(□) 開始基準(Entry Criteria)が明確にされた。
(■) 行動指針(Code of Ethics)が追加された。
(□) 確認テストと呼ぶよりも再テストと呼ぶ方が一般的と判断した。
(■) 相互運用性テストは非機能テストではなく、機能テストとした。(※非常に重要)
(■) 予防的／対処的アプローチが除外された。テストアプローチと戦略の関係が整理された。
(■) レビューミーティングが「検査・評価・記録」に変更された。
(□) テストツールの目的と意義(ツールによるテストへの支援)が追加された。
(■) データ品質とテストやリスクとの関係が追加された。
(□) 要求される知識レベルの表現が3段階から4段階(K4の追加)に変わった。
(□) IEEE 829:2008標準に対するコメントが付記された。
テストの目的が変更された。
根幹であるべき「テストの目的」まで変更されています。目的の1つとして従来の「対象ソフトウェアの品質レベルが十分であることを確認し、その情報を示す」が2つに分割され、明確化されています。テストの目的として次の4つが挙げられました。
* 欠陥を検出する。
* 品質レベルについて確信を得る。
* 意思決定のための情報を提供する。
* 欠陥の作りこみを防ぐ。
テストの目的に関する問題は毎回1問は出題されるので、抑えておく必要があります。
各テストレベルごとにテスト対象とテストベースが明示された。(※非常に重要)
今回の改訂でもっとも画期的であるのは、各テストレベルごとにテスト対象とテストベースが明示されたことでです。従来のJSTQBのシラバスでは、コードはテストベースであるともテスト対象であるとも曖昧に表現されてました(矛盾する記述があった)が、今回からテストベースであると明言されています。また曖昧だった利用者マニュアルもシステムテストのテスト対象であることが明言されています。整理すると以下のようになります。なお、JSTQBのシラバスでは解釈の違う部分もありますので、判断は読者にお任せします。テストレベルごとにテストベースと典型的なテスト対象をまとめています。テスト対象には「典型的」が添えているように、一例であると考えてください。「構成データ」として挙げられているものは、構成データの中で具体的に何をテスト対象とするかは、テスト計画で決めておく必要があります。
| テストレベル | テストベース | 典型的なテスト対象 |
|---|---|---|
| コンポーネントテスト | ■コンポーネント要件 ■詳細設計 ■コード | ■コンポーネント (※オブジェクト、クラスなども) ■プログラム ■データ変換プログラムやデータ移行プログラム ■データベースモジュール |
| 統合テスト | ■ソフトウェア設計とシステム設計 ■アーキテクチャ (※アーキテクチャ記述) ■ワークフロー ■ユースケース | ■サブシステム ■データベースの実装 ■インフラ (※OS、ファイルシステム、ハードウェアなど) ■インタフェース (※コンポーネント間、システム間) ■システム構成 ■構成データ (※何を対象とするかは計画で明示する) |
| システムテスト | ■システム要求仕様とソフトウェア要求仕様 ■ユースケース ■機能仕様 ■リスク分析レポート | ■システム ■ユーザーマニュアルや運用マニュアル ■システム構成 ■構成データ (※何を対象とするかは計画で明示する) |
| 受け入れテスト | ■ユーザー要求 ■システム要求 ■ユースケース ■ビジネスプロセス ■リスク分析レポート | ■完全統合されたシステムを活用したビジネスプロセス ■運用プロセスと保守プロセス ■ユーザー手続き(User procedures) ■フォーム (※入力帳票) ■レポート (※出力帳票) ■構成データ (※何を対象とするかは計画で明示する) |
またもう1つ強化されているのは、データの扱い、データべースについてのテストです。上記でも、データベースモジュール、データ変換プログラムやデータ移行プログラム、データベースの実装がテスト対象として明示されました。また運用受け入れテストでも、データのロードとデータ移行をチェックすることが盛り込まれました。またテストツールとしても「データ品質評価ツール」が取り上げられ、データの重要性やボリュームに関するテストも強調されています。
ちなみに、ソフトウェアの完全性レベルとは、ソフトウェアが満たしている、あるいは満たさなければならない程度であり、利害関係者が選定したソフトウェア(新規開発だけでなく、市販品の購入も含む)や、ソフトウェアに依存するシステムの特性(例えば、複雑さ、リスク診断、安全性レベル、セキュリティレベル、要求される性能、信頼性、コストなど)が満たされている程度を表現するものです。ソフトウェアの重要な点を利害関係者に理解してもらうためにも、これらの完全性レベルを定義しておきたい。と、シラバスで解説されています。
今後の出題では、テストベースとテスト対象を問う問題が充実してくるでしょう。システムテストは、システムだけでなく、付属的なユーザーマニュアルや運用マニュアルもテスト対象することが明示されているので、このあたりの問題も出てきそうです。
テストベースとテストケースのトレーサビリティについて補足された。
これは大したことはありません。テストベースとテストケースは双方向にトレースできるようにしておく、という1文が追加されただけです。
経験ベースはブラックボックスに分類しない。
これまで、ブラックボックステストは仕様ベースと経験ベースとされてましたが、経験ベースはブラックボックステストとは呼ばない方針のようです。エラー推測は、経験ベースの技法とされています。エラー推測は、ある程度、内部構造が分かっていないと適用できる範囲は限定されてしまいます。経験ベースの技法にはブラックボックスのものもあるし、グレーボックスのものもあるため、あえてシラバス2011では言及しない方針にしたと思われます。エラー推測は、欠陥の履歴や統計を利用する「欠陥ベースの技法」ともいえますが、Foundationではそれを無理やり経験ベースというカテゴリに押しこんだ弊害があったのかもしれません。
経験ベースはグレーボックスとみなす、あるいはブラックボックスもあればホワイトボックスもあると理解する必要があります。これまでの試験でも経験ベース＝ブラックボックスといった出題はなかったのではないだろうかと推測します。ですから、大きな変更と考える必要はないでしょう。
開始基準(Entry Criteria)が明確にされた。
開始基準が具体化されています。以前のシラバスでは、開始基準を計画時に設定しておくことだけが述べられ、何をどこに記述するかは語られていませんでした。しかし、今回も内容的にはごく当り前のことです。テスト環境、テストツール、コード、テストデータが準備できているかをチェックせよという程度の記述です。依然として、テスト計画書のどこに記述するかといった説明はありません。ちなみに、シラバスV1.1.0で開始基準についての唯一の具体的な記述は、テストコントロールにおいて「修正をビルドに反映させる前に、開発者が再テスト(確認テスト)を実施していることを開始基準とする」というものでした。これはシラバス2011でも活きています。
開始基準に関する出題も出てきますが、一般論で解答できると思われます。テスト環境、テストツール、コード、テストデータが準備できているか、ビルドに対してスモークテストを実施しているか、といったことです。
行動指針(Code of Ethics)が追加された。
行動指針は、どんな資格試験でも提示されています。JSTQBで提示されている内容はごく当り前のことです。認定されたテスト担当者やテストリーダに要求される、公共の利益(public interest)を意識したふるまい、行動指針に沿った倫理的なアプローチが示されています。
今後の出題でも出てくる可能性がありますが、公共の利益(public interest)というポイントを抑えておけば十分で、個人情報とか、PMPなどで頻出の「利害の衝突」といった出題はないだろうと予測します。
確認テストと呼ぶよりも再テストと呼ぶ方が一般的と判断した。
ISTQBでは確認テストと表現するのはやめて、再テストで統一したい旨が記述されています。しかしJSTQBではどうでしょうか。当面は確認テストの表現も残るのではないでしょうか。再テストには、「単に同じテストをもう1回やる」という意味と、「修正された欠陥を確認するために再度同じテストをやる」という2つの意味があります。ISTQBのいう再テストの定義は後者です。でも日本では、漠然と再テストといえば前者を指して捉える人も多いでしょう。確認テストの方が、日本では適しているように思います。
相互運用性テストは非機能テストではなく、機能テストとした。(※非常に重要)
非機能テストに分類されていた相互運用性テストが機能テストに分類されました。はい、そうですかといった感じですが、ISTQB/JSTQBにあわせてそう把握するしかありません。セキュリティテストも機能テストです。機能性テストそのものも機能テストと同義として扱われているので、シラバスでは明言されていませんが、正確性テストも機能テストとみなす必要がありそうです。個人的には異論がありますが、受験者は相互運用性テスト、セキュリティテストは機能テストに含まれ、機能テスト＝機能性テストとみなすものと把握しておく必要があります。
ちなみに私は、相互運用性テスト、セキュリティテスト、正確性テストは非機能テストに分類すべきだと思っています。ISTQBの判断が理解できていません。今回初めて相互運用性テストを非機能から機能に移動させたという経緯からも、ISTQBでも判断に揺らいでいる状況があるのかもしれません。
機能性(functionality)＝機能(function)ではありません。機能性テスト(functionality test)＝機能テスト(functional test)ではありません。ISTQBでもベースとしているISO 9126のソフトウェア品質特性(非機能要件)に従うと、機能性(functionality)は機能充足性とでもいうべき、機能をどの程度満たしているかを示すものです。機能性のサブカテゴリにセキュリティ、相互運用性、正確性などが挙げられています。機能はするがセキュリティが弱い、機能はするがつながりにくい、機能はするが精度が悪い、という状況を想定するとイメージしやすいでしょう。そうとは言え、受験者はISTQB/JSTQBの判断にしたがってください。
予防的／対処的アプローチが除外された。テストアプローチと戦略の関係が整理された。
シラバスV1.1.0では、単にテストアプローチの種類を列挙しているだけでしたが、シラバス2011では、テスト戦略(test strategy)とテストアプローチ(test approach)の関係が明確化されています。テスト計画には、テスト戦略とテストアプローチを定義することとしています。
「テストアプローチは、特定のプロジェクトでテスト戦略を実装したものである。テストアプローチは、テスト計画とテスト設計で定義され、洗練される。テストアプローチは、一般に、プロジェクトのゴールとリスクの診断にもとづいて決定される。テストアプローチを決めた後に、適用するテスト設計技法やテストの種類、開始基準や終了基準の定義を決める。」と説明されています。
テスト戦略は、組織や組織内のプロジェクトに共通する、テストアプローチを一般化したもの、テンプレート化したものと言えます。実際のプロジェクトでは、プロジェクトの特性(ゴールやリスクなど)に合ったテスト戦略を選定し、テストアプローチとして具体化します。組織で標準としている開発プロセスで選択可能なテスト戦略を挙げておき、実際のプロジェクトでプロセスをカスタマイズする際に、テスト戦略を選定し、テストアプローチとして具体化します。
シラバスV1.1.0で取り上げらていた予防的アプローチ、対処的アプローチは、シラバス2011では除外されています。これは、テスト戦略を包含させたための副作用といえます。戦略的にテストを行うことを主張したいのに、対処的アプローチを取り上げることに矛盾を感じたからではないだろうかと推測します。
レビューミーティングが「検査・評価・記録」に変更された。
公式な典型的なレビュープロセスで、従来「レビューミーティング」であったものが「検査・評価・記録（レビューミーティング）」に変更されました。これは物理的な会議体のレビューミーティングだけでなく、グループ内での電子的なコミュニケーションも包含させたためです。MailやTracなどの利用も考慮したのでしょう。またレビューミーティングの本質が、検査、評価、記録の3段階で構成されることも明示しているといえます。
物理的なミーティング以外も包含するということ以上に大きな変化ではないが、アクティビティの名称が変わるというインパクトはあります。アクティビティの順序を問うような出題はこれまでも結構ありました。
テストツールの目的と意義(ツールによるテストへの支援)が追加された。
あらたに節「ツールによるテストへの支援」を設けて語られています。記述の量は多いのですが、重要度はまだ、個人的によく分かっていません。テストフレームワークのISTQBでの定義が、一般とは異なることが5行も使って説明されています。このこだわりの意図も分かっていません。後日、勉強しておきます。
データ品質とテストやリスクとの関係が追加された。
ツールの分類に「データ品質評価ツール」が追加されました。「特定のプロジェクトにおいては、データは重要です。データ変換やデータ移行のプロジェクトもありますし、データウェアハウスのようなアプリケーションもあります。データの重要性やデータボリュームは、プロジェクトやアプリケーションに大きく依存します。このような場面では、データ品質評価ツールが必要とされます。データ変換やデータ移行の際に、処理したデータが正しく、完全で、事前に定義された条件を満たしているかどうかをレビューし、検証するために利用されます。」といったことが追記されています。
また各テストレベルでのテスト対象として、データベースモジュール、データ変換プログラムやデータ移行プログラム、データベースの実装が明示されています。また運用受け入れテストでも、データのロードとデータ移行をチェックすることが盛り込まれています。
要求される知識レベルの表現が3段階から4段階(K4の追加)に変わった。
知識レベルをきちんと意識して学習している人は少ないでしょう。さらっと流しましょう。
IEEE 829:2008標準に対するコメントが付記された。
シラバスでは、IEEE 829（Standard for Software Test Documentation）を参照しています。テストプロセスで作成すべきドキュメントのテンプレートが提示されており、試験問題でもかなりの範囲で参照されています。テスト計画書、インシデントレポート、テストサマリーレポートなどです。ところが、IEEE 829には改訂版がいくつかあり、現在のJSTQBはIEEE 829 1998/2005を参照しています。最新版はIEEE 829 2008ですので、シラバスではちょっと古いものをベースとしていることになります。
なぜ、最新版IEEE 829 2008を参照していないのかのコメントになります。「IEEE 829:2008のテスト計画標準は、それぞれのレベルテスト計画で網羅できているので、マスターテスト計画においてもテスト計画標準を網羅したことになるだろう。各テストレベルの計画は、それらを網羅するプロジェクトレベルでの計画と同様に作成できると考えている。マスターテスト計画は用語集には登録しておく。」と書かれているだけです。
よく出題されるインシデントの再現手順と再現性についての出題には、個人的にはこのあたりの整合性のまずさがあると思っています。また、テストの開始基準をどこに記述すべきかも不明確になるという弊害があると思っています。また、後日、勉強しておきます。
ざっと、こんな感じです。ここに挙げたもの以外の部分的な改訂も各所にありますが、今回は大きな変更だろうと思うものを解説してみました。
