開発者は、単体テスト以外のテストを担当する必要がありますか？

現在、かなり大きなプロジェクトに取り組んでおり、JUnitとEasyMockを使用して、かなり広範囲のユニットテスト機能を使用しています。私は今、私が心配すべき他のタイプのテストに興味を持っています。開発者として、機能テストや回帰テストなどについて心配するのは私の責任ですか？これらをMaven / Ant / Gradleなどのツールで使用可能な方法で統合する良い方法はありますか？これらはテスターまたはBAに適していますか？私が見逃している他の有用なタイプのテストはありますか？

欠陥のないコードの提供に努めるのはあなたの責任です。提供するコードに自信を持たせるために、テストを作成、作成、またはテストの作成または実行を保証する必要があります。

注：欠陥のないコードを提供する必要があるとは言いません。むしろ、与えられた要件に応じて可能な限り最高のコードを書くことを試みるべきです。それができるということは、コードをテストする必要があることを意味します。

それが機能テストと回帰テストに個人的に責任があることを意味するかどうかは、主に会社がどのように組織されているかによって決まります。私が知っている最高の熟練したプログラマーのすべては、「タイプXのテストを書くことは私の責任ですか？」と自問しません。代わりに、彼らは「自分のコードが適切にテストされていることを確認するために何をしなければならないのか」と自問します。答えは、単体テストを作成するか、回帰にテストを追加するか、QAの専門家と話し、どのテストを作成する必要があるかを理解するのを助けることです。ただし、すべての場合において、適切にテストされていることを確認するために、作成しているコードに十分注意を払っていることを意味します。

結論：高品質のコードを提供する責任があります。そのため、機能テストまたは回帰テストを作成する必要がある場合は、実行してください。

これはあなたを助けるかもしれません：

Q1は開発者によって作成されました。

Q2は開発者によって自動化され、ビジネスやテスターと共同で作成されます。

私が見逃している他の有用なタイプのテストはありますか？

ガーキン言語を使用するBDDスタイルのフレームワークを推奨する受け入れテストがあります：JBehave（Java）、Cucumber（Ruby）、Behat（PHP）など。このタイプのテストには、単体テストよりもいくつかの利点があります。

• テストは開発者以外でも簡単に読むことができるので、顧客に見せることができます
• テストでは、実装の詳細に入らずにビジネスプロセスを明確に記述します（実装が重要ではないということではありません-確かです-しかし、ビジネス要件をコード自体から分離する方が良いです）
• テストは、ユーザーがアプリケーションを使用して行うことを行います
• 記述しやすい（IMHO、言語とフレームワークに依存する場合があります）：：笑がなく、技術的な詳細が少ない

機能テストは、単体テストと同様に自動化でき、プロジェクトのさまざまなコンポーネントがどのように連携するか、システムがビジネスルールをどの程度反映しているかをテストするのに非常に役立ちます。

また、この自動化されたテストは、ソフトウェアに対して行う必要のある大きな（または小さな）変更（バグ修正、リファクタリング、ビジネス変更、新機能など）の回帰および受け入れテストスイートとして機能します。これにより、開発者はそのための自信を深めます。

この種のテストにはいくつかのフレームワークがあり、フィットネスを使用して非常に良い結果が得られています。Webページのテストに非常に優れたライブラリがあり（WebアプリとWebサービスのテストに使用します）、MavenおよびJenkinsと非常によく統合されています。

また、開発者間で「クロス機能テスト」を実行していましたが、この種のテストは「繰り返し可能」ではないため、その有用性は限られています...

開発者として、私は自分自身がすべてのコードを単体テストする責任があると考え、欠陥がないことを最大限に保証します。だからこそ、モッキングなどの自由に使えるツールがたくさんあります。テストでモックオブジェクトを作成する目的は、コードを「外部」の世界から隔離して、正常に動作し、何かが失敗しても「あなたのせいではない」ことを保証することです。

それはあなたのせいではなく、コードが正常に機能しているという事実にもかかわらず、それはあなたが残りのテストで助けられないという意味ではありません。他の人が行った仕事にあなたの仕事を助け、統合することもあなたの責任だと思います。IT開発チームは、信頼性の高いソフトウェアを提供するための大きなチームとして、他の部門（QAなど）と協力しながら、毎回油を塗ったマシンとして作業する必要があります。

しかし、それはあなただけのものではなく、チームの仕事です。

明らかに統合テスト。それらは単体テストよりも重要であり、書くのがより困難です。それは家を建てるようなものです。単体テストでは、レンガが固体であり、圧力、温度、湿度、その他の条件に耐えることのみを保証します。しかし、レンガを組み合わせて家がどのように見え、どのように振る舞うかはわかりません。

大規模プロジェクト、特にコンテナ内にあるJavaプロジェクトの問題は、統合テストが難しいことです。そのため、大規模プロジェクトでのシステム統合テストを容易にするには、プロジェクト専用に作成されたテストフレームワークが必要です。これは、開発者がそれをコーディングする仕事です。最近、この分野で大きな改善が行われ、Arquillianのようなプラットフォームは、テストフレームワークの記述を大幅に簡素化します（またはそれを置き換えます）。

現実の世界では、チーム/ボスが責任を負うのと同じくらい責任があるだけです。すべての隅々を探してビジネスロジックのバグを上司（またはマーケティングの悪い方）が解釈するという気まぐれに飛びつくために労力を費やしている場合は、すべての責任を負います。

言い換えれば、あなたに与えられた範囲で必要なことをしてください。何らかの常識を投げたり、他の人があなたが構築している製品を使用して修正するユースケースや考えられる問題を理解したり、それを「修正」する前にチームや上司に知らせたりするのは良いことです。これには、選択したツールが含まれます。すべての努力は、全員が参加しているものでなければなりません。

あなたの質問が有用なバグ追跡の場合、私はbugzilla、google docs、zendeskまたはbasecampが通信システムの観点から好きです。

私はこれがすでにカバーされているとは思わない-それを逃した場合は申し訳ありません。

1つの問題は、開発者の時間の効率的な使用です。

開発者は、特定の種類のテストに長けているスキルを欠いていることがよくあります。一部、これは自然なことです。著者が編集者を持っているのと同じ理由です。近すぎると何かの欠陥を見つけるのは非常に困難です。しかし、それはまた、異なるスキルセットと異なる専門性についてです。

そのため、テストに時間を費やす開発者は、コストとメリットの点で貧弱です。その開発者は他のことを行うと生産性が高くなり、専門のテスターはテストを行うと生産性が高くなります。

もちろん、それは必ずしも有効ではないさまざまな仮定を行っています。たとえば、小さな会社では、テストに特化した人を雇うのは意味がないかもしれません。ただし、追加のサポートスタッフを雇ってテストを行うか、少なくとも自分で作成していないコードをテストするようにさせる方が理にかなっています。

QA向けにリリースされる前に、考えられるすべてのテストシナリオを網羅するのは（開発者でもある）私たちの責任だと思います。QAの目的は、ソフトウェアを検証することです。さらに、エラーのために独自のコードをハンマーで打つことで、QAの時間をいつでも見栄えよくすることができます。

どのテストケースが最も関連性があるかを開発者よりもよく知っている人。開発者は、すべての単体テストを行う責任があります。可能な場合、開発者はテストスクリプトの記述と実行を支援する必要があります。これは大規模プロジェクトではめったに可能でないため、開発者がすべてのテストケースをレビューするための時間を与える必要があります。さらに、開発者は知識を持ち、利用可能なさまざまな自動テストツールを使用する必要があります。

私の開発キャリアでは、開発チームとテストチームが緊密に統合されていれば、プロジェクトの成果が向上することがわかりました。

各チームの少なくとも1人のメンバーが、他の計画および実装会議にも参加する必要があります。