QAはテストを2回行う必要があります。1回はステージングで、もう1回は製品で行いますか？
qAチームは、prod envとほぼ正確に一致する環境でテストを行うのが理想的です（設定の違いが原因で発生するキャッチされていないバグを最小限に抑えるため）。
それが本当である場合、QAチームは通常、GoogleやAmazonでの本番環境でのデプロイ後にテストを再度行いますか？答えが「はい」の場合、それは冗長に聞こえますが、どのようにして生産をテストできないのでしょうか。
何をしているかに依存しますが、システムが実際のリソースに接続されているため、運用環境でテストできないことがよくあります。 Amazonの場合、実際のクレジットカードで実際の注文を行い、本が届くのを待ちますか？多くの場合、テストデータを運用システムに配置する際には注意が必要です。
いったん稼働すると、監視システムに依存してバグの早期警告を出すことができます。完了した注文の突然の低下？更新をより適切にロールバックしてから、ログを調べて、何が起こったかを調べます。
（間違いなく、SpaceXが行っているのは、ロケット回収システムを使用した「本番環境でのテスト」です。ダミーの打ち上げを行うのは実際にはコストがかからないため、実際のペイロードで打ち上げて、システムがロケットを着陸させることができるかどうかを確認します。）
適切なテスト環境では見つからないものが見つからないため、本番環境ではテストしません。展開が成功したかどうか、ある種の簡単なチェックかもしれませんが、これはテストの大部分ではありません。
まず、コードをテストします（単体テスト）。次に、アプリケーション全体でコードをテストします（統合テスト）。次に、システム全体でコードをテストします（システムテスト）。
さらなるテストはすべて、バグの発見または報告から何も得られない人々によって行われます。これは、あなたが考えると、製品の品質を低下させます。
「テスト」は単一のことではなく、一度だけ行われるものでもありません。要件から展開まで、コードは多くのレベルのテストを通過する必要があります。
- コードがビルドされてチェックインされると、ユニットテストと統合テストが実行されます。
- あらゆるタスクの一部として、テスターは要件に対して実装をチェックすることと、機能が正常かつ使用可能な方法で機能することをテストすることの両方を行う必要があります。
- 要求の内容が彼らが望んでいるものであることを確認するために、生産前に要求者が機能をレビューする必要がある
- さまざまなタイプのユーザー、受け入れ、および回帰テストがリリース前に実行される可能性があります。
- リリースされた後でも、顧客を使用してA/Bテストを行い、バグを報告することができます。
全体がコードの周りの品質管理（QC）を形成します。 「テストを1回または2回実行する必要がある」と主張すると、コードが実際にテストされる範囲が（適切な環境で）見落とされます。
ああ、それを「QA」と呼ばないでください。ソフトウェアテストでは、ユーザーとデータのやり取りとプログラムフローの可能なすべての組み合わせを100％カバーすることはできません。したがって、コードが目的に適合していることを保証することはできません。できるのは「サンプルテスト」による品質管理だけです。
理想的には、はい、QAはライブシステムをテストする必要があります。それ以外の場合は、ライブシステムをテストします。代わりに、顧客にそれを実行させるだけです。
本当の問題は、ステートフルなアプリケーションがあるときにこれをどのように実現するかです。すなわち。実際にすべての注文を削除せずに、DeleteAllOrdersボタン（極端な例）をテストするにはどうすればよいですか？
通常、これはテスト環境を用意することで実現されますが、お気づきのとおり、これには欠陥があります。テスト環境で機能するものがライブで機能するという保証はありません。さらに、必然的に、すべての異なる機能またはチームに対して数十のテスト環境が必要になり、その日にすべてがうまく機能するかどうかをテストすることは非常に困難になります。
2番目のアプローチは、ライブで実行するテストのサブセットを用意することです。これにより、簡単なものをテストできます。 「テスト注文をするが、請求される前にキャンセルする」などですが、これも完璧ではありません。
ライブシステムを完全にテストするには、テスト容易性を考慮してシステムをプログラムする必要があります。
削除すべて注文ボタンを作成する場合は、「これをどのようにテストするのですか？」と考える必要があります。 UndeleteAllTheOrdersIjustDeletedボタンも追加する必要があるかもしれません！
システムの一部の機能がめったに実行されない場合、またはテストするのが難しい場合は、その機能が重要でないとは見なされません。
ベストプラクティスは、常にライブシステムをテストすることです。問題が発生した場合は、すぐにそれについて知りたいです。
たとえば、eコマースサイトがある場合、サイトが稼働し商品を販売していることを確認するために、常にダミー注文を出します。ダミー注文が失敗し始めたら、すぐに知りたいので、顧客がヘルプラインに電話するのを待つ必要はありません。
はい、ステージング環境と本番環境で2回テストする必要があります。
ステージングをテストする際の最大の要素は、新しい機能が期待どおりに機能すること、および既存の機能が壊れていないことを確認することです。このテストは、理想的にはユニットレベルと機能レベルで徹底的に行う必要があり、通常は実行に時間がかかります。
プロダクションのテストにおける最大の要素は、ソフトウェアを提供している実際のマシン、ネットワーク、構成などを使用して、既存の機能が破壊されないことを確認することです。これらは多くの場合、迅速な「健全性」または「煙」テストであり、非常に迅速に実行され、メインの「ハッピー」パスがまだ正しく機能していることを確認できます。
また、ステージング環境または本番環境のいずれかでのテストは、今日、主にアジャイル環境に品質を追加するには遅すぎることが多いことも学びました。その時点でコードは作成されており、変更に対する柔軟性が低くなっています（告白：私は以前の開発者です）。テストがコードで記述される前にテスト計画と設計に焦点を当て、次にアプリケーションコードが記述される前にテストコードに焦点を当てて、テストがTDD/BDD方式でコードをガイドできるようにすることをお勧めします。 localおよびci環境。
私の経験では、ステージングされた環境でテストし、製品で再度テストしないと、バグが製品にリリースされることがよくあります。私の組織は、最近の変更の結果である生産の問題を非常に厳密に追跡し、リリースプロセスを詳しく調べて、その内訳を見つけています。
人為的ミスにより、ステージ環境が本番環境の正確なミラーにならないことがよくあります。または、上流と下流にあるすべてのシステムもステージで複製されません。または、ステージ環境には、prodシステムを流れるデータの完全なボリュームがありませんでした。
「勤勉をやりすぎたことで解雇されたことはないが、十分に応募しなかったことで十分だ」というような古い言い回しはありませんか。ない場合は、あるはずです。
実際には、すべてを100％テストすることはできません。それ以外の場合、製品がリリースされることはなく、どこに線を引くかを理解することは容易ではありません。
QAの要点は、最終製品がクライアントの要件を満たし、アプリケーションが展開するのに十分安定していることを確認することです。そのため、QA環境が本番環境を模倣している場合でも、構成の不足やサーバーの問題、データの欠落による新しいバグなど、デプロイメント中に問題が発生する可能性があります。
さまざまなQA戦略を使用するいくつかの会社と協力しました。それらの会社のいくつかは生産をテストしておらず、他の会社は生産をテストしてすべてが完璧であることを保証する特別なチームを持っています。
私の経験では、「冗長な」QAアクションはありません。それは常にマネージャーのビジョンとプロジェクトの規模とマイルストーンに依存します。
はい。しかし、この時点では、統合テスト、機能テスト、パフォーマンステストを自動化し、頻繁に実行するのが良いでしょう。それが、QAが中継できるContinous Integrationなどのシステムの目的です。この時点で、私はContinuous DeliveryおよびContinuous Testingについて検索します。
理想的なシナリオは、すべてがtest、intおよびpreでテストされているシナリオです。最後にQAはリリースにOK/KOと言います。しかし、コードは本番環境で実行する前にstaging envs全体に負荷がかかっています。しかし、ソフトウェアエンジニアリングでは理想的なシナリオは非常に珍しいことはわかっています。
私にとっての一般的なシナリオは、ソフトウェアが私のものではない（私がプロバイダーである）シナリオです。本番環境で運用を実行するのは、それがdealedであり、それが契約に表示されているためです。
したがって、お客様は手動でプロをテストする予定です！ただし、私または私のQAチーム（プロバイダー）が作成したテスト計画を使用します
ご覧のように、Proでテストを実行することは、政治的な決定である場合があります。他のシナリオでは、配信管理の戦略に依存します。