テストエンジニアが教える JUnitを書き始める前に考えるべきテスト/JJUG_CCC_2019_Spring

テストエンジニアが教える JUnitを書き始める前に考えるべきテスト/JJUG_CCC_2019_Spring

以下のイベントの投影資料です。
http://www.java-users.jp/ccc2019spring/#/

以下、スライド内記載のURL一覧

P13 テストの目的
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14

P18 パスワードの例題
https://www.slideshare.net/takashiyamasaki378/ss-55384920/25

P59 Testing and Checking Refined
http://www.satisfice.com/blog/archives/856

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

P62 開発工程と不良摘出
http://www.jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf#page=29

P64 Checking is not Testing
https://www.thoughtworks.com/insights/blog/qa-dead

P67 最初に行うべき自動テストの内容
http://jasst.jp/symposium/jasst16tokyo/pdf/D4.pdf#page=5

P69 入門者向けオススメ書籍
マインドマップから始めるソフトウェアテスト https://www.amazon.co.jp/dp/4297105063
ソフトウェアテスト技法ドリル https://www.amazon.co.jp/dp/4817193603

P70 初めての自動テスト
https://www.amazon.co.jp/dp/4873118166/

P71 ソフトウェアテスト教科書 JSTQB Foundation
https://www.amazon.co.jp/dp/4798124699

P72 WACATE
https://wacate.jp/

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

P76 ソフトウェアテストの7原則
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=15

P77 テスト自動化の8原則
https://sites.google.com/site/testautomationresearch/test_automation_principle

706ff501573a736401aa4de5adc88e05?s=128

nihonbuson

May 18, 2019
Tweet

Transcript

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

  2. 自己紹介 • ブロッコリー • @nihonbuson • 株式会社ビズリーチ • JaSST Review

    実行委員長 • WACATE 実行委員 • テストエンジニアによる 合同誌『Crabink』著者
  3. Agenda • はじめに • テストの目的 • 何をテストすべきか • どうやってテストケースを作るのか •

    おわりに
  4. はじめに

  5. この発表は… • テストの話にかける時間数 – 社内の新人研修…丸2日 – 社外の勉強会…2時間弱 – JJUG…45分 •

    本来話したい内容の1/15程度しかありません! • もっと詳しく話を聞きたい方、 今日参加してない人にも伝えたい方、 講演後、気軽に話しかけてください!
  6. この発表は… • 話さない内容 – JUnitの書き方 – TDDのやり方 – 自動テストの設計方法 •

    話す内容 – テストの目的とは何か – テストファーストで行うことの本当の良さ – 何をテストすれば良いのか
  7. こんな経験していませんか? 開発はできたけど、 テストをどうやれば良いのか 分からないよ…。 リリースしてから トラブルがいっぱい 起きるなぁ…

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

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

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

  11. テストの目的

  12. テストの目的は何か?

  13. テストの目的は何か? 以下のような目的があります。 • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分であることの確認 • 意思決定のための情報の提示 • 欠陥の作りこみの防止

    JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない
  14. なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍

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

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

    200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト 修正コストを下げるには…(2) 早い段階で不具合を発見する
  17. 何をテストすべきか

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

  19. ステップ1 • 例題について考えてみてください。 – テスト条件 – 何をテストしたいか – どんなところが気になるか •

    どこかにメモしてください。 – 丁寧な字で!
  20. ステップ2 • 隣の人と2人組を作ってください。 • お互いに何を書いたのか 説明してください。

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

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

    ロック保持期間 状態遷移 許容しないとどうなる? (ボタン制御orエラー画面) 5回目の入力はどうなる?
  23. 設計・開発時点 Bさんはエラー画面を 作ってくれるだろう。 Aさんはエラーを ボタン制御でやるだろう。 Aさん Bさん

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

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

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

    ロック保持期間 状態遷移 許容しないとどうなる? (ボタン制御orエラー画面) 5回目の入力はどうなる?
  27. 2つの伝えたいこと • 隣の人はあなたが気付かなかったことを知って いませんでしたか? – お互いにテスト内容についても議論しましょう。 •

  28. 2つの伝えたいこと • 隣の人はあなたが気付かなかったことを知って いませんでしたか? – お互いにテスト内容についても議論しましょう。 • この例では何もプログラムを書いていません。 – 実装前にテストすることができる例です。

    – もしもこの時点で指摘できれば、 総コストは削減できるでしょう。
  29. 再掲:テストの目的は何か? 以下のような目的があります。 • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分であることの確認 • 意思決定のための情報の提示 • 欠陥の作りこみの防止

    JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 実装前に行うこともある テストの7原則①テストは「欠陥がある」ことしか示せない
  30. 再掲:なぜ早期のテスト・レビューをするのか 要求仕様 設計 コーディング テスト リリース後 1倍 5倍 10倍 20倍

    200倍! 出典:『ソフトウェア開発201の鉄則(日経BP社)』 仕様誤りの修正コスト 修正コストを下げるには…(2) 早い段階で不具合を発見する
  31. パスワードは4文字以上12文字以下の 英数字のみを許容する パスワードを3分以内に4回以上間違って入力すると アカウントを5分間ロックする もしもドキュメントが無かったら… どのようなテストを行えば良いか分からなくなります

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

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

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

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

    だが47を代入してしまった • 下までスクロールできなかった
  36. 答え (2) 都・道・府・県の4つを使う (東京都、北海道、大阪府、神奈川県) →以下のように、印刷物に丸印を反映させる場合  都・道・府・県それぞれの値でテストすべき 東京     渋谷区渋谷2丁目… 都 道 府 県

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

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

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

    break; case “青森県”: // 何らかの処理 break; …
  40. テストケース名に役立つ @Test public void _青森県の場合{ } @Test public void _広島県の場合{

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

    } 他の45都道府県も 行うべきなのか…?
  42. テストケース名に役立つ @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public

    void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); }
  43. テストケースはいくつ? パスワードは4文字以上12文字以下 1文字、2文字、3文字…100文字 膨大な数の テストケース テストの7原則②全数テストは不可能

  44. テストケースはいくつ? • テストケースは時間があれば無限にできる。 • サンプリング方法としてテスト設計技法がある。 – テストケースを合理的に少なくするための技法 • 同値分割法、AllPair法 –

    多くの欠陥が見つかるようにするための技法 • 境界値分析、エラー推測、探索的テスト – テスト対象をある観点で漏れなくテストするための技法 • カバレッジ、デシジョンテーブル、状態遷移、ユースケーステスト
  45. テスト設計技法 ~境界値分析~ テストの7原則④欠陥の偏在 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下

  46. テスト設計技法 ~境界値分析~ • 「パスワードが4文字以上12文字以下」で なぜ3,4,12,13をテストするのか? if( x < 3 ){ return

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

    “入力したパスワードが短いです”; } … • 上記の例で、不等号のミスによる不具合を 発見できるのは、3の時だけ!
  48. テスト設計技法 ~境界値分析~ 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%だけど…
  49. テスト設計技法 ~境界値分析~ 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下 テストの7原則④欠陥の偏在

  50. テスト設計技法 ~境界値分析~ 12 4 有効 無効 無効 3 13 パスワードは4文字以上12文字以下 0

    テストの7原則④欠陥の偏在
  51. (ここまでの)まとめ

  52. まとめ • テストの目的は欠陥の検出以外に 欠陥の未然防止がある • テストには実装開始前に行う活動もある • 早期にテストやレビューをすることで コストを削減できる •

    全てを闇雲にテストすると膨大なケース数と時間 が発生するが、その数を削減できる手法がある
  53. おまけ (講座中にあった質問)

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

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

  56. 1. QAチームは システムテストレベルを見たい! • 単体テスト(モジュールテスト) – 商品の個数欄にマイナスの数値を入力できない。 • 結合テスト –

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

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

    カートに3個入っていて、2個追加したら、 確認ページで5個になった。 • システムテスト – 会員登録→商品購入→商品キャンセル→退会の 一連の流れ。 開発者は ここをやりきれ!
  59. 2. QAチームはTestingをしたい! http://www.satisfice.com/blog/archives/856

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

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

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

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

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

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

    なので「自動テストが出来れば工数が0になる」 ということはありません。
  66. (ブラウザ)自動テストについて 自動テストはどんな内容が適しているの?

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

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

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

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

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

  72. テストの勉強は「習うより慣れよ」 • 1泊2日のワークショップ形式のイベント • 半年に1度開催(6月と12月)。 • 10周年を迎えました! • 新卒1年目の開発・QAも多く参加 •

    参加費は24000円 • 35歳以上は27000円 • ほとんどが宿泊費・経費で利益は無し https://wacate.jp
  73. 最新のテスト事情を知るには JaSSTがオススメ • 日本最大級のテストのイベント • 年に10回、各地で実施 • 東京では毎年3月頃開催 • 2日間でのべ1600人以上が参加

    • 昨年より、JaSST Reviewも新たに開催 http://www.jasst.jp/ 昨年の講演者 ・鈴木雄介さん ・及部敬雄さん など…
  74. もしも今回の話を 同僚に伝えたい場合は… • 本来話したい内容の1/15程度しかありません! • もっと詳しく話を聞きたい方、 今日参加してない人にも伝えたい方、 講演後、気軽に話しかけてください!

  75. おしまい

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

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