アジャイルなテストの見積もりと計画づくり Nagoya.Testing in Tokyo3 2013.03.10 presented by きょん(@kyon_mm)
自己紹介なまえ : きょん@kyon_mm対象 :開発環境改善Groovy, SCM, Test, Agile, CD, かんs関数/証明プログラミングStudySCMBootCamp,Nagoya.Testing,CDStudy, Cafe....
Sponsor
Sponsor今回の勉強会開催にあたって@kyon_mmを支援してくださっている企業さんの広告になります。
PhantomType名古屋のソフトウェア企業http://www.phantomtype.com
PhantomTypeファントムタイプ社の目指すところは「コミュニティ活動のバイタリティを支援する」ことです。
PhantomTypeコミュニティ活動とは例えば「⃝⃝Boot Campを主催する」だとか「××言語スタートアップを主催する」とかそういうのです。特に技術的な面にこだわっているわけではありません。
PhantomTypeファントムタイプ社がやりたいのはコミュニティを主催したい人たちの交通費、宿泊費、開催場所とか諸々の支援です。
Attention!これは私の独断と偏見と体験です。所属する組織、コミュニティの意見ではございません。
BackGroundテストエンジニア一年生(当時)!GUIのないWebアプリでサーバーサイドスマートフォンアプリWeb用のフレームワークライブラリ
Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
AgendaSoftwareTest ProcessAgileAgile Testing
SoftwareTest Processhttp://goo.gl/alX5c
AgendaSoftwareTest ProcessAgileAgile Testing
Agileアジャイルはソフトウェア開発スタイルであってプロセスではない!アジャイルの基礎は「アジャイル宣言」と「アジャイルの12の原則」Haskellが関数プログラミングスタイルの1つの実装であるように、XP, Scrum, Lean ,etc...
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 方針とフィードバックをどれくらい早く 共有するか つくりたいもの + 全体の戦略 + 実現したもの +戦略へのフィードバック...
AgendaSoftwareTest ProcessAgileAgile Testing
Agile Testingチームコラボ見積もりまとめ
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」によってどこまでテストすればいいの?...
ProblemQualityModelとしてISO9126 + マインドマップを使ってチームでミーティングする機会を必ずつくるようにすることで、正しさより気軽に考えられるよう テスト観点ってなに? にして意識を...
Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに?品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。...
Problem テスト観点ってなに?「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに?をつ...
続けたいこと品質モデルの共有チームのレビュー相対見積もりの活用
課題複数のテストエンジニアが関わったときにうまく共有できない。(TestBoardなどはまだチームで常に共有できるほど完成度が高くない
出来そうなことテスト観点のネスト構造について実践してみる。(テストバスケット?テスト観点のリファクタリングや設計パターンの構築
気付いた事Flowの最初につくるテストアーキテクチャは自分が思った以上に作り込む必要がない今回の例だとテスト観点モデルは徐々に成長させることになる。独立性と合成性が高いテスト観点を考える事が重要。
ご清聴ありがとうぴょん◆
of 135

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

Published on: Mar 3, 2016
Published in: Technology      
Source: www.slideshare.net


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

  • 1. アジャイルなテストの見積もりと計画づくり Nagoya.Testing in Tokyo3 2013.03.10 presented by きょん(@kyon_mm)
  • 2. 自己紹介なまえ : きょん@kyon_mm対象 :開発環境改善Groovy, SCM, Test, Agile, CD, かんs関数/証明プログラミングStudySCMBootCamp,Nagoya.Testing,CDStudy, Cafe.Testing, TDDBootCampCafe.Testing
  • 3. Sponsor
  • 4. Sponsor今回の勉強会開催にあたって@kyon_mmを支援してくださっている企業さんの広告になります。
  • 5. PhantomType名古屋のソフトウェア企業http://www.phantomtype.com
  • 6. PhantomTypeファントムタイプ社の目指すところは「コミュニティ活動のバイタリティを支援する」ことです。
  • 7. PhantomTypeコミュニティ活動とは例えば「⃝⃝Boot Campを主催する」だとか「××言語スタートアップを主催する」とかそういうのです。特に技術的な面にこだわっているわけではありません。
  • 8. PhantomTypeファントムタイプ社がやりたいのはコミュニティを主催したい人たちの交通費、宿泊費、開催場所とか諸々の支援です。
  • 9. Attention!これは私の独断と偏見と体験です。所属する組織、コミュニティの意見ではございません。
  • 10. BackGroundテストエンジニア一年生(当時)!GUIのないWebアプリでサーバーサイドスマートフォンアプリWeb用のフレームワークライブラリ
  • 11. Problemテスト観点ってなに?テストの見積もりが難しい。。。品質ってなに?テストはどうやって区切るの?どこまでテストすればいいの?
  • 12. AgendaSoftwareTest ProcessAgileAgile Testing
  • 13. SoftwareTest Processhttp://goo.gl/alX5c
  • 14. AgendaSoftwareTest ProcessAgileAgile Testing
  • 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
  • 29. AgendaSoftwareTest ProcessAgileAgile Testing
  • 30. Agile Testingチームコラボ見積もりまとめ
  • 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. ProblemQualityModelとしてISO9126 + マインドマップを使ってチームでミーティングする機会を必ずつくるようにすることで、正しさより気軽に考えられるよう テスト観点ってなに? にして意識を向けた テストの見積もりが難しい。。。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  • 129. Problem テスト観点、フィーチャ単位などを実施した。 実際にはなにを知りたいか次第。 テスト観点ってなに?品質に直結するなら品質モデルベースで区切る。 開発と同じ単位で知りたいなら開発対象単位。 テストの見積もりが難しい。。。 制約ややりやすさで変わる。 品質ってなに? テストはどうやって区切るの? どこまでテストすればいいの?
  • 130. Problem テスト観点ってなに?「リリースのDone」はテストするときではなく、最 初に共有しておき徐々に修正していく。 テストの見積もりが難しい。。。範囲や組合せを考えるが、基本的には常に優先順位 品質ってなに?をつける。 テストはどうやって区切るの? どこまでテストすればいいの?
  • 131. 続けたいこと品質モデルの共有チームのレビュー相対見積もりの活用
  • 132. 課題複数のテストエンジニアが関わったときにうまく共有できない。(TestBoardなどはまだチームで常に共有できるほど完成度が高くない
  • 133. 出来そうなことテスト観点のネスト構造について実践してみる。(テストバスケット?テスト観点のリファクタリングや設計パターンの構築
  • 134. 気付いた事Flowの最初につくるテストアーキテクチャは自分が思った以上に作り込む必要がない今回の例だとテスト観点モデルは徐々に成長させることになる。独立性と合成性が高いテスト観点を考える事が重要。
  • 135. ご清聴ありがとうぴょん◆

Related Documents