テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021

以下のイベントの投影資料です。
https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337

お問い合わせは https://twitter.com/nihonbuson まで。

【発表資料中のURL】
P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15
※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています

P17 概説テスト分析
http://www.slideshare.net/takashiyamasaki378/ss-55384920

P29 システム/ソフトウェア製品品質、利用時の品質
https://www.ipa.go.jp/files/000045962.pdf#page=13

P33 勝手にリデザイン：新宿高層ビルの館内施設案内板
https://note.openvista.jp/2011/redesigning-shinjuku-building-sign

P37 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=20

P71 あなたがやっているのはテスティングかチェッキングか？
https://www.infoq.com/jp/news/2009/12/testing-or-checking

P74 Agile Testing Condensed: A Brief Introduction (English Edition)
https://www.amazon.co.jp/dp/B07YR4CC4B

P76 テストから見えてくるグーグルのソフトウェア開発
https://www.amazon.co.jp/dp/B00IE3B522/

P92 見てわかるテスト駆動開発
https://speakerdeck.com/twada/tdd-live-and-workshop-2019-spring?slide=16

P92 顧客が本当に必要だったものから学ぶこと
https://www.casleyconsulting.co.jp/blog/engineer/4334/

P93 事例から学ぶ実例マッピングのやり方
https://speakerdeck.com/nihonbuson/example-mapping

P93 TODOリストの整理を通じて実行すべきテストを考える
https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt

P93 「テストは単純作業ではなく創造的な活動だ」という意識を浸透させた物語
https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity

P94 継続的テストモデル（改）
https://lisacrispin.com/2020/11/01/shifting-left-right-in-our-continuous-world/

P97 [改訂新版]マインドマップから始めるソフトウェアテスト
https://www.amazon.co.jp/dp/4297105063/

P98 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際
https://www.amazon.co.jp/dp/4817193603

P98 ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~
https://www.amazon.co.jp/dp/429711061X/

P99 Agile Testing Condensed: A Brief Introduction (English Edition)
https://www.amazon.co.jp/dp/B07YR4CC4B

P100 JaSST
http://www.jasst.jp/

P101 WACATE
https://wacate.jp/

Transcript

1. テストコードを 書き始める前から 考えるべきテストの話 ブロッコリー (@nihonbuson)
2. 自己紹介 • 風間裕也（ブロッコリー） • @nihonbuson • 所属 ◦ 株式会社ビズリーチ ◦ QA基盤推進室 QA Evangelist • 社外活動 ◦ JaSST Review実行委員長 ◦ WACATE実行委員 ◦ 書籍『Agile Testing Condensed』 翻訳
3. アジェンダ • はじめに • テストの目的 • 何をテストすべきか • どうやってテストケースを作るのか • QAはどのように開発者と一緒に仕事をするのか • テストの勉強方法 • まとめ
4. はじめに https://www.pexels.com/photo/young-game-match-kids-2923/
5. 注意事項 • 話さない内容 ◦ テストコードの書き方 ◦ TDDのやり方 ◦ 自動テストの設計方法 • 話す内容 ◦ テストの目的とは何か ◦ テストファーストで行うことの本当の良さ ◦ 何をテストすれば良いのか
6. 今日話す内容は… QA（Quality Assurance＝品質保証） チームはどういう動きをするか
7. 今日話す内容は… QA（Quality Assurance＝品質保証） チームはどういう動きをするか ↓ 開発者はどんなことをすべきか
8. こんな経験していませんか？ 開発はできたけど、 テストをどうやれば良いのか 分からないよ…。 リリースしてから トラブルがいっぱい 起きるなぁ…
9. こんな経験していませんか？ 開発はできたけど、 テストをどうやれば良いのか 分からないよ…。 リリースしてから トラブルがいっぱい 起きるなぁ… 品質やテストのことを学べば 解決できるかもしれない！
10. テストの目的 https://jp.freeimages.com/photo/on-target-1504936
11. 質問です テストの目的って何でしょう？
12. テストの目的とは何か？ • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分なことの確認 • 意思決定のための情報の提示 • 欠陥の作り込みの防止 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない
 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より
13. なぜ実装前にテスト・レビューをするのか 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍 20倍 200倍！ 出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社
14. なぜ実装前にテスト・レビューをするのか 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍 20倍 200倍！ 出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社 修正コストを下げるには…(1) 素早くリリースしてフィードバックをもらい、 すぐに修正できる体制にする
15. なぜ実装前にテスト・レビューをするのか 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍 20倍 200倍！ 出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社 修正コストを下げるには…(2) 早い段階で不具合を発見する
16. 何をテストすべきか https://jp.freeimages.com/photo/target-1306247
17. • パスワードは4文字以上12文字以下の 英数字のみを許容する。 • パスワードを3分以内に4回以上 間違って入力すると、 アカウントを5分間ロックする。 https://www.pexels.com/photo/man-in-brown-shirt-writing-on-noteb ook-3202028/ 引用：概説 テスト分析 例題
18. 例題 あなたが考えた • テスト内容 • 気になった内容 • 起こりそうなバグ を書いてください。 ※何個でもOK！ • パスワードは4文字以上12文字以下の 英数字のみを許容する。 • パスワードを3分以内に4回以上 間違って入力すると、 アカウントを5分間ロックする。 https://www.pexels.com/photo/man-in-brown-shirt-writing-on-noteb ook-3202028/ 引用：概説 テスト分析
19. 回答例 パスワードは4文字以上12文字以下の 英数字のみを許容する。 パスワードを3分以内に4回以上間違って入力すると、 アカウントを5分間 ロックする。 文字列長 文字種 誤入力期間 誤入力回数 ロック保持期間 状態遷移
20. 回答例 パスワードは4文字以上12文字以下の 英数字のみを許容する。 パスワードを3分以内に4回以上間違って入力すると、 アカウントを5分間 ロックする。 文字列長 文字種 誤入力期間 誤入力回数 ロック保持期間 状態遷移 許容しないとどうなる？ （ボタン制御orエラー画面） 5回目の入力はどうなる？
21. 設計・開発時点
22. テスト時点
23. テスト時点 追加コストが発生！
24. 回答例 パスワードは4文字以上12文字以下の 英数字のみを許容する。 パスワードを3分以内に4回以上間違って入力すると、 アカウントを5分間 ロックする。 文字列長 文字種 誤入力期間 誤入力回数 ロック保持期間 状態遷移 許容しないとどうなる？ （ボタン制御orエラー画面） 5回目の入力はどうなる？
25. 伝えたいこと • 隣の人はあなたが気づかなかったことを 知っていませんでしたか？ ◦ お互いにテスト内容についても議論しましょう！ •
26. 伝えたいこと • 隣の人はあなたが気づかなかったことを 知っていませんでしたか？ ◦ お互いにテスト内容についても議論しましょう！ • この例では1文字もプログラムを書いていません！ ◦ 実装前にテストすることができる例です。 ◦ もしもこの時点で指摘できれば 総コストは削減できるでしょう。 ▪ 今回の場合、「許容する」をこの時点で 話し合うと、ほぼ不具合が発生しません。
27. テストの目的とは何か？（再掲） • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分なことの確認 • 意思決定のための情報の提示 • 欠陥の作り込みの防止 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない
 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
28. 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍 20倍 200倍！ 出典： Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社 修正コストを下げるには…(2) 早い段階で不具合を発見する なぜ実装前にテスト・レビューをするのか（再掲）
29. 機能を作る≠顧客へ価値を提供する https://www.ipa.go.jp/files/000045962.pdf#page=13
30. 使用性の例 次の画像を見て判断してください。 化粧室に行くには、 左折、直進、右折の どの方向へ行けば良い？
31. 使用性の例 化粧室に行くには、 左折、直進、右折の どの方向へ行けば良い？
32. 使用性の例 面白いデザインだ！ 採用！ 看板作成者 どこに何があるのか 分からない！ 利用者
33. 使用性の例 並び変えるだけでも 分かりやすくなる https://note.openvista.jp/2011/redesigning-shinjuku-building-sign
34. 「何をテストすべきか」で伝えたいこと • 実装前に考えられるテストは存在する ◦ 例えば設計レビューの場で 「こういうテストを考えています」 という話も聞けると良いな • 「機能を作る」と「顧客へ価値を提供する」は 同義ではない ◦ 機能を作ることに没頭せず、 顧客が本当に欲しい物が何かを考えましょう
35. どうやって テストケースを 作るのか https://jp.freeimages.com/photo/check-list-1150080
36. 例題：何個の選択肢をテストする？ 都道府県の項目についてテストする場合、 どんな値を使ってテストしますか？ 何個の選択肢をテストしますか？
37. テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス（JSTQBより） 参考：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02 何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する
38. テストケース作成の心得 テストケース作成者「◦◦◦のテストをします！」 司会者「ほぉ～、それはどうしてだい？」 テストケース作成者「【理由を一言】」
39. 答え(その1) プルダウンの一番下の値を使う（沖縄県） →プルダウン内のスクロール、配列エラー確認(i[47])
40. 答え(その2) 都・道・府・県の4つを使う （東京都、北海道、大阪府、神奈川県） →以下のように、印刷物に丸印を反映させる場合 　都道府県それぞれの値でテストすべき
41. 答え(その3) 文字数が3文字と4文字の選択肢を使う （東京都、神奈川県） →以下の確認画面のように、文字数による崩れを 　見つけたい場合、文字数の違う値でテストすべき
42. 答え(その4) 各地域の選択肢を使う →例えば地域によって価格が異なる場合、 　価格ごとにテストすべき
43. 答え(その5) すべての選択肢を行う →switch文で分岐の場合、全選択肢をテストすべき switch(area){ case “北海道”: // 何らかの処理 break; case “青森県”: // 何らかの処理 break; …
44. テストケース名にも役立つ @Test public void _青森県の場合{ } @Test public void _広島県の場合{ }
45. テストケース名にも役立つ @Test public void _青森県の場合{ } @Test public void _広島県の場合{ }
46. テストケース名にも役立つ @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); }
47. テストケース名にも役立つ @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケース ローレベルテストケース
48. テストケースはいくつ？ • テストケースは時間があれば無限にできる。 • サンプリング方法としてテスト設計技法がある。 ◦ テストケースを合理的に少なくするための技法 ▪ 同値分割法、AllPair法 ◦ 多くの欠陥が見つかるようにするための技法 ▪ 境界値分析、エラー推測、探索的テスト ◦ ある観点で漏れなくテストするための技法 ▪ カバレッジ、デシジョンテーブル、 状態遷移、ユースケーステスト
49. 境界値分析 https://jp.freeimages.com/photo/linux-login-1497422
50. テストケースはいくつ？ パスワードは4文字以上12文字以下 1文字、2文字、3文字…100文字 テストの7原則②全数テストは不可能 膨大な数の テストケース
51. テストケース作成の心得 テストケース作成者「◦◦◦のテストをします！」 司会者「ほぉ～、それはどうしてだい？」 テストケース作成者「【理由を一言】」
52. 12 4 有効 無効 無効 3 13 境界値分析で考える パスワードは4文字以上12文字以下
53. 境界値分析で考える 「パスワードが4文字以上12文字以下」で なぜ3,4,12,13をテストするのか？ if( x < 3 ){ return “入力したパスワードが短いです”; }
54. 境界値分析で考える 「パスワードが4文字以上12文字以下」で なぜ3,4,12,13をテストするのか？ if( x < 3 ){ return “入力したパスワードが短いです”; } 上記の例で、不等号のミスによる不具合を 発見できるのは、3の時だけ！
55. カバレッジは100%だけど… public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_short_password{ assertThat( judge(2), is(false)); } @Test public void test_long_password{ assertThat( judge(15), is(false)); } @Test public void test_valid_password{ assertThat( judge(7), is(true)); }
56. カバレッジは100%だけど… public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_short_password{ assertThat( judge(2), is(false)); } @Test public void test_long_password{ assertThat( judge(15), is(false)); } @Test public void test_valid_password{ assertThat( judge(7), is(true)); }
57. カバレッジは100%だけど… public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_short_password{ assertThat( judge(2), is(false)); } @Test public void test_long_password{ assertThat( judge(15), is(false)); } @Test public void test_valid_password{ assertThat( judge(7), is(true)); }
58. カバレッジは100%だけど… public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_short_password{ assertThat( judge(2), is(false)); } @Test public void test_long_password{ assertThat( judge(15), is(false)); } @Test public void test_valid_password{ assertThat( judge(7), is(true)); }
59. カバレッジは100%だけど… public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_short_password{ assertThat( judge(2), is(false)); } @Test public void test_long_password{ assertThat( judge(15), is(false)); } @Test public void test_valid_password{ assertThat( judge(7), is(true)); }
60. 12 4 有効 無効 無効 3 13 欠陥は局所的に発生する パスワードは4文字以上12文字以下 テストの7原則④欠陥の偏在
61. 12 4 有効 無効 無効 3 13 もう1箇所テストできるならば… パスワードは4文字以上12文字以下 テストの7原則④欠陥の偏在
62. 12 4 有効 無効 無効 3 13 0文字はnull処理などの可能性がある パスワードは4文字以上12文字以下 テストの7原則④欠陥の偏在 0
63. 「どうやってテストケースを作るのか」で伝えたいこと • 全てを闇雲にテストすると膨大なケース数と時間が 発生するが、その数を削減できる手法がある • そのテストを行う理由をテストケース名にする • テストを考えることで、 仕様に書かれていない内容に気づくことができる
64. QAはどのように 開発者と一緒に 仕事をするのか https://www.pexels.com/photo/woman-in-black-coat-1181346/
65. QAチームは何をするの？ これだけテストが充実できれば QAチームは必要ないのでは？
66. QAチームは何をするの？ これだけテストが充実できれば QAチームは必要ないのでは？ →ここまでの発表以外にQAは、 1. システムテストレベルを見たい！ 2. CheckingではなくTestingを行いたい！ 3. テスト以外も行いたい！ ※QAチームが無い場合、誰かor全員が担うべき
67. QAはシステムテストレベルを見たい！ • 単体テスト（モジュールテスト） ◦ 商品の個数欄にマイナスの数値を入力できない。 • 結合テスト ◦ カートに3個入っていて、2個追加したら、 確認ページで5個になった。 • システムテスト ◦ 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 EC サイト の例
68. QAはシステムテストレベルを見たい！ • 単体テスト（モジュールテスト） ◦ 商品の個数欄にマイナスの数値を入力できない。 • 結合テスト ◦ カートに3個入っていて、2個追加したら、 確認ページで5個になった。 • システムテスト ◦ 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 QAチームは ここをやりたい！
69. QAはシステムテストレベルを見たい！ • 単体テスト（モジュールテスト） ◦ 商品の個数欄にマイナスの数値を入力できない。 • 結合テスト ◦ カートに3個入っていて、2個追加したら、 確認ページで5個になった。 • システムテスト ◦ 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 開発者は ここをやりきって！
70. QAはシステムテストレベルを見たい！ • 単体テスト（モジュールテスト） ◦ 商品の個数欄にマイナスの数値を入力できない。 • 結合テスト ◦ カートに3個入っていて、2個追加したら、 確認ページで5個になった。 • システムテスト ◦ 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 QAが担当せずに 開発者が全てやるのもあり
71. QAはTestingをしたい！ https://www.infoq.com/jp/news/2009/12/testing-or-checking
72. QAはTestingをしたい！ https://www.infoq.com/jp/news/2009/12/testing-or-checking Checking
 意図通り動くか確認する作業
 
 Testing
 なんとかして製品を破壊する作業
 TDDで書くテストは ほとんどchecking
73. QAチームはテスト以外も行いたい！ 私の 経験
74. QAチームはテスト以外も行いたい！ https://www.amazon.co.jp/dp/B07YR4CC4B
75. Agile Testing Condensedの例 • QA＝「Question Asker」という考え方 ◦ 誰も質問しないと思う質問を定期的に出す ◦ 自由回答形式の質問もする ▪ 隠れた仮定が明らかになる ▪ 質問例 • 実装しても問題解決できない 可能性はあるか？ • 機能の使用前にユーザーは何をするか？ • その後、ユーザーは何をするか？
76. QAチームはテスト以外も行いたい！ https://www.amazon.co.jp/dp/B00IE3B522/
77. GmailチームのTE(Test Engineer)の例 • 最初の数週間は話を聞くために費やし、 自分からは話しません。 • 私は最初の5分で抗生物質を処方する医者 のような人とは働きたくありません。 • 長年のうちに、もっとも強力な問いは 「なぜ？」だということを学びました。 話を聞く段階でもそこのところを聞きます。 （アンキットメータへのインタビューより）　　
78. QAチームはテスト以外も行いたい！ 私の 経験
79. 開発者に質問を投げかける 開発者に一番多く投げかける質問 • 「で、これで何をしたいんだっけ？」 • 「ごめん、ちゃんと理解できてないから、 この部分をもう一度説明してもらっていい？」
80. 開発者に質問を投げかける 開発者に一番多く投げかける質問 • 「で、これで何をしたいんだっけ？」 ◦ HowからWhatに立ち返ることができる • 「ごめん、ちゃんと理解できてないから、 この部分をもう一度説明してもらっていい？」 ◦ もっと詳しく説明してくれる ◦ 抜けてるパターンを開発者自身が気付ける
81. モブプロ体験会での出来事
82. モブプロ体験会のお題 • 題材は自動販売機 • Cucumber + JUnit • 与えられた要求は下記の3つ ◦ 100円硬貨を入れたら 入金額が100円になってほしい ◦ 100円硬貨を入れた後に50円硬貨を入れたら 入金額が150円になってほしい ◦ 1円硬貨は対応しないでほしい
83. モブプロ体験会の結果 Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている public class VendingMachine { int currentMoney = 0; public void insertCoin(int money) { if (money == 50 || money==100) { currentMoney += money; } } public int getCurrentMoney() { return currentMoney; } }
84. テストシナリオをさらに改善する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
85. テストシナリオをさらに改善する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている すべてシナリオ名が
 『入金額確認』になってますね。
 同じ名前はどうかと思うので
 変えたほうが良い気がしてます。
 なるほど。
 そしたらこんな感じですかね。
 （テストシナリオを編集する）

86. テストシナリオをさらに改善する Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている すべてシナリオ名が
 『入金額確認』になってますね。
 同じ名前はどうかと思うので
 変えたほうが良い気がしてます。
 なるほど。
 そしたらこんな感じですかね。
 （テストシナリオを編集する）

87. テストシナリオをさらに改善する Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている なるほど。ちなみに、
 2つ目のテストの意図って
 なんですかね？
 コインを1回だけではなく、
 2回投入した時にも
 ちゃんと動くか確認したい
 という意図です。

88. テストシナリオをさらに改善する Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている なるほどー。
 そしたら『2回投入時』と
 書いていますが、
 3回目はどうなるのでしょうか？
 3回目は2回目と同じく、
 加算されていく仕組みなので、
 ロジック上は大丈夫です。

89. テストシナリオをさらに改善する Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている ということは、気にしているのは
 2回投入の金額ではなく、
 複数回の投入時の加算
 なんですね。
 あー、確かにそうですね。
 （テストシナリオを編集する）

90. テストシナリオをさらに改善する Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている ということは、気にしているのは
 2回投入の金額ではなく、
 複数回の投入時の加算
 なんですね。
 あー、確かにそうですね。
 （テストシナリオを編集する）

91. 数年後、テストの意図が分かるのはどっち？ Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
92. 質問をすることで得られるメリット テストのメンテナンスコストの削減 顧客が本当に必要だったものが何か 立ち返る機会を持つ https://speakerdeck.com/twada/tdd-live-and-workshop- 2019-spring?slide=16 https://www.casleyconsulting.co.jp/blog/engineer/4334/
93. 質問をするテスト活動の事例 https://speakerdeck.com/nihonbuson/example-mapping https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity
94. シフトレフトのテスト活動 継続的テストモデル（改）
95. テストの勉強方法 （時間があれば） https://jp.freeimages.com/photo/reading-1420126
96. こんな質問が多い どうやってテストの勉強を すれば良いの？ テストの勉強ができる オススメの書籍が知りたい！
97. 「何をテストすべきか」でオススメの書籍 https://www.amazon.co.jp/dp/4297105063/ 2019/4/13 改訂版発売！
98. 「どうやってテストケースを作るのか」でオススメの書籍 https://www.amazon.co.jp/dp/4817193603 https://www.amazon.co.jp/dp/429711061X/
99. 「シフトレフトのテスト活動」でオススメの書籍 https://leanpub.com/agiletesting-condensed-japanese-edition
100. 最新のテスト情報収集ならJaSSTがオススメ！ • 日本最大級のテストのイベント ◦ JaSST'19 Tokyoは2日間で1600名が参加 • 年に10回、各地で開催 • 2018年から新たにJaSST Reviewも開催 ◦ 実行委員長は私 http://www.jasst.jp/
101. テストを実践して学ぶならWACATEがオススメ！ • 1泊2日のワークショップ形式のイベント • 2007年初開催 • 半年に1度開催（6月と12月） • 新卒1年目の開発・QAも多く参加 • 参加費は24,000円（35歳以上は27,000円） https://wacate.jp/
102. まとめ https://jp.freeimages.com/photo/bright-sky-1393231
103. まとめ • テストの目的は欠陥の検出以外に 欠陥の未然防止がある • テストには実装開始前に行う活動もある • 早期のテスト活動でコストを削減できる • テストすべき内容には、 仕様書に書かれていない内容や品質特性などがある • QAは様々なテスト活動を行いたい
104. おしまい https://jp.freeimages.com/photo/track-finish-1442273