シラバス2011をチェックしてみた。
【2011/05/17追記】この記事は「FLシラバスのレビューメモ」の方に6回分をまとめておきました。
JSTQB絡みの話ばかりで申し訳ないが、先日ダウンロードした最新のシラバス(バージョン2011)をチェックしてみた。残念なことばかりだ。品質はほとんど改善されていない。是非、早期に修正していただきたいので、気付いた点を挙げておく。致命的なものには(■)を、軽微なものや要望には(□)をマークしておく。P12 ソフトウェアの欠陥の原因
(□)「エラーが... 欠陥となる」では誤解しそうなので「エラーが... 欠陥をもたらす」とかにしてほしい。
(■)「他システムとのインタフェース」では、それがどうして誘因になるか分からない。「他システムとの相互作用の多さ」が正しい。interfacesとinteractionsを間違えている可能性がある。
P13 テストの十分性
(□)「技術や安全性、そしてビジネス上のレベルや...」は一部係り受けがおかしくなっている。正しくは「リスクのレベルの重要度によって決まる。リスクには、技術的なもの、安全性、ビジネスリスク、プロジェクト制約(期間や予算など)が含まれる。」
(■)「顧客への次回リリース」ではおかしい。「テストは、ステークホルダの意思決定のために十分な情報を提供するべきである。その情報をもとに、テストされたソフトウェアやシステムのリリースについて、次の開発ステップに進んでいいか、顧客へ引き渡していいかといった決定が行える。」ではどうだろうか。
P14 テストとは何か
(■)「テストとは何か」の「ソフトウェアの実行」は「テストの実行」の間違い。「テストとは何か」ではなく「テストするとは何か」で書き出したいが、あえて抑えて指摘すると、「テストとは何か、に対する一般的な認識は、テストを実行すること、すなわちソフトウェアの実行であることが多い。テストの実行はテスト活動の一部ではあるが、全部ではない。」となる。「テストの実施」ではなく、「テストの実行」で統一しておくといい。
(□)「テスト完了基準の検証」では不統一。「テスト終了基準の評価」で統一したのではなかったか。
(□) テストの目的に「対象ソフトウェアの品質レベルが十分であることを確認する」と以前の表現になっている。意図が不明だが、最新版に合わせて「品質レベルについて確信を得る」としておくほうが無難だ。
(□) earlyを「初期」と訳しているが「早期」の方が適切だ。「ライフサイクルの早期」や「早期テスト」に変更して統一してほしい。できるだけ早期からテストを開始することを言っている。ライフサイクルの初期というと要求フェーズとかをイメージしてまうし、「できるだけ初期に」とは言わない。
(□) 「ライフサイクルの初期にテスト設計の関わりを考えるプロセスと活動」ではなく「ライフサイクルの早期にテスト設計を含めて行うプロセスと活動」といった表現の方がいい。ただ関わりを考えるのではなく、早くからテスト設計を開始しろと言っている。
(□) 中ほどの「受け入れテストの場合、」の文はテスト目的「品質レベルについて確信を得る」に対応した表現にしなければならない。「システムが期待通りに動作することを確認し、要件に合致していることの確信を得ることが目的となる」が正しい。
P15 全数テストは不可能
(□)「入力条件の全組み合わせ」ではなく「入力と事前条件の全組み合わせ」が正しい。
(□)「リスクや優先順位によりテストの焦点を絞る」ではなく「リスク分析や優先順位付けによりテストの焦点を絞る」が正しい。
P15 初期テスト
(□)「初期テスト」は「早期テスト」の方が誤解しない。
P15 欠陥の偏在
(□) 丁寧に訳すなら「リリース前のテストで見つかる欠陥の大部分や、運用時の故障の大部分の責任は、...」となるはずだ。
P15 殺虫剤のパラドックス
(□) 訳では同じテストを繰り返すと徐々に効果が低下するニュアンスだが、原文では同じテストは繰り返しても効果がないことを言っている。「同じテストを何度も繰り返すと最終的にはそのテストでは新しい欠陥を見つけられなくなる」ではなくて「同じテストを何度繰り返しても、結局はテストケースの同じ集合であり、もはや新しい欠陥は見つけられない」だ。ニュアンスが異なる。
(□) その次の文もテストケースの改訂だけではないぞ。「テストケースは定期的にレビューし修正する必要があり、新しいテストや異なったテストが必要となる...」だ。
P15 テストは条件次第
(□)「高信頼性が必要な24時間...」はシラバス2011で「安全性クリティカルなシステムは...」に変更されたが対応できていない。
P15 バグゼロの落とし穴
(□)「欠陥を見つけて修正することは、構築したシステムが使えなかったり、ユーザのニーズや期待を満足しないということの助けにはならない。」が正しい。検証のためのテストと妥当性確認は違うぞ、といったニュアンスでないと正しくない。
P16 基本的なプロセス
(□) 用語の「インシデント」に付与される脚注は外すこと。脚注を添えるならもっと分かりやすく。「動作結果の事象」ではないほうがましだ。
(□) 「効率よく有効に」は「効果的で効率的に」の方が適切だ。
(□) 「テスト計画には、テストの計画、テストケースの設計、テストの前準備、結果の評価に費やす時間も含めるべきである」が正しい。テスト実行以外の時間も明確に含めろといっている。
P16 テスト計画作業とコントロール
(■)「使命や目的に合致するようテストの仕様を決める」とあるが、テスト計画ではテスト仕様を決めたりしない。「使命や目的に合致するように各活動の仕様を決める」が正しい。
P16 分析と設計
(□)「リスク解析レポート」は「リスク分析レポート」で統一すること。
(□)「テストベースやテストケース」は「テストベースとテストケース」が正しい。
(■)「テストアイテム、仕様、動作、ソフトウェアの構造などの」は「テストアイテム、仕様、ソフトウェアのふるまいや構造の」が正しい。ちなみにここでの「仕様」とはテスト仕様全体の中の「テスト設計仕様」のことだ。「テスト設計仕様」と限定して明記したほうが親切だとは思う。「動作」は「ふるまい」で統一すること。
P17 つづき
(■)「高度なテストケース」では誤解する。「高位レベルのテストケース」が正しい。高位レベルテストケースは用語集にも載っている。
(□)「テスト環境を設計し」は「テスト環境のセットアップを設計し」の方が正しい。後続の文章にも沿う。
P17 テスト実装と実行
(□) テスト手順を書く前に「必要なテストケースを実行順に組み合わせて」となっているが、原文では「特定の順に」となっている。この段階では、まだ実行順でなくてもいい。実行順を記述するのは、テスト実行スケジュールであり、もう少し後だ。
(□) JSTQBではログと記録が曖昧というか、すべて記録と表現されている。ISTQBでもSWEBOKでも簡易的／機械的なログと明示的な記録は別物と扱われている。もっと明確化した方がいいと思う。このことは用語集にも影響する。「テストの実行結果の記録を取り」は「テストの実行結果をログとして残し」が正しい。
P17 終了作業
(■)「システムを受け入れるために文書を作成する」とあるが、終了作業の段階では、通常、受け入れは終わっている。「システムの受け入れを文書化しておく」が正しい。打ち切りから終了作業に到った場合には関係ないが、通常は受け入れテストで受け入れ基準が満たされて終了作業に到る。受け入れが承認されたことの記録を言っている。
(□)「次回も使えるように...」の文の後半がおかしい。「後で再利用するために、テストウェア、テスト環境、テストインフラストラクチャの最終版を作成し、アーカイブしておく。」が正しい。ちなみにインフラストラクチャを「基盤構造」(P12)と訳している部分も見られる。インフラストラクチャで統一したほうがいい。用語集にもある。
P22 テストタイプ
(□) LO-2.3.4で「ソフトウェア、システムの構造」と並列になっているが、「ソフトウェアシステムの構造」が正しい。単にシステムをソフトウェアを中心に考えているだけだ。
P23 V字モデル
(□)「要求仕様」が他のところでは「要求仕様書」になっていたりする。「要求仕様」で統一のこと。このページは正しい。コードとソースコードはどちらも用語集に登録しているのでどちらでもいい。
(□)「初期のテスト設計」は「早期のテスト設計」のほうがいい。
P23 イテレーティブ・インクリメンタル
(□)「システムの要件、設計、構築」は「システムの要件の確立、設計、構築」あるいは「システムの要件定義、設計、構築」としたほうがいい。要件だけでは活動とみなせない。
(■) 後半の文章がイテレーティブとインクリメンタルで混在してしまっている。イテレーティブの単位はイテレーション(反復)であるが、インクリメンタルの単位はインクリメント(増分)である。「開発済みのソフトウェアにインクリメント(増分)を追加する場合も、システムを部分的に成長させながら形成するので、テストが必要である。... 検証と妥当性確認は各インクリメントで実施できる。」が正しい。
P23 最後の文
(■) 「ユーザテスト」が紛らわしいので、「受け入れテスト（機能テストや非機能テスト、ユーザ受け入れテストや運用受け入れテスト）」と略さずに書いてほしい。用語集ではユーザテストとユーザ受け入れテストは別物とされているので略してはいけない。
P25 テストレベル
(■)「もし、そのようなデータがシステムの一部ならば、システム構成データはテスト計画中に考慮されるべきである」では、ほとんどの方が分からないだろう。シラバス2011でテスト対象をテストレベルごとに明確化されたが、その際、「構成データ」がテスト対象であると明記された。それの但し書きのことである。「システム構成データのテストは、テスト計画で考慮すべきである」となっている。つまり、構成データと大雑把に表現しているが、実際にその中の何をテスト対象とするかは、テスト計画で明らかにしておくことを言っている。
P25 コンポーネントテスト
(□)「データ変換／移行プログラム」では誤解するので「データ変換プログラムやデータ移行プログラム」にして欲しい。
P26 統合テスト
(□)「ソフトウェア設計もしくはシステム設計」は「ソフトウェア設計とシステム設計」が正しい。
(■)「サブシステムのデータベース実装」では大間違い。「サブシステム」と「データベース実装」は別物として改行すること。
(□)「システム構成・構成データ」も明確に2つを分離するか、せめて「システム構成と構成データ」として欲しい。システム構成は、システムに1つであり、明らかにテスト対象であるが、構成データは任意である。そういった意味で本当は分離しておきたい。前述したように、構成データの何をどのレベルでテスト対象とするかはテスト計画で決めるとある。
(□)「統合テストは、...をテストする」の文章は係り受けを誤解する可能性があるので、「統合テストは、コンポーネント間のインタフェース、システムの別の部分（OS、ファイルシステム、ハードウェアなど）との相互作用、システム間のインタフェースをテストする」にしてほしい。
(■)「ビジネスプロセスは、一連のシステムの中に含まれるワークフローとして実装する」ではおかしい。「ワークフローとして実装されるビジネスプロセスは、一連のシステムを含んでよい」が正しい。ビジネスプロセスが複数システムの連携で実現されることを言っている。
(■)「システムの形態やコンポーネントがベース」は係り受けがおかしい。「システムやコンポーネントの形態」の方がまだいい。
P27 システムテスト
(□)「システム要求仕様もしくはソフトウェア要求仕様」は「システム要求仕様とソフトウェア要求仕様」が正しい。
(■)「システム、ユーザとオペレーションマニュアル」は、これは個人的な判断だが「システム」と「ユーザマニュアルやオペレーションマニュアル」と分けた方がよい。ISTQBに確認して欲しいが、おそらく改行を入れ忘れたのではないだろうか。
(□)「システム構成・構成データ」も明確に2つを分離するか、せめて「システム構成と構成データ」として欲しい。前述のとおり。
(□)「システムやソフトウェアプロダクトの振る舞いに関わりが」は、システムテストなので「システムやソフトウェアプロダクトの全体としての振る舞い...」が正しい。
(■) その次に続く2文は係り受けがぼろぼろです。別途指摘します。(※次回)
P28 受け入れテスト
(□)「統合が完了しているシステム上のビジネスプロセス」では包含関係を誤解してしまう。完全に統合されたシステムを用いて所期のビジネスプロセスが実現できたことを確認する訳なので、うまく表現できないが「完全統合されたシステムを活用したビジネスプロセス」くらいかな。
(■)「操作と保守プロセス」は、勿論「運用プロセスと保守プロセス」とすること。
(□)「書式」では分かりにくい。まだ「フォーム」のままの方がいい。個人的には「フォーム（入力帳票）」と「レポート（出力帳票）」のように表現すると日本人には親しみがあると思う。
(□)「また、ステークホルダが参加する」は「また、その他のステークホルダが参加する」が正しい。顧客やユーザー以外のステークホルダのことだ。
(□)「例えば受け入れテストの後で、大規模システム統合テストを実施する」では誤解する。「例えば、システムの受け入れテストの後で、大規模システムの統合テストを実施する」が正しい。
(□)「新規機能の拡張分は、システムテストの前に」は「新規機能の拡張分の受け入れテストは、システムテストの前に」が正しい。
P28 運用受け入れテスト
(□)「システム管理者による受け入れテスト。これには以下の種類がある。」は「システム管理者によるシステムの受け入れテスト。これには以下の作業が含まれる。」の方が親切だし誤解がない。
(□)「データ負荷と移行」では異質なものが並んだようみれる。「データロードとデータ移行」にしたい。できれば「データロード作業とデータ移行作業」とし、上段の「保守」も「保守作業」として整合させてほしい。
P28 契約による受け入れテスト
(■)「判定基準」と「受け入れ条件」は「受け入れ基準」に修正すること。受け入れ基準は、開始基準・終了基準に並ぶ重要な概念なので、ここで明確に「受け入れ基準」と表現しておく必要がある。
P28 ベータテスト
(■)「ベータテストあるいはフィールドテストは顧客もしくは潜在顧客によるテストである」だけでは足らない。「ベータテストあるいはフィールドテストは顧客もしくは潜在顧客によって、顧客の環境で実施されるテストである」とするべき。
P30 テストタイプ
(■) 用語に「テストスイート」が残っている。外されたはずだ。
(□) 「ソフトウェアの機能」は「ソフトウェアによって実行されるべき機能」の方が忠実。
(□) 「信頼性、使用性等の非機能的な特性」は「信頼性やユーザビリティなどの非機能品質特性」が正しい。
(□) 「関連する変更」ではおかしい。「変更に関すること」が正しい。
(□) 後続の文章も係り受けが若干おかしい。「欠陥が正しく修正されたことの確認（確認テスト）と故意ではない変更の発見（回帰テスト）」が正しい。
(□) 「ソフトウェアのモデルを作って」と「使うことがある」が離れすぎて誤解する。「ソフトウェアのモデルを作ったり、使ったりすることがある。構造テストでは...」のように表現したい。
P30 機能のテスト
(□) 「相互運用性（接続性）テスト」は「相互運用性テスト」でいい。なぜ相互運用性だけ言い換えようとするのだ。ユーザビリティ(使用性)などと全て言い換えるつもりか。もしくっつけたいなら、新出の箇所にしてほしい。
