より多くの開発者テストを提唱しようとしているときに、「それは QA の仕事ではないのか?」という議論を見つけました。多く使われています。私の考えでは、QA チームにすべてのテストの責任を与えることは意味がありませんが、同時にスポルスキーや他の人々は、時速 30 ドルのテスターができることを時速 100 ドルの開発者に任せるべきではないと言っています。 . 専任の QA チームを擁する企業の他のメンバーはどのような経験をしていますか? 仕事の分担はどこに描くべきですか？
明確化: QA は検証および検証チームとしての意味でした。開発者は検証 (顧客中心のテスト) を行うべきではありませんが、検証 (機能テスト) の分割ポイントはどこにありますか?
これは、「ブラック ボックス」テスト (コードが何をすべきかはわかっているが、どのように機能するかはわかっていない) と「ホワイト ボックス」テスト (どのように機能するかを知っていると、どのようにテストするかが決まる) の違いです。「ブラック ボックス」テストは、品質保証について言及するときにほとんどの人が思い浮かべるものです。
QA チームがソフトウェア開発者でもある会社で働いています。(あなたが会社を推測したいのであれば、それは分野をかなり狭めます.) 私はジョエルの意見を知っています.のエラーは、コードの書き方を知っているホワイト ボックス テスターによってより効果的に発見されます (したがって、一般的な間違いは何か - たとえば、メモリ リークなどのリソース管理の問題)。
また、QA 指向の開発者は初期設計段階からプロセスの一部であるため、理論的には、プロセス全体でより高品質のコードを推進するのに役立ちます。理想的には、機能に精神的に焦点を当ててプロジェクトに取り組んでいる各開発者に対して、コードを壊す (したがってコードをより良くする) ことに精神的に焦点を当てている反対の開発者がいます。
その観点から見ると、開発者をテスターとして使用するという問題ではなく、1 人の開発者が品質管理に重点を置いている一種の切断されたペア プログラミングです。
一方、多くのテスト (基本的な UI 機能など) では、率直に言って、そのようなスキルは必要ありません。そこがジョエルの狙いです。
多くの企業で、プログラミング チームがコード レビューとテストの義務をお互いのコードでトレードオフするシステムを目にすることができました。たとえば、ビジネス ロジック チームのメンバーは、ときどきツアーに参加して、UI チームのコードをテストおよびレビューすることができます。また、その逆も可能です。そうすれば、フルタイムのテストで開発者の才能を「無駄にする」ことはありませんが、コードを (できれば) 専門家の精査と処罰にさらすという利点を得ることができます。次に、従来型の QA チームが「ブラック ボックス」テストを行うことができます。
必要に応じて、開発者ではなく、品質管理チームがセキュリティ、リグレッション、ユーザビリティ、パフォーマンス、ストレス、インストール/アップグレードのテストを実施できる必要があります。
開発者は、最小限の目標として、記述されているコードのコード カバレッジで単体テストを行う必要があります。
その間に、まだかなりのテストが必要です
これらに対する責任は、何が最も理にかなっているかについての相互の合意に基づいて、QA と開発の間で混合されます。一部のコンポーネントのテストは単体テストでしか実行できませんが、他のコンポーネントは統合テスト中に「十分に」テストされます。
お互いに話し合って、誰もが最もやりやすいことを見つけてください。少し時間がかかりますが、それだけの価値があります。
開発者のテストは常に行う必要があります。開発者があまりにも多くのバグを作成している場合、開発者は後でそれらのバグを修正するために時間を無駄にしています。開発者が、バグを残せば見つかって修正する機会が得られるというような態度をとらないことが重要です。
発生するバグのしきい値を維持しようとします。テスト中にこのしきい値を超えた場合、開発者はそれに対して責任があります。このしきい値を決定するのはあなた次第です (私たちにとっては、プロジェクトごとに異なる場合があります)。
また、すべての単体テストは開発者によって行われます。
私は業界に 1 年しかいませんが、私の経験では、開発者は機能の単体テストを担当し、QA はシナリオのテストを担当しています。QA では、境界条件をテストすることも期待されます。
質問に対する回答を社内フォーラムに貼り付けています。あなたが1時間かそこらを持っているならば..スピードビデオに基づいてメアリーポッペンディークの競争を聞いてください。おすすめされた
注（テスターによる-私はQAチームを参照します）
開発者/単体テスト________=_______ ユーザビリティテストと探索的テスト
'================================================= =================
受け入れ/顧客テスト___=_____プロパティテスト
それが4つの象限を持つ正方形であると想像してください。:)
左半分は自動化する必要があります。
右半分は、優れたテスターの時間と労力をより有効に活用しています。たとえば、自動テストではXダイアログが使用可能かどうかを判断できません。人間は機械よりもこれが得意です。
テスターは、左半分のテスト計画の実行に時間を費やすべきではありません。これは、コードが顧客と開発者の意図したとおりに機能することを保証する開発者の責任です。テスターは、実際に顧客が受け入れテストを策定するのを助けることができます。
テストは可能な限り自動化する必要があります。これにより、テスト担当者が自動化されたテスト スイートに追加されるコードを作成している場合、開発作業に戻ります。
また、コード レビューで多くの QA が行われていることがわかりました。人々は、レビューされている単体テストに追加してほしい追加のエッジやコーナー ケースを提案するからです (もちろん、テストするコードと一緒に)。 .
私の一般的なスタンスは、テスターはユニット レベルのバグ (境界ケースを含む) を決して見つけてはならないということです。テスターが見つけるバグは、コンポーネント、統合、またはシステム レベルである必要があります。もちろん、最初はテスターは「ハッピー パス」バグやその他の単純なバグを見つけるかもしれませんが、これらの異常は開発者の改善に役立てるべきです。
問題の一部は、1 時間あたり 100 ドルの開発者と 1 時間あたり 30 ドルのテスターを使用している可能性があります:}。しかし、コストに関係なく、開発サイクルの早い段階で発見されたバグは必然的に安価であることを知っているので、開発者にもっと多くのテストを所有させることでおそらくお金を節約できると思います. 高給取りの開発チームとハック テスターがいる場合、多くの明らかな大きな問題が見つかる可能性がありますが、後で出くわす多くのあいまいなバグを見逃すことになります。
したがって、あなたの質問に対する答えは、テスターは好きなだけテストする必要があるということだと思います。すべてのテスターを解雇して開発者にすべてのテストを行わせることも、大勢のテスターを雇って開発者が望むものを何でもチェックインさせることもできます。
開発者のテストが最も効率的で最高の見返りとなるいくつかの方法を次に示します。
3 番目の例で開発者がどれだけのテスト義務を実行する必要があるかについては議論の余地がありますが、開発者にとって最も効率的であると私は主張します。なぜなら、ドキュメントとコードの多くの層からの関連する細目はすべて、すでに彼女の短期記憶にあるからです。この完璧な嵐は、事後にテスターが達成できない可能性があります。
QAまたは検証について話しているのですか？検査チェックリスト、コード標準の施行、UI ガイドラインなどに沿った QA について考えます。検証について話している場合、開発者が正式なテスト ケースの作成と実行に多くの時間を費やすことは意味がありませんが、開発者は優れたテストを作成するために必要なすべての理論的根拠と設計ドキュメントを提供する必要があります。