Slide 1

Slide 1 text

テストエンジニアが教える JUnitを書き始める前に 考えるべきテスト (JJUG CCC 2019 Spring) ブロッコリー

Slide 2

Slide 2 text

自己紹介 ● ブロッコリー ● @nihonbuson ● 株式会社ビズリーチ ● JaSST Review 実行委員長 ● WACATE 実行委員 ● テストエンジニアによる 合同誌『Crabink』著者

Slide 3

Slide 3 text

Agenda ● はじめに ● テストの目的 ● 何をテストすべきか ● どうやってテストケースを作るのか ● おわりに

Slide 4

Slide 4 text

はじめに

Slide 5

Slide 5 text

この発表は… ● テストの話にかける時間数 – 社内の新人研修…丸2日 – 社外の勉強会…2時間弱 – JJUG…45分 ● 本来話したい内容の1/15程度しかありません! ● もっと詳しく話を聞きたい方、 今日参加してない人にも伝えたい方、 講演後、気軽に話しかけてください!

Slide 6

Slide 6 text

この発表は… ● 話さない内容 – JUnitの書き方 – TDDのやり方 – 自動テストの設計方法 ● 話す内容 – テストの目的とは何か – テストファーストで行うことの本当の良さ – 何をテストすれば良いのか

Slide 7

Slide 7 text

こんな経験していませんか? 開発はできたけど、 テストをどうやれば良いのか 分からないよ…。 リリースしてから トラブルがいっぱい 起きるなぁ…

Slide 8

Slide 8 text

こんな経験していませんか? 開発はできたけど、 テストをどうやれば良いのか 分からないよ…。 リリースしてから トラブルがいっぱい 起きるなぁ… 品質やテストのことを学べば 解決できるかもしれない!

Slide 9

Slide 9 text

今日話す内容は… QAチームはどうしていくべきか

Slide 10

Slide 10 text

今日話す内容は… QAチームはどうしていくべきか ↓ 開発者はどんなことをすべきか

Slide 11

Slide 11 text

テストの目的

Slide 12

Slide 12 text

テストの目的は何か?

Slide 13

Slide 13 text

テストの目的は何か? 以下のような目的があります。 ● 欠陥の検出 ● 対象ソフトウェアの品質レベルが十分であることの確認 ● 意思決定のための情報の提示 ● 欠陥の作りこみの防止 JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない

Slide 14

Slide 14 text

なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍 200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト

Slide 15

Slide 15 text

なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍 200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト 修正コストを下げるには…(1) 素早くリリースしてフィードバックをもらい、 すぐに修正できる体制にする

Slide 16

Slide 16 text

なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍 200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト 修正コストを下げるには…(2) 早い段階で不具合を発見する

Slide 17

Slide 17 text

何をテストすべきか

Slide 18

Slide 18 text

次の仕様に対してどんなテストをすれば良いか。 ● パスワードは4文字以上12文字以下の 英数字のみを許容する ● パスワードを3分以内に4回以上間違って入力すると アカウントを5分間ロックする http://www.slideshare.net/takashiyamasaki378/ss-55384920 例題

Slide 19

Slide 19 text

ステップ1 ● 例題について考えてみてください。 – テスト条件 – 何をテストしたいか – どんなところが気になるか ● どこかにメモしてください。 – 丁寧な字で!

Slide 20

Slide 20 text

ステップ2 ● 隣の人と2人組を作ってください。 ● お互いに何を書いたのか 説明してください。

Slide 21

Slide 21 text

パスワードは4文字以上12文字以下の 英数字のみを許容する パスワードを3分以内に4回以上間違って入力すると アカウントを5分間 ロックする 文字列長 文字種 誤入力 期間管理 誤入力 回数管理 ロック保持期間 状態遷移

Slide 22

Slide 22 text

パスワードは4文字以上12文字以下の 英数字のみを許容する パスワードを3分以内に4回以上間違って入力すると アカウントを5分間 ロックする 文字列長 文字種 誤入力 期間管理 誤入力 回数管理 ロック保持期間 状態遷移 許容しないとどうなる? (ボタン制御orエラー画面) 5回目の入力はどうなる?

Slide 23

Slide 23 text

設計・開発時点 Bさんはエラー画面を 作ってくれるだろう。 Aさんはエラーを ボタン制御でやるだろう。 Aさん Bさん

Slide 24

Slide 24 text

Bさん テスト時点 なんでエラー画面を 作っていないの? 私はボタン制御で エラー管理をしていると 思っていたよ! Aさん

Slide 25

Slide 25 text

Mr.A Bさん テスト時点 なんでエラー画面を 作っていないの? 私はボタン制御で エラー管理をしていると 思っていたよ! 追加コストが発生!

Slide 26

Slide 26 text

パスワードは4文字以上12文字以下の 英数字のみを許容する パスワードを3分以内に4回以上間違って入力すると アカウントを5分間 ロックする 文字列長 文字種 誤入力 期間管理 誤入力 回数管理 ロック保持期間 状態遷移 許容しないとどうなる? (ボタン制御orエラー画面) 5回目の入力はどうなる?

Slide 27

Slide 27 text

2つの伝えたいこと ● 隣の人はあなたが気付かなかったことを知って いませんでしたか? – お互いにテスト内容についても議論しましょう。 ●

Slide 28

Slide 28 text

2つの伝えたいこと ● 隣の人はあなたが気付かなかったことを知って いませんでしたか? – お互いにテスト内容についても議論しましょう。 ● この例では何もプログラムを書いていません。 – 実装前にテストすることができる例です。 – もしもこの時点で指摘できれば、 総コストは削減できるでしょう。

Slide 29

Slide 29 text

再掲:テストの目的は何か? 以下のような目的があります。 ● 欠陥の検出 ● 対象ソフトウェアの品質レベルが十分であることの確認 ● 意思決定のための情報の提示 ● 欠陥の作りこみの防止 JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない

Slide 30

Slide 30 text

再掲:なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍 200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト 修正コストを下げるには…(2) 早い段階で不具合を発見する

Slide 31

Slide 31 text

パスワードは4文字以上12文字以下の 英数字のみを許容する パスワードを3分以内に4回以上間違って入力すると アカウントを5分間ロックする もしもドキュメントが無かったら… どのようなテストを行えば良いか分からなくなります

Slide 32

Slide 32 text

どうやって テストケースを作るのか

Slide 33

Slide 33 text

何個の選択肢をテストする? 都道府県の項目についてテストする場合、 どんな値を使ってテストしますか? 何個の選択肢をテストしますか?

Slide 34

Slide 34 text

テストケース作成者「○○○のテストをします!」 司会者「ほぉ~、それはどうしてだい?」 テストケース作成者「【理由を一言】」 テストケース作成の心得

Slide 35

Slide 35 text

答え (1) プルダウンの一番上と一番下の値を使う (北海道と沖縄県) →最後の項目まで動くか確認したい場合、 両端の値をテストすべき 特に、一番最後の値は重要 ● 配列 i[46] だが47を代入してしまった ● 下までスクロールできなかった

Slide 36

Slide 36 text

答え (2) 都・道・府・県の4つを使う (東京都、北海道、大阪府、神奈川県) →以下のように、印刷物に丸印を反映させる場合  都・道・府・県それぞれの値でテストすべき 東京     渋谷区渋谷2丁目… 都 道 府 県

Slide 37

Slide 37 text

答え (3) 文字数が3文字と4文字の選択肢を使う (東京都、神奈川県) →以下の確認画面のように、 文字数による崩れを見つけたい場合、 文字数の違う値でテストすべき 都道府県 住所 神奈川 県 横浜市鶴見区…

Slide 38

Slide 38 text

答え (4) 各地域の選択肢を使う →以下のように、地域によって条件が異なる場合 (配送料など)、価格ごとにテストすべき http://www.noriya3.com/new/2017-09-21-094818.html

Slide 39

Slide 39 text

答え (5) すべての選択肢を行う →以下のように、case文で分岐している場合、 すべての選択肢をテストすべき switch(area){ case “北海道”: // 何らかの処理 break; case “青森県”: // 何らかの処理 break; …

Slide 40

Slide 40 text

テストケース名に役立つ @Test public void _青森県の場合{ } @Test public void _広島県の場合{ }

Slide 41

Slide 41 text

テストケース名に役立つ @Test public void _青森県の場合{ } @Test public void _広島県の場合{ } 他の45都道府県も 行うべきなのか…?

Slide 42

Slide 42 text

テストケース名に役立つ @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); }

Slide 43

Slide 43 text

テストケースはいくつ? パスワードは4文字以上12文字以下 1文字、2文字、3文字…100文字 膨大な数の テストケース テストの7原則②全数テストは不可能

Slide 44

Slide 44 text

テストケースはいくつ? ● テストケースは時間があれば無限にできる。 ● サンプリング方法としてテスト設計技法がある。 – テストケースを合理的に少なくするための技法 ● 同値分割法、AllPair法 – 多くの欠陥が見つかるようにするための技法 ● 境界値分析、エラー推測、探索的テスト – テスト対象をある観点で漏れなくテストするための技法 ● カバレッジ、デシジョンテーブル、状態遷移、ユースケーステスト

Slide 45

Slide 45 text

テスト設計技法 ~境界値分析~ テストの7原則④欠陥の偏在 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下

Slide 46

Slide 46 text

テスト設計技法 ~境界値分析~ ● 「パスワードが4文字以上12文字以下」で なぜ3,4,12,13をテストするのか? if( x < 3 ){ return “入力したパスワードが短いです”; } …

Slide 47

Slide 47 text

テスト設計技法 ~境界値分析~ ● 「パスワードが4文字以上12文字以下」で なぜ3,4,12,13をテストするのか? if( x < 3 ){ return “入力したパスワードが短いです”; } … ● 上記の例で、不等号のミスによる不具合を 発見できるのは、3の時だけ!

Slide 48

Slide 48 text

テスト設計技法 ~境界値分析~ public boolean judge (int x) { if( x < 3 ){ return false; } else if( x > 13 ){ return false; } return true; } @Test public void test_1{ assertThat( judge(2), is(false)); } @Test public void test_2{ assertThat( judge(15), is(false)); } @Test public void test_3{ assertThat( judge(7), is(true)); } カバレッジは100%だけど…

Slide 49

Slide 49 text

テスト設計技法 ~境界値分析~ 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下 テストの7原則④欠陥の偏在

Slide 50

Slide 50 text

テスト設計技法 ~境界値分析~ 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下 0 テストの7原則④欠陥の偏在

Slide 51

Slide 51 text

(ここまでの)まとめ

Slide 52

Slide 52 text

まとめ ● テストの目的は欠陥の検出以外に 欠陥の未然防止がある ● テストには実装開始前に行う活動もある ● 早期にテストやレビューをすることで コストを削減できる ● 全てを闇雲にテストすると膨大なケース数と時間 が発生するが、その数を削減できる手法がある

Slide 53

Slide 53 text

おまけ (講座中にあった質問)

Slide 54

Slide 54 text

QAチームは何をするの? これだけテストが充実できればQAチームは 必要ないのでは?

Slide 55

Slide 55 text

QAチームは何をするの? これだけテストが充実できればQAチームは 必要ないのでは? ⇒まだまだ必要なことが多いです。 テストエンジニアは 1. システムテストレベルを確認したい! 2. CheckingではなくTestingを行いたい

Slide 56

Slide 56 text

1. QAチームは システムテストレベルを見たい! ● 単体テスト(モジュールテスト) – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、 確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。

Slide 57

Slide 57 text

1. QAチームは システムテストレベルを見たい! ● 単体テスト(モジュールテスト) – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、 確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 QAチームは ここをやりたい!

Slide 58

Slide 58 text

1. QAチームは システムテストレベルを見たい! ● 単体テスト(モジュールテスト) – 商品の個数欄にマイナスの数値を入力できない。 ● 結合テスト – カートに3個入っていて、2個追加したら、 確認ページで5個になった。 ● システムテスト – 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 開発者は ここをやりきれ!

Slide 59

Slide 59 text

2. QAチームはTestingをしたい! http://www.satisfice.com/blog/archives/856

Slide 60

Slide 60 text

2. QAチームはTestingをしたい! https://www.infoq.com/jp/news/2009/12/testing-or-checking

Slide 61

Slide 61 text

2. QAチームはTestingをしたい! https://www.infoq.com/jp/news/2009/12/testing-or-checking Checking 意図通り動くか確認する作業 Testing なんとかして製品を破壊する作業

Slide 62

Slide 62 text

QAチームは何をするの? http://www.jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf#page=29

Slide 63

Slide 63 text

(ブラウザ)自動テストについて 何でも自動テストにすれば良いんじゃない? (テストの工数が0になるのでは?)

Slide 64

Slide 64 text

(ブラウザ)自動テストについて 何でも自動テストにすれば良いんじゃない? (テストの工数が0になるのでは?) https://www.thoughtworks.com/insights/blog/qa-dead 自動テストは Checkingの 自動化

Slide 65

Slide 65 text

(ブラウザ)自動テストについて 何でも自動テストにすれば良いんじゃない? (テストの工数が0になるのでは?) 1. 手動でおこなって効果のないテストを   自動化しても無駄である  (テスト自動化の8原則②) 2. 自動テストはテスト結果分析というコストが発生する  (テスト自動化の8原則⑧) なので「自動テストが出来れば工数が0になる」 ということはありません。

Slide 66

Slide 66 text

(ブラウザ)自動テストについて 自動テストはどんな内容が適しているの?

Slide 67

Slide 67 text

(ブラウザ)自動テストについて 自動テストはどんな内容が適しているの? http://jasst.jp/symposium/jasst16tokyo/pdf/D4.pdf#page=5

Slide 68

Slide 68 text

テストの勉強方法を知りたい どうやってテストの勉強を すれば良いの? テストの勉強ができる オススメの書籍が知りたい!

Slide 69

Slide 69 text

テストの勉強でオススメの書籍 (入門者向け) https://www.amazon.co.jp/dp/4297105063/ https://www.amazon.co.jp/dp/4817193603 5/13 改訂版発売!

Slide 70

Slide 70 text

テストの勉強でオススメの書籍 (自動テスト、入門者向け) https://www.amazon.co.jp/dp/4873118166/ 画面上の自動テストの開発に関わらない人も、 第1章と第8章を読むべき

Slide 71

Slide 71 text

テストの勉強でオススメの書籍 (中級者向け) https://www.amazon.co.jp/dp/4798124699 テストとはどうあるべきかが分かる本 資格勉強用の本だが、資格を取らなくても勉強になる

Slide 72

Slide 72 text

テストの勉強は「習うより慣れよ」 ● 1泊2日のワークショップ形式のイベント ● 半年に1度開催(6月と12月)。 ● 10周年を迎えました! ● 新卒1年目の開発・QAも多く参加 ● 参加費は24000円 ● 35歳以上は27000円 ● ほとんどが宿泊費・経費で利益は無し https://wacate.jp

Slide 73

Slide 73 text

最新のテスト事情を知るには JaSSTがオススメ ● 日本最大級のテストのイベント ● 年に10回、各地で実施 ● 東京では毎年3月頃開催 ● 2日間でのべ1600人以上が参加 ● 昨年より、JaSST Reviewも新たに開催 http://www.jasst.jp/ 昨年の講演者 ・鈴木雄介さん ・及部敬雄さん など…

Slide 74

Slide 74 text

もしも今回の話を 同僚に伝えたい場合は… ● 本来話したい内容の1/15程度しかありません! ● もっと詳しく話を聞きたい方、 今日参加してない人にも伝えたい方、 講演後、気軽に話しかけてください!

Slide 75

Slide 75 text

おしまい

Slide 76

Slide 76 text

参考資料1 テストの7原則 ①テストは「欠陥がある」ことしか示せない ②全数テストは不可能 ③初期テスト ④欠陥の偏在 ⑤殺虫剤のパラドックス ⑥テストは条件次第 ⑦「バグゼロ」の落とし穴 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=15

Slide 77

Slide 77 text

参考資料2 テスト自動化の8原則 ①手動テストはなくならない ②手動で行って効果の無いテストを自動化しても無駄である ③自動テストは書いたことしかテストしない ④テスト自動化の効用はコスト削減だけではない ⑤自動テストシステムの開発は継続的に行うものである ⑥自動化検討はプロジェクト初期から ⑦自動テストで新種のバグが見つかることは稀である ⑧テスト結果分析という新たなタスクが生まれる https://sites.google.com/site/testautomationresearch/test_automation_principle