テストを行うプログラマ

プログラマーが帽子をかぶって、お互いの作業をテストするのがどれほど典型的なことかと思います。チームが、タスクの形式化からリリースへの移行に「責任を共有する」アプローチを取りたいと仮定します-

1. プログラマーが機能を記述しない限り、ソフトウェアテストとして作業することをお勧めしますか？

2. これは頻繁に起こりますか？

3. プログラマが自分の作業をどの程度「テスト」できるか？

TDDと単体テストを使用しても、開発プロセスでソフトウェアテスト装置がまだ必要ではありませんか？

1. プログラマーにそれらの機能をテストしてもらうことは、混合バッグになる可能性があります。一方では、プログラマーはコードブロックに「慣れすぎ」ている可能性があり、よく知られているパス/フェイルタイプのパラメーターを簡単にテストできます。一方、コードに「慣れすぎている」プログラマーが機能を機能させることに熱心である場合、関数の内部動作と潜在的な抜け穴を知っているため、問題を引き起こす可能性のあるフリンジケースについてより多くの知識を得ることができます。その中で。

2. これは頻繁に発生すると思います。プログラミングショップの大部分は小規模なチームに属しているか、または物事を成し遂げるために多くのプレッシャーがかかっていると思います。これでは、グループ内の専用のQA /テスターの贅沢は得られないので、誰もが共有する必要があります。アプリのライフサイクル全体に各開発者が本質的に責任を負う「ローンカウボーイ」ショップはまだまだかなりあります。それが私の場合です。

3. これについては、1番に延期します。プログラマーは、機能がどのように機能するかについて深い知識を持っているため、TDDモデル以外でも自分の作業をテストできると思います。彼らは「一歩下がる」ように注意し、コードの特定の広範な問題（テキスト入力フィールドの「太った運指」-どうなるかなど）をカバーできるようにする必要がありますが、それは可能です。

お互いのコードをテストする開発者は、焦点を絞ったQAスペシャリストによるテストの代わりに行われるべきではありませんが、さらにすばらしいでしょう集中テスターに​​よるテストに。開発者は、製品を機能させる方法について考えることに熟練しています。テスターは、製品がどのように失敗するかを理解することに焦点を当てているチームの唯一の人々（BA、PM、開発者など）です。それは非常に異なる考え方です。シャワーを浴びながら頭の中でプロジェクトの概要を説明するときなど、「ダウンタイム」の作業について考えてください。「ああ、これはその機能に取り組むための良い方法だと思います！」それとも、「ねえ、私がこれをやればそのコードが失敗するかどうか確認すべきだ！」と思いますか？仕事はオフィスで起こるだけではなく、開発者はおそらく「自由な時間」にコードを壊すことに取り組んでいないでしょう。テスターは、テストツールとテスト手法に関する幅広い知識と、開発者が持っていないそれらの間で選択した経験も蓄積する必要があります。

同時に、学際的な経験は非常に良いことであり、他の開発者のコ​​ードを操作することには常にメリットがあります。特定のQA /テスト担当者がコードを確認する前に開発者がテストにもっと力を注ぐと、おそらくコードの品質が向上し、テストのターンアラウンドが速くなり、テストカバレッジが向上し、削減（ただし、排除されない）する可能性があります。必要な専用テスターの数。

人数が少ないために実際にトレードオフを行う必要がある場合、またはQAのスキルプールが現在の場所で非常に悪い場合、この設定は何もないよりはましですが、目標は実際のテスターに​​なることです。チームが大きくなりすぎる前に。

悪いテスト方法を見たことがない。

プログラマは自分のコードをテストする必要がありますか？はい-明らかに。

他の人が自分のコードをテストする必要がありますか？はい-明らかに。

カバレッジテストは良い考えですか？はい。

モンテカルロテストは良いですか？はい。

テストのためにかなり良い設定と考えられるものを手に入れ、次に新しい人がいくつかのテストを行います。何だと思う？彼らは以前に発見されなかった問題を見つけます。

品質が良くなっている兆候は、実際にはバグではないテストで見つかった問題の割合が100％に近づいたときです。

テスト駆動開発（TDD）と呼ばれる、大きく成長している開発運動があります。私はエキスパートであるとは主張しておらず、デフォルトでこのメソッドを実行することに頭を悩ませていますが、要点は、開発者が最初に失敗したテストを作成し、次にそのテストに合格するためのコードを作成することです。

このコンセプトには多くの長所があります。1つは、すばらしいテストセットがあることです。もう1つは、これは多くの小さな増分で行われるため、何かを壊した場合にすぐにわかるということです。この方法と他のすべてのテストの「義務化」で私が見たことの1つは、開発者が優れた機能を備えているため、余分な機能を追加する必要がないことです。機能には常にコストがかかり、多くの場合、開発者はそのコストを見たり感じたりしません。コードを記述する前にテストケースを記述するため、TDDを使用します。

この理論には拡張機能があり、テストの記述を要件ソースに取り入れ、ビジネスエキスパートが仕様を構成する一連の機能テストを記述し、開発者がその一連のテストケースを開発します。

したがって、TDDを使用すると、開発者は多くのテストを記述します。テストコードの行とコードの行の比率が1：1であると主張する人もいます。

これを好転させる-私は、コーディングよりもテストに優れているチームのために少なくとも数人を採用することに大きな価値があると思います。それは開発とは異なるスキルセットであり、TDDやその他のアジャイルプラクティスを使用しても、テストに優れた目を持つ人は製品の品​​質にとって非常に貴重だと思います。

質問するのは簡単です-テスターは、コーダーがテストしているのと同じくらいコーディングする必要があります。

IMO-はい、少なくとも少しはミックスする必要があります。製品の生産のもう一方の端に視点を持っていると、あなたは丸みを帯びたままであり、新しい洞察を上げるかもしれません。

コードの一部をチェックインしてサインオフする前に、かなりまともな量のデューデリジェンスを行うのはプログラマの責任だと思います。これは、次のことを意味します。

• 完全な単体テストを作成します。
• 実際の使用シナリオでそのコードをテストし、それを壊そうとします。つまり、本番環境で使用されるようにコードを操作します。

...

• 次に、別のプログラマーがそのコードと単体テストを確認する必要があります。

• 次に、専用のテスター/ QA担当者がそのコードをテストする必要があります。

最初の3を行わない理由はないと思います。最後のステップを行わない理由はないと思いますが、コードのすべてのビットを専用のテスターがテストすることは高価で小規模な会社です（少なくとも考えてみてください）これは彼らが買う余裕のない贅沢だと思います。

個人的には、特定のテストが方程式から除外されるべきではないと私は信じています。少なくとも同じ製品（またはおそらく大きなモジュール）を開発していない人を見つける必要があると思います。そうすれば、実装が何であるか本当にわかっていない限り、他のプログラマーもテストできます。最も重要なことは、今までになくても、開発者はテスターとして機能でき、テスターは開発者として機能できる必要があるということです。知識ベースと親しみやすさの両方があると、開発、テスト、および2つの間の通信がはるかに簡単になります。

1. はい。ただし、「ソフトウェアテストとして機能している」わけではありません。テストを書くことはプログラマーの仕事の一部です。また、優れたテストを書くこともスキルです。独自の機能を適切にテストできないことは、テストの欠陥ではなく、スキルの不足の指標です*。

2. 私は確かにそう願っています。

3. プログラマは自分の作業を完全にテストできますが、外部QAプロセスに価値がある場合があります。しかし、私はそれが事実であることをめったに発見しませんでした。

テストの目的は3つあります。

1. 開発を推進する
2. 変更を管理するには
3. 自信を与える

開発者のテストは、これらの目的のすべてに役立つことができ、役立つはずです。開発者のテストで十分であれば、それ以上テストする必要はありません。

*ペアプログラミングでは、独自の機能をテストすることはないため、このような悪いテストを書くのはさらに難しくなります。