プログラマーはテスターが悪いですか？

これはすでに質問されている他の質問とよく似ていますが、実際は少し異なります。一般に、プログラマーはアプリケーションのテストの役割を実行するのが得意ではないと考えられているようです。例えば：

Joel on Software- テスターがいない上位5つの（間違った）理由（強調）

大学のCS卒業生に、彼らがあなたのために働くことができると告げようとすることさえ考えないでください。私はこれを見てきました。プログラマーは優れたテスターを作りません。そして、交換するのがはるかに難しい優れたプログラマーを失います。

そして、この質問では、最も人気のある答えの1つが言います（再び、私の強調）：

開発者はテスターに​​なることができますが、テスターであってはなりません。開発者は、アプリケーションを破壊する可能性のある方法での使用を意図せず/意識せずに避ける傾向があります。それは、彼らがそれを書いて、大抵それが使われるべき方法でそれをテストするからです。

質問は、プログラマーがテストに苦手なのか？この結論を裏付ける証拠や議論はありますか？プログラマは自分のコードをテストするのが苦手なだけですか？プログラマーが実際にテストに長けていることを示唆する証拠はありますか？

「テスト」とはどういう意味ですか？私は、単体テストや、ソフトウェアを作成するためにソフトウェアチームが使用する方法論の一部と見なされるものを意味しません。コードが構築され、ソフトウェアチームが「テスト環境」と呼ぶものにデプロイされた後に使用される何らかの品質保証方法を意味します。

この質問は、特にSystem Testingについて質問しているように見えるため、この回答全体を通して私が言及していることです。

テストを実行することを選択するのが悪い人であることと、実際にテストが苦手なこととの間には、重要な区別があると思います。

プログラマーがテストに苦手な理由：

• あなたがコードを書いたのであれば、あなたは（物事がうまくいかない可能性のある多くの方法をすでに考えており、それらに対処したはずです）。
• 特に厄介なバグを見つけることは、あなたがうんざりしているかもしれないコードベースでそれを行って修正しなければならないことを意味する場合、それはあなたのモチベーションを助けません。

プログラマーがテストに長けている理由：

• プログラマーは論理的思考者であり、体系的な方法での作業が得意です。
• 経験豊富なプログラマーは、エッジケースをすばやく特定し、有用なテストを思い付くことができます。（正式なテストプロセスがある場合、これらのケースのほとんどすべては、システムテストの前に既に特定され、テストされているはずです。）
• プログラマーは、すべての有用な情報がバグ報告に含まれることを確認するのが得意です。

プログラマーが悪いテスターである理由：

• プログラマーはテスターよりも高価です（ほとんどの場合）。
• 考え方は根本的に異なります。「（動作する）製品を構築する」と「（このことは（未知の）バグが入っているわけではありません。）」
• 通常、テスターはより効率的です。つまり、同じ時間でより多くのテストを実行します。
• プログラマーはプログラミングを専門としています。QAの専門家はテストを専門としています。

プログラマーは自分のコードをテストするのが苦手だと思う。

私たちのコードは要件に応じて完璧に機能すると信じ、テストします。私の代わりに、私たちは自分のコードをテストしてから、実際のテストサイクルにリリースする前にお互いのコードをテストします。

プログラマーは間違いなくシステムのいくつかの部分をテストするのにふさわしい人です-それを彼らが効果的にそれをすることができる唯一の人である場所で。

プログラマーがテストで非常に悪い傾向がある場所の1つは、「通常のユーザーのようにUIを使用する」ビット全体です。通常のユーザーではなく、そのように動作しません。例えば：

• プログラマーは、テキストエントリを適切に取得するのが非常に得意です。よくある問題は、先頭または末尾のスペースです。ほとんどの人はそうは思わないでしょうが、優秀なプログラマーはおそらく、余計なスペースのない適切な文字列を作ることに熱心です。
• プログラマーはキーボーディストになる傾向があり、タブやその他のショートカットを利用して作業を高速化します。通常のユーザーは、フィールド間でマウスをつかむ傾向があります。
• プログラマーは、エラーメッセージを無視して[OK]をクリックするだけでなく、システムが何を伝えているかを理解する傾向があります。

そのため、通常のユーザーはプログラマーがしない多くのことを行います。UATを開発チームに完全に依存することはできません。

技術レベル（単体テスト、統合テスト、回帰テスト）では、おそらくプログラマーがテスターに​​なる資格のある唯一の資格者です。これらの種類のテストは自動化可能であり、自動化する必要があるためです。

しかし、私はそれがあなたが話していることではないと思います、そしてそれはジョエル・スポルスキーが意味するものでもないことをかなり確信しています-それは残っている部分であり、実際の実践的な手動テスト：要件文書と機能仕様の変換テストスクリプトを作成し、完成した製品に対してこのスクリプトを慎重に実行します。

優れたテスターであるためには、優れたプログラマーとなるものとほとんど直交する品質が必要です。若干の重複があります-分析的に考えることができなければならず、一般的にコンピューターとのある程度の親和性が必要です-それ以外は、テスターのスキルは大きく異なります。それ自体では、両方のスキルセットを使用できることを意味するものではなく、実際、おそらくかなりの人が使用する可能性があります。しかし、本当に優れたプログラマーになるには、ある程度の怠requires（雑用を自動化したいという欲求）が必要です。一方、本当に優れたテスターに​​は永続性（3,000のフォームフィールドすべてに矛盾がないかチェックする）が必要です。テスターに​​なるために必要なものを持っているので、通常はその考えを嫌います。

そして、選択的なバイアスがあります：すでにプロジェクトに少しでも関わっているプログラマーは、コードベースについてある程度の内部知識を既に持っており、エンドユーザーの観点から、頭を悩ませてアプローチするのに苦労します。「このボタンが機能することはわかっているので、「パス」に注意してください」のように、明示的である必要はありません。それははるかに微妙な場合があり、それらの微妙な効果は、テストで見落とされる重大なエッジケースにつながる可能性があります。

私の経験から、はい、プログラマーは悪いテスターです。多くの場合、他の人に会って「ハァッ、でもチェックインする前にテストしました！」目の前でバグを再現するテスターが直面したとき。

どうして？まあ、なぜそうなったのかは分かりませんが、多分それは私たちが機能しているのを見たいからでしょう。または、この機能またはその機能のテストを既にやり直したいだけです。

とにかく、テストは私たちが学んだスキルではなく、私たちは機能を壊すのが得意なのでプログラマーとして働きません。また、適切なテスト計画やQAが行う他のすべてのことを行う方法がわからない場合もあります。テスターが新しい3Dレンダリングパイプラインを実装する資格を持っているので、テスターの仕事をする資格はもうありません。

質問のように、テストとは自動化されたものではなく、実際にプログラムを使用してテストすることを意味します。

テストにはいくつかのレベルがあります。「低レベル」テストは、開発者が行うことができ、行う必要があります。私はユニットテストで考える。

一方、「高レベル」テストはまったく別のものです。一般に、開発者はテスターが悪いと思うのではなく、スキルを逃すからではなく、思考方法や作業方法を数時間で変えるのが非常に難しいからだと思います。

私はできるだけコードをテストしてみますが、テスターが少なくとも10分たつと、バグや機能強化を検討する何かが生じます。これは、作成したものをテストするのは大変な仕事であることを意味します。クリックする場所、クリックするタイミング、ビジネスロジック、データの永続化方法を知っています。あなたは決して落ちない神です。

どのようなテストを意味しますか？包括的な網羅的なテストを意味する場合、可能性のある入力のすべての組み合わせをそのようなテストの要件と見なすと、ほとんどの人がこのカテゴリで貧しいと思うかもしれませんが、イエスと言う理由がいくつかあります。

ソフトウェアを設計する開発者は、コードが何を処理するかという点に関しては、トンネルのビジョンを持っている可能性があることを認めることができます。たとえば、数字nを受け取り、画面に1からnまでを印刷するWebフォームを作成すると、何も入力されていない場合や、eやpiなどの自然数ではないものなど、いくつかの特殊なケースを見逃す場合があります。これらの場合にプログラムが何をするのかは疑わしいかもしれません。

テスト駆動開発は、ここで別の見方をする可能性のある別の観点からテストを行う開発方法論の例です。

プログラマーは、コードを記述する前にテストを定義するときに、テストを細かく定義します。練習すれば、さらに良くなります。

しかし、彼らが書いたコードのテストを定義するとき、それらはあまりうまくいきません。彼らは、コードを書く際に持っていたのと同じテストの盲点を持ちます。

プログラマーを使用して手動テストを行うのはばかげています。手動テストは、それ自体ではばかげています。プログラマーにそれをさせるのは非常にばかげています。それは高価であり、有能なプログラマを追い払います。

特にデベロッパーが失敗するのを確認したテストの1つは、要件が満たされているかどうかをテストすることです。開発者が要件内の何かを考えていることとテスターがそれが意味していると考えることは、多くの場合2つのまったく異なるものです。

開発者がデルタエクスポートを行うように要求され、開発者が一度送信されていないレコードを取得することを意味し、テスターが新しいレコードと変更を取得することを意味すると考えた最近の1つを考えることができます。彼らはクライアントに戻って、誰が正しかったかを見つけなければなりませんでした。コードをレビューし、開発者が要件について行ったのと同じ仮定をしました。論理的には、更新を含める場合は、それらに言及しているはずだからです。そして、私は以前は物事のユーザー側にいたため、これらのあいまいなものを見つけるのが得意です。

そのため、テストを行う他の開発者は、「X副Yを意味する場合、詳細が多かったので、答える前に答える必要があるので、詳細があったはずです」などの特定の仮定を行うため、同じ仮定の多くを行う傾向がありますしかし、要件作成者はそのように考えていないため、要件作成者に似ていると考える人は開発者の仮定をテストする必要があり、開発者ではない人は問題があることを確認するのに適しています。