Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test Retrospective #kyon_kao_wedding in Tokyo

1,972 views

Published on

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

Published in: Software
  • Be the first to comment

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. ご清聴ありがとぴょん◆

×