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

最終回(!)
システムテスト自動化標準ガイド
読書会
第8章メトリクス
2015/08/22
ふじわらようへい

 ふじわらようへい
 品質保証やってます
 テスト戦略策定/テスト計画策定
テスト分析/テスト設計/テスト実装
テスト実施/テスト自動化（CI）/レポート
リリース判定/テストマネジメント
 プロジェクトリーダ
 部署横断での開発基盤構築
 JaSST Tokyo 実行委員
WACATE 実行委員
@_mirer

第8章メトリクス概要

第8章メトリクス目次1
8.1 なぜテスティングと
テスト自動化を計測するのか
8.2 計測できるもの
8.3 テスティングと
テスト自動化の目的
8.4 ソフトウェアテストの属性
8.5 テスト自動化の属性
：

第8章メトリクス目次2
：
8.6 最高のテスト自動化の枠組みは
どれだろう
8.7 本当に全てを計測すべきなのか？
8.8 まとめ

どれだろう
8.8 まとめ

燃費を計算する理由
 自動車が良い買い物だったか
どうかを判断するため
 選択肢の評価、代案との比較、
改善のモニタのため
 問題の早期発見や予測のため
 標準や競合に対する
ベンチマークのため

投資利益率 ROI
予測および評価のために使われる
テスティングの改善の ROI
 DDP → 後述！
 どれだけテストにコストを掛けるか
テスト自動化の ROI
 手動実行のテストのコストと比較
 ただし、上記がすべてではない

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

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

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

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

役に立つ計測指標は何か？
計測はあくまで手段
『何を知りたいか』という
目的に依存する
目的を把握する必要がある

テスティングの目的
様々
 組織
 テスト領域
 テストレベル
 ドメイン/テスト対象
 時期・時間
…によって異なる

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

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

どれだろう
8.8 まとめ
ここから後半

「テスト自動化」の計測
…の前に「テストそのもの」の計測
貧弱なテストを自動化しても、
利益をほとんど生まない
テストの有効性を計測するには…？
→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
 ただし、カバレッジ≠徹底性

テスト自動化において
計測すべき属性を提示
保守性効率性信頼性柔軟性
ユーザビリティ堅牢性移植性

保守性
→ メンテナンス（コスト）
メトリクス：
1テストの更新にかかる時間、工数
ソフトウェアの変更の発生頻度
大きな仕様変更は、自動化システムに
影響を与えることがある

効率性
コストと密接な関係
引用：システムテスト自動化標準ガイド

信頼性
テスト結果は正確か、再現性はあるか
メトリクス：
テスト設計やテスト自動化の欠陥など、
「テストそのものの」欠陥
その欠陥のせいで必要となったテスト
サイクルやイテレーションの数
テスト結果が、実は間違っていた数

柔軟性
様々なテスト目的に対応できるか
メトリクス：
 特定バージョンに対するテストのために使う時間
 特定のバージョンのためのテストセットの
特定にかかる時間
 テストケースのサブセットの指定に利用
可能な選択基準の数
 アーカイブされたテストケースを
リストアするのに必要な時間や工数

ユーザビリティ
自動化の枠組みのユーザーを考慮
メトリクス：
枠組みへテストケース追加に必要な時間
自動テスト実行結果の確認に必要な時間
自動テストの枠組みの使いやすさ

堅牢性
ソフトウェアの変更・安定性に対して
どれだけ枠組みが有効であるか
メトリクス：
1つの欠陥で失敗するテストの数
自動テストが「つまずく」頻度
テストがつまずくまでの間隔
予期しない障害の原因調査に要した時間

移植性
その自動化の枠組みは様々な環境でも
実行できるか
メトリクス：
新しい環境、新しいハードウェアプラット
フォームを導入してから、自動テスト実行
を成功させるまでの時間や工数
異なるテストツールを使用してテスト実行
するのに必要な時間や工数
環境の種類の数

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

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

自分たちにとって最も重要な目的
テスティングやテスト自動化の枠組み
を監視できるもの
3つか4つ
数ヶ月継続監視し、学習成果を把握
有用でなければ、変更すべし

テスティング/テスト自動化は
計測可能、計測すべきもの
ROI, 評価や比較、
問題の早期発見、予測、ベンチマーク
何を計測するかは、目的に関連する

テスティングの有効性は
欠陥検出率、欠陥修正、信用度の獲得
に関連付けられる
テスト自動化の枠組みのための属性は
保守性・効率性・信頼性・柔軟性・
ユーザビリティ・堅牢性・移植性
がある

テスト自動化の枠組みの計測は重要
計測を通してのみ、監視と管理が可能
最適化が進められる
一方で、達成可能であること、
目的に合致していること、
役に立つことという、現実面も大事
手段と目的を履き違えないように！

参考文献
 JaSST’13 Tokyo 基調講演「Challenges in Software Testing
ソフトウェアテストのチャレンジ」 - Dorothy Graham
http://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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à システムテスト自動化標準ガイド読書会第8章

Similaire à システムテスト自動化標準ガイド読書会第8章 (20)

Dernier

Dernier (12)