テストマネージャシラバス日本語版(2007.J02)のレビューメモ

※2015/12/02時点での最新のシラバスは「2012.J03」です。 ここに指摘しているものは「2007.J02」に対するレビューですので注意ください。かなり古いバージョンです。 最新版ではかなりの部分で修正されています。紛らわしいので捨ててもよいのですが、しばらくは残しておきます。 ご了解ください。

「2007.J02」というバージョンは、2011/08/27に第1回テストマネージャ試験が実施されたときのシラバスです。 ここに挙げるものは、事務局でレビューした際のメモを整理したものです。致命的なものには(■)を、軽微なものや要望には(□)をマークしています。

指摘事項

P12 1.1 イントロダクション

(□)「マルチシステム」は「マルチシステムズ」と表現しないと「システムオブシステムズ」との整合性が悪い。

P28 1.3.2.2 セーフティクリティカルシステムと複雑性

(□)「リスクマネジメント(リスクの発生確率と影響度を低減させる)」という表現の方がいいか。 可能性と影響でもいいのだが、他との整合性からだと発生確率と影響度で統一した方がよさそう。

P30 2.1 イントロダクション

(□)「終了基準の検証とレポート」はFLでは「終了基準の評価とレポート」で統一された。

(□)「上記に示したテスト開発での作業を除き」が何を指すのか分からない。原文もはっきりしない。 おそらく、テストアナリストとテクニカルテストアナリストは、5つの活動の中で、テストケースの開発(作成)に関わる分析・設計・実装まで は関係するが、残りのテスト計画とコントロール、テスト実行、評価とレポート、終了作業はFLレベルの知識で十分だといっているようだ。 テスト実行を含むかどうかは微妙ではある。

P30 2.2 テストプロセスモデル

(■)「実践的ソフトウェアテスト」は後述の「Practical Software Testing」のことだ。訳すのか訳さないのかはっきりして欲しい。

(□) 最後の3行がなぜ訳されていないか意図が不明だ。TMM,CTP,STEPが何の略であるか示したいなら、もっと工夫すること。

P32

(□)「テスト計画作業のほとんどはテストに関わる活動を始めるときに着手し、テスト戦略で 識別された使命や目的を達成するためのすべての活動やリソースを識別し実装する」の訳がおかしい。

P37 2.7 終了作業

(□)「テスト実行中に実施したテストケースの割合」は「テスト実行の活動で実施したテストケースの割合」の方が誤解がない。

(□)「成果物として識別し、保管したものの割合」は「識別して保管した成果物の割合」の方が誤解がない。 おそらく、きちんと構成管理したドキュメントの数や量のことを言っていると思われる。

P39 3.2.2 テスト戦略

(■) テスト戦略とテストアプローチの考え方は、FLシラバスで見直されたが、ALには反映されていない。 FLとの不整合として、唯一挙げられる点である。 ALで説明される「テスト戦略はテストアプローチともよばれる」という説明は適切ではなくなった。 FLシラバスの記述が優先されるべきである。 FLでは予防的、対処的アプローチという概念も明示しないことになっている。 日本語訳の問題ではなく、ISTQBでの不整合といえる。 AL試験でどう扱われるかははっきりしないが、ALに提示の考え方は古いということを理解しておく必要があるだろう。

P41 3.4 テスト見積り

(□)「コスト、労力、期間」と訳されているが、「コスト、工数、期間」が一般的。 しかも、本文では後半ではきちんと「コスト、工数、期間」と訳せている。一貫性のなさを露呈している。 労力と訳されている箇所は、ほとんど工数と置き換えてもよさそうだ。結構な箇所で現れる。

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

(□)「確信度合い」はconfidenceの訳であることを添えておきたい。 confidenceは、テストの目的でも表現されているので、一貫性のある訳で統一しておきたい。 その訳が「確信度合い」であるならそれでもいいが、統一してもちいること。

P44 3.7 テストのビジネスバリュー

(□)「ビジネスバリュー」は「ビジネス価値」でいいと思う。

(■)「定量的価値」で統一すること。「量的価値」と訳したものが混ざっている。 これも数箇所で現れる。

P45 つづき

(■)「評価コスト」となっているが、「検出コスト(cost of detection)」の間違い。 市販雑誌でも誤ったままの参照が見られた。ちなみに用語集では「査定コスト(appraisal cost)」という表現も載っている。

(■)「内部失敗コスト」、「外部失敗コスト」となっているが「内部故障コスト」、「外部故障コスト」で統一すること。 市販雑誌でも誤ったままの参照が見られた。

P46 3.9 リスクベーステスト

(□)「リスクの度合い」は「リスクレベル」と訳さないといけない。用語だ。用語集との整合性もある。

P47 3.9.2.1 リスク識別

(□)「リスク自体の識別でプロセスが停止する」では誤解する。「識別されたリスクによってはリスク識別のプロセス自体が停止する」かな。
※ただし、筆者も意味がよく分からず。

(□)「危険分析」は、私なら「危険要因分析」としておく。

P48 3.9.2.2 リスク分析

(■)「財政的、経済的、社会的損失または責任の可能性」ところは「責任」よりも「負債」のニュアンスの方がいい。

(■)「次善策」は「回避策」。workaroundは一般に回避策で定着している。 「次善策」だと何が「最善策」なのか示さないとつながらない。

(■)「2つの値をかけることで発見のコストを計算できる」では誤解する。 「(発生確率と影響度)の2つの値を乗じることで、リスクが露呈した場合のコストを計算できる」としたい。発見では誤解する。 リスクが実際の問題となって表出すること(exposure)は「リスク露呈」と訳すのがいいと思う。

(□)「質的か量的か」は「定性的か定量的か」で統一すること。数箇所に見られる。

P49 3.9.2.3 リスク軽減

(■)「リスクを他の処理担当部門に移転させる」では誤解する。「リスクの扱いを他の組織・部門に転嫁させる」にすべき。すでに「リスク転嫁法」として定着している。 あるいは「リスクの扱いを他の組織・部門に移転させる。(リスク転嫁)」としておくといいだろう。市販雑誌でも誤ったままの参照が見られる。

(□)「リスクを無視して、そのまま受け入れる」は「リスクを無視して、そのまま受け入れる。(リスク受容)」のような記述だとありがたい。 リスク受容またはリスク保有として定着している。

P49 プロジェクトリスク軽減

(□)「テストスタッフの調達能力と資質」は「テスト要員の可用性と適格性」の方がいい。要員がフルに参画できるか、スキルはあるかといった意味だ。

(□)「テストへの入力情報の錯綜」は「テスト入力情報の変更頻度の多さ」。

(□)「標準類、ルール、技法の欠如」は「標準、ルール、技法の欠如」。類は不要。

(□) 8項目のリスク軽減アプローチについての訳がはっきりしない。 「プロダクトの以前のバージョンに対する事前テスト」や「以前のプロジェクト結果のレビューへの参加」では誤解する。 「早期」も明示すること。 「テストウェアの早期準備(早期に準備すること)、 テスト機器の事前テスト、 プロダクト早期バージョンの事前テスト(早期に入手して事前テストすること)、 テスト開始基準の厳格化、 テスト容易性要件(要件を明確化すること)、 早期プロジェクト成果物レビューへの参加(早期にレビューすること)、 問題管理や変更管理への参加、 プロジェクト進捗や品質のモニタリング」といった感じかな。

P49 プロダクトリスク軽減

(□)「縦型探索(Depth-first)、横型探索(Breadth-first)」という訳はどうも直感的にわかりにくい。 「深さ優先、広がり優先」でよかったと思う。(※この訳語にはベースとなったものがあるのだろうか。)

(□)「テストはこのようなリスクを軽減する形式となる」では、意味が伝わらない。 「テストはこのようなリスク(プロダクトリスク)を軽減するための手段となる」としたい。

(□)「リリースの前に欠陥やその処理機会について認識することにより」では、誤解するだろう。 「リリース前に欠陥に気付いて対処する機会が与えられることで」としたい。

P50 つづき

(■)「詳細なテストサイクルのためのテストの調整」では誤解する。 furtherを「詳細な」と訳しているが、「以降も続くさらなるテスト」のことを言っている。 別に詳細でなくてもいい。「後続のテストサイクルでのテストの調整」ではどうだろうか。

P52 3.11.1 探索的テストに対するテストマネジメントの考慮点

(□)「テストオブジェクト」は「テスト対象」と訳す約束のはず。

P53 3.11.3 セーフティクリティカルシステムに対するTMの考慮点

(□)「システムが組織によって「重要」と分類されている場合」は「システムが組織によって「クリティカル(重大)」と分類されている場合」とすべき。 セーフティクリティカルシステムで統一するなら、当然「クリティカル」の説明でないといけない。

P53 3.11.4 その他のTMの考慮点

(□)「所定のアプリケーション」は「対象のアプリケーション」でいい。

P54 つづき

(■)「コミュニケーション」は「通信」と訳しておくべき。人間系のコミュニケーションのことではないため。 「組織要因」、「通信要因」、「データセキュリティ要因」のように揃えた方が、後続の説明と整合する。

P54 3.11.4.1 ステークホルダの要件

(■)「非機能的な要因」は「非機能要件」と訳せ。紛らわしい。どうしてこんな訳が唐突に出てくるのか不思議だ。

(□)「要件を扱う人は」は「要件の読み手は」でいい。要件を語る人や記述する人のことではないため。

P55 3.11.4.3 必要なハードウェア

(□)「専用の研究所」は「ユーザビリティ・ラボ」とでも訳して統一して欲しい。ISTQBの用語集にもある。 シラバスではラボといったり、研究所といったり、不統一だ。数箇所に見られる。

P71 5.3.2　信頼性テスト

(□)MTTRの訳としては「平均修理時間」の方が一般的だ。

P77 6.2　レビューの原則

(□)「レビュー題材」は「レビューの対象」でいいと思う。テーマや目的ではなく、レビュー対象のドキュメントのことだ。

P78 6.3.1　マネジメントレビューおよび監査

(■) マネジメントレビューの特徴が7項目挙げられているが、途中のインデントが壊れている。 「たとえば」の係り受けがおかしい。「by or for」のニュアンスがおかしい。
・Carried out by or for managers having direct responsibility for the project or system
・Carried out by or for a stakeholder or decision maker, e.g. a higher level manager or director
ニュアンスとしては以下の感じだ。意思決定者が最低一人は含まれることを強調していると思う。
・プロジェクトやシステムに直接責任を持つマネージャたちで実施する。
・一人のステークホルダや意思決定者（上位マネージャや部門長など）を含めて実施する。

(□)「成果には...を含む」は「レビュー結果ドキュメントには...を含む」の方が親切かな。

(□) 最後1項目は「参加者は個々の準備を行う」と「決定事項は記録する」に分離したほうが誤解がない。 くっつけると誤解する。

(□)「監査担当者は、ヒアリング、観察、...」はきちんと「監査担当者は、インタビュー、証言、...」と訳すべき。 インタビュー、証言はエビデンスを得る技法として定着している。

P79 6.3.2　開発成果物ごとのレビュー

(□)「安全性(safety)を最重要視するシステム」は、他のところではすべて「セーフティクリティカルシステム」で通しているはず。

P83 7.4　欠陥フィールド

(■)「完全、完結、正確、客観的」は「完全、簡潔、正確、客観的」の間違い。 完結と簡潔をワープロ変換でミスしたようだ。Conciseは簡潔・簡明といった意味だ。最悪のミスだ。

P84 7.6　インシデントのコミュニケーション

(□)「欠陥選別ミーティング」は「欠陥トリアージミーティング」の方がイメージしやすい。

P88 8.2.4.3　食品および医薬品行政

(□) ここの文章はインデントがおかしくなっている。前項の「宇宙産業」の箇条書きが影響しているようだ。ワープロ編集ミス。

P92 8.5　TMM

(■) CMMIの説明で「プロセスエリア、汎用ゴール、汎用プラクティス、特定ゴール、特定プラクティス」は 「プロセス領域、共通ゴール、共通プラクティス、固有ゴール、固有プラクティス」と訳すの一般的だ。 CMMIとの訳語の整合性がとれていないことを露呈している。

P99 9.2.7　オープンソーステストツールの使用

(□)「ツールの正確性」と訳されているが、この場面では「ツールの適格性」といったほうがいいだろう。

P99 9.2.8　独自のテストツールの開発

(■)「知的所有権を保有するテスト環境やハードウェアを用いる場合」ではなく、「所有するテスト環境やハードウェアを用いる場合」である。 知的所有権は関係ない。単に所有するテスト環境やハードウェアに特化したテストツールが欲しい場合という意味だ。

P99 9.2.9　テストツールの分類

(■)「COTS」ではなく、単に「既成プログラム」である。商用のものに限定はしていない。

(□)「実際のユーザに従って分類できる」ではなく、「以下、実際のユーザに従って分類している」である。

P100 9.3.1　テストマネジメントツール

(□) 追跡機能の3番目の説明が分かりにくい。 「テストスイートの異なるテスト環境での並行実行に関するデータ（複数のサイトや組織で横断的に同じテストセッション内の実行される場合）」ではどうか。

(■)「実行する時間」の項目も分かりにくい。間違った解釈になっている。 正しくは、「実行時間（...など）とその他の重要なタイミング。マネジメントでの判定に利用できる平均値を含む」である。

(■)「テストケースのテスト成果物、リポジトリ、ドライバなどの管理」は間違った解釈になっている。 正しくは、「テスト成果物の管理機能、テストケースのリポジトリと操作機能」かな。スタブやドライバのことではない。

(□)「テストの進捗を記述する、テスト成果物についてのテストメトリクス（テストドキュメンテーション）」では誤解する。 「テスト進捗を記述するテスト成果物（テストドキュメンテーション）についてのテストメトリクス」が正しい。

(□) 追跡機能として5項目挙がっているように見えるが、インデントがおかしいのではないかと思う。 メトリクスまでは含めてもいいが、最後の1項目も追跡機能のようには読み取れない。 単に「テストマネジメントツールには以下のものを支援する機能もある」でいいような気がする。

P101 9.3.3　ツールのデバッグとトラブルシューティング

(■)「ツールのデバッグとトラブルシューティング」ではなく、「デバッグツールとトラブルシューティングツール」だ。

P102 9.3.4　フォールトシーディングツールとフォールトインジェクションツール

(□)「ミューテーションテスト」は「変異テスト」でいい。変異と変異体を使い分ける必要はないだろう。

P102 9.3.6　静的および動的解析ツール

(□) 誤解をさけるために「静的解析ツールと動的解析ツール」と訳さなければいけない。

(□) 案の定、冒頭の1文が動的解析ツールのことだけを語ってしまっている。原文では静的解析ツールと動的解析ツールが併記されている。

P104 9.3.9　Web関連ツール

(□)「SLA」を「サービス品質保証制度」と訳しているが「サービスレベル合意」とか「サービスレベルアグリーメント」のままの方がいい。

P105 10.2　個人のスキル

(■)「シミュレートしたユーザー数」は不要だ。前のページから箇条書きをコピペして編集した際にゴミとして残ったもののようだ。 このミスもひどい。

P106 10.4　組織内におけるテストの適合

(□)「最終目標」は「ゴール」のままの方がいい。

P107 10.5　モチベーション

(■)「給与、メリットやボーナスの増加を含む」は「給与、昇給、賞与を含む」だ。merit increaseとは昇給のことだ。

P108 10.6　コミュニケーション

(■)「情報の収集と分散」では誤解する。「情報の収集と共有・配布」ではどうだろうか。分散して管理することではなく、情報を伝える手段を言っている。

(□)「すべてのコミュニケーション」は「3つのコミュニケーション」とした方が、誤解がないだろう。

おわりに

以上です。気付いたものを列挙したに過ぎません。最新のシラバスで修正されているかを後日確認したいので、残しておきます。 シラバスが分冊化された時点で、記述自体がなくなっている可能性もあります。