ソフトウェア品質のテストの数について
ソフトウェアの品質を上げる、テストを改善するというと、今までよりもテストの量が増え、大変になるという風に捉えられることがあります。
そういう場合もあるかもしれませんが、必ずしもそうならないこともありますので、少しまとめておこうと思います。
テストの量≠ソフトウェアの品質向上
ソフトウェアの品質向上が重要なので、テストの量を増やすというアプローチはよく聞きます。
ただし、テストの量でテストの質を評価するというのは、ソースコードのstep数で開発能力や機能の難易度を測定するようなものと近いです。
ソースコードの規模で能力や難易度を図るというアプローチを行っているところもまだあるかもしれませんが、昨今はだんだん減っているのではないでしょうか？
会社のルールになっているから仕方なくソースコードの量で測定している、というところもまだあるかもしれません。
テストケースの数などは簡単に測定できるので単純に概要を知りたい場合は有効かもしれません。
ただし、それでテスト自体の本質が分かると思ってしまったり、テストケースの数を増やすことで品質を上げられる、品質を上げるためにはテストを頑張る、という施策を取ってしまうと、作業量は増えて大変になるけれども、本質的には何も改善しないということになり得ます。
アジャイル、DevOps時代の品質
アジャイルやDevOpsの考え方の中では、顧客への提供スピードを早く行い、仮設検証を早く行える仕組みを取り入れていきます。
その仮説検証の結果から更に仮説検証を行うという、仮説検証のフィードバックループを早く行えることが重要となります。
ソフトウェアの品質というと良く挙げられるものにISO/IEC 25000シリーズがあります。
これらの中では、顧客への提供スピードに近い項目というものはありません。
ただし、最近はDORA(Google)の中で、DevOpsの品質測定の基準というものが言及されています。
そのため、ソフトウェアの更新スピード、更新頻度などの価値提供のスピードは品質の一つと捉えられることも多くなってきているかと思います。
ただし、提供スピードが早ければ良いというものでもありません。
個人開発や、企業の最初のプロダクトとして提供する場合は、テストはあまりせず、プロトタイプに近い形でユーザーに提供するということもあるかもしれません。
ただし、一定規模以上の企業の場合、実装されている機能が想定通りに動かなかったり、可用性が低いというような場合は、企業のブランドのイメージダウンに繋がります。
企業ブランドのイメージダウンというのは測定が難しい指標だと思いますが、気が付かないうちにダウンしているということになり得ます。
特にSNSで口コミが広がりやすい昨今ですので、一人のネガティブイメージが拡散されるということもあり得ます。
アジャイル、DevOps時代のテスト量
提供スピードも重要な品質な一つとした場合は、テスト量を単純に増やすというアプローチを取っていていると、気が付かない品質の特性を一つ犠牲にしているということになります。
ではどうするのが良いのかというと、テストに関して以下を徹底的に考えることが重要になります。
- 実施するべきテストを考える
- 実施しないテストを考える
- 効率的なテストを考える
テストの量に関していうと、足りない状態でもなく、余分な状態でもない状態を考えます。
「丁度良い量」、「ほどほどな量」という言い方することもありますが、ちょっと誤解される場合もあるかもしれません。
これらは80点くらいで良いというわけではなく、テストに関して言うと、100やるべきテストがあるとした場合、80でいいというわけではなく、かといって120を行うというわけでもなく、100のやるべきテストがあった場合、100を狙ってテストを実施していく必要があります。
（誤解を招かないように数字に％などは付けないで表現しています）
そのため、テストを改善する場合には、今まで行われていない足りないテストがあればテスト量としては増えるかもしれませんし、今まで余分なテストを実施している場合にはテスト量はむしろ減るかもしれません。
更にそれらのテストを効率的に行えるようにするために適切なテストフェーズでテストが行えるようにしたり（テスト実施タイミング）、効果的なテスト（テスト実施方法）を考えます。
そういったことを考える際には、テスタビリティなどもとても重要な要素になってきます。
自動テストに関して言うとメンテナンスコストなども考慮して、効果的なテストを考える必要があります。
過去にテストの十分性や量などについて、プロダクトのフェーズによってテスト量は増減するべきなのかを考えたことがあります。
私の個人的な考えとですが、達成するべきテストというのはプロダクトのフェーズによって大きくは変わらないと思っています。
新しいプロダクトであっても、テストが不十分でユーザーに影響があった場合、それらは企業ブランドなどのイメージダウンになる可能性があり得ますし、細かい機能追加がメインのプロダクトであっても、余分なテストを多く行うプロセスを採用していると、競合企業に提供のスピードで負けたり、バグ修正の提供スピードが落ちるということに繋がる可能性があります。
最適なテストを考えるには
良いテストを考える際には、単純にテスト量を増やすのではなく、テスト観点が足りない状態でもなく、余分な状態でもない必要十分な量で網羅されているかどうかを考えます。
テスト観点という用語は少し定義が曖昧ですが、テストするべきフィーチャーを考え、そのフィーチャーに関して必要十分なテスト条件や、テストモデルを考えます。
テスト量のように簡単に数に変換できるものでないので、テスト条件をモデル化したり、テストモデルを作成し、カバレッジなどを定めて、評価することで、テストの質を評価し、改善して行くことになります。
テスト条件をモデル化する際には、テスト条件をツリー構造で整理すると良いです。
VSTePなども参考になると思います。
https://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf
一つのテスト条件はなるべく少ないテストケースで確認できるようにテスト条件や、テストモデルをテストケースにしていきます。
実際、このような方法でテスト条件を整理したり、そのテスト条件をどうテストするか、どうテストすると効率的にテストできるかを考えると、テスト量は増えるのではなく、トータルのテスト量は削減されるということも結構あると思っています。
ユニットテスト内に限っても、テスト技法を適切に使ったり、レイヤードアーキテクチャやクリーンアーキテクチャのレイヤーの振る舞いに着目してテストを行うなどの方針を決めることで、テストケース数を削減することができる可能性があります。
最適なテストをテスト計画でどのように計画するか
こういった全体のテストなどの方針を示すドキュメントは、テスト計画になると思っています。
全体的な効率的なテストを考えるためには、ソフトウェアのアーキテクチャや、テスト環境等、色々な物を把握しておく必要があります。
自分はE2Eテストのみが自分の範囲であるとか、APIテスト以上が自分の範囲である、自分はユニットテストしか行わない、という状況では全体を俯瞰して最適なテストを考えるのは難しくなります。
テスト計画を考えるには、そういったことをすべて理解できる人が行うのは理想になります。
フロントエンドや、バックエンド、QAや、開発者など、自分の作業範囲のみでテストを考えるのではなく、全てを俯瞰してテストを考える必要があります。
テスト計画にはテストの自動化も入ってきますので、直近の有期限のプロジェクト限定のテストを対象とするというわけではなくなります。
テスト計画は、自動化方針のようなプロダクトとしてのテスト計画があり、直近のプロジェクトでは、そのプロジェクト特有なプロジェクトとしてのテスト計画を考える必要があると思います。
プロダクトのテスト計画をベースとして、プロジェクトではそれにプロダクトのテスト計画をアドオンしていくイメージになると思います。
こうして、テスト計画で効率的なテストはどういったものか、過不足ないテストを実施するにはどうするかを考えていきます。
プロジェクトの初期にテスト計画を考える場合、そのテスト計画でのテスト条件は抽象的なものなると思います。そのため、具体的なテスト条件は、テスト分析やテスト設計でも考える必要があります。
まとめ
自分なりに考えを少しまとめて文章にしてみました。
過不足ないテストを考えるには、プロジェクトなどを全体的に俯瞰して把握する必要があります。
その際に求められるのは最低限色々なことが分かるT型人材のような人だと思っています。また、大規模になりすぎると全てを把握することが難しくなると思いますので、開発スコープを少なくする、逆コンウェイの法則でマイクロサービスを設計して、開発規模を少なくするなどの工夫も必要になると思います。
なお、この記事に書いている最適なテストの考え方については、AIなどの機械学習を用いた帰納的な判断を行うソフトウェアには適用できないと思います。
AIのテストについては、QA4AIなどの資料を参考にしてください。
