Disposable Test !!!
ソフトウェアテストの
レトロスペクティブ
2014.03.29 kyon_kao_wedding
自己紹介
きょん(@kyon_mm)
ソフトウェアテストアーキテクト
うさみみ系エンジニア
Groovy, C#, F#, Ruby, Scala
SCMBootCamp, TDDBootCamp, 基礎勉強会,
Nagoya.Testing,...
Test Retrospective
テストの振り返りってしていますか?
テストがどれくらい意味のあるものだったか?
Test Retrospective
in SGT
3/50
=> 6%
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグタイプ
Case A Sprint1
テストコード行数/テスト件数 : 1200/30=40.0
テスト規模/バグ数 : 5day/1=5
リリースバグ数/全バグ数 : ?
テストスイートサイクルタイム : 2day
TDDサイクルタイム : 2min...
Case A Sprint4
テストコード行数/テスト件数 : 4000/250=16
テスト規模/バグ数 : 5day/5=1
リリースバグ数/全バグ数 : 2/(30+2)=0.06
テストスイートサイクルタイム : 2day
TDDサイク...
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
テストコード行数/テスト件数
1件あたりのテストコード行数が多いというの
は、再利用性が低いコードになっている可能
性が高い。4Phaseで共通化できるものがされ
ていないとか。
テストのステップが多くなると、値が大きく
なって当然。...
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
テスト規模/バグ数
(例えば)何日かければバグ1件見つけられる
か。
個人的には、特定期間で見るよりも最終的な
指標として使う事が多い。
考えられる全てのテストをやったが、本当に
大丈夫?みたいな感じ。
1から3くらいならokな感覚が...
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
リリースバグ数/全バグ数(リリースバグ+開発中
発見バグ)数
低ければ低いほどいい。
バグの重要度別に出す方が効果的。
目標は0.002くらい。
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
テストスイートサイクルタイム
統合テストレベルのテストケースをある固ま
りでまとめて、どれくらいの時間でグリーン
にできるか。
この値が大きすぎるときは進捗報告し辛いの
で、テスト設計し直すか、テスト実装がクソ
か、バグがありまくるか...
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
(UnitTestの)TDDサイクルタイム
TDDの1サイクルをまわす時間。
600秒超えてると僕の精神が持たない。
20秒から180秒くらいが目安。
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
計画的テストケース数/アドホック的テストケー
ス数
事前に設計したテストケース数と、テストし
ながら思いついて実行したテストケース数。
自動生成するかとか、プログラマーがどれく
らい対象を知っているかでよく変わる。
10以上だと無理難...
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Item
バグタイプ
Verification系、Validation系のバランスを
大切にする。
バグ原因、バグ混入時期を満遍なく想定して
みて、バグの偏りにあたりをつける。
目安とかない。バイザーのバグ分類とか読む
と楽しい。
Item
テストコード行数/テスト件数
テスト規模/バグ数
リリースバグ数/全バグ数
テストスイートサイクルタイム
TDDサイクルタイム
計画的テストケース数/アドホック的テストケー
ス数
バグ発見サイクルタイム
バグタイプ
Test Retrospective
テスト戦略基準な振り返りに使えそうな値をあ
げてみました。
テストケースレベルでの振り返りは非常に難し
いです。
正直有効なものがよくわかりません。
テストケースレベルの妥当性判断はFault
Inject...
ご清聴ありがとぴょん◆
Upcoming SlideShare
Loading in …5
×

Test Retrospective #kyon_kao_wedding in Tokyo

1,651 views
1,567 views

Published on

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

Published in: Software
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,651
On SlideShare
0
From Embeds
0
Number of Embeds
100
Actions
Shares
0
Downloads
9
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Test Retrospective #kyon_kao_wedding in Tokyo

  1. 1. Disposable Test !!! ソフトウェアテストの レトロスペクティブ 2014.03.29 kyon_kao_wedding
  2. 2. 自己紹介 きょん(@kyon_mm) ソフトウェアテストアーキテクト うさみみ系エンジニア Groovy, C#, F#, Ruby, Scala SCMBootCamp, TDDBootCamp, 基礎勉強会, Nagoya.Testing, Cafe.Testing, STAR, TDDeXchange
  3. 3. Test Retrospective テストの振り返りってしていますか? テストがどれくらい意味のあるものだったか?
  4. 4. Test Retrospective in SGT 3/50 => 6%
  5. 5. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグタイプ
  6. 6. Case A Sprint1 テストコード行数/テスト件数 : 1200/30=40.0 テスト規模/バグ数 : 5day/1=5 リリースバグ数/全バグ数 : ? テストスイートサイクルタイム : 2day TDDサイクルタイム : 2min 計画的テストケース数/アドホック的テストケー ス数 : 40/5=8 バグタイプ : 単純な境界値
  7. 7. Case A Sprint4 テストコード行数/テスト件数 : 4000/250=16 テスト規模/バグ数 : 5day/5=1 リリースバグ数/全バグ数 : 2/(30+2)=0.06 テストスイートサイクルタイム : 2day TDDサイクルタイム : 2min 計画的テストケース数/アドホック的テストケー ス数 : 250/80=3.125 バグタイプ : シナリオ考慮漏れ、復帰処理漏れ
  8. 8. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  9. 9. Item テストコード行数/テスト件数 1件あたりのテストコード行数が多いというの は、再利用性が低いコードになっている可能 性が高い。4Phaseで共通化できるものがされ ていないとか。 テストのステップが多くなると、値が大きく なって当然。 コンポーネントテストでBDDするとだいたい4 行から10行くらい(Spockで) 統合テストでだいたい12行から30行くらい (kyon_mmフレームワークで)
  10. 10. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  11. 11. Item テスト規模/バグ数 (例えば)何日かければバグ1件見つけられる か。 個人的には、特定期間で見るよりも最終的な 指標として使う事が多い。 考えられる全てのテストをやったが、本当に 大丈夫?みたいな感じ。 1から3くらいならokな感覚が多い。(ただ し、戦略依存した値)
  12. 12. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  13. 13. Item リリースバグ数/全バグ数(リリースバグ+開発中 発見バグ)数 低ければ低いほどいい。 バグの重要度別に出す方が効果的。 目標は0.002くらい。
  14. 14. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  15. 15. Item テストスイートサイクルタイム 統合テストレベルのテストケースをある固ま りでまとめて、どれくらいの時間でグリーン にできるか。 この値が大きすぎるときは進捗報告し辛いの で、テスト設計し直すか、テスト実装がクソ か、バグがありまくるか。 2日以下くらいがいい。
  16. 16. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  17. 17. Item (UnitTestの)TDDサイクルタイム TDDの1サイクルをまわす時間。 600秒超えてると僕の精神が持たない。 20秒から180秒くらいが目安。
  18. 18. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  19. 19. Item 計画的テストケース数/アドホック的テストケー ス数 事前に設計したテストケース数と、テストし ながら思いついて実行したテストケース数。 自動生成するかとか、プログラマーがどれく らい対象を知っているかでよく変わる。 10以上だと無理難題か、ハイスキルか、テス ト知らないか。 3から5くらいがやりやすい。
  20. 20. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  21. 21. Item バグタイプ Verification系、Validation系のバランスを 大切にする。 バグ原因、バグ混入時期を満遍なく想定して みて、バグの偏りにあたりをつける。 目安とかない。バイザーのバグ分類とか読む と楽しい。
  22. 22. Item テストコード行数/テスト件数 テスト規模/バグ数 リリースバグ数/全バグ数 テストスイートサイクルタイム TDDサイクルタイム 計画的テストケース数/アドホック的テストケー ス数 バグ発見サイクルタイム バグタイプ
  23. 23. Test Retrospective テスト戦略基準な振り返りに使えそうな値をあ げてみました。 テストケースレベルでの振り返りは非常に難し いです。 正直有効なものがよくわかりません。 テストケースレベルの妥当性判断はFault Injection, Mutation TestやTest Suite Reductionの話になると思います。
  24. 24. ご清聴ありがとぴょん◆

×