シラバス2011をチェックしてみた。(5)
【2011/05/17追記】この記事は「FLシラバスのレビューメモ」の方に6回分をまとめておきました。
引き続いて、JSTQBのシラバス2011をチェックして気付いた点を挙げてみる。致命的なものには(■)を、軽微なものや要望には(□)をマークしている。JSTQBには早期に対応していただいて、完成度の高いシラバスにしていただけることだけを期待している。今回5回目の指摘です。以前の指摘とあわせて参照ください。・シラバス2011をチェックしてみた。 (P12〜P32)
・シラバス2011をチェックしてみた。(2) (P26〜P37)
・シラバス2011をチェックしてみた。(3) (P38〜P44)
・シラバス2011とシラバスV1.1.0の差異を説明してみる。
・シラバス2011をチェックしてみた。(4) (P44〜P54)
・シラバス2011をチェックしてみた。(5) (P55〜P62)
P55 テスト終了基準
(□) 「テスト終了基準は...テストの終了を定義することである」では不自然だ。もっと素直に「終了基準は、テストレベルの終わりや、テスト集合が特定のゴールを達成したときなどのように、いつテストを終了させるかを定義する。」ではどうだろう。
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の訳をいろいろと変えないで統一したほうがいい。
(■)「インシデントログの作成日付、作成した組織、作成者」は大間違い。インシデントレポートの話なのになんでインシデントログが出てくるのだ。単に「発行日、発行組織、作成者」でいい。インシデントログはインシデントレポートから参照されたり、添付されることはあるだろうが、論理的に別なものだ。
(□)「期待した結果」は「期待結果」で統一のこと。用語だ。
(□)「インシデントが発生した...」は「インシデントが観察された...」の方が適切だろう。
(□)「識別、欠陥の特定、修正、修正後の確認」という感じで用語を統一のこと。
今日はここまで。残りのツールに関しては、個人的に関心が薄いので大雑把なチェックにとどめたいな。
