シラバス2011をチェックしてみた。(2)
【2011/05/17追記】この記事は「FLシラバスのレビューメモ」の方に6回分をまとめておきました。
用語検索ツールをいくつか強化したので、使ってみてください。簡単な検索履歴機能を追加しました。学習目的で利用される場合を想定して、もっとハイパーリンクを充実させていくつもりです。ただ、コンテンツの編集は手作業なので、余裕があるときに徐々に対応していくつもり、気長にお待ちください。また、アクセスカウンタを追加したり、ソートも選べるようにしたり、高度な検索も行えるようにしました。妥当性確認とか、受け入れ基準などで検索を試してみてください。また、先日2011/04/22にJSTQBが正式に用語集2011版を公開したようです。急いで、ダウンロードし、上記の用語検索ツールとの整合性をチェックしておきました。JSTQB 2011版の用語集には、まだ不備も多いようです。usabilityを有用性と訳したり、判定とデシジョンが混在したりといった問題も依然として残ったままです。訳がおかしいと思える見出し語を挙げてみると、インシデント、欠陥、検証、妥当性確認、一貫性、アルファテストなど基本的な用語さえも該当します。ぜひ、当方のツールを利用いただいて、確認していただけたらと思います。JSTQB 2011版の用語集で、勿論、いくつか改善されている点もあります。操作プロファイルが運用プロファイルに、ソフトウェア機能がソフトウェアフィーチャに、予想結果が期待結果に修正されていました。
では、引き続いて、JSTQBのシラバス2011をチェックして気付いた点を挙げてみます。致命的なものには(■)を、軽微なものや要望には(□)をマークしています。
P26 統合テスト
(□) 前回指摘はしなかったが、P26の最後の文「これは機能的および構造的アプローチが使える」だが、ちょっと誤解しそうだ。訳はたしかに正しいのだが、テストアプローチのことかと誤解しそうなので「統合の各段階では、機能テストと構造テストの両方が適用できる。」くらいの表現に変えておく方が親切だろう。
P27 システムテスト
(■) 前回保留にしておいたところの指摘だ。「システムテストの対象となる機能要件を」以降の文は、機能テストの後に構造テストをせよというニュアンスが失われてしまっている。正しくは「対象システムの概観をテストするために、機能要件のシステムテストを最適な仕様ベース（ブラックボックス）技法を用いて開始する。例えば、...。それから構造べース（ホワイトボックス）技法を用いて、構造要素に対してテストの徹底度を査定する。例えば、...。」となる。この流れを失ってはいけない。
P30 機能テスト
(□) 前回指摘はしなかったが、P30の中ほどの「機能やフィーチャ（ドキュメント中に記述してあること、あるいはテスト担当者が理解していること）」だが、誤解しそうだ。訳はたしかに正しいのだが、括弧書きがフィーチャの定義のように見えてしまう。括弧を外したほうがいいだろう。「機能テストは、機能やフィーチャ、またそれらの特定システムとの相互運用性にもとづいたものである。ドキュメント中に明示されていることだけでなく、テスト担当者が理解していることも含めてテストする必要がある。また機能テストは、全ての...」といった感じではどうだろう。
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 テクニカルレビュー
(■) 「レビューアが事前ミーティングを準備する」ではなく、前述のように「レビューアは事前ミーティング準備を行う」が正しい。事前に対象ドキュメントをレビューしておくことだ。
(□) 「チェックリストを作ることがある」ではなく「チェックリストを使うことがある」が正しい。作ってもいいが、既存のものを使うことも多い。
今日はここまでとさせてください。残りは後日チェックしてみます。
