Author: mumumu Date: Mon Oct 27 18:30:39 2008 New Revision: 1545 Log: - translated "Quality Assurance (i.e., Professional Testing)" section.
Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml ============================================================================== --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Mon Oct 27 18:30:39 2008 @@ -1749,11 +1749,12 @@ <!-- ======================== subsection =========================== --> <sect2 id="subsidize-qa"> -<title>Quality Assurance (i.e., Professional Testing)</title> <!-- -<title>品質保証 (テストの専門家) を支援する</title> +<title>Quality Assurance (i.e., Professional Testing)</title> --> +<title>品質保証 (テストの専門家) を支援する</title> +<!-- <para>In proprietary software development, it is normal to have teams of people dedicated solely to quality assurance: bug hunting, performance and scalability testing, interface and documentation @@ -1765,7 +1766,23 @@ coverage, and, in the case of performance and scalability testing, partly because volunteers often don't have access to the necessary hardware resources anyway.</para> +--> + +<para> + プロプラエタリなソフトウェア開発では、バグ探しやパフォーマンス、 + スケーラビリティのテスト、インターフェイスやドキュメントの確認、 + などの品質保証専門のチームを置くことが普通です。 + フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、 + 品質保証に関する活動は積極的に行われないのが一般的です。 + これはテストのような地味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、 + ユーザー数が多いプロジェクトのコミュニティーでは、 + テストの網羅率が高くなると人々が考えるということもあります。 + また、パフォーマンスやスケーラビリティのテストの場合は、 + ボランティアは必要なハードウェアリソースを得られないから、 + ということもあります。 +</para> +<!-- <para>The assumption that having many users is equivalent to having many testers is not entirely baseless. Certainly there's little point assigning testers for basic functionality in common environments: bugs @@ -1779,14 +1796,32 @@ your customers (the people who drive <emphasis>your</emphasis> interest in the software) may differ in statistically significant ways from the usage patterns of the Average User In The Street.</para> +--> +<para> + 多くのユーザーを抱えているプロダクトには多くのテスターがいる、 + という考えは全く根拠がないものではありません。一般的な環境で、 + 基礎的な機能にテスターを割り当てるのはあまり意味がないのは確かです。 + なぜなら、そういう状況ではバグがすぐに見つかるのが自然の流れだからです。 + しかし、ユーザーはただ仕事をこなそうとするだけなので、 + プログラムの動作の限界を意図的に探そうとはしません。 + よってある程度のバグが残る可能性があります。 + さらに、容易に回避する方法があるバグの場合、 + ユーザーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。 + もっとも油断ならないのは、あなたの顧客 + (<emphasis>あなたが</emphasis> 関心がある人たちです) + のソフトウェアの使い方が、 + そこら辺にいる平均的なユーザの使い方と違う場合があることです。 +</para> + +<!-- <para>A professional testing team can uncover these sorts of bugs, and can do so as easily with free software as with proprietary software. The challenge is to convey the testing team's results back to the public in a useful form. In-house testing departments usually have their own way of reporting test results, involving company-specific jargon, or specialized knowledge about particular customers and their -data sets. Such reports would be inappropriate for the public bug +data sets. Such reports would be inappropriate for the public bug tracker, both because of their form and because of confidentiality concerns. Even if your company's internal bug tracking software were the same as that used by the public project, management might @@ -1797,7 +1832,32 @@ customer. But even when they're not confidential, they're of no concern to the public project, and therefore the public should not be distracted with them.</para> +--> + +<para> + テスト専門のチームは、 + こうした手合いのバグをフリーソフトウェアでも発見してくれます。 + 難しいのは、テストチームが行った作業の結果を、 + わかりやすい方法で皆に伝えることです。 + 組織内のテスト専門部署は、 + テスト結果を報告する独自のやり方をそれぞれに持っています。 + たとえば企業独自の方言や、 + 特定の顧客や彼ら向けのデータに関する特定の知識などです。 + こういった独自の情報は、書式や秘密保持の観点から、 + 公開されているバグ追跡システムに載せるのは不適切です。 + たとえあなたの企業で使っているバグ追跡システムが、 + フリーソフトウェアプロジェクトのそれと同じだったとしても、 + 特定の企業向けのコメントやバグに関するメタデータ + (たとえば、バグに対する内部的な優先度や、 + 特定の顧客向けに解決するスケジュール) を作る必要があるでしょう。 + こうした情報は外部には漏らさないのが普通です— + 場合によっては、顧客にすらみせてはいけないものです。 + しかし、たとえ秘密でなくても、 + それらはフリーソフトウェアプロジェクトにとっては関心がないものです。 + よって、そうした情報に気を取られてはいけません。 +</para> +<!-- <para>Yet the core bug report itself <emphasis>is</emphasis> important to the public. In fact, a bug report from your testing department is in some ways more valuable than one received from users at large, @@ -1805,7 +1865,18 @@ Given that you're unlikely to get that particular bug report from any other source, you definitely want to preserve it and make it available to the public project.</para> +--> + +<para> + しかしながら、<emphasis>バグ報告そのもの</emphasis> はフリーソフトウェアプロジェクトにとって重要なものです。 + 実際、テスト専門のチームからあがってきたバグ報告は、 + 多くのユーザーから受け取るそれよりもある意味価値があるものです。 + なぜなら、彼らはユーザーが調べてくれないことを調べてくれるからです。 + テストチームからしかあがってこないバグ報告がある場合、 + 確実に保存してフリーソフトウェアプロジェクトが利用できるようにしておきます。 +</para> +<!-- <para>To do this, either the QA department can file issues directly in the public issue tracker, if they're comfortable with that, or an intermediary (usually one of the developers) can "translate" the @@ -1814,7 +1885,18 @@ makes no reference to customer-specific information (the reproduction recipe may use customer data, assuming the customer approves it, of course).</para> +--> +<para> + 確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、 + 彼らとの仲介役 (通常は開発者のひとり) が、 + 内部向けのバグ報告を新しいものに「翻訳」してバグ追跡システムに登録するようにします。 + ここでいう「翻訳」とは、単に顧客特有のデータ (バグの再現手順には、 + 勿論顧客の同意を得た上で顧客のデータを使う場合があります) + を参照せずにバグについて説明することです。 +</para> + +<!-- <para>It is somewhat preferable to have the QA department filing issues in the public tracker directly. That gives the public a more direct appreciation of your company's involvement with the project: @@ -1824,24 +1906,65 @@ team is monitoring the public issue tracker, a developer can commit a fix for a scalability bug (which the developer may not have the resources to test herself), and then add a note to the issue asking -the QA team to see if the fix had the desired effect. Expect a bit of +the QA team to see if the fix had the desired effect. Expect a bit of resistance from some of the developers; programmers have a tendency to regard QA as, at best, a necessary evil. The QA team can easily overcome this by finding significant bugs and filing comprehensible reports; on the other hand, if their reports are not at least as good as those coming from the regular user community, then there's no point having them interact directly with the development team.</para> +--> +<para> + テストチームが直接問題を登録する方がどちらかといえば望ましいです。 + こうすることで、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。 + 役に立つバグ報告をすると、 + 技術的な貢献をすることと同じくらいあなたの組織への信頼は高まります。 + これは開発者にとっては、 + テストチームと直接話をする機会に繋がります。 + たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、 + 開発者はスケーラビリティに関するバグ (これをテストするリソースを彼らは持たない場合があります) を修正する作業に注力でき、 + その修正が望ましい結果を出しているかどうかを検証するようにバグ追跡システム上にコメントすることで, + テストチームに頼むことができます。 + 開発者から多少の抵抗があることは覚悟しておいて下さい。 + プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。 + テストチームが重要なバグを発見し、 + 理解しやすいバグ報告を行えば、こうした抵抗を振り払うのは簡単です。 + 一方、彼らのバグ報告の質がユーザーからあがってくるそれと大差ない場合は、 + 開発者と彼らが直接話をする意味はありません。 +</para> + +<!-- <para>Either way, once a public issue exists, the original internal issue should simply reference the public issue for technical content. Management and paid developers may continue to annotate the internal issue with company-specific comments as necessary, but use the public issue for information that should be available to everyone.</para> +--> + +<para> + どちらにせよ、組織内部のバグ報告が、 + 外部のバグ追跡システムにいったん登録されたら、 + 組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。 + 組織の管理者や雇われている開発者は、 + 必要に応じて顧客に特有の情報について注釈を付けても構いませんが、 + みんなが使えるようにするために、外部の情報を利用するようにしましょう。 +</para> +<!-- <para>You should go into this process expecting extra overhead. Maintaining two issues for one bug is, naturally, more work than maintaining one issue. The benefit is that many more coders will see the report and be able to contribute to a solution.</para> +--> + +<para> + こうした作業の過程で、あなたには余計な負担が掛かるはずです。 + ひとつしかバグがないのに二重にバグ報告を管理するのは、 + ひとつを管理するのに比べて仕事が多くなるのは当然です。 + ただ、こうすることで多くのプログラマがバグ報告の情報を利用でき、 + 問題の解決に貢献できるようになるのです。 +</para> </sect2> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
