なぜユニットテストはC1カバレッジで80%くらいあるといいのだろう？〜とあるプロダクトの事例〜

はじめに

DevOpsとマイクロサービス時代のQA: 高品質なソフトウェアを目指してと題した記事を公開しました。この記事を振り返りつつ、品質が高いとされる状態とは具体的に何か、自らに問い直してみると、まず思い浮かぶのが「ユニットテストでC1カバレッジ80%以上」という点です。

しかし、なぜユニットテストはC1カバレッジで80%程度あると良いのでしょうか。この点を深掘りしていきたいと思います。

https://youtu.be/Jum0TzxLOnQ

ケーススタディ

背景

6年前、フリーランス時代にインヴァスト証券のマネーハッチというプロジェクトにエンジニアとして参画しました。プロジェクトを進める中で、プロダクトオーナーから「亀ちゃんに任せる」との一言をいただき、プレイングマネージャー兼プログラマーとして活動しました。
※私がマネーハッチに関わったことを公表するのは問題ないことを確認しています。
※この開発に関する詳細は別途記事にします。

リリース後の成果

リリース後、マネーハッチはバグゼロという結果を達成しました。利用者数も、数ヶ月で5000人を超えるなど、決して少なくはありませんでした。

バグや問い合わせの多発を予測して、リリース後1ヶ月は仕事を控え問い合わせ対応に充てる予定でしたが、実際は問い合わせがほとんどなく、その時間をSeleniumでのE2Eテスト作成に費やしました。これについても別途記事にします。

ユニットテストの効果

リリース時のユニットテストカバレッジは90%近くに達していました。正確な数値は残っていませんが、その高いカバレッジがバグゼロに貢献したと考えています。

ブラックボックステストの成果

画面単位でテスト仕様書を作成し、マニュアルテストも実施しましたが、バグはほとんど発見されませんでした。主に変更に伴う認識の齟齬があった程度です。ユニットテストのおかげで、変更による影響は最小限に抑えられました。また、ユーザーストーリーごとにインテグレーションテストを実施し、データのライフサイクルも意識した持続可能なテスト環境を構築しました。

考察

ユニットテストとブラックボックステストの相乗効果

ブラックボックステストでのバグ発見率が低かったのは、ユニットテストがブラックボックステストを補完する形で機能していたためです。特にバリデーションのテストでは、メソッド単位のユニットテストで大部分のテストケースをカバーできていました。

下記の記事で深掘りしています。

• なぜC1カバレッジを採用するのか？：ホワイトボックスがブラックボックスを照らす

デグレードの防止

ユニットテストがメソッド単位で実行されることで、新たなバグの発生を効果的に

検知し、安心して変更を加えることができます。

ビジネス価値

• CS（カスタマーサポート）への問い合わせが少なく、他の価値ある業務に集中できました。
• エンジニアも新たな開発に注力できる時間が増えました。
• 期待以上の売上成長を達成しました（具体的な数字は非公開です）。