テスターが見つけられるようにコードに意図的なバグを残す
私たちの会社ではこれを行っていませんが、私の友人の1人は、プロジェクトマネージャーが製品がQAに移行する直前に、すべての開発者に意図的なバグの追加を依頼したと言っています。これがどのように機能するかです：
- 製品がQAに進む直前に、開発チームはコード内のランダムな場所に意図的なバグをいくつか追加します。元の機能するコードを適切にバックアップし、これらのバグが最終製品に同梱されていないことを確認します。
- テスターもこれについて通知を受けます。ですから、彼らはバグが存在することを知っており、バグを見つけられないことが能力不足の兆候と見なされる可能性があることを知っているので、彼らは一生懸命テストします。
- バグ（意図的またはその他）が見つかった場合は、開発チームが修正するように報告されます。次に、開発チームは、製品が第2レベルのQAに進む直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考える必要があり、変更が加えられたセクションに新しいバグがあることを期待する必要があると述べています。
まあ、これはそれがどうなるかです。彼らは、このアプローチには以下の利点があると言います。
- テスターは常につま先に立ち、狂ったようにテストします。これにより、開発者はそれらを修正できるように、隠れた（意図しない）バグも見つけることができます。
- テスターはバグをフィードします。バグを見つけないと、彼らの士気に影響します。簡単に見つけられるようにすると、彼らの士気が高まります。
これらの意図的なバグの1つが最終製品と共に出荷されるシナリオを無視する場合、このアプローチの採用を考える前に考慮すべき他の欠点は何ですか？
いくつかの明確化：
- 元のコードをソース管理で適切にバックアップします。
- テスターが意図的なバグを見つけた場合、開発チームはそれを無視します。テスターが意図しない（元の）バグを発見した場合、開発チームはまず、それが意図的なバグの原因であるかどうかを確認します。つまり、開発チームは最初に元の作業コードでその再現を試み、可能であれば修正を試みます。
- QAと開発チームの関係の問題は無視してください。私は特にこの質問をProgrammersではなくThe Workplaceで行いました。 QAと開発チームの間に良好な関係があり、勤務時間後に彼らが一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、常に両方のチーム（Godsend）をサポートする準備ができている素敵な老紳士です。
これはまったくおかしな話です。それは非常に疑わしい利益のために多大な労力を費やしており、実践はいくつかの不完全な前提に基づいているようです：
そのQAは、彼らが毎日テストされていることを知らない限り、きちんと機能しません（これは士気に良いことではありません）。
ソフトウェアに意図せず導入されたバグがQAが見つけるのに十分ではないこと
そのQAの仕事はバグを見つけることです-それはそうではありません。ソフトウェアが生産品質であることを確認することです
開発とQAの間のこの種の機知の戦いは、ある意味で会社にとって健全です-それはそうではありません。すべての従業員は、お互いの代わりに会社の競争相手に対して協力する必要があります。
それはひどい考えであり、問題のプロジェクトマネージャーは、人や動機について何も理解していないジャーク/バカです。そしてそれはビジネスに悪い。
「QAの仕事」についての私の説明をさらに詳しく説明すると、QAは間違いなく、コードとテストスイートの両方でバグを見つけることになるはずです。バグ。」 「新機能を考慮し、すべての高いテストカバレッジを確保するには、テストスイートを最新の状態に保つ必要があります。これによりバグが検出されない場合、テスト手順は製品に対して十分に洗練されていません。
まあ、私が学んだことに基づいて：
- 学校や就職の面接ではありません。
- テスターは子供ではありません。
- ゲームではありません。
- それは会社のお金を浪費します。
QAはバグを見つけるだけでなく、システム直感的がどのようになっているか、ユーザーの学習曲線を心配することもできます。 sability、およびaccessibilityが一般的です。例：「システムはgly？」、「ユーザーはカラーブラインドで、物は赤と緑ですか？」彼らも文句を言うべきです。
システムがQAに合格するための最小要件は、通常、その特定の機能のユーザーストーリー、またはPOがシステムを自分の頭の中にいかに魅力的にしたかで説明されています。
tl; dr
これはバグだけではなく、テスターはこの狭い視野から成長する必要があります。
悪いアイデア。
テスターの観点から：「彼らはバグが存在することを知っており、バグを見つけられないことは彼らの無能と見なされるかもしれないので、彼らは一生懸命テストするでしょう。」基本的に、開発者はコードをだまし取っています。 （バグは事前にわかっているため）最終的には無意味であるが、それでも彼らの知覚方法に影響を与える作業を好む人はほとんどいません。ブービートラップを見つけられないという具体的な罰がある場合は、さらにそうです。そして、テスターがバグを見つけることで成功することを知っていますか？それは有毒な対立環境のように聞こえます。彼らが調べているコードが高品質であるならば、QAは幸せであるべきです。ただし、バグによって支払われた場合... http://thedailywtf.com/articles/The-Defect-Black-Market
開発者の観点から：QAは、あなたが知っているバグを見つけるために奨励されています。それは本当のバグがドアから出て行く可能性を増やすかもしれません。 QAは少なくとも実際に微妙なバグではなく、簡単に植えられる種類のバグを探すために時間を費やしています。さらに、ブービートラップがドアの外に出る可能性が少しあります。
なぜこれが動機とひどい人々の管理にとって悪いのかについて、私は上記の答えに完全に同意します。ただし、これを行わないことには、技術的な理由がおそらくあります。
製品がQAに進む直前に、開発チームはコード内のランダムな場所に意図的なバグをいくつか追加します。彼らはそれらのバグが最終製品に同梱されていないことを確認するために、元の機能しているコードを適切にバックアップします。
最初のステートメントに基づいて、あなたはneverが実際にこれらの2つのパスで目的の製品コードをテストします。
顧客の変更を急いでしようとしたときに、リリースされた製品コードに誤って「意図的な」バグが含まれる可能性が大幅に高まると思います。いくつかの点でいくつかの赤い頬を引き起こす可能性があります。
これはテスターが開発者のように考えるように訓練するだけだと思います（つまり、トムがここにバグを追加する方法）。これにより、トムが考えていないバグを見つける可能性が低くなります。
編集
この回答はあなたのQAプロセスのテストの概念についてのみ話していることを明確にしたいと思います。私は質問で描かれた特定の方法論を擁護していません。
編集の終了
テスト/チェックが実際に機能しているかどうかを確認する正当な理由があります。製造の例を挙げましょうが、原理は同じです。
機械を通して材料を供給する場合、フィーダーが材料を十分に押し通さないことがよくあります。これは「ショートフィード」と呼ばれ、これを防ぐために「ショートフィードセンサー」（通常、材料によってブロックされる透過型センサー）を設置する場合があります。このセンサーは、材料が完全な送り長さに達したときに材料の終わりを検出します。マシンサイクルの特定の時点で、センサーがブロックされていることを確認し、チェックが失敗した場合はマシンを停止します。
ここで、テスト自体がどのように失敗するかについて考える必要があります。たとえば、ほこりやその他の破片はセンサーをブロックする可能性があり、常に「正常」と報告し、機械を停止することはありません。また、センサーの性質は、ビームが当たるとレシーバーがオンになることです。そのため、設置したセンサーのタイプによっては、センサーがブロックされていません。つまり、ケーブルが切断されたり、センサーへの電力が失われたり、入力が失敗したりすると、プログラムのロジックは「オフ」と表示され、「ブロック」または「OK」を意味します。
これらのテストの失敗モードを検出するために、通常、2番目のチェックを挿入して、サイクルの2番目の部分でセンサーが実際にブロックされていないことを確認します。このようにして、テストが実際に動作していることを確認します（可能な限り）。
同様に、QA部門が失敗する可能性がある多くの方法があります。おそらく、自動テストが実行されず、レポートはテストデータの古いコピーを調べています。おそらく誰かが自分の仕事を正しく行っていません。 QA部門のテストは妥当なことです。
明らかに欠点は、「テストバグ」がQA部門を通過して最終製品に到達する可能性があることです。製造業界では、「Red Rabbit」と呼ばれることもある既知の不良部品がプロセスに挿入され（通常、QAの担当者が）、その部品がプロセスを通過するのを監視し、所要時間を測定する場合がありますパーツを見つけて削除します。通常、この部分は明るい赤（またはオレンジ）に塗装されているため、簡単に追跡できます。このテスト中、部品がプロセスを通過するのを誰かが見ているので、それが最終製品になる可能性はほとんどありません。もちろん、「システムがそれを見つけることができるかどうかを確認する」ためにプロセスに既知の悪い部分を投げ入れ、もちろんその日に製造されたすべての最終部品を検疫して手動でそれらをソートする必要があるという外典的な話がありますが、それは単なる十分な注意を払ってテストを実施しないケース。
正直なところ、私はこの振る舞いを露骨に非倫理的で非現実的と呼んでいます。 PMは、終了しない場合でも、深刻な再トレーニングが必要です。
- 品質保証の概念を根本的に理解していないことを示しています。テスターは、開発者のように考えるべきではありません。エンドユーザーのように考えるべきです。 QAチームを持つ理由は、開発者が本質的にコードに近すぎるためです。 QAは、開発者が逃したものをキャッチできるように、コードから十分な距離を維持することになっています。
- QAの労力を無駄にします。これらのバグはささいなものではないと仮定します-いつ発生するかについては以下を参照してください-それは、QAが既知のことを調査するために時間とリソースを費やしているときに、不明な点を探すためにその努力を費やしている可能性があることを意味します。
- 開発者の労力を無駄にします。 QA担当者がこれらの重要なバグをキャッチするには、まず開発者がそれらを記述する必要があります。これには、バグのコーディングだけでなく、ソフトウェアの要件と設計の検討にも費やされた、さらなる努力が必要です。
- 生産を不必要なリスクにさらします。変更が適切にマージされないのは時間の問題です。
- 上記を行わない場合、それは無意味です。既知のすべてのバグが些細なものである場合、それらは標準以下のワーカーをキャッチしません。それらはまったく作業をしていない人々のみをキャッチします。それを行うにはもっと良い方法があります。
- 作業環境を汚染する。 QAテスターは専門家です。彼らは、他に疑う実際の理由があるまで、beの専門家に信頼されるべきです。 isと疑われる理由がある場合、これらのマインドゲームの代わりに適切な調査が必要です。それ以外のものは士気を殺します。
真剣に。首相のパラノイアがこの特定のケースで十分に根拠があると判明したとしても、これはテスターを管理するビジネスを持っている人ではありません。
個人的に、私はこのアプローチに不快に感じています。
私が気になる主なことは、意図的バグを挿入する実用性です。これは、予測可能な方法で行うのは難しいようです。
すべてのコード変更（意図的またはその他）は、副作用のリスクがあります。これらの副作用はテスト中に明らかになる可能性がありますが、根本的な原因が何であるか（バグを仕掛けた開発者にさえ）明らかでない場合があります。私が何を意味するかを知っていれば、「安全」だとは感じません（私はここの私の腸から話しています）。
また、テスターは、実際にはリリースされないコードのテストに多くの時間を費やします。私の意見では、意図的なバグが削除されたら、とにかく完全な再テストを行う必要があります。これがテストの要点です。何かが変化し、anything、そしてeverythingを再テストします。 Ok実際にはこれが起こらないことは知っていますが、それが回帰テストのすべてです。
だから、全体的には納得できません。
一方、QAチームの作業をお客様に確認させる傾向があるため、理想的ではない可能性があります。それは非常に強力なフィードバックループですが。
既に与えられたすべての理由からそれは悪い考えですが、バグの種付けは別の目的のための有用なツールです。これを使用して、QAプロセスの効果の大まかな基準を取得できます。
最も単純なケースでは、100個のバグをシードし、それらが実際のバグの全範囲を代表しているとしましょう（わかっていますが、可能性は低いですが、単純化しています）。 これを行っていることをQAに知らせません実験を台無しにしないようにします。 QAプロセスの最後に、100個のシード済みバグ（およびその他の実際のバグ）のうち60個が見つかったとします。これで、QAがバグの60％を検出していることがわかりました。
QAが検出したrealバグの数を数えることでこれをさらに拡張し、偽のバグ率を適用できます。この例では、QAが200個の実際のバグを検出した場合、それらのバグの60％しか検出できなかったと結論付けることができるため、133個が残ります。
もちろん、これは巨大なエラーバーを含む大まかな見積もりです。現実的で代表的なバグを書くのは難しいです。あなたが書くバグは、開発者がバグを書かないように訓練されているので、QAが見つけるのは簡単である可能性があります。オフバイワンエラー、Unicodeミス、バッファオーバーフローなどのバグのクラスをシミュレートすることをお勧めします。
これはQA全体に適用する必要がありますプロセスには、開発者の単体テスト、継続的インテグレーション、および可能な場合は専用のQAチームが含まれます。
これはmetricであり、管理の動機付けツールとして乗っ取られるべきではありません。
悪いアイデア。
これは、開発者がよく使用する一種の論理的なバイナリアプローチですが、QEをやる気にさせます。それは単に信頼の欠如を示しています。 QEは、多くの場合、それらからの入力なしにこれらの状況に置かれ、彼らはそれで大丈夫であると想定しました。
この種の考え方は、QEが手動テスターのみであり、テスト中の実際のコードを理解する意欲がないことに結びつきます。
私はシニアQEであり、これは私が働いたほとんどの組織でよく知られている問題です。
悪い考えだと思います。
1つ：プログラマーはコードに故意のバグを配置することに時間を費やし、良いバージョンを保存するためにいくらかの努力を費やします。テスターはおそらく植え付けられたバグの機能を含めてすべてをテストしているはずですが、それらを見つけたら、戻ってそのテストを再実行し、これが実際にバグであることを確認する必要があります（テスターが混乱したのではありません）。何らかの方法で）。テスターは少なくとも、植えられたバグの作成に時間を費やすことになります。次に、プログラマーは植えたバグの修正に時間を費やす必要があります。これは、優れたコードを記述して実際のバグを作成するために費やされる可能性のある多くの作業です。
２：それは、プログラマーおよび／または管理者が彼らが彼らの仕事をしていないので子供として扱われなければならないと考えるという明確なメッセージをテスターに送ります。これが士気に良いとは思えない。プログラマーとして、プログラムにあいまいまたは矛盾した仕様が与えられ、それらを明確にするために多くの時間を費やす必要があり、数時間または数日を浪費した後、上司が私に言った、「ああ、ええ、私は意図的に矛盾したステートメントをあなたが本当にそれらを読んでいることを確認するためだけの仕様」、私は本当にイライラすると思います。それが定期的に起こった場合、それで私は別の仕事を探すのに十分かもしれません。
実際には、最も重要なコード変更以外のすべてにバグがあります。テスターに与えられた最初のドラフトコードは100％完全であることが多いので、テスターが自己満足することに問題を抱えたことはありません。私は十分な仕事をしていない怠惰なテスターに対処しなければなりませんでしたが、プログラマーがとても完璧だったので、彼らはそのようにはなりませんでした。私がかつて一緒に働いた最高のテスト担当者は、新しいソフトウェアリリースでは、100のバグを見つけるという個人的な目標を設定したと私に話しました。さて、100が現実的な数であるかどうかは、製品の大きさと変更の広さによって異なりますが、私たちの場合、彼はほとんど常にその目標を達成することができました。メッセージでつづりが間違っているWordを「バグ」と呼ぶなど、時々彼は物事を引き延ばさなければなりませんでしたが、ちょっと、それは修正されなければなりませんでした。
ポストスクリプト：これを行うと、遅かれ早かれプログラマーが意図的にバグを植え付けることになり、テスターはその特定のバグを見つけられず、プログラマーは優れたコードを戻すのを忘れます。故意に植えられたバグが顧客に出荷されます。
これは悪い考えではないと思います。私がうまく機能すると推測できることはたくさんあります。
QAには、できる限り品質について責任を負わせてください。たとえば、サポートを彼らの責任にすることによって。これにより、出荷された製品の品質が向上するようにする動機が高まります。自分自身で不適切な点（バグ、明らかに欠けている機能、直感に反する動作）を発見するよりも、動揺しているユーザーが説明しようとしていることを理解しようとする方が、常に少ない労力で済みます。そして、開発者にさえその責任の一部を課すことは、QAが彼らの仕事をできる限り最善にするのを助ける彼らの動機を高めるかもしれません。
複数のQAチームがいて、競争することができます。もちろん、賢明なメトリックを見つける必要があります。間違いなく問題の数だけではありません。提案された拡張機能の欠陥の重大度またはビジネス上の価値（利害関係者によって決定されたもの）を考慮に入れることが役立つはずです。
QAが「十分」であるかどうかを判断するのは困難です。 QAを「常に改善」する方法を見つけることは、長期的にはより簡単で、場合によってはさらに優れています。
それでも、意図的なバグを導入する場合に注意する必要がある問題が1つあります。「正しい」コードが最初に実際に正しかったことをどのようにして知っていますか？2番目のQAの後発見されていない意図的なバグをすべて削除します。別の方法で壊れているコードで単にそれらを置き換えるのではなく、以前は到達できなかった壊れた動作を有効にしていないことを知る方法はありません（誇張された例：意図的なバグのために一部のダイアログが開かなかった、しかし、ダイアログ自体が壊れています-テスターがそれを見ることができなかったため、あなたはそれを見つけられません）。
他の人が言ったように、開発者は意図的にソフトウェアにバグを追加するべきではありませんが、テストプロセスの一部としてソフトウェアにバグを追加することは正当な戦略for your test suiteです。
これは mutation Testing と呼ばれます。アイデアは、ソフトウェアを使用して、ソースコードの小さな変更（ミュータントと呼ばれる）の作成を自動化することです。変更は、異なる動作を作成するように設計されています。たとえば、
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」のサイロは私を怖がらせ、混乱させます。そのため、私はこの観点から答えようとします。余談ですが、（@ SparKの回答でよく説明されているように）資格のあるQAエンジニアは、私の観点から、ソフトウェアがユーザーストーリーを完全に満たし、全体的な "品質"（バグを探す代わりに、ソフトウェアが対象としているドメイン）。
ここで私を惹いたのは、質問へのコメントでの@JamesMcleodの「欠陥注入」についての言及です。実際に開発者にシステムにバグを挿入する方法を考えてもらうことは、多層防御の概念をターゲットにするための素晴らしいアイデアだと私は実際に考えています。単一のバグだけでは、システム全体を制御されない方法で停止させたり（明確な実用的なログ記録なし）、データ破損を引き起こしたり、それ自体でセキュリティの脆弱性を露呈させたりすることはできません。
各コンポーネントの開発者に意図的な欠陥を作成させ、他のコンポーネントの欠陥を処理させ、全体としてソフトウェアに対してより敵対的な考え方を取り入れることで、ソフトウェアの堅牢性を向上させる可能性が高まります。直接的なメリットでさえ大きなものになる可能性があります。新しい種類の欠陥（これまでテストされていなかったもの）を挿入するたびに、開発者はすぐに新しいテストでそれをカバーする必要があります。バグが邪魔されずにコードベース内にしばらく存続し、配信前にオンになって（そして欠陥が削除されて）、テストスイートをより包括的にする通常のテストに変えることができます。
関連するオプションは、機能フラグを使用して特定のコンポーネントの機能を意図的にオフにし、他のコンポーネントがそれをどのように処理するかを調べることです。また、無料の本/記事を読むことを強くお勧めします "First Respondersから学ぶ：システムが機能する必要があるとき" は、Obamaチームが使用するソフトウェアインフラストラクチャのそのような広範なテストについて説明しています2012年の選挙。
他の人がすでに述べたように、バグを見つけることだけがQAの仕事ではありません。私はさらに進んで、技術的には彼らの仕事ではないと言います。開発者は、自分のコードをバグのない状態に保つ責任があります。新しいコードがコミットされる前にテストスイートを実行する必要があります。テストスイートが失敗した場合は、最初からQAにしてはなりません。バグを意図的に導入するということは、テストスイートに絶対に合格できないことを意味します。なぜコードがQAに進むのでしょうか。
QAの役割は、実装するユーザーストーリーに対してアプリケーションを検証することです。フローやUIなどをテストし、ユーザーが実行できるすべてのことを、可能な限り最も使いやすくアクセスしやすい方法で実行できることを確認する必要があります。もちろん、これを行っている間、彼らはバグに遭遇するかもしれませんが、それは彼らが何をしているかの副作用であり、何をしているかではありません。 QAはバグのない保証ではなく品質保証を意味することを忘れないでください。
他の誰もまだ言及していないことの1つ： 変異テスト 。
これは、自動化されたツールがソースコードを取得し、意図的にバグを挿入する場所です。 （たとえば、ランダムに選択されたステートメントを削除したり、ANDをORに変更したりします。）次に、完全なテストスイートを実行し、テストに合格したかどうかを確認します。
すべてのテストに合格した場合、2つの可能性があります。
- 変更されたものは何もしません。言い換えれば、あなたは死んだコードを持っています。
- この変更により、テストスイートで検出されないバグが発生しました。さらにテストが必要です。
あなたの提案とは異なり、上で説明したことはすべてautomatedであることに注意してください。手作業で無意味なバグを挿入する開発者の時間を無駄にすることはありません。また、テスターが既知のバグを見つけるために時間を無駄にすることもありません。使い尽くしているのはマシン時間だけで、はるかに安価です。 （マシンは同じテストを2万回実行することに飽き飽きしません。人間はしばらくして気を止めます！）
自動突然変異テストは、あなたが話している手動のシナリオよりもはるかに優れたアプローチであることをお勧めします。
開発者に手動でバグを挿入するように依頼した場合、得られるバグの種類は、人間が犯す可能性のある偶発的な間違いの代表ではないことに注意してください。 （たとえば、競合状態の可能性があることに気付いていない場合は、意図的なものを挿入することはほとんどありません。）もちろん、自動化されたツールがより客観的であるかどうかはまだわかりません…
これは、思ったほどクレイジーではありません。それはむしろあなたの動機に依存します。あなたがテストチームを倒すための棒を探しているなら、それはwould狂っている。一方、ソフトウェア開発で最も難しいことの1つは、テストアプローチの効果を知ることです。
したがって、適切に構造化すると、この手法を使用して、出荷しようとしている製品に残っている未発見のバグの数を見積もることができます。テストビルドに100個のバグを人為的にシードし、テスターが50個のバグを見つけたとします。次に、シードされていないバグが50個も見つかった場合、おそらく残り50個になる可能性があると推測できます。
もちろん、これには多くの問題があります。あなたはこれらの統計に基づいて出荷するかどうかを決めることができますが、実際には、1つの非常に厄介な問題、または1000の軽度の刺激を見つけるかもしれません。
それでも-知識は力であり、この手法がなければ、コードベースの品質についての考えはさらに少なくなります。あなたがそれを敬意を持ってそして正しい理由でそれを実装することができるなら、私は「なぜそうしないのですか？」と言うでしょう。
これは一般的には悪い考えですが（他の回答で理由を完全に説明しています）、制御された一時的な方法で意図的にバグを本番コードに挿入する特別な状況がいくつかあります。
テストコードをリファクタリングする場合、テストコードは本番用コードと同じように細部に注意を払う価値があります。テストコードがまだ検出すべきバグを検出しているかどうかを知りたい場合があります。
次に、意図的に製品コードを壊して、テストが引き続き機能するかどうかを確認できます。
これが可能な複数のレベルがあります。
- 一部の単体テストをリファクタリングしたばかりの開発者は、本番用のコードを壊して、単体テストで検出すべきものがまだ見つかっていることを確認する場合があります。
- いくつかの受け入れテストをリファクタリングしたばかりのテスターは、受け入れコードが検証すべきものをまだ検証していることを検証するために、製品コードを壊す可能性があります。
- インターフェイスが安定していて十分に堅牢（つまりプロトコルベース）である場合、会社は一連の既知の障害のある製品バージョンを保持し、それらに対してテストを実行して、テストを回帰テストすることができます。
これらの事が理にかなっているかどうかは異なります。私が開発者で、バグを挿入するのにわずか1分しかかからない場合は、単体テストをテストし、バグを削除してください。しかし、私は、エディタ、サイクル、およびバージョン管理システムを、誤ってコミット/配信/チェックイン/バグをプッシュしないような適切な管理下に置く必要があります。テスターと受け入れテストについても同様です。
既知の障害のある製品バージョンのスイートと回帰テストを維持することが組織にとって意味があるかどうかは、テストによって異なります。オンラインショップの場合はそうしません。自動車組み込み、航空宇宙組み込み、銀行カード、または有料TVカードの場合は、.
これがどれほどの労力を費やすかは、テストが本番コードからどのように分離されているかに大きく依存します。テストが本番コードから分離されるほど、それを実行するための労力が少なくなり、テストが本番コードとの一貫性が高まるほど、より多くの労力が必要になります。
その理由は単にこれだけです。テストと本番コードがまとまりのある場合、本番コードを変更するにはテストを頻繁に変更する必要があり、テストと障害のある本番サンプルの間の依存関係が壊れます。次に、不良な製造サンプルも保守する必要があります。まれなケースですが、それでも労力を費やす価値があります。バージョン管理システムのモックとスマートな使用により、労力を大幅に削減できますが、熟練した開発者よりはるかに多くの人が必要です。
プロダクションコードに意図的にフォールトを挿入するという概念はSabotageと呼ばれ、注入されたフォールトはsaboteurと呼ばれます。
テスト対象のコードをリポジトリから直接取得していないテスターは、それを間違っています。（1）
チェックインしている開発者既知の障害のあるコードintoリポジトリが間違っている。（2）
したがって、この段階では、開発やテストを行う方法の非常に基本的な前提に片側または両側が違反しない限り、このスキームが機能する方法はすでにありません。
（1）テストしたバージョンを文書化する必要があるため。 GitハッシュまたはSVNリビジョン番号でタグ付けされたバージョンは、「Joeがくれたコード」ではテストできないものです。
（2）そうしないので、expecting失敗であるテストドライバーの外。
これは、開発者、テスター、および管理者がすぐに理解できる、可能な限り短い「エレベーターピッチ」の理由での試みです。
QAに送信するすべてのビルドに意図的にバグを挿入しないことをお勧めします。
場合によっては、1年に1回、秘密の「QA監査」を行うことができます。 「テスト済みで動作している」コードベースと、Todoリストから可能な限り多くの小さな新機能を取り入れます。通常よりも「少しだらしなく」実装してください。 Edgeのケースを考えて書き留めてください。ただし、コードを修正して考慮に入れないでください。 QAに送信します。
あなたが書いたよりも多くの機能しないEdgeケースのバグを彼らが見つけた場合、監督を必要とするのは確かにあなたのQAではありません... ;-)