kyon_mm * kaori_t_spica 結婚祝いLT大会 in Tokyoでの発表資料です。

1. Disposable Test !!!
ソフトウェアテストの
レトロスペクティブ
2014.03.29 kyon_kao_wedding

2. 自己紹介
きょん(@kyon_mm)
ソフトウェアテストアーキテクト
うさみみ系エンジニア
Groovy, C#, F#, Ruby, Scala
SCMBootCamp, TDDBootCamp, 基礎勉強会,
Nagoya.Testing, Cafe.Testing, STAR,
TDDeXchange

3. Test Retrospective
テストの振り返りってしていますか？
テストがどれくらい意味のあるものだったか？

4. Test Retrospective
in SGT
3/50
=> 6%

5. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグタイプ

6. Case A Sprint1
テストコード行数/テスト件数 : 1200/30=40.0
テスト規模/バグ数 : 5day/1=5
リリースバグ数/全バグ数 : ?
テストスイートサイクルタイム : 2day
TDDサイクルタイム : 2min
計画的テストケース数/アドホック的テストケー
ス数 : 40/5=8
バグタイプ : 単純な境界値

7. Case A Sprint4
テストコード行数/テスト件数 : 4000/250=16
テスト規模/バグ数 : 5day/5=1
リリースバグ数/全バグ数 : 2/(30+2)=0.06
テストスイートサイクルタイム : 2day
TDDサイクルタイム : 2min
計画的テストケース数/アドホック的テストケー
ス数 : 250/80=3.125
バグタイプ : シナリオ考慮漏れ、復帰処理漏れ

8. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

9. Item
テストコード行数/テスト件数
1件あたりのテストコード行数が多いというの
は、再利用性が低いコードになっている可能
性が高い。4Phaseで共通化できるものがされ
ていないとか。
テストのステップが多くなると、値が大きく
なって当然。
コンポーネントテストでBDDするとだいたい4
行から10行くらい（Spockで)
統合テストでだいたい12行から30行くらい
(kyon_mmフレームワークで)

10. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

11. Item
テスト規模/バグ数
(例えば)何日かければバグ1件見つけられる
か。
個人的には、特定期間で見るよりも最終的な
指標として使う事が多い。
考えられる全てのテストをやったが、本当に
大丈夫？みたいな感じ。
1から3くらいならokな感覚が多い。（ただ
し、戦略依存した値）

12. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

13. Item
リリースバグ数/全バグ数(リリースバグ+開発中
発見バグ)数
低ければ低いほどいい。
バグの重要度別に出す方が効果的。
目標は0.002くらい。

14. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

15. Item
テストスイートサイクルタイム
統合テストレベルのテストケースをある固ま
りでまとめて、どれくらいの時間でグリーン
にできるか。
この値が大きすぎるときは進捗報告し辛いの
で、テスト設計し直すか、テスト実装がクソ
か、バグがありまくるか。
2日以下くらいがいい。

16. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

17. Item
(UnitTestの)TDDサイクルタイム
TDDの1サイクルをまわす時間。
600秒超えてると僕の精神が持たない。
20秒から180秒くらいが目安。

18. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

19. Item
計画的テストケース数/アドホック的テストケー
ス数
事前に設計したテストケース数と、テストし
ながら思いついて実行したテストケース数。
自動生成するかとか、プログラマーがどれく
らい対象を知っているかでよく変わる。
10以上だと無理難題か、ハイスキルか、テス
ト知らないか。
3から5くらいがやりやすい。

20. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

21. Item
バグタイプ
Verification系、Validation系のバランスを
大切にする。
バグ原因、バグ混入時期を満遍なく想定して
みて、バグの偏りにあたりをつける。
目安とかない。バイザーのバグ分類とか読む
と楽しい。

22. Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ

23. Test Retrospective
テスト戦略基準な振り返りに使えそうな値をあ
げてみました。
テストケースレベルでの振り返りは非常に難し
いです。
正直有効なものがよくわかりません。
テストケースレベルの妥当性判断はFault
Injection, Mutation TestやTest Suite
Reductionの話になると思います。

24. ご清聴ありがとぴょん◆