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

テストコードを書き始める前に考えるべきテストの話 #DevSumi / Developers_Summit_2020

nihonbuson
February 13, 2020

テストコードを書き始める前に考えるべきテストの話 #DevSumi / Developers_Summit_2020

以下のイベントの投影資料です。
https://event.shoeisha.jp/devsumi/20200213/session/2364/

発表時の諸注意など
http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000

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

【発表資料中のURL】

P2 Agile Testing Fellow
https://agiletestingfellow.com/

P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf

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

P48 テスト設計チュートリアル U-30クラス向け 2020年度版
http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65

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

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

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

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

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

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

P103 WACATE
https://wacate.jp/

P106 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf

nihonbuson

February 13, 2020
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. テストコードを
    書き始める前に
    考えるべきテストの話
    ブロッコリー( @nihonbuson )
    https://www.pexels.com/photo/man-wearing-black-and-white-stripe-shirt-looking-at-white-printer-papers-on-the-wall-212286/

    View Slide

  2. 自己紹介
    ● 株式会社ビズリーチ
    ○ QA基盤推進室
    ○ QA Evangelistチーム
    ● 社外活動
    ○ WACATE実行委員
    ○ JaSST Review 実行委員長
    ○ ASTER正会員
    ○ Agile Testing Fellow会員
    ■ https://agiletestingfellow.com/
    ↓Twitterアイコン
    風間 裕也(@nihonbuson)

    View Slide

  3. アジェンダ
    はじめに
    テストの目的
    何をテストすべきか
    どうやってテストケースを作るのか
    どうやって「ともにつくる」のか
    おまけ

    View Slide

  4. はじめに
    https://www.pexels.com/photo/young-game-match-kids-2923/

    View Slide

  5. この発表の注意事項
    ● テストの話にかける時間数
    ○ 社内の新人研修…丸2日
    ○ デブサミ …45分
    ● 本来話したい内容の1/15程度しかありません!
    ● もっと詳しく話を聞きたい方、
    今日参加してない人にも伝えたい方、
    講演後、お気軽に話しかけてください!

    View Slide

  6. この発表の注意事項
    ● 話さない内容
    ○ テストコードの書き方
    ○ TDDのやり方
    ○ 自動テストの設計方法
    ● 話す内容
    ○ テストの目的とは何か
    ○ テストファーストで行うことの本当の良さ
    ○ 何をテストすれば良いのか

    View Slide

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

    View Slide

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

    View Slide

  9. 今日話す内容は…
    QA(Quality Assurance=品質保証)
    チームはどういう動きをするか

    View Slide

  10. 今日話す内容は…
    QA(Quality Assurance=品質保証)
    チームはどういう動きをするか

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

    View Slide

  11. アンケート

    View Slide

  12. View Slide

  13. View Slide

  14. テストの目的
    https://jp.freeimages.com/photo/on-target-1504936

    View Slide

  15. テストの目的とは何か?
    欠陥の検出
    対象ソフトウェアの品質レベルが十分であることの確認
    意思決定のための情報の提示
    欠陥の作り込みの防止
    実装前に行うこともある
    ISTQBテスト技術者資格制度
    Foundation Level シラバス 日本語版
    Version 2011.J02より
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
    TDDでの検知、リリース判断、ユーザーの利用判断など…
    テストの7原則①テストは「⽋陥がある」ことしか⽰せない

    View Slide

  16. なぜ実装前にテスト・レビューをするのか
    仕様誤りの修正コスト
    要求仕様 設計 実装 テスト リリース後
    1倍
    5倍
    10倍
    20倍
    200倍!
    出典: Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社

    View Slide

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

    View Slide

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

    View Slide

  19. 何をテストすべき

    https://jp.freeimages.com/photo/target-1306247

    View Slide

  20. 例題
    ● パスワードは4文字以上12文字以下の
    英数字のみを許容する。
    ● パスワードを3分以内に4回以上
    間違って入力すると、
    アカウントを5分間ロックする。
    http://www.slideshare.net/takashiyamasaki378/ss-55384920 https://www.pexels.com/photo/man-in-brown-shirt-writing-on-
    notebook-3202028/

    View Slide

  21. 例題
    http://www.slideshare.net/takashiyamasaki378/ss-55384920
    あなたが考えた
    ● テスト内容
    ● 気になった内容
    ● 起こりそうなバグ
    をどこかにメモして
    ください。
    ● パスワードは4文字以上12文字以下の
    英数字のみを許容する。
    ● パスワードを3分以内に4回以上
    間違って入力すると、
    アカウントを5分間ロックする。
    https://www.pexels.com/photo/man-in-brown-shirt-writing-on-
    notebook-3202028/

    View Slide

  22. 例題
    ● 2人組を作ってください。
    ● お互いに何を書いたのか
    説明してください。
    https://www.pexels.com/photo/man-working-on-laptop-while-woman-takes-notes-3153199/

    View Slide

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

    View Slide

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

    View Slide

  25. 設計・開発時点

    View Slide

  26. テスト時点

    View Slide

  27. テスト時点
    追加コストが発生!

    View Slide

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

    View Slide

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

    View Slide

  30. 伝えたいこと
    ● 隣の人はあなたが気づかなかったことを
    知っていませんでしたか?
    ○ お互いにテスト内容についても議論しましょう!
    ● この例では1文字もプログラムを書いていません!
    ○ 実装前にテストすることができる例です。
    ○ もしもこの時点で指摘できれば
    総コストは削減できるでしょう。
    ■ 今回の場合、「許容する」をこの時点で
    話し合うと、ほぼ不具合が発生しません。

    View Slide

  31. テストの目的とは何か?(再掲)
    欠陥の検出
    対象ソフトウェアの品質レベルが十分であることの確認
    意思決定のための情報の提示
    欠陥の作り込みの防止
    実装前に行うこともある
    ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14
    TDDでの検知、リリース判断、ユーザーの利用判断など…

    View Slide

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

    View Slide

  33. どうやって
    テストケースを
    作るのか
    https://jp.freeimages.com/photo/check-list-1150080

    View Slide

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

    View Slide

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

    View Slide

  36. 境界値分析で考える
    12
    4
    有効
    無効 無効
    3 13

    View Slide

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

    View Slide

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

    View Slide

  39. カバレッジは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));
    }

    View Slide

  40. カバレッジは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));
    }

    View Slide

  41. カバレッジは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));
    }

    View Slide

  42. カバレッジは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));
    }

    View Slide

  43. カバレッジは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));
    }

    View Slide

  44. 欠陥は局所的に発生する
    テストの7原則④欠陥の偏在
    12
    4
    有効
    無効 無効
    3 13

    View Slide

  45. もう1箇所テストできるならば…
    テストの7原則④欠陥の偏在
    12
    4
    有効
    無効 無効
    3 13

    View Slide

  46. 0文字はnull処理などの可能性がある
    テストの7原則④欠陥の偏在
    12
    4
    有効
    無効 無効
    3 13
    0

    View Slide

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

    View Slide

  48. テスト実施の前にも段階的に行う内容がある
    http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65

    View Slide

  49. テスト実施の前にも段階的に行う内容がある
    http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65
    パスワードの例題

    View Slide

  50. テスト実施の前にも段階的に行う内容がある
    http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65
    境界値分析の例

    View Slide

  51. どうやって
    「ともにつくる」のか
    https://www.pexels.com/photo/woman-in-black-coat-1181346/

    View Slide

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

    View Slide

  53. QAチームは何をするの?
    これだけテストが充実できれば
    QAチームは必要ないのでは?
    →まだまだ必要なことが多いです。QAは
    1. システムテストレベルを見たい!
    2. CheckingではなくTestingを行いたい!
    3. テスト以外も行いたい!
    ※QAチームが無い場合、誰かor全員が担うべき

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  59. QAチームはテスト以外も行いたい!
    私の
    経験

    View Slide

  60. QAチームはテスト以外も行いたい!

    View Slide

  61. Agile Testing Condensedの例
    QA=「Question Asker」という考え方
    ● 誰も質問しないと思う質問を定期的に出す
    ● 自由回答形式の質問もする
    ○ 隠れた仮定が明らかになる
    ○ 質問例
    ■ 実装しても問題解決できない可能性はあるか?
    ■ この機能の使用前にユーザーは何をするか?
    ■ その後、ユーザーは何をするか?

    View Slide

  62. QAチームはテスト以外も行いたい!

    View Slide

  63. GmailチームのTE(Test Engineer)の例
    ● 最初の数週間は話を聞くために費やし、
    自分からは話しません。
    ● 私は最初の5分で抗生物質を処方する医者
    のような人とは働きたくありません。
    ● 長年のうちに、もっとも強力な問いは
    「なぜ?」だということを学びました。
    話を聞く段階でもそこのところを聞きます。
    (アンキットメータへのインタビューより)

    View Slide

  64. QAチームはテスト以外も行いたい!
    私の
    経験

    View Slide

  65. 開発者とどのように「ともにつくる」のか
    開発者に一番多く投げかける質問
    ● 「で、これで何をしたいんだっけ?」
    ● 「ごめん、ちゃんと理解できてないから、
    この部分をもう一度説明してもらっていい?」

    View Slide

  66. 開発者とどのように「ともにつくる」のか
    開発者に一番多く投げかける質問
    ● 「で、これで何をしたいんだっけ?」
    ○ HowからWhatに立ち返ることができる
    ● 「ごめん、ちゃんと理解できてないから、
    この部分をもう一度説明してもらっていい?」
    ○ もっと詳しく説明してくれる
    ○ 抜けてるパターンを開発者自身が気付ける

    View Slide

  67. 「ともにつくる」を実現した例

    View Slide

  68. モブプロ体験会のお題
    ● 題材は自動販売機
    ● Cucumber + JUnit
    ● 与えられた要求は下記の3つ
    ○ 100円硬貨を入れたら
    入金額が100円になってほしい
    ○ 100円硬貨を入れた後に50円硬貨を入れたら
    入金額が150円になってほしい
    ○ 1円硬貨は対応しないでほしい

    View Slide

  69. モブプロ体験会の結果
    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;
    }
    }

    View Slide

  70. テストシナリオをさらに改善する
    Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている
    Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている
    Scenario: 入金額確認
    Given 自動販売機がある
    When 1円を入金
    Then 0円が入金されている

    View Slide

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

    View Slide

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

    View Slide

  73. テストシナリオをさらに改善する
    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回投⼊した時にも
    ちゃんと動くか確認したい
    という意図です。

    View Slide

  74. テストシナリオをさらに改善する
    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回⽬と同じく、
    加算されていく仕組みなので、
    ロジック上は⼤丈夫です。

    View Slide

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

    View Slide

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

    View Slide

  77. 数年後、テストの意図が分かるのはどっち?
    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円が入金されている

    View Slide

  78. テストコードのメンテナンスコストを低減する

    View Slide

  79. 「ともにつくる」の
    追加の例
    (時間が残っていれば)
    https://jp.freeimages.com/photo/reading-1420126

    View Slide

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

    View Slide

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

    View Slide

  82. 答え(その1)
    プルダウンの一番下の値を使う(沖縄県)
    →最後の項目まで動くか確認したいから

    View Slide

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

    View Slide

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

    View Slide

  85. 答え(その4)
    各地域の選択肢を使う
    →例えば地域によって価格が異なる場合、
    価格ごとにテストすべき

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  91. 追加で伝えたかったこと
    ハイレベルテストケースを記載することで
    メンテナンス性が高い状態を保つ
    そのテストを行う理由をテストケース名にする
    テスト作業ではなく、テスト活動をする

    View Slide

  92. まとめ
    https://jp.freeimages.com/photo/bright-sky-1393231

    View Slide

  93. まとめ
    テストの目的は欠陥の検出以外に
    欠陥の未然防止がある
    テストには実装開始前に行う活動もある
    早期テスト活動でコストを削減できる
    理由を考えながらテストを作成する
    開発とコラボしてテスト活動する
    やり方もある

    View Slide

  94. テストの勉強方法
    (時間があれば)
    https://jp.freeimages.com/photo/reading-1420126

    View Slide

  95. こんな質問が多い
    どうやってテストの勉強を
    すれば良いの︖
    テストの勉強ができる
    オススメの書籍が知りたい︕

    View Slide

  96. 「何をテストすべきか」でオススメの書籍
    https://www.amazon.co.jp/dp/4297105063/
    2019/4/13
    改訂版発売!

    View Slide

  97. 「どうやってテストケースを作るのか」でオススメの書籍
    2020/1/7発売!
    https://www.amazon.co.jp/dp/4817193603 https://www.amazon.co.jp/dp/429711061X/

    View Slide

  98. 「どうやって『ともにつくる』のか」でオススメの書籍
    https://www.amazon.co.jp/dp/B07YR4CC4B
    2019/9/25完成!
    (英語版のみ)

    View Slide

  99. 「どうやって『ともにつくる』のか」でオススメの書籍
    https://www.amazon.co.jp/dp/B07YR4CC4B
    2019/9/25完成!
    (英語版のみ)
    鋭意翻訳中!

    View Slide

  100. アンケート

    View Slide

  101. View Slide

  102. 最新のテスト情報収集ならJaSSTがオススメ!
    ● 日本最大級のテストのイベント
    ○ JaSST'19 Tokyoは2日間で1600名が参加
    ● 年に10回、各地で開催
    ● 2018年から新たにJaSST Reviewも開催
    ○ 実行委員長は私
    http://www.jasst.jp/

    View Slide

  103. テストを実践して学ぶならWACATEがオススメ!
    ● 1泊2日のワークショップ形式のイベント
    ● 2007年初開催
    ● 半年に1度開催(6月と12月)
    ● 新卒1年目の開発・QAも多く参加
    ● 参加費は24,000円(35歳以上は27,000円)
    https://wacate.jp/

    View Slide

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

    View Slide

  105. おしまい
    https://jp.freeimages.com/photo/track-finish-1442273

    View Slide

  106. 参考文献:ソフトウェアテストの7原則
    1.テストは欠陥があることは示せるが、
    欠陥がないことは示せない
    2.全数テストは不可能
    3.早期テストで時間とコストを節約
    4.欠陥の偏在
    5.殺虫剤のパラドックスにご用心
    6.テストは状況次第
    7.「バグゼロ」の落とし穴
    ● ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03
    ○ http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf

    View Slide

  107. 使用デザイン
    ● スライドデザイン
    ○ Professional Google Slides Template
    ■ https://slidesmash.com/professional-google-slides-template/
    ● アイコン画像
    ○ Lynny Icon Set
    ■ https://dribbble.com/shots/1925069-Lynny-Icon-Set-Free

    View Slide