目次
はじめに（本記事の見どころなど）
今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。
本記事はDaniel Terhorst-North(Dan North)が書いた記事です。Dan NorthはBDDの原典ともいえる記事「Introducing BDD」（日本語訳の記事「BDDの導入 - Dan North」）を書いたことでも有名です。
本記事では、Danが考えたテストの目的を提示した上で、自動テストやTDDに対する誤解について語っています。そしてテスターに対する本当の価値についても、敬意を持って語っています。
Danはテスターではなくプログラマーでありながら、ここまでテストのことについて語っていることが素晴らしいと思い、翻訳することにしました。
これ以降は元記事を翻訳したものになります。
テストについて話し合わなくてはならない
話し合わない状態の中、どのようにして、プログラマーとテスターが協力して幸せで充実した生活を送ることができるのでしょうか。
なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？
何年にもわたって、プログラマーやテスター、その他さまざまな人々と、このような質問について何度も議論してきました。 これらは重要なトピックであり、多くの場合、混乱と誤解と仲間意識で覆われています。 私はプログラマーとテスターの両方の陣営から、プログラマーはテストを書くべき/書くべきではない、テストを書く資格がある/資格がない、テストを理解している/理解していない、などと聞いています。
私たちはよく、議論開始時点よりも良い結論にたどり着くので、この記事では、私たちが行った議論の一部を紹介したいと思います.
混乱の多くは、テストの目的を理解していないことに起因しています。皮肉ですが、開発者だけでなく大多数のテスターも同様に理解していません。そのため、理論立てた共有ができていません。
この理論を作成するために、いくつかのトピックを見てみたいと思います。
- テストとは何か。テストではないものとは何か。
- なぜTDD (および BDD) はテストとは無関係なのか
ここからは、上に書いた質問のそれぞれに対処し、テスターとプログラマーが幸せな生活のためにどのように協力できるかについて説明します。これにより、あなたの役割が何であれ、テストの規律と領域を再評価し、テストが素晴らしい仕事であると認識して取り組むようになることを願っています。
長文になったので、お茶でも飲みながら読み始めましょう。
テストの目的
「うまくいかないかもしれないものは何ですか？」
新しいフィーチャーの追加、フィーチャーの変更または置き換え、物事を改善するための「内部の」変更など、ソフトウェアを変更するたびに、リスクが発生します。どのような変更でも、「悪いこと」が起こる可能性はゼロではありません。
リスクは、コード自体だけでなく、ビルドシステム、デプロイまでのパス、動作環境、統合した場所、およびその他の直接的または間接的な依存関係にも当てはまります。
起こりうる「悪いこと」には多くの種類があります。 いくつか挙げると……
- 機能の正しさ：期待した結果が得られません。
- 信頼性：ほとんどの場合、正しい内容が表示されますが、たまに表示されません。
- ユーザビリティ：確かに動きますが、一貫性がなく、使用時にイライラします。
- アクセシビリティ：ユーザビリティと同様ですが、排他的であり、おそらく不正です。
- 予測可能性：メモリ、I/O、CPU使用率などのリソースにランダムなスパイクが発生するか、かなりの時間ハングすることがあります。
- セキュリティ：設計どおりに動きますが、セキュリティの脆弱性が露呈しています。
- コンプライアンス：動きますが、個人情報を正しく処理しません。
- 可観測性：ほとんどの場合は動きますが、動かない場合、その理由の特定が困難です。
「悪いこと」の種類ごとに、気にかけている人または役割があり、私たちはそのような人々を利害関係者と呼んでいます。 これらの人々は、私たちの取り組みにおけるさまざまな面のリスクや品質を表しています。
なぜテストをするのですか？
ここまで書いたことを念頭に置いて、私は次の提言をします。
テストの目的とは、証拠を通じて利害関係者の信頼を高めることです。
この提言には 3 つの要素があります。
- 利害関係者とは、私たちの仕事を通じて直接的または間接的に影響を受ける人です。 UXスペシャリストのMarc McNeillは、「私たちが触れている人々」という素敵な言葉を使っています。これは、製品やサービスの顧客やエンドユーザーよりも広く、利害関係者は1つの視点だけ見えているサイロ化された個人ではありません。利害関係者はさまざまな視点から貢献する協力者です。
- 技術的に不確実性を減らし信頼を高めるとは、利害関係者が関心を持っており、私たちが行っている、または始めようとしている作業がどのように影響するかを理解することです。利害関係者の夜の睡眠を改善するにはどうすればよいでしょうか？
- 証拠とは、議論の余地のない情報またはデータです。利害関係者は、あなたの保証や約束に依存したり、評判に頼ったりする必要がありません。これらは冷静で確固たる証拠であるものがふさわしいです。
不確実性を低減するプロセスを保証と表現し、利害関係者が気にかけていることを品質 (の基準) と表現できるため、テストの規律を表すもう 1 つの一般的な用語である品質保証についてもカバーしています*1。私たちは品質保証が盲目的な信仰やわざとらしい言動ではなく証拠に基づいていると主張しています。
その結果、私がテストの考え方に関連付ける 3 つの「スーパーパワー」があります。
- 共感：利害関係者の頭の中に入り込み、彼らの視点から世界を見て、懸念の原因を理解する能力。
- 懐疑主義：自分がやっている仕事をしているときでさえ、その仕事を疑う能力。 これはプログラマーにとって特に難しいことです。私たちのエゴと確証バイアスは常にあります。この懐疑論は、仮説を「証明」するのではなく、仮説を反証しようとする科学的方法と同じ考え方です。
- 創意工夫：利害関係者に安心感を与えるために必要なことは何でもする、またはそもそも彼らが懐疑的であることが正しいと見出す能力と決意です！テストは非線形で自明ではなく、多くの場合突発的です。データベースをいじる、ネットワーク上のパケットを盗み見る、インタラクションを記録するようなサービスプロキシを挿入する、目の動きを追跡する、DNSをハッキングする、他のコードを壊すコードを書くなど。優れたテスターにとって、立ち入り禁止になるものは何もありません。
この場合に限り……
この定義から、
証拠を通じて利害関係者の信頼を高めている場合に限り、テストを行っています。
テスト思考には、欠陥のクラス全体を防ぐアーキテクチャまたはデザインの選択を行うことや、手探りで作ったUIを、振る舞い特性がよく理解されている堅牢で強化された、十分に文書化されたウィジェットの制約付きセットに置き換えることが含まれます。これらは、特定の種類のリスクを無効にする予防措置です。利害関係者が不愉快な驚きを受けることがないため、下流工程で誰もこの種のエラーをチェックする必要がありません。
テスト思考とは、新しいフィーチャーを設計している間、この変更に関心を持つ可能性のあるさまざまな利害関係者全員がそれぞれ心配しているかもしれないすべてのことについて考える時間を作り、それらがおそらく正しいと仮定することを意味します。
逆に、具体的な証拠を通じて、明らかにどの利害関係者の信頼も高めない仕事をしている場合は、あなたが何をしていたとしても、テストしていないことになります！テストの観点から見ると、せいぜい、すでに踏まれた道を進んでいることになります。最悪の場合、テスト劇場（意訳：テストしているフリをして）に従事していることになります。これは、有用な情報を生成せずにテストをしているような錯覚を与える活動です。
デジタル製品のコンテキストでは、この証拠を表面化する最も一般的な形式は、システムと対話して手動または自動化されたテストを設計、作成、および実行することによる実践的なテストです。優れた自動化されたテストの設計と作成については、独自のセクションを設けて説明する価値があります。ただしその前に TDD について説明する必要があります。TDD は混乱の主な原因であるためです。
テスト駆動開発 〜テストについて語る前に説明が必要です〜
テスト駆動開発 (Test-Driven Development, TDD) は、プログラマーが API またはコードのフィーチャーの設計をガイドするために、小さく実行可能なコード例を作成するプログラミング方法です。 このアプローチは、小規模で意図的な手順を実行し、テストコード形式で書かれた具体例を動かすために必要なことだけに集中する優れた方法です。プログラマーが新しい具体例を動かし始めるたびにリファクタリングと整理を忘れない限り、狭いインターフェースと、適切に構造化され必要な情報を簡単に見つけられるコードを生成する傾向があります。
この方法で作成した具体例は、コードベースが進化するにつれてプログラマーが明らかな欠陥を防ぐための回帰テストとして事後的に使用するため、混乱が生じます。具体例のガイド付きプログラミングの初期の実践者は、このようなスタイルを「テスト駆動開発」と呼びました。この用語は、Kent Beck が書いた影響力があるアジャイルで標準的な書籍『Extreme Programming Explained（邦訳：エクストリームプログラミング）』を通じて主流になりました。後に、Kent Beckや他の人は好んでテスト駆動開発で書くようになりました。
これらはプログラマーに有益なフィードバックを提供する一方で、これらの実行可能な具体例は必ずしも良いテスト(これについては後述で詳しく説明します)であるとは限りません。そしていずれにせよ、経験豊富な TDD実践者は、通常、実行可能な具体例をできるだけ少なく書きます。 Kent Beck が言うように、プログラマーはテストを書くことで報酬を得るのではなく、機能するコードを書くことで報酬を得ます。
この混乱が、振る舞い駆動開発を考案する主な動機でした。私は TDD でチームを指導していましたが、この記事の冒頭にあるすべての質問に行き詰まり、そのような質問で示している「テスト」がTDDの実践とは何の関係もないことがわかりました。そのため、「テスト」という単語をまったく使用せずにTDDを説明する方法を策定しました。これにより、チーム内での TDD の牽引力と採用が大幅に向上することがわかりました。
この用語の誤用は、ほとんどのテストが単なるテスト劇場であるという信念と相まって、アジャイルのムーブメントが、過去 20 年間にわたってソフトウェアテストの規律に不注意に甚大な損害を与えてきたと考えています。
これは物議を醸す意見であることを理解していますので、以下で詳しく説明します。すべてに対して否定的というわけではありません。テストの世界は、自動化されたビルドとデプロイの影響によって多大な恩恵を受けてきました。フィードバックがまったくないよりはましな「プログラマーテスト」を実行する、より小さなチャンクで作業して、デリバリー時間とフィードバックの遅延を減らすなどです。カオスエンジニアリングなどの新たに出てきたムーブメントに代表される「本番環境でのテスト」の文化も刺激的ですが、それはまだ成熟していない分野です。
しかし、テストの目的と本質、およびその実践者の役割は、侵略的な「自動テスト」によって薄められてきました。悪名高い自動化テストピラミッドでさえ、セキュリティやコンプライアンスなどの分野横断的な安全性の問題、または操作性や可観測性の品質特性ではなく、通常、ほぼ完全に機能性に関するものになっています。
要約すると、TDD、BDD、ATDD、および関連するメソッドは、その名前が示すように、テストに取って代わるものではありません。これらは主に設計および開発手法です。
なので、テストとは利害関係者に証拠を提供することであり、TDDに忠実に従っているとしても、せいぜい表面的なテストにすぎないことを理解していただけたでしょう。よって、最初の質問に戻ることができます。
テストについて話しましょう
なぜすべてのテストを自動化しないの？
これは、私が言及した巨大な不注意による損害が現れている場所です。 アジャイルの手法が注目を集める前の 1990 年代、テストは構造化された活動であり、プロジェクトの開始時に要件が作成されると同時にテスト計画が開始されました。 この段階での重要な活動は、影響度分析でした。何が変化しているのか、そしてそれが「悪いこと」を引き起こす可能性のあるさまざまな方法を理解することです。
今、私はソフトウェアデリバリーの暗黒時代に戻ることを主張しているわけではありません。
この数年間で、以下のような新しい考え方が定着しました。
- アジャイルなソフトウェアチームは、主にプログラマーで構成され、ドメインエキスパート（Subject Matter Expert、SME）またはアナリスト (後にプロダクト オーナー) がドメイン情報を提供し、スコープを設定します。
- 私たちプログラマーは、TDD、つまり「テストファースト」なプログラミングなどを使用しているため、作業を進めながら単体テストを作成しています。
- テストファーストなプログラミングをすることで、コードに十分自信が持てるテストを作成できます。
- 単体テストは高速なので、変更を加えるたびにすべて実行できます。「常にすべてのテストを実行する」というスローガンもあります。
- これは、変更ごとに影響度分析を行う必要がないことを意味します。どこかの機能に影響がある場合は、包括的な単体テストスイートを実行するとすぐにわかります。
- 残ったものを取り除くためのテスターだけが必要です。自動化するにはコストがかかりすぎるテストや、頻繁に変更する価値のないテストを行います。これを手動テストと呼びます。
- 自動テストの作成が上手になるにつれて、必要な手動テスターはますます少なくなります。
- テスターが十分に頭が良ければ、自動テスターとして再訓練するべきです。つまり、自動テストを作成する程度しかできない二流のプログラマーのようなものです。他の人はボタンを押すことができます。したがって、階層はプログラマー > 自動テスター > 手動テスターです。
- この価値の低いテストのほとんどを外部委託し、一般的なサービス化されたバックグラウンド活動として扱うことができます。
- 私たちのテストカバレッジメトリクスは、テストにおける私たちの素晴らしさを示しています。私たちならできる！
この考え方には非常に多くの誤りがあるため、時間をかけて紐解く価値があります。
- [アジャイル ソフトウェア チーム…] プログラミングは、デジタル製品開発のバリューチェーンの一部にすぎません。「チーム」のほとんどがプログラマーであるという事実は、価値創造に直接的または間接的に関与するより幅広い役割を覆い隠しています。
- […単体テストを書いている…] プログラマーは自分が単体テストを書いていると思っています。そうではありません。彼らは、設計の指針となる簡単な具体例をテストコード形式で書いているに過ぎません。通常、これらは、セキュリティ、アクセシビリティ、コンプライアンスなどのより微妙な非機能面ではなく、コードが何をするかについての機能面についての単一なサンプルのテストです。そのフィーチャーが利害関係者の1人に対してである場合を除き、他のすべての利害関係者は脇に追いやられます。
これらの具体例は、テストとしてではなく、ガイドとして設計されたものです。たとえば、プログラマーとして、計算をチェックするために単一の値を使用して「テスト」を作成し、より複雑な場合に三角測量を行うためにもう 1 つの値を作成するかもしれません。それから私は勝利を宣言します。テストの考え方で、エッジケース、小さい値または大きい値、巨大な負の値、プラス/マイナスゼロに近い値またはその他の重要な遷移、欠落または無効な値、順不同の呼び出し、およびその他のさまざまな不正な検査について考えます*2。
プログラマーがこのテストの考え方を採用できない理由はありませんが、通常、納期のプレッシャーのために、すでに次の作業に進んでいます。 - […自分のコードに自信がある…] プログラマーが自分のコードに自信を持っていることは、品質の悪い指標となることで有名です。作業する人は、定義上、作業に対して自信を持っている可能性が最も高い人です。正しいと思わなかったら、別のコードを書いていたでしょう。ここではあらゆる種類の認知バイアスが働いています。いくつか例を挙げると、確証バイアス、根本的な帰属の誤り（帰属バイアスの一種）、ダニングクルーガー効果などです。
これらすべてをナビゲートすることは、プログラマーがテスターのように考え始めるための最低限のことです。私たちは、失敗を想定しておらず、成功を想定した立場から始めています。私のデフォルトのモードは、幻想を破壊するのではなく、「自分が正しいことを証明する」ための証拠を探し、それを見つけたら停止することです。 - […すべて実行…] 始めた頃は真実ですが、細部へのマメで規律ある注意がなければ、数秒のビルドが数分のビルドになり、30 分のビルドになります。環境の自動プロビジョニングとティアダウン、テストデータのサニタイズとロード、ビルドおよびデプロイリソースの競合、能力不足の開発環境、その他多くの要因が加わると、「常にすべてのテストを実行する」という夢は遠のいてしまいます。その時点で、どの段階でテストのどのサブセットを実行するかを決定します。そこでは、多くの段階を導入して中間のフィードバックループを短縮し、本番までの全体的なリード タイムを増加させます。テストスイート管理の闇の世界に入る必要があります。
- […影響分析…] 一部のツールは、失敗したテストを最初に再実行したり、静的解析を使用してどのテストが最も有用であるかを判断するといった、影響主導のアプローチを取ることができます。しかし、影響度分析のスキルと規律は、依然として必要な技術であり、消えゆく技術でもあります。
- […取り除くためのテスターだけが必要…] ここまでの話を踏まえると、どこに向かっているのか推測できるでしょう。テストについて考えるのを手伝ってくれるテスターが必要です！自動vs手動という軸は、誤った考えに取りつかれている最も興味深いものの1つです。リスクとその潜在的な影響を複数の側面から理解し、そのすべての重要な情報を明らかにすることは、常に考えるべき分野です。
- […手動テスターの減少…] 驚くかもしれませんが、私はこれに同意する傾向にあります。しかし、アジャイルなプログラマーが「自動テストを書く」と考えていることは、優れた自動テストを作成するスキルや規律とはまったく異なります。これは多くのプログラマーにとって驚きでしょう。
- [自動テスターとしての再訓練] プログラミングスキルはテスターに役立ちますが、自動テスターまたは手動テスターの役割を認識していないでしょう。自動化は、優れたテスターのツールベルト*3に入っている多くの便利なツールの1つです。
- […外部委託…] そして、ここに問題があります！リスクを認識し、影響を理解し、利害関係者の頭の中に入り込み（主要な個人やグループとの関係を構築し）、証拠の表面化を模索することは、外部委託するのが賢明な活動や素質ではありません。 「外部委託したテスト機能」がある場合、それが同じ組織内の別のチームであっても、彼らはテスト劇場に従事しており、リスクを軽減したり信頼を高めたりするために何もしていない可能性があります。
- […テスト カバレッジ メトリクス…] テストカバレッジについては後述します。残念ながら、私たちのテストは素晴らしくありません。
このような考え方は普遍的なものではなく、多くのチームがテストに対して健全で包括的なアプローチを取っています。ですが、このような考え方は広く普及しており、採用から資格認定、キャリアパス全体に至るまで、「手動」テスターvs「自動」テスターの考え方はほぼどこにでもあります。
「なぜすべてのテストを自動化しないの？」という質問に答えましょう。自動テストが証拠を表面化するのに役立つ場合、特に繰り返し行う可能性が高いものについては、自動テストを作成するべきです。これは、プログラマーの指針の観点ではなく、テストの観点から行う必要があります。また、データベースやリモートサービスからテスト結果を取得したり、予めテストデータを使用可能な形式に処理したりするなど、他のテスト活動を支援するツールを作成することもあります。
人間は、コンピューターシステムとやり取りするときにボタンを押すだけではなく、多くのことを行っています。人間が生成できる洞察とフィードバックにより、実践的なテストは貴重で継続的な活動になります。
テストカバレッジは有用な指標ですか？
有用でもあり、そうでない時もあります。 場合によります。 「テストカバレッジ」は、「自動テストの実行によってカバーされるコード」という説明を省略した言葉です*4。ここでも品質に関する複数の側面を適用します。 この特定のテストを通じて、どの利害関係者に証拠を提供していますか？これは彼らの自信にどのように影響を与えますか？一部のコードが別のコードを実行したという事実は、せいぜい少なくとも1人の利害関係者に対して何らかの証拠を与えられたことを示しています。
たとえば、コードパスを実行して正確性（正しい答えが得られるかどうか？）をチェックしても、セキュリティの脆弱性や、規制に違反しているかどうかについては何もわかりません。 また、実行するたびに同じ単一の値のみをチェックするテストを実行することは、どのような場合の保証にもなりません。
テストカバレッジで明らかになることの1つは、自動テストがまったくないコードです！カバレッジの欠如は、コードが自動テストによってチェックされていないことを示します。 しかし、他の方法でコードを検証していることがわかっている場合、それは必ずしも問題ではありません。たとえば、開発者やテスターが毎日何度も目にするユーザーインターフェースでは、確認するための自動テストがなくても、明らかなレイアウトエラーが発生する可能性はほとんどありません。
「テストをシフトレフトする」とはどういう意味ですか？
以前は、シフトレフトするということは、すべてのテスト活動をプロセスの早い段階で開始することを意味すると考えていましたが、それ以上のものであることに気付きました。シフトレフトとは別のことを行うことを意味します。テストをシフトレフトするということは、さまざまな利害関係者を早期かつ継続的に考慮して、アーキテクチャと設計について異なる考え方をすることを意味します。これは、セキュリティ、アクセシビリティ、および私たちが気にかけるべき他のすべての品質の側面をシフトレフトすることを意味します。したがって、テストをシフトレフトすると、あらゆる種類の保証活動が動機付けられ、決してうまくはたらかないソリューションに過剰に投資するのを防ぐことができます。 強力にしたTDDのようなものです。
意図しない結果として、テスターが製品を後からしか確認できない場合に下流工程で行わなければならなかった従来の作業の多くを取り除くことができます。繰り返しますが、私たちは早い段階でその作業を行っているわけではありません。作業をまったく必要としないように状況を整えているのです！
いつ、どこでテストすべきですか？
シフトレフトの結果がこの質問の回答です。 明白な回答は、できるだけ早く、実用的な頻度で、です。 開発サイクルのどこからでも、保証を与える証拠の表面化を開始できます。 プログラマーは、少なくとも時々はテスターのように考える必要があり、テスターはこれを支援することができます。
フィーチャーをテストする前に「完成」または「織り込み済みに」すべきという誤りがあります。ですが、これは簡単に暴かれます。シフトレフトでは、どのデータが、どこから、どのように、どのくらいの期間、どのような目的でアクセスされているかを評価できます。これにより、軽量な UI スケッチの一貫性やアクセシビリティを評価できます。
このことから、セキュリティ、プライバシー、コンプライアンスについて意見を述べることができます。 毎回どのくらいのデータが返されますか？データ量やデータ値、または画面の更新時間に関する最悪のシナリオは何ですか？このような質問により、信頼性、堅牢性、回復力に関する洞察が得られます。
プログラマーは、常にすべての関係者と同じように考えることはできません。しかし、このテスト思考は継続的に行われるべきであり、開発チームやバリューチェーンに沿った他の場所にテスターが組み込まれています。
十分なテストとはどれくらいですか？
システムを変更するすべてのアクティビティは、多くの側面でリスク（「悪いこと」の可能性）を伴います。それらのいくつかは前述しました。変化の種類と状況に応じて、証拠を通じて適切なレベルの信頼を生み出す責任は私たちにあります。
これは、テストの「量」が直線的な量ではないことを示唆しています。 同じ次元でも「十分」を考慮する必要があります。変化の大きさは？ 何か悪いことが起こった場合の潜在的な影響は何ですか？セキュリティ、ユーザビリティなどにどのような影響を与えるでしょうか？リスクプロファイルを変更するために、どのようにして別の方法で行うことができますか?
「十分な」テストについて考えると、さまざまな意味を持つ代替案について建設的な議論につながる可能性があります。これらはほとんど常にトレードオフです。あるソリューションが別のソリューションよりもすべての次元で客観的に「優れている」ことはめったにありません。よりシンプルで小さな変更は、より大きく複雑な変更よりも通常はリスクが低いと言っても過言ではありません。
おわりに
プログラマーとして、私は 30 年のキャリアのかなりの部分、おそらく過去 20 年間、テストとテスターがソフトウェア開発にどのように適合するかについて考えてきました。私は、アジャイルソフトウェア開発におけるテストとテスターの位置付けに満足したことがなく、これらの考えを構造化して明確にするのに長い時間がかかりました。 この記事の初期のヒントは、2016 年のBDDxでの私の基調講演に現れており、2018年末の時点で書くことにしました。
私はプロのテスターではありません。私は、最近チーム内およびチーム間で作業し、何年にもわたって何人かの素晴らしいテスターに会って作業する権利を得たアジャイルプログラマーの観点からこれを書きました。
私は、テストの目的と原則はアジャイルなデリバリー方法とうまく調和できると信じています。そして、テストの目的と原則が一般的には調和できていないという事実は、システムの必然性というよりも歴史的ないたずらです。この道を歩み続けると、テストとテスターを脇に置き続け、真に優れたパフォーマンスを発揮するチームの機会を逃すことになります。
これらのアイデアのいくつかを再導入することで、より優れた品質のソフトウェアをより速く、より持続的に作成でき、「より良く、より速く、より安く」という珍しい三方良しを楽しむことができます。
Maaike Brinkhof、Aslam Khan、Tom Roden、Anna Urbaniak のレビューフィードバックと、Liz Keogh と Paul Shepheard が以前から考えていたことに感謝します。
*1:原理主義者は、品質保証とテストには違いがあると主張します。本記事に関する調査をしているときに、これらの用語を区別すべきと主張するいくつかの情報源を読みましたが、それぞれのテストの定義は狭く、矛盾していました！また、本記事で私が話しているようなことを説明するために「品質保証」という用語を使用していました。私が話した多くのテスターは、「品質保証」という用語を完全に削除したいと考えています。
*2:プロパティベースまたは生成テストと呼ばれる自動テストの別のスタイルがあり、単一のテストで数千または数百万の疑似乱数サンプルを生成できます。ただし、それは本記事の説明の域を超えています。それらはクールだと思うよ！
*3:訳注：ツールベルトとは、工具などを差して携帯できるようになっているベルトのこと
*4:訳注：「自動テストの実行によってカバーされるコード」は「テストカバレッジ」ではなく「コードカバレッジ」を指すと思われますが、原文が「Test coverage」と表記しているため、忠実に従っています。
