🧪
Google Testing Blog 'How Much Testing is Enough?'まとめ
Google Testing Blogの記事『How Much Testing is Enough?』を読んだ時のメモ
「リリースのためにどれくらいテストをすべきか？」に対してどんな対象に対しても通用する答えはない。
しかしそれぞれのケースでテスト戦略を検討するにあたって拠り所にできる方針はある。
記事に記載されている方針は以下の7つ
手順や戦略の文書化
- 目的
- 次回以降のリリース時に参照するため
- 後の改善活動での分析の際の参考資料とするため
- テスト計画/戦略文書はプロダクトデザインと同時に存在すべき
充実したユニットテスト
- 目的
- 後の結合テスト、デバッグ、修正をする際の時短
- コードを修正する際は該当箇所に対応するユニットテストを作成すること
結合テストをないがしろにしない
- 目的
- より安定な（対e2eテスト）でまとまった振る舞いを検証するため
- e2eで同じ振る舞いを検証できるが、結合テストは依存関係が少ない分安定しているから好ましい
クリティカルなユーザー導線に対するe2eテスト
- 目的
- ユーザーにとって重要な目的を達成するに至るまでの流れを検証するため
- ユニットテスト > 結合テスト > e2eテストの順に総数は大きくなる
画像引用元
多要素のテストに対する理解と実装
たとえば以下のような内容
- パフォーマンス
- 負荷およびスケーラビリティ
- 耐障害性
- セキュリティ
- アクセシビリティ
- ローカライゼーション
- グローバリゼーション
- プライバシー
- ユーザビリティー
codeと機能のカバレッジに対する理解
- codeカバレッジ
- codeの総体に対するテストカバー率
- カバーされている≠バグがない
- changelistカバレッジ
- 追加/修正された行に対するテストカバー率
- 非カバー範囲の増減を把握できる
- featureカバレッジ
- カバレッジの区分単位を機能とする
- behaviorカバレッジ
- カバレッジの区分単位をユーザー導線とする
現場からのフィードバックの活用
- 実行可能なアクションとしてフィードバックを解釈するのが重要
- 実行可能なアクションとは？
- 実際に起きたこととテストしていることの差が明確
- テスト戦略が明確
- どんな種類のテスト（負荷やfault tolerance）が不足している。など
Discussion