JSTQB Foundationのシラバスと用語集をもっと整備してほしい。(3)
【2011/05/17追記】この記事はちょっと古いのできれば
「FLシラバスのレビューメモ」も合わせて参照ください。
JSTQB Foundationの模擬問題を360問ほど作成し、ソフトウェアテスティング基礎コース(http://squaring.jp/EC03-JSTQB/)として提供を開始した。当然、JSTQBが公開しているシラバスと用語集をベースにしており、これらをかなり読み込んだ。その際に気づいたシラバス(V1.1.0、2009年改訂版)と用語集に関する問題を提示しておくことにした。以下の記事の続きだ。
【1】JSTQB Foundationの模擬問題360問(過去問100問を含む)を作成してみた。
【2】JSTQB Foundationのシラバスと用語集をもっと整備してほしい。
(1) シラバスが古い。
(2) IEEE 829標準の参照も古い。
(3) 用語集が不十分だ。
【3】JSTQB Foundationのシラバスと用語集をもっと整備してほしい。(2)
(4) 同義語が多い。
(5) テストプロセスが分かりにくい。
(6) リスク管理と動的リスクベースアプローチの扱いがはっきりしない。
(7) 機能テスト(functional test)と機能性テスト(functionality test)がはっきりしない。
もう大して指摘事項は残っていないが、引き続いて気づいた細かい点を挙げておく。
(8) 運用プロファイル(operational profile)
operational profileは、SWEBOKでは運用プロフィールと訳されている。JSTQBでは操作プロファイルや運用プロフィールと訳されている。個人的には「運用プロファイル」で統一してほしいと思っている。プロフィールはフランス語だ。プロファイルは英語だ。どうして、こんなところでフランス語に拘るのだ。プロフィールだとどうしても人物紹介という感じになる。もっと犯罪捜査で人物を絞り込む際に使われる「プロファイル」の方がいい。その方が格好いいし、本来のoperational profileの意味としても、近いはずだ。あるいは一般的ではないかもしれないが、「運用分析表」と訳してくれた方がまだいいかもしれない。これはJSTQBというより、SWEBOKでの訳がまずかったのが原因かもしれない。ただ操作プロファイルといったり、運用プロフィールといったり、不統一なのは論外だ。
【訂正】最新の用語集(2.0)では見出し語は「運用プロファイル」に修正されていました。失礼しました。ただ、まだ一部の説明の中に残ってはいます。
【2011/04/09追記】最新の用語集でもまだ、operationalを「運用」と「操作」で一貫性がなく、用いられている。運用テスト、運用プロファイルの解説においても「操作」を使いたがっているようだ。もっと徹底してほしい。シラバスにおいても「運用」とすべきところが「操作」のままの箇所もあるようだ。
(9) 不十分な保守性 (insufficient maintainability)
JSTQBは、なぜか、保守の不十分性と訳している。どうみてもソフトウェアの品質特性の1つである保守性が不十分である状態を言っている。保守の不十分性と訳すと、保守の作業で足らないものがあるように誤解してしまう。足らないのは、保守での作業ではなく、テスト対象が具備している保守性が劣っていること言っている。コードが理解しにくいとか、変更が容易でないとか、テストしにくいというようなことだ。
【2011/04/09追記】最新のシラバスでもまだ「保守の不十分性」のままだ。残念だ。私の主張していることが間違いなのか。
さらにいうならば、この問題のステートメントは、静的テストが動的テストよりも容易に見つけられる欠陥についての説明においてである。原文とJSTQBの訳を並べてみる。
- deviations from standards (コーディング規約の不遵守)
- requirement defects (要件の欠陥)
- design defects (設計の欠陥)
- insufficient maintainability (保守の不十分性 ※前述)
- incorrect interface specifications (不正なインタフェース仕様)
【2011/04/09追記】コーディング規約の不遵守の方は、最新のシラバスでは「規格からの逸脱」に変更されていた。80点だ。standardは「標準」と訳さなければならない。用語集にも登録されているからだ。
シラバスのこの欠陥によって、市販の教科書本でも保守の不十分性、コーディング規約の不遵守が踏襲されてしまっている。これではいわゆる"高価な欠陥"の典型になってしまう。早急に修正をお願いしたい。
(10) and の訳し方
どうも原文でのandを日本語で表現するときに誤解しそうなものがいくつかある。どちらかというとorで置き換えて表現した方が適切だ。たとえば、以下のものだ。
冗長でもこのように分離して、原文のandをorに置換して表現した方がいい。契約受け入れテストと、規定受け入れテストは別のものであるにも関わらず、むりやり総称的に「契約および規程による受け入れテスト」と呼ばせようとしているように見える。アルファテスト、ベータテストは個々にはこのように呼ぶが、総称的に「アルファ、ベータテスト」と呼ぶ必要はないだろう。また細かいが、規程ではなく、規定の方が訳語として適しているように感じる。【2011/04/09追記】最新のシラバスでは「アルファテスト、ベータテスト(フィールドテスト)」、「契約受け入れテスト、および規定受け入れテスト」のように修正いただいた。また規程から規定に変更もされていた。満足だ。
(11) 典型的な終了基準の「完全性の値」とは
シラバスで代表的な終了基準として「コード、機能性、リスクのカバレッジのように、完全性の値」が筆頭に挙げられている。完全性の値とは何だ。シラバスを読んで、すんなりと理解できる人はいないのではないだろうか。原文では「Thoroughness measures, such as coverage of code, functionality or risk」のようだ。Thoroughnessは、SWEBOKでは「徹底度」と訳している。これならまだ分かりやすい。市販の教科書本においては、「全体の値がわかり、どこまでテストを実施したかが分かるもの」といったニュアンスで解説されているが、これでもまだ足りない。coverage(カバレッジ)だけでは表現しきれないため、thoroughness(徹底度)を持ち出しているのだ。「コードカバレッジ、機能性、リスクなど、実施したテストの徹底度を計量できるもの」ではどうだろうか。おそらく、coverage(カバレッジ)という表現は、構造をもった対象の要素に対して網羅性を単純に計数できるものに用いている。一方、機能性(機能に対するセキュリティ、正確性、相互運用性など)やリスクは程度を表現するものなので、網羅性を単純には計数できない。コードカバレッジなら行や分岐を単純に計数して50%、100%のように明確に判断できるが、機能性やリスクの網羅性については、評価の明確な数式がある訳ではないので、達成度というべき徹底度(thoroughness)という概念を持ち出しているのだ。
(12) 静的解析ツールとモデリングツール
静的解析を支援するツールのカテゴリに静的解析ツールとモデリングツールが並列に記述されているが、静的解析ツールの範囲がどうも明確でない。コードの静的解析ツールということだろうか。静的解析はコードだけでなく、要求や設計のモデルについても行えるはずである。そうすると、要求や設計のモデルについては、静的解析ツールもモデリングツールも適用可能となる。ISTQBの原本から不明確だ。コードに限定した静的解析のツールと明言しておくか、あるいは逆に、要求や設計のモデルについての静的解析も含めるなら、コードに限定しない表現をとるべきだろう。
今日は、ここまでとしておこう。続きは後日。
