Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (12)
Ähnlich wie #NagoyaTesting アジャイルなテストの見積りと計画づくり
Ähnlich wie #NagoyaTesting アジャイルなテストの見積りと計画づくり (20)
Mehr von kyon mm
Mehr von kyon mm (20)
#NagoyaTesting アジャイルなテストの見積りと計画づくり
- 1. アジャイルなテストの 見積もりと計画づくり Nagoya.Testing in Tokyo3 2013.03.10 presented by きょん(@kyon_mm)
- 2. 自己紹介 なまえ : きょん@kyon_mm 対象 : 開発環境改善 Groovy, SCM, Test, Agile, CD, かんs 関数/証明プログラミング Study SCMBootCamp,Nagoya.Testing, CDStudy, Cafe.Testing, TDDBootCamp Cafe.Testing
- 3. Sponsor
- 15. Agile アジャイルはソフトウェア開発 スタイルであってプロセスではない! アジャイルの基礎は「アジャイル宣言」と 「アジャイルの12の原則」 Haskellが関数プログラミングスタイルの1つ の実装であるように、 XP, Scrum, Lean ,etc はアジャイルの実装の 1つである。
- 16. PO つくりたいもの Test Dev
- 17. PO つくりたいもの 品質 モデル Test Dev
- 18. PO 品質モデル Test Dev
- 19. PO つくりたいもの + 品質モデル 設計 Test Dev
- 20. PO 設計 品質モデル Test Dev
- 21. PO つくりたいもの + 品質モデル + 設計 + etc... Test Dev
- 22. PO 要求 つくりたいもの +全体の戦略 品質モデル + 設計 プロダクト + etc... アーキテクチャ Test テスト Dev アーキテクチャ
- 23. PO つくりたいもの + 全体の戦略 Test Dev
- 24. PO つくりたいもの + 全体の戦略 テスト 開発 Test Dev
- 25. PO テスト プロダクト つくりたいもの 設計実装 設計実装 + 全体の戦略 Test Dev
- 26. PO つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバック Test Dev
- 27. PO つくりたいもの +顧客の要望 全体の戦略 + 実現したもの +戦略へのフィードバック Test Dev
- 28. PO 方針とフィードバックをどれくらい早く 共有するか つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバック テスト 開発 Test Dev
- 37. Test Level 自動化範囲はプロジ ェクト毎に違う コミットステージ：ユニット ストーリー受け入れ：ハッピーパス 結合：テストエンジニアによるテスト
- 38. Quality Model ISO9126(品質特性) + 経験 FCM(Walters & McCallのモデル)
- 41. そこで経験をだな
- 48. Effective by share テストの優先順位の意識付け どの品質を対象にしているかの意識付 け まずは、マインドマップ + ISO9126で 議論をスタートするチームが増えた。
- 50. Estimation
- 52. テスト観点 = 何かを実証するアプローチのこと と定義します。
- 53. テスト観点毎にテストするとやり やすいかもしれない。。。 という直感。
- 54. そこで、テスト観点を列挙！
- 55. あるプロジェクトで テスト観点を列挙すると150個以 上になった。。。
- 56. あるプロジェクトで テスト観点を列挙すると150個以 上になった。。。 僕には見積もれないよ。。。
- 57. そこで
- 58. 相対見積もりですよ
- 59. Relative Estimation テスト観点を相対的に見積もる 例) プロパティファイルの変更 : 5 points クライアントツールのインストール : 8 points
- 60. テストの相対見積もりに挑戦！
- 62. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう？
- 63. やってみてすぐに悩んでしまう。。。 何を見積もればいいのだろう？ 規模？ 複雑さ？ 時間？ 他のもの？
- 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個以 上になった。。。
- 70. 理想日での見積もりは？
- 73. Flowの一例 テストアーキテクチャ構築 テストポイント見積もり テスト観点の集合をつくる。 テスト戦略策定 次のような事をすることが多かった。 ・品質モデルの共有などを通してテスト目的をつくる 1日だけうすくひろくテストを実施する ・テスト対象をつくる テストポイントの再見積もり テスト戦略再策定 ・テスト観点をつくる テスト実施 ・テスト観点のリファクタリングをする ・必要な情報が抜けていないか考える
- 74. Flowの一例 テストアーキテクチャ構築 テストポイント見積もり テスト戦略策定 1日だけうすくひろくテストを実施する テストポイントの再見積もり 先のテストアーキテクチャは不完全で使えないので、 テスト戦略再策定 プロジェクトの息を吹き込む。（なにをいっt リソースや日々の変化、日程などを加味した全体での テスト実施 作戦になるもの。
- 76. Flowの一例 テストアーキテクチャ構築 Team テストポイント見積もり テスト戦略策定 Review 1日だけうすくひろくテストを実施する テストポイントの再見積もり テスト戦略再策定 テスト実施
- 77. Flowの一例 2week テストアーキテクチャ構築 Team テストポイント見積もり テスト戦略策定 Review 1日だけうすくひろくテストを実施する テストポイントの再見積もり テスト戦略再策定 テスト実施
- 79. Test Strategy テスト観点のマトリクス POと相談してどのテスト観点のテスト を実施するか決定 テスト用のKanbanを用意してみた
- 80. Test Board ToDo Doing Test1 Test7 Test2 Test8 Test3 Test6 Test5 Test4
- 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. Ease of divide test ある規模当たりの作業品質 バグ混入率 分担人数
- 86. Ease of divide test ある規模当たりの作業品質 できるだけ右のようなグラフにしたい バグ混入率 バグ混入率 分担人数 分担人数
- 87. Ease of divide test ある規模当たりの作業品質 バグ混入率 バグ混入率 バグ混入率 分担人数 分担人数 分担人数 テストの独立性
- 88. Ease of divide test ある規模当たりの作業品質 様々な要因があるが、 バグ混入率 率 パラメータが多い事によって規模が大きくなるテス バグ混入率 バグ混入率 トはテストを分割しやすい(独立性を保ち易い)ので はないだろうか。という経験則。 分担人数 分担人数 分担人数 テストの独立性
- 89. Test Board パラメータが多いテストは分担しや すそうという予測があったので、 わかりやすくしたかった 技術的難易度 ToDo Doing Test1 Test7 印 パラメータ 無印 普通 Test2 Test8 多め 多い Test3 Test6 Test5 ビジネス優先度 Test4
- 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 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
- 99. 調査的テスト（仮） 探針とは違う？ 見積もりのために実施する1dayのテス トを調査的テストと仮に名前つけた。 できるだけ、満遍なく多くのテスト観 点をテストする。 目的は「テストの見積もり」「プロダ クトの現状調査」「必要そうなスキル の確認」
- 101. Velocity 1st Sprint -> 1500p / 1week 2nd Sprint -> 2000p / 1week 3rd Sprint -> 1800p / 1week
- 103. 見積り可能なテスト 見積もり可能なテストはテスティング を導いてくれる。 見積もれないテストはテスティングが 行き当たりばったりになる。 行き当たりばったりになったら、 見積もりが不正確な可能性が高かった
- 104. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ
- 105. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ 一部だけだけど こんなイメージ
- 106. 依存関係 品質モデル 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 107. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintの リスク テスト戦略 テスト戦略 フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 108. 依存関係 品質モデル より軽く より早く より観測しやすく 全体の Sprintの リスク テスト戦略 テスト戦略 作る事が目的になってると達成しづらく 変更に弱いガラクタになる フィーチャ それぞれがいつでも 想定と異なる可能性がある
- 109. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test3 Test4
- 110. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
- 111. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test1 Test3 Test4
- 112. Implemented Test Test Architecture Sprint Architecture Test1 Test2 Test2 Test3 Test1 Test3 Test4
- 113. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4
- 114. Implemented Test Test Architecture Sprint Architecture Test1 Test2 TestA TestB Test3 Test4 テストを実装、実施して行く中で、 Test1, Test2, Test3はTestA, TestBとすることで テストの保守性を高くした。
- 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
- 117. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestD TestE
- 118. Implemented Test Test Architecture Sprint Architecture TestA TestB TestC TestD TestA TestB TestC TestD TestE
- 119. Implemented Test Test Architecture Sprint Architecture TestA TestB TestA TestB TestC TestC TestD 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 フィードバック！ 継続してやりたいですね＞＜ バグが見つかった！
- 124. まとめ
- 126. Problem テスト観点ってなに？ テストの見積もりが難しい。。。 認識、管理しやすい 品質ってなに？ 単位の定義を与える 事で、使い易い言葉 テストはどうやって区切るの？ にして、テストに対 する意識を増やした どこまでテストすればいいの？
- 127. Problem テスト観点ってなに？ テストの見積もりが難しい。。。 品質ってなに？ 「相対見積もり」によって テストはどうやって区切るの？ ざっくりとしか出来ない範囲 「調査的テスト + Velocity」によって どこまでテストすればいいの？ 徐々に正確にできる範囲にわけた。
- 128. Problem QualityModelとしてISO9126 + マインドマップを使 ってチームでミーティングする機会を必ずつくるよ うにすることで、正しさより気軽に考えられるよう テスト観点ってなに？ にして意識を向けた テストの見積もりが難しい。。。 品質ってなに？ テストはどうやって区切るの？ どこまでテストすればいいの？
- 129. Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに？ 品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。。 制約ややりやすさで変わる。 品質ってなに？ テストはどうやって区切るの？ どこまでテストすればいいの？
- 130. Problem テスト観点ってなに？ 「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。 範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに？をつける。 テストはどうやって区切るの？ どこまでテストすればいいの？
- 135. ご清聴ありがとうぴょん◆