アジャイルなテストの見積もりと計画づくり                  JaSST 12 Tokai                     2012.11.30    presented by きょん(@kyon_mm)
自己紹介なまえ : きょん@kyon_mm対象 :開発環境改善Groovy, SCM, Test, Agile, CD, かんs関数/証明プログラミングStudySCMBootCamp,Nagoya.Testing,CDStudy, Cafe....
勉強会広告だよっ!
2012/12/8
NGK
Nagoya  GodoKonshinkai
名古屋中のITに興味ある人があつまって忘年会
Google -> NGK2012B
昼 -> 活動紹介LT 夜 -> 飲み会
Google -> NGK2012B
みんなきてねっ>ω<
本題に戻るよ!
Attention!これは私の独断と偏見と体験です。所属する組織、コミュニティの意見ではございません。
What’s Agile?アジャイルはソフトウェア開発スタイルであってプロセスではない!アジャイルの基礎は「アジャイル宣言」と「アジャイルの12の原則」Haskellが関数プログラミングスタイルの1つの実装であるように、XP, Scrum, L...
BackGroundテストエンジニア一年生!GUIのないWebアプリでサーバーサイドスマートフォンアプリWeb用のフレームワークライブラリ
Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
PO       つくりたいものTest             Dev
PO             つくりたいもの 品質モデル      Test             Dev
PO       品質モデルTest           Dev
PO       つくりたいもの        + 品質モデル                        設計Test              Dev
PO        設計       品質モデルTest           Dev
PO       つくりたいもの        + 品質モデル           + 設計          + etc...Test                 Dev
PO                     要求       つくりたいもの        +全体の戦略          品質モデル           + 設計        プロダクト          + etc...    アーキテ...
PO       つくりたいもの        + 全体の戦略Test              Dev
PO             つくりたいもの              + 全体の戦略テスト                           開発      Test              Dev
PO    テスト     プロダクト      つくりたいもの   設計実装      設計実装       + 全体の戦略Test           Dev
PO      つくりたいもの       + 全体の戦略      + 実現したもの   +戦略へのフィードバックTest          Dev
PO      つくりたいもの       +顧客の要望         全体の戦略      + 実現したもの   +戦略へのフィードバックTest          Dev
PO  方針とフィードバックをどれくらい早く               共有するか            つくりたいもの             + 全体の戦略            + 実現したもの         +戦略へのフィードバック...
Agendaチームコラボ見積もりまとめ
Team Collaboration
Analyze Requirementフィーチャー技術的アーキテクチャスケジュールチームのリソースクライアントのリソース
Use Tools5W2Hマインドマップフィーチャーボードテスト観点モデル
Shareテストレベル品質モデルテストタイプ技術的リスク市場リスク
Test Levelコミットステージストーリー受け入れ結合
Test Levelコミットステージ:ユニットストーリー受け入れ:ハッピーパス結合:テストエンジニアによるテスト
Test Level   自動化範囲はプロ             ジェクト毎に違うコミットステージ:ユニットストーリー受け入れ:ハッピーパス結合:テストエンジニアによるテスト
Quality ModelISO9126(品質特性) + 経験FCM(Walters & McCallのモデル)
ISO9126わかりやすそう型から入る(TypeじゃなくてFormだよ!
ISO9126ISO9126ベースにどんな品質が必要か考えてみた。結果、それを見ただけではどんなサービスか想像つかないものができあがりやすかった。自分には使いこなせない系。
そこで経験をだな
.NET? Android?経験ありませんでした。
ということで、チームに  聞いてみた
ISO9126 + Team開発者が思う次のような不安点を分類しなおした。仕様が曖昧だけど作らなければいけない部分の漏れテストが困難故に単体でしかテストしていない範囲
ISO9126 + TeamPO(プロダクトオーナー)が思う次のような不安点を分類しなおした。運用時に言われそうな課題について確認出来ていない受け入れ基準
ISO9126 + Team「何ができるのか」と「どう使われるか」が少しずつ鮮明になっていった。これは他の品質モデルを使っても一緒だった。
Risk設計ビューティフル・コードパフォーマンスバグ修正顧客のビジネス影響連携サービス
Effective by shareテストの優先順位の意識付けどの品質を対象にしているかの意識付けまずは、マインドマップ + ISO9126で議論をスタートするチームが増えた。
Agendaチームコラボ見積もりまとめ
Estimation
Use Tools5W2Hマインドマップフィーチャーボードテスト観点モデル
テスト観点 =何かを実証するアプローチのこと    と定義します。
テスト観点毎にテストするとやり やすいかもしれない。。。    という直感。
そこで、テスト観点を列挙!
あるプロジェクトでテスト観点を列挙すると150個以   上になった。。。
あるプロジェクトでテスト観点を列挙すると150個以   上になった。。。 僕には見積もれないよ。。。
そこで
相対見積もりですよ
Relative Estimationテスト観点を相対的に見積もる例)プロパティファイルの変更 : 5 pointsクライアントツールのインストール : 8 points
テストの相対見積もりに挑戦!
やってみてすぐに悩んでしまう。。。
やってみてすぐに悩んでしまう。。。     何を見積もればいいのだろう?
やってみてすぐに悩んでしまう。。。     何を見積もればいいのだろう?  規模?  複雑さ?  時間?  他のもの?
3つに絞ったテストに関わりそうなパラメータ数テスト実施の難易度どれくらい組み合わせるか
Definition of Test Point    テストポイント =    テストに関わりそうなパラメータ数     テスト実施の難易度     どれくらい組み合わせるか
Examples of Test Point        パラ    実施   組合せ   TP       メータ   難易度言語を 跨ぐ     5     1     3    15コードDB基本    3     3     2   ...
これを全てのテスト Examples of Test Point 観点に適用する!         パラ    実施   組合せ   TP        メータ   難易度 言語を  跨ぐ     5     1     3    15 コード...
テスト観点を列挙すると150個以   上になった。。。
6000テストポイント と変換できた。
理想日での見積もりは?
実施したテストをもとに 理想日を見積もる
Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
Flowの一例   テストアーキテクチャ構築   テストポイント見積もりテスト観点の集合をつくる。   テスト戦略策定次のような事をすることが多かった。・品質モデルの共有などを通してテスト目的をつくる   1日だけうすくひろくテストを実施する・...
Flowの一例    テストアーキテクチャ構築    テストポイント見積もり    テスト戦略策定    1日だけうすくひろくテストを実施する    テストポイントの再見積もり先のテストアーキテクチャは不完全で使えないので、    テスト戦略再...
Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
Flowの一例テストアーキテクチャ構築                Teamテストポイント見積もりテスト戦略策定         Review1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
Flowの一例    2weekテストアーキテクチャ構築                  Teamテストポイント見積もりテスト戦略策定         Review1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定...
Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点のテストを実施するか決定
Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点のテストを実施するか決定     テスト用のKanbanを用意してみた
Test Board            ToDo                  DoingTest1           Test7        Test2           Test8   Test3               ...
Test Board技術的難易度      ToDo                  DoingTest1           Test7        Test2           Test8   Test3               ...
Test Board技術的難易度      ToDo                    DoingTest1           Test7        Test2           Test8   Test3             ...
Test Board技術的難易度      ToDo                    DoingTest1           Test7               印   パラメータ                          ...
Test Board         パラメータが多いテストは分担しや                    すそうという予測があったので、                       わかりやすくしたかった技術的難易度      ToDo  ...
Ease of divide test           ある規模当たりの作業品質バグ混入率           分担人数
Ease of divide test           ある規模当たりの作業品質        できるだけ右のようなグラフにしたいバグ混入率                     バグ混入率           分担人数         ...
Ease of divide test               ある規模当たりの作業品質バグ混入率                 バグ混入率                                バグ混入率        分担人数...
Ease of divide test         ある規模当たりの作業品質           様々な要因があるが、バグ混入率 率    パラメータが多い事によって規模が大きくなるテス                 バグ混入率     ...
Test Board         パラメータが多いテストは分担しや                    すそうという予測があったので、                       わかりやすくしたかった技術的難易度      ToDo  ...
Test Board                                実施順技術的難易度      ToDo                      DoingTest1           Test7             ...
Test Board            ToDo                  DoingTest1           Test7        Test2           Test8   Test3               ...
Test Board         ToDo                 Doing            Test7             Test1    Test2           Test8 Test3           ...
Test Board         ToDo                  Doing            Test7             Test2                    Test8 Test3          ...
Test Board         ToDo         Doing            Test7    Test2                   Test8             分担できそうなテストなので、 Test3  ...
Test Board     ToDo                  Doing       Test7              Test3                Test8                          Te...
Test Strategyテスト観点のマトリクスPOと相談してどのテスト観点をテストを実施するか決定
Flowの一例テストアーキテクチャ構築テストポイント見積もりテスト戦略策定1日だけうすくひろくテストを実施するテストポイントの再見積もりテスト戦略再策定テスト実施
調査的テスト(仮)見積もりのために実施する1dayのテストを調査的テストと仮に名前つけた。できるだけ、満遍なく多くのテスト観点をテストする。目的は「テストの見積もり」「プロダクトの現状調査」「必要そうなスキルの確認」
調査的テスト(仮)        探針とは違う?見積もりのために実施する1dayのテストを調査的テストと仮に名前つけた。できるだけ、満遍なく多くのテスト観点をテストする。目的は「テストの見積もり」「プロダクトの現状調査」「必要そうなスキルの確認」
調査的テスト(仮)さらっと言えば、Test Boardを1日で1周することで、何かを掴む。
Velocity1st Sprint -> 1500p / 1week2nd Sprint -> 2000p / 1week3rd Sprint -> 1800p / 1week
見積り可能なテスト見積もり可能なテストはテスティングを導いてくれる。見積もれないテストはテスティングが行き当たりばったりになる。
見積り可能なテスト見積もり可能なテストはテスティングを導いてくれる。見積もれないテストはテスティングが行き当たりばったりになる。   行き当たりばったりになったら、  見積もりが不正確な可能性が高かった
依存関係      品質モデル               全体の      Sprintのリスク           テスト戦略    テスト戦略      フィーチャ
依存関係      品質モデル               全体の      Sprintのリスク           テスト戦略    テスト戦略      フィーチャ                一部だけだけど              ...
依存関係      品質モデル               全体の      Sprintのリスク           テスト戦略    テスト戦略      フィーチャ                それぞれがいつでも            ...
依存関係      品質モデル       より軽く                  より早く                  より観測しやすく               全体の      Sprintのリスク           テスト...
依存関係    品質モデル       より軽く                より早く                より観測しやすく           全体の     Sprintのリスク       テスト戦略   テスト戦略  作る事...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2     Test3         Test4
Implemented TestTest Architecture     Sprint                                 Architecture Test1   Test2      Test1     Tes...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2                 Test1 ...
Implemented TestTest Architecture    Sprint                                    Architecture Test1   Test2      Test2 Test3...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2                 TestA ...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2                 TestA ...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2                 TestA ...
Implemented TestTest Architecture   Sprint                               Architecture Test1   Test2                 TestA ...
Implemented TestTest Architecture   Sprint                               Architecture TestA TestB                   TestA ...
Implemented TestTest Architecture    Sprint                                    Architecture TestA TestB        TestC TestD...
Implemented TestTest Architecture   Sprint                               Architecture TestA TestB                   TestA ...
Implemented TestTest Architecture    Sprint                                Architecture TestA TestB                    Tes...
Implemented TestTest Architecture   Sprint                               Architecture TestA TestB                   TestA ...
Implemented TestTest Architecture   Sprint                               Architecture TestA TestB                   TestA ...
Agendaチームコラボ見積もりまとめ
まとめ
Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
Problemテスト観点ってなに?テストの見積もりが難しい。。。           認識、管理しやすい品質ってなに?    単位の定義を与える           事で、使い易い言葉テストはどうやって区切るの?           にして、テ...
Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?    「相対見積もり」によってテストはどうやって区切るの?   ざっくりとしか出来ない範囲「調査的テスト + Velocity」によってどこまでテストすればいいの?...
Problem QualityModelとしてISO9126 + マインドマップを使ってチームでミーティングする機会を必ずつくるようにすることで、正しさより気軽に考えられるよ      テスト観点ってなに?             うにして意識...
Problem テスト観点、フィーチャ単位などを実施した。    実際にはなにを知りたいか次第。   テスト観点ってなに?品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。   テストの見積もりが難しい。。...
Problem    テスト観点ってなに?「リリースのDone」はテストするときではなく、最   初に共有しておき徐々に修正していく。    テストの見積もりが難しい。。。範囲や組合せを考えるが、基本的には常に優先順位    品質ってなに?をつ...
続けたいこと品質モデルの共有チームのレビュー相対見積もりの活用
課題複数のテストエンジニアが関わったときにうまく共有できない。(TestBoardなどはまだチームで常に共有できるほど完成度が高くない
出来そうなことテスト観点のネスト構造について実践してみる。(テストバスケット?テスト観点のリファクタリングや設計パターンの構築
気付いた事Flowの最初につくるテストアーキテクチャは自分が思った以上に作り込む必要がない今回の例だとテスト観点モデルは徐々に成長させることになる。独立性と合成性が高いテスト観点を考える事が重要。
ご清聴ありがとうぴょん◆
アジャイルなテストの見積もりと計画作り
Upcoming SlideShare
Loading in …5
×

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

4,904 views

Published on

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

Published in: Technology

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

  1. 1. アジャイルなテストの見積もりと計画づくり JaSST 12 Tokai 2012.11.30 presented by きょん(@kyon_mm)
  2. 2. 自己紹介なまえ : きょん@kyon_mm対象 :開発環境改善Groovy, SCM, Test, Agile, CD, かんs関数/証明プログラミングStudySCMBootCamp,Nagoya.Testing,CDStudy, Cafe.Testing, TDDBootCampCafe.Testing
  3. 3. 勉強会広告だよっ!
  4. 4. 2012/12/8
  5. 5. NGK
  6. 6. Nagoya GodoKonshinkai
  7. 7. 名古屋中のITに興味ある人があつまって忘年会
  8. 8. Google -> NGK2012B
  9. 9. 昼 -> 活動紹介LT 夜 -> 飲み会
  10. 10. Google -> NGK2012B
  11. 11. みんなきてねっ>ω<
  12. 12. 本題に戻るよ!
  13. 13. Attention!これは私の独断と偏見と体験です。所属する組織、コミュニティの意見ではございません。
  14. 14. What’s Agile?アジャイルはソフトウェア開発スタイルであってプロセスではない!アジャイルの基礎は「アジャイル宣言」と「アジャイルの12の原則」Haskellが関数プログラミングスタイルの1つの実装であるように、XP, Scrum, Lean ,etc はアジャイルの実装の1つである。
  15. 15. BackGroundテストエンジニア一年生!GUIのないWebアプリでサーバーサイドスマートフォンアプリWeb用のフレームワークライブラリ
  16. 16. Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
  17. 17. PO つくりたいものTest Dev
  18. 18. PO つくりたいもの 品質モデル Test Dev
  19. 19. PO 品質モデルTest Dev
  20. 20. PO つくりたいもの + 品質モデル 設計Test Dev
  21. 21. PO 設計 品質モデルTest Dev
  22. 22. PO つくりたいもの + 品質モデル + 設計 + etc...Test Dev
  23. 23. PO 要求 つくりたいもの +全体の戦略 品質モデル + 設計 プロダクト + etc... アーキテクチャ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. PO 方針とフィードバックをどれくらい早く 共有するか つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバックテスト 開発 Test Dev
  30. 30. Agendaチームコラボ見積もりまとめ
  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. Problem QualityModelとしてISO9126 + マインドマップを使ってチームでミーティングする機会を必ずつくるようにすることで、正しさより気軽に考えられるよ テスト観点ってなに? うにして意識を向けた テストの見積もりが難しい。。。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  129. 129. Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに?品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。。 制約ややりやすさで変わる。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  130. 130. Problem テスト観点ってなに?「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに?をつける。 テストはどうやって区切るの? どこまでテストすればいいの?
  131. 131. 続けたいこと品質モデルの共有チームのレビュー相対見積もりの活用
  132. 132. 課題複数のテストエンジニアが関わったときにうまく共有できない。(TestBoardなどはまだチームで常に共有できるほど完成度が高くない
  133. 133. 出来そうなことテスト観点のネスト構造について実践してみる。(テストバスケット?テスト観点のリファクタリングや設計パターンの構築
  134. 134. 気付いた事Flowの最初につくるテストアーキテクチャは自分が思った以上に作り込む必要がない今回の例だとテスト観点モデルは徐々に成長させることになる。独立性と合成性が高いテスト観点を考える事が重要。
  135. 135. ご清聴ありがとうぴょん◆

×