自動テストにおける技術的負債の問題は、自動化の成長とともに認識されるようになりました。テストの数が数百から数千に達した際、その保守はしばしば開発自体よりも高くつき、アーキテクチャ上のエラーが増加しました。
自動化の初期に、テストは迅速に作成され、パターンや標準がなく、その後のリファクタリングも行われませんでした。その結果、自動テストのリポジトリは時代遅れになり、アプリケーションの変更により壊れ、保守にはますます多くの労力が必要になりました。
主な特徴：
テストによるコードカバレッジが高いことは、技術的負債がないことの指標ですか？
いいえ、形式的なカバレッジはテストベースの品質や実行可能性を保証するものではありません：古いまたは「不要な」テストが存在する可能性があります。
技術的負債を排除するためには、一度自動テストのテンプレートを書けば十分ですか？
いいえ、インフラとパターンはプロジェクトの成長に伴い、常に見直しや発展が必要です。
自動テストがよく構造化されている場合、手動テストは完全に不要ですか？
いいえ、常に手動でのスモーク/回帰/ニッチテストが必要であり、自動テストは安定した機能の定期的な「監視」に必要です。
自動テストはレビューなしで書かれ、構造はプロジェクトの進行に伴って変化し、一部のテストはもはや関連性がなく — 40%のテストがアプリケーションの変更により失敗しました。
利点：
欠点：
チームでは、2週間ごとに自動テストのレビューとリファクタリングが行われ、アーキテクチャは採用された標準に従って維持され、テストは最新のユーザーストーリーに密接に関連しています。
利点：
欠点：