Disposable Test !!!

ソフトウェアテストのレトロスペクティブ

2014.03.29 kyon_kao_wedding

自己紹介

きょん(@kyon_mm)

ソフトウェアテストアーキテクト

うさみみ系エンジニア

Groovy, C#, F#, Ruby, Scala

SCMBootCamp, TDDBootCamp, 基礎勉強会, Nagoya.Testing, Cafe.Testing, STAR, TDDeXchange

Test Retrospective

テストの振り返りってしていますか？

テストがどれくらい意味のあるものだったか？

Test Retrospective

in SGT

3/50

=> 6%

Item

テストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグタイプ

Case A Sprint1

テストコード行数/テスト件数 : 1200/30=40.0

テスト規模/バグ数 : 5day/1=5

リリースバグ数/全バグ数 : ?

テストスイートサイクルタイム : 2day

TDDサイクルタイム : 2min

計画的テストケース数/アドホック的テストケース数 : 40/5=8

バグタイプ : 単純な境界値

Case A Sprint4

テストコード行数/テスト件数 : 4000/250=16

テスト規模/バグ数 : 5day/5=1

リリースバグ数/全バグ数 : 2/(30+2)=0.06

テストスイートサイクルタイム : 2day

TDDサイクルタイム : 2min

計画的テストケース数/アドホック的テストケース数 : 250/80=3.125

バグタイプ : シナリオ考慮漏れ、復帰処理漏れ

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Itemテストコード行数/テスト件数

1件あたりのテストコード行数が多いというのは、再利用性が低いコードになっている可能性が高い。4Phaseで共通化できるものがされていないとか。

テストのステップが多くなると、値が大きくなって当然。

コンポーネントテストでBDDするとだいたい4行から10行くらい（Spockで)

統合テストでだいたい12行から30行くらい(kyon_mmフレームワークで)

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Itemテスト規模/バグ数

(例えば)何日かければバグ1件見つけられるか。

個人的には、特定期間で見るよりも最終的な指標として使う事が多い。

考えられる全てのテストをやったが、本当に大丈夫？みたいな感じ。

1から3くらいならokな感覚が多い。（ただし、戦略依存した値）

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Item

リリースバグ数/全バグ数(リリースバグ+開発中発見バグ)数

低ければ低いほどいい。

バグの重要度別に出す方が効果的。

目標は0.002くらい。

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Item

テストスイートサイクルタイム

統合テストレベルのテストケースをある固まりでまとめて、どれくらいの時間でグリーンにできるか。

この値が大きすぎるときは進捗報告し辛いので、テスト設計し直すか、テスト実装がクソか、バグがありまくるか。

2日以下くらいがいい。

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Item

(UnitTestの)TDDサイクルタイム

TDDの1サイクルをまわす時間。

600秒超えてると僕の精神が持たない。

20秒から180秒くらいが目安。

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Item

計画的テストケース数/アドホック的テストケース数

事前に設計したテストケース数と、テストしながら思いついて実行したテストケース数。

自動生成するかとか、プログラマーがどれくらい対象を知っているかでよく変わる。

10以上だと無理難題か、ハイスキルか、テスト知らないか。

3から5くらいがやりやすい。

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Item

バグタイプ

Verification系、Validation系のバランスを大切にする。

バグ原因、バグ混入時期を満遍なく想定してみて、バグの偏りにあたりをつける。

目安とかない。バイザーのバグ分類とか読むと楽しい。

Itemテストコード行数/テスト件数

テスト規模/バグ数

リリースバグ数/全バグ数

テストスイートサイクルタイム

TDDサイクルタイム

計画的テストケース数/アドホック的テストケース数

バグ発見サイクルタイム

バグタイプ

Test Retrospective

テスト戦略基準な振り返りに使えそうな値をあげてみました。

テストケースレベルでの振り返りは非常に難しいです。

正直有効なものがよくわかりません。

テストケースレベルの妥当性判断はFault Injection, Mutation TestやTest Suite Reductionの話になると思います。

ご清聴ありがとぴょん◆