事例から学ぶ実例マッピングのやり方 / Example Mapping

【発表資料中のURL】
※複数ページで出てくる場合は、初出のページ数に掲載

◆P3
・Introducing Example Mapping
・【翻訳記事+α】受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」

◆P6
・Continuous Testing in DevOps…

◆P7
・Shifting left & right in our continuous world

◆P11
・Ｗモデルとは何か

◆P74
・The BDD Books - Discovery
・The BDD Books - Discovery (Japanese Edition)

◆P75
・Keep your scenarios BRIEF
・【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

◆P82
・QAエンジニアが実例マッピングを2ヶ月運用した話
・miroを使って実例マッピングの一歩目を踏み出すの(仮)
・異世界に転生したら激レア職業のスクラム Developer だったので手始めに Scrum Fest Osaka 2020 でラーニングしたスキルでリファインメント無双してみた

◆P82
・ブロッコリー(@nihonbuson)

Transcript

1. 事例から学ぶ 実例マッピングのやり方 ブロッコリー (@nihonbuson)
2. 実例マッピングとは何か
3. 実例マッピング ルールの理解を明確にする手法 • 赤い付箋（疑問点）だらけ ◦ 学ぶ内容がまだ沢山ある • 青い付箋（ルール）だらけ ◦ ストーリーが大きく複雑 ◦ ストーリーを分割すべき • 1つのルールに多くの緑の付箋 ◦ ルールが複雑すぎる ◦ 複数の青い付箋（ルール）に分割すべき 日本語版: https://nihonbuson.hatenadiary.jp/entry/ExampleMapping https://cucumber.io/blog/bdd/example-mapping-introduction/
4. 実例マッピングの範囲
5. テスト活動っていつやるの？ • 開発の実装が終わったらテスト活動を始める？ • 開発の実装が始まるのと同時にテスト活動を始める？ • 開発の実装前からテスト活動を始める？
6. 継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
7. 継続的テストモデル（改） https://lisacrispin.com/2020/11/01/shifting-left-right-in-our-continuous-world/
8. 継続的テストモデル（改） https://lisacrispin.com/2020/11/01/shifting-left-right-in-our-continuous-world/ テスト 作業の 範囲に なりがち
9. 継続的テストモデル（改） https://lisacrispin.com/2020/11/01/shifting-left-right-in-our-continuous-world/ TDDの 範囲
10. 継続的テストモデル（改） https://lisacrispin.com/2020/11/01/shifting-left-right-in-our-continuous-world/ 実例 マッピング の範囲
11. Vモデルで言うと… http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf を元に作成 実例 マッピング の範囲
12. 実例マッピングでの 登場人物
13. Three Amigos 3つの立場の人が集まり協調的に要件を確認する People vector created by stories - www.freepik.com QA(Tester) 開発者 PO
14. 事例を用いた 実例マッピングの作り方
15. 事例を通じて伝えたいこと • 実例マッピングというプラクティスを使うことが 大切なのではない！ • ストーリーとルールと例と疑問点を分けて会話し、 分かれた状態で記録するという思考が大切！ • 今回は、実例マッピングが作られていく過程となる 会話も併せて紹介する
16. 今回の題材・登場人物 PO QA 人数のグラフを 良い感じに表示する 開発者
17. スケールのルール追加 人数のグラフを 良い感じに表示したい 「良い感じ」が 分からないので 色々質問しますね 縦軸の目盛りは最大値を 基準に良い感じで スケールが変わる 最大値を 基準に スケール 変更 人数のグラフを 良い感じに表示する
18. 1000人の場合 例えば1000人の場合は どうなります？ 人数のグラフを 良い感じに表示する
19. 1000人の場合 目盛りが4本なので、 目盛りは250, 500, 750, 1000ですかね 例えば1000人の場合は どうなります？ 人数のグラフを 良い感じに表示する
20. 具体例の追加 例えば1000人の場合は どうなります？ 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 1000人
21. 具体例の追加 目盛りが4本なので、 目盛りは250, 500, 750, 1000ですかね 例えば1000人の場合は どうなります？ 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 1000人 250,500 750,1000
22. 目盛りのルールの追加 目盛りが4本なので、 目盛りは250, 500, 750, 1000ですかね 例えば1000人の場合は どうなります？ 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000
23. 800人の場合 じゃあ800人だったら？ 人数のグラフを 良い感じに表示する
24. 具体例の追加 人数のグラフを 良い感じに表示する 目盛りが 4本出る 1000人 250,500 750,1000 800人 最大値を 基準に スケール 変更 じゃあ800人だったら？
25. 具体例の追加 人数のグラフを 良い感じに表示する 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 最大値を 基準に スケール 変更 じゃあ800人だったら？ その場合も目盛りは 1000人の場合と 同じです
26. 1500人の場合 人数のグラフを 良い感じに表示する じゃあ1500人でも 同じ？
27. 1500人の場合 人数のグラフを 良い感じに表示する じゃあ1500人でも 同じ？ その場合は 400,800,1200,1600 に調整されますね
28. 1500人の場合 人数のグラフを 良い感じに表示する じゃあ1500人でも 同じ？ 1500人 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000
29. 具体例の追加 人数のグラフを 良い感じに表示する その場合は 400,800,1200,1600 に調整されますね じゃあ1500人でも 同じ？ 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000
30. 目盛りを超えないルールの追加 人数のグラフを 良い感じに表示する 1500人の場合はなぜ 変わるんですかね？ 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000
31. 目盛りを超えないルールの追加 人数のグラフを 良い感じに表示する 上の目盛りが 1000だと グラフが突き抜けて しまうので… 1500人の場合はなぜ 変わるんですかね？ 一番上の 目盛りを 超えない 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000
32. 1050人の場合 そしたら1050人は？ 1000人超えだけど… 人数のグラフを 良い感じに表示する
33. 具体例の追加 人数のグラフを 良い感じに表示する 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… 一番上の 目盛りを 超えない 1050人
34. 具体例の追加 人数のグラフを 良い感じに表示する その場合はグラフが 外にはみ出ないので 目盛りは1000のまま ですね。 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… 1050人 250,500 750,1000 一番上の 目盛りを 超えない
35. ルールの変更 人数のグラフを 良い感じに表示する その場合はグラフが 外にはみ出ないので 目盛りは1000のまま ですね。 一番上の 目盛りを 超えない 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… グラフがエリア外に 出ないことが 重要なんですね。 1050人 250,500 750,1000
36. ルールの変更 人数のグラフを 良い感じに表示する その場合はグラフが 外にはみ出ないので 目盛りは1000のまま ですね。 データが エリア外 に出ない 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… グラフがエリア外に 出ないことが 重要なんですね。 1050人 250,500 750,1000
37. 600人の場合 今度は小さい値を 考えてみます。 600人はどうですか？ 人数のグラフを 良い感じに表示する
38. 具体例の追加 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 今度は小さい値を 考えてみます。 600人はどうですか？
39. 具体例の追加 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 200,400 600,800 250,500,750,1000だと グラフが小さく表示さ れるので、200,400, 600,800ですかね。 今度は小さい値を 考えてみます。 600人はどうですか？
40. 150人の場合 人数のグラフを 良い感じに表示する もっと小さい値 で150人だったら？
41. 具体例の追加 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 200,400 600,800 150人 もっと小さい値 で150人だったら？
42. 具体例の追加 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 200,400 600,800 150人 40,80 120,160 そしたら40,80,120, 160ですかね。 ちょうど良いのは。 もっと小さい値 で150人だったら？
43. ルールの発見 人数のグラフを 良い感じに表示する あー、 確かにそうですね なるほどー。 ここまでの話から 最大値は目盛りの 上から2番目よりは 大きいように調整 するんですかね？
44. ルールの発見 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 200,400 600,800 150人 40,80 120,160 あー、 確かにそうですね なるほどー。 ここまでの話から 最大値は目盛りの 上から2番目よりは 大きいように調整 するんですかね？
45. ルールの発見 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、 確かにそうですね なるほどー。 ここまでの話から 最大値は目盛りの 上から2番目よりは 大きいように調整 するんですかね？
46. 2人の場合 人数のグラフを 良い感じに表示する さらに小さい値を 考えてみます。 2人だと どうなります？
47. 具体例の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 2人 さらに小さい値を 考えてみます。 2人だと どうなります？
48. 具体例の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 4分割で考えると0.5, 1, 1.5, 2ですかね。 2人 0.5,1 1.5,2 さらに小さい値を 考えてみます。 2人だと どうなります？
49. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、それは調整する 必要があるかも。 人数なのに 小数点以下の 目盛りがあるのは 違和感がありますね 2人 0.5,1 1.5,2
50. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、それは調整する 必要があるかも。 人数なのに 小数点以下の 目盛りがあるのは 違和感がありますね 2人 0.5,1 1.5,2 小数点の 目盛りは 表示される？
51. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 価値が無くなる訳では ないので、今回は一旦 そのままにしましょう！ 目盛りの数を状況に よって変えるのは 工数がかかるから 今回はそのままに したい… 2人 0.5,1 1.5,2 小数点の 目盛りは 表示される？
52. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 価値が無くなる訳では ないので、今回は一旦 そのままにしましょう！ 目盛りの数を状況に よって変えるのは 工数がかかるから 今回はそのままに したい… 2人 0.5,1 1.5,2 小数点の目盛り は表示される？ →表示する
53. 0人の場合 人数のグラフを 良い感じに表示する それは自分も どうするか明確に してないですね… あとは、0人だったら どうなります？ 目盛りがどのように 調節されるのか 分からない…
54. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人 40,80 120,160 それは自分も どうするか明確に してないですね… あとは、0人だったら どうなります？ 目盛りがどのように 調節されるのか 分からない… 2人 0.5,1 1.5,2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？
55. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000
56. 実例マッピングの 成果物から分かること
57. 今回の実例マッピングの成果物 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000
58. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000 ここがSpike Taskになる場合も… （調査・決定しない限り、 開発に着手すべきでない）
59. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000 受け入れ条件に使える （これらを実現したことを確認して 案件を「完了」に変える）
60. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2 小数点の目盛り は表示される？ →表示する 最大値が0人 の時に目盛り はどうする？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000 テストケース例に使える ※これが全てではないので注意！
61. 実例マッピングの成果物から見える状況 具体例の付箋が少ない →議論が足りないかも or 実装内容が自明かも
62. 実例マッピングの成果物から見える状況 1つのルールに対して 具体例の付箋が多い →ルールが複雑なので、 複数のシンプルなルールに 分割した方が良いかも
63. 実例マッピングの成果物から見える状況 ルールの付箋が多い →ストーリーが複雑なので もっと小さいストーリーに 分割した方が良いかも
64. 実例マッピングの成果物から見える状況 疑問点の付箋が多い →開発開始する準備 ができていないかも
65. 実例マッピングで 必要なスキル Designed by Rawpixel.com / Freepik
66. 今回の実例マッピングで必要なスキル • 具体例で考えられる ◦ 実際に起こりうる例で考えられる • 抽象化と具体化の行き来ができる ◦ 具体例からルールを導き出す時に必要 ◦ テストのスキルも必要 ▪ 同値分割法 ▪ ハイレベルテストケースと ローレベルテストケース
67. 具体例で考えられる • 具体例を用いることで… ◦ 各ストーリーの共有理解を 構築するのに役立つ ◦ 矛盾点に気付きやすくなる ◦ ストーリーの受け入れ拒否が減る ◦ 本番デプロイまでの時間短縮が期待できる 『Agile Testing Condensed』 第4章 P16より
68. Three Amigosの得意分野 Three Amigosは得意分野となる注目点が異なる • PO…今回のFeatureで実現したいことに注目 • 開発者…今回のFeatureはどのようにすれば 　　　　実現できるかに注目 • QA…今回のFeatureが「完成した」と 　　判断するためには 　　何を確認すれば良いのかに注目 ※あくまでも得意分野であり、 　責任分担している訳ではない
69. 抽象化と具体化の行き来 人数のグラフを 良い感じに表示する
70. 抽象化と具体化の行き来 じゃあ1500人は どうなる？ 人数のグラフを 良い感じに表示する 1500人 具体化
71. 抽象化と具体化の行き来 上の目盛りが1000だと グラフが突き抜ける ので、その場合は 400,800,1200,1600に 調整されますね じゃあ1500人は どうなる？ 人数のグラフを 良い感じに表示する 1500人 400,800 1200,1600
72. 抽象化と具体化の行き来 上の目盛りが1000だと グラフが突き抜ける ので、その場合は 400,800,1200,1600に 調整されますね じゃあ1500人は どうなる？ 人数のグラフを 良い感じに表示する 一番上の 目盛りを 超えない 1500人 400,800 1200,1600 抽象化
73. 実例マッピングから 自動化へ…
74. BDDにおける自動化への流れ 参考：『The BDD Books - Discovery』第1章より
75. BDDにおける自動化への流れ 参考：『The BDD Books - Discovery』第1章より 例）実例 　　マッピング 例）自動テスト 　　コード作成 例）BRIEFによる 　　シナリオ整理 参考：【翻訳記事】テスト自動化の対象となる 　　　テストシナリオの整理に役立つBRIEFの原則
76. 自動化ツールを最初に考えない • 実例マッピングのような発見のプラクティス を単独で実施するだけで、 ソフトウェア開発活動を大幅に改善できる • BDDツールを利用したり、Given/When/Thenを 使用してテストを自動化しても、 開発アプローチは少しもBDDにはなりません • チームをまたいだ協調作業が 得意になるまでは、 自動化ツールに焦点を合わせない方が良い 参考：『The BDD Books - Discovery』
77. 自動化ツールを最初に考えない • 実例マッピングのような発見のプラクティス を単独で実施するだけで、 ソフトウェア開発活動を大幅に改善できる • BDDツールを利用したり、Given/When/Thenを 使用してテストを自動化しても、 開発アプローチは少しもBDDにはなりません • チームをまたいだ協調作業が 得意になるまでは、 自動化ツールに焦点を合わせない方が良い 参考：『The BDD Books - Discovery』 この書籍の著者は、BDDツール 「SpecFlow(Cucumber for .NET)」の作者
78. 実例マッピングの まとめ
79. 実例マッピングのまとめ • ストーリーに対し、ルール・具体例・疑問点を 区別して表現することができる • 具体例で考え、 抽象化と具体化の行き来をする思考が大切 • 開発者・PO・QAが協力し、 開発の実装前からテストを考え、 チームが目指す製品について認識をしよう • 実例マッピングなどの発見のプラクティスは 自動テストを行う前に考えるのが大切 ◦ 実例マッピングを必ず使う必要はない
80. 参考文献と実践事例
81. 参考文献 • Introducing Example Mapping（方法紹介の記事） ◦ 日本語翻訳版 • The BDD Books - Discovery （書籍） ◦ 日本語翻訳版
82. 実践事例 • QAエンジニアが実例マッピングを2ヶ月運用した話 • miroを使って実例マッピングの一歩目を踏み出すの (仮) • 異世界に転生したら激レア職業のスクラム Developer だったので手始めに Scrum Fest Osaka 2020 で ラーニングしたスキルでリファインメント無双 してみた その他、社外発表はしていませんが、 個別に連絡をいただいた事例あり
83. もしも試してみたくなった方は… 本スライドを実例マッピング参加者全員で読むことで、 基本的には理解できると思います。 もしも • 口頭補足なども含めて詳しく教えてほしい • 自分たちのプロジェクトでも適用したいので アドバイスしてほしい などの要望がありましたら、 ブロッコリー(@nihonbuson)宛にご連絡ください。
84. おしまい