開発者に自分の作業をテストさせる/させない理由

製品が生産される前の最後のステップとして開発者が自分の作品をテストできるようにするのは悪い考えである理由についていくつかの議論を集めたいと思います。 、ほとんどの人が他のことで忙しすぎて、プログラムのその部分に別の人を慣れさせる時間がないという議論は要約されました-それは非常に専門的なソフトウェアです）。

この場合のテスト計画はありますが（常にではありませんが）、テストされた変更を行わなかった人が実際に最終テストを行うことを非常に支持しています。ですから、次回議論する際に持ち出せる議論の良いしっかりしたリストを提供していただけないかとお願いしています。または、特にテストする正式なテストケースがある場合にこれが完全に問題ないと考える場合に、反論を提供するために。

他の人（およびあなた自身）が指摘したように、開発者は自分のコードを単体テストする必要があります。ただし、その後、自明でない製品も独立した人物（QA部門および/またはクライアント自身）によってテストされる必要があります。

開発者は通常、「この作業を行う方法」という開発者の考え方で作業します。。優れたテスターは、「これを破る方法」について考えています。-非常に異なる考え方。ユニットテストとTDDは、開発者にある程度帽子を変えることを教えますが、それに頼るべきではありません。さらに、他の人が指摘したように、要件を誤解する可能性が常にあります。したがって、最終的な受け入れテストは、できる限りクライアントに近い誰かが実施する必要があります。

開発者はコードがどのように機能するかを知っており、この知識に従ってコードをテストする習慣に陥ります。

開発者は、「どのように機能するか」ではなく、「どのように機能するか」という考え方から自分自身を取り除くことは難しいと感じるでしょう。

このため、QAやテストエンジニアなど、客観性の高い人にプログラムをテストしてもらうことをお勧めします

テスター破るテスト、シンプル。 ショーストッパーを実際に見つけるには、このタイプのバイアスが必要です。

開発者は作業をテストする必要があります。それは暗黙の責任です。

私はあなたの声明に基づいてテストを行うための専用のチームがないと仮定しています。ただし、開発者がコードをコーディングした方法でテストする傾向があるため、テスト専用のチームを持つことは非常に役立ちます。ある種の品質保証チームができたら、開発者の責任としてテストを既に受けられるということではありません。

開発者は通常、バグを見つけるために大きな穴のあるネットを使用します。その結果、小さなバグが回避されます。

開発者は自分のコードを壊そうとするのが苦手だからです。彼らの心は、データ入力とアプリケーションとの相互作用の正しい道をたどるだけです。多くのバグは、通常の人のようにシステムと対話することの結果です。開発者は通常のユーザーではありません。彼らはプロのユーザーです。

専任のテストチームを配置するのには、いくつかの正当な理由があります。まず、前述のように、開発者はコードが機能するかどうかをテストするのが得意ですが、それを壊すことはできません。

また、あなたが言うように、開発者は彼らが書いたものを知っていますが、テストチームは何を書かれるべきかを知っています。時々、これらの2つの概念は一致しません。テストチームの仕事の1つは、ソフトウェアが要件を満たしていることを確認することです。多くの場合、開発者はシステムのほんの一部を非常によく知っていますが、QAチームはすべてを知っています。

次の理由は、テストチームが完全な統合テストを行うことです。あなたが書いたコードはそれ自体でうまくいくかもしれませんが、あなたが知らなかった他の機能を壊す可能性があります。

QAチームと一緒に仕事をしたことはありますが、彼らの仕事に100％感謝し、ソフトウェアチームの重要な部分であると言います。QAチームがいると、コードのリリースがはるかに簡単になり、完全にテストされていることを知っているため、午前3時の呼び出しが少なくなります。

開発者は独自のコードを単体テストする必要があります。

独立したテスターは、破壊するかどうかをテストするだけでなく、開発者がコーディング中に行った、記述されていない未定義の仮定をテストします。

開発者は、変更をコミットする前に初期テストを行い、コードが機能することを確認することを期待しています。その後、開発者がテストケースに彼らが持っている特定の「ホワイトボックス」知識を入力することを期待します。たとえば、影響を受ける可能性のあるコードの他の領域の詳細。

開発者が独自のコードをテストすることに対する主な反対は、1つのビューポイントのみをテストしているということです。開発者は仕様を読み、解釈しました。仕様が明確で完全で明確であることを願っていますが、常にそうであるとは限りません。開発者が仕様の一部を誤解している可能性があります。独自のコードをテストする場合、関数が期待どおりに動作することがわかるため、これはキャッチされません。

異なる人々はまた、製品を異なる方法で使用する傾向があり、その結果、コードを介して異なるルートを取ることになります。開発者は、コードが確実に機能することを保証しますが、別のテスターが見つける可能性のあるエッジケースを考慮していない場合があります。

開発者は自分の作業をテストする必要があります。開発者がテストされていない作業をQAチームや開発者の同僚にプッシュできるようにすることは、本当に悪い考えです。開発者とテスターの時間を無駄にし、関係を台無しにします。

ただし、それだけでは十分ではありません。開発者は、システムを介して幸せな道をたどるか、開発中に何度も何度もさらされてきたいくつかの特異性に目がくらんでいる可能性があります。

もう1つのポイントは、仕様と展開の間に多くのコミュニケーション層があることです。これにより、最終的なデプロイ可能オブジェクトに中国のささやき効果がもたらされる可能性があります。要件またはバグレポートのテストを定義した人が、希望どおりに動作することをお勧めします。

開発者は自分のコードを担当しているので、テストする必要があります。Does the feature work as expected?答えが「はい」の場合、完了です。

なぜテストケースをすべきではないのですか？

1. 発見されたバグはあなた（またはあなたの同僚）によって書かれているため、あなたは主観的です。
2. あなたもある高価な場合、テストを実行するには、会社のために。（私は願います）。

通常、開発者は、特定の特殊な場合を除き、ほとんどの場合、コードを使用する開発者ではありません。したがって、運用システムに昇格する前の最後のテスト手順は、ユーザー受け入れテスト（UAT）である必要があります。一般的に、彼らはパッケージが何をしていると期待しているのかをよく知っています。一般的に、日常的に使用しない人には馴染みのないエントリフローで物事を壊すことができます。

プロジェクトはユーザーテストに対応していませんか？ユーザーにそれをテストしてもらうと、実装後のバグよりも早くバグを発見する可能性があります。

開発者は自分のコードをテストするべきではありません。それはあなた自身の子供の芸術を判断することに似ているからです。どちらにしてもあなたに美しく見えるでしょう、そしてあなたは本当に欠陥を指摘するために専門家が必要です。一方、単体テストは、子供が鉛でペイントしようとしていないことを確認することに似ています。

本当にQAを雇いたくない場合は、開発者に他の開発者向けのテストコードを作成してもらってください。これは良い第一歩です。開発者はCRに加えて他のコードの問題のテストに多くの時間を費やしているため、開発者はすぐにQAリソースを要求します。

開発者がコードを保護しているだけでなく、特定のケースを認識していないか、何かを開発する方法で仕様を誤って解釈している場合、コードをテストするときにそれらのケースを見逃します。

テストのテクニックとスキルも非常に異なります。

テストチームによるほとんどのテストは、機能的（製品が仕様に従って機能する）であり、ブラックボックス（テストチームはアプリケーションの内部動作を確認しません）です。機能テスターは、物事がどのように機能するかを気にする必要はなく、機能するかどうかにのみ焦点を合わせる必要があります。

私の経験では、少なくとも私の小さな組織では、エンドユーザーがテストする必要があります。私たちが手に入れるほとんどすべてのプロジェクトは、必要なすべての情報を提供するのに失敗し、常に特定の詳細を省略しています。開発者は、ユーザーの仕事をする方法がわからないため、常にテストで不利な立場にあります。したがって、提供された情報に従ってソフトウェアが機能することは知っていますが、エンドユーザーに役立つかどうかはわかりません。彼らの仕事をします。

開発者は要件を誤って解釈し、その要件の責任者は重要なものを指定できないことがよくあります。開発者以外の誰もテストしない場合、誰もこれらの接続解除を見つけることができません。開発者がテストするとき、彼らはそれがどのように機能するかについてあまりにも多くを知っており、ユーザーが試みるかもしれない愚かなことをしようとしないでください。開発者はまた、要件の解釈に基づいてテストを作成しますが、これは多くの場合、実際の意味ではありません。したがって、テストは合格しますが、要件は満たされませんでした。別の人がテストを行う場合、その人は要件について異なる考えを持っている可能性があり、2人の異なる人がどのように解釈するかによって求人が不十分に表現された場所を見つけることがよくあります。ライブで公開した後よりも、テストでこれを見つける方がはるかに優れています。

開発者は、私たちが持っている要件に従って、コード化した部分が期待どおりに機能することを知るために、初期テストを行う必要があります。そのため、通常のテストを行い、作成したコードの単体テストを作成しました。

次のステップは、コードを作成するときに開発者に見えないものを見つけるQAの仕事です。開発者はより高いレベルで考えますが、ユーザーは同じレベルで考えないかもしれません。開発者が自分の作品をテストしていて、テキストボックスにテキストを入力する必要がある場合、ユーザーは常に完全な文字列を入力することもあります。ユーザーがそれを行うこともありますが、テキストに％＆$ ^などの特殊文字を入力すると、アプリケーションが壊れてしまい、エンドユーザーには見栄えがよくありません。開発者は、そのように考えるように訓練されていないため、発生する可能性のあるすべての可能性について考えることはできません。QA（テスター）に関しては、ユーザーが愚かではなく、このアプリケーションを中断し、本のすべての愚かなことを試みるためにユーザーが何をするかについて常に考えています。

また、一般に、同時に複数の作業が行われ、両方が生産されることを理解する必要があります。開発者は自分の作品だけをテストし、それがうまく機能していると考えることができますが、プッシュされているすべての作品について全体的な回帰テストを行う必要があります。よく見えません。また、負荷テストのシナリオや、テスターがより精通しているその他のことも考慮する必要があります。

最後に、UAT（User Acceptance Test）を実行して、行った部分が予想どおりかどうかを確認する必要があります。一般に、要件はBAを通過しますが、最終的な人はそれがどのように見えるかを正確に知らない可能性があり、彼/彼女は期待したものではないと思うかもしれませんし、見た目を良くするために何か他のものを追加したり、何らかの理由でスクラップするかもしれません彼らは作品が既に利用可能な機能では行かないと思うので、作品全体。

上記で説明したように、これらは非常に重要であり、開発者だけでは実行できず、アプリケーションが正常に機能するために絶対に必要です。これは保守的なアプローチであると経営者は言うことができますが、より良いアプローチです。上記にいくつかの調整を加えることはできますが、全体として回避することはできません。

上記のコメントには大きなポイントがあります。

以前に言及されていない追加の1つは、個別のテストコードを持つことで、要件の追加チェックとして機能し、システムがそれらを正しく実装しているかどうかです。

要件とドキュメントは完全ではなく、多くの場合、実装は開発者による要件の解釈の結果です。

テストが別の個人によって行われる場合、テスト計画を作成してテストを実行するときに、要件の独自の解釈も提供します。

テストアクティビティが開発アクティビティから独立して行われ、両方の結果が「同意する」場合、システムが正しく、要件の当初の意図に完全に一致するという追加の確認が提供されます。

プログラマーは、テスト時に「Quantity」というラベルの付いたテキストボックスが表示され、「1」と入力します。その後、経験豊富なプログラマーが値「2」でフォローアップテストを行います。

ユーザーには「Quantity」というラベルの付いたテキストボックスが表示され、「~~ unicorns ROX !!! ~~」と入力されます。経験豊富なユーザーも「-12 1/2」を試してみます。

願わくば、テスターがそこにいて、ユーザーがこれらのことをするときに経験することをプログラマーに警告するでしょう。

1つの理由は、開発者が自分のコードに近すぎるためです。彼らはそれが奇抜であることを知っています、それは少し奇妙な振る舞いです。彼らはテストする傾向があるの周りに、彼らはとてもよく知って少し癖。彼らはそれについて十分客観的ではありません。テストチームはそれをブラックボックスのように扱います。数十または数百のテストケースのマトリックスを作成し、それらを系統的に実行して、コードが何をするかを確認します。多くの場合、開発チームが夢にも思わないシナリオを思い付きます。

もう一つの理由は時間です。段階的に構築される大規模プロジェクトの場合、開発チームは段階1を構築します。その後、テスターは段階2の構築中にテストを行い、段階1の欠陥を修正します。これはすべてのステージで継続するため、テスト対象のステージはビルドされた前のステージです。

開発者がテストを本番に移行する前の最後のステップとして自分の作業をテストできるようにするのは悪い考えである理由についていくつかの議論を集めたいと思います。残念なことに、私の仕事の場所は時々これを行うためです、ほとんどの人が他のことで忙しすぎて、プログラムのその部分に他の人を慣れさせる時間がないという議論は要約されました-それは非常に専門的なソフトウェアです）。

開発者にとってテストはオプションではありません。開発者は、書いたコードをテストする必要があります。彼は他にどのようにして、タスクが正常に完了したことを確信できますか？何らかの種類の自動テスト（ユニットテスト）を記述するか、「GUIを使用して、コマンドラインでコマンドを呼び出すなどして」手動で「マシンが実行したいことを実行している」ことを確認する必要があります。

その後テストされているものはすべて、他の人（同僚、QAなど）による「唯一の」追加テストです。開発者による直接テストに代わるものはありません。開発者は、彼が書いたコード/機能をテストする必要がない（または許可されていない）と私に言う人は誰でも、ソフトウェアの開発方法をまったく理解していません。

コードが好きかどうかに関係なく、コードに不慣れな人がテストします。問題は、その誰かを顧客にしたいかどうかです。

いい質問ですね。あなたの状況では、テストケース（時には）が存在し、ソフトウェアが十分に複雑であるため、初心者が製品を使いこなすのは実用的ではないようです。また、実行されるテストは生産前の最終テストであると言います

開発者が最終テストをしても大丈夫かもしれない理由

• 他にも十分なテストカバレッジがあります。単体テストが存在し、統合テスト環境が存在し、使用されている、UIテスト、探索的テストなどが実行されているなど。その後、最終テストは最終的な「駆け抜ける"
• プロのSQA /テスターに​​よって作成されたテストケースのセットが存在し、誰か（開発者）が明示的に従う/できる必要がある
• それ以外の場合、機能/製品/モジュールの障害のリスクは低レベルに軽減されました（専門家は高リスク領域をテストし、「新人」は低リスクをテストします）
• ビジネス状況の現実は、潜在的な欠陥のある製品をリリースする方が、リリースを遅らせるよりも良いということです。
• 問題の開発者は実際には非常に有能なテスターでもあり、精神的に役割を変更することができます
• この変更は、システムがオフラインになっているために顧客のサイトがシャットダウンされるか、収益を失ったときに開発者によってフィールドで行われたバグ修正です（パッチはオフィスに戻され、できるだけ早く管理バージョンでテスト/リリースされます） ）

開発者がテストを行うべきではない理由

• 他に何か

一般に、実際のソリューションを攻撃する正しい道を進んでいるようです-SQAエキスパートにテストケースを生成してもらいます...

注：一般に、開発者にテストを行わせることに賛成ですが、最初の箇条書きが存在することを確認します。...

人間は人間であるため、認知バイアスに苦しむ傾向があります-2つのほぼ同一のシナリオでの判断が、単に変化したいくつかのことのために異なる場合-開発の8年で気づいたことの1つは、開発者が同僚が書いたコードとは対照的に、自分のコードのテストに直面していますが、自分のコードで実行されたテストは品質がかなり悪いです。

これは、開発者が直接過失であると言うことではありません-彼/彼女の脳は、彼らが書いたバイアスを使用して、彼らが正しいと信じているという事実を補強し、開発者とは対照的に、基本的なチェックのみを実行します他の人のコードを見て、より徹底的なチェックをたくさん行います。

認知バイアスを防ぐための手順が導入されている例、または航空管制のコンピューターシステムなど、一般に「ヒューマンファクター」として知られている2つの異なる航空機が同じ空域を占有するのを防ぐための例が何千もあります時間、医療処置に配置されているので、複数の医師が診断を与える必要があります。

IT業界がより専門的な態度に移行し、独自のコードのテストを防止する手順を導入する時期です。

• 全員がテストする必要があります-テストコードの開発者、QA'ersテスト機能、マーケティングテストメッセージング。そうすることで、誰もがテストについて同じ哲学と言語を共有します。これは戦いの半分です。

• テストは日常的なメンテナンスであり、私は通常、類推を使用して比較します。たとえば、車のオイル交換の例えです。オイルを交換する必要はありません。しかし、とにかく定期的にそれを行います。あなたの歯を磨くために同じ。それらを毎日維持する理由があります-彼らは「今日」を壊すつもりはありません、それは明日と未来の日と投資をすることについてのすべてです。

• 全員がテストの責任を分かち合う必要があります。QAチームは重要ですが、QAチームだけが行うこととして「テスト」を行うことは、製品開発とワークフローに統合されない「別個の」活動であり、良いことではありません。

• 生産で何かが壊れた場合、次の2つのことを行います。

  1. 最初のコメントとして「うーん、そのためのテストはありますか」と言ってください。
  2. 修正よりも最初に再現する問題のテストを含む修正を行います。

私の会社では、かなり複雑な金融アプリケーションをいくつか作成しています。当社の一般的なポリシーは、開発者が技術的なエラーが発生しないことを確認することです。基本的に、ユーザーのリソースを考慮して、できる限りすべてを試してみてください。ランタイムエラーが見つからない場合は、テストのためにBAに転送します。ビジネス要件のテストで燃え尽きるまで道に迷った開発者が何人かいましたが、それはそのテストがすべて責任ではなかったからです。はっきりと見える明白なエラーがない限り、出力を理解するために報酬を得る人に転送します。また、ユーザーは結果を検証する上で実際の役割を持っている必要があります。小売店の店員は洋服を試着するのではなく、適切なサイズの洋服を見つけるなどの「技術的な詳細」のお手伝いをします。

1つの問題は、開発者が自分のコードを破るインセンティブをほとんど持っていないことです。自分の作品の欠陥を検索したり、ミスをしたりする人はほとんどいません。別のチームを持つことは、物事が壊れることを確実にするのに役立ちます。

開発者が要件を理解していることを誰かが確認できるように、品質保証の役割は他の理由の中でも重要です。開発者がこのチェックを自分で行うことはできません。なぜなら、彼らが誤解したと思った場合、それは明確化を要求するからです。