Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テストエンジニアが教える 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

nihonbuson

May 18, 2019
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

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

    View Slide

  2. 自己紹介

    ブロッコリー
    ● @nihonbuson

    株式会社ビズリーチ

    JaSST Review 実行委員長

    WACATE 実行委員

    テストエンジニアによる
    合同誌『Crabink』著者

    View Slide

  3. Agenda

    はじめに

    テストの目的

    何をテストすべきか

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

    おわりに

    View Slide

  4. はじめに

    View Slide

  5. この発表は…

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

    本来話したい内容の1/15程度しかありません!

    もっと詳しく話を聞きたい方、
    今日参加してない人にも伝えたい方、
    講演後、気軽に話しかけてください!

    View Slide

  6. この発表は…

    話さない内容
    – JUnitの書き方
    – TDDのやり方
    – 自動テストの設計方法

    話す内容
    – テストの目的とは何か
    – テストファーストで行うことの本当の良さ
    – 何をテストすれば良いのか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    開発者はどんなことをすべきか

    View Slide

  11. テストの目的

    View Slide

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

    View Slide

  13. テストの目的は何か?
    以下のような目的があります。

    欠陥の検出

    対象ソフトウェアの品質レベルが十分であることの確認

    意思決定のための情報の提示

    欠陥の作りこみの防止
    JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14
    実装前に行うこともある
    テストの7原則①テストは「欠陥がある」ことしか示せない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 何をテストすべきか

    View Slide

  18. 次の仕様に対してどんなテストをすれば良いか。

    パスワードは4文字以上12文字以下の
    英数字のみを許容する

    パスワードを3分以内に4回以上間違って入力すると
    アカウントを5分間ロックする
    http://www.slideshare.net/takashiyamasaki378/ss-55384920
    例題

    View Slide

  19. ステップ1

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

    どこかにメモしてください。
    – 丁寧な字で!

    View Slide

  20. ステップ2

    隣の人と2人組を作ってください。

    お互いに何を書いたのか
    説明してください。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  27. 2つの伝えたいこと

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

    View Slide

  28. 2つの伝えたいこと

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

    この例では何もプログラムを書いていません。
    – 実装前にテストすることができる例です。
    – もしもこの時点で指摘できれば、
    総コストは削減できるでしょう。

    View Slide

  29. 再掲:テストの目的は何か?
    以下のような目的があります。

    欠陥の検出

    対象ソフトウェアの品質レベルが十分であることの確認

    意思決定のための情報の提示

    欠陥の作りこみの防止
    JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14
    実装前に行うこともある
    テストの7原則①テストは「欠陥がある」ことしか示せない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    配列 i[46] だが47を代入してしまった

    下までスクロールできなかった

    View Slide

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

    View Slide

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

    横浜市鶴見区…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. テスト設計技法 ~境界値分析~

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

    View Slide

  47. テスト設計技法 ~境界値分析~

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

    上記の例で、不等号のミスによる不具合を
    発見できるのは、3の時だけ!

    View Slide

  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%だけど…

    View Slide

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

    View Slide

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

    View Slide

  51. (ここまでの)まとめ

    View Slide

  52. まとめ

    テストの目的は欠陥の検出以外に
    欠陥の未然防止がある

    テストには実装開始前に行う活動もある

    早期にテストやレビューをすることで
    コストを削減できる

    全てを闇雲にテストすると膨大なケース数と時間
    が発生するが、その数を削減できる手法がある

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  56. 1. QAチームは
    システムテストレベルを見たい!

    単体テスト(モジュールテスト)
    – 商品の個数欄にマイナスの数値を入力できない。

    結合テスト
    – カートに3個入っていて、2個追加したら、
    確認ページで5個になった。

    システムテスト
    – 会員登録→商品購入→商品キャンセル→退会の
    一連の流れ。

    View Slide

  57. 1. QAチームは
    システムテストレベルを見たい!

    単体テスト(モジュールテスト)
    – 商品の個数欄にマイナスの数値を入力できない。

    結合テスト
    – カートに3個入っていて、2個追加したら、
    確認ページで5個になった。

    システムテスト
    – 会員登録→商品購入→商品キャンセル→退会の
    一連の流れ。
    QAチームは
    ここをやりたい!

    View Slide

  58. 1. QAチームは
    システムテストレベルを見たい!

    単体テスト(モジュールテスト)
    – 商品の個数欄にマイナスの数値を入力できない。

    結合テスト
    – カートに3個入っていて、2個追加したら、
    確認ページで5個になった。

    システムテスト
    – 会員登録→商品購入→商品キャンセル→退会の
    一連の流れ。
    開発者は
    ここをやりきれ!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. テストの勉強は「習うより慣れよ」

    1泊2日のワークショップ形式のイベント

    半年に1度開催(6月と12月)。

    10周年を迎えました!

    新卒1年目の開発・QAも多く参加

    参加費は24000円

    35歳以上は27000円

    ほとんどが宿泊費・経費で利益は無し
    https://wacate.jp

    View Slide

  73. 最新のテスト事情を知るには
    JaSSTがオススメ

    日本最大級のテストのイベント

    年に10回、各地で実施

    東京では毎年3月頃開催

    2日間でのべ1600人以上が参加

    昨年より、JaSST Reviewも新たに開催
    http://www.jasst.jp/
    昨年の講演者
    ・鈴木雄介さん
    ・及部敬雄さん
    など…

    View Slide

  74. もしも今回の話を
    同僚に伝えたい場合は…

    本来話したい内容の1/15程度しかありません!

    もっと詳しく話を聞きたい方、
    今日参加してない人にも伝えたい方、
    講演後、気軽に話しかけてください!

    View Slide

  75. おしまい

    View Slide

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

    View Slide

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

    View Slide