プログラマーは悪いテスターですか？
これは既に質問されている他の質問とよく似ていますが、実際には少し異なります。プログラマーはアプリケーションのテストの役割を実行するのが得意ではないと一般的に考えられているようです。例えば：
Joel on Software- テスターがいないトップ5（間違った）理由 （私の強調）
大学のCSの卒業生にあなたのために働くことができると伝えようとすることさえ考えないでください。私はこれをたくさん見ました。 プログラマーは優れたテスターを作成しません、そしてあなたは、置き換えるのがはるかに難しい優れたプログラマーを失うでしょう。
そして この質問 で、最も人気のある回答の1つは次のように述べています（これも私の強調です）：
開発者はテスターになることができますが、テスターであってはなりません。 開発者は、意図せず/無意識のうちに、アプリケーションを壊すような方法でアプリケーションを使用することを避けがちです。彼らがアプリケーションを記述し、ほとんどの場合それを使用する方法でテストするためです。
だから問題はプログラマーがテストが苦手なのでしょうか？この結論を裏付ける証拠や議論はありますか？プログラマは自分のコードをテストするのが苦手なだけですか？プログラマーが実際にテストで良いであることを示唆する証拠はありますか？
「テスト」とはどういう意味ですか？私はではありません単体テストまたはソフトウェアチームがソフトウェアを作成するために使用する方法論の一部と見なされるものを意味します。ソフトウェアチームが "テスト環境"と呼ぶものにコードが構築され、展開された後に使用される、ある種の品質保証方法を意味します。
この質問は、具体的には システムテスト について尋ねているようです。そのため、この回答全体でそれについて言及しています。
私は、テストを実行することを選択するのが悪い人であることと、実際にテストが下手であることの間には、重要な区別があると思います。
プログラマーがテストが苦手な理由：
- あなたがコードを書いたのであれば、あなたはすでに、物事がうまくいかない可能性のある多くの方法を考えており、それらに対処しているはずです。
- 特に厄介なバグを見つけて、それを修正する必要がある場合、コードベースでうんざりするかもしれませんが、それはあなたの動機づけには役立ちません。
プログラマーがテストに優れている理由：
- プログラマーは論理的な思想家であり、体系的な方法での作業に優れている傾向があります。
- 経験豊富なプログラマーは、エッジケースをすばやく特定し、有用なテストを考え出すのが非常に得意です。 （正式なテストプロセスがある場合、これらのケースのほとんどすべては、システムテストの前にすでに識別およびテストされているはずです。）
- プログラマーは、すべての有用な情報がバグレポートに含まれるようにするのが得意です。
プログラマーが悪いテスターである理由：
- プログラマーはテスターよりも高価です（ほとんどの場合）。
- 考え方は根本的に異なります： "（機能する）製品を作成する"対 "このことは、（未知の）バグが存在することによるものではありません初期化。"
- 通常、テスターはより効率的です。つまり、同じ時間でより多くのテストを実行できます。
- プログラマーはプログラミングを専門としています。 QA専門家はテストを専門としています
プログラマは自分のコードをテストするが苦手だと思います。
私たちは、コードが要件に従って完全に機能すると信じて、そのようにテストします。私の場所では、独自のコードをテストしてから、実際のテストサイクルにリリースする前に他のコードをテストし、独自のコードをテストするよりもはるかに多くのバグをその方法でキャッチしました
プログラマーは、システムのいくつかの部分をテストするのに間違いなく適切な人々です-効果的にそれを行うことができるかもしれない場所で彼らだけです。
プログラマーがテストで非常に悪い傾向がある1つの場所は、全体が「通常のユーザーのようにUIを使用する」ビットです。つまり、通常のユーザーではなく、そのように動作しません。例えば：
- プログラマーは、テキストエントリを適切に取得することに長けている傾向があります。私が見るかなり一般的な問題は、先頭または特に末尾のスペースです。ほとんどの人はそれらのようには見えませんが、優れたプログラマーはおそらく、余分なスペースなしで自分の文字列を適切な文字列にすることを信仰しています。
- プログラマーはキーボード奏者になる傾向があり、タブやその他のショートカットを利用して作業をスピードアップします。通常のユーザーは、フィールド間でマウスをつかむ傾向があります。
- プログラマは、エラーメッセージを無視して[OK]をクリックするだけでなく、システムが何を伝えているかを理解する傾向があります。
したがって、通常のユーザーは、プログラマーが行わない多くのことを行います。 UATの開発チームに完全に依存することはできません。
技術レベル（単体テスト、統合テスト、回帰テスト）では、プログラマーはおそらくテスターになる資格のある唯一の人物です。これらの種類のテストは自動化可能であり、したがって自動化する必要があるため、プログラミングが必要です。
しかし、それはあなたが話していることではないと私は思います、そしてそれはジョエル・スポルスキーも意味するところではないと確信しています-それは残っている部分、実際の実践的な手動テスト：要件ドキュメントと機能仕様をテストスクリプトを作成し、完成した製品に対してこのスクリプトを細心の注意を払って実行します。
優れたテスターであるためには、優れたプログラマーを作るものとほとんど直交する性質が必要です。少しオーバーラップがあります-分析的に考えることができなければならず、一般にコンピューターとのある程度の親和性が必要です-それ以外は、テスターのスキルは大きく異なります。それ自体が、両方のスキルセットを持つことができるという意味ではありません。実際、かなりの数のスキルを持っている人もいるでしょう。ただし、本当に優れたプログラマーになるにはある程度の怠惰（家事を自動化したいという願望）が必要ですが、本当に優れたテスターには永続性（3,000のフォームフィールドすべてに不整合がないか確認する）が必要です。テスターになるために必要なことは、通常、その考えを嫌います。
そして、選択的なバイアスがあります。たとえほんの少しでも、すでにプロジェクトに関与しているプログラマは、コードベースに関する内部知識をすでに持っており、エンドユーザーの観点から、何も考えずにそれに取り組むのは難しいでしょう。 。 「このボタンが機能することはわかっているので、「合格」とだけ書きます）のように、明示的である必要はありません。それははるかに微妙な場合があり、それらの微妙な影響は、重要なEdgeケースがテストで見逃されることにつながる可能性があります。
私の経験から、はい、プログラマーは悪いテスターです。私は他の人を見て、私自身が「ハァッ、しかしチェックインする前にテストした！」あなたの前でバグを再現するテスターに直面したとき。
どうして？まあ、それがなぜなのかはわかりませんが、それは私たちが機能することを確認したいためです。または、この機能またはその機能のテストをすでにやり直したいだけです。
とにかく、テストは私たちが学んだスキルではなく、機能を壊すのが得意なので、プログラマーとしては働きません。また、適切なテスト計画を行う方法や、QAが行うその他すべてのことを行う方法がわからない場合もあります。テスターが新しい3Dレンダリングパイプラインを実装する資格を持つよりも、テスターの仕事をする資格がない。
問題のように、テストは自動化されたものではなく、プログラムを使用して実際にテストすることを意味します。
いくつかのレベルのテストがあります。 「低レベル」のテストは、開発者が行うことができ、また行う必要があります。ユニットテストで思う。
一方、「高レベル」テストは完全に別のことです。一般的に私は、開発者がスキルを欠いているからではなく、数時間で考える方法と作業方法を変更することが非常に難しいため、開発者は悪いテスターだと思います。
私はコードを可能な限りテストするために使用していますが、テスターが少なくとも10分行った後、バグまたは機能拡張を検討するための何かが発生します。つまり、作成したものをテストするのは大変です。どこをクリックするか、いつクリックするか、ビジネスロジックを知っているか、データがどのように永続化されるかを知っています。あなたは絶対に落ちない神です。
プログラマは、テストを定義するときにテストを細かく定義しますbeforeコードを記述します。練習すれば、さらに良くなります。
しかし、彼らが書いたコードのテストを定義するとき、彼らはあまりうまくいきません。彼らは、コードを書くときに持っていたのと同じテストでの盲点を持っているでしょう。
プログラマーを使用して手動テストを行うのはばかげています。手動テストはそれだけでばかげています。プログラマーにそれをさせることは非常にばかげています。それは高価であり、有能なプログラマを追い払う。
私が特に開発者が失敗するのを目にしたテストの1つのタイプは、要件が満たされているかどうかのテストです。開発者が要件の何かを意味することと、テスターがそれを意味することは、多くの場合、2つのまったく異なるものです。
最近、develoeprがデルタエクスポートを実行するように依頼され、開発者が一度も送信されていないレコードを取得することを意図していて、テスターは、新しいレコードと変更を取得することを意味すると考えました。彼らはクライアントに戻って、誰が正しかったかを見つけなければなりませんでした。私はコードをレビューし、開発者が要件について行ったのと同じ仮定を行いました。なぜなら、論理的には、更新を含めたい場合は、それらについて言及していたからです。そして、私は通常、ユーザーの側にいたので、あいまいなものを見つけるのが得意です。
したがって、テストを行う他の開発者も同じ仮定の多くを行う傾向があります。なぜなら、彼らも、「まあ、X副Yを意味するのであれば、詳細がたくさんあるので、私が行う前に答えるべき詳細がたくさんあるからです。しかし、要件作成者はそのように考えていません。したがって、要件作成者のように考える人は開発者の仮定をテストする必要があり、開発者ではない人は問題があることを確認するのにも優れた人です。
どのようなテストを意味しますか？包括的な徹底的なテストを意味する場合、そうしたテストの必要条件として考えられるすべての入力の組み合わせを考慮すると、ほとんどの人はこのカテゴリで貧弱になると思いますが、そうだとする理由がいくつかあります。
ソフトウェアを設計する開発者は、コードが何を処理するかに関してトンネルビジョンを持っている可能性があることを認め、考えられなかった可能性があるいくつかの境界ケースを無視します。たとえば、数値nを取り、画面に1からnまでを印刷するWebフォームを作成した場合、何も入力されていない場合や、eやpiなどの自然数ではない場合など、いくつかの特殊なケースを見逃す可能性があります。 。これらの場合にプログラムが何をすることになっているのかは疑わしいかもしれません。
テスト駆動開発 は、ここで別の見方をする可能性のある別の観点からテストを行う開発方法論の例です。