別の品質保証（QA）の完全に重複したシステムを作成することは悪い習慣ですか？

職場では、かなり複雑なシステムがあります。このシステムをSystem_Aと呼びます。QAチームは別のシステムを作成しました。このシステムをSystem_Bと呼び、System_Aをテストします。

System_Bの使用方法は次のとおりです。入力（System_B自体を使用）INを生成し、そのような入力をSystem_Bを介して処理し、出力O_Bを生成します。したがって、プロセスは次のとおりです。

System_B(IN) -> O_B。

次に、System_Aにも同じことを行い、独自の出力O_Aを生成します。

System_A(IN) -> O_A。

いつでも、O_Bは期待される出力であり、O_Aは観測された/実際の出力であると想定されます。暗黙のうちに、O_Bは「ゴールド」ソース（真実）です。しかし、問題の組み合わせに遭遇しました。

• O_Aは間違っている、O_Bは正しい
• O_Aは正しい、O_Bは正しい
• O_Aが間違っている、O_Bが間違っている
• O_Aは正しい、O_Bは間違っている

O_Bが常に正しいと想定されている場合（または何が期待されている場合）、何が正しいかをだれが決定しますか まあ、それはO_Bが人間の検査と分析で時々（またはしばしば）間違っていることがわかりました。物事はこのプロセスを使用してQAに合格し、実際のユーザーは不満を抱きます。結局、O_Bが間違っていたことが判明するまで戻ります。

問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか？

• 滑りやすい斜面はどうですか？それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。
• 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか？
• System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています（System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため）。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか？その理由は、並列システムを作成することを正当化するのに十分ですか？
• 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています（かなり頻繁に）。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか？それに対して、職場の誰も満足のいく対応をすることができません。

この問題に関するガイダンスは大歓迎です。

• O_Aは間違っている、O_Bは正しい

修正A

• O_Aは正しい、O_Bは間違っている

修正B

• O_Aは正しい、O_Bは正しい

うまくいけば、彼らも同意します。

• O_Aが間違っている、O_Bが間違っている

うまくいけば、彼らは同意しないので、あなたはそれについて何かをすることを知っているでしょう。

すべてをキャッチするプロセスはありません。確かに、コードは2倍になっていますが、O（2n）の2のように考えてください。統合テストまでの自動化されたQAは素晴らしいことです。手動テストはイノベーションの妨げになります。特に、完全なテストを必要とする横断的な変更について。また、異なるプログラマに同じものを実装させることになるので、彼らに競争させることができます。

さまざまなバグが発生する確率を上げるのは、人によって異なります。システムAから対処してシステムBを作成することはお勧めしません。提供されるのは、グレグレションテストだけです。O_Aの古いコピーを保存して新しいものと比較するだけで、同じことを得ることができます。

問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか？

もしそうなら、すべてのテストは悪いです。

• 滑りやすい斜面はどうですか？それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。

はい、私たちはそれを主張することができます。この3番目のシステムをsystem_Aと呼びます。：P

• 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか？

ナーフガンで遊ぶために私たちに支払う幸せな顧客の数によって。手動テストのコストから解放されました。バグが発見されるたびにその有用性が証明されるものを作成しました。バグの初期のコストは、遅くに報告されたバグよりもはるかに低コストです。

• System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています（System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため）。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか？その理由は、並列システムを作成することを正当化するのに十分ですか？

System_Bの複雑さは、System_Aから見事に分離されています。System_Bが存在するため、System_Aに機能を追加することは難しくありません。System_Bは高速で進む自信を与えるので、実際には簡単です。

• 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています（かなり頻繁に）。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか？それに対して、職場の誰も満足のいく対応をすることができません。

これはタイプミスですか？System_Bはかなり間違っていることが多いので、System_Aを置き換えるために使用したいのがゴールドスタンダードですか？

私はあなたがSystem_Aがしばしば間違っていることを意味すると仮定します。どれが最も頻繁に間違っているかは重要ではありません。どちらが間違っていても、作業が必要です。これらのシステムは正しいか間違っているかを決定しません、開発者は決定します。テストが行​​うことは、何かが正しくないことを意味する不一致を生み出すことです。開発者はそれが何であるかを理解します。ここで作成されているゴールドスタンダードはありません。同意または不一致のみがあります。意見の相違は、作業を行う必要があることを要求します。その仕事の一部はどこにあるかを理解することです。

顧客が実際に使用しているシステムが本番稼働中の場合、バグ修正と新機能を検証するQAシステムが必要です。品質の観点からは、本番システムのレプリカにできるだけ近いものにする必要があります。このようにして、本番システムとそのQAシステムが同一であることを確認した場合、一方で機能するものが他方でも機能するはずです。そうでない場合、システムは同一ではなく、入力は同一ではなく、および/または出力は誤って解釈されました。

これは二重に行われるため、システムがミッションクリティカルであり、24時間365日利用可能である必要がある場合は、本番システムでのダウンタイムを最小限に抑える必要があるため、QAシステムがないという贅沢に努力することはできません。24時間年中無休のシステムの場合、本番システムの正確なレプリカが非常に強く推奨されます。

さて、このアプローチの明らかな欠点はコストです。ハードウェアコストが2倍になり、展開とメンテナンスのコストが増加します。さらに、本番システムからQAへのデータの継続的なレプリケーションを実装する必要があるため、システムが処理するデータの違いによる異なる結果の可能性を最小限に抑えることができます。

通常、QAシステムのコンポーネントの一部を本番システムに比べて縮小することで、ある程度のバランスを見つけることができるため、ほとんどの機能を適切にテストできます。これらは通常、冗長サーバー、サーバーのサイズ、またはワークステーションの数です。ただし、私の経験では、ダウンサイジングされた部分にバグが常に正確に見つかるので、本番システムで許容されるダウンタイムを最小限に抑えながら問題を再現して修正を実装するのは悪夢です。

システムをテストするときはいつでも、予想される結果が何かを知る必要があります。

システムにこの予期される結果を生成させることの問題は、明らかに「そのシステムをどのようにテストするか」です。

それでも、たとえば期待される結果のセットを生成するために、人々がスプレッドシートを使用するのを見るのは通常ではありません。

結局のところ、システムの要件を解釈して手動で期待される結果を生成するには、人間が本当に必要です。もしシステムがあればそれを行い、違いのみをチェックするなら、あなたはテストをスキップしています。