「もちろん、別！」、読者の大半が答えます。 「彼らはいつもそのように働いた」ので、そのような答えは彼らの世界の絵に適合します。
いつもそうだった
このフレーズは、通常、既に実動に取り組んでいる製品またはリリースされようとしている製品の存在を意味しますが、単体テストおよび統合テストなしで記述されています。 テストからのセーフティネットがなければ、変更は長くて高価であり、多くの新しいバグが発生します。 開発の世界でのこのようなプロジェクトは、「レガシー」と呼ばれます。
会社は、セーフティネットなしではできないことを理解しているため、通常、製品の品質を保証せず、それを管理するだけのQA部門が作成されます。 QA部門を使用すると、開発者は自分がやりたいことを安全に行うことができます。コードを作成してください。専任の部門が品質に責任を持つようになったためです。 テスト部門には、古典的な「壁を越えてコードを投げる」ことがあります。
QA部門は、リグレッション中に完了しなければならない既製の機能について、何百ものブラックボックステストケースを作成します。 また、製品の開発が続けば、新しい機能のための数百のテストケースが後から回帰に追加されます。
各テストケースは手動であるため、テストプロセスには多くの時間がかかります。 回帰のテストケースの数は自然な理由で絶えず増加しており、QA部門内に自動化チームを作成することが決定されています。
ブラックボックステストで構成される回帰サイクルを高速化する必要があるため、新しいチームが採用されたため、GUIまたはAPIを介してブラックボックスレベルでも自動化が行われます。 GUIを使用した自動化は、テストの脆弱性と低速性のために最も苦痛で費用がかかりますが、多くの場合、それから開始します。
一方、新しいチームを作成しても、開発チームには何の影響もありません。テスト用に低品質の製品を提供し続け、単体テストと統合テストの作成は無視します。 自動化のキューにある膨大な数のブラックボックススクリプトを考えると、Ice-Cream Coneアンチテストパターンを取得します。このパターンでは、最も遅くて最も高価なGUIセルフテストの数が、安価で高速なユニットおよび統合テストの数よりもはるかに多くなります。
リリースごとにGUIの自動テストが不安定で遅くなるため、それらをサポートするためにより多くのリソースが費やされ、自動化チームの拡大につながります。 品質保証部は成長していますが、製品の品質の適切な成長を保証するものではありません。 常にこのように働きたいですか？
問題は何ですか？
上記の状況の主な理由の1つは、各開発者が自分が書いたコードを担当する開発文化の欠如です。 そして、最小限の責任であっても、「私の仕事の準備ができました！」と喜んで叫ぶ前に、コードが機能する必要性を理解することを意味します。
Eye Driven Developmentは、コードが機能していることを確認する最も簡単な方法ですが、最良ではありません。 この方法は、知的作業をほとんど伴わないという点でシンプルです。アプリケーション、サービス、クラスなどを手動でテストします。 境界値、等価クラス、否定的なシナリオ、さまざまなレベルのアクセス許可を持つシナリオなどを考慮せずに、エンドユーザーの観点から。 この方法では、開発中に迅速なフィードバックが提供されず、さまざまなデータの選択の本質を検証できず、多くの時間がかかり、製品の品質が向上しません。
最も最適な方法は、開発されたコードで自動テストを書くことです。 コードの責任について言えば、自動テストがいつ記述されるかは問題ではありません。コード自体の前でも後でもかまいません。 この方法を提供する主なことは、作業が本当に完了し、別のタスクに進むことができるという自信です。 迅速なフィードバックという形で他の利点を考えると、大規模なサンプルでエンティティを検証する機能、および開発者によって書かれた高速の自動テストは、製品品質を改善するための優れたツールです。
私たちはいつものように働きません
私は、メンバーが記述されたコードを担当するチームで、起こりうるイベントの発生を精神的にシミュレートすることを提案します。
製品はすでに実稼働で動作しているか、リリースの準備が整っているだけで、単体テストと統合テストでカバーされています。 コードは絶えず改善されており、既存の機能を破壊することを恐れずに新しい機能が追加されています。 開発された機能が機能していることを確認するために、テスト部門に「壁を越えてコードを投げる」必要がなくなり、判定を待つ時間を失い、何度も繰り返しを繰り返す必要がなくなります。
QA部門はすでに作成されており、開発プロセスに積極的に関与しており、製品の品質を確保することに真剣に取り組んでいます。 品質保証に関しては、テストクアドラントに導かれると便利だと思います。
テストクアドラントを使用して、テストを4つのカテゴリに分類できます。
最初のカテゴリは、製品実装テストです。これは、開発チームのセーフティネットを作成します。 このカテゴリは、単体テストと統合テストを使用した低レベルのテストを担当し、開発者が技術的な観点から正しいことを実行していることを理解できるようにします（正しいことを行う）。 明らかに、低レベルのテストは完全に自動化されており、関心のある分野にあるため、開発チームによって作成されています。
2番目のカテゴリは、製品のビジネス機能をテストし、開発チームのセーフティネットを作成することです。 ここでは、主にビジネスと開発チームの間の適切なコミュニケーションを作成し、ビジネスが本当に必要としている正しいこと（Do Right Things）を行っていることをチームが理解できるようにすることを目的とした、例、ストーリーテストなどの種類のテストについて説明しています。
自動化の例またはストーリーテストは、インターフェイスを使用するための複雑なシナリオではなく、ビジネスロジックのみをテストするエンドツーエンドテストであり、エンドユーザーがアクセスできるインターフェイスを使用します。 このカテゴリのテストはまだ開発の分野であるため、自動化は開発チームの肩にかかっています。
3番目のカテゴリは、製品のビジネス機能のテストです。これは、エンドユーザーが製品の品質を認識するために重要です。 研究テスト、複雑な製品のユースケースのテスト、ユーザビリティテスト、アルファおよびベータテストはこのカテゴリに分類されます。 このカテゴリのテストは完全にQAチームの肩にかかっており、自動化は不可能または複雑すぎます。
機能エラーを見つけることができる複雑なシナリオのテストおよびテストについて直接話す場合、見つかったエラーはコード内のエラーであり、適切な単体テストまたは統合テストでカバーできることに注意してください。 これはマーティン・ファウラーによってよく書かれており、私は翻訳の自由を取りました。
私は常に、高レベルのテストがテスト防御の2番目のラインとして存在すると主張します。 機能コードにバグがあるだけでなく、高レベルのテストで障害が発生した場合、ユニットテストが欠落しているか、正しくありません。 したがって、高レベルのテストで公開されたバグを修正する前に、単体テストでバグを再現することをお勧めします。 次に、単体テストにより、バグが死んでいないことを確認します。
高レベルのテストは第2の防衛線に過ぎないと私は主張します。 高度なテストの失敗とは、製品コードのバグだけでなく、適切な単体テストの欠如または既存の単体テストのエラーも意味します。 あなたへの私のアドバイス：高レベルのテストで発見されたバグを修正する前に、単体テストを使用してそれを再現すれば、あなたは永遠にバグに別れを告げるでしょう。
4番目のカテゴリは、製品の実装のテストです。これは、製品の品質に対するエンドユーザーの認識にとって重要です。 通常、ストレステスト、パフォーマンステスト、セキュリティおよびシステムの信頼性テストは、このカテゴリに分類されます。 そのようなテストは、特定のプロジェクトのニーズのために書かれた特別なツールを使用して実行されます。 良い意味で、DevOps部門はこのようなテストを実行するためのインフラストラクチャと、適切なツールの開発に関与しています-
別のチーム。 さらに、ツールはオンデマンドテスト（サービスとしてのテスト）を許可する必要があります。
作成されたQA部門は現在、製品の品質管理だけでなく品質保証も担当しているため、彼の責任は次のとおりです。
- 開発者が最初のカテゴリのテストを作成するのを支援する
- 開発チームとビジネス担当者とのコミュニケーション中に、例とストーリーテストの形成に参加する
- 探索的テストの実施と複雑なシナリオのテスト
- ユーザビリティテストとユーザーフィードバック
回帰手動ブラックボックステストケースの無限の成長は発生しません。これらのケースのほとんどは、開発チームによって最初と2番目のカテゴリでカバーされているためです。 この場合、正しいテスト関係、または「テストピラミッド」と呼ばれるものを形成します。
回帰手動テストの数の増加は最小限であり、ユニット、統合、およびGUIテストのレベルでの自動化は開発チームによって実行されます。 さらに、GUIテストの数は少なく、複雑なGUIの使用シナリオではなく、ユーザーインターフェイスを介したビジネスロジックの動作について説明しています。つまり、脆弱性が低く、サポートが安価です。 QA部門は、品質保証、ユーザーからのフィードバックの受信と操作、研究テストの実施、複雑なスクリプトを使用した新機能のテスト、開発者とのビジネスコミュニケーションの支援に真剣に取り組んでいます。 プロジェクトでのテストは、最初のケースよりも効率的に自動化されていますが、自動化チームはQA部門に現れませんでした。
そして、「自動化QAは別のコマンドですか？」という質問を繰り返します。