Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

テストコードを書き始める前に考えるべきテストの話(2023年版) #cedec2023

テストコードを書き始める前に考えるべきテストの話(2023年版) #cedec2023

以下のイベントの投影資料です。
https://cedec.cesa.or.jp/2023

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

【発表資料中のURL】
P14 ゼロから始める「テスト設計」の書(ゲームテストの世界) - JaSST’17 Kyushu
https://www.jasst.jp/symposium/jasst17kyushu/pdf/S4.pdf

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

P19 ソフトウェア開発201の鉄則
https://bookplus.nikkei.com/atcl/catalog/96/140263/

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

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

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

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

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

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

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

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

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

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

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

P95 The BDD Books - Discovery (Japanese Edition)
https://leanpub.com/bddbooks-discovery-jp

P96 ソフトウェアテスト技法ドリル【第2版】: テスト設計の考え方と実際
https://www.amazon.co.jp/dp/4817197668

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

P98 ゼロからはじめるゲームテスト: 壁抜けしたら無限ガチャで最強モードな件?
https://www.amazon.co.jp/dp/4274230678/

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

P100 WACATE
https://wacate.jp/

P101 開発を加速するためのテスト講座 〜アジャイル開発にも適用できるシフトレフトなアプローチ〜
https://event.shoeisha.jp/cza/agile-testing

nihonbuson

August 25, 2023
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. 自己紹介 • 風間裕也(ブロッコリー) • 所属 ◦ 株式会社10X ◦ 株式会社iCARE フェロー(QAE技術顧問)

    ◦ B-Testing(個人事業主) • 社外活動 ◦ JaSST Review実行委員長 ◦ WACATE実行委員長 • 執筆活動 ◦ 『Agile Testing Condensed』(翻訳) ◦ 『Testing in DevOps』(翻訳) ◦ 『The BDD Books Discovery』(翻訳) ◦ 『テストコードの注入から始める レガシーコードのリファクタリング』(技術同人誌) SNS上の アイコン
  2. アジェンダ • はじめに • テストの目的 • 何をテストすべきか • どうやってテストケースを作るのか •

    QAはどのように開発者と一緒に仕事をするのか • テストの勉強方法 • まとめ
  3. 注意事項 • 話さない内容 ◦ テストコードの書き方 ◦ TDDのやり方 ◦ 自動テストの設計方法 ◦

    バグの無いゲームの作り方 • 話す内容 ◦ テストの目的とは何か ◦ テストファーストで行うことの本当の良さ ◦ 何をテストすれば良いのか
  4. テストの目的とは何か? • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分なことの確認 • 意思決定のための情報の提示 • 欠陥の作り込みの防止 実装前に行うこともある

    テストの7原則①テストは「欠陥がある」ことしか示せない
 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より
  5. なぜ実装前にテスト・レビューをするのか 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍

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

    20倍 200倍! 出典: Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社 修正コストを下げるには…(2) 早い段階で不具合を発見する
  7. 例題(チャット禁止!) あなたが考えた • テスト内容 • 気になった内容 • 起こりそうなバグ を、手元のメモ帳に 書いてください。

    ※何個でもOK! ※チャットには  まだ書かないで! (4分) • パスワードは4文字以上12文字以下の 英数字のみを許容する。 • パスワードを3分以内に4回以上 間違って入力すると、 アカウントを5分間ロックする。 https://www.pexels.com/photo/man-in-brown-shirt-writing-on-noteb ook-3202028/ 引用:概説 テスト分析
  8. • オフラインの方へ ◦ 考えた内容を 隣の人と共有 ◦ 話し合って 他に思いついたら追加 • オンラインの方へ

    ◦ テキストに記入 ▪ 何個でも可 https://www.pexels.com/photo/man-working-on-laptop-while-woman-takes-notes-3153199/ 例題
  9. オンライン参加者の回答(抜粋) • パスワードの文字数テスト • パスワードに含まれる文字の種類テスト • アカウントのロック時間テスト • 何も書かずに決定する •

    パスワードの時間が最初から3分か最後から3分か • みんな大好きSQLインジェクション • サマータイムスイッチ時に1時間ロックされるか • 通信環境の影響によるリトライのリクエストが 飛んだ場合の判定はどうするか? • 前回と同じパスワードを使った場合 間違いの1回としてカウントしない (連打防止)
  10. テスト時点 追加コストが発生! • チケット起票のコスト • 開発内容を思い出すコスト • 修正するコスト • もう一度テストするコスト

    • 関連しそうな部分にデグレードが無いか確認するコスト • 起票したチケットを完了にするコスト
  11. テストの目的とは何か?(再掲) • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分なことの確認 • 意思決定のための情報の提示 • 欠陥の作り込みの防止 実装前に行うこともある

    テストの7原則①テストは「欠陥がある」ことしか示せない
 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02より http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
  12. 仕様誤りの修正コスト 要求仕様 設計 実装 テスト リリース後 1倍 5倍 10倍 20倍

    200倍! 出典: Alan M. Davis. ソフトウェア開発 201の鉄則. 日経BP社 修正コストを下げるには…(2) 早い段階で不具合を発見する なぜ実装前にテスト・レビューをするのか(再掲)
  13. テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)

    参考:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02 何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する
  14. テストケース名にも役立つ @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public

    void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケース ローレベルテストケース
  15. テストケースはいくつ? • テストケースは時間があれば無限にできる。 • サンプリング方法としてテスト設計技法がある。 ◦ テストケースを合理的に少なくするための技法 ▪ 同値分割法、AllPair法 ◦

    多くの欠陥が見つかるようにするための技法 ▪ 境界値分析、エラー推測、探索的テスト ◦ ある観点で漏れなくテストするための技法 ▪ カバレッジ、デシジョンテーブル、 状態遷移、ユースケーステスト
  16. カバレッジは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)); }
  17. カバレッジは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)); }
  18. カバレッジは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)); }
  19. カバレッジは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)); }
  20. カバレッジは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)); }
  21. • 単体テスト(モジュールテスト) ◦ アイテムの個数欄にマイナスの数を入力できない。 • 結合テスト ◦ 指定したアイテムの組み合わせを入れると 「合成」ボタンが押せるようになった。 •

    システムテスト ◦ 新規登録→キャラ選択→ゲーム実施→退会の 一連の流れ。 テスターは ここをやりたい! システムテストレベルを見たい!
  22. • 単体テスト(モジュールテスト) ◦ アイテムの個数欄にマイナスの数を入力できない。 • 結合テスト ◦ 指定したアイテムの組み合わせを入れると 「合成」ボタンが押せるようになった。 •

    システムテスト ◦ 新規登録→キャラ選択→ゲーム実施→退会の 一連の流れ。 開発者は ここをやりきって! システムテストレベルを見たい!
  23. • 単体テスト(モジュールテスト) ◦ アイテムの個数欄にマイナスの数を入力できない。 • 結合テスト ◦ 指定したアイテムの組み合わせを入れると 「合成」ボタンが押せるようになった。 •

    システムテスト ◦ 新規登録→キャラ選択→ゲーム実施→退会の 一連の流れ。 システムテストレベルを見たい! テスターが担当せずに 開発者が全てやるのもあり
  24. Agile Testing Condensedの例 • QA=「Question Asker」という考え方 ◦ 誰も質問しないと思う質問を定期的に出す ◦ 自由回答形式の質問もする

    ▪ 隠れた仮定が明らかになる ▪ 質問例 • 実装しても問題解決できない 可能性はあるか? • 機能の使用前にユーザーは何をするか? • その後、ユーザーは何をするか?