こんにちは、LIFULLのSET(Software Engineer in Test)のRueyです。
前回は自動テストの指標とEMTE(Equivalent Manual Test Effort)に関する記事を書きました。
そして先日開催されたSTAC 2020でも同じテーマで登壇させていただきました。
www2.slideshare.net
この発表では自動テストの評価指標の中でEMTEと関連がある3つの指標のみ紹介しました。
今回はそれ以外の指標の説明と使い方を紹介したいと思います。
はじめに
ISTQB CTAL-TAE(Advanced Level Test Automation Engineer)のシラバスで自動テストの13個の指標が書いてありますが、それぞれの説明が一言だけで、細かい使い方などは一切説明はされておりません。
そこで、私はシラバスの内容と自分の自動テストの経験をもとにまとめました。本記事を読んで、評価する時にどの指標を使うかをイメージができれば幸いです。
なお、世の中全部の自動テストの目的や構成などが同じにはなりませんので、この記事を読んだ上で自分の自動テストに合わせて調整し、計測指標を使っていただければいいと思います。
自動テストの評価指標 (メトリクス)
自動テストを評価するときにいろいろな指標を測って、テストの目的が達成しているかを確認します。
ISTQB CTAL-TAEのシラバスにある13個をそれぞれ翻訳しました。 次の章は指標を分類してそれぞれの指標の説明と使い方を紹介したいと思います。
※ 翻訳も個人でやりましたので、他の方の訳し方と違う可能性があります
- 外部要因指標
- 自動化メリット
- 自動テストの構築工数
- 自動テストの結果分析工数
- 自動テストのメンテナンス工数
- 同じ欠陥によるケース失敗率
- 自動テストの実行時間
- 自動テストのケース数
- 自動テストのケース成功/失敗数
- 自動テストの結果誤判定数
- 自動テストのカバレッジ
- 内部要因指標
- 分析ツールの結果メトリクス
- 自動テストのコードの欠陥密度
- 自動テストシステムのコンポーネントの効率性
分類する
使い方とタイミングを合わせて、下記四種類に分類します。
※ ここは個人で考えた分類であり、シラバスでは特に分類していません
- 恩恵系
- 工数系
- 自動テスト運用系
- 品質系
恩恵系
恩恵系の指標は自動化により得られたメリットです。 自動テストの実装と実行後のタイミングに集計することができます。
使うタイミング:
テスト自動化により、改善できた部分を確認したいとき
指標:
- 「自動化メリット」
自動化メリット
シラバスでは「自動化メリット」指標をさらにいくつかの小指標で分けています。
手動テストから節約できた時間 (Number of hours of manual test effort saved)
手動から自動にして、節約できた時間です。これは一番わかりやすいメリットだと思います。
計算式は「手動でのテスト実行時間」ー 「自動でのテスト実行時間」です。
工数系の指標と併用すると費用対効果のグラフもかけると思います。詳細は前回の記事を参照してください。
回帰テストで節約した時間 (Reduction in time to perform regression testing)
この指標は上と同じ、自動化して節約できた時間です。回帰テストは基本同じ手順、長期間の運用で何回も実行するので、自動化を導入しやすいです。
計算式は「自動化前の回帰テスト実行時間」ー 「自動化後の回帰テスト実行時間」です。
追加で達成したテストサイクル (Number of additional cycles of test execution achieved)
テストサイクルが自動化により早くなると開発効率も上がると思います。
例えば、以前はリリース前に必ず実行する回帰テストのケースが多すぎて、実行時間が長く一週間で2回しかリリースできない状況でした。ですが、自動化によるテストの実行が非常に短縮された結果週に5回リリースできるようになりました。
追加で実行されたテストケースの割合 (Number or percentage of additional tests executed)
以前実行できない部分もできたので、これもメリットがわかりやすい指標だと思います。
全テストケースに対して自動化したケースの割合 (Percentage of automated test cases related to the entire set of test cases)
部分的に自動化をした状態では、基本的に自動化した部分の効率がよくなるので、全体の効率もよくなると思います。
この指標は高い程メリットが多いと思います。
カバレッジの増加 (Increase in coverage)
より多くのケースが実行できるので、カバーできる範囲も大きくなると思います。
この指標は高い程メリットが多いと思います。
自動化することでより早く発見した欠陥数 (Number of defects found earlier because of the TAS)
テストの実行が早くなったので、欠陥があればより早く発見できます。自動化による開発サイクルのテストシフトレフトもあるので、より早い段階で欠陥を見つけることができます。
自動テストでしか拾えない欠陥数 (Number of defects found because of the TAS which would not have been found by manual testing)
自動化は手動より短時間で大量のケースが実行できるようになるので、信頼性テストや負荷テスト的なケース実行もできるようになります。それにより、手動で検知できない欠陥を見つけることができます。
工数系
工数系は13個の指標のうち工数で取得するものです。
目標段階で予定した工数以内で、自動テストができたかの確認指標です。
自動テストのメイン作業の消費工数の確認するため、以下を測ればいいと思います。
使うタイミング:
チームの想定する工数内に収めるため、自動テストの消費工数を確認したいとき
指標:
- 「自動テストの構築工数」
- 「自動テストの結果分析工数」
- 「自動テストのメンテナンス工数」
前回の記事でこの部分を紹介したので、今回は割愛します。 工数系の指標に興味があれば、是非前回の記事を参考にしてください。
自動テスト運用系
自動テスト運用系は自動テストの効果を測る指標です。
自動テストの効果は短期間ではあまり参考にできないので、長い期間で継続的に集計した方がおすすめです。
使うタイミング:
自動テストをしばらく運用し、効果を確認したいとき。または自動テストを見直したいとき
指標:
- 「同じ欠陥によるケース失敗率」
- 「自動テストの実行時間」
- 「自動テストのケース数」
- 「自動テストのケース成功/失敗数」
- 「自動テストの結果誤判定数」
- 「自動テストのカバレッジ」
同じ欠陥によるケース失敗率
普段のコードは疎結合が大事だと思いますが、テストコードも同じです。
一箇所に問題が発生して、影響を受けたケースが多くなると自動テスト結果分析の時に確認しづらくなります。
この指標はなるべく低い状態がいいと思います。
自動テストの実行時間
一番シンプルな指標、低い程効率がいいです。
手動の実行時間と比較したいときにEMTEで変換してもいい指標です。
自動テストのケース数
自動テストの規模確認用の指標。規模がどんどん肥大化すると実行速度に影響がでやすいですし、結果分析の時も確認しづらくなります。
※ ケースが多いほどカバレッジが高いわけではありません。
自動テストのケース成功/失敗数
自動テストの状態確認用の指標です。
普段は自動テストの結果として使っています。成功率はリリースできるかのクオリティゲートとしても使われることがあります。
また、常に失敗するケースが存在する場合、効果がないテストケースが存在することが分かります。
失敗数が少ない方がいい指標です。
自動テストの結果誤判定数
自動テストの信頼性の指標です。False PositiveとFalse Negativeがあります。
False Negativeは成功になるテストケースを失敗に判定されるので、多くなると自動テストの信頼性が下がり、結果があまり参考にならない状態になります。
逆にFalse Positiveは失敗になるテストケースを成功に判定されます。テストケースの検証メソッドの実装ミスの恐れがありますし、そして、見つけられる欠陥も見つからない状態になるかもしれません。
できるだけ誤判定数が減った方がいい気がします。
自動テストのカバレッジ
自動テストの担保範囲の確認指標です。
よく知られている指標だと思います。自動テストが機能もしくは要求・要件をどれぐらいカバーできているかを表します。
運用コストにもよりますが、この指標はできるだけ高くすべきだと思います。
品質系
内部要因の指標は全部品質系になります。
普段の開発でコードの品質を意識すると思いますが、テストコードも同じく品質が大事です。
長く運用したいなら自動テストのコード品質を意識すべきだと思います。
使うタイミング:
自動テストの品質を確認したいとき
指標:
- 「分析ツールの結果メトリクス」
- 「自動テストのコードの欠陥密度」
- 「自動テストシステムのコンポーネントの効率性」
分析ツールの結果メトリクス
普段のコードと同じく、静的解析などのツールを利用して、いろいろなメトリクスを測ります。よく取るメトリクスはLOC(Line of code)、コード複雑度、技術負債の返済期間など。
どのメトリクスを見ればいいかは決まっていないですが、項目ごとに納得できるしきい値を守りましょう。
自動テストのコードの欠陥密度
テストコードも同じく欠陥があります。
計算式は「欠陥数」/「コード総行数」です。
1行のコード内におよそどれぐらいの欠陥があるかの指標です。
欠陥密度は高い程、欠陥が現れやすいので、低い状態を維持した方がいいです。
自動テストシステムのコンポーネントの効率性
自動テストはテストコード自身の影響以外にも影響される部分が多いです。
自動テストの品質はテストコードだけではなく、自動テストシステム全体で見るべきだと思います。テスト対象の反応速度は毎回同じではなく、負荷による変化もあるので、自動テスト全体の効率に影響が出ます。
自動テストコードの実装は各コンポーネントの効率と変更の可能性を考慮し、調整し続けるべきだと思います。それを怠ると、Flakyのケースは多くなります。
指標の使用例
自動テストの指標は評価するときに使われます。
ここからは各シナリオで、どの指標を利用して評価するかを見ていきましょう。
シナリオ1
重大なリリースがあって、大量のページをリリース前に全部チェックをしたい。
自動テストは一回のみ利用します。
ポイント:
「短期利用」、「広範囲のカバー」
使う指標:
「恩恵系」
短期利用なので、工数系、自動テスト運用系、品質系は特に考えなくていいと思います。 大量のページをチェックしたいので、恩恵系の「増えたカバレッジ」、「追加で実行できたケース数」を集計し、目標のページ数を達成したかの確認ができます。
シナリオ2
既に手動の回帰テストがありますが、チームの工数が厳しい状態です。
自動化して工数を節約したいし、自動テストの運用工数を最小限にしたい。
ポイント:
「運用工数」、「節約」
使う指標:
「工数系」、「恩恵系」
節約時間は恩恵系の「手動テストから節約できた時間」で分かります。
構築した後工数系の指標を測ることで、実際に前より工数の合計が少なくなっていることが確認できますし、構築にかかる工数が節約されることにより還元される期間も分かります。
シナリオ3
大規模のシステムに3年以上運用できる自動テストを導入したい
ポイント:
「長い運用」
使う指標:
「品質系」
長い運用であれば品質系の指標を測りましょう。
静的解析ツールを導入し、自動で「分析ツールの結果メトリクス」が取れれば、テストコードの状況が把握できます。大体の静的解析ツールは品質の評価点を表示すると思いますので、想定内の品質の評価点で構築できたかを確認できますし、今後の運用で技術負債が増えることもすぐ把握できます。
運用しながら、静的解析ツールの指摘で継続的にテストコードの品質を守りましょう。
シナリオ4
既に運用中の自動テストを効果を確認し、見直しが必要な部分を確認したい
ポイント:
「効果を確認」
使う指標:
「自動テスト運用系」
しばらく自動テストを運用したら、自動テスト運用系の集計はできると思います。
また、現状確認しつつ傾向も分かると思いますし、以前より劣化した指標がリストアップできます。
すると、各指標に対して、自動テストの状態に合わせた対策を考えられます。
おまけ
上記の指標で自動テストの評価ができますが、ビジネスの観点で予算から考えたい時もあるかと思います。
その場合は工数系の指標を担当者の人件費として計算すれば考えやすいでしょう。
そして自動テストの実行時間などは各サーバーの運用代で置き換え計算が出来ます。
ビジネス目標:
今期の予算50万で自動テストを構築する。
金額変換:
- 人件費は2000円/hr
- サーバー代は1000円/hr
計算:
- 今回の自動テストの構築工数は50時間
- 運用工数は一回の実行で30分
- 毎営業日でテスト1時間実行
今期の金額は:
※ 一期は120日で計算
構築50hr + 毎日30分の運用工数 * 120日 + 毎日1時間のサーバー実行 * 120日
= 50* 2000 + 0.5 * 2000 * 120 + 1 * 1000 * 120
= 100,000 + 120,000 + 120,000
= 340,000円
今期の予算内で出来ました!
最後
今回は全部の指標に対して説明と使い方を紹介しました。
皆さんも少しイメージができましたでしょうか。
実際には自動テストを構築する前に何を測るべきかを決められないと思うので、
状況に合わせて自動テストを試し、いろいろな指標を実際に測ってみればより分かると思います。
ぜひ自分の自動テストに必要な指標で評価しましょう。