シラバス2011をチェックしてみた。(3)
【2011/05/17追記】この記事は「FLシラバスのレビューメモ」の方に6回分をまとめておきました。
先日、JSTQBのHPで、第10回Foundation試験の合格者が発表され、また8/27に第11回Foundation試験と第1回Advanced試験(テストマネージャ編)を実施すると公表されました。次回のFoundation試験は、シラバス2011と最新の用語集に準拠して行うことも通知されています。いままさにそのFoundationのシラバス2011版を読んでいるのですが、かなり疑問に思える点もあり、また翻訳での間違いが多く、苦労させられています。シラバスはバイブルであり、多くの学習者や教材や市販本のベースになるわけですが、ちょっと品質が良くないと言わざるを得ません。シラバスの欠陥は非常に「高価な欠陥」になることを理解していただき、早急に対応していただけることを期待します。
このシラバス2011は3/30に公開され、4/07にアナウンスされました。気付いた、おかしい箇所を挙げています。早期に対応していただけることを期待しています。今回3回目の指摘です。以前の指摘とあわせて参照ください。
・シラバス2011をチェックしてみた。(P12〜P32)
・シラバス2011をチェックしてみた。(2)(P26〜P37)
では、JSTQBのシラバス2011をチェックして気付いた点を挙げてみます。致命的なものには(■)を、軽微なものや要望には(□)をマークしています。
P38 レビューの種類
(■) 「...成果物を何度もレビューすることがある。複数回のレビューを実施する場合、レビューの種類によって実施する順番がことなる」では微妙にニュアンスが違う。「...成果物をレビューする主題は複数ある。複数のレビューの種類を適用する場合、順序は様々である。」が正しい。単に回数ではなく、複数種類のレビューを組み合わせる場合のことを言っている。
P38 ウォークスルー
(□) 「運営により」では硬い。in practiceなので「実際の適用では」くらいではどうか。テクニカルレビューでも出てくる。
P38 テクニカルレビュー
(□) 「指摘一覧、...」の文が微妙におかしい。「レビューレポートを準備する。指摘事項の一覧、ソフトウェアプロダクトが要求に合致しているかどうかの判定を含めること。また適切に、指摘に関しての対処を含めること。」ではどうだろう。
P38 インスペクション
(□) 「各人の役割が決まっている」ではニュアンスが違う。「役割を定義する」としたい。なお、ここでのrolesはチェックリストと並ぶ技法の1つとして捉えられている。「配役／役割決め」といったニュアンスが必要だ。
(■) 「規則やチェックリストを使い、形式に基づいたプロセスで進める」は間違い。rolesとrulesを間違えたか。「役割決めとチェックリストに基づいた公式なプロセスである」が正しい。ISTQBではインスペクションは公式なレビューとされている。ここではrolesを技法として扱っているので、単に役割とするのではなく「役割決め」としたらどうかと思う。
(■) 「インスペクション前の準備が必要である」という表現はプロセスが分かっていない。インスペクションというプロセスの中に事前ミーティング準備というアクティビティがある。「事前ミーティング準備を行う」が正しい。
(■) 「インスペクションのレポートや指摘一覧を書く」という表現では成果物の包含関係がおかしい。「インスペクションレポートを作成する。指摘事項の一覧を含めること」が正しい。
(□) 「形式の決まったフォローアッププロセスがある」は誤解をさけて、「公式なフォローアッププロセスである」とすること。たしかに「形式的」と訳してもいいのだが、レビューの公式性は様々であると冒頭に述べているので、各レビュー形態では、公式性について個々に語る方がいい。
P38 レビューを成功させるために
(□) レビューを成功させるためにとして列挙された項目は結構意訳されていて、微妙なものが多い。「...すること」で統一すると分かりやすいと思う。
(□) 「レビュー開始前に目的を明確にする」も微妙におかしい。「レビュー目的を明確に事前定義しておくこと」が正しい。「レビュー開始前」と表現しないほうがいい。
(■) 「欠陥を見つけることは目的に合致しており、歓迎すべきことである」ではなく「発見された欠陥は、歓迎し、客観的に表現すること。」が正しい。
(■) 「目的を達成するために」の項目は係り受けがおかしい。「目的の達成に適った、またソフトウェア作業成果物やレビューアのタイプやレベルに適ったレビュー技法を適用すること」が正しい。
(□) 「欠陥を効率よく見つけられれるのであれば」の文は「チェックリストや役割決めは、欠陥識別の効果が期待できる場合に用いること。」くらいかな。ここも「役割決め」にしておきたい。原文もはっきりしない文だが、チェックリストや役割決めの技法は使ってもいいが、逆効果ということもあるのでむやみに使うなというニュアンスのようだ。
(■) トレーニングは全てに必要で、特にインスペクションで大切というニュアンスなので「レビュー技法をトレーニングして習得すること。特にインスペクションのように公式性の高い場合では重要。」ではどうだろう。
(□) 「管理者」としない方がいい。「良好なレビュープロセスを支援できるように管理すること。(プロジェクトスケジュールにレビュー活動の予定時間を組み込むなど)」ではどうだろう。
(□) 「学習とプロセス改善は目的」と言い切らない方がいい。「成功には、学習とプロセス改善が重要である」ではどうだろう。この文だけ前述のものらよりトーンが異なる。
P39 ツールによる静的解析
(■) 「リンクのようにソフトウェアモデル間の依存性、非依存性を見つける」では「非依存性」を「不整合」に差し替えた方がいい。
(□) 「開発中に学習することで欠陥を予防する」ではニュアンスを誤解しそう。「開発中に学んだ教訓は、欠陥の予防に役立つ」くらいではどうだろう。
P42 テスト開発プロセス
(□) formal,informal,formalityはここでは「形式的」などと訳さずに「公式」「非公式」「公式性」と訳すべきだ。組織やプロジェクトできっちり定義したプロセスに沿っているか、そうでないかの差だ。レビュープロセスのときの公式性と同等のトーンでいい。
(■) 「公式性のレベルは、テスト実施の条件に依存する。例えば、テストプロセスや開発プロセスの成熟度、時間制約、安全性や規制の要件、参加する人員などに依存する。」ではどうだろう。時間的余裕ではなく時間制約だ。
(□) 「テスト条件は、...項目やイベントとして定義する」ではなく「テスト条件とは、....項目やイベントである」とした方が明確だ。
(□) 「構造的要素」は構成要素あるいは構造要素でいいでしょう。
(■) 「トレーサビリティを確立できると」の文が分かりにくいというか間違っている。「トレーサビリティを確立できると、要件変更のときに影響度分析が効果的に行えるし、要件を網羅できるテスト集合を決定することもできる」だ。
(□) 「テスト分析では...リスクに大きく影響を受ける」の文がおかしい。「テスト分析では、テスト設計技法を選択してテストアプローチを詳細化する。テスト設計技法の選定は、いろいろな観点の中でも特に、識別されたリスクにもとづいた利用を考慮して行う。」ではどうだろう。テストアプローチ、テスト設計技法の選定は単語として明確に表現したい。
(□) この節はプロセスの説明なので、「テスト分析では...」「テスト設計では...」「テスト実行では...」というように統一的に書き出すと分かりやすくなると思う。
(■) テストケースの定義も係り受けが微妙におかしい。「テストケースは、特定のテスト目的やテスト条件を網羅するために定義された、....を集合として構成される。」が正しい。ただ、1つの特定の目的や条件に対応して1つのテストケースが存在することを強調した文になっているので「テストケースは、...で構成される。テストケースは、特定のテスト目的やテスト条件(1つの場合も複数の場合もある)を満たすように定義する」と訳してやると丁寧だ。網羅と表現してもいいが、どうも誤解しやすい。「テスト条件をいくつかのテストケースで網羅する」と表現し、「テストケースはテスト条件の一部または全てを満たす」と表現して区別してやる方が分かりやすいと思う。
(■)テストケースとテスト手順仕様の関係が間違っている。係り受けを間違って訳している。テスト手順仕様のためにテストケースを開発するわけではない。「テスト実装では、テストケースを開発し、実装し、優先順位付けし、テスト手順仕様に組み入れる」ではどうか。
P43 テスト設計技法のカテゴリ
(■) 中ほどの「テスト技法の中には」の訳が間違っている。「テスト技法は1つのカテゴリに収まるものもあれば、複数の要素を備えたものもある」が正しい。BlackとWhiteのどちらかという話ではない。
(□) 「解決すべき問題、ソフトウェアやコンポーネントの仕様として、公式、非公式に関わらずモデルを使用する」としたい。仕様ベースの話なので「定義」とかでなく、きちんと「仕様」と表現すること。formal,informalは「公式、非公式」としたい。
(□) 「詳細化された設計」でもいいが、普通は「詳細設計」という。
(□) peapleを「担当者」と訳すとテスト担当者と勘違いする。単に「人」としておきたい。「人の知識や経験をベースに...」となる。
P44 同値分割法
(□) 「同値分割したグループ」は「同値領域」と換言したほうがいい。
(■) 「同値領域(同値クラス)は、有効データ（受け入れられるべき値）だけでなく、無効データ（拒否される値）にもある。同値領域は入力だけでなく、出力、内部の値、時間依存の値（例えば、イベントの前後で）、インタフェースパラメータ（例えば、統合テストでテストするコンポーネントで）からも識別できる。」ではどうか。「(たとえば、統合テストでの...)」の括弧書きは「インタフェースパラメータ」を修飾しないとおかしい。
P44 境界値分析
(■) 「テストケースを設計するときは、両領域から値を選ぶ」では間違い。「テストケースの設計では、各境界値のテストを選ぶ」が正しい。両領域ではなく各境界値だ。
(□) 最後の文がちょっと誤解しそう。「同値クラスは、人による画面入力で利用されるだけではない。例えば、時間範囲(...)やテーブル範囲(...)にも利用できる」としたい。
今日はここまで。続きはまた後日。
