シラバス2011をチェックしてみた。(4)
【2011/05/17追記】この記事は「FLシラバスのレビューメモ」の方に6回分をまとめておきました。
次回8/27に実施される第11回Foundation試験は、シラバス2011(4/07公開)に沿って行われることは確かだし、それに対応した用語集も4/22にリリースされている。また8/27には第1回Advanced試験(テストマネージャ編)もあわせて実施されることが決まっている。ところで、そのAdvanced試験の対応するシラバスは2007年版の古いものでやるつもりだろうか。それとも近々Advanced用のシラバス2011がリリースされるのだろうか。また、JSTQBが4/22にリリースした用語集からはAdvancedに該当する用語が削除されていた。ISTQBの用語集は、FoundationとAdvancedを網羅して構成されている風だったが、JSTQBはあらたにAdvanced用の用語集も出すつもりなのだろうか。はっきりしないところだ。古いシラバス2007年版で実施した場合でも、その次の第2回からはすぐにシラバス2011版(またはその時点での最新版)に移行することになり、慌しい感じだ。この状況では、当分はAdvanced用の参考書籍も出せないのではないだろうか。
では、引き続いて、JSTQBのシラバス2011をチェックして気付いた点を挙げてみる。致命的なものには(■)を、軽微なものや要望には(□)をマークしている。非常にペースダウンして申し訳ない。反応もなく、非常にむなしい作業だ。JSTQBには早期に対応していただいて、完成度の高いシラバスにしていただけることだけを期待している。今回4回目の指摘です。以前の指摘とあわせて参照ください。
・シラバス2011をチェックしてみた。 (P12〜P32)
・シラバス2011をチェックしてみた。(2) (P26〜P37)
・シラバス2011をチェックしてみた。(3) (P38〜P44)
・シラバス2011とシラバスV1.1.0の差異を説明してみる。
P44 デシジョンテーブルテスト
(□) ほぼ的確に訳せている。ただ、カラム(列)を表現するものは条件とactionsであるが、actionsを動作と訳したり行動と訳したりして不統一に見える。この文面に限ればすべて「動作」に統一した方がいいだろう。
P45 状態遷移テスト
(□) 「システムの状態により」は余計かな。「システムは、現在の条件と以前の履歴(状態)によりいろいろな動作を示すことがある。このような状況でシステムの様相を表現できるのが、状態遷移図である。」....「状態は有限個であり、それぞれ個々に識別できる。」ではどうか。
(■) 状態とはオブジェクトの状態であり、プロセスの状態ではない。また「(例えば、インターネット...)」の括弧書きは画面フローを修飾しているのではなく、直前の文全体を修飾している。だから「この技法は、いくつかの状態を持つビジネスオブジェクトをモデリングしたり、画面遷移フローをテストしたりするのにも適している。例えば、インターネットアプリケーションやビジネスシナリオのテストで用いられる。」が正しい。「画面による対話処理フロー」は「画面遷移フロー」としていいと思う。
P45 ユースケーステスト
(■) アクター間の相互作用と言っているようだ。アクターとシステム間に限定しないのは、ビジネスユースを考慮していると思われる。「テストはユースケースから導出できる。ユースケースはアクター(ユーザーやシステム)間の相互作用を記述するものであり、システムユーザーや顧客にとっての価値を表現するものである。」ではどうだろう。
(□) 「テクノロジーフリー」とはどういった意味なのか。私にはうまくイメージできない。「ITシステムを利用しないビジネス(?)」か。こういった用語が混ざるとシラバスがわかりにくくなる。適切な訳があれば別だが、この文脈では割愛してしまっていいのではないかと思う。
(■) 「事後条件になると終わる」の説明ではおかしい。条件を満たすから終わるのではなく、終わった時に満たしているべき条件(状態)だ。「各ユースケースは事後条件で終わる。事後条件は、観察可能な結果であり、ユースケースが完了した後のシステムの最終状態である。」が正しい。
(□) likely＝好ましいと捉えたほうがいい。「ユースケースには、基本フローのシナリオ(もっとも好ましい実行)と、代替のシナリオがある。」ではどうか。
(□) また次の文も「ユースケースは、実際の好ましい利用を想定してシステムを介したプロセスフローを記述している。」としたい。次の文でas-is(実世界)に対してto-be(描いたユースケース)を対照することを言っている。そのギャップが欠陥として検出しやすいという論理のようだ。
P46 構造ベース／ホワイトボックスのテスト技法
(□) 「特定の構造」は単に「構造」でいい。specifiedが削除されたのかも。
(□) 「ステートメント、判定、分岐、その他のパス」では「パス」を誤解しそう。「ステートメント、デシジョン(判定)、ブランチ(分岐)、あるいはパス」としたい。「even distinct path」は「前述のものらとは異なった概念であるパス」と言っているようだ。ステートメント、判定、分岐は構成要素だが、パスは構成要素ではないからだ。
(□) 「取りうるデシジョンを視覚化」はちょっと違う。「各デシジョンの選択肢を視覚化」の方がいい。alternativesは、条件によって分岐したtrue,falseなどのステートメントを指して用いられる。
(□) この節では「デシジョン(判定)」また「ブランチ(分岐)」のように統一して用いてほしい。デシジョンテスト、ブランチカバレッジなどのようにカタカナ表記で用語を定義した以上、それで通して一貫性を出してほしい。用語集との整合性・一貫性も当然、必要。
P46 ステートメントテストとカバレッジ
(□) 「網羅したステートメント数を全ての実行可能なステートメント数で割った数」では誤解する。「網羅した実行可能なステートメント数を全ての実行可能なステートメント数で割った値」と正確に記述しておきたい。最後は数でなく「値」にすること。
P46 デシジョンテストとカバレッジ
(■) 「ブランチテスト（ブランチカバレッジ）と呼ばれるデシジョンカバレッジは、」という記述では、ブランチテスト＝ブランチカバレッジ＝デシジョンカバレッジと捉えられてしまう。このように理解させることは適切ではない。カバレッジという概念があり、そのカバレッジに着目して行うテストがある、というニュアンスでないといけない。「ブランチテストに関係するデシジョンカバレッジは...を評価するものである」でとどめていい。
ブランチとデシジョンは厳密には異なる、ブランチカバレッジとデシジョンカバレッジは厳密には異なるニュアンスを残しておく必要がある。
(□) ブランチとデシジョンの差異を説明しているのが次の1文だ。「ブランチはもともとコードの中のデシジョンポイントからきており、コードの中の別の場所に制御を移すことを示す」は一見正しそうに見えるのだが、originate fromを「もともと...からきており」と由来のように訳すのが正しいのか、それが事実なのか、残念ながら私にも判断できない。
ただ、「ブランチは、コード中のデシジョンポイント(判定の瞬間)から生じる。また、制御がコード中の異なった場所へ移ることを示す」とする方が適当かもしれないと思う。そもそも、デシジョン(判定)、ブランチ(分岐)の定義がはっきりしない。コードベースで語るならば、デシジョン(判定)は、if,case,switch,while,untilなど条件判定を伴うステートメントのまさにデシジョンポイント(判定の瞬間)であるから、これは分かりやすい。
一方、ブランチ(分岐)は、ISTQBの定義では「実行が選択される基本ブロックであり、2つ以上のプログラムパスの選択肢があり、そのうち1つが有効であるようなプログラム構造にもとづく。例えば、case、jump、go to、if-then-elseなどである。」とある。判定を伴わない無条件のjumpやgo toも含めているところが気になるし、前半の定義と矛盾するようにも見える。ブランチとは、コード上のシーケンシャルな流れ(命令の順次実行)から他の場所へのジャンプを表現するもの、単に脇道に反れるだけのもの、call,goto,break,continue,jumpといった無条件ジャンプも含んでいると言っているのかもしれない。条件ジャンプのことが「コード中のデシジョンポイント(判定の瞬間)から生じる」と表現され、また無条件ジャンプを含めて「制御がコード中の異なった場所へ移ることを示す」と表現されているとも言える。
どちらにせよ、コードのステートメントをカバレッジの観点で捉えた場合、両者に差異はないため、ISTQB/JSTQBでは同義として扱って良い。といったニュアンスが欲しい。
(■) 「網羅した判定数を全ての実行可能な判定数で割った数」は間違い。ステートメントテストからコピぺして修正し間違えたな。また判定数と表現すると、何かの回数かと思う。デシジョンで統一したい。だから「網羅したデシジョンの数を全てのデシジョンの数で割った値」としたい。最後は数でなく「値」にすること。
(■)「デシジョンテストは、デシジョンポイントを通り、特定の制御フローに続くため、制御フローの一形式である」ではおかしい。followを「続くため」と訳すからおかしな文になる。「デシジョンテストは、制御フローの一形式であり、デシジョンポイントを通過する特定の制御フローに着目して行う」ではどうか。
P47〜P51
(※) この部分は適切に訳せています。
P52 テスト組織と独立性
(□) 「効率が上がる」は「効果的である」または「有効性が上がる」にしたい。一般に、効果は上がる(品質は上がる)が、効率が上がる(少ない工数や予算で同程度の品質が得られる)かどうかははっきりしないはずだ。また、数行ほど下ではeffectivenessは有効性と訳しているので、それと整合させた方がいいだろう。
(□) 「一般に、複雑な」は「一般に、大規模で複雑な」としておきたい。
(□) 「先入観がないため、異なる欠陥が見つけられる」というのは言い過ぎだ。「他のいろいろな欠陥を知っており、先入観がない」と言っている。
(■) 「システムの仕様策定中や実装中に想定通りかを検証できる」ではちょっとニュアンスがおかしい。「システムの仕様策定や実装の間であっても、前提条件を検証できる」かな。テストそのもの(テスト対象の検証)ではなく、テストのreadinessとしての前提条件の検証が開発と並行して行えることの利点を言っている。
(□) 「ビジネスやドメインのエキスパート、インフラストラクチャやITの運用担当者」と表現したほうが適切だ。
P52 テストリーダと担当者の作業
(□) roleを「職務」と訳しているが、他との整合性から「役割」で統一すること。
P53
(■) 「他の人が実施したテストをレビューする」ではおかしい。やはり「他の人が開発したテストをレビューする」が正しい。「実施した」だと実行後となるが、普通は実行前にレビューする。
P54 テスト計画作業
(■) マスターテスト計画とレベルテスト計画の両方がmustといったニュアンスで訳されているが、それでは基本的なテストプロセスでの記述と整合しない。「そして」が余計だ。「マスターテスト計画で文書化することもあるし、テストレベルに応じて個別のテスト計画として文書化することもある」といったニュアンスでないとおかしい。
(□) 「連続的な活動」より「継続的な活動」の方が一般的だ。
P54 テスト計画策定
(■) 「何をテストするか、...」の項目が訳がおかしい。というか古いシラバスのままか。終了条件はもっと上段で定義済みだ。「何をテストするか、どんな役割でテスト活動を実施するか、どのようにテスト活動をすべきか、どのようにテスト結果を評価するかについて意思決定する。」が正しい。
(■) 次の項目。「分析と計画」ではなく「分析と設計」だ。
P54 開始基準
(■) ここはavailabilityを「可用性」と訳すと誤解しそうだ。readinessと対等なので、availabilityは入手可能といった意味で捉えた方がいい。まだ手元になくてもよくて、いつでも入手できる状況になっていることを言っている。readinessはいつでも使える状態になっていること。availabilityは「xxxが入手可能であること」、readinessは「...が準備できていること」と表現したい。
続きは後日。
