#NagoyaTesting アジャイルなテストの見積りと計画づくり

7,365 views

Published on

Published in: Technology

#NagoyaTesting アジャイルなテストの見積りと計画づくり

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

×