JSTQB Foundationのシラバスと用語集をもっと整備してほしい。(4)
【2011/05/17追記】この記事はちょっと古いのできれば
「FLシラバスのレビューメモ」も合わせて参照ください。
その前にrabbit2goさんの記事がすごい反響ですね。「頑張るほどに問題の本質が見えなくなる」の記事です。少しあやかろうと思います。JSTQBのシラバスを頑張って読んでいるのですが、問題だらけでなかなか本質が見えてきません。
これまで、以下の内容で書いている。
【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)がはっきりしない。
【4】JSTQB Foundationのシラバスと用語集をもっと整備してほしい。(3)
(8) 運用プロファイル(operational profile)
(9) 不十分な保守性 (insufficient maintainability)
(10) and の訳し方
(11) 典型的な終了基準の「完全性の値」とは
(12) 静的解析ツールとモデリングツール
では、引き続いて気づいた点を3点ほど挙げておこう。JSTQB Foundationのシラバスについての指摘だ。
(13) テスト終了作業(Test Closure Activities)は訳語を変えるべき。
前々回、「(5) テストプロセスが分かりにくい」ことを書いたが、それに関連して、テスト終了基準とテスト終了作業が似ていて紛らわしいという問題がある。そのため、プロセスを間違って理解してしまうリスクもある。同じ終了でもISTQBの原本では、前者の終了基準はexit、後者の終了作業はclosureで使い分けられている。終了基準(Exit Criteria)に対して、「テスト終結作業(Test Closure Activities)」と訳して、もっと明示的に区別すべきであったと思う。
PMBOKなどプロジェクト管理の標準でも、「立ち上げ」の作業に対して、「終結」の作業が定義されるし、SWEBOKでも「終結」(Closure)を用いている。現在のJSTQBの終了基準、終了作業という表現では、おそらく、終了基準の判定を行って終了していいと判断されたら、終了作業に進むものと誤解している人も多いだろうと思われる。これは正確な理解ではない。最後のテストレベル(通常、受け入れテスト)の終了基準を満たしたとき、また各テストレベルでコスト要因や期間要因でプロジェクトが継続できないとき、終了作業(＝テスト終結作業)に進むことになる。次のシラバスでは、是非、テスト終結作業に変更してほしい。
【2011/04/09追記】JSTQBの最新シラバスで確認したが対応はされなかった。
(14) シラバス2010(Foundation Level Syllabus (2010).pdf)のインデントが壊れている。
ISTQBからダウンロードした最新のシラバスだが、PDFにきちんと変換できていないようだ。インデントが壊れていて誤解のもとだ。早く修正したものをアップロードしてほしい。例えば、各テストレベルでテストベースとテスト対象がリストアップされるようになったが、インデントがおかしいため、個々の項目が何なのか分かりづらくなっている。それでもじっと眺めれば、インデントがおかしいとすぐに気が付く。
しかし、一般的なレビューのアクティビティの説明では、インデントの壊れ方が尋常ではない。シラバスV1.1.0で6個だったアクティビティが、シラバス2010で12個になったと勘違いしてしまった。以前の記事にもそれを大きな変更点として紹介してしまった。(※記事は修正しておきました。)
ついでだから、一般的なレビューのアクティビティがシラバス2010でどのように変更されたか説明しておこう。これまで「レビューミーティング」というアクティビティであったものが、「検査・評価・記録(レビューミーティング)」という長い名前のアクティビティに変わった。これは、ミーティングという物理的な会議だけでなく、グループ内でのメールや情報共有といった電子的なコミュニケーションでの議論の結果も包含させたためのようだ。ネーミングに苦心したのだろう、括弧書きで「(レビューミーティング)」が添えられている。
【2011/04/09追記】JSTQBの最新シラバスでは、インデントはきちんとできていた。ISTQBのシラバスの方は未確認。
(15) JSTQBのシラバスの翻訳はもっと精度を上げるべき。
本当にいらいらさせられるのだが、バイブルとすべきシラバスの翻訳がおかしいために、非常に苦労する。またその誤訳を受けた2次的な市販本も、その誤訳をさらに変な方向に曲解してしまっている。いくつか例を示しておこう。たとえば、[2.2レビュープロセス」の1ページのなかに致命的な誤訳が4つあった。市販の教科書本も照会してみたが、その誤訳をなんとかつじつまが合うようにとさらに傷を広げている感じなのだ。
【15-1】レビューミーティングの説明に「結果を記述したドキュメントや議事録をもとに（公式性の高い場合）、議論し、議論を記録する」とある。これを受けて教科書本では「ミーティングが繰り返して行われるときは、議事録をもとに議論することもあります」と説明されている。原本のニュアンスはそうではないだろう。議事録をもとに議論することが、テストべース以上に強調される訳がない。原文は「Discussing or logging, with documented results or minutes (for more formal review types)」だ。「議論したり、ログを残すこと。公式性が高い場合には、結果を文書化したものや議事録を伴う」と書かれている。前回の議事録をもとに議論することを強調している訳ではないだろう。公式性が高い場合には、単にログではなく、議事録などにきちんと結果を記録することを言っている。ログと議事録などのドキュメントを使い分けているのは、レビューが一般の会議のようなミーティングだけでなく、コードインスペクションやウォークスルーなどの形態も包含しているためだ。
【2011/04/09追記】JSTQBの最新シラバスでは、若干考慮はいただいた。「議論を行い、結果や議事内容を文書として記録する。(より公式なレビュータイプの場合)」に変更されていた。30点くらいだ。「より公式な」は議論には係らないで、文書として記録するのみに係るようにしないといけない。
【15-2】マネージャの説明に「レビューを実施することを決め、実施のスケジュールを立て、レビューの目的が適切かどうかを判断する」とある。教科書本でも「レビューの目的が適切かどうかも判断します」と同じ口調で書かれている。レビューの実施が決まって、スケジュールも決まっているのに、それから目的が適切かどうかを判断していいのか。遅すぎるだろう。レビューの実施を決める段階では目的は明確になっていないといけない。原文は「determines if the review objectives have been met.」だ。「レビュー目的が合意されたかどうかを判断する」と言っている。レビュー目的は、作成者や人選されたモデレータなどを含めて改めて合意することを言っている。マネージャが単独で目的を決めるのではなく、むしろモデレータが主導して目的を合意し、マネージャがそれを決定事項として明らかにし、キックオフに臨んで目的を説明するという流れが適切だ。レビュープロセスの解説の冒頭にも「合意したレビューの目的に応じてレビューの形態を決める」とある。目的が適切かどうかではなく、目的が合意されたかどうかである。
【2011/04/09追記】JSTQBの最新シラバスでは対応いただけなかった。残念だ。
【15-3】モデレータの説明に「必要なら、いろいろな視点から物事を考える。レビューの成功、不成功はこの人に拠ることが多い」とある。教科書本でも「いろいろな視点からものごとを考えることもあります」と同じような口調だ。「いろいろな視点から物事を考える」では、当り前すぎるだろう。原文は「If necessary, the moderator may mediate between the various points of view and is often the person upon whom the success of the review rests.」だ。「レビューを成功に導くために、必要なら、いろいろな意見の仲介・調整を行う」ことを語っていると思う。いろいろ考えていいし、意見を言ってもいいのだが、ここではレビューアらの意見が競合するような場合に、仲介・調整することを言っている。
【2011/04/09追記】JSTQBの最新シラバスで対応いただいたようだ。「必要なら、様々な意見の仲裁を行う」と修正されていた。
【15-4】レビューアの説明に「レビューアはいろいろな分野や、レビュープロセスの役割を代表する人として選ばれ、あらゆるレビューに参加する」とある。教科書本でも「同じ目的をもつすべてのレビューに参加します」としている。あらゆるレビューに参加するではおかしすぎる。関係するレビューにだけ参加すればいいはずだ。原文は「Reviewers should be chosen to represent different perspectives and roles in the review process, and should take part in any review meetings.」だ。「レビューアとしては、レビュープロセスにおいて異なった視点と役割をもった人が選ばれるべきであり、レビューミーティングでは、その視点と役割を担当すべきである。」ということだと思う。あらゆるレビューに参加するのでなく、参加するミーティングでは、当然、個々のレビューアに責務として与えられた視点と役割を担当することをいっている。担当外のミーティングに参加する必要はない。
【2011/04/09追記】JSTQBの最新シラバスではまだおかしい。対応いただかなかったようだ。残念だ。JSTQBの訳者はanyを「あらゆる」と訳す癖があるのかもしれない。用語集でも似たような間違いが見られた。
わずか1ページの中にこれだけおかしなところがある。たしかに原文の曖昧さもあるが、翻訳したあとにもう少し論理的に考えてみれば分かることだし、まともにレビューすれば分かることだと思う。きっとレビューも大して行っていないのだろう。レビューの解説をレビューしていないとは、ちょっとはずかしいことだ。シラバスの欠陥は、非常に"高価な欠陥"になることを、もっと意識して欲しい。
今日はここまでとしておこう。
