テスターが見つけるためのコードに意図的なバグを残す

弊社ではこれを行っていませんが、友人の一人が、プロジェクトマネージャーがすべての開発者に、製品がQAに移行する直前に意図的なバグを追加するように依頼したと言います。これがどのように機能するかです：

1. 製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。
2. テスターに​​もこのことが通知されます。バグが存在し、それらを見つけられないことは無能の兆候と見なされる可能性があることを知っているため、彼らは一生懸命テストします。
3. バグ（意図的またはその他）が見つかった場合、それらは開発チームが修正するために報告されます。開発チームは、製品が第2レベルのQAに移行する直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考えるべきであり、変更が行われたセクションに新しいバグがあることを期待すべきだと言います。

まあ、これはそれがどのように行くかです。彼らは、このアプローチには次の利点があると言っています。

1. テスターは常につま先を向いており、狂ったようにテストします。これは、開発者が修正できるように、隠れた（意図しない）バグを見つけるのにも役立ちます。
2. テスターはバグをフィードします。バグを見つけられないと、彼らの士気に影響します。ですから、彼らに見つけやすいものを与えることは彼らの士気を助けるでしょう。

これらの意図的なバグの1つが最終製品に同梱されるシナリオを無視する場合、このアプローチの採用を検討する前に考慮すべきその他の欠点は何ですか？

いくつかの説明：

1. ソース管理で元のコードを適切にバックアップします。
2. テスターが意図的なバグを見つけると、開発チームはそれを無視します。テスターが意図しない（元の）バグを見つけた場合、開発チームは最初に意図的なバグが原因かどうかを確認します。つまり、開発チームは最初に元の作業コードでそれを再現しようとし、可能な場合は修正しようとします。
3. QAと開発チームの関係の問題を無視してください。私は、ワークプレイスではなくプログラマーにこの質問を具体的に尋ねました。QAと開発チームの間には良好な関係があり、勤務時間後には一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、両方のチーム（Godsend）をサポートする準備が常にできている、素晴らしく、年配の紳士です。

これは絶対にナッツっぽい。非常に疑わしい利益のために多大な努力を費やしており、実践はいくつかの欠陥のある前提に基づいているようです：

• 彼らが毎日テストされていることを知らない限り、QAは懸命に働きません（士気に良いことはできません）

• QAが見つけるのに十分な意図しないバグがソフトウェアに導入されていないこと

• QAの仕事はバグを見つけることです。そうではありません。ソフトウェアが生産品質であることを保証することです

• 開発とQAの間のこの種の知恵の戦いは、会社にとって何らかの形で健全であること-それはそうではありません。すべての従業員は、お互いの代わりに会社の競合他社に対して協力する必要があります。

それはひどいアイデアであり、問​​題のプロジェクトマネージャーは、人と動機について何も理解していないジャーク/バカです。そして、それはビジネスに悪いです。

私の「QAの仕事」の説明を拡張するには、QAは間違いなく、コードとテストスイートの両方で、仕事をすることの成果物としてバグを見つける必要がありますが、役割は「見つける必要がある」バグ。」「新しい機能を説明し、テストの対象範囲をすべて確保するには、テストスイートを最新の状態に保つ必要があります。これによりバグが検出されない場合、テスト手順は製品に対して十分に洗練されていません。

まあ、私が学んだことに基づいて：

1. 学校や就職の面接ではありません。
2. テスターは子供ではありません。
3. それはゲームではありません。
4. 会社のお金を無駄にします。

QAは、バグを見つけるためだけでなく、システムがどれほど直感的であるか、ユーザーの学習曲線、使いやすさ、アクセシビリティ全般について心配するためにもあります。例：「システムは見苦しいですか？」、「ユーザーは色盲であり、スタッフは赤と緑ですか？」彼らも文句を言うべきです。

システムがQAに合格するための最小要件は、通常、その特定の機能のユーザーストーリー、またはPOがシステムを頭の中に入れたいと思った魔法の中で説明されています。

tl; dr

バグだけでなく、テスターはこの狭い視野から脱却する必要があります。

悪いアイデア。

テスターの観点から：「彼らはバグが存在することを知っているので、彼らは一生懸命テストします。そして、それらを見つけられないことは彼らの無能と見なされるかもしれません。」基本的に、開発者はコードを仕掛けています。最終的に無意味な作業（バグは事前に知られているため）を行うことを好む人はほとんどいません。ブービートラップを見つけられなかったために具体的な罰があれば、もっとそうです。そして、テスターがバグを見つけることに成功していることをご存知ですか？それは有毒な対立環境のように聞こえます。検査しているコードが高品質であれば、QAは満足しているはずです。彼らがバグによって支払われている場合でも... http://thedailywtf.com/articles/The-Defect-Black-Market

開発者の観点から：QAは、あなたがそこにいることがわかっているバグを見つけるために奨励されています。これにより、実際のバグがドアから出る可能性が高くなります。QAは、実際には微妙なバグではなく、植え付けやすいバグの種類を探すために少なくとも時間を費やしています。さらに、ブービートラップがドアから出る可能性がわずかにあります。

なぜこれがやる気と一般的にひどい人の管理に悪いのかについて、上記の答えに完全に同意します。ただし、これを行わないことにはおそらく技術的な理由があります。

製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。

1. 最初のステートメントに基づいて、これら2つのパスで目的の製品コードを実際にテストすることはありません。

2. 顧客の変更を急いで行おうとすると、リリースされた製品コードに偶発的に「意図的な」バグを含める可能性が大幅に高まると思います。ある時点でいくつかの赤い頬を引き起こす可能性があります。

3. これは、テスターが開発者のように考えるように（つまり、Tomがここにバグを追加する方法を）訓練するだけで、おそらくTomが考えていないバグを見つける可能性が低くなると思います。

編集

この答えはあなたのQAプロセスをテストする概念についてのみ話していることを明確にしたいのですが、質問に描かれている特定の方法論を擁護しているわけではありません。

編集を終了

テスト/チェックが実際に機能しているかどうかを確認する正当な理由があります。製造業の例を挙げましょうが、原理は同じです。

材料を機械に供給する場合、フィーダーが材料を十分に押し出さないことが一般的です。これは「ショートフィード」と呼ばれ、これを防ぐために「ショートフィードセンサー」（通常、材料によってブロックされている貫通ビームタイプのセンサー）を取り付けることがあります。このセンサーは、完全な送り長さに達すると材料の端を検出します。マシンサイクルの特定の時点で、センサーがブロックされていることを確認し、チェックに失敗した場合はマシンを停止します。

ここで、テスト自体がどのように失敗するかを考えなければなりません。たとえば、いくつかの汚れやその他の破片がセンサーをブロックする可能性があり、常に「OK」を報告し、マシンを停止することはありません。また、センサーの性質は、ビームが当たるとレシーバーがオンになるため、取り付けたセンサーのタイプに応じて、センサーがブロックされていないときに電気的に「ON」入力を取得します。つまり、ケーブルが切断されたり、センサーへの電力が失われたり、入力が失敗した場合、プログラムのロジックは「OFF」と表示され、「ブロック」または「OK」を意味します。

テストのこれらの失敗モードをキャッチするには、通常、2番目のチェックを挿入して、サイクルの2番目の部分でセンサーが実際にブロック解除されていることを確認します。このようにして、テストが実際に動作していることを確認します（可能な限り）。

同様に、QA部門が失敗する多くの方法があります。おそらく、自動化されたテストは実行されず、レポートはテストデータの古いコピーを見ています。おそらく誰かが自分の仕事を正しくしていない。QA部門をテストするのは妥当なことです。

明らかに欠点は、「テストバグ」がQA部門を通過して完成品に到達する可能性があることです。製造業では、「レッドラビット」と呼ばれることもある既知の不良部品がプロセスに挿入される場合があり（通常はQAの誰かによって）、その部品がプロセスを通過し、その所要時間を測定します部品を見つけて削除します。通常、この部分は明るい赤（またはオレンジ）で塗られているため、簡単に追跡できます。このテスト中に誰かが部品のプロセスを監視しているので、最終製品になる可能性はほとんどありません。もちろん、誰かが「システムがそれを見つけることができるかどうかを確認する」ために、既知の悪い部分をプロセスに投げ入れているという外伝的な物語があります。

正直なところ、私はこの行動を露骨に非倫理的で非現実的と呼んでいます。PMは、終了ではないにしても、何らかの重大な再訓練を必要としています。

• それは品質保証の概念の理解の基本的な不足を示します。テスターは開発者のように考えるべきではありません。エンドユーザーのように考えるべきです。QAチームを持つ理由は、開発者が本質的にコードに近すぎるためです。QAは、開発者が見落としたことをキャッチできるように、コードから十分な距離を維持することになっています。
• QAの努力を無駄にします。これらのバグは些細なものではないと仮定します（いつ以下を参照）は、QAが既知の事柄を調査するために時間とリソースを費やしていることを意味します。
• 開発者の努力を無駄にします。QAの人々がこれらの重要なバグをキャッチするには、開発者が最初にそれらを作成する必要があります。これには、バグのコーディングだけでなく、ソフトウェアの要件と設計の検討も含めて、さらに努力が必要です。
• それは生産を不必要なリスクにさらします。変更が適切にマージされないのは時間の問題です。
• 上記を実行しない場合、それは無意味です。既知のバグがすべて些細なものである場合、標準以下のワーカーをキャッチすることはありません。仕事をしていない人だけをキャッチします。それを行うより良い方法があります。
• それは作業環境を害します。QAテスターはプロです。そうでないと疑われる実際の理由があるまで、彼らはプロであると信頼されるべきです。そこにするときであるそう疑う理由は、代わりにこれらの心のゲームの適切な調査があるはずです。他のものは士気を殺します。

真剣に。PMの妄想がこの特定のケースで十分に根拠があると判明したとしても、これはテスターを管理するビジネスを持つ人ではありません。

個人的には、このアプローチには不快感を覚えます。

私に関係する主なことは、意図的なバグを挿入する実用性です。これは、予測可能な方法で行うのが難しいように思えます。

任意の（意図的または他の方法で）コードの変更は、副作用を有するリスク。これらの副作用は、テスト中に明らかになる可能性がありますが、根本的な原因が何であるかは明らかではないかもしれません（バグを植えた開発者にとってさえ）。あなたが私が意味することを知っているなら、それは「安全」とは感じません（ここで私の腸から話しています）。

また、テスターは実際にはリリースされないコードのテストに多くの時間を浪費します。意図的なバグが削除されたら、とにかく、完全な再テストを行う必要があります。それがテストの全体のポイントです。何かが変わり、何でも、そしてあなたはすべてを再テストします。それは実際には決して起こらないことはわかっていますが、それが回帰テストのすべてです。

したがって、全体としては納得できません。

一方、顧客にQAチームの作業を確認させる傾向がありますが、これは理想的ではない可能性があります。ただし、これは非常に強力なフィードバックループです。

既に挙げられているすべての理由から悪い考えですが、バグの種付けは別の目的に役立つツールです。これを使用して、QAプロセスの効果の大まかなメトリックを取得できます。

最も単純なケースでは、100個のバグをシードし、それらが実際のバグの全範囲を代表しているとしましょう（私は知っていますが、ありそうもないが、私は単純化しています）。 実験を台無しにしないために、これを行っていることをQAに伝えません。QAプロセスの最後に、シードされた100個のバグのうち60個（およびその他の実際のバグ）が見つかったとします。QAがバグの60％を検出していることがわかりました。

QAで見つかった実際のバグの数をカウントして、これをさらに拡張し、偽のバグ率を適用できます。この例では、QAが200個の実際のバグを見つけた場合、それらのバグの60％しか見つけられなかったと結論付けることができます。

もちろん、これは巨大なエラーバーを含む単なる概算です。現実的な代表的なバグを書くのは難しいです。開発者はバグを書かないように訓練されているため、あなたが書いたバグはQAにとって見つけやすいでしょう。off-by-oneエラー、Unicodeの間違い、バッファオーバーフローなどのバグのクラスをシミュレートする方が良い場合があります。

これは、開発者の単体テスト、継続的な統合、および可能な場合は専任のQAチームを含むQA プロセス全体に適用する必要があります。

これはメトリックであり、管理の動機付けツールとしてハイジャックされるべきではありません。

悪いアイデア。

これは、開発者がしばしばもたらす一種の論理的なバイナリアプローチですが、QEにとってはやる気になります。それは単に信頼の欠如を示しています。多くの場合、QEはこれらの状況に置かれますが、QEからの入力は多くなく、QEはそれで問題ないと想定し、そうでなければ提案する場所ではありません。

この種の考え方は、QEが手動テスターのみであり、テスト対象の実際のコードを理解するように動機付けられていないことに結び付きます。

私は上級QEであり、これは私が働いてきたほとんどの組織でよく知られている問題です。

私は悪い考えを言うだろう。

1つ：プログラマーは、コードに意図的なバグを入れるのに時間を費やし、良いバージョンを保存するための努力をします。テスターはおそらく、植え付けられたバグの機能を含むすべてをテストする必要がありますが、見つかった場合は、テストを戻って再実行し、これが実際にバグであったことを確認する必要があります（テスターが混乱したことではありません）何らかの方法で）。少なくとも、テスターは植え付けられたバグの作成に時間を費やします。それからプログラマーは、植えたバグの修正に時間を費やさなければなりません。これは、良いコードを書き、実際のバグを書き込もうとするのに費やすことができる多くの努力です。

2：テスターに​​明確なメッセージを送信します。プログラマーや管理者は、自分たちは仕事をしておらず、子供として扱われなければならないと考えています。これが士気に良いとは想像できません。プログラマーとして、プログラムの仕様があいまいまたは矛盾している場合、それらを明確にするのに多くの時間を費やさなければならなかった場合、上司は「ああ、そうだ、意図的に矛盾した文を入れた」と言った。あなたが本当にそれらを読んでいることを確認するための仕様」、私は本当にイライラすると思います。それが定期的に起こった場合、それは私が別の仕事を探すのに十分かもしれません。

実際には、最も些細なコード変更以外のすべてにバグがあります。与えられた最初のドラフトコードは100％完全であることが多いため、私はテスターが満足するのに問題はありませんでした。適切な仕事をしていない怠zyなテスターに​​対処しなければなりませんでしたが、プログラマーがとても完璧だったので、彼らはそのようにはなりませんでした。私がかつて一緒に働いた最高のテスト担当者は、新しいソフトウェアリリースでは、100個のバグを見つけるという個人的な目標を設定したと言っていました。さて、100が現実的な数であるかどうかは、製品の大きさと変更の程度によって異なりますが、私たちの場合、彼はほぼ常にその目標を達成できました。メッセージ内のつづりの間違った単語を「バグ」と呼ぶように、物事を伸ばさなければならないこともありましたが、修正する必要がありました。

ポストスクリプト：これを行うと、遅かれ早かれプログラマーが意図的にバグを植え付け、テスターはその特定のバグを見つけられず、プログラマーは良いコードを戻すことを忘れるでしょう。そのため、意図的に植えられたバグが顧客に出荷されます。

これは悪い考えだとは本当に思いません。私はもっ​​とうまくいくと推測することがたくさんあります：

1. 可能な限り、品質についてQAに責任を負わせます。たとえば、サポートにも責任を持たせることにより。これにより、出荷される製品の品質を高めるためのモチベーションが高まります。自分自身の不備（バグ、明らかに欠落している機能、直感に反する動作）を発見するのは、動揺しているユーザーが何を説明しようとしているのかを理解するために常に努力を必要としません。そして、その責任の一部を開発者に置くことで、QAが最善を尽くすのを助けるモチベーションを高めることができます。

2. 複数のQAチームがあり、競争することができます。もちろん、賢明な指標を見つける必要があります。問題の数だけではありません。提案された機能強化の欠陥の重大度またはビジネス上の価値（利害関係者によって決定される）を考慮に入れると役立ちます。

QAが「十分」かどうかを判断するのは困難です。QAが「改善し続ける」方法を見つけることは、長期的には簡単で、場合によってはさらに良いことです。

それでも、意図的なバグを導入した場合に注意する必要がある問題が1つあります。「正しい」コードが実際に最初から正しかったことをどのように確認できますか。2回目のQAの後、発見されていない意図的なバグをすべて削除します。別の方法で壊れたコードに置き換えているだけではなく、以前は到達できなかった壊れた動作を有効にしていないことを知る方法はありません（誇張された例：意図的なバグのためにダイアログが開かない、しかし、ダイアログ自体は壊れています-テスターがそれを見ることができなかったので、あなたは見つけません。

他の人が言ったように、開発者は意図的にソフトウェアにバグを追加するべきではありませんが、テストプロセスの一部としてソフトウェアにバグを追加することはテストスイートにとって正当な戦略です。

突然変異テストと呼ばれます。アイデアは、ソフトウェアを使用してソースコードの小さな変更（ミュータントと呼ばれる）の作成を自動化することです。変更は、異なる動作を作成するように設計されています。たとえば、変更できます

if x < 10:
    print "X is small!"

に

# we flipped the inequality operator
if x > 10:
    print "X is small!"

そして良いユニットテストは、ミュータントコードフラグメントが期待通りに動作しなくなり、ミュータントを殺すことを検出するはずです。元のコードがテストに合格し、すべてのミュータント（機能的に同等ではない）がテストに失敗すると、コードとテストが強いことがわかります。

私はそのアイデアが好きです。「平和で汗をかくほど、戦争で出血する量が減る」と言ったのはパットン将軍でした。

テスターの意図的なバグを「時間の浪費」に置きます。しかし、それはまた、彼らをより難しくします。つまり、彼らはまた、意図しないバグを見つけるのにより良い仕事をするでしょう。（そして、あなたは「オリジナル」のコピーを持っているので、あなたがやったことと一緒に暮らす必要はありません。）

意図しないバグを見つけることは、長期的には意図的なバグを処理するコストよりも多くの悲しみを節約する可能性があります。

さらに、テスターの素晴らしさではなく、テスターの素晴らしさを知ることができます。

報奨や罰の根拠はそれ自体のメリットにはありませんが、ターゲットとする行動の結果に基づいています。また、意図しない結果が生じる場合があります。QAチームが怠けないようにすること、またはマネージャーが邪魔をしていることに気付かずに実際に何かを貢献しているように感じさせることが目標です。

ポジティブな結果-QAチームはバグを見つけるために一生懸命働きます。誰が知っている、多分彼らはこれを挑戦として見る。フレンドリーなゲームです。または彼らは見られているのでちょうどしている（ホーソーン効果？）。

負の結果-彼らは一生懸命働かず、とにかくバグを見つけるかもしれません。QAはこれをささいな敵と見なしています。それで、彼らはハイパーバグ発見ドライブに入り、あらゆる種類のちょっとしたつまらない小さな問題を返します。スクリーンショットを撮ってPDFに変換し、500％で表示すると、そのフォントは適切にレンダリングされません。

影響なし-このような音は違いはありませんが、なぜ気にしますか？時間を無駄にし、人をいらいらさせるだけです。

これが90％の時間で機能しないことに全員が同意できます。それは他の10％にはあまり役に立たない。自分でテストしてください。意図的なコードのバグがあるリリースに顧客はより満足していますか？他の分野の労働者の士気と生産性に影響しますか？売上高を増やしますか？教えてください。

開発者がテストを自分で記述して実行することが期待される世界から来ているこの「テスト」「QA」サイロは、あなたを怖がらせて混乱させるので、この観点から答えようとします。余談ですが、私の観点からは、資格のあるQAエンジニア（@SparKの回答で詳しく説明されているように）は、ソフトウェアがユーザーストーリーを完全に満たし、全体的な "品質"（バグを探す代わりに、ソフトウェアが対象とするドメイン）。

ここで私を引き付けたのは、@ JamesMcleodの質問へのコメントでの「欠陥注入」の言及です。開発者にシステムにバグを挿入する方法を考えてもらうことは、実際に防御の概念を徹底的にターゲットにするための素晴らしいアイデアだと思います。システム全体を制御されない方法で（明確なアクション可能なログなしで）ダウンさせたり、データ破損を引き起こしたり、単独でセキュリティの脆弱性を公開したりするのに十分なバグは1つもありません。

各コンポーネントの開発者に意図的な欠陥を作成させ、他のコンポーネントの欠陥を処理し、全体的にソフトウェアに関するより敵対的な考え方を入力することで、ソフトウェアの堅牢性を向上させることができます。差し迫った利益でさえも重要です-新しい種類の欠陥（これまでテストされていなかった）を挿入するたびに、開発者はすぐに新しいテストでそれをカバーする必要があります。バグをしばらくの間コードベースにそのまま残し、その後配信前にスイッチを入れて（および欠陥を除去して）テストスイートをより包括的にする通常のテストに変えます。

関連するオプションは、機能フラグを使用して、特定のコンポーネントの機能を意図的にオフにして、他のコンポーネントがそれをどのように処理するかを調べることです。また、2012年の選挙でオバマチームが使用するソフトウェアインフラストラクチャの広範なテストについて説明している無料の書籍/記事「最初の応答者からの学習：システムが動作する必要があるとき」を読むことを強くお勧めします。

他の人がすでに言っているように、バグを単に見つけるのはQAの仕事ではありません。技術的には、さらに先に進んで、彼らの仕事ではないと言います。開発者は、自分のコードにバグがないようにする責任があります。新しいコードがコミットされる前にテストスイートを実行する必要があります。テストスイートが失敗した場合、そもそもQAに到達することはありません。バグを意図的に導入するということは、テストスイートに合格できないことを意味します。それで、コードがQAに移行するのはなぜですか。

QAの仕事は、実装するユーザーストーリーに対してアプリケーションを検証することです。フロー、UIなどをテストし、ユーザーができる限りすべての操作をできる限り確実に実行できるようにする必要があります。もちろん、これを行っている間、彼らはバグに出くわすかもしれませんが、それは彼らがすることではなく、彼らがすることの副作用です。QAはバグのない保証ではなく、品質保証を意味することを忘れないでください。

これは必ずしも思ったほどクレイジーではありません。それはむしろあなたの動機に依存します。テストチームを倒すためのスティックを探しているなら、それはおかしいでしょう。一方、ソフトウェア開発で最も難しいことの1つは、テストアプローチがどれほど効果的かを知ることです。

したがって、適切に構成すれば、この手法を使用して、出荷しようとしている製品に未発見のバグがいくつ残っているかを推定できます。したがって、テストビルドに人工的に100個のバグをシードし、テスターがそのうちの50個を見つけたとします。そうすれば、シードされていないバグも50個見つかった場合、おそらく50個が残っている可能性があると推測できます。

もちろん、これには多くの問題が伴います。これらの統計に基づいて出荷するかどうかを決定できますが、実際には、非常に厄介な問題が1つ、または軽微な刺激が1つ見つかることがあります。

それでも、知識は力であり、この手法がなければ、コードベースの品質についてはあまり考えられません。敬意を払い、適切な理由で実装できる場合は、「なぜですか」と言います。

誰もまだ言及していないことの1つ：突然変異テスト。

これは、自動化されたツールがソースコードを受け取り、意図的にバグを挿入する場所です。（たとえば、ランダムに選択されたステートメントを削除し、ANDをORに変更するなど）。その後、完全なテストスイートを実行し、テストに合格するかどうかを確認します。

すべてのテストに合格した場合、次の2つの可能性があります。

• 変更されたものは何もしません。つまり、デッドコードがあります。
• この変更により、テストスイートでは検出できないバグが発生しました。さらにテストが必要です。

あなたの提案とは異なり、上記で説明したことはすべて自動化されていることに注意してください。開発者が無意味なバグを手作業で挿入する時間を無駄にすることはありません。また、既知のバグを見つけるためにテスターが時間を無駄にすることはありません。使い果たしているのは機械時間だけで、これははるかに安価です。（マシンは同じテストを20,000回実行することに飽きません。人間はしばらくして思いやりをやめます！）

自動突然変異テストは、あなたが話している手動のシナリオよりもはるかに優れたアプローチであることをお勧めします。

開発者にバグを手動で挿入するように依頼した場合、発生するバグの種類は、人間が犯す可能性のある偶発的な間違いの代表ではないことに注意してください。（たとえば、競合状態が発生する可能性があることに気付いていない場合は、意図的な競合状態を挿入することはほとんどありません。）もちろん、自動化されたツールがより客観的であるかどうかは、まだわかりません。

一般的には悪い考えですが（他の答えはその理由を完全に説明します）、制御された一時的な方法で意図的にバグを本番コードに注入することができる特別な状況がいくつかあります。

テストコードをリファクタリングする場合、テストコードは本番コードと同じように細部に注意を払う必要があります。テストコードがまだ見つかっているバグを見つけているかどうかを知りたい場合があります。

その後、テストがまだ機能するかどうかを確認するために、意図的に製品コードを壊すことができます。

これが可能な複数のレベルがあります。

• いくつかの単体テストをリファクタリングしたばかりの開発者は、製品コードを壊して、単体テストがまだ見つけるべきものを見つけていることを確認するかもしれません。
• 一部の受け入れテストをリファクタリングしたばかりのテスターは、受け入れコードが検証対象を検証していることを検証するために製品コードを壊す可能性があります。
• インターフェイスが十分に安定していて堅牢な場合（つまりプロトコルベース）、企業は既知の障害のある製品バージョンのスイートを保持し、テストを回帰テストするためにそれらに対してテストを実行することができます。

これらが意味を成すかどうかは依存します。私が開発者であり、バグの挿入、単体テストのテスト、バグの削除にわずか1分しかかからない場合は、なぜですか。しかし、エディター、サイクル、およびバージョン管理システムを適切に管理して、誤ってバグをコミット/配信/チェックイン/プッシュしないようにする必要があります。テスターと受け入れテストについても同様です。

組織が既知の障害のある製品バージョンと回帰テストのスイートを保持することが理にかなっているかどうかは、テストに依存します。オンラインショップの場合はそうしません。自動車の組み込み、航空宇宙の組み込み、銀行カードまたは有料テレビカードの場合。

これがどれだけの労力を要するかは、テストが本番コードからどの程度分離されているかに大きく依存します。本番コードからテストを切り離すほど、これを行う労力が少なくなり、テストが本番コードとより緊密になり、より多くの労力がかかります。

理由はこれだけです。テストと本番コードが結合している場合、本番コードを変更するにはテストを頻繁に変更する必要があり、テストと障害のある本番サンプルの間の依存関係が壊れます。その後、障害のある生産サンプルも更新する必要があります。まれに、それでも努力に値する場合があり、バージョン管理システムのモックとスマートな使用により、努力を大幅に減らすことができますが、熟練した開発者をはるかに超える必要があります。

製品コードで意図的に注入する障害の概念は呼ばれサボタージュ注入し、障害が呼び出され、破壊工作。

テスト対象のコードをリポジトリから直接取得していないテスターは、間違っています。（1）

既知のエラーコードをリポジトリにチェックインしている開発者は、間違っています。（2）

そのため、この段階では、開発とテストの実行方法に関する非常に基本的な前提に一方または両方が違反しない限り、このスキームが機能する方法はすでにありません。

（1）テストしたバージョンを文書化する必要があるため。GitハッシュまたはSVNリビジョン番号でタグ付けされたバージョンはテストできますが、「Joeがくれたコード」はテストできません。

（2）しないので、失敗を期待しているテストドライバーの外。

これは、開発者、テスター、経営陣のいずれにとってもすぐに意味をなす最短距離の「エレベーターピッチ」の理由での試みです。

QAに送信するすべてのビルドに意図的にバグを挿入しないことをお勧めします。

1年に1度、「QA監査」をひそかに行うことができます。「テスト済みで機能する」コードベースと、できるだけ多くのTodoリストの小さな新機能を使用してください。通常よりも「少しずさんに」実装してください。エッジケースを考えて書き留めますが、コードを修正して考慮に入れないでください。QAに送ってください。

彼らがあなたが書き留めたよりも多くの非機能的なエッジケースのバグを見つけた場合、監督を必要とするのは確かにあなたのQAではありません... ;-)