スキルアップ

テストの質を測るためのメトリクス

テストの質を測るためのメトリクス

テストの質

世の中には、プロダクトの質やプロジェクトの質、プロセスの質を測るためのメトリクスが存在しますが、このうち、プロダクトの質は「テストの質」に影響を受けます。例えば、テストの質が悪いとそこで得られる“プロダクトの質の情報”があてにならなくなります。プロダクトの質が良く見えるのはテストの質が悪いから、ということもあり得ます。

図表1:テストの質とプロダクトの質

今回は、テストの質を測るためにどんなメトリクスがあるのか、またその指標となる値はどのようになるかをご紹介します。

テストの質を測るためのメトリクスの種類

テストの質を測るためのメトリクスをベリサーブの一部で収集したものがあります。そのメトリクスは以下の通りです。

図表2:テストの質を測るためのメトリクス一覧。一覧は一例です。テスト実行の質もありますが今回は列挙していません

今回はこの中からテストケース有効率、欠陥レポート有効率、テストケース内の欠陥発見率の3つについて紹介します。

なお、紹介する中で参考に「指標」を記載していますが、いずれもベリサーブの実プロジェクトから得られた数値となります。収集した対象となるテストプロジェクトの状況とメトリクスの数値を照らし合わせて算出しています。従って、状況によってこの値は変わりますのであくまで参考値としてみてください。

テストケース有効率

1つ目はテストケース有効率です。このメトリクスによって分かるのは「どれだけ無駄なテストケースを作らなかったか」です。

無駄なテストケースとは、例えば成立しない条件のテストを作ったり、あるテストケースが別の視点から作られたテストケースと重複したり、実装されない機能に対して作ったテストケースです。

図表3:テストケース有効率

このメトリクスの指標は経験上、95%以上としています。もちろん100%がいいのですが、これまでメトリクスを取ってきたテストプロジェクトで、テストの質が高いプロジェクトでは95%以上で収まっています。一方で、テストの質が低いとみられるときは85%に満たないことが多いです。

無駄なテストを作ってしまうのは、仕様の理解が追い付いていないことやテスト設計者のスキルが追い付いていないことが原因として考えられます。このような場合にはテストそのものの質が低いと捉えることができます。また、テスト担当者が初めて経験するプロダクトでテスト設計すると91%前後にとどまることが多い傾向があります。このことからもテスト設計者による仕様の理解度がテストケース有効率につながっていると言えるでしょう。

また、テスト工程での欠陥発見率が低い場合にプロダクト品質が良いと捉えることもできるのですが、もしかするとテストの質が悪く欠陥を見逃していることで欠陥発見率が低くなっている可能性もあります。そのテストの質が良かったのかどうかを見る材料の1つとしてテストケース有効率を使うことができます。

よって、欠陥発見率とテストケース有効率それぞれ片方だけを見るのではなく、両方を見ることが大切です。

更に、このメトリクスは継続的に収集し、比較することでそのテストチームのテストの質の成熟度合いも見えてきます。前述のように最初は91%だったのがそのプロダクトのテストを重ねるごとに徐々に上がってくることがあります。プロダクトの知識が増えていることによって、より良いテスト設計ができるようになると捉えられるからです。

図表4:成熟度が上がるイメージ

欠陥レポート有効率

2つ目は欠陥レポート有効率です。これはテストチームが報告した不正のうち、どれだけ「本当に欠陥であったか」を測るメトリクスです。

図表5:欠陥レポート有効率

この「本当に欠陥であった」とされるものの中には対処される「ソフトウェアバグ」や「仕様の問題」、またソフトウェアバグや仕様の問題で「今回対処しないが次期開発で検討するもの」ももちろん含まれます。逆に欠陥と識別されない不正とは、例えば「テストケースの間違い」「テスト実行のミス」「仕様通りと判定されたもの」が含まれます。

この欠陥レポート有効率が低い、つまり欠陥と識別されない不正が多いということからは、テストケースの質の悪さやテスト実行の質の悪さ、テストチームの仕様の理解不足などのテストの質が見えてきます。また、テストケースの間違いなどは実はテストベースとなる仕様書などの質が悪い場合もあります。よって、このメトリクスではテストの質だけに限らずテストベースの質も見ることができます。

このメトリクスでの指標は85~95%に収まっていると良いです。100%でも良いように思えますが、100%を指標としてしまうとテストチーム側が不正の報告をためらってしまい、結果、要件に対する問題などを出しづらくしてしまうというデメリットがあります。

なお、欠陥と識別されない不正の例で挙げた「仕様通り」には注意が必要です。もともと仕様通りであれば欠陥と識別されない不正でよいのですが、例えば不正の報告をきっかけとして仕様が変更された場合や、明確でなかった仕様を明確にした場合、このメトリクスとしては「有効」にするのが適切です。あくまでテストの質を測るためのメトリクスだからです。これらのメトリクスはあくまでテストの質を測るものであるため、開発の能力を測ることに使用すべきではありません。正しいメトリクスが取れなくなってしまうからです。

図表6:欠陥レポート有効率

テストケース内の欠陥発見率

このメトリクスはどれだけテストケースによって発見できたかというメトリクスです。

図表7:テストケース内の欠陥発見率

テストケースを作成してそれに沿ってテスト実行していると、そのテストケースで確認したい内容以外で欠陥を発見することがあります。例えば、ある処理が問題なく動くことを前提として(事前条件として)テストケースを作っていたにもかかわらず、その事前条件を作り出す過程で欠陥を発見することがあります。また、テストケース中に突然フリーズする事象を発見することがあります。テストケースを作成するに当たって「○○という条件のときにフリーズしないこと」というようなテストケースはなかなか作ることがありません。

これらの欠陥はそのテストケースによって意図して検出しようとした欠陥ではないため、テストケース“外”で発見した欠陥となります。意図していないということはテスト実行者がその事象をたまたま気付いたり、その手順を踏んだりしなければ欠陥を見逃していた恐れがあります。

このメトリクスによって、狙ったとおり欠陥を発見できているかどうかが分かり、ひいてはテストケースの質が間接的に分かります。

指標は75~85%としており、75%を下回るとテスト実行に頼りすぎているためテストケースの質が低いと言えます。もちろんそれはテスト実行者が優秀である場合もありますが、とはいえ、75%を下回るようだとテストケースの質が低い傾向にあると言えます。

また、こういった状況ではプロダクトの品質そのものが悪い場合があります。例えば、システムテストレベルのテストで統合テストレベルの欠陥が多く出る、つまりある処理が動くことを前提としているのにその前提が動いていないと、どうしてもテストケース“外”の欠陥として検出されやすくなってしまいます。

また、指標の上限として85%にとどめているのは、テストケース内の欠陥が85%を超えるような場合、テスト実行者が気付きを得ていない傾向があるからです。あまりにテストケースを厳密にし過ぎるとテスト実行者はテストケースどおりにテスト実行することに注力してしまい、結果、欠陥を見逃しているケースがあるからです。

図表8:欠陥を見逃すリスク

しかし、この指標はプロダクトがどれだけ正確なテストを必要としているか、などによって変わります。安全性を求められる自動車のようなプロダクトではより100%に近い指標にするほうがいいでしょう。

まとめ

いかがだったでしょうか。テストの質を測る上で収集するメトリクス、またそのメトリクスの指標について参考になれば幸いです。

このメトリクスに限らないのですが、メトリクスは何か1つのメトリクスを取っていつでもそれが使えるというような絶対的なものはありません。その時々で必要なメトリクスが変わりますし、プロダクトやプロジェクトによって指標も変わってきます。

メトリクスを収集して分析する上で大切なことは相対的に見ること、複数のデータで見ること、そして、その収集したメトリクスの背景も考慮することです。

例えば、ソフトウェア信頼度成長モデルについても、そのグラフの裏でどういった種類のテストをどのように進めたか、が非常に大切です。

テスト終盤で欠陥を発見するグラフの伸びが収束していなくても機能ごとにテストを進めた場合は終盤でも欠陥が出ます。その場合、決して収束していないことが良くない、とは言い切れず、狙いどおりの動きであればテストを終了してもよい、と判断することも可能です。

また、メトリクスでは「比較」が分析する上で重要です。

例えば、予測との比較、過去のプロジェクトとの比較、類似のプロダクトとの比較、同一プロジェクト内の序盤と終盤との比較、などです。

比較して同じであれば安定している、と言えますし、比較して異なっていると何かアラートが上がっている証拠かもしれません。

補足

この記事は「JaSST’20 Kansaiテクノロジーセッション」で発表した内容を加筆・修正したものです。

SNSシェア

この記事は面白かったですか?

今後の改善の参考にさせていただきます!

Search Articles By The Cast出演者/執筆者から記事を探す

Search Articless By The Categoryカテゴリから記事を探す

Ranking

ランキング

もっと見る