Test Retrospective #kyon_kao_wedding in Tokyo
Upcoming SlideShare
Loading in...5
×
 

Test Retrospective #kyon_kao_wedding in Tokyo

on

  • 1,128 views

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

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

Statistics

Views

Total Views
1,128
Views on SlideShare
1,095
Embed Views
33

Actions

Likes
2
Downloads
5
Comments
0

2 Embeds 33

https://twitter.com 32
http://localhost 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Test Retrospective #kyon_kao_wedding in Tokyo Test Retrospective #kyon_kao_wedding in Tokyo Presentation Transcript

  • 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の話になると思います。
  • ご清聴ありがとぴょん◆