開発者はテスト段階に関与する必要がありますか？

従来のV字型の開発プロセスを使用しています。次に、要件、アーキテクチャ、設計、実装、統合テスト、システムテスト、および承認があります。
テスターは、プロジェクトの最初のフェーズでテストケースを準備しています。問題は、リソースの問題（*）が原因で、テストフェーズが長すぎ、時間の制約があるために短縮されることが多いということです（プロジェクトマネージャーは知っています...;））。開発者は必要に応じてユニットテストを行っています。

したがって、私の質問は簡単です。開発者がテスト段階に関与する必要があるかどうか、それはあまりにも「危険」ではありません。作業が完了したので、プロジェクトマネージャーに良い品質の誤った感覚を与えることになると思いますが、追加されたman.daysは何か価値がありますか？私は、開発者がテストを行うことに自信がありません（ここでは問題はありませんが、数日間に数回のクリックで中断するのは非常に難しいことは誰でも知っています）。

ご意見をお寄せいただきありがとうございます。

（*）あいまいな理由から、テスターの数を増やすことは現在のところオプションではありません。

（ちょうど前もって、それはプログラマーがテストを設計する際にテスターを助けるべきか？の複製ではなく、テストの準備ではなくテストの準備について話し、開発者の影響を回避します）

あなたの質問を非常に文字通り（「関与する」）見ると、私の唯一の答えは絶対的に明確です

はい

開発者は自分のコードに最終的な発言権を与えるべきではありません。

ただし、開発者は他の開発者の作業のテストに関与する必要があります。次の2つのことを行います。

1. テストに開発者の洞察をもたらします。これは、特定の時点でおそらく使用されているAPI、それらのAPIから発生する可能性のある例外、およびそれらの処理方法を知っているという一般的なケースの両方です。開発者はQAが通常行うよりも、なぜ何かが行われているのかについてのさまざまな議論に多くの露出を得るので、QAがしないはずのエッジケースを見つける可能性があるため、特定のプロジェクトにも役立ちます。開発者は通常、より多くの情報を提供し、すぐにそれを修正する方法についてより多くの洞察を提供するため、開発者が見つけたバグは、修正する方が安くなる可能性もあります。
2. それは、開発者が他の方法ではさらされない可能性のあるアプリケーションの一部を公開します。これにより、長期的にはそのアプリの開発者がより良くなります。私のAPIがどのように使用されるかを知っていると、スペックを追い払うだけの場合よりも、次にすべきことを予測するのがはるかに上手になります。最も重要なのは、アプリケーションとその使用法を知っていれば、コーディングを開始する前に仕様が間違っていることを知ることができるということです。

最後に、なぜあなたはできるだけ多くの目を使わないのですか？採用とオンボーディングのプロセスを経て、追加のQA担当者を派遣する余裕はほとんどありません。それで、あなたはあなたが必要とする余分な目をどこで見つけますか？それとも、これまでと同じ数のQAでクランチタイムを乗り切ろうとしていますか？開発者が時間の20％を費やしてテストを行い、80％がバグを修正する場合でも、以前よりもアプリに注目しています。自動テストでは、特定のレベルの保証しか得られず、100％になることは決してありません。

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

ユニットテスト以外では絶対にそうではありません。開発者は、アプリについて、そして客観的なテスターに​​なるためにどのように機能することが「想定」されているかについて知りすぎています。

開発者とQsの間のテスト哲学の根本的な違いはこれです。通常、プログラマーは自分のプログラムをテストして、コードが機能することを証明します（「ポジティブ」テスト）。QAはこれを実行できますし、実行しますが 、ソフトウェアを破壊しようとすることによって（「ネガティブ」テストを使用して）、何が機能しないかを見つけることに焦点を合わせています。

ソフトウェアが機能することを「証明」するプログラマーテストによってQAスタッフが破損する可能性がある限り、開発者テストとQAテストは分離されている必要があります。開発者は、何が機能するかを示すことにより、QAテストを確実に支援できますが、ソフトウェアが壊れないことを個別に確認するのはQAの責任です。

プログラマーがテスト作業を支援するためにできる最善のことは、要件ドキュメントの個々の要件に合わせたテストを含む、包括的で高品質で検証可能な単体テストスイートを提供することです。

テストに関しては、3つのタイプがあります。

ブラックボックス、グレーボックス、ホワイトボックス。

ブラックボックスは、製品が内部でどのように機能するかを知らない、製品をテストするユーザーを指します。

灰色のボックスは、コンピュータープログラミングの知識はあるが、開発チームには属していないパワーユーザーを指します。これらの人々は、製品にメモリリークやシステム要件の問題などがあるかどうかをテストします。

主な部分は次のとおりです。白いボックスは、コードレベルで製品をテストする開発者を指します。つまり、ユニットテスト、デバッグなどを行っているということです。

したがって、ユーザーと開発チームがすべてテストフェーズに関与するのは良いことですが、各テストでは、テスト対象に応じて、ユーザーと開発チームからの適切なコミットメントレベルが必要です。

ユニットテストはすべての開発者にとって必須です

これをどのように利用できるかについては、C ++開発を行っている場合は、次のリンクを参照してください。

• Google C ++テストフレームワークの簡単な紹介
• オープンソースのC / C ++ユニットテストツール、パート1：Boostユニットテストフレームワークを理解する
• オープンソースのC / C ++ユニットテストツール、パート3：CppTestを理解する

QA担当者がこれらのテストを行う方法はありません。ありえない。

プロジェクトにかなりの数の開発者がいるとすると、必ず開発者がテストに取り掛かります。注意点の1つは、開発者が自分のコードのテスト（ユニットテストは含まない）を行わないことです。

開発者ではなく、管理スタッフ（または実際の潜在的なユーザー）がQAテストを行うことを望みます。製品がどのように機能するように設計されているかを知らない人は、それを使用する必要があります。開発者は、テストへの取り組み方が非常に制限される傾向があり、率直に言って、1時間あたりのコストが高すぎてQAテストにも使用できません。

あなたが書く：

問題は、リソースの問題（*）が原因で、テストフェーズが長すぎ、時間の制約により短縮されることが多いということです。これは、開発者がテストを行っていないためです。最高の最も安定した製品を提供している最大のインターネット企業の1つは、テスターをまったく使用していません。自動テストのみを使用しており、すべて開発者自身が行っています。結果は、開発者がテストを「テスター」に任せる場合よりも10倍優れた製品です。

それは、建設労働者があなたの家を建てるようなものですが、別のチームに、建物が実際に立っている、ドアが開閉している、空調が機能しているなどのことを確認してもらいます。信頼できない。