ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

"test quality into the product" という不思議な言い回しをどう解釈すべきか

 miwaさんのこちらのツイートに、ソフトウェア品質・テスト関係の方々がいろんな意見を寄せていました。ぜひスレッドを追ってみてください!

いろんなところに現れる常套句

 上のツイートは、『実践アジャイルテスト』からの引用です。原著『Agile Testing』と合わせて、もう少し引用してみます。

An old saying in the testing business is, "You can't test quality into the product." This is, of cource, true of agile development as well. We feel you can't deliver high-quality software without following some fundamental practices.
テストのビジネスのことわざで、「製品の中で品質をテストできない」 というのがあります。これはもちろんアジャイル開発においても真実です。いくつかの基本的なプラクティスなしには、高い品質のソフトウェアは作れないと感じています。

 日本語も理解が難しいですが、原文なら理解できるかというとそれも難しい。
 似たような表現は随所に現れます。
 『テストから見えてくる グーグルのソフトウェア開発』とその原著『How Google Tests Software』から引用。

"Quality cannot be tested in" is so cliche it has to be true.
<品質はテストできない>という言葉はとても使い古されているので、真実であるに違いない。自動車からソフトウェアまで、最初の設計段階から品質が作り込まれていなければ、製品は決してまともなものにはならない。

 『実践ソフトウェア・エンジニアリング』*1とその原著『Software Enineering - A Practitioner's Approach』から引用。

As they say, "You can't test in quality. If it's not there before you begin testing, it won't be there when you're finished testing."
「品質はテストできない。テストを始める前に存在しなかった品質は、テストが終わったところでやはり存在しないのだ」という言葉の通りだ。

どう解釈するか

 少なくとも、3つの解釈が考えられます。

  1. 品質は、テストより前に作り込むべきものである。
  2. 品質を上げるのはテスト自体ではなく、その後の活動である。
  3. 品質そのものはテストできない。

 辰巳さんからは、William Edwards Deming氏の言葉を教えていただきました。
 『Out of the Crisis』*2からの引用(翻訳筆者)です。

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “**You can not inspect quality into a product.”
品質は、検査によって改善されるわけでも、約束されるわけでもない。検査では遅すぎるのだ。良いにせよ悪いにせよ、品質はすでに製品に備わってしまっている。

 test(テスト)ではなくinspection(検査)という言葉に変わっていますが、意味合いは同じでしょう。
 この文章や、その引用の文章周辺を見ても、解釈1が一番原意に近く、広義には2も含む、みたいに考えられるのではないでしょうか。

test quality into って何!?

 ただそれでも、「test quality into the product」ってどういうニュアンスなのよというモヤモヤは残ります*3。日本人(主語デカ)は、動詞+副詞/前置詞型の句動詞に弱いんだよ!

 Deming氏の引用にも出てくる*4、統計的品質管理のHarold F. Dodge氏のこの言葉がヒントになると思います。

You cannot inspect quality into a product; it must be built into it.

 build quality into a product と inspect quality into a product を対句と捉えることができます。
 build inが「作り込む」、push inが「割り込む」であるように、inやintoがもたらす「~込む」という語感。これをtestにくっつけることで、「テストを通じて品質を練り込む」みたいなニュアンスを表現しているのでは、というのがわたしの仮解釈です。どうでしょうかね?

 ということで、「テストの段階になって初めて品質を作り込もうなんて考えちゃいかんよ」と、何十年も前から言われ続けていることをあらためて噛み締めて、眠ることにしましょう。

Into The Fog

*1:この部分はわたし自身が、『グーグルのソフトウェア開発』の翻訳を参考に訳したので、完全に文責筆者ってやつです・・・。

*2:Amazonで新品の取り扱いがある・・・。

*3:この表現について社内のネイティブに聞いてみたところ、「It is awkwardly worded」というコメントをいただきました。ネイティブスピーカーn=1の意見で正しいというつもりはないけれど、信頼できる英語話者と考えられる方です。

*4:ググっているうちに、「In search sites, his name always come with Deming’s.」という文章に出会って笑ってしまった。確かにセットでした。

【読書メモ】発想の組み合わせが面白い本2冊

 ショートショートの大家・星新一は、その膨大な作品のもととなった発想の源泉について、「アイデアは、異質なものを結びつけるところから生まれる」と語っています。また、「技術革新」と訳される「イノベーション」は、実は既存のモノやコトの組み合わせから生まれたものが多いとも言います。

 今日は、「おお、いい組み合わせだな~」って思った本を2刷紹介します。
 イノベーションの話は出てきません。

おとぎ話×SF、『百万光年のちょっと先』

 『このライトノベルがすごい! 2018』で紹介されていた本です。
 ライトノベルは、本当に好きになれるものとそうでないものの落差が激しく、かつ表紙が40代男性にはだいぶ厳しいものが多いという欠点はあるのですが、やっぱり面白いものは面白い。

 『百万光年のちょっと先』は、型落ち気味の自動家政婦が、幼い少年に紡ぐ物語。宇宙や未来、この世界のどこかを舞台にした小さなお話の集まりです。

 SF的で、かつ短編といえば、星新一や筒井康隆や眉村卓の作品が思い出されますが、『百万光年のちょっと先』は、そこにおとぎ話のエッセンスを加えています*1。小さなエピソードから醸し出される、不思議だったり、寓意だったり、物悲しさだったり。

 正直最初は、SFとしてはちょっとライトすぎるなと感じました。また、「十億年の時間を要し、建造に関わった星間文明が百回も代替わりした末に完成」といったやたらと大げさな数字も安易に感じて、抵抗がありました。

 ですが、ふと思い出すのです。そうだ、これは「こどもに聞かせるおとぎ話」なのだと。
 おとぎ話だから、豆の木が天まで届いたり、お椀に乗って旅する侍がいたり、極端なことが当たり前に起きてもいいし、その根拠や背景や理屈を丁寧に解説することは、蛇足でしかないのですね。

 それぞれのお話にワクワクするようなガジェットが登場するのも魅力です。たとえば、「宇宙のあらゆる知識を詰め込んだような究極の百科事典」とか、「亜光速単原子生物や超弦生物までを展示している宇宙動物園」・・・。

 そこで起きる小さなお話を、ぜひ楽しんでみてください。
 わたしが特に気に入ったエピソードは、『夢見るものを、夢見るもの』と『最後の一冊』です。

落語×哲学、『落語―哲学』

 タイトルがそのまんまですが、落語と哲学という異色の組み合わせ。
 と思うのですが、本書を読み進めていくとたしかに、落語には謎めいた、不条理な話が紛れ込んでいることに気づきます。紹介されているネタでいうと、

  • 『芝浜』: 大金を拾った魚屋におかみさんが、それが夢だったと信じ込ませるおはなし。
  • 『粗忽長屋』: 行き倒れの男の身元が熊五郎かどうかを、熊五郎自身を呼んできて確かめようとするおはなし。
  • 『あたま山』: 頭に桜の木が生えたり池ができたりしてしまい、そこで人が花見や釣りをすることを嘆いた男が、その池に身を投げるはなし。

のように、単なる笑い話で片付けられない違和感を含んでいます。

 たとえば『芝浜』について、筆者は2つの視点で分析を試みています。
 1つは、多世界解釈

この噺は、コペンハーゲン解釈ではなく、多世界解釈によって、さらに深みを増す。あるいは、この噺の背景には、多くの離接肢(可能世界)が隠れていて、芝浜という噺の内容が、現実になった離接的偶然として屹立しているともいえるだろう。

 大金を拾わなかったら、拾った金を散財してしまっていたら、そして3年働いた後に酒を飲んでしまったら。起こり得たかもしれないけれど、この世界線では起こらなかったたくさんのことを想像させるのが、この噺の魅力ではないかとしています。

 もう1つは章タイトル、「この世は夢ではないのか」*2という視点。

この一日で、熊は、何と三度起こされ、おかみさんも熊に一度起こされるのだ。眠りに眠った一日だといえるだろう。だからこそ、この日は、二人のあいだで、夢の現の境目が消えかけていた。どこまでが現実で、どこからが夢なのかわからなくなる条件は、十分そろっていたのである。 

 噺の中に、実は夢自体は一度も出てこないながら、睡眠と覚醒を繰り返す中、眠りの象徴である「海」から、覚醒の象徴である「陸」に財布が上がってきているという解釈が提示されます。

 一体、落語にそこまで深い意図が込められているのか。深読みに深読みを重ねていないか。
 そう感じる部分もけっこうあります。ですけど、落語のネタを呼び水にして、世界や人間のあり方を考えていく、話もやたらと広がっていく、それが面白いからオッケーです。

 あらためて、落語をちゃんと見てみたいなって思いました*3

おわりに

 組み合わせの妙が面白い2冊を紹介しました。
 なおこの記事自体も、全然関係のない2冊の関連を見つけて、組み合わせて紹介するという試みをしてます!

*1:星新一にもその要素はありますね。というかそれをテーマにした作品集自体があった気がする。

*2:『胡蝶の夢』的な作品って、『マトリックス』『ザ・セル』『インセプション』という映画や、小説だと『完全なる首長竜の日』などたくさんあって使い古されているはずなんだけれど、なぜか惹かれてしまいますね。『百万光年のちょっと先』にも、これに属するエピソードがあります。

*3:落語といえば『昭和元禄落語心中』も面白いんですが、『夏子の酒』でも有名な尾瀬あきらさんの『どうらく息子』もとても良いです。久しぶりに読もうかなあ。

テスト管理ツールにおけるテストケースのグルーピング

はじめに

 テストケースの数が多くなってくると、それらをグルーピングする必要が生じます。
 たとえばExcelテスト管理パラダイムであれば、ワークシートに「大分類」「中分類」「小分類」という列を設けて、階層構造を表現することが可能ではあります*1

 では、テスト管理ツールではどのようなグルーピングが理想的でしょうか?

 なお本記事では、テストケースを管理する目的を以下とします。

一貫したルールに沿ってテストケースを体系だてることで、テストセットの全体像の把握や、テストケースの取捨選択が効率的に行えること。

結論

 開発項目をツリーで表現してテストケースを分類したうえで、テストタイプやテスト目的でタグ付けして管理すると、見通しがいいんじゃないかね。

f:id:kz_suzuki:20220109195710p:plain
ツリー構造とタグ付け

本文の前に

関連記事

 この記事を書くキッカケとなったのは、きんぢさんの以下の記事です。 qiita.com

 またこの話の前提として、テスト管理ツールにおけるテストケース管理について、以下を読んでいただけると。 www.kzsuzuki.com

言葉の定義

 テストスイート(test suite)は、JSTQBでは以下のように定義されています。

特定のテストランで実行されるテストスクリプト、またはテスト手順のセット。

 テストケーススイート(test case suite)、テストセット(test set)もその同義語とされています。
 定義上「テストケース」という言葉すら出てこず、ちょっと不便なので、この記事では

テストセット: 特定のテストランで実行されるテストケースの集合。

という意味で使います。で、ついでに以下を定義しておきます。

フルテストセット: 定義されたすべてのテストケースの集合。

ツリー構造とタグ付け

 多くのテスト管理ツールでは、テストケースの管理方法として、「ツリー構造」「タグ付け」*2をサポートしています*3

ツリー構造による管理

考え方

 OSのファイル管理におけるディレクトリのように、フォルダを分けてテストケースを管理する方法です。フォルダには、テストケースだけでなく、別のフォルダを入れ子にすることもできます。
 あるテストケース・フォルダは、1つのフォルダにしか所属することができないため、ツリー構造が形成されます。

長所

 結局ヒトは、ツリー構造・階層構造にわかりやすさを見出すものです。扱う対象が大きいほど、divide and conquerってなもんで分割していく。それはツリー構造になっていくはずです。思えば上述のExcelテスト管理パラダイムにおける「大分類」「中分類」「小分類」も、ツリー構造によるグルーピングですね。
 ツリーがきれいにできていれば、「フィーチャにA関するテストはこのディレクトリより下に全部集まっている」ということが一目でわかるようになります。

短所

 あるテストケースが1つのフォルダにしか所属できないという性質から、融通がききづらいのが短所。ツリーを構成する際には、MECEと一貫性に配慮が必要です。

 MECE(もれなくダブりなく、Mutually Exclusive, Collectively Exhaustive)から考えてみましょう。
 CEの方は、万能の「その他」でしのぐ*4としても、あるテストケースが1つのフォルダにしか所属できない以上、フォルダ同士はMEでなくてはなりません。
 Exclusiveでない、つまり「ダブりあり」だと、そのダブった属性を持つテストケースをどちらに配置すればいいかわかりません。「2021年度」フォルダの下に、「第3四半期」と「下半期」というサブフォルダが共存してはいけないわけです。

 また、分類の軸に一貫性がないと、混乱をきたします。
 極端な例ですが、「入力バリデーションチェック」と「リグレッションテスト」みたいなフォルダが共存してしまうと、「値のバリデーションチェックを行うリグレッションテストはどっちに入れればいいのか」ということになってしまいます。

タグ付けによる管理

考え方

 所属先を1つしか指定できないツリー構造に対し、タグ管理では1つの対象に複数のタグを付与することができます。たとえばFirefoxのブックマークやEvernoteのノートは、タグで管理することができます。

長所

 ツリー構造のような、「親は一人だけ」の制約がないことが最大のメリットです。
 1つのテストケースに対し複数のタグを与え、それぞれのタグで検索することができます。これによってたとえば、「性能テスト」といったカットでグルーピングができるわけです。

短所

 MECEを自然と意識させるツリー構造と比べて、タグは自由に作れます。この自由さは、無秩序と表裏一体です。そして一貫性のないタグの増殖は、タグ付けの煩雑さと検索性の低下につながります
 タグ付けによる管理においては、タグの作成ルールが必要です。

おすすめプラクティス

 ここからは完全に私見です(そしてこれまでも完全に私見です*5)。

 ツリー構造に合うのは、テスト対象となる開発項目、またはそれをテストのために整理しなおしたテストアイテムだと考えています。DevチームとQAチームがゆるやかにでも分かれている場合でも、両チームの意識を合わせやすいです。開発項目というのは、テスト以前に、ある程度ツリー構造化されていることも多いからです。
 ただし、階層をあまり深くし過ぎると逆に管理しづらくなるので、「どこまでを階層構造で表現し、どこからをテストケース名で表現するか」というポリシーは決めておいた方がいいでしょう。
 一方タグ付けは、テスト目的やテストタイプによるグルーピングに用いるとよいでしょう。

 ツリーとタグの組み合わせによって、開発項目の階層構造を横断する形で、目的に応じたテストをフィルタすることができます*6
 最初の絵は、これを図示したものです。

f:id:kz_suzuki:20220109195710p:plain
ツリー構造とタグ付け(再掲)

 Full Test Setには、定義されたすべてのテストケースが所属しています。これは開発項目のツリー構造に関連づいています。
 一部のテストケースは、タグ(●で表現)が付与されており、たとえば「スモークテスト」を簡単に特定することができるというわけです。

ただし・・・

 注意点が2つあります。

ツールの性能も大事

 グルーピングは、テストケースが多くなればなるほど重要になります。
 一方で、テストケースが多くなるほど影響を受けるのが、テスト管理ツールの性能です。
 テストケースのツリー間移動、タグの付け外し、そして検索とフィルタ。いくら論理的にはきれいな構造を作ったとしても、これらの機能がモタつくようでは、せっかくの構造も使い物になりません。

グルーピングの先にあるもの

 テストセットの中から、テストケースをグルーピングする方法について述べてきました。
 一方、テストケース同士、テストセット同士の関連を記述する方法については、何も述べていません。テスト対象が大きくなると、この関連の表現がより重要になってくると考えられます。

おわりに

 テスト管理ツールを使って、テストケースをグルーピングする方法について書きました。

 ところで、前回の記事を書いたあと、このようなツイートをお見かけしました。

 たしかに、「テスト実行者を型にはめて縛る」という印象はよくわかります。これって、チケット管理ツールを導入した際にも感じたことではないでしょうか?

 ただ使っていくうちに、わかってきます。
 チケット管理ツールもテスト管理ツールもただの「箱」であって、いろいろできるけど、結局のところ「運用ルールを自分たちで作らないと、グチャグチャになる」ものです。グッドプラクティス的なものは出てくるでしょうけれど、どこの現場の事情・文化にも合う完璧なプラクティス*7ってのは難しいんじゃないかなと思います。

Assembled in the USA

*1:なおこのプラクティスは、にしさんにより「固定3レイヤー法」と命名されています。「考える抽象度が固定されてしまう」との注釈付きで。

*2:タグは「ラベル」と呼ばれることもあります。

*3:Evernoteは、タグ自体をツリー構造にできる。もしかしたらこれが最強なのか?

*4:「その他」は整理されていないゴミの集積所になるリスクがあるので注意。

*5:いせりさんがツイートされたよう100万オーダのテストケースという規模は、わたしは未経験です。想像つかない・・・。

*6:完全に余談ですが、わたしのEvernoteは読んだ本のメモが多いので、「IT技術」「科学」「語学」といった「分野」によるツリー構造と、本に対する評価タグで管理しています。これによって、「2021年に読んだ科学関連の本で、★が4つ以上のもの」といった検索できるようになっています。ツリー×タグは強い。

*7:「銀の弾丸はない」は意地でも言わない。

テスト管理ツールにおけるテストケース管理

 この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2021」の26日目の記事(自称)です。
 きんぢさんのブログ記事、「テストケースを束ねしもの -とあるテスト管理ツール開発者の気づき-」に触発されて、テストケースの「束ね方」について、私見を書こうと思います。

qiita.com

 ただその前に、前提となる「テストケースとテスト実行の分離」の一般的な*1考え方について整理してみます。というのも、テスト管理ツールを知らない人にとって、その理解が最初の障壁になりがちだと感じるからです。

Excel1件1行型テスト管理の問題点

 Excelをはじめとするスプレッドシートによるテスト管理では、こんな表が登場します。

f:id:kz_suzuki:20211230001029j:plain

 テストケースの内容と、テスト実行の結果が、1行で管理されていますね。
 つまり、テストケースとテスト実行が1:1で結合した構造ということができます。言い換えると、1つのテストケースに対して、テスト実行の情報を1つしか持てないということです。

 模式的に描くと、以下のようになります。

f:id:kz_suzuki:20211230001014j:plain

 この形には、2つの問題が内在しています。

問題点1: テスト実行が失敗した場合の管理が煩雑になる

 あるバージョンにおけるテストを考えてみましょう。
 テストケースが1回目の実行で失敗すると、Excelの「結果」欄にたとえば「×」などと書くことになるでしょう。
 失敗の原因がテスト環境の不備だったとして、それをあらため、テスト再実行。今度はうまくいきました。Excelのテスト結果を「〇」にしましょう。
 ・・・いえ、それだと失敗した履歴が消えてしまうので、「×→〇」と書いておきましょうか。
 「実施日」欄にはどう書きましょう。「2021/12/24」と「2021/12/25」、2回分の実行日を書いておきますか?

f:id:kz_suzuki:20211230001032j:plain

 すでに地獄感がありますよね。
 テスト結果に「〇」「×」以外の「×→〇」という新しくて気持ち悪い値が出てきたうえに、今後も「×→×→〇」など、どんな値が出てくるかもわかりません。せっかく表計算ソフトで管理しているのに、これでは集計が大変そうです*2

 あるテスト期間で行うテストケース1つに対して、テスト実行の回数は0か1ではなく、「0以上」なのです。それを無視して、複数の実行を1つの記録に押し込もうとすると、どんどんぐちゃぐちゃになっていくんですね。

f:id:kz_suzuki:20211230001017j:plain

問題点2: 複数のバージョンで実行するテストケースの関連が失われる

 Excelテスト管理ではありがちなのが、「前のバージョンのテストケース一覧をコピーして、新しいバージョンをテストケース一覧のベースにする」プラクティス(?)です。
 この際に、コピー元とコピー先の情報の関係が保持されることは、まずありません。まったく同じ内容のテストケースであっても、それを把握するための情報が失われているのです*3

f:id:kz_suzuki:20211230001020j:plain

 上の図でいうと、テストケースAとテストケースA'が実は同一であることがわからなくなります。
 すると、「このテストケースを前回やったのはいつだっけ?」が遡れません。「同じテストケースで過去にも欠陥が見つかっている」といった分析もできなくなりますね。

 またこのコピーによる副作用として、「自分たちがテストケースをいくつ持っているのかわからなくなる」 という問題もあります。バージョンごとに毎度コピーを作っているため、ユニークなテストケース件数がわからなくなってしまうのです。

テスト管理ツールによる問題解決

 2つの問題は、テストケースとテスト実行の関係を多対多で管理することで解決できます。

解決1: テスト実行はそれぞれ別に管理する

 あるバージョンのテストにおいて、1つのテストケースは複数回実行されることを前提にします。それぞれのテスト実行の情報(実行結果、実行日時など)は、独立した別のレコードとして記録されます
 気の利いたテスト管理ツールであれば、各テストケースの最新の結果を、サマリとして表示してくれます。

f:id:kz_suzuki:20211230001023j:plain

解決2: テストケースをバージョンに「割り当てる」

 「バージョンがあって、その中でテストケースを作る」のではなく、「一元管理されたテストセットがあって、バージョンに対してはその中からテストケースを割り当てる」 という考え方になります。

f:id:kz_suzuki:20211230001026j:plain

 これによって、複数バージョンで同じテストケースを行う場合でも、両者の関係が維持されます*4

まとめ

 テスト管理ツールでは普通、テストケースとテスト実行の関係を以下のように捉えます。

  1. テストセットの中からテストケースを選定し、割り当てる。
  2. テストケースは1つのバージョンの中でも複数回実行されうる。

 Excelテスト管理の文化からすると、テスト管理ツールにおける各概念とその関係性に戸惑いを覚えることがあります。が、無意味に難解になっているわけではなく、むしろ合理的な考えに基づいてこの姿になっているということです。

*1:この記事における「一般的な」「普通は」という言葉の意味するところは、筆者が見た範囲でそうなっている、という意味です、ごめん。

*2:もちろん、Excelをがんばって作りこめば、一番最後の文字を取得して最終結果と見なすなどの式は書けるだろう、でもやりたくない・・・。

*3:もちろん、Excelをがんばって作りこめば情報を保持することはできるだろう、でもやりたくない・・・。

*4:細かくいうと、バージョン1とバージョン2では、テストケースAの内容が変更されていることもありうる。普通は、その時点のテストケースの内容がスナップショットして保持されている。しかし依然として、行われたテストケースが同一のアイデンティティをもったものであるという情報は保持される。

『実践ソフトウェアエンジニアリング 第9版』を訳して、日本語の難しさを知る

 『Software Engineering - A Practitioner's Approach - Ninth Edition』の日本語版・『実践ソフトウェアエンジニアリング 第9版』が発売されました。
 わたしは「SEPA翻訳プロジェクト」の1メンバーとして、第3部「品質とセキュリティ」の3章分の翻訳と、周辺の章のレビュアを担当しました。

 メンバーのmasskanekoがアドベントカレンダーを作ってくれたので、記事を一つ書いてみます。
 本書の位置づけや意義については、ET&IoT2021で他のメンバーがヘヴィな発表をしているのでそちらを参照していただくとして、まだ全章読めてすらいないわたしは、言葉の面白さについての雑文をば。

www.slideshare.net

英語より日本語で悩む

 翻訳の専門家でないどころか、素人翻訳者としてすら長いキャリアがあるわけでもない身でえらそーな言い方になりますが、英語で書かれた技術書を翻訳するうえで必要な能力は大きく3つあります。

  1. 原文を理解する英語力
  2. 書かれた内容を咀嚼する知識
  3. 内容を文章に落とし込む日本語力

 1と2に比べて、3は影が薄いです。何せ、日本人の多くは、日本語を不自由なく操れるはずですから。
 でも実際、一番苦労するのは3だったりします。
 「原文が悪文だ」と原著者のせいにしたくなることもありますし、自然言語がそもそもあいまいさを許容していることも難しい問題なのですが、やはり、日本語と英語の文法の特性が大きく違うことが、翻訳を難しくする大きな要因に思えます。

 たとえば、「受動態」「無生物主語」「使役動詞」「関係詞」。
 こやつらは、訳文をぎこちなくさせる主犯格であり、同時にあまたの受験生を苦しめてもいる連中です。ただこういった英語の文法を考えていくと、いつしか日本語の問題に行き着いたりするのです。

 受動態について考えてみましょう。
 以下の文章、どちらが適切に思えますか?

  1. 「テストで摘出したバグのトリアージを行う。」
  2. 「テストで摘出されたバグのトリアージを行う。」

 「バグ」を修飾する言葉が、能動態的な「摘出した」なのか、受動態的な「摘出された」なのかだけの違いです。
 英語なら bugs detected in testing みたいに受動態的に修飾すると思う*1のですが、日本語だと両方許容されるように感じませんか? こんな場面で、ハタと迷うわけですね。
 わたしには、aもbも間違っているようには思えませんが、「何らかのロジックに基づいてどちらか選べ」と言われれば、以下のロジックで選びます。

「バグを摘出した」人と「バグのトリアージを行う」人が

  • 同一なら: a(摘出した)を選ぶ。
  • 同一でないなら: b(摘出された)を選ぶ。

 でも、正しいかどうかはよくわからないので、他の人にもそうすべきとは言えません。

 とまあこんな風に、英語のことを考えていたはずが、いつの間にか「日本語って難しいな!」ってなるのが、翻訳の面白いところです。

「ひっくり返さない」

 10代の多感な時期に身に着けた「英文法」の読解は今もわたしの心に暗い影を落としています。
 その1つが、「日本語とは逆に、英語は後ろから後ろから修飾していくので、日本語にするときには逆に訳していかなければならない。」ってやつです。

 たとえばこんな文章。

Your software team can develop a set of quality characteristics and associated questions that would probe the degree to which each factors has been satisfied.
(原書15.2.2 Qualitative Quality Assessment)

 that would ... が questions を後ろから修飾し、to which ... が the degree を後ろから修飾しているようです。修飾の順番を「逆に」すると、こんな訳になるでしょうか。

品質特性と、その品質特性がどの程度満たされているかを明らかにするための質問のセットを作ってもいいだろう。

 たぶん間違ってはいないんでしょうけれど、「品質特性」で宣言した、「『と』で結ばれるべき相手」である「質問」が、待てど暮らせど出てこないんですね。読み手は、「品質特性」と「と」で結ばれる相手がこの後出てくるはずだというアタマになっているのに。

 訳す方も実は同じです。
 characteristics をいったん脳に保管しておいて、次の修飾部1を訳しているうちにさらに修飾部2が現れる。修飾部1も脳に保管したうえで、修飾部2を訳し、終わったら修飾部1を脳から取り出し、最後に「品質特性」を脳から取り出して結合する。スタック構造が脳のキャパシティを浪費してしまいます

 こんな文章の翻訳について、『翻訳エクササイズ』(金原瑞人・著)では、「ひっくり返さない」という章で、こんな説明をしています(修飾筆者)。

なぜか中高の英語教育では、関係代名詞や接続詞の前後をひっくり返して訳すように教えることが多く、これが翻訳のときの足枷になっているのは間違いありません。いえ、英語を読むときの足枷にもなっています。

On a sunny day I met a beautiful girl whose name was Jane.

これを訳せというと、たいがいの学生は、
「ある晴れた日、私は、その名がジェインである美しい少女に会った」
と訳してきます。しかし英語は頭から読んでいくと
「ある晴れた日、美しい少女にあった。その子の名前はジェインだった」
と書かれている。だから、そう訳しましょうという、ただそれだけのことをいっているのです。じゃあ、英語の関係代名詞whoseはどこにいったんだ、whoseをand herとしてしまっていいのかと疑問に思う人もいるでしょう。しかしそれでいいのです。というか、翻訳の場合はこう訳したほうがいいということです。

 我が意をえたり~。受験脳のせいで、関係代名詞の限定用法と叙述用法の区別が頭をちらついたりしますが、「翻訳の場合はこう訳したほうがいい」のです!
 ということで、先の文章も

Your softaware team can develop a set of quality characteristics and associated questions that would probe the degree to which each factors has been satisfied.(原書15.2.2 Qualitative Quality Assesmentより)
品質特性とそれに関する質問のセットを作り、各要素がどの程度満たされているかを調べることも可能だ。

としています。これはこれで問題ナシというつもりはなく、主語が長すぎるという欠点があり悩ましいのですが・・・。

先ぶれの副詞も・・・

 『井上ひさしの作文教室』には、「先ぶれの副詞」という考え方が出てきます。以下抜粋。

 日本語というのは文のポイントが、そのおしまいに来る。判断個所が文の終わりに来るんですよね。
 私は昼御飯をー--というところで終わってしまったら、食べたのか食べなかったのかわかりません。
 そのときに「まだ」とついたら、食べてないということが、すぐにわかってしまいます。
 わたしたち日本人は「まだ」と聞くと、下に否定が来ると判断できるんです。こういう「まだ」のようなものを「先触れの副詞」と言います。文章が長くて、読み手が、いい加減ここらで判断の手掛かりを出してくれないかなと思いそうなところで、こういう副詞をちょっと出してやる。そうすると、その文章の判断が決まっていくわけです。

 主観ですが、原著は文章が比較的長く、節と節の間の論理関係が取りづらいと感じることが多かった。そういう時には文章を区切ったり、この「先触れの副詞」で早めに文章の意味の方向性を示したり、という工夫を盛り込んだりもしています。
 結局、いい訳文を作ろうとすると、日本語に立ち返っていくわけですね~。

おわりに

 本書の内容にはまったく触れず、「翻訳って日本語と難しさに気づかされて面白いよ!」という話を書いてみました。
 わたしの訳文はベストではないだろうと思いますし、英語のデキる人からすると笑止かもしれませんが、こういったことにできるだけ配慮して書いてみました。
 ぜひ、ご一読いただければと思います。

*1:能動態的に修飾するなら、「(誰かが)テストで摘出したバグ」と考えて、bugs someone has detected in testing みたいな感じでしょうけど、あまりそういう言い方はしなさそうです。