テック
リグレッションテストの自動化:スプリントを丸ごと費やさない進め方
テストがほとんどないコードベースで、どこから手を付けるか。重要なフローを優先し、CIで高速なテストを回し、チームの手を止めずに進める方法を解説します。
リグレッションとは、動いていた機能が変更後に動かなくなることです。リグレッションテストは、顧客より先にそれを見つけるためにあります。多くの若いチームが抱える問題は、コードベースがテストより速く大きくなり、遅れを取り戻すには、誰も確保できないスプリントが丸ごと1つ必要に思えることです。
ここでは、小さなリリースを重ねながら前に進む方法を紹介します。
1. 止まったときの損失が大きいフローから始める
止まったときに最も損失が大きいフローを5つ挙げます。サインアップ、ログイン、プロダクトの中心となる操作、データのエクスポート、通知の送信です。フローごとにE2Eテストを1本用意するだけで、重要な部分は守られます。
2. 変更する前に、現在の振る舞いを固定する
古いコードでは、まず特性テスト(characterization test)を書きます。特性テストは、コードが本来すべきことではなく、今実際に行っていることを記述します。これがあれば、コードを変更したときに振る舞いが変わったかどうかをすぐに確認できます。
3. テストスイートを高速に保つ
遅いテストスイートは、いずれ無効にされます。CI(継続的インテグレーション)での実行時間は数分を目標にします。
- ビジネスロジックにはユニットテスト
- データベースやAPIとのやり取りには、少数の結合テスト
- E2Eテストは最小限にとどめ、重要なフローに絞る
4. プルリクエストごとに実行する
自動で実行されないテストは、何も守りません。テストスイートをCIに組み込み、失敗したらマージをブロックします。
5. 不安定なテストにはすぐ対処する
ランダムに失敗するテストは、失敗を無視する習慣をチームに植えつけます。まず隔離し、原因(待機処理、実行順序、共有データ)を修正してから、テストスイートに戻します。
AIはどこで役立つか
AIは、既存のコードやチケットからテストの下書きを作るのに役立ちます。境界値のケース、テストデータ、特性テストなどです。ただし、レビューの代わりにはなりません。誤っているのに通ってしまうテストは、テストがないよりも有害です。ルールは人が書いたコードと同じです。すべてのテストはプルリクエストとして届き、御社のチームがレビューしてからマージします。
まとめ
- 価値のない高いカバレッジ率より、重要な5つのフローを確実にカバーするほうが効果的です。
- 高速なテストを、プルリクエストごとに実行します。
- 不安定なテストは一切放置しません。
テストと移行をプルリクエストで納品し、御社のチームがレビューしてマージします。詳しくは開発チーム向けのサービスをご覧ください。