回答。

既存のプロジェクトに自動テストを導入することは、複雑で多層的な課題です。

問題の歴史: 手動でのテストが長期間行われている組織では、プロセス、ドキュメント、コードのアーキテクチャが自動化の要件に必ずしも合致しません。テスターは自動化ツールに対する経験がなく、テストとアプリケーション自体のアーキテクチャは、自動テストの迅速な実行をサポートしていない場合があります。

問題: 導入の主な課題は以下の通りです：

1. 自動化の文化の欠如：経験、ツール、プロセスがありません。
2. レガシーコードの複雑さ：テストの統合が難しく、テスト可能なインターフェースや要素の安定した構造が欠けています。
3. 優先順位付けの基準の欠如：何を最初に自動化すべきか、どこで最大の効果が得られるか？

解決策: チームは以下の段階を経なければなりません：

1. 準備状況の評価：時間を節約するために、最も重要で頻繁に繰り返される手動テストを特定します。
2. パイロット実施：システムの小さな部分を選び、仮説を迅速に検証するためのパイロット自動テストセットを実装します。
3. 段階的な導入：パイロットの成功に伴い、自動テストのカバレッジを拡大し、同時に自動化のためのチームをトレーニングします。

キーとなる特徴：

• 自動化は回帰テストと"スモーク"テストから始めると良いでしょう。
• 自動テストを既存の開発プロセスに組み込む（例えば、プルリクエストごとに実行する）ことが重要です。
• コミュニケーションに注意し、自動化の利点と制限をビジネスとテスターに説明する必要があります。

トリッキーな質問。

自動テストが手動テストを完全に置き換えることができますか？

いいえ。高いカバレッジがあっても、自動テストは繰り返し可能で決定的なシナリオにのみ適用されます。ユーザビリティのバグ、探索的テスト、デザイン上の欠陥、典型的でない"人間の"バグは通常手動で発見されます。

すべてのテストケースを無条件に自動化する必要がありますか？

いいえ。すべてのテストケースを自動化することは正当化されません：低頻度または複雑なシナリオは、高コストと低いリターンのため手動テストのままにしておく方が良いです。

テスターは自動化を成功させるためにプログラマーである必要がありますか？

いいえ、しかし基本的なプログラミングレベルが望ましいです。チームは通常、経験豊富なテスターと自動テストのアーキテクチャ、そして自動化の開発者によって構成されます。

一般的な間違いやアンチパターン

• 優先順位を定めずにすべてを自動化しようとする試み。
• 手動テストと自動化側の間のコミュニケーション不足。
• "流行の"ツールを選び、特定のプロジェクトに適したツールを選ばない。
• 自動テストのサポートと更新プロセスの欠如："実行して忘れる"。

実際の例

ネガティブケース

会社はすべての手動テストを同時に自動化することを決定し、別のチームを作らず優先順位を話し合いませんでした。流行のツールを購入しましたが、必要なブラウザの一部をサポートしていませんでした。結果的に、四半期後には半分のテストが機能しなくなりました。

利点:

• 迅速な初回導入、チームの意欲。

欠点:

• 巨大なコスト、すぐに訪れた失望、トレーニングにかかる費用、実際に必要なシナリオのカバレッジが低いこと。

ポジティブケース

チームは手動で最も頻繁に行われる10の回帰シナリオを選びました。Python（Selenium）で自動化のトレーニングを行い、CIにテストを追加しました。半年後、70%の回帰チェックが自動的に実行され、手動テスターはクリエイティブな作業を行いました。

利点:

• 実際の時間の節約、チームの専門知識の向上、人為的な要因の低減。

欠点:

• インターフェースの変更に伴う自動テストの更新コスト、長いスタート。