テストアナリスト編のシラバス日本語版（2012.J01）のレビューメモ

本書は、「テストアナリスト編のシラバス」のレビューメモです。 対象シラバスのバージョンは「2012.J01」です。

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

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

指摘事項

P11 1.3.2 テストのモニタリングとコントロール

(□)「要件とリスクカバレッジの情報（トレーサビリティ）」は誤解しそう。 「要件カバレッジやリスクカバレッジの情報（トレーサビリティ）」ではどうだろう。

P13 1.5 テスト設計

(■)「以前に指定されたテストを参照し、理解することが必要になる」は間違い。 これは「事前にテストの記述を読んで理解する」が正しい。 過去に記述されたテストや、別のところに記述されたテストを参照せよということではない。 第三者がテストケースを読んだとき、目的や重要性までも理解してもらえるように記述しておきたいということだ。

P15 1.6 テスト実装

(■)「テスト担当者は、テスト実行時に」は「テスト実装時に」の間違い。

(■)「テスト環境の作成およびメンテナンスの担当者のサポートを得ることができ」も間違い。 テスト担当者は、責任ある当事者であるのに他人任せな訳になっている。 「テスト担当者は、テスト環境の作成と保守について知見があり、環境を準備できる責任を持つ」が正しい。

(■)「分析的なリスクベーステスト戦略」ではなく、「リスクベースの分析的テスト戦略」である。 分析的テスト戦略は用語集にもある。テストベースを分析して、テスト条件を識別するという標準的な方法のことだ。 それをリスクベースで行う場合には、探索的テストなど動的なテスト戦略を組み合わせると言っている。

P16 1.7 テスト実行

(□)「適切な時間をかけて、テスト時に観察された他の興味を引くテストシナリオおよび振る舞いを 確実にカバーする必要がある。そのような逸脱の発生時に検出したすべての故障を、故障を再現するために必要な手続き化された テストケースからのバリエーションを含めて記述する必要がある」では、additionalが訳せていないし、anyをすべてと訳すので伝わりにくい。 「関心のあるテストシナリオやテスト時に観察された振る舞いについて追加のテストを行うために適切な時間を確保する必要がある。 さらに、故障が検出された場合には逸脱について記述しなければならず、そこには手続き化されたテストケースだけでなく、 故障が再現するバリエーションを含める必要がある」ではどうだろう。 怪しいと感じた部分について追加のテストをしたり、インシデントレポートに再現性、再現手順、再現範囲を確認して追記したりするための時間が確保される必要があることを言っている。

(□)「手続き化した際のテスト範囲の不足が引き起こす見逃しの防止」がわかりにくい。 「手続き化されたテスト（スクリプトテスト）で網羅されずに漏れてしまうテストの予防」ではどうだろう。

(■)「欠陥を識別したら」は「故障を識別したら」の間違い。

P17 (続き)

(□) confidenceを「信頼感」と訳しているが、「確信度合い」で統一するのではなかったか。

(□) irrelevant を「関連性のない」と訳しているのでどうもしっくりこない。何と何の関連性なのか。 「怪しい兆候に注目して探索せよ」と言っている。

(□)「疑わしい問題を検出した場合、・・・そのテストケース以降のテスト実行で検出されるであろう」と2回「検出」が出てきてよく分からない。 「疑わしい問題があれば、ただちに問題を調査してメモしなさい。後でテストケースの実行で検出されるだろうと期待してはいけない」と言っている。 なぜなら、後で実行されない可能性が高いからだ。

P20 2.2 テスト進捗のモニタリングとコントロール

(■)「使用するライフサイクルが、記録する欠陥ドキュメントの量と、情報を記録する方法に影響を及ぼす」とあるが 「使用する」がおかしい。単にライフサイクルだと開発のライフサイクルモデルと誤解する。 ここは欠陥のライフサイクル(欠陥が作り込まれてから除去されるまで)を言っている。 欠陥情報はいろいろなタイミング（検出時、分析時、修正時、確認時など）で情報が追加される。

P22 2.4.2 リスク識別

(■)「ドメインエキスパートやユーザと共に行うエキスパートへのインタビュー」は間違い。「共に行う」ではない。「ドメインエキスパートやユーザーへの専門的なインタビュー」である。

P22 2.4.3 リスクアセスメント

(□)「テクニカルリスク」は「技術的リスク」とすべき。なぜなら、FLシラバスではそのように表現しているから。 シラバス間との整合性を考えて用語を徹底させないといけない。 技術的リスクのアセスメントの結果が発生確率であり、ビジネスリスクのアセスメントの結果が影響度であると言える。

(□)「テストアナリストは、各リスクアイテムがビジネスドメインやユーザに及ぼす潜在的な影響を識別および評価する必要がある。 ビジネスリスクに影響する要因を次に示す」の訳は、影響の因果が逆になった表現だ。 リスクの原因を挙げているのではなく、リスクが現実の問題となって発生した場合の予測される結果が挙げられている。 「テストアナリストは、各リスクアイテムごとに、潜在的なビジネスドメインやユーザーに及ぼす影響を識別して、評価する必要がある。 ビジネスリスクが及ぼす影響を次に示す」ではどうだろう。

P23 2.4.4 リスク軽減

(□)「使用性調査の実践または観察」はイメージできない。「使用性スタディの実践または監督」である。使用性スタディはペアプロのような感じで行う。 操作する人と指揮する人がいるようだ。 ※筆者も実態を知らないので正確なことは言えない。おそらく、テスト設計の前に既に動くものが提供されているなら、実際に使ってみることを言っているのだろう。

P26 3.2 仕様ベースの技法

(□)「仕様ベースの技法は、コンポーネントやシステムの内部構造を参照することなく、テストベースの分析に基づいてテストケースを導き出すためのテスト条件に適用する」は誤解する。 「テストベースの分析に基づいたテスト条件に適用して、テストケースを導き出す」がより適切な表現だ。 テスト分析で識別したテスト条件に技法を適用して、テストケースを導出するのである。

P27 3.2.2 境界値分析 ／適用

(■)「数値属性を持つ非数値変数（たとえば、A3、B5といった用紙サイズなど）」はおかしい。 原文の例では「長さなど」とあるのに勝手に列挙型の用紙サイズに置き換えている。 「非数値変数の数値属性（長さなど）」が正しい。何のことかというと、文字列の長さなどのことだ。 文字列の長さは、2文字以上10文字以下のように同値クラスになり、境界値分析に利用できる。 A3、B5といった用紙サイズは列挙型であり、個々の値はそれぞれが同値クラスになり、同値分割には使えるが、境界値分析とは関係ない。

P29 3.2.5 状態遷移テスト

(■)「ソフトウェアはある状態から別の状態に遷移し、アクションを実行する」の訳では誤解する。訳者は状態遷移図を理解していない。 遷移してそれからアクションを実行する訳ではない。「遷移したり、アクションを実行したりする」が正しい。 状態から状態への遷移だけでなく、状態が変わらないがアクションをおこす場合がある。後者は、自身への遷移ともとれる。

P33 3.2.8 ユーザストーリーテスト

(■)「実装対象の機能性の記述、すべての非機能条件」は「実装されるべき機能や非機能条件の記述」が正しい。 訳者は「any」を「すべて」と訳す癖がある。他の箇所にも「any＝すべて」があるので注意のこと。それで通じる場合もあるが、ここは「すべて」ではない。 ユーザストーリーには機能や品質特性を記述することを言っている。

(■)「アジャイル、および類似の反復性または拡張性のある開発の環境で使用する」は「アジャイル、および類似のイテレーティブ／インクリメンタル開発の環境で使用する」でしょう。 イテレーティブ／インクリメンタル開発は、反復型ライフサイクルを総称するときの呼び方だ。 なぜ、ここだけ「反復性または拡張性」と訳すのだ。incrementalを拡張性と訳してはいけない。

P34 3.2.9 ドメイン分析

(■)「1次元ドメイン。例えば、25歳以上65歳以下の男性」では「men」を「男性」ではなく「人」と訳さなければいけない。 男性とすると、年齢と性別の2次元であるように読み取れる。 多次元の説明でも「25歳以上65歳以下かつ体重が70kg以上89kg以下の人」と対応させて訳す必要がある。

(■)「ドメイン理論に基づく方式を用いると、（１次元ドメインでは）テストケース数は変数の数に比例することになるが」はおかしい。 １次元ドメインは変数が１つであり、変数の数に比例するのではない。「ドメイン理論に基づく方式は、線形的増加をもたらすので、」が正しい。 だから、多次元だと指数的増加になると言っている。

P35 3.4 経験ベースの技法

(■)「動的またはヒューリスティックなアプローチ」では「and」を「または」と訳している。ここは「かつ」だ。 一般的な経験ベーステストの説明であり、動的で発見的なアプローチと言っている。テスト実行の中で発見的にテストケースを急造して実行する。 テスト設計を経てテストケースを作成する訳ではない。これを動的と言っている。「動的かつヒューリスティックな」が正しい。

P38 3.4.4 最善の技法の適用

(□)「操作故障を分析する必要がある場合」の「操作故障」は「運用時の故障」とした方がよい。リリース後の運用段階での故障を分析するときが想定されている。

P42 4.2.4 使用性テスト

(□)「使用性テストは、ユーザがシステムを使用して、または使用する方法を習得して、特定の状況で特定のゴールに到達できるという、使いやすさをテストする」は誤解する。 この訳では使いやすさだけが強調されているが、原文のニュアンスは、使いやすさと学習のしやすさが並列である。 「ユーザーがシステムを利用して特定の状況で特定のゴールに到達しようとするとき、システムは使いやすいのか、利用方法は学習しやすいのかをテストする」である。

(■)「正確かつ安全に」は「正確かつ完全に」だ。completenessを「安全」と訳しているが「完全」が正しい。

P43 4.2.4 使用性テスト

(■)有効性、効率性、満足性の訳が原文と異なっている。利用時の品質特性を語っている部分である。 「利用者が指定された利用の状況で」、「明示的な条件の下で」、「指定された利用の状況で」とそれぞれ訳が変わっている。 訳者の意図が分からない。原文は3つとも同じ「in a specified context of use」だ。利用時の品質特性を語っているのだから、 「ユーザが使用するときに」または「利用時の」で統一しなければ誤解する。一体、どこからの転載なのか。

(□)理解性の説明が「ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、およびどのように利用できるかを利用者が理解できるソフトウェアの属性」となっている。 原文には「特定の作業に特定の利用条件で」などは出てこない。どこか別のところから転載したような文章になっている。 原文では「ソフトウェアが利用者にとって、論理的に把握しやすく、適用しやすいものであるか」と言っている。

(■)同じく、運用性の説明が最悪である。「利用者がソフトウェアの運用および運用管理を行うことができるソフトウェアの属性」と原文とは関係のない、 運用性（operability）とは関係のない文章が転載されている。「ソフトウェアが利用者にとって、作業を効果的かつ効率的に行いやすいものであるか」が正しい。 運用性は、運用や運用管理とはまったく関係ない。

P43 4.2.4.1 使用性テストの実施

(■)「ビデオカメラを備えたユーザビリティ・ラボ、擬似オフィス、レビューパネル、ユーザなどを用意する必要がある」は係り受けを間違っている。 ユーザビリティ・ラボを用意せよと言っている。「ユーザビリティ・ラボを用意する必要がある。 このラボでは、実システムが実際の人に与える影響を開発スタッフが観察できるようにビデオカメラ、擬似オフィス、レビューパネル、ユーザなどを揃えておく」が正しい。

(□)「検証可能な使用性の仕様を要件に定義し、すべての類似プロジェクトに適用する使用性ガイドラインのセットを用意することは非常に重要である」はニュアンスが違う。 「要件として定義された検証可能な使用性の仕様だけでなく、すべての類似プロジェクトに適用できる使用性ガイドラインのセットを用意することは非常に重要である」と言っている。

(□)「ガイダンスのアクセシビリティ」は「ガイダンスへのアクセスのしやすさ」でよい。障害者への配慮という意味のアクセシビリティとは違う。 操作法の記述が見つけやすく、説明がわかりやすいことを言っている。

P44 4.2.4.2 使用性テストの詳細

(■)「機能的な側面ではなく、習得性または操作性」の操作性は「運用性」と訳さないといけない。他では運用性である。ISO 9126の用語だ。

P46 5.2 レビューでのチェックリストの使用

(□)「汎用チェックリストは、一意のIDを持つ」の「IDを持つ」は余計だ。必ずしもIDが付与されていなくてもいい。 章・節・項などで階層化してもよい。個々のアイテムがユニークに識別できればよいのだ。

P47 (続き)

(■)「ユースケースの呼び出し構造の可用性」の訳では意味が通じないだろう。use case calling structureは、ユースケース記述のことを言っている。 ユースケース記述が構造的に適切に書けていることを言っている。

P48 (続き)

(■)「FLのシラバスで参照しているような標準チェックリストを使用し、前述のような組織固有のチェックリストを開発すると、 テストアナリストは効果的にレビューを実行できる」はおかしい。２つのチェックリストは並列である。 「FLシラバスで参照しているような標準チェックリストを使用したり、前述のような組織固有のチェックリストを開発したりすると」が正しい。

P52 6.4 欠陥の分類

(■)「拡張による問題」という訳は何かを誤解している。 原文では「enhancement」である。機能の拡張や増強の作業であるエンハンスメントを想定してはいけない。拡張が足らないという問題を言っている。 つまり、資源が不足しているという問題である。物理的なメモリサイズやディスク容量かもしれないし、論理的なスタックのサイズかもしれない。 ちなみに現象（symptom）に挙げられた「性能」とは、性能の劣化のことを言っている。

(■)「（延期された場合、欠陥を確認できない場合も含む）」で「欠陥を確認できない」では「再現しない」というニュアンスになるが、そうではない。 修正後の確認テストで失敗する場合を言っている。

(□)「解決」（resolution）ではなく「解決策」にしておかないと後述の「最終的な解決策」の説明につながらない。

(□)「修正アクション」（corrective action）は、「是正措置」と訳すのが一般的である。CAと略されることもある。 ちなみに反対語が予防措置＝Preventive Action（PA）である。

P53 (続き)

(■)「いつまでに修正したものを提供するかを合意する際に考慮することがある」の訳ではquicklyが消えている。 ここは優先度や重要度に緊急度が関係していることの説明である。だから「迅速に」を漏らしてはいけない。「修正したものをいかに迅速に提供するか」と言っている。

P55 7.2.3.3 テスト自動化の実装

(■)「判定箇所」は「デシジョンポイント」でいい。decision pointの訳だが「デシジョンポイント」のままの方が誤解がない。 プロセスの分岐点である。一般に、なんらかのイベントが発生したとき、それを受け入れるか／拒否するかの判定がデシジョンポイントとなる。 またkeyは「主要な」ではなく、キーワードになることを結びつけやすいように「キーとなる」と訳した方がいいだろう。

(■)「ビジネスプロセスモデル化」は、通常、「ビジネスプロセスモデリング」と訳す。

(■)「ツールは、ビジネスルールとプロセス記述に基づく入力に従って動作する」はまったく逆のことを言っている。 「モデリングは、手動で行うこともできるし、ツールを利用することもできる。ビジネスルールとプロセス記述に基づく入力に従わないツールでもよい」が正しい。

P56 7.2.3.5 キーワード駆動自動化

(□)「スクリプトは特定のキーワードに容易にマッピングできるように、高度に実装する。 これらのモジュールスクリプトを実装するには、プログラミングスキルが必要になる」は、モジュール性の話である。 モジュールの凝集度と結合度を意識した設計がスクリプトにも必要だと言っている。 「スクリプトは特定のキーワードに容易にマッピングできるように、高度にモジュールを実装する。 これらのモジュール化されたスクリプトを実装するには、プログラミングスキルが必要になる」なら許そう。

おわりに

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