Test Retrospective #kyon_kao_wedding in Tokyo
description
Transcript of Test Retrospective #kyon_kao_wedding in Tokyo
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の話になると思います。
ご清聴ありがとぴょん◆