アジャイルなテストの見積もりと計画作り

  • 3,697 views
Uploaded on

JaSST 12 Tokaiでの発表資料です。予稿集から50ページほど増加しました。 …

JaSST 12 Tokaiでの発表資料です。予稿集から50ページほど増加しました。
解説を後日、d.hatena.ne.jp/kyon_mmにて投稿します。

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,697
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
39
Comments
0
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. アジャイルなテストの見積もりと計画づくり JaSST 12 Tokai 2012.11.30 presented by きょん(@kyon_mm)
  • 2. 自己紹介なまえ : きょん@kyon_mm対象 :開発環境改善Groovy, SCM, Test, Agile, CD, かんs関数/証明プログラミングStudySCMBootCamp,Nagoya.Testing,CDStudy, Cafe.Testing, TDDBootCampCafe.Testing
  • 3. 勉強会広告だよっ!
  • 4. 2012/12/8
  • 5. NGK
  • 6. Nagoya GodoKonshinkai
  • 7. 名古屋中のITに興味ある人があつまって忘年会
  • 8. Google -> NGK2012B
  • 9. 昼 -> 活動紹介LT 夜 -> 飲み会
  • 10. Google -> NGK2012B
  • 11. みんなきてねっ>ω<
  • 12. 本題に戻るよ!
  • 13. Attention!これは私の独断と偏見と体験です。所属する組織、コミュニティの意見ではございません。
  • 14. What’s Agile?アジャイルはソフトウェア開発スタイルであってプロセスではない!アジャイルの基礎は「アジャイル宣言」と「アジャイルの12の原則」Haskellが関数プログラミングスタイルの1つの実装であるように、XP, Scrum, Lean ,etc はアジャイルの実装の1つである。
  • 15. BackGroundテストエンジニア一年生!GUIのないWebアプリでサーバーサイドスマートフォンアプリWeb用のフレームワークライブラリ
  • 16. Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
  • 17. PO つくりたいものTest Dev
  • 18. PO つくりたいもの 品質モデル Test Dev
  • 19. PO 品質モデルTest Dev
  • 20. PO つくりたいもの + 品質モデル 設計Test Dev
  • 21. PO 設計 品質モデルTest Dev
  • 22. PO つくりたいもの + 品質モデル + 設計 + etc...Test Dev
  • 23. PO 要求 つくりたいもの +全体の戦略 品質モデル + 設計 プロダクト + etc... アーキテクチャTest テスト Dev アーキテクチャ
  • 24. PO つくりたいもの + 全体の戦略Test Dev
  • 25. PO つくりたいもの + 全体の戦略テスト 開発 Test Dev
  • 26. PO テスト プロダクト つくりたいもの 設計実装 設計実装 + 全体の戦略Test Dev
  • 27. PO つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバックTest Dev
  • 28. PO つくりたいもの +顧客の要望 全体の戦略 + 実現したもの +戦略へのフィードバックTest Dev
  • 29. PO 方針とフィードバックをどれくらい早く 共有するか つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバックテスト 開発 Test Dev
  • 30. Agendaチームコラボ見積もりまとめ
  • 31. Team Collaboration
  • 32. Analyze Requirementフィーチャー技術的アーキテクチャスケジュールチームのリソースクライアントのリソース
  • 33. Use Tools5W2Hマインドマップフィーチャーボードテスト観点モデル
  • 34. Shareテストレベル品質モデルテストタイプ技術的リスク市場リスク
  • 35. Test Levelコミットステージストーリー受け入れ結合
  • 36. Test Levelコミットステージ:ユニットストーリー受け入れ:ハッピーパス結合:テストエンジニアによるテスト
  • 37. Test Level 自動化範囲はプロ ジェクト毎に違うコミットステージ:ユニットストーリー受け入れ:ハッピーパス結合:テストエンジニアによるテスト
  • 38. Quality ModelISO9126(品質特性) + 経験FCM(Walters & McCallのモデル)
  • 39. ISO9126わかりやすそう型から入る(TypeじゃなくてFormだよ!
  • 40. ISO9126ISO9126ベースにどんな品質が必要か考えてみた。結果、それを見ただけではどんなサービスか想像つかないものができあがりやすかった。自分には使いこなせない系。
  • 41. そこで経験をだな
  • 42. .NET? Android?経験ありませんでした。
  • 43. ということで、チームに 聞いてみた
  • 44. ISO9126 + Team開発者が思う次のような不安点を分類しなおした。仕様が曖昧だけど作らなければいけない部分の漏れテストが困難故に単体でしかテストしていない範囲
  • 45. ISO9126 + TeamPO(プロダクトオーナー)が思う次のような不安点を分類しなおした。運用時に言われそうな課題について確認出来ていない受け入れ基準
  • 46. ISO9126 + Team「何ができるのか」と「どう使われるか」が少しずつ鮮明になっていった。これは他の品質モデルを使っても一緒だった。
  • 47. Risk設計ビューティフル・コードパフォーマンスバグ修正顧客のビジネス影響連携サービス
  • 48. Effective by shareテストの優先順位の意識付けどの品質を対象にしているかの意識付けまずは、マインドマップ + ISO9126で議論をスタートするチームが増えた。
  • 49. Agendaチームコラボ見積もりまとめ
  • 50. Estimation
  • 51. Use Tools5W2Hマインドマップフィーチャーボードテスト観点モデル
  • 52. テスト観点 =何かを実証するアプローチのこと と定義します。
  • 53. テスト観点毎にテストするとやり やすいかもしれない。。。 という直感。
  • 54. そこで、テスト観点を列挙!
  • 55. あるプロジェクトでテスト観点を列挙すると150個以 上になった。。。
  • 56. あるプロジェクトでテスト観点を列挙すると150個以 上になった。。。 僕には見積もれないよ。。。
  • 57. そこで
  • 58. 相対見積もりですよ
  • 59. Relative Estimationテスト観点を相対的に見積もる例)プロパティファイルの変更 : 5 pointsクライアントツールのインストール : 8 points
  • 60. テストの相対見積もりに挑戦!
  • 61. やってみてすぐに悩んでしまう。。。
  • 62. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう?
  • 63. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう? 規模? 複雑さ? 時間? 他のもの?
  • 64. 3つに絞ったテストに関わりそうなパラメータ数テスト実施の難易度どれくらい組み合わせるか
  • 65. Definition of Test Point テストポイント = テストに関わりそうなパラメータ数 テスト実施の難易度 どれくらい組み合わせるか
  • 66. Examples of Test Point パラ 実施 組合せ TP メータ 難易度言語を 跨ぐ 5 1 3 15コードDB基本 3 3 2 18 操作インス 3 10 2 60トール
  • 67. これを全てのテスト Examples of Test Point 観点に適用する! パラ 実施 組合せ TP メータ 難易度 言語を 跨ぐ 5 1 3 15 コード DB基本 3 3 2 18 操作 インス 3 10 2 60 トール
  • 68. テスト観点を列挙すると150個以 上になった。。。
  • 69. 6000テストポイント と変換できた。
  • 70. 理想日での見積もりは?
  • 71. 実施したテストをもとに 理想日を見積もる
  • 72. Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
  • 73. Flowの一例 テストアーキテクチャ構築 テストポイント見積もりテスト観点の集合をつくる。 テスト戦略策定次のような事をすることが多かった。・品質モデルの共有などを通してテスト目的をつくる 1日だけうすくひろくテストを実施する・テスト対象をつくる テストポイントの再見積もり テスト戦略再策定・テスト観点をつくる テスト実施・テスト観点のリファクタリングをする・必要な情報が抜けていないか考える
  • 74. Flowの一例 テストアーキテクチャ構築 テストポイント見積もり テスト戦略策定 1日だけうすくひろくテストを実施する テストポイントの再見積もり先のテストアーキテクチャは不完全で使えないので、 テスト戦略再策定プロジェクトの息を吹き込む。(なにをいっtリソースや日々の変化、日程などを加味した全体での テスト実施作戦になるもの。
  • 75. Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
  • 76. Flowの一例テストアーキテクチャ構築 Teamテストポイント見積もりテスト戦略策定 Review1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
  • 77. Flowの一例 2weekテストアーキテクチャ構築 Teamテストポイント見積もりテスト戦略策定 Review1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
  • 78. Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点のテストを実施するか決定
  • 79. Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点のテストを実施するか決定 テスト用のKanbanを用意してみた
  • 80. Test Board ToDo DoingTest1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
  • 81. Test Board技術的難易度 ToDo DoingTest1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
  • 82. Test Board技術的難易度 ToDo DoingTest1 Test7 Test2 Test8 Test3 Test6 Test5 ビジネス優先度 Test4
  • 83. Test Board技術的難易度 ToDo DoingTest1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
  • 84. Test Board パラメータが多いテストは分担しや すそうという予測があったので、 わかりやすくしたかった技術的難易度 ToDo DoingTest1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
  • 85. Ease of divide test ある規模当たりの作業品質バグ混入率 分担人数
  • 86. Ease of divide test ある規模当たりの作業品質 できるだけ右のようなグラフにしたいバグ混入率 バグ混入率 分担人数 分担人数
  • 87. Ease of divide test ある規模当たりの作業品質バグ混入率 バグ混入率 バグ混入率 分担人数 分担人数 分担人数 テストの独立性
  • 88. Ease of divide test ある規模当たりの作業品質 様々な要因があるが、バグ混入率 率 パラメータが多い事によって規模が大きくなるテス バグ混入率 バグ混入率 トはテストを分割しやすい(独立性を保ち易い)ので はないだろうか。という経験則。 分担人数 分担人数 分担人数 テストの独立性
  • 89. Test Board パラメータが多いテストは分担しや すそうという予測があったので、 わかりやすくしたかった技術的難易度 ToDo DoingTest1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
  • 90. Test Board 実施順技術的難易度 ToDo DoingTest1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
  • 91. Test Board ToDo DoingTest1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
  • 92. Test Board ToDo Doing Test7 Test1 Test2 Test8 Test3 Test6 Test5 Test4
  • 93. Test Board ToDo Doing Test7 Test2 Test8 Test3 Test6 Test5 Test4
  • 94. Test Board ToDo Doing Test7 Test2 Test8 分担できそうなテストなので、 Test3 チームの誰かに協力を仰いでみて Test6 Test5 もいいかも! Test4
  • 95. Test Board ToDo Doing Test7 Test3 Test8 Test4 Test6 Test5
  • 96. Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点をテストを実施するか決定
  • 97. Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
  • 98. 調査的テスト(仮)見積もりのために実施する1dayのテストを調査的テストと仮に名前つけた。できるだけ、満遍なく多くのテスト観点をテストする。目的は「テストの見積もり」「プロダクトの現状調査」「必要そうなスキルの確認」
  • 99. 調査的テスト(仮) 探針とは違う?見積もりのために実施する1dayのテストを調査的テストと仮に名前つけた。できるだけ、満遍なく多くのテスト観点をテストする。目的は「テストの見積もり」「プロダクトの現状調査」「必要そうなスキルの確認」
  • 100. 調査的テスト(仮)さらっと言えば、Test Boardを1日で1周することで、何かを掴む。
  • 101. Velocity1st Sprint -> 1500p / 1week2nd Sprint -> 2000p / 1week3rd Sprint -> 1800p / 1week
  • 102. 見積り可能なテスト見積もり可能なテストはテスティングを導いてくれる。見積もれないテストはテスティングが行き当たりばったりになる。
  • 103. 見積り可能なテスト見積もり可能なテストはテスティングを導いてくれる。見積もれないテストはテスティングが行き当たりばったりになる。 行き当たりばったりになったら、 見積もりが不正確な可能性が高かった
  • 104. 依存関係 品質モデル 全体の Sprintのリスク テスト戦略 テスト戦略 フィーチャ
  • 105. 依存関係 品質モデル 全体の Sprintのリスク テスト戦略 テスト戦略 フィーチャ 一部だけだけど こんなイメージ
  • 106. 依存関係 品質モデル 全体の Sprintのリスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
  • 107. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintのリスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
  • 108. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintのリスク テスト戦略 テスト戦略 作る事が目的になってると達成しづらく 変更に弱いガラクタになる フィーチャ それぞれがいつでも 想定と異なる可能性がある
  • 109. Implemented TestTest Architecture Sprint Architecture Test1 Test2 Test3 Test4
  • 110. Implemented TestTest Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
  • 111. Implemented TestTest Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
  • 112. Implemented TestTest Architecture Sprint Architecture Test1 Test2 Test2 Test3 Test1 Test3 Test4
  • 113. Implemented TestTest Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4
  • 114. Implemented TestTest Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4 テストを実装、実施して行く中で、 Test1, Test2, Test3はTestA, TestBとすることで テストの保守性を高くした。
  • 115. Implemented TestTest Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4 実装によって発見出来た設計の不味さを修 正し、更によくしてみる テストを実装、実施して行く中で、 Test1, Test2, Test3はTestA, TestBとすることで テストの保守性を高くした。
  • 116. Implemented TestTest Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4
  • 117. Implemented TestTest Architecture Sprint Architecture TestA TestB TestA TestB TestC TestD TestE
  • 118. Implemented TestTest Architecture Sprint Architecture TestA TestB TestC TestD TestA TestB TestC TestD TestE
  • 119. Implemented TestTest Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE バグが見つかった!
  • 120. Implemented TestTest Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック! バグが見つかった!
  • 121. Implemented TestTest Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック! プロセスが鈍重だとやってられなくなっ て、結局やらなくなる。 バグが見つかった!
  • 122. Implemented TestTest Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック! 継続してやりたいですね>< バグが見つかった!
  • 123. Agendaチームコラボ見積もりまとめ
  • 124. まとめ
  • 125. Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
  • 126. Problemテスト観点ってなに?テストの見積もりが難しい。。。 認識、管理しやすい品質ってなに? 単位の定義を与える 事で、使い易い言葉テストはどうやって区切るの? にして、テストに対 する意識を増やしたどこまでテストすればいいの?
  • 127. Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに? 「相対見積もり」によってテストはどうやって区切るの? ざっくりとしか出来ない範囲「調査的テスト + Velocity」によってどこまでテストすればいいの? 徐々に正確にできる範囲にわけた。
  • 128. Problem QualityModelとしてISO9126 + マインドマップを使ってチームでミーティングする機会を必ずつくるようにすることで、正しさより気軽に考えられるよ テスト観点ってなに? うにして意識を向けた テストの見積もりが難しい。。。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  • 129. Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに?品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。。 制約ややりやすさで変わる。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  • 130. Problem テスト観点ってなに?「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに?をつける。 テストはどうやって区切るの? どこまでテストすればいいの?
  • 131. 続けたいこと品質モデルの共有チームのレビュー相対見積もりの活用
  • 132. 課題複数のテストエンジニアが関わったときにうまく共有できない。(TestBoardなどはまだチームで常に共有できるほど完成度が高くない
  • 133. 出来そうなことテスト観点のネスト構造について実践してみる。(テストバスケット?テスト観点のリファクタリングや設計パターンの構築
  • 134. 気付いた事Flowの最初につくるテストアーキテクチャは自分が思った以上に作り込む必要がない今回の例だとテスト観点モデルは徐々に成長させることになる。独立性と合成性が高いテスト観点を考える事が重要。
  • 135. ご清聴ありがとうぴょん◆