アジャイルなテストの見積もりと計画作り
•
13 gostaram•3,416 visualizações
JaSST 12 Tokaiでの発表資料です。予稿集から50ページほど増加しました。 解説を後日、d.hatena.ne.jp/kyon_mmにて投稿します。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (12)
Semelhante a アジャイルなテストの見積もりと計画作り
Semelhante a アジャイルなテストの見積もりと計画作り (20)
Mais de kyon mm
Mais de kyon mm (20)
Último
Último (11)
アジャイルなテストの見積もりと計画作り
- 1. アジャイルなテストの 見積もりと計画づくり JaSST 12 Tokai 2012.11.30 presented by きょん(@kyon_mm)
- 2. 自己紹介 なまえ : きょん@kyon_mm 対象 : 開発環境改善 Groovy, SCM, Test, Agile, CD, かんs 関数/証明プログラミング Study SCMBootCamp,Nagoya.Testing, CDStudy, Cafe.Testing, TDDBootCamp Cafe.Testing
- 3. 勉強会広告だよっ！
- 4. 2012/12/8
- 5. NGK
- 9. 昼 -> 活動紹介LT 夜 -> 飲み会
- 12. みんなきてねっ＞ω＜
- 13. 本題に戻るよ！
- 15. What’s Agile? アジャイルはソフトウェア開発 スタイルであってプロセスではない! アジャイルの基礎は「アジャイル宣言」と 「アジャイルの12の原則」 Haskellが関数プログラミングスタイルの1つ の実装であるように、 XP, Scrum, Lean ,etc はアジャイルの実装の 1つである。
- 18. PO つくりたいもの Test Dev
- 19. PO つくりたいもの 品質 モデル Test Dev
- 20. PO 品質モデル Test Dev
- 21. PO つくりたいもの + 品質モデル 設計 Test Dev
- 22. PO 設計 品質モデル Test Dev
- 23. PO つくりたいもの + 品質モデル + 設計 + etc... Test Dev
- 24. PO 要求 つくりたいもの +全体の戦略 品質モデル + 設計 プロダクト + etc... アーキテクチャ Test テスト Dev アーキテクチャ
- 25. PO つくりたいもの + 全体の戦略 Test Dev
- 26. PO つくりたいもの + 全体の戦略 テスト 開発 Test Dev
- 27. PO テスト プロダクト つくりたいもの 設計実装 設計実装 + 全体の戦略 Test Dev
- 28. PO つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバック Test Dev
- 29. PO つくりたいもの +顧客の要望 全体の戦略 + 実現したもの +戦略へのフィードバック Test Dev
- 30. PO 方針とフィードバックをどれくらい早く 共有するか つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバック テスト 開発 Test Dev
- 38. Test Level 自動化範囲はプロ ジェクト毎に違う コミットステージ：ユニット ストーリー受け入れ：ハッピーパス 結合：テストエンジニアによるテスト
- 39. Quality Model ISO9126(品質特性) + 経験 FCM(Walters & McCallのモデル)
- 42. そこで経験をだな
- 49. Effective by share テストの優先順位の意識付け どの品質を対象にしているかの意識付 け まずは、マインドマップ + ISO9126で 議論をスタートするチームが増えた。
- 51. Estimation
- 53. テスト観点 = 何かを実証するアプローチのこと と定義します。
- 54. テスト観点毎にテストするとやり やすいかもしれない。。。 という直感。
- 55. そこで、テスト観点を列挙！
- 56. あるプロジェクトで テスト観点を列挙すると150個以 上になった。。。
- 57. あるプロジェクトで テスト観点を列挙すると150個以 上になった。。。 僕には見積もれないよ。。。
- 58. そこで
- 59. 相対見積もりですよ
- 60. Relative Estimation テスト観点を相対的に見積もる 例) プロパティファイルの変更 : 5 points クライアントツールのインストール : 8 points
- 61. テストの相対見積もりに挑戦！
- 63. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう？
- 64. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう？ 規模？ 複雑さ？ 時間？ 他のもの？
- 66. Definition of Test Point テストポイント = テストに関わりそうなパラメータ数 テスト実施の難易度 どれくらい組み合わせるか
- 67. Examples of Test Point パラ 実施 組合せ TP メータ 難易度 言語を 跨ぐ 5 1 3 15 コード DB基本 3 3 2 18 操作 インス 3 10 2 60 トール
- 68. これを全てのテスト Examples of Test Point 観点に適用する！ パラ 実施 組合せ TP メータ 難易度 言語を 跨ぐ 5 1 3 15 コード DB基本 3 3 2 18 操作 インス 3 10 2 60 トール
- 69. テスト観点を列挙すると150個以 上になった。。。
- 71. 理想日での見積もりは？
- 74. Flowの一例 テストアーキテクチャ構築 テストポイント見積もり テスト観点の集合をつくる。 テスト戦略策定 次のような事をすることが多かった。 ・品質モデルの共有などを通してテスト目的をつくる 1日だけうすくひろくテストを実施する ・テスト対象をつくる テストポイントの再見積もり テスト戦略再策定 ・テスト観点をつくる テスト実施 ・テスト観点のリファクタリングをする ・必要な情報が抜けていないか考える
- 75. Flowの一例 テストアーキテクチャ構築 テストポイント見積もり テスト戦略策定 1日だけうすくひろくテストを実施する テストポイントの再見積もり 先のテストアーキテクチャは不完全で使えないので、 テスト戦略再策定 プロジェクトの息を吹き込む。（なにをいっt リソースや日々の変化、日程などを加味した全体での テスト実施 作戦になるもの。
- 77. Flowの一例 テストアーキテクチャ構築 Team テストポイント見積もり テスト戦略策定 Review 1日だけうすくひろくテストを実施する テストポイントの再見積もり テスト戦略再策定 テスト実施
- 78. Flowの一例 2week テストアーキテクチャ構築 Team テストポイント見積もり テスト戦略策定 Review 1日だけうすくひろくテストを実施する テストポイントの再見積もり テスト戦略再策定 テスト実施
- 80. Test Strategy テスト観点のマトリクス POと相談してどのテスト観点のテスト を実施するか決定 テスト用のKanbanを用意してみた
- 81. Test Board ToDo Doing Test1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
- 82. Test Board 技術的難易度 ToDo Doing Test1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
- 83. Test Board 技術的難易度 ToDo Doing Test1 Test7 Test2 Test8 Test3 Test6 Test5 ビジネス優先度 Test4
- 84. Test Board 技術的難易度 ToDo Doing Test1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
- 85. Test Board パラメータが多いテストは分担しや すそうという予測があったので、 わかりやすくしたかった 技術的難易度 ToDo Doing Test1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
- 86. Ease of divide test ある規模当たりの作業品質 バグ混入率 分担人数
- 87. Ease of divide test ある規模当たりの作業品質 できるだけ右のようなグラフにしたい バグ混入率 バグ混入率 分担人数 分担人数
- 88. Ease of divide test ある規模当たりの作業品質 バグ混入率 バグ混入率 バグ混入率 分担人数 分担人数 分担人数 テストの独立性
- 89. Ease of divide test ある規模当たりの作業品質 様々な要因があるが、 バグ混入率 率 パラメータが多い事によって規模が大きくなるテス バグ混入率 バグ混入率 トはテストを分割しやすい(独立性を保ち易い)ので はないだろうか。という経験則。 分担人数 分担人数 分担人数 テストの独立性
- 90. Test Board パラメータが多いテストは分担しや すそうという予測があったので、 わかりやすくしたかった 技術的難易度 ToDo Doing Test1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
- 91. Test Board 実施順 技術的難易度 ToDo Doing Test1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
- 92. Test Board ToDo Doing Test1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
- 93. Test Board ToDo Doing Test7 Test1 Test2 Test8 Test3 Test6 Test5 Test4
- 94. Test Board ToDo Doing Test7 Test2 Test8 Test3 Test6 Test5 Test4
- 95. Test Board ToDo Doing Test7 Test2 Test8 分担できそうなテストなので、 Test3 チームの誰かに協力を仰いでみて Test6 Test5 もいいかも！ Test4
- 96. Test Board ToDo Doing Test7 Test3 Test8 Test4 Test6 Test5
- 100. 調査的テスト（仮） 探針とは違う？ 見積もりのために実施する1dayのテス トを調査的テストと仮に名前つけた。 できるだけ、満遍なく多くのテスト観 点をテストする。 目的は「テストの見積もり」「プロダ クトの現状調査」「必要そうなスキル の確認」
- 102. Velocity 1st Sprint -> 1500p / 1week 2nd Sprint -> 2000p / 1week 3rd Sprint -> 1800p / 1week
- 104. 見積り可能なテスト 見積もり可能なテストはテスティング を導いてくれる。 見積もれないテストはテスティングが 行き当たりばったりになる。 行き当たりばったりになったら、 見積もりが不正確な可能性が高かった
- 105. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ
- 106. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ 一部だけだけど こんなイメージ
- 107. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 108. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 109. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintの リスク テスト戦略 テスト戦略 作る事が目的になってると達成しづらく 変更に弱いガラクタになる フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 110. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test3 Test4
- 111. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
- 112. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
- 113. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test2 Test3 Test1 Test3 Test4
- 114. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4
- 115. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4 テストを実装、実施して行く中で、 Test1, Test2, Test3はTestA, TestBとすることで テストの保守性を高くした。
- 116. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4 実装によって発見出来た設計の不味さを修 正し、更によくしてみる テストを実装、実施して行く中で、 Test1, Test2, Test3はTestA, TestBとすることで テストの保守性を高くした。
- 117. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4
- 118. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestD TestE
- 119. Implemented Test Test Architecture Sprint Architecture TestA TestB TestC TestD TestA TestB TestC TestD TestE
- 120. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE バグが見つかった！
- 121. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック！ バグが見つかった！
- 122. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック！ プロセスが鈍重だとやってられなくなっ て、結局やらなくなる。 バグが見つかった！
- 123. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD TestD TestE フィードバック！ 継続してやりたいですね＞＜ バグが見つかった！
- 125. まとめ
- 127. Problem テスト観点ってなに？ テストの見積もりが難しい。。。 認識、管理しやすい 品質ってなに？ 単位の定義を与える 事で、使い易い言葉 テストはどうやって区切るの？ にして、テストに対 する意識を増やした どこまでテストすればいいの？
- 128. Problem テスト観点ってなに？ テストの見積もりが難しい。。。 品質ってなに？ 「相対見積もり」によって テストはどうやって区切るの？ ざっくりとしか出来ない範囲 「調査的テスト + Velocity」によって どこまでテストすればいいの？ 徐々に正確にできる範囲にわけた。
- 129. Problem QualityModelとしてISO9126 + マインドマップを 使ってチームでミーティングする機会を必ずつくる ようにすることで、正しさより気軽に考えられるよ テスト観点ってなに？ うにして意識を向けた テストの見積もりが難しい。。。 品質ってなに？ テストはどうやって区切るの？ どこまでテストすればいいの？
- 130. Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに？ 品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。。 制約ややりやすさで変わる。 品質ってなに？ テストはどうやって区切るの？ どこまでテストすればいいの？
- 131. Problem テスト観点ってなに？ 「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。 範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに？をつける。 テストはどうやって区切るの？ どこまでテストすればいいの？
- 136. ご清聴ありがとうぴょん◆