Agile Testingのエッセンス #devsumi / Agile Testing Essence 20220218

by nihonbuson

Slide 1

Slide 1 text

開発者・経営者へ特に伝えたい Agile Testingのエッセンスブロッコリー (@nihonbuson) https://www.pexels.com/ja-jp/photo/6387848/

Slide 2

Slide 2 text

自己紹介 ● 風間裕也（ブロッコリー） ● @nihonbuson ● 所属 ○ 株式会社ビズリーチ ○ QAグループ ● 社外活動 ○ JaSST Review実行委員長 ○ WACATE実行委員 ○ 書籍『Agile Testing Condensed』翻訳 ○ 書籍『Testing in DevOps』翻訳

Slide 3

Slide 3 text

Agile Testingの生い立ち

Slide 4

Slide 4 text

JanetとLisaが執筆した3冊のAgile Testing Agile Testing （日本語版あり） More Agile Testing Agile Testing Condensed （日本語版あり） 2008年刊行全576ページ 2014年刊行全544ページ 2019年刊行全113ページ

Slide 5

Slide 5 text

なぜ最新作はページ数が少ない？ ● 今までの本は分厚すぎて経営者が読まなかった ● 手軽に読んでもらいたくてこの量になった Condensed=濃縮された

Slide 6

Slide 6 text

『Agile Testing Condensed』読書会＆感想 ● 社内読書会報告 ○ atama plus 株式会社様 ○ メディアマックスジャパン株式会社様 ○ 株式会社エス・エム・エス様 ○ ユニバ株式会社 Azukaritaiチーム様 ● 感想ブログ ○ hgsgtk様 ○ らーめん様 ○ 粕谷様

Slide 7

Slide 7 text

第一部 Agileの中で行われる Testing活動第二部 Agile Testingとは新しい概念なのか？

Slide 8

Slide 8 text

第一部 Agileの中で行われる Testing活動

Slide 9

Slide 9 text

改めてテストを考える Designed by pch.vector / Freepik

Slide 10

Slide 10 text

質問 ● なぜ皆さんはテストをしているのでしょうか？ ● テストの目的はなんでしょうか？

Slide 11

Slide 11 text

テストの目的とは何か？ ● 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ。 ● 明確にしたすべての要件を満たしていることを検証する。 ● テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。 ● テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。 ● 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。 ● ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。 ● 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。 ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版Version 2018.J03より実装前に行うこともある

Slide 12

Slide 12 text

テストマニフェスト http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 『Agile Testing Condensed』第1章 P5より

Slide 13

Slide 13 text

欠陥を防ぐ活動はデブサミ2020で講演済テストコードを書き始める前から考えるべきテストの話

Slide 14

Slide 14 text

質問 ● 皆さんは普段どんなテストをしてますか？ ● 業務の中にある「◯◯テスト」を思い出してください Communication vector created by freepik - www.freepik.com

Slide 15

Slide 15 text

こんな考えを持っていませんか？ ● QAチームがテストしているよ ● TDD（テスト駆動開発）でテストしているよ ● 自動テストツールを使ってテストしているよ ● 自動テストでできるだけテストして、できない部分は探索的テストをしているよ ● 最新のツールを使ってテストしているよだから大丈夫だよ！ or 十分考えているけど上手くいかない…

Slide 16

Slide 16 text

こんな考えを持っていませんか？ ● QAチームがテストしているよ ● TDD（テスト駆動開発）でテストしているよ ● 自動テストツールを使ってテストしているよ ● 自動テストでできるだけテストさせて、できない部分は探索的テストをしているよ ● 最新のツールを使ってテストしているよだから大丈夫だよ！ or 十分考えているけど上手くいかない… TDDも自動テストも探索的テストも必要だけど、それだけじゃない！

Slide 17

Slide 17 text

Test Automation Circles(※今日は話しません) 参考：ソフトウェアテスト自動化の変遷。変わったことと変わらないこと。テスト自動化の導入パターン。

Slide 18

Slide 18 text

Test Automation Circles(※今日は話しません) 参考：ソフトウェアテスト自動化の変遷。変わったことと変わらないこと。テスト自動化の導入パターン。同心円の中心から順に考えるべき

Slide 19

Slide 19 text

自動テストプロセス例(※今日は話しません) 参考：ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは

Slide 20

Slide 20 text

自動テストプロセス例(※今日は話しません) 参考：ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは自動テストの話＝自動テストスクリプト実装の話に限定されがち

Slide 21

Slide 21 text

探索的テストとは(※今日は話しません) 探索的テストとは「システムについて学ぶためのテスト設計と実行を同時に行い、最後の実験から得た洞察を次に伝える」探索的テストはじめの一歩 #wacateより Explore It!より

Slide 22

Slide 22 text

探索的テストとは(※今日は話しません) 以下のテストは探索的テストではない ● 計画や文書なしで行うテスト（アドホックテスト） ● ランダムな入力やランダムなアクションを入力して確認するテスト（モンキーテスト）「ランダムにさまようこと」と「思慮深く探索すること」は違う『Agile Testing Condensed』第6章 P26より

Slide 23

Slide 23 text

継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ 『Agile Testing Condensed』第1章 P3より

Slide 24

Slide 24 text

継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ 『Agile Testing Condensed』第1章 P3より AgileTestingの範囲

Slide 25

Slide 25 text

継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ テストの範囲になりがち『Agile Testing Condensed』第1章 P3より

Slide 26

Slide 26 text

継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ TDD など『Agile Testing Condensed』第1章 P3より

Slide 27

Slide 27 text

継続的テストモデル https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ 今回の発表範囲『Agile Testing Condensed』第1章 P3より

Slide 28

Slide 28 text

ストーリー完了までの流れ『Agile Testing Condensed』第4章 P17より Sprint 開始前に実施する

Slide 29

Slide 29 text

ストーリー完了までの流れ『Agile Testing Condensed』第4章 P17より Sprint 開始前に実施する自動テスト探索的テスト

Slide 30

Slide 30 text

ストーリー完了までの流れ『Agile Testing Condensed』第4章 P17より Sprint 開始前に実施する今回の発表範囲

Slide 31

Slide 31 text

Sprint開始前に行う活動テスト活動面に注目した Scrumでの例

Slide 32

Slide 32 text

Sprint開始前に行う活動

Slide 33

Slide 33 text

ストーリー完了までの流れ『Agile Testing Condensed』第4章 P17より Sprint 開始前に実施する今回の発表範囲

Slide 34

Slide 34 text

Sprint開始前の活動例…実例マッピング日本語版: https://nihonbuson.hatenadiary.jp/entry/ExampleMapping https://cucumber.io/blog/bdd/example-mapping-introduction/ ● BDDの導入にあたり考えられたやり方 ● 4色の付箋を用いる ○ 黄色の付箋ユーザーストーリー ○ 青色の付箋ルール ○ 緑色の付箋具体例 ○ 赤色の付箋疑問点、仮定

Slide 35

Slide 35 text

事例を通じて伝えたいこと ● 実例マッピングというプラクティスを使うことが大切なのではない！ ● ストーリーとルールと具体例と疑問点を分けて会話し、分かれた状態で記録するという思考が大切！ ● 実例マッピングが作られていく過程となる会話も併せて紹介する

Slide 36

Slide 36 text

Three Amigos 3つの立場の人が集まり協調的に要件を確認する People vector created by stories - www.freepik.com QA(Tester) 開発者 PO

Slide 37

Slide 37 text

今回の題材・登場人物 PO QA 人数のグラフを良い感じに表示する開発者

Slide 38

Slide 38 text

スケールのルール追加人数のグラフを良い感じに表示したい「良い感じ」が分からないので色々質問しますね縦軸の目盛りは最大値を基準に良い感じでスケールが変わる最大値を基準にスケール変更人数のグラフを良い感じに表示する

Slide 39

Slide 39 text

1000人の場合例えば1000人の場合はどうなります？人数のグラフを良い感じに表示する

Slide 40

Slide 40 text

1000人の場合目盛りが4本なので、目盛りは250, 500, 750, 1000ですかね例えば1000人の場合はどうなります？人数のグラフを良い感じに表示する

Slide 41

Slide 41 text

具体例の追加例えば1000人の場合はどうなります？人数のグラフを良い感じに表示する最大値を基準にスケール変更 1000人

Slide 42

Slide 42 text

具体例の追加目盛りが4本なので、目盛りは250, 500, 750, 1000ですかね例えば1000人の場合はどうなります？人数のグラフを良い感じに表示する最大値を基準にスケール変更 1000人 250,500 750,1000

Slide 43

Slide 43 text

目盛りのルールの追加目盛りが4本なので、目盛りは250, 500, 750, 1000ですかね例えば1000人の場合はどうなります？人数のグラフを良い感じに表示する最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000

Slide 44

Slide 44 text

800人の場合じゃあ800人だったら？人数のグラフを良い感じに表示する

Slide 45

Slide 45 text

具体例の追加人数のグラフを良い感じに表示する目盛りが 4本出る 1000人 250,500 750,1000 800人最大値を基準にスケール変更じゃあ800人だったら？

Slide 46

Slide 46 text

具体例の追加人数のグラフを良い感じに表示する目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 最大値を基準にスケール変更じゃあ800人だったら？その場合も目盛りは 1000人の場合と同じです

Slide 47

Slide 47 text

1500人の場合人数のグラフを良い感じに表示するじゃあ1500人でも同じ？

Slide 48

Slide 48 text

1500人の場合人数のグラフを良い感じに表示するじゃあ1500人でも同じ？その場合は 400,800,1200,1600 に調整されますね

Slide 49

Slide 49 text

1500人の場合人数のグラフを良い感じに表示するじゃあ1500人でも同じ？ 1500人最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000

Slide 50

Slide 50 text

具体例の追加人数のグラフを良い感じに表示するその場合は 400,800,1200,1600 に調整されますねじゃあ1500人でも同じ？ 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000

Slide 51

Slide 51 text

目盛りを超えないルールの追加人数のグラフを良い感じに表示する 1500人の場合はなぜ変わるんですかね？ 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000

Slide 52

Slide 52 text

目盛りを超えないルールの追加人数のグラフを良い感じに表示する上の目盛りが 1000だとグラフが突き抜けてしまうので… 1500人の場合はなぜ変わるんですかね？一番上の目盛りを超えない 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000

Slide 53

Slide 53 text

1050人の場合そしたら1050人は？ 1000人超えだけど… 人数のグラフを良い感じに表示する

Slide 54

Slide 54 text

具体例の追加人数のグラフを良い感じに表示する 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… 一番上の目盛りを超えない 1050人

Slide 55

Slide 55 text

具体例の追加人数のグラフを良い感じに表示するその場合はグラフが外にはみ出ないので目盛りは1000のままですね。 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… 1050人 250,500 750,1000 一番上の目盛りを超えない

Slide 56

Slide 56 text

ルールの変更人数のグラフを良い感じに表示するその場合はグラフが外にはみ出ないので目盛りは1000のままですね。一番上の目盛りを超えない 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… グラフがエリア外に出ないことが重要なんですね。 1050人 250,500 750,1000

Slide 57

Slide 57 text

ルールの変更人数のグラフを良い感じに表示するその場合はグラフが外にはみ出ないので目盛りは1000のままですね。データがエリア外に出ない 1500人 400,800 1200,1600 最大値を基準にスケール変更目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は？ 1000人超えだけど… グラフがエリア外に出ないことが重要なんですね。 1050人 250,500 750,1000

Slide 58

Slide 58 text

600人の場合今度は小さい値を考えてみます。 600人はどうですか？人数のグラフを良い感じに表示する

Slide 59

Slide 59 text

具体例の追加人数のグラフを良い感じに表示する最大値を基準にスケール変更 600人今度は小さい値を考えてみます。 600人はどうですか？

Slide 60

Slide 60 text

具体例の追加人数のグラフを良い感じに表示する最大値を基準にスケール変更 600人 200,400 600,800 250,500,750,1000だとグラフが小さく表示されるので、200,400, 600,800ですかね。今度は小さい値を考えてみます。 600人はどうですか？

Slide 61

Slide 61 text

150人の場合人数のグラフを良い感じに表示するもっと小さい値で150人だったら？

Slide 62

Slide 62 text

具体例の追加人数のグラフを良い感じに表示する最大値を基準にスケール変更 600人 200,400 600,800 150人もっと小さい値で150人だったら？

Slide 63

Slide 63 text

具体例の追加人数のグラフを良い感じに表示する最大値を基準にスケール変更 600人 200,400 600,800 150人 40,80 120,160 そしたら40,80,120, 160ですかね。ちょうど良いのは。もっと小さい値で150人だったら？

Slide 64

Slide 64 text

ルールの発見人数のグラフを良い感じに表示するあー、確かにそうですねなるほどー。ここまでの話から最大値は目盛りの上から2番目よりは大きいように調整するんですかね？

Slide 65

Slide 65 text

ルールの発見人数のグラフを良い感じに表示する最大値を基準にスケール変更 600人 200,400 600,800 150人 40,80 120,160 あー、確かにそうですねなるほどー。ここまでの話から最大値は目盛りの上から2番目よりは大きいように調整するんですかね？

Slide 66

Slide 66 text

ルールの発見人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、確かにそうですねなるほどー。ここまでの話から最大値は目盛りの上から2番目よりは大きいように調整するんですかね？

Slide 67

Slide 67 text

2人の場合人数のグラフを良い感じに表示するさらに小さい値を考えてみます。 2人だとどうなります？

Slide 68

Slide 68 text

具体例の追加人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 2人さらに小さい値を考えてみます。 2人だとどうなります？

Slide 69

Slide 69 text

具体例の追加人数のグラフを良い感じに表示する最大値が目盛りの上から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人だとどうなります？

Slide 70

Slide 70 text

疑問点の追加人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、それは調整する必要があるかも。人数なのに小数点以下の目盛りがあるのは違和感がありますね 2人 0.5,1 1.5,2

Slide 71

Slide 71 text

疑問点の追加人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 あー、それは調整する必要があるかも。人数なのに小数点以下の目盛りがあるのは違和感がありますね 2人 0.5,1 1.5,2 小数点の目盛りは表示される？

Slide 72

Slide 72 text

疑問点の追加人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 価値が無くなる訳ではないので、今回は一旦そのままにしましょう！目盛りの数を状況によって変えるのは工数がかかるから今回はそのままにしたい… 2人 0.5,1 1.5,2 小数点の目盛りは表示される？

Slide 73

Slide 73 text

Slide 74

Slide 74 text

0人の場合人数のグラフを良い感じに表示するそれは自分もどうするか明確にしてないですね… あとは、0人だったらどうなります？目盛りがどのように調節されるのか分からない…

Slide 75

Slide 75 text

疑問点の追加人数のグラフを良い感じに表示する最大値が目盛りの上から2番目よりは大きくなる 600人 200,400 600,800 150人 40,80 120,160 それは自分もどうするか明確にしてないですね… あとは、0人だったらどうなります？目盛りがどのように調節されるのか分からない… 2人 0.5,1 1.5,2 小数点の目盛りは表示される？ →表示する最大値が0人の時に目盛りはどうする？

Slide 76

Slide 76 text

今回の実例マッピングのまとめ人数のグラフを良い感じに表示する 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

Slide 77

Slide 77 text

実例マッピングの成果物から分かること

Slide 78

Slide 78 text

今回の実例マッピングの成果物人数のグラフを良い感じに表示する 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

Slide 79

Slide 79 text

実例マッピングの成果物から分かること人数のグラフを良い感じに表示する 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になる場合も… （調査・決定しない限り、開発に着手すべきでない）

Slide 80

Slide 80 text

実例マッピングの成果物から分かること人数のグラフを良い感じに表示する 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 受け入れ条件に使える（これらを実現したことを確認して案件を「完了」に変える）

Slide 81

Slide 81 text

実例マッピングの成果物から分かること人数のグラフを良い感じに表示する 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 テストケース例に使える ※これが全てではないので注意！

Slide 82

Slide 82 text

実例マッピングの成果物から見える状況具体例の付箋が少ない →議論が足りないかも or 実装内容が自明かも

Slide 83

Slide 83 text

実例マッピングの成果物から見える状況 1つのルールに対して具体例の付箋が多い →ルールが複雑なので、複数のシンプルなルールに分割した方が良いかも

Slide 84

Slide 84 text

実例マッピングの成果物から見える状況ルールの付箋が多い →ストーリーが複雑なのでもっと小さいストーリーに分割した方が良いかも

Slide 85

Slide 85 text

実例マッピングの成果物から見える状況疑問点の付箋が多い →開発開始する準備ができていないかも

Slide 86

Slide 86 text

実例マッピングで必要なスキル Designed by Rawpixel.com / Freepik

Slide 87

Slide 87 text

今回の実例マッピングで必要なスキル ● 具体例で考えられる ○ 実際に起こりうる例で考えられる ● 抽象化と具体化の行き来ができる ○ 具体例からルールを導き出す時に必要 ○ テストのスキルも必要 ■ 同値分割法 ■ ハイレベルテストケースとローレベルテストケース

Slide 88

Slide 88 text

具体例で考えられる ● 具体例を用いることで… ○ 各ストーリーの共有理解を構築するのに役立つ ○ 矛盾点に気付きやすくなる ○ ストーリーの受け入れ拒否が減る ○ 本番デプロイまでの時間短縮が期待できる『Agile Testing Condensed』第4章 P16より

Slide 89

Slide 89 text

Three Amigosの得意分野 Three Amigosは得意分野となる注目点が異なる ● PO…今回のFeatureで実現したいことに注目 ● 開発者…今回のFeatureはどのようにすれば　　　　実現できるかに注目 ● QA…今回のFeatureが「完成した」と　　判断するためには　　何を確認すれば良いのかに注目 ※あくまでも得意分野であり、　責任分担している訳ではない

Slide 90

Slide 90 text

抽象化と具体化の行き来人数のグラフを良い感じに表示する

Slide 91

Slide 91 text

抽象化と具体化の行き来じゃあ1500人はどうなる？人数のグラフを良い感じに表示する 1500人具体化

Slide 92

Slide 92 text

抽象化と具体化の行き来上の目盛りが1000だとグラフが突き抜けるので、その場合は 400,800,1200,1600に調整されますねじゃあ1500人はどうなる？人数のグラフを良い感じに表示する 1500人 400,800 1200,1600

Slide 93

Slide 93 text

抽象化と具体化の行き来上の目盛りが1000だとグラフが突き抜けるので、その場合は 400,800,1200,1600に調整されますねじゃあ1500人はどうなる？人数のグラフを良い感じに表示する一番上の目盛りを超えない 1500人 400,800 1200,1600 抽象化

Slide 94

Slide 94 text

実例マッピングから自動化へ…

Slide 95

Slide 95 text

BDDにおける自動化への流れ参考：『The BDD Books - Discovery』第1章より

Slide 96

Slide 96 text

BDDにおける自動化への流れ参考：『The BDD Books - Discovery』第1章より例）実例　　マッピング例）自動テスト　　コード作成例）BRIEFによる　　シナリオ整理参考：【翻訳記事】テスト自動化の対象となる　　　テストシナリオの整理に役立つBRIEFの原則

Slide 97

Slide 97 text

自動化ツールを最初に考えない ● 実例マッピングのような発見のプラクティスを単独で実施するだけで、ソフトウェア開発活動を大幅に改善できる ● BDDツールを利用したり、Given/When/Thenを使用してテストを自動化しても、開発アプローチは少しもBDDにはなりません ● チームをまたいだ協調作業が得意になるまでは、自動化ツールに焦点を合わせない方が良い参考：『The BDD Books - Discovery』

Slide 98

Slide 98 text

Slide 99

Slide 99 text

実例マッピングのまとめ

Slide 100

Slide 100 text

実例マッピングのまとめ ● ストーリーに対し、ルール・具体例・疑問点を区別して表現することができる ● 具体例で考え、抽象化と具体化の行き来をする思考が大切 ● 開発者・PO・QAが協力し、開発の実装前からテストを考え、チームが目指す製品について認識をしよう ● 実例マッピングなどの発見のプラクティスは自動テストを行う前に考えるのが大切 ○ 実例マッピングを必ず使う必要はない

Slide 101

Slide 101 text

テスト活動面に注目した Scrumでの例

Slide 102

Slide 102 text

テストの考えを日々のサイクルに取り込む Scrumのどのタイミングで、テストの考え方を活用すれば良いのか紹介する

Slide 103

Slide 103 text

今回説明するScrum中の出来事プロダクトバックログリファインメントスプリントプランニングデイリースクラムスプリントレビューレトロスペクティブ開発

Slide 104

Slide 104 text

注意事項 ● 今回はScrumイベント自体の説明はしません ● Scrumの出来事の中で行う、テスト活動面や QAエンジニアの活動に注目した説明をします

Slide 105

Slide 105 text

プロダクトバックログリファインメント ● 毎日30分だけ行う ● 作成したユーザーストーリーから 1つをピックアップして話し合う ● POや開発に疑問点を聞きまくる ● 受け入れ基準（対象PBIをクローズする条件）についてPOと認識合わせをする ● 開発する時のテスト観点の元ネタを作る ● 成果物の例 ○ 実例マッピング ○ テスト観点図

Slide 106

Slide 106 text

スプリントプランニング 1. 各PBIのざっくりとした相対見積もりを行う ○ テストがどのくらい大変になるか考える ○ テストの工数も踏まえた見積もりにする ■ 例.全画面に影響ある共通部分の修正1行 2. 見積もり結果とPBI達成時のインパクトから開発の優先順位を決める 3. テスト観点を出す 4. 各PBIに対してのタスクを洗い出す ○ 最初にテストのタスクを考える

Slide 107

Slide 107 text

開発 ● 開発者 ○ 最初にテストケース作成を行う ○ その後、各PBIの実装・テスト実施をする ● QAエンジニア（テスター） ○ 開発者作成のテストケースをレビューする ○ 各PBIのテスト実施をする ■ スクリプトテスト ■ 探索的テスト ○ 仕様変更によるリグレッションテスト用の E2E自動テストへの影響確認をする

Slide 108

Slide 108 text

レトロスペクティブ ● 今回のスプリントのふりかえりを行う ○ 次回以降のスプリントでもっと仕事をやりやすくするには？を考える ● QAエンジニアだからとかは関係なく、とりあえず意見は出す ○ 「やる/やらない」を判断するのはチーム

Slide 109

Slide 109 text

第一部まとめ

Slide 110

Slide 110 text

第一部のまとめ ● Agileの中で行う活動として実例マッピングを紹介した ● Scrumの中でどのようにテスト活動を考えれば良いか紹介した

Slide 111

Slide 111 text

第二部 Agile Testingとは新しい概念なのか？

Slide 112

Slide 112 text

Agile Testingとは特別な存在なのか？ Abstract photo created by jcomp - www.freepik.com

Slide 113

Slide 113 text

書籍『Agile Testing』執筆のきっかけ JonathanとJanetが同じプロジェクトで関わる ● Jonathan…XP/TDDのコーチ ● Janet…QA出身のPO Jonathan「XPなのでQAいらない」 Janet「そんなことはないはず」 ● Janetは書籍『Agile Testing』を執筆 ● Jonathanは書籍『アジャイルサムライ』を執筆 ○ アジャイルテスターが書籍内に登場参考：https://kawaguti.hateblo.jp/entry/2020/05/08/172925

Slide 114

Slide 114 text

Agile without testing https://twitter.com/m_seki/status/1424503907435225091

Slide 115

Slide 115 text

Agile Testingは特別なことをしていない ● 『Agile Testing Condensed』は AgileにおけるTestingについて述べた書籍 ○ Agileの中でTestingだけ別途のフェーズが存在している訳ではない ○ Agileでテストエンジニア（Tester）がどうすべきかのみ述べた書籍ではない ● "Agile Testingは特定の人が行う訳ではない" と主張して書籍が書かれているのに、逆にこの書籍の存在が、Agile Testingという特別な存在のように見える皮肉

Slide 116

Slide 116 text

Agile以前に Agile Testingのような考え方はなかったのか？ Designed by Freepik - jp.freepik.com

Slide 117

Slide 117 text

デブサミのテーマは Hello, New Decade!

Slide 118

Slide 118 text

デブサミのテーマは Hello, New Decade! 次の10年を考える前に今までの歴史を振り返る

Slide 119

Slide 119 text

https://nureyon.com/seven_segment_indicator-4?pattern=5

Slide 120

Slide 120 text

No content

Slide 121

Slide 121 text

No content

Slide 122

Slide 122 text

テストマニフェスト考案(2015) http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 『Agile Testing Condensed』第1章 P5より

Slide 123

Slide 123 text

No content

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

No content

Slide 126

Slide 126 text

テストの目的を定義したISTQBの前身が発足(1998) ● 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ。 ● 明確にしたすべての要件を満たしていることを検証する。 ● テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。 ● テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。 ● 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。 ● ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。 ● 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。 ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版Version 2018.J03より

Slide 127

Slide 127 text

ISTQBの前身が発足アジャイルソフトウェア開発宣言実践アジャイルテスト刊行 1998 2001 2008 2015 2016 2019 Agile Testing 年表継続的テストモデル実例マッピングテストマニフェスト Agile Testing Condensed 刊行

Slide 128

Slide 128 text

ISTQBの前身が発足アジャイルソフトウェア開発宣言実践アジャイルテスト刊行 1998 2001 2008 2015 2016 2019 Agile Testing 年表継続的テストモデル実例マッピングテストマニフェスト Agile Testing Condensed 刊行 1998年以前に、欠陥を防ぐ品質はチーム全体での責任という考え方は無かったのか？

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

1950年代に品質を作り込むことをやっていた１９５０年代後半から,新製品開発の品質管理ということが盛んにいわれるようになります. つまり, 設計や開発段階からしっかりチェック, 管理を行い,いいものを作っていこうという考え方です. ソフトウェアの品質管理推進について（ENGINEERS 誌 1981年8月号）

Slide 133

Slide 133 text

テストマニフェスト（再掲） http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 『Agile Testing Condensed』第1章 P5より

Slide 134

Slide 134 text

バグの発見よりもバグの防止検査の業務は単なる評価ではなく, 予防に主眼を置いた広汎な活動領域である. ソフトウェアの検査の考え方（学会誌「情報処理」1972年5月号）

Slide 135

Slide 135 text

機能性をチェックするよりもチームが理解している価値をテストするソフトウェアは「原理的に動く」だけのものであってはならず, 「製品として価値がある」ものでなければ, システムにおける機能を全うし得ない. ソフトウェアの検査の考え方（学会誌「情報処理」1972年5月号）

Slide 136

Slide 136 text

直接部門と間接部門のいかんを問わず,（中略）いろいろな角度から全社的品質管理(Total Quality Control:TQC)を推し進めてゆかねばならない. ソフトウェア製品生産管理：ソフトウェア工学における品質管理（QC）と品質保証（QA）（学会誌「情報処理」1980年10月号）テスターの責任よりも品質に対するチームの責任

Slide 137

Slide 137 text

ISTQBの前身が発足 QCリサーチグループ結成ソフトウェアの検査の考え方発表ソフトウェア製品生産管理：ソフトウェア工学における品質管理(QC)と品質保証(QA) 発表日本的品質管理刊行ソフトウェアの品質管理推進について　発表 1949 1972 1980 1981 1998 新製品開発の品質管理を始める 1950年代後半

Slide 138

Slide 138 text

Slide 139

Slide 139 text

QA活動とは何か？品質保証（Quality Assurance）とは ● マニュアル通り作っているかチェックする活動 ● チェックリストの内容を確認する活動

Slide 140

Slide 140 text

QA活動とは何か？品質保証（Quality Assurance）とは ● マニュアル通り作っているかチェックする活動 ● チェックリストの内容を確認する活動 ● ソフトウェアエンジニアリングを用いた活動 ○ 要求が漏れにくいような要件定義を考える ○ 適切なアーキテクチャの良し悪しを考える ○ 欠陥が発生しにくい設計を考える ○ テスト自動化を検討する ○ 稼働実績の把握とフィードバックを考える

Slide 141

Slide 141 text

QA・QCではエンジニアリングを活用する大事なことは,計画段階から設計,製造,検査, 運用,保全を経て廃棄に至るまでのそれぞれの過程に焦点を合わせた方法論の定式化である. 稼働実績の把握に際しては, 信頼性工学の場で広く適用されている解析技法（中略）を大いに活用し,データに語らしめ, データに学ぶことが大切である. ソフトウェア製品生産管理：ソフトウェア工学における品質管理（QC）と品質保証（QA）（学会誌「情報処理」1980年10月号）

Slide 142

Slide 142 text

QA・QCではエンジニアリングを活用する全社的品質管理という名前に引っ張られて、統計的方法の活用が不十分な企業を見受けるが、統計的方法はQCの基礎である。石川馨著『日本的品質管理＜増補版＞』p136

Slide 143

Slide 143 text

Slide 144

Slide 144 text

No content

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

No content

Slide 147

Slide 147 text

未来はどうなるのか？ ● 手法は新たに発明されるかもしれないが根本的な考え方は昔から変わらないかも ● 新たな技術に飛びつくのも大事だが、根本的な考え方を見失わないようにしよう！ ○ 「新しい手法だから」「新しい単語だから」は危険な兆候 ○ 本日紹介した実例マッピングを導入する際も、根本となる考えを思い出して！ ● New Decadeに思いを馳せる前に、温故知新の考えを持つと良い

Slide 148

Slide 148 text

Slide 149

Slide 149 text

第二部まとめ

Slide 150

Slide 150 text

第二部のまとめ ● Agile Testingでは特別なことをしていない ○ 特別なフェーズが存在しているのではない ○ Agile Testerのみの話ではない ● Agile Testingで述べられていることが実は昔から日本でやられている

Slide 151

Slide 151 text

おわりに

Slide 152

Slide 152 text

まとめ ● Agile Testingのことを開発者や経営者にも気軽に知ってもらうために『Agile Testing Condensed』は刊行された ● チーム全体でプロダクトの品質に責任を持とう ● 具体例を用いることで、より協力して開発を進めることができる ● Agile Testingで述べられていることは、実は昔から日本でやられている（組織もある） ○ Agileかそうではないか、テスターか開発者かは関係ない

Slide 153

Slide 153 text

参考書籍 https://leanpub.com/ agiletesting-condensed-japanese-edition http://www.bddbooks.com/

Slide 154

Slide 154 text

その他、参考文献(Agile Testing関連) ● Appendix A: What We've Learned Since Agile Testing【動画】 ● テストマニフェスト ● Continuous Testing in DevOps… ● 実例マッピング ● Cucumber School - Give Me An Example【動画】 ● Cucumber School ● ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは ● Explore It!【書籍】 ● 探索的テストはじめの一歩 #wacate

Slide 155

Slide 155 text

その他、参考文献(品質管理関連) ● ソフトウェアの品質管理推進について ● ソフトウェアの検査の考え方 ● ソフトウェア製品生産管理：ソフトウェア工学における品質管理（QC）と品質保証（QA） ● 日本的品質管理―TQCとは何か【書籍】 ● Quality Management Evolution from the Past to Present: Challenges for Tomorrow ● 品質保証の歴史学 at 「リリカルの質問全部答えます」

Slide 156

Slide 156 text

おしまい

Slide 157

Slide 157 text

補足（時間が余れば話します）

Slide 158

Slide 158 text

これってテストの話ではないのでは？ Q. テストの話ではなく、仕様の話では？ Q. これってレビューの話では？ A. レビューもテスト活動の一部として　考えています。 “テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。” ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版Version 2018.J03 より

Slide 159

Slide 159 text

参考：BDDアプローチを含めたプロセス例『The BDD Books - Discovery』第4章を元に要素を追加し作成

Slide 160

Slide 160 text

どうしてQA＝チェックという認識になったの？ Q.半世紀以上前から、Agile Testingで　言われている活動を日本で行っていたのに、　なんで、その活動が最近まで無かった　（QA＝チェックという認識になった）の？ A.まずは品質管理の歴史について　おさらいしましょう

Slide 161

Slide 161 text

品質管理の進歩 ● 検査重点主義の品質管理 ● 工程管理重点主義の品質管理 ● 新製品開発主義の品質管理石川馨著『日本的品質管理＜増補版＞』p106

Slide 162

Slide 162 text

検査重点主義の品質管理 ● 性悪説的な考え方 ○ 生産部門は悪いことをするもしれない ■ 厳しく管理しよう ■ 検査部門を独立させ、権限を強くしよう ● 検査を強化することが品質保証につながる ● 日本ではQCを初めてすぐ、この考え方を捨てた ● 工場従業員に対する検査員の比率(1981年当時) ○ 日本…1〜5%（検査重点主義ではない） ○ 欧米…15%の場合も（検査重点主義）

Slide 163

Slide 163 text

工程管理重点主義の品質管理 ● 生産工程をよく管理して全製品を良品にしてしまおうという考え方 ● QCの格言「品質は工程でつくり込め」 ● 検査部門だけでは目的を達成できない ○ トップから作業員までQCを実施する ● 開発・設計段階に起因する問題は製造部門や検査部門でカバーできない

Slide 164

Slide 164 text

新製品開発重点主義の品質管理 ● 新製品企画からアフターサービスまでの各ステップごとにしっかりした評価を行う ○ 本生産に入る前に十分な品質解析を行う ● 格言「品質は設計と工程でつくり込め」 ● 新製品開発のQAを重要視している理由 ○ 新製品開発中に品質管理していなければ、十分な品質保証ができない ○ 新製品開発に失敗すると、その企業は倒産の瀬戸際に立たされることになる ○ 全部門が、品質管理、品質保証を実際に体験できる

Slide 165

Slide 165 text

欧米式TQC(Total Quality Control) ● ファイゲンバウム博士の考え方 ● 本来のTQCの考え ● 全部門がQCを実施する必要がある ● QC技術者が中心になって活躍する必要がある

Slide 166

Slide 166 text

日本式TQC(Total Quality Control) ● 1949年から行っているQC活動で生まれた考え方 ● QC技術者が行うQCということではない ● 各階層、各部門がQCを勉強し、実施する ● トップやスタッフも含めた全員でQCを実施する ● 品質の管理と同時に原価管理、量管理、納期管理を推進していく ● 海外にはCWQC(Company-Wide Quality Control) として紹介していた ● 後にTQM(Total Quality Management)に発展し欧米に受け入れられる

Slide 167

Slide 167 text

品質管理の時代変化検査重点主義工程管理重点主義新製品開発重点主義 ISO 9001 信仰？？？？検査重点主義？？？？ 1950 1990 2010 日本欧米認証主義 →ISO9000へ発展日本的TQCの導入 →TQMへの発展

Slide 168

Slide 168 text

品質管理の時代変化検査重点主義工程管理重点主義新製品開発重点主義 ISO 9001 信仰？？？？検査重点主義？？？？ 1950 1990 2010 日本欧米認証主義 →ISO9000へ発展日本的TQCの導入 →TQMへの発展 NBCが「If Japan Can… Why Can't We?」を放映

Slide 169

Slide 169 text

品質管理の時代変化検査重点主義工程管理重点主義新製品開発重点主義 ISO 9001 信仰？？？？検査重点主義？？？？ 1950 1990 2010 日本欧米認証主義 →ISO9000へ発展日本的TQCの導入 →TQMへの発展・プロジェクト　マネジメントブーム・プロセスを守ればOK ・国際規格を守ればOK

Slide 170

Slide 170 text

プロセスを決めれば品質保証できるという幻想品質保証の歴史学 at「リリカルの質問全部答えます」

Slide 171

Slide 171 text

参考：米国専門家が捉えた品質管理の時代変化 Quality Management Evolution from the Past to Present: Challenges for Tomorrow のTable2を翻訳

Slide 172

Slide 172 text

参考：米国専門家が捉えた品質管理の時代変化 Quality Management Evolution from the Past to Present: Challenges for Tomorrow のTable2を翻訳