Agile Testingのエッセンス #scrumosaka / Agile Testing Essence

以下のイベントの投影資料です。
https://www.scrumosaka.org/

実例マッピングについては下記のブログ記事も参考にしてください。
https://nihonbuson.hatenadiary.jp/entry/ExampleMapping

【発表資料中のURL】
「第○章 P△△より」という記述は全て、書籍『Agile Testing Condensed Japanese Edition』( https://leanpub.com/agiletesting-condensed-japanese-edition )の記載

その他の記載内容については下記の通り

P4 Agile Testing: A Practical Guide for Testers and Agile Teams
https://www.amazon.co.jp/dp/B001QL5N4K/

P4 実践アジャイルテスト
https://www.amazon.co.jp/dp/4798119970/

P5 Appendix A: What We´ve Learned Since Agile Testing
https://www.youtube.com/watch?v=FIJQPHNS5Jc

P6 More Agile Testing
https://www.amazon.co.jp/dp/B00O27V8DA

P7 Agile Testing Condensed
https://leanpub.com/agiletesting-condensed

P7 Agile Testing Condensed Japanese Edition
https://leanpub.com/agiletesting-condensed-japanese-edition

P10 マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1 (日本語) 単行本
https://www.amazon.co.jp/dp/4863543026

P10 TESTER CHAN English Edition vol.1
https://testerchan.booth.pm/items/1478233

P10 Lisa、Janetとの3ショット写真
https://twitter.com/nihonbuson/status/1191722675162537984

P54 Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
https://www.amazon.co.jp/dp/B00I8W50T8/

P54 探索的テストはじめの一歩 #wacate
https://www.slideshare.net/tosikawa/wacate-56868585/27

Transcript

1. 日本の開発者・経営者に 特に伝えるべき Agile Testingの エッセンス ブロッコリー (@nihonbuson)
2. 自己紹介 • 風間裕也（ブロッコリー） • 所属 ◦ 株式会社ビズリーチ ◦ QA基盤推進室 QA Evangelist • 社外活動 ◦ JaSST Review実行委員長 ◦ WACATE実行委員 ◦ 書籍『Agile Testing Condensed』 翻訳
3. JanetとLisaによる Agile Testingの歴史
4. 2008年…書籍『Agile Testing』を刊行 • 日本語翻訳版『実践アジャイルテスト』も翌年に刊行 https://www.amazon.co.jp/dp/B001QL5N4K/ https://www.amazon.co.jp/dp/4798119970/
5. 2011年…Agile Testing Daysにて講演 https://www.youtube.com/watch?v=FIJQPHNS5Jc
6. 2014年…『More Agile Testing』を刊行 • 日本語翻訳版はまだ刊行されていない https://www.amazon.co.jp/dp/B00O27V8DA
7. 2019年…『Agile Testing Condensed』を刊行 • 日本語翻訳版は2020年4月に電子版のみ刊行 https://leanpub.com/agiletesting-condensed https://leanpub.com/agiletesting-condensed-japanese-edition
8. 各書籍のページ数 • Agile Testing …576ページ • More Agile Testing …544ページ • Agile Testing Condensed …113ページ 最新作『Agile Testing Condensed』が圧倒的に ページ数が少ない！
9. なぜ最新作はページ数が少ない？ • 今までの本は分厚すぎて経営者が読んでくれなかった • もっと手軽に読んでもらいたくてこの量になった Condensed=濃縮された Agile Testing Days 2019 　　　　　　 での一コマ
10. なぜ私が翻訳したのか • Agile Testing Days 2019 で著者の2人に直接会う • 日本から持ってきた 『テスターちゃん』と 物々交換 ◦ 日本語書籍版 ◦ 英語同人誌版 • 後日、川口さんが 翻訳の許可を貰っている ことを知り、翻訳作業開始 https://twitter.com/nihonbuson/status/1191722675162537984
11. 今回の発表内容 • 『Agile Testing Condensed』に載っている アジャイルテストに関する考え方を紹介する • 実際に行なった事例や日本での考え方を紹介する
12. 改めて アジャイルテストを 考える
13. アジャイルテストの定義 • 始まりからデリバリーまで、そしてそれ以降も 継続的に実施される協調的なテストの実践により、 お客様への価値の頻繁な提供をサポートします。 • テスト活動は、高速なフィードバックループを用いて 理解を検証しながら、 プロダクトの品質を築くことに重点を置いています。 • プラクティスは、品質に対するチーム全体の責任とい う考え方を強化し、サポートします。 第1章 P5より
14. 継続的テストモデル 第1章 P3より
15. アジャイルテストの10の原則 • 継続的なフィードバックを提供します • 顧客に価値を提供します • 対面でのコミュニケーションを可能にします • 勇気を持って • シンプルさを保ちます • 継続的な改善を実践します • 変更に対応します • 自己組織化します • 人に焦点を当てます • 楽しんで！ 第1章 P4より
16. テストマニフェスト 第1章 P5より
17. テストのアプローチ • 例を用いる • 探索的テスト • 品質特性のテスト • DevOpsでのテスト
18. 例を用いる
19. 例を用いる • 例を用いることで… ◦ 各ストーリーの共有理解を構築するのに役立つ ◦ 矛盾点に気付きやすくなる ◦ ストーリーの受け入れ拒否が減る ◦ 本番デプロイまでの時間短縮が期待できる • 例を用いるプラクティス ◦ 振る舞い駆動開発（BDD） ◦ 受け入れ駆動開発（ATDD） ◦ インパクトマッピング ◦ 実例マッピング 第4章 P16より
20. 実例マッピング ルールの理解を明確にする • 赤い付箋（疑問点）だらけ ◦ 学ぶ内容がまだ沢山ある • 青い付箋（ルール）だらけ ◦ ストーリーが大きく複雑 ◦ ストーリーを分割すべき • 1つのルールに対して、 多くの緑の付箋（例）がある ◦ ルールが複雑すぎる ◦ 複数の青い付箋（ルール）に分割すべき 第5章 P23より
21. 実例マッピングの事例
22. 事例を通じて伝えたいこと • 実例マッピングというプラクティスを使うことが 大切なのではない！ • ストーリーとルールと例と疑問点を分けて会話し、 分かれた状態で記録するという思考が大切！ • 今回は、実例マッピングが作られていく過程となる 会話も併せて紹介する
23. 今回の題材・登場人物 人数のグラフを 良い感じに表示する 開発者 QA
24. スケールのルール追加 人数のグラフを 良い感じに表示したい 「良い感じ」が分からない ので色々質問しますね 縦軸の目盛りは最大値を 基準に良い感じで スケールが変わる 最大値を 基準に スケール 変更 人数のグラフを 良い感じに表示する
25. 1000人の場合 目盛りが4本出るので、 目盛りは250, 500, 750, 1000ですかね 例えば1000人の場合って どうなります？ 人数のグラフを 良い感じに表示する
26. 目盛りのルール追加 目盛りが4本出るので、 目盛りは250, 500, 750, 1000ですかね 例えば1000人の場合って どうなります？ 人数のグラフを 良い感じに表示する 目盛りが 4本出る 1000人なら 250,500 750,1000 最大値を 基準に スケール 変更
27. 800人の場合 その場合も目盛りは 同じです じゃあ800人だったら？ 人数のグラフを 良い感じに表示する
28. 例の追加 その場合も目盛りは 同じです じゃあ800人だったら？ 人数のグラフを 良い感じに表示する 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 最大値を 基準に スケール 変更
29. 1500人の場合 上の目盛りが1000だと グラフが突き抜ける ので、その場合は 400,800,1200,1600に 調整されますね じゃあ1500人でも 同じ？ 人数のグラフを 良い感じに表示する
30. 目盛りを超えないルールの追加 上の目盛りが1000だと グラフが突き抜ける ので、その場合は 400,800,1200,1600に 調整されますね じゃあ1500人でも 同じ？ 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 一番上の 目盛りを 超えない 1500人なら 400,800 1200,1600
31. 1050人の場合 そしたら1050人は？ 1000人は超えるけど… 人数のグラフを 良い感じに表示する その場合はグラフが 外まではみ出ないので 目盛りは1000のまま ですね。
32. 1050人の場合 そしたら1050人は？ 1000人は超えるけど… 人数のグラフを 良い感じに表示する その場合はグラフが 外まではみ出ないので 目盛りは1000のまま ですね。 あくまでも、グラフが エリア外に出ないこと が重要なんですね。
33. 1050人の場合 そしたら1050人は？ 1000人は超えるけど… 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000 その場合はグラフが 外まではみ出ないので 目盛りは1000のまま ですね。 あくまでも、グラフが エリア外に出ないこと が重要なんですね。 一番上の 目盛りを 超えない
34. ルールの変更 そしたら1050人は？ 1000人は超えるけど… 目盛りが 4本出る 1000人なら 250,500 750,1000 800人なら 250,500 750,1000 人数のグラフを 良い感じに表示する 最大値を 基準に スケール 変更 データが エリア外 に出ない 1500人なら 400,800 1200,1600 1050人なら 250,500 750,1000 その場合はグラフが 外まではみ出ないので 目盛りは1000のまま ですね。 あくまでも、グラフが エリア外に出ないこと が重要なんですね。
35. 600人の場合 250,500,750,1000だと グラフが小さく表示さ れるので、200,400, 600,800ですかね。 今度は小さい値を 考えてみます。 600人はどうなります？ 人数のグラフを 良い感じに表示する
36. 150人の場合 そしたら40,80,120, 160ですかね。 ちょうど良いのは。 じゃあもっと小さい値 で150人とかだったら？ 人数のグラフを 良い感じに表示する
37. 例の追加 そしたら40,80,120, 160ですかね。 ちょうど良いのは。 じゃあもっと小さい値 で150人とかだったら？ 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値を基準に スケール変更
38. ルールの発見 あー、 確かにそうですね なるほどー。 ここまでの話を聞くと 最大値は目盛りの 上から2番目よりは 大きいように調整 される感じですかね？ 人数のグラフを 良い感じに表示する
39. ルールの発見 あー、 確かにそうですね なるほどー。 ここまでの話を聞くと 最大値は目盛りの 上から2番目よりは 大きいように調整 される感じですかね？ 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値を基準に スケール変更
40. ルールの発見 あー、 確かにそうですね なるほどー。 ここまでの話を聞くと 最大値は目盛りの 上から2番目よりは 大きいように調整 される感じですかね？ 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整
41. 2人の場合 4分割で考えると0.5, 1, 1.5, 2ですかね。 さらに小さい値を 考えてみます。 2人だと どうなります？ 人数のグラフを 良い感じに表示する
42. 2人の場合 4分割で考えると0.5, 1, 1.5, 2ですかね。 さらに小さい値を 考えてみます。 2人だと どうなります？ 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 2人なら 0.5, 1 1.5, 2
43. 疑問点の追加 あー、それは調整する 必要があるかも。 人数なのに小数点以下 の目盛りがあるのは 違和感がありますね 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 小数点の 目盛りは 表示される？ 2人なら 0.5, 1 1.5, 2
44. 0人の場合 それは自分も どうするか明確に してないですね… あとは、0人だったら どうなります？ 目盛りがどのように 調節されるのか 分からないのですが… 人数のグラフを 良い感じに表示する
45. ルールの追加 それは自分も どうするか明確に してないですね… あとは、0人だったら どうなります？ 目盛りがどのように 調節されるのか 分からないのですが… 人数のグラフを 良い感じに表示する 600人なら 200,400 600,800 150人なら 40,80 120,160 最大値が目盛りの 上から2番目よりは 大きくなるように調整 小数点の 目盛りは 表示される？ 最大値が0人 の時に目盛り はどうする？ 2人なら 0.5, 1 1.5, 2
46. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 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
47. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 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になる場合も…
48. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 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 受け入れ条件に使える
49. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 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 テストケースに使える
50. 今回の実例マッピングのまとめ • ストーリーに対して、ルール・例・疑問点を 区別して表現することができた • 実例マッピングの成果物をインプットとして、 Spike Taskの抽出、受け入れ条件の作成、 テストケースの作成に役立てることができる • 開発者とQAが協力して、 開発の実装前からテストのことを考え、 チームが目指す製品について認識することができた
51. テストマニフェスト（再掲） 第1章 P5より
52. 今回の実例マッピングで必要なスキル • 具体例で考えられる ◦ 実際に起こりうる例で考えられる • 抽象化と具体化の行き来ができる ◦ 具体例からルールを導き出す時に必要 ◦ テストのスキルも必要 ▪ 同値分割法 ▪ ハイレベルテストケースと ローレベルテストケース
53. 探索的テスト
54. 探索的テスト 探索的テストとは 「システムについて 学ぶためのテスト設計 と実行を同時に行い、 最後の実験から得た 洞察を次に伝える」 探索的テストはじめの一歩 #wacateより Explore It!より
55. 探索的テスト 以下のテストは探索的テストではない • 計画や文書なしで行うテスト（アドホックテスト） • ランダムな入力やランダムなアクションを入力して 確認するテスト（モンキーテスト） 「ランダムにさまようこと」と 「思慮深く探索すること」は違う 第6章 P26より
56. アジャイルテストで よく使われる図を 再考する
57. アジャイルテストでよく使われる図 • アジャイルテストの四象限 • テスト自動化戦略の視覚化
58. アジャイルテストの四象限 第9章 P44より
59. アジャイルテストの四象限 第9章 P42より
60. アジャイルテストの四象限 • この図のポイント ◦ 各象限に入っているものが重要ではない ◦ どの象限が何を示しているのか理解することが重要 ▪ Q1…開発を導く技術面のテスト ▪ Q2…開発を導くビジネス面のテスト ▪ Q3…プロダクトを批評するビジネス面のテスト ▪ Q4…プロダクトを批評する技術面のテスト • 状況に合わせてモデルを当てはめる 第9章 P43より
61. テスト自動化戦略の視覚化 • 視覚化モデルの例 ◦ テスト自動化ピラミッド ◦ テスト自動化の氷山
62. テスト自動化ピラミッド 第10章 P43より
63. テスト自動化の氷山 第10章 P51より
64. 今日のアジャイルテスト
65. 今日のアジャイルテスト • テスターの新たな役割 • 成功の材料
66. テスターの新たな役割
67. テスターの新たな役割 • 世界中のテスターが新たな役割を提案している ◦ 世界ではQAエンジニアやテストエンジニアと言わず 「テスター」と呼ぶことが多い • 世界中のテスターの考えを次ページ以降に共有する • 先ほどの実例マッピングで当てはめたものを 吹き出しで示す
68. 世界中のテスターが考えていること • テスターはチームにとって品質の接着剤である • アジャイルテスターのプロフェッショナルな旅 ◦ ランダムなテストから、 モデル、テクニック、専門的なスキルや知識を 使った思慮深いテストの設計に移行する 同値分割を活用 第11章 P54-56より
69. 世界中のテスターが考えていること • テスターとして進化する魅力的な道 ◦ 品質のゲートキーパーから、 下記のコアスキルを持つ人材へ進化する ▪ 新しい実験を学び、試す ▪ 優れた質問者になる ▪ モデリングスキルを持つ ▪ テスト容易性などを定義するための知識を持つ ▪ 共有と共同の姿勢を持つ 質問しまくり 第11章 P57より
70. 世界中のテスターが考えていること • できる限りのことをする • 会話から始める • 世界にはこれ以上のチェッカーは必要ない どんなプロダクト？ から考える 第11章 P58-60より
71. JanetとLisaが考えていること • テスターがチームのテストコンサルタントとして 行動する必要性が高まっている ◦ 協調スキル ◦ ファシリテーションスキル ◦ 教育スキル ◦ コーチングスキル ◦ コミュニケーションスキル 開発者が テストを学ぶ 第11章 P61-62より
72. テストも含めて アジャイルを 成功させるためには
73. 成功の材料 • チーム全体のアプローチを意識する • アジャイルテストの考え方を持つ • 回帰テストを自動化する • フィードバックを提供および取得する • コアプラクティスの基盤を構築する • 顧客との協調をする • 全体像を見る 第12章より
74. 信頼関係構築のプラクティス • 実例を使う • 探索的テストをする • フィーチャーをテストする • 継続的に学習する • 状況に敏感になる • 常に現実的でいる 第12章より
75. 成功への道 • テストの問題をデリバリーチーム全体が対処する問題 に変えることは、プロダクトに品質を組み込み、 持続可能な成功を達成する方法を学ぶために不可欠。 • 品質の望ましいレベルを達成するには何年もかかる ◦ 忍耐が必要 ◦ 頻繁なチームのふりかえりはとても重要 ▪ 品質関連の最大の問題を特定するため ▪ 小さな実験を計画するため 第12章より
76. まとめ
77. まとめ • アジャイルテストのことを開発者や経営者にも 気軽に知ってもらうために 『Agile Testing Condensed』は刊行された • テストマニフェストなどで示されているように チーム全体でプロダクトの品質に責任を持つ • 例を用いることで、 より協力して開発を進めることができる • モデル化されたものも状況に応じてカスタマイズする • 思慮深いテスト設計も必要
78. おしまい