FLシラバス日本語版(2011.J01)のレビューメモ

本書は、JSTQBが公開している「FLシラバス」のレビューメモです。 対象シラバスのバージョンは2011/04/07に公開したされた「2011.J01」です。

※2015/12/02時点での最新のシラバスは「2011.J02」です。 ここに指摘しているものは「2011.J01」に対するレビューですので注意ください。 最新版では既に修正されているものもあるかもしれませんし、ページ番号もずれているかもしれません。 ご了解ください。

第11回FL試験(2011/08/27)以降は、このシラバス2011.J01を対象に実施されています。 しかし、JSTQBが提供するシラバスの日本語訳は、不適切な訳語や誤訳が多く、品質が不十分です。 そこで、スクエアリングサービス事務局で独自にレビューした際のメモを提供したいと思います。 学習者や読者には、シラバスを読む際の参考資料として（ほとんど正誤表の位置づけとして）、利用いただけたらと思います。 また、JSTQBで翻訳を手がけられている方々には、参考にしていただいて、早期にシラバスの修正・改訂を行っていただけることを期待しています。

以下、各ページや項目ごとに気付いた点を順に列挙しています。 致命的なものには(■)を、やや軽微なものには(□)をマークしています。 なお、以下の指摘事項の記述は、文体が丁寧ではありませんがご了承ください。

指摘事項

P12 ソフトウェアの欠陥の原因

(□)「エラーが... 欠陥となる」では誤解しそうなので「エラーが... 欠陥をもたらす」とかにしてほしい。

(■)「他システムとのインタフェース」では、それがどうして誘因になるか分からない。「他システムとの相互作用の多さ」が正しい。 interfacesとinteractionsを間違えている可能性がある。

P13 テストの十分性

(□)「技術や安全性、そしてビジネス上のレベルや...」は一部係り受けがおかしくなっている。正しくは「リスクの重要度によって決まる。 リスクには、技術的なもの、安全性、ビジネスリスク、プロジェクト制約(期間や予算など)が含まれる。」

(■)「顧客への次回リリース」ではおかしい。「テストは、ステークホルダの意思決定のために十分な情報を提供するべきである。 その情報をもとに、テストされたソフトウェアやシステムのリリースについて、次の開発ステップに進んでいいか、顧客へ引き渡していいかといった決定が行える。」ではどうだろうか。

P14 テストとは何か

(■)「テストとは何か」の「ソフトウェアの実行」は「テストの実行」の間違い。「テストとは何か」ではなく「テストするとは何か」で書き出したいが、あえて抑えて指摘すると、「テストとは何か、に対する一般的な認識は、テストを実行すること、すなわちソフトウェアの実行であることが多い。テストの実行はテスト活動の一部ではあるが、全部ではない。」となる。「テストの実施」ではなく、「テストの実行」で統一しておくといい。

(□)「テスト完了基準の検証」では不統一。「テスト終了基準の評価」で統一したのではなかったか。

(□) テストの目的に「対象ソフトウェアの品質レベルが十分であることを確認する」と以前の表現になっている。意図が不明だが、最新版に合わせて「品質レベルについて確信を得る」としておくほうが無難だ。

(□) earlyを「初期」と訳しているが「早期」の方が適切だ。「ライフサイクルの早期」や「早期テスト」に変更して統一してほしい。できるだけ早期からテストを開始することを言っている。ライフサイクルの初期というと要求フェーズとかをイメージしてまうし、「できるだけ初期に」とは言わない。

(□) 「ライフサイクルの初期にテスト設計の関わりを考えるプロセスと活動」ではなく「ライフサイクルの早期にテスト設計を含めて行うプロセスと活動」といった表現の方がいい。ただ関わりを考えるのではなく、早くからテスト設計を開始しろと言っている。

(□) 中ほどの「受け入れテストの場合、」の文はテスト目的「品質レベルについて確信を得る」に対応した表現にしなければならない。「システムが期待通りに動作することを確認し、要件に合致していることの確信を得ることが目的となる」が正しい。

P15 全数テストは不可能

(□)「入力条件の全組み合わせ」ではなく「入力と事前条件の全組み合わせ」が正しい。

(□)「リスクや優先順位によりテストの焦点を絞る」ではなく「リスク分析や優先順位付けによりテストの焦点を絞る」が正しい。

P15 初期テスト

(□)「初期テスト」は「早期テスト」の方が誤解しない。

P15 欠陥の偏在

(□) 丁寧に訳すなら「リリース前のテストで見つかる欠陥の大部分や、運用時の故障の大部分の責任は、...」となるはずだ。

P15 殺虫剤のパラドックス

(□) 訳では同じテストを繰り返すと徐々に効果が低下するニュアンスだが、原文では同じテストは繰り返しても効果がないことを言っている。「同じテストを何度も繰り返すと最終的にはそのテストでは新しい欠陥を見つけられなくなる」ではなくて「同じテストを何度繰り返しても、結局はテストケースの同じ集合であり、もはや新しい欠陥は見つけられない」だ。ニュアンスが異なる。

(□) その次の文もテストケースの改訂だけではないぞ。「テストケースは定期的にレビューし修正する必要があり、新しいテストや異なったテストが必要となる...」だ。

P15 テストは条件次第

(□)「高信頼性が必要な24時間...」はシラバス2011で「安全性クリティカルなシステムは...」に変更されたが対応できていない。

P15 バグゼロの落とし穴

(□)「欠陥を見つけて修正することは、構築したシステムが使えなかったり、ユーザのニーズや期待を満足しないということの助けにはならない。」が正しい。検証のためのテストと妥当性確認は違うぞ、といったニュアンスでないと正しくない。

P16 基本的なプロセス

(□) 用語の「インシデント」に付与される脚注は外すこと。脚注を添えるならもっと分かりやすく。「動作結果の事象」ではないほうがましだ。

(□) 「効率よく有効に」は「効果的で効率的に」の方が適切だ。

(□) 「テスト計画には、テストの計画、テストケースの設計、テストの前準備、結果の評価に費やす時間も含めるべきである」が正しい。テスト実行以外の時間も明確に含めろといっている。

P16 テスト計画作業とコントロール

(■)「使命や目的に合致するようテストの仕様を決める」とあるが、テスト計画ではテスト仕様を決めたりしない。「使命や目的に合致するように各活動の仕様を決める」が正しい。

P16 分析と設計

(□)「リスク解析レポート」は「リスク分析レポート」で統一すること。

(□)「テストベースやテストケース」は「テストベースとテストケース」が正しい。

(■)「テストアイテム、仕様、動作、ソフトウェアの構造などの」は「テストアイテム、仕様、ソフトウェアのふるまいや構造の」が正しい。ちなみにここでの「仕様」とはテスト仕様全体の中の「テスト設計仕様」のことだ。「テスト設計仕様」と限定して明記したほうが親切だとは思う。「動作」は「ふるまい」で統一すること。

P17 つづき

(■)「高度なテストケース」では誤解する。「高位レベルのテストケース」が正しい。高位レベルテストケースは用語集にも載っている。

(□)「テスト環境を設計し」は「テスト環境のセットアップを設計し」の方が正しい。後続の文章にも沿う。

P17 テスト実装と実行

(□) JSTQBではログと記録が曖昧というか、すべて記録と表現されている。ISTQBでもSWEBOKでも簡易的／機械的なログと明示的な記録は別物と扱われている。もっと明確化した方がいいと思う。このことは用語集にも影響する。「テストの実行結果の記録を取り」は「テストの実行結果をログとして残し」が正しい。

P17 終了作業

(■)「システムを受け入れるために文書を作成する」とあるが、終了作業の段階では、通常、受け入れは終わっている。「システムの受け入れを文書化しておく」が正しい。打ち切りから終了作業に到った場合には関係ないが、通常は受け入れテストで受け入れ基準が満たされて終了作業に到る。受け入れが承認されたことの記録を言っている。

(□)「次回も使えるように...」の文の後半がおかしい。「後で再利用するために、テストウェア、テスト環境、テストインフラストラクチャの最終版を作成し、アーカイブしておく。」が正しい。ちなみにインフラストラクチャを「基盤構造」(P12)と訳している部分も見られる。インフラストラクチャで統一したほうがいい。用語集にもある。

P19-P20 テストの心理学

(※) 特に問題はない。

P21 行動規範

(□) いきなり「公人」といわれるとテスターは皆「公務員」かと思ってしまう。「公共の利益のために一貫性ある行動をする」程度でいいかと思う。

(□) 「判断」のところでintegrityを「誠実さ」といった訳にしているが、顧客や雇用主に対して言っている訳ではないので「完全性」の方がいいだろう。「完全性と独立性をもって、プロとしての判断を行うこと」でいい。

P22 テストタイプ

(□) LO-2.3.4で「ソフトウェア、システムの構造」と並列になっているが、「ソフトウェアシステムの構造」が正しい。単にシステムをソフトウェアを中心に考えているだけだ。

P23 V字モデル

(□)「要求仕様」が他のところでは「要求仕様書」になっていたりする。「要求仕様」で統一のこと。このページは正しい。コードとソースコードはどちらも用語集に登録しているのでどちらでもいい。

(□)「初期のテスト設計」は「早期のテスト設計」のほうがいい。

P23 イテレーティブ・インクリメンタル

(□)「システムの要件、設計、構築」は「システムの要件の確立、設計、構築」あるいは「システムの要件定義、設計、構築」としたほうがいい。要件だけでは活動とみなせない。

(■) 後半の文章がイテレーティブとインクリメンタルで混在してしまっている。イテレーティブの単位はイテレーション(反復)であるが、インクリメンタルの単位はインクリメント(増分)である。「開発済みのソフトウェアにインクリメント(増分)を追加する場合も、システムを部分的に成長させながら形成するので、テストが必要である。... 検証と妥当性確認は各インクリメントで実施できる。」が正しい。

P23 最後の文

(■) 「ユーザテスト」が紛らわしいので、「受け入れテスト（機能テストや非機能テスト、ユーザ受け入れテストや運用受け入れテスト）」と略さずに書いてほしい。用語集ではユーザテストとユーザ受け入れテストは別物とされているので略してはいけない。

P25 テストレベル

(■)「もし、そのようなデータがシステムの一部ならば、システム構成データはテスト計画中に考慮されるべきである」では、ほとんどの方が分からないだろう。シラバス2011でテスト対象をテストレベルごとに明確化されたが、その際、「構成データ」がテスト対象であると明記された。それの但し書きのことである。「システム構成データのテストは、テスト計画で考慮すべきである」となっている。つまり、構成データと大雑把に表現しているが、実際にその中の何をテスト対象とするかは、テスト計画で明らかにしておくことを言っている。

P25 コンポーネントテスト

(□)「データ変換／移行プログラム」では誤解するので「データ変換プログラムやデータ移行プログラム」にして欲しい。

P26 統合テスト

(□)「ソフトウェア設計もしくはシステム設計」は「ソフトウェア設計とシステム設計」が正しい。

(■)「サブシステムのデータベース実装」では大間違い。「サブシステム」と「データベース実装」は別物として改行すること。

(□)「システム構成・構成データ」も明確に2つを分離するか、せめて「システム構成と構成データ」として欲しい。システム構成は、システムに1つであり、明らかにテスト対象であるが、構成データは任意である。そういった意味で本当は分離しておきたい。前述したように、構成データの何をどのレベルでテスト対象とするかはテスト計画で決めるとある。

(□)「統合テストは、...をテストする」の文章は係り受けを誤解する可能性があるので、「統合テストは、コンポーネント間のインタフェース、システムの別の部分（OS、ファイルシステム、ハードウェアなど）との相互作用、システム間のインタフェースをテストする」にしてほしい。

(■)「ビジネスプロセスは、一連のシステムの中に含まれるワークフローとして実装する」ではおかしい。「ワークフローとして実装されるビジネスプロセスは、一連のシステムを含んでよい」が正しい。ビジネスプロセスが複数システムの連携で実現されることを言っている。

(■)「システムの形態やコンポーネントがベース」は係り受けがおかしい。「システムやコンポーネントの形態」の方がまだいい。

(□) P26の最後の文「これは機能的および構造的アプローチが使える」だが、ちょっと誤解しそうだ。訳はたしかに正しいのだが、テストアプローチのことかと誤解しそうなので「統合の各段階では、機能テストと構造テストの両方が適用できる。」くらいの表現に変えておく方が親切だろう。

P27 先頭行

(■)「統合計画の構造や影響」も係り受けがおかしい。「アーキテクチャや統合計画の影響」が正しい。

P27 システムテスト

(□)「システム要求仕様もしくはソフトウェア要求仕様」は「システム要求仕様とソフトウェア要求仕様」が正しい。

(■)「システム、ユーザとオペレーションマニュアル」は、これは個人的な判断だが「システム」と「ユーザマニュアルやオペレーションマニュアル」と分けた方がよい。ISTQBに確認して欲しいが、おそらく改行を入れ忘れたのではないだろうか。

(□)「システム構成・構成データ」も明確に2つを分離するか、せめて「システム構成と構成データ」として欲しい。前述のとおり。

(□)「システムやソフトウェアプロダクトの振る舞いに関わりが」は、システムテストなので「システムやソフトウェアプロダクトの全体としての振る舞い...」が正しい。

(■) その次に続く2文は係り受けがぼろぼろだ。「システムテストの対象となる機能要件を」以降の文は、機能テストの後に構造テストをせよというニュアンスが失われてしまっている。正しくは「対象システムの概観をテストするために、機能要件のシステムテストを最適な仕様ベース（ブラックボックス）技法を用いて開始する。例えば、...。それから構造べース（ホワイトボックス）技法を用いて、構造要素に対してテストの徹底度を査定する。例えば、...。」となる。この流れを失ってはいけない。

P28 受け入れテスト

(□)「統合が完了しているシステム上のビジネスプロセス」では包含関係を誤解してしまう。完全に統合されたシステムを用いて所期のビジネスプロセスが実現できたことを確認する訳なので、うまく表現できないが「完全統合されたシステムを活用したビジネスプロセス」くらいかな。

(■)「操作と保守プロセス」は、勿論「運用プロセスと保守プロセス」とすること。

(□)「書式」では分かりにくい。まだ「フォーム」のままの方がいい。個人的には「フォーム（入力帳票）」と「レポート（出力帳票）」のように表現すると日本人には親しみがあると思う。

(□)「また、ステークホルダが参加する」は「また、その他のステークホルダが参加する」が正しい。顧客やユーザー以外のステークホルダのことだ。

(□)「例えば受け入れテストの後で、大規模システム統合テストを実施する」では誤解する。「例えば、システムの受け入れテストの後で、大規模システムの統合テストを実施する」が正しい。

(□)「新規機能の拡張分は、システムテストの前に」は「新規機能の拡張分の受け入れテストは、システムテストの前に」が正しい。

P28 運用受け入れテスト

(□)「システム管理者による受け入れテスト。これには以下の種類がある。」は「システム管理者によるシステムの受け入れテスト。これには以下の作業が含まれる。」の方が親切だし誤解がない。

(□)「データ負荷と移行」では異質なものが並んだようみれる。「データロードとデータ移行」にしたい。できれば「データロード作業とデータ移行作業」とし、上段の「保守」も「保守作業」として整合させてほしい。

P28 契約による受け入れテスト

(■)「判定基準」と「受け入れ条件」は「受け入れ基準」に修正すること。受け入れ基準は、開始基準・終了基準に並ぶ重要な概念なので、ここで明確に「受け入れ基準」と表現しておく必要がある。

P28 ベータテスト

(■)「ベータテストあるいはフィールドテストは顧客もしくは潜在顧客によるテストである」だけでは足らない。「ベータテストあるいはフィールドテストは顧客もしくは潜在顧客によって、顧客の環境で実施されるテストである」とするべき。

P30 テストタイプ

(■) 用語に「テストスイート」が残っている。外されたはずだ。

(□) 「ソフトウェアの機能」は「ソフトウェアによって実行されるべき機能」の方が忠実。

(□) 「信頼性、使用性等の非機能的な特性」は「信頼性やユーザビリティなどの非機能品質特性」が正しい。

(□) 「関連する変更」ではおかしい。「変更に関すること」が正しい。

(□) 後続の文章も係り受けが若干おかしい。「欠陥が正しく修正されたことの確認（確認テスト）と故意ではない変更の発見（回帰テスト）」が正しい。

(□) 「ソフトウェアのモデルを作って」と「使うことがある」が離れすぎて誤解する。「ソフトウェアのモデルを作ったり、使ったりすることがある。構造テストでは...」のように表現したい。

P30 機能のテスト

(□) 「相互運用性（接続性）テスト」は「相互運用性テスト」でいい。なぜ相互運用性だけ言い換えようとするのだ。ユーザビリティ(使用性)などと全て言い換えるつもりか。もしくっつけたいなら、新出の箇所にしてほしい。

(□) P30の中ほどの「機能やフィーチャ（ドキュメント中に記述してあること、あるいはテスト担当者が理解していること）」だが、誤解しそうだ。訳はたしかに正しいのだが、括弧書きがフィーチャの定義のように見えてしまう。括弧を外したほうがいいだろう。「機能テストは、機能やフィーチャ、またそれらの特定システムとの相互運用性にもとづいたものである。ドキュメント中に明示されていることだけでなく、テスト担当者が理解していることも含めてテストする必要がある。また機能テストは、全ての...」といった感じではどうだろう。

P30 非機能のテスト

(■) 「相互運用性テスト」が残っているぞ。V1.1.0のシラバスのままだ。シラバス2010から相互運用性テストは非機能から機能に変更されたことを忘れたか。こんなミスがあるとは信じがたい。レビューしてください。お願いしますから。

P31 ソフトウェアの構造

(□) thoroughnessは「完全性」ではなく「徹底度」で統一すること。

P31 変更部分のテスト

(□) 「デバッグ（欠陥の修正）」は「デバッグ（欠陥を特定して修正すること）」が正しい。

(□) 「回帰テストの範囲は、正常に動いていたソフトウェアから欠陥が見つからないリスクを基に決める」では微妙におかしい。正しくは「回帰テストの範囲は、以前に動作していたソフトウェアで見つかっていない欠陥のリスクをもとに決める」だ。

P32 保守テスト

(■) 「システムの入れ替えに関する」は「システムの回収のための」が正しい。retirementを回収作業と訳しているようなので「回収」で通すこと。個人的には退役とか撤収とかの方がいいかと思うが定義だけのことなので回収でいい。入れ替えってどこから出てきたのだ。すぐ上段では、変更、移行、回収があるといっておきながらなぜこんなところで間違えるのだ。

(■) 「保守テストの実施範囲は、変更のリスク、現実のテストの規模、変更の大きさに依存する」では大間違いだ。過去にもこの1文に関する出題もされたことがある。誤訳にもとづく出題だった。正しくは「保守テストの実施範囲は、変更のリスク、既存システムの規模、変更の規模に関係する」だ。規模＝sizeだが、片方は規模で片方は大きさと訳されていた。しかも既存システムの規模を現実のテストの規模としていた。現実のテストの規模って何だ。テストの範囲と決めるのにテストの規模が出てきてどうする。

番外

(□) 全体的なことだが、JSTQBでは「欠陥を摘出する」と表現されるが、テストを主体とする場合「検出する」の方が適切だと思う。個人的には「検出する」しか使っていない。「摘出する」にはどうしても手術のイメージがあって「取り出して除去する」つまり「欠陥を見つけて除去する」ところまでイメージしてしまうからだ。できれば「検出する」で統一してほしい。

P35 静的技法とテストプロセス

(□) 「レビューでは、機能と処理（例えば要件）の抜けを見つける」ではおかしい。「レビューは、抜け（例えば要件での抜け）を見つけることができる。」でいい。機能、特に処理はどこから出てきたのだ。

(■) 最後の文。過去にも何度も指摘しているがなかなか修正してもらえない。再度言います。「規格からの逸脱」ではなく「標準からの逸脱」だ。standard=標準は用語集にも登録されているので変えてはいけない。また「保守の不十分性」ではなくて「不十分な保守性」だ。maintainability=保守性だ。他の余地はない。

P36 レビュープロセス

(□) 「レビュータイプには...非公式なもの...から、公式なもの...に至る。レビュープロセスの形式は、...」の繋がりがおかしい。正しくは「レビュータイプには...非公式なもの...から、体系的なもの...に至る。レビュープロセスの公式性は、...」となる。「公式性」の表現は欲しい。

P36 公式レビューの活動

(■) タイトルは「検査・評価・記録（レビューミーティング）」と短くすべきだろう。examinationは「実施」と訳すより「検査」とした方がいい。タイトルでは「する」や「結果」は削除する。長いと、後々困ると思う。

(■) これも過去に指摘したがまだ修正してもらっていない。「議論を行い、結果や議事内容を文書として記録する（より公式なレビュータイプの場合）」ではなく、「議論をし、ログを残す。より公式なレビュータイプの場合は、結果を文書化したものや議事録を伴う。」だ。非公式でも議論はするし、ログは残す。公式な場合には、議事録などにちゃんと記録することを言っている。「logging, with」で係り受けをカンマで制御されていることに注意してほしい。また一般的に考えてもそうだ。前回も書いたが、ログと記録は区別する必要がある。ログは簡易的／機械的で、記録は明示的で公式性が高い。

(■) 次の文。「欠陥を書き出し、欠陥の扱いについて意見を出し、欠陥についての判断を下す」が正しい。

(■) 次の文。「物理的なミーティングの最中に、実施、評価...」ではおかしい。物理的なミーティングと物理的でない電子的なコミュニケーションを包含して語っている。「物理的なミーティングにおいて、検査し、評価し、課題を記録する。またグループでの電子的なコミュニケーションを追跡する。」ではどうだろうか。

(□) フォローアップのところの文。「欠陥を処理したかチェックする」ではちょっとニュアンスが違う。addressなので、大して違わないが「欠陥が対処されたかをチェックする」だ。

P37 役割と責任

(□) マネージャーは「実施のスケジュールを立て、レビューの目的が適切かどうかを判断する」ではなく「レビューの実施を決め、プロジェクトスケジュールに時間を確保し、レビューの目的が合意されたかを判断する」が正しい。これも過去に指摘したがまだ修正してもらっていない。スケジュールを立てて、時間も割り当ててから、目的が適切かどうかを判断しては遅すぎる。作成者やモデレータなどと目的を最終的に合意し、キックオフに臨む流れがある。

(□) モデレータの説明。「レビューを取りまとめる人。取りまとめには...が含まれる。」は表現がおかしい。「レビューを主導する人。...を含めて行う。」ではどうだろう。

(■) レビューアの後半の説明。これも過去に指摘したがまだ修正してもらっていない。「あらゆるレビューに参加する」訳ではないし、係り受けも間違っている。「レビューアは、レビュープロセスで異なった視点と役割を代表する人として選出される。レビューミーティングではその与えられた視点と役割を果たすべきである。」といった方が適切だ。

P37 非公式レビュー

(□) 「技術指導的にレビューする形式」ではなく「レビューしながら技術指導する形態」の方がいい。

P37 ウォークスルー

(■) 「レビューアの事前準備ミーティングを行うことがある」では間違い。「レビューアは事前ミーティング準備を行うことがある」が正しい。pre-meeting preparationは以降3箇所くらいに出てくるが、訳がバラバラだ。「事前ミーティング準備」で統一しておきたい。事前に対象ドキュメントをレビューしておくことだ。

(■) 「(作成者以外が)記載者になることもある。」ではおかしい。記録をとること自体がオプションだし、用語も書記か記録係で統一すること。「書記はオプションである。(その場合でも作成者以外が書記となること）」が正しいニュアンスだ。

P38 テクニカルレビュー

(■) 「レビューアが事前ミーティングを準備する」ではなく、前述のように「レビューアは事前ミーティング準備を行う」が正しい。事前に対象ドキュメントをレビューしておくことだ。

(□) 「チェックリストを作ることがある」ではなく「チェックリストを使うことがある」が正しい。作ってもいいが、既存のものを使うことも多い。

P38 レビューの種類

(■) 「...成果物を何度もレビューすることがある。複数回のレビューを実施する場合、レビューの種類によって実施する順番がことなる」では微妙にニュアンスが違う。「...成果物をレビューする主題は複数ある。複数のレビューの種類を適用する場合、順序は様々である。」が正しい。単に回数ではなく、複数種類のレビューを組み合わせる場合のことを言っている。

P38 ウォークスルー

(□) 「運営により」では硬い。in practiceなので「実際の適用では」くらいではどうか。テクニカルレビューでも出てくる。

P38 テクニカルレビュー

(□) 「指摘一覧、...」の文が微妙におかしい。「レビューレポートを準備する。指摘事項の一覧、ソフトウェアプロダクトが要求に合致しているかどうかの判定を含めること。また適切に、指摘に関しての対処を含めること。」ではどうだろう。

P38 インスペクション

(□) 「各人の役割が決まっている」ではニュアンスが違う。「役割を定義する」としたい。なお、ここでのrolesはチェックリストと並ぶ技法の1つとして捉えられている。「配役／役割決め」といったニュアンスが必要だ。

(■) 「規則やチェックリストを使い、形式に基づいたプロセスで進める」は間違い。rolesとrulesを間違えたか。「役割決めとチェックリストに基づいた公式なプロセスである」が正しい。ISTQBではインスペクションは公式なレビューとされている。ここではrolesを技法として扱っているので、単に役割とするのではなく「役割決め」としたらどうかと思う。※この部分、最新のISTQBシラバスではrulesになっている。しかし、筆者はrolesの間違いだと思う。

(■) 「インスペクション前の準備が必要である」という表現はプロセスが分かっていない。インスペクションというプロセスの中に事前ミーティング準備というアクティビティがある。「事前ミーティング準備を行う」が正しい。

(■) 「インスペクションのレポートや指摘一覧を書く」という表現では成果物の包含関係がおかしい。「インスペクションレポートを作成する。指摘一覧を含めること」が正しい。

(□) 「形式の決まったフォローアッププロセスがある」は誤解をさけて、「公式なフォローアッププロセスである」とすること。たしかに「形式的」と訳してもいいのだが、レビューの公式性は様々であると冒頭に述べているので、各レビュー形態では、公式性について個々に語る方がいい。

P38 レビューを成功させるために

(□) レビューを成功させるためにとして列挙された項目は結構意訳されていて、微妙なものが多い。「...すること」で統一すると分かりやすいと思う。

(□) 「レビュー開始前に目的を明確にする」も微妙におかしい。「レビュー目的を明確に事前定義しておくこと」が正しい。「レビュー開始前」と表現しないほうがいい。

(■) 「欠陥を見つけることは目的に合致しており、歓迎すべきことである」ではなく「発見された欠陥は、歓迎し、客観的に表現すること。」が正しい。

(■) 「目的を達成するために」の項目は係り受けがおかしい。「目的の達成に適った、またソフトウェア作業成果物やレビューアのタイプやレベルに適ったレビュー技法を適用すること」が正しい。

(□) 「欠陥を効率よく見つけられるのであれば」の文では、ここも「役割決め」にしておきたい。

(■) トレーニングは全てに必要で、特にインスペクションで大切というニュアンスなので「レビュー技法をトレーニングして習得すること。特にインスペクションのように公式性の高い場合では重要。」ではどうだろう。

(□) 「管理者」としない方がいい。「良好なレビュープロセスを支援できるように管理すること。(プロジェクトスケジュールにレビュー活動の予定時間を組み込むなど)」ではどうだろう。

(□) 「学習とプロセス改善は目的」と言い切らない方がいい。「成功には、学習とプロセス改善が重要である」ではどうだろう。この文だけ前述のものらよりトーンが異なる。

P39 ツールによる静的解析

(■) 「リンクのようにソフトウェアモデル間の依存性、非依存性を見つける」では「非依存性」を「不整合」に差し替えた方がいい。

(□) 「開発中に学習することで欠陥を予防する」ではニュアンスを誤解しそう。「開発中に学んだ教訓は、欠陥の予防に役立つ」くらいではどうだろう。

P42 テスト開発プロセス

(□) formal,informal,formalityはここでは「形式的」などと訳さずに「公式」「非公式」「公式性」と訳すべきだ。組織やプロジェクトできっちり定義したプロセスに沿っているか、そうでないかの差だ。レビュープロセスのときの公式性と同等のトーンでいい。

(■) 「公式性のレベルは、テスト実施の条件に依存する。例えば、テストプロセスや開発プロセスの成熟度、時間制約、安全性や規制の要件、参加する人員などに依存する。」ではどうだろう。時間的余裕ではなく時間制約だ。

(□) 「テスト条件は、...項目やイベントとして定義する」ではなく「テスト条件とは、....項目やイベントである」とした方が明確だ。

(□) 「構造的要素」は構成要素あるいは構造要素でいいでしょう。

(■) 「トレーサビリティを確立できると」の文が分かりにくいというか間違っている。「トレーサビリティを確立できると、要件変更のときに影響度分析が効果的に行えるし、要件を網羅できるテスト集合を決定することもできる」だ。

(□) 「テスト分析では...リスクに大きく影響を受ける」の文がおかしい。「テスト分析では、テスト設計技法を選択してテストアプローチを詳細化する。テスト設計技法の選定は、いろいろな観点の中でも特に、識別されたリスクにもとづいた利用を考慮して行う。」ではどうだろう。テストアプローチ、テスト設計技法の選定は単語として明確に表現したい。

(□) この節はプロセスの説明なので、「テスト分析では...」「テスト設計では...」「テスト実行では...」というように統一的に書き出すと分かりやすくなると思う。

(■) テストケースの定義も係り受けが微妙におかしい。「テストケースは、特定のテスト目的やテスト条件を網羅するために定義された、....を集合として構成される。」が正しい。ただ、1つの特定の目的や条件に対応して1つのテストケースが存在することを強調した文になっているので「テストケースは、...で構成される。テストケースは、特定のテスト目的やテスト条件(1つの場合も複数の場合もある)を満たすように定義する」と訳してやると丁寧だ。網羅と表現してもいいが、どうも誤解しやすい。「テスト条件をいくつかのテストケースで網羅する」と表現し、「テストケースはテスト条件の一部または全てを満たす」と表現して区別してやる方が分かりやすいと思う。

(■)テストケースとテスト手順仕様の関係が間違っている。係り受けを間違って訳している。テスト手順仕様のためにテストケースを開発するわけではない。「テスト実装では、テストケースを開発し、実装し、優先順位付けし、テスト手順仕様に組み入れる」ではどうか。

P43 テスト設計技法のカテゴリ

(■) 中ほどの「テスト技法の中には」の訳が間違っている。「テスト技法は1つのカテゴリに収まるものもあれば、複数の要素を備えたものもある」が正しい。BlackとWhiteのどちらかという話ではない。

(□) 「解決すべき問題、ソフトウェアやコンポーネントの仕様として、公式、非公式に関わらずモデルを使用する」としたい。仕様ベースの話なので「定義」とかでなく、きちんと「仕様」と表現すること。formal,informalは「公式、非公式」としたい。

(□) 「詳細化された設計」でもいいが、普通は「詳細設計」という。

(□) peopleを「担当者」と訳すとテスト担当者と勘違いする。単に「人」としておきたい。「人の知識や経験をベースに...」となる。

P44 同値分割法

(□) 「同値分割したグループ」は「同値領域」と換言したほうがいい。

(■) 「同値領域(同値クラス)は、有効データ（受け入れられるべき値）だけでなく、無効データ（拒否される値）にもある。同値領域は入力だけでなく、出力、内部の値、時間依存の値（例えば、イベントの前後で）、インタフェースパラメータ（例えば、統合テストでテストするコンポーネントで）からも識別できる。」ではどうか。「(たとえば、統合テストでの...)」の括弧書きは「インタフェースパラメータ」を修飾しないとおかしい。

P44 境界値分析

(■) 「テストケースを設計するときは、両領域から値を選ぶ」では間違い。「テストケースの設計では、各境界値のテストを選ぶ」が正しい。両領域ではなく各境界値だ。

(□) 最後の文がちょっと誤解しそう。「同値クラスは、人による画面入力で利用されるだけではない。例えば、時間範囲(...)やテーブル範囲(...)にも利用できる」としたい。

P44 デシジョンテーブルテスト

(□) ほぼ的確に訳せている。ただ、カラム(列)を表現するものは条件とactionsであるが、actionsを動作と訳したり行動と訳したりして不統一に見える。この文面に限ればすべて「動作」に統一した方がいいだろう。

P45 状態遷移テスト

(□) 「システムの状態により」は余計かな。「システムは、現在の条件と以前の履歴(状態)によりいろいろな動作を示すことがある。このような状況でシステムの様相を表現できるのが、状態遷移図である。」....「状態は有限個であり、それぞれ個々に識別できる。」ではどうか。

(■) 状態とはオブジェクトの状態であり、プロセスの状態ではない。また「(例えば、インターネット...)」の括弧書きは画面フローを修飾しているのではなく、直前の文全体を修飾している。だから「この技法は、いくつかの状態を持つビジネスオブジェクトをモデリングしたり、画面遷移フローをテストしたりするのにも適している。例えば、インターネットアプリケーションやビジネスシナリオのテストで用いられる。」が正しい。「画面による対話処理フロー」は「画面遷移フロー」としていいと思う。

P45 ユースケーステスト

(■) アクター間の相互作用と言っているようだ。アクターとシステム間に限定しないのは、ビジネスユースを考慮していると思われる。「テストはユースケースから導出できる。ユースケースはアクター(ユーザーやシステム)間の相互作用を記述するものであり、システムユーザーや顧客にとっての価値を表現するものである。」ではどうだろう。

(□) 「テクノロジーフリー」とはどういった意味なのか。「ITシステムを利用しないビジネス(?)」か。適切な訳があれば別だが、この文脈では割愛してしまっていいのではないかと思う。

(■) 「事後条件になると終わる」の説明ではおかしい。条件を満たすから終わるのではなく、終わった時に満たしているべき条件(状態)だ。「各ユースケースは事後条件で終わる。事後条件は、観察可能な結果であり、ユースケースが完了した後のシステムの最終状態である。」が正しい。

(□) 次の文も「ユースケースは、実際の好ましい利用を想定してシステムを介したプロセスフローを記述している。」としたい。次の文でas-is(実世界)に対してto-be(描いたユースケース)を対照することを言っている。そのギャップが欠陥として検出しやすいという論理のようだ。

P46 構造ベース／ホワイトボックスのテスト技法

(□) 「特定の構造」は単に「構造」でいい。specifiedが削除されたのかも。

(□) 「ステートメント、判定、分岐、その他のパス」では「パス」を誤解しそう。「ステートメント、デシジョン(判定)、ブランチ(分岐)、あるいはパス」としたい。「even distinct path」は「前述のものらとは異なった概念であるパス」と言っているようだ。ステートメント、判定、分岐は構成要素だが、パスは構成要素ではないからだ。

(□) 「取りうるデシジョンを視覚化」はちょっと違う。「各デシジョンの選択肢を視覚化」の方がいい。alternativesは、条件によって分岐したtrue,falseなどのステートメントを指して用いられる。

(□) この節では「デシジョン(判定)」また「ブランチ(分岐)」のように統一して用いてほしい。デシジョンテスト、ブランチカバレッジなどのようにカタカナ表記で用語を定義した以上、それで通して一貫性を出してほしい。用語集との整合性・一貫性も当然、必要。

P46 ステートメントテストとカバレッジ

(□) 「網羅したステートメント数を全ての実行可能なステートメント数で割った数」では誤解する。「網羅した実行可能なステートメント数を全ての実行可能なステートメント数で割った値」と正確に記述しておきたい。最後は数でなく「値」にすること。

P46 デシジョンテストとカバレッジ

(■) 「ブランチテスト（ブランチカバレッジ）と呼ばれるデシジョンカバレッジは、」という記述では、ブランチテスト＝ブランチカバレッジ＝デシジョンカバレッジと捉えられてしまう。このように理解させることは適切ではない。カバレッジという概念があり、そのカバレッジに着目して行うテストがある、というニュアンスでないといけない。「ブランチテストに関係するデシジョンカバレッジは...を評価するものである」でとどめていい。

ブランチとデシジョンは厳密には異なる、ブランチカバレッジとデシジョンカバレッジは厳密には異なるニュアンスを残しておく必要がある。

(□) ブランチとデシジョンの差異を説明しているのが次の1文だ。「ブランチはもともとコードの中のデシジョンポイントからきており、コードの中の別の場所に制御を移すことを示す」は一見正しそうに見えるのだが、originate fromを「もともと...からきており」と由来のように訳すのが正しいのか、それが事実なのか、残念ながら私にも判断できない。

ただ、「ブランチは、コード中のデシジョンポイント(判定の瞬間)から生じる。また、制御がコード中の異なった場所へ移ることを示す」とする方が適当かもしれないと思う。そもそも、デシジョン(判定)、ブランチ(分岐)の定義がはっきりしない。コードベースで語るならば、デシジョン(判定)は、if,case,switch,while,untilなど条件判定を伴うステートメントのまさにデシジョンポイント(判定の瞬間)であるから、これは分かりやすい。

一方、ブランチ(分岐)は、ISTQBの定義では「実行が選択される基本ブロックであり、2つ以上のプログラムパスの選択肢があり、そのうち1つが有効であるようなプログラム構造にもとづく。例えば、case、jump、go to、if-then-elseなどである。」とある。判定を伴わない無条件のjumpやgo toも含めているところが気になるし、前半の定義と矛盾するようにも見える。ブランチとは、コード上のシーケンシャルな流れ(命令の順次実行)から他の場所へのジャンプを表現するもの、単に脇道に反れるだけのもの、call,goto,break,continue,jumpといった無条件ジャンプも含んでいると言っているのかもしれない。条件ジャンプのことが「コード中のデシジョンポイント(判定の瞬間)から生じる」と表現され、また無条件ジャンプを含めて「制御がコード中の異なった場所へ移ることを示す」と表現されているとも言える。

どちらにせよ、コードのステートメントをカバレッジの観点で捉えた場合、両者に差異はないため、ISTQB/JSTQBでは同義として扱って良い。といったニュアンスが欲しい。

(■) 「網羅した判定数を全ての実行可能な判定数で割った数」は間違い。ステートメントテストからコピぺして修正し間違えたな。また判定数と表現すると、何かの回数かと思う。デシジョンで統一したい。だから「網羅したデシジョンの数を全てのデシジョンの数で割った値」としたい。最後は数でなく「値」にすること。

(■)「デシジョンテストは、デシジョンポイントを通り、特定の制御フローに続くため、制御フローの一形式である」ではおかしい。followを「続くため」と訳すからおかしな文になる。「デシジョンテストは、制御フローの一形式であり、デシジョンポイントを通過する特定の制御フローに着目して行う」ではどうか。

P47-P51

(※) この部分は適切に訳せている。

P52 テスト組織と独立性

(□) 「効率が上がる」は「効果的である」または「有効性が上がる」にしたい。一般に、効果は上がる(品質は上がる)が、効率が上がる(少ない工数や予算で同程度の品質が得られる)かどうかははっきりしないはずだ。また、数行ほど下ではeffectivenessは有効性と訳しているので、それと整合させた方がいいだろう。

(□) 「一般に、複雑な」は「一般に、大規模で複雑な」としておきたい。

(□) 「先入観がないため、異なる欠陥が見つけられる」というのは言い過ぎだ。「他のいろいろな欠陥を知っており、先入観がない」と言っている。

(■) 「システムの仕様策定中や実装中に想定通りかを検証できる」ではちょっとニュアンスがおかしい。「システムの仕様策定や実装の間であっても、前提条件を検証できる」かな。テストそのもの(テスト対象の検証)ではなく、テストのreadinessとしての前提条件の検証が開発と並行して行えることの利点を言っている。

(□) 「ビジネスやドメインのエキスパート、インフラストラクチャやITの運用担当者」と表現したほうが適切だ。

P52 テストリーダと担当者の作業

(□) roleを「職務」と訳しているが、他との整合性から「役割」で統一すること。

P53

(■) 「他の人が実施したテストをレビューする」ではおかしい。やはり「他の人が開発したテストをレビューする」が正しい。「実施した」だと実行後となるが、普通は実行前にレビューする。

P54 テスト計画作業

(■) マスターテスト計画とレベルテスト計画の両方がmustといったニュアンスで訳されているが、それでは基本的なテストプロセスでの記述と整合しない。「そして」が余計だ。「マスターテスト計画で文書化することもあるし、テストレベルに応じて個別のテスト計画として文書化することもある」といったニュアンスでないとおかしい。

(□) 「連続的な活動」より「継続的な活動」の方が一般的だ。

P54 テスト計画策定

(■) 「何をテストするか、...」の項目が訳がおかしい。というか古いシラバスのままか。終了条件はもっと上段で定義済みだ。「何をテストするか、どんな役割でテスト活動を実施するか、どのようにテスト活動をすべきか、どのようにテスト結果を評価するかについて意思決定する。」が正しい。

(■) 次の項目。「分析と計画」ではなく「分析と設計」だ。

P54 開始基準

(■) ここはavailabilityを「可用性」と訳すと誤解しそうだ。readinessと対等なので、availabilityは入手可能といった意味で捉えた方がいい。まだ手元になくてもよくて、いつでも入手できる状況になっていることを言っている。readinessはいつでも使える状態になっていること。availabilityは「xxxが入手可能であること」、readinessは「...が準備できていること」と表現したい。

P55 テスト終了基準

(□) 「テスト終了基準は...テストの終了を定義することである」では不自然だ。もっと素直に「終了基準は、テストレベルの終わりや、テスト集合が特定のゴールを達成したときなどのように、いつテストを終了させるかを定義する。」ではどうだろう。

P55 テスト見積り

(□) 「問題のドメインの複雑性」ではぎこちない。problem domainは「問題領域」か、せめて「問題ドメイン」と言い切りたい。

P55 テスト戦略、テストアプローチ

(■) 「テストアプローチはテスト戦略を実装することである」では誤解を招く。「テストアプローチはテスト戦略の実装である」あるいは「テストアプローチはテスト戦略を実装したものである」が正しい。classとinstanceの関係だと思えばいい。

(■) 「テスト設計技法の選択とテストタイプの適用」では係り受けがおかしい。「適用すべきテスト設計技法とテストタイプの選定」が正しい。

(□) 「選択されたアプローチは、...の考慮によって決まる」では文章がおかしい。「選択された」と「決まる」が整合しない。「アプローチの選択は、プロジェクトの状況に依存する。選択では...を考慮する必要がある」だと丁寧かな。

(■) 方法論的アプローチの説明が古いシラバスのままのようだ。「故障ベース(...)、経験ベース、チェックリストベース、品質特性ベースなど」が正しい。

P56

(■) 「回帰的アプローチ」の原文は「regression-averse approaches」だ。「回帰的アプローチ」だと回帰テストを推奨するアプローチのように読み取れるが、内容は逆で、できるだけ回帰テストの労力を抑制するためのアプローチとなっている。regression-averseは「回帰をいやがる」という意味だ。回帰テストをするなとまではいっていないが、テストの再利用や高度な自動化や標準の適用で回帰テストの効率を上げることを推進するアプローチになっている。「効率的回帰アプローチ」とか「回帰最小化アプローチ」ではどうだろうか。脚注で補足するという案でもいい。

(□) 間違いではないのだが「例えば、リスクをベースにした動的アプローチのように、違うアプローチを組み合わせることもできる」といった文が唐突に現れてくるから、シラバスが読みにくくなる。もうすこし、原文の順序を大切にした方がいい。「異なったアプローチを組み合わせることもできる。例えば、リスクベースで動的なアプローチなどがある。」とすれば、唐突感がなくなり、前の文章からのつながりもよくなると思う。これはシラバス各所で言えることだ。

P57 テスト進捗モニタリング

(□) 言い切らない方がいい。「...例えばカバレッジのように終了基準の尺度として用いるものもある。メトリクスは、...比較に用いられることもある。」でいい。

(□) 「テストケース準備で完了した作業のパーセンテージ（あるいは計画に対する準備されたテストケースのパーセンテージ）」の方がいい。

(□) 「テスト環境準備で完了した作業のパーセンテージ」の方がいい。

(□) 「プロダクトの品質に対するテスト担当者の主観的な信頼度」では分かりづらい。「テスト担当者が判断するプロダクト品質についての確信」ではどうか。これはテスト目的と呼応している。テストの目的に「confidenceを得る」とある。confidenceを確信とするか、信用とするか、信頼度とするかは統一してあればいい。テストの目的での訳に整合させるといい。個人的には信頼を避けたい。信頼性(reliability)と紛らわしいからだ。「確信を得る」と表現したほうがいいかなと思う。

(□) 「テストに対するコスト。例えば、次の欠陥を摘出することや次のテストによる利益とコストの比較」も良く分からない。「テストのコスト。次の欠陥を検出することの利益と比較したコストや、次のテストを実行するためのコストを含む。」だと思う。

P57 テストレポート

(□) 「発生する可能性の高いリスク」ではなく、その時点で発生している「著しいリスク」を言っている。発生確率ではなく重大性を言っている。

(□) 「テスト完了ソフトウェアの信頼度のレベル」もconfidenceが使われており、テストの目的の「confidenceを得る」にあわせた表現で統一すること。信頼度で通すならそれでもいい。

P57 テストコントロール

(■) モニタリングするのは「情報」と「メトリクス」と言っているので、それに呼応した表現で語る必要がある。またcorrective actionは補正作業よりも「是正処置」と訳すのが一般的だ。CMMI,SWEBOK,PMBOKあたりもそうしてたはずだ。ちなみにpreventive actionは「予防処置」とする。なので、「テストコントロールは、収集され報告された情報やメトリックの結果をベースに次に進む方向を決めたり、是正処置を行うことである。これらの処置は...」ではどうだろう。

P58 構成管理

(□) 「全てのドキュメントやアイテムを識別し、テストドキュメントに明確に記載してある」ではおかしい。識別することは直前の項目で行っている。だから「識別された全てのドキュメントとソフトウェアアイテムは、テストドキュメントの中で明確に参照される。」かな。

P59 リスクとテスト

(■) 冒頭の文で、chanceやlikelihoodなどが適切に訳せていない感じだ。係り受けも若干疑わしい。「リスクは、イベント、危険、脅威、発生する状況の可能性と、望ましくない結果や潜在的な問題の影響として定義される。リスクのレベルは、不利なイベントの発生確率とインパクト(イベントから影響を受ける損害)で決まる。」が正しいニュアンスだ。イベントの発生確率とイベント結果のインパクト(＝影響度)は2つをセットにしてリスクは定義できることを忘れてはいけない。

P59 プロジェクトリスク

(□) 「プロジェクトリスクはプロジェクトを遂行する際に影響を与えるリスクである」では、何に影響を与えるかが不明確だ。「プロジェクトリスクは、プロジェクトの目的を遂行する能力に関連するリスクである」と忠実に表現しておきたい。

(■) 「テストから期待できるものを正しく評価しようとしない。(例えば、テストで見つかった欠陥の情報を真摯に受け止めようとしない)」では曲解が過ぎる。「テストに対する無作法な態度や期待。(例えば、テストで欠陥を検出することの価値を理解しようとしないなど)」が正しいニュアンスだ。

(□) 「リスクとリスクの回避策を記述する旨を」は、せいぜい「リスクと対策」程度にとどめておきたい。IEEE 829では回避策にまで言及していないはずだ。計画段階で回避策まで具体化しない。具体化できるなら対応せよ、ということになるだろう。一般に、回避策という場合は計画的でない。計画的なものを偶発性計画(＝コンティンジェンシー計画)というはすだ。

P59 プロダクトリスク

(□) 「...失敗する可能性のある領域(次に起きる事象が意に沿わなかったり、危険を引き起こしたりする可能性)をプロダクトリスクと呼ぶ」では誤解しそう。リスクの主体はプロダクトでないといけない。また括弧書きが変。「...故障が起きる可能性のある領域（不利な将来イベントや危険要因）はプロダクトリスクとなる」としたい。領域＝プロダクトリスクではなく、プロダクトリスクの発生源になるというイメージでないと誤解する。

(□) 「故障の起きやすいソフトウェアの出荷」では主体が「出荷」となり誤解を招く。リスクの主体はプロダクトでないといけない。だから「故障の起きやすい出荷済みのソフトウェア」などとしておきたい。

P60

(□) 「リスクコントロールとしてのテストは、重大な欠陥の除去や偶発性計画の効果を計測することで、残存リスクについてのフィードバック情報を提供できる。」なら、すこし分かりやすい。ちなみにContingency planはたしかに緊急時対応計画、偶発性計画、コンティンジェンシー計画などと訳されるが、個人的には偶発性計画が素直だと思う。Contingency planは用語集の見出し語にはないが、なぜか一部(テスト計画の説明)で「代替計画」と訳されていたりする。すくなくともシラバスにも用語集にも出てくる用語なので、独立した見出し語として偶発性計画(Contingency plan)で登録しておくほうがいいだろう。登録されていれば、コンティンジェンシープランでも我慢はできる。代替計画はやめた方がいい。

(■) 「このアプローチはプロダクトリスクを1つずつ洗い出すこと、テスト計画作業のガイダンス...」の文は係り受けがおかしい。「プロダクトリスクを識別すること、それらリスクをテスト活動(テスト計画とコントロール、テスト仕様の作成、テストの準備と実行)のガイドとして利用することを含んでいる。」が正しい。

P61 インシデント管理

(□)「検出時点から分類、修正、最終確認まで」は正確には「検出と分類から、修正と確認まで」

(□)「問題を特定、抽出、解決できる」は「問題を識別し、欠陥を特定し、修正できる」でいい。identify,isolate,correctの訳をいろいろと変えないで統一したほうがいい。

(■)「インシデントログの作成日付、作成した組織、作成者」は大間違い。インシデントレポートの話なのになんでインシデントログが出てくるのだ。単に「発行日、発行組織、作成者」でいい。インシデントログはインシデントレポートから参照されたり、添付されることはあるだろうが、論理的に別なものだ。

(□)「期待した結果」は「期待結果」で統一のこと。用語だ。

(□)「インシデントが発生した...」は「インシデントが観察された...」の方が適切だろう。

(□)「識別、欠陥の特定、修正、修正後の確認」という感じで用語を統一のこと。

P64 テストツールの種類

(□) 用語に「デバッグツール」が挙げられているが、これはV1.1.0の残骸なのか。ISTQBでも残っている。シラバスでは全く触れられていないが、これも出題範囲なのだろうか。

(□)「表計算ソフトウェア」といったり、「スプレッドシート」といったり不統一だ。

(■)「テストの中で行われるプロセス全体」ではなく「テスト実行のプロセス全体」だ。計画や設計のことは言っていない。

P67

(□) authorizationは単に「権限」とするのではなく「認可」の方がいいだろう。認証・認可はセットだ。

P67 データ品質評価

(■) 最後の文がおかしい。「標準に変換することを保証する」ではない。「データ変換やデータ移行の際に、処理したデータが正しく、完全で、事前に定義された条件を満たしているかどうかをレビューし、検証するために利用される。」が正しいニュアンスだ。

P70 組織へのツールの導入

(□)「ツールを活用するために...」がわかりづらい。「ツールを導入してテストプロセスを改善するために、組織の成熟度、強みと弱みを評価し、導入の機会を見極める。」ではどうか。

(□)「ツールべンダー(...)」の括弧がきの修飾がおかしい。「ツールべンダーについて...などを評価する。非商用ツールの場合...」としたらどう。

おわりに

指摘の内容に間違いがあるかもしれませんが、ほとんどが明らかな欠陥と認められるはずです。 読者の責任と、シラバス翻訳担当者の責任において、指摘の内容をよく検討し、何が「真」であるかを判断くださいますよう、お願いします。 シラバスはバイブルであり、多くの学習者や教材や市販本のベースになります。 シラバスの欠陥は非常に「高価な欠陥」になることを理解していただき、関係者には早急に対応していただけることを期待しています。