最終回 (!)

システムテスト自動化 標準ガイド読書会

第 8 章 メトリクス

2015/08/22ふじわらようへい

　　　自己紹介

ふじわらようへい

品質保証やってます テスト戦略策定 / テスト計画策定

テスト分析 / テスト設計 / テスト実装テスト実施 / テスト自動化（ CI ） / レポートリリース判定 / テストマネジメント

プロジェクトリーダ 部署横断での開発基盤構築

JaSST Tokyo 実行委員 WACATE 実行委員

@_mirer

　　　第 8 章 メトリクス 概要

第 8 章 メトリクス 目次 18.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと　　テスト自動化の目的

8.4 ソフトウェアテストの属性8.5 テスト自動化の属性

：

第 8 章 メトリクス 目次 2：

8.6 最高のテスト自動化の枠組みは　　どれだろう

8.7 本当に全てを計測すべきなのか？

8.8 まとめ

　　　本編

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

燃費を計算する理由 自動車が良い買い物だったか どうかを判断するため

選択肢の評価、代案との比較、 改善のモニタのため

問題の早期発見や予測のため 標準や競合に対する ベンチマークのため

投資利益率 ROI　予測および評価のために使われる

テスティングの改善の ROIDDP → 後述！どれだけテストにコストを掛けるか

テスト自動化の ROI手動実行のテストのコストと比較ただし、上記がすべてではない

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

「どんなものであっても、　何らかの方法で計測できるし、　それは計測しないより優れている」　　　　　　　　　　　　 Tom Gilb

「計測できないものは制御できない」　　　　　　　　　　 Tom DeMarco

計測できるもの 1コード行数ファンクションポイントオブジェクトコードサイズ判定の数 → 循環的複雑度発見された欠陥の数工数開発者の数

計測できるもの 2 　 テスト編テストスイートに含まれるテストの数計画しているテスト数実施済みのテスト数成功したテスト数　 → テスト進捗率テスティングの工数テスティングで発見された欠陥の数カバレッジ

計測できるもの 3 　 自動化編自動化スクリプトの数自動化されたテストの数自動テストの実行時間テスト自動化のメンテナンス工数欠陥が原因で失敗したテストの数

役に立つ計測指標は何か？計測はあくまで手段

『何を知りたいか』という　目的に依存する

目的を把握する必要がある

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

テスティングの目的様々

組織テスト領域テストレベルドメイン / テスト対象時期・時間　　　　　…によって異なる

テスト自動化の目的（抜粋）反復可能で一貫したテスティング人手の要らないテスト実行リグレッションバグの発見より頻繁なテスト実行ソフトウェアの品質をより良くするテストをより完全にする

より多くのバグの発見

調査によると、多くの組織で目標を十分に達成できていない

良い目標 → 達成可能な目的

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

ここから後半

「テスト自動化」の計測…の前に「テストそのもの」の計測

貧弱なテストを自動化しても、利益をほとんど生まない

テストの有効性を計測するには…？

→DDP

DDP 欠陥検出率  

 

注意点DDP は事後の計測である

→ DDP の値は変化する

潜在的な欠陥の数は誰にも分からないバグ報告が無い ≠ バグが無い

→ 完璧な情報は決して得られない

テスティングや運用規模に依存する→ 使われなければ欠陥も見つからない

リリース直後でまだ不具合報告が無いと DDP は 100% にならないか？→ なります　 が、それは無意味な指標なので　 通常は期間をとって計算する

時間経過と供に不具合報告が増えるとDDP はどんどん下がらないか？→ 下がります　 が、不完全であっても使い方次第で　 有用な指標になる

ある保険会社のファイナンスシステムの例

1年目1ヶ月目： DDP 70%10ヶ月目： DDP 50%

↓テストの方法を改善↓2年目

1ヶ月目： DDP 92%

オプション欠陥の深刻度を導入する本来検出すべきだったテストステージや欠陥のタイプでカテゴライズする　→ バグ分析

アジャイル開発でのバグの扱いは？　→ 累積的に計測することを提案　　 傾向は読み取れる

DDP を使う場合は、一貫した見方で DDP を使うことです。

そのためには、テストの方針を予め意志決定する必要があります。

「正確性は重要でありません。一貫性の方がより重要」（ Dorothy氏）。

一部 http://gihyo.jp/news/report/2013/01/3101 より引用

その他の指標  

テストの徹底性の計測良いテストの定義とは、欠陥を見つけるテストのことだ　　　Myers

では、欠陥を見つけないテストは役に立たないテストか？→ そんなことはない

徹底性の評価主観的な評価客観的な評価

コードカバレッジステートメントカバレッジブランチカバレッジコンディションカバレッジ　… etc

ただし、カバレッジ≠徹底性

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

テスト自動化において計測すべき属性を提示

保守性 効率性 信頼性 柔軟性

ユーザビリティ 堅牢性 移植性

保守性→ メンテナンス（コスト）

メトリクス：1 テストの更新にかかる時間、工数ソフトウェアの変更の発生頻度

大きな仕様変更は、自動化システムに影響を与えることがある

効率性コストと密接な関係

引用：システムテスト自動化標準ガイド

信頼性テスト結果は正確か、再現性はあるか

メトリクス：テスト設計やテスト自動化の欠陥など、

「テストそのものの」欠陥その欠陥のせいで必要となったテスト

サイクルやイテレーションの数テスト結果が、実は間違っていた数

柔軟性様々なテスト目的に対応できるか

メトリクス：特定バージョンに対するテストのために使う時間特定のバージョンのためのテストセットの特定にかかる時間

テストケースのサブセットの指定に利用可能な選択基準の数

アーカイブされたテストケースをリストアするのに必要な時間や工数

ユーザビリティ自動化の枠組みのユーザーを考慮

メトリクス：枠組みへテストケース追加に必要な時間自動テスト実行結果の確認に必要な時間自動テストの枠組みの使いやすさ

堅牢性ソフトウェアの変更・安定性に対して

どれだけ枠組みが有効であるか

メトリクス：1 つの欠陥で失敗するテストの数自動テストが「つまずく」頻度テストがつまずくまでの間隔予期しない障害の原因調査に要した時間

移植性その自動化の枠組みは様々な環境でも

実行できるかメトリクス：新しい環境、新しいハードウェアプラット

フォームを導入してから、自動テスト実行を成功させるまでの時間や工数

異なるテストツールを使用してテスト実行するのに必要な時間や工数

環境の種類の数

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

引用：システムテスト自動化標準ガイド

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

本当に全てを計測すべきなのか？この読書会に参加しているみなさんはお察しのことと思いますが…

→No!

自分たちにとって最も重要な目的

テスティングやテスト自動化の枠組みを監視できるもの

3 つか 4 つ

数ヶ月継続監視し、学習成果を把握

有用でなければ、変更すべし

8.1 なぜテスティングと　　テスト自動化を計測するのか

8.2 計測できるもの8.3 テスティングと

　　テスト自動化の目的8.4 ソフトウェアテストの属性8.5 テスト自動化の属性8.6 最高のテスト自動化の枠組みは

　　どれだろう8.7 本当に全てを計測すべきなのか？8.8 まとめ

テスティング / テスト自動化は計測可能、計測すべきもの

ROI, 評価や比較、問題の早期発見、予測、ベンチマーク

何を計測するかは、目的に関連する

テスティングの有効性は欠陥検出率、欠陥修正、信用度の獲得に関連付けられる

テスト自動化の枠組みのための属性は保守性・効率性・信頼性・柔軟性・ユーザビリティ・堅牢性・移植性がある

テスト自動化の枠組みの計測は重要

計測を通してのみ、監視と管理が可能最適化が進められる

一方で、達成可能であること、目的に合致していること、役に立つことという、現実面も大事

手段と目的を履き違えないように！

参考文献 JaSST’13 Tokyo 基調講演「 Challenges in Software Testing

ソフトウェアテストのチャレンジ」 - Dorothy Grahamhttp://www.jasst.jp/symposium/jasst13tokyo/pdf/A1.pdf

テスティングにまつわる過去，現在，未来を Dorothy Graham氏が語る─ソフトウェアテストシンポジウム 2013 基調講演http://gihyo.jp/news/report/2013/01/3101

資格認定 ISTQB はソフトウェア・テストの何を変えたのか？ ――ソフトウェアテストシンポジウム 2013東京（ JaSST‘13 Tokyo ） http://www.kumikomi.net/archives/2013/02/rp05jast.php