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

テストコードを書き始める前に考えるべきテストの話(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. テストエンジニアが伝える
    テストを実施する前に
    考えるべきテストの話
    ブロッコリー
    (@nihonbuson)

    View full-size slide

  2. 自己紹介
    ● 風間裕也(ブロッコリー)
    ● 所属
    ○ 株式会社10X
    ○ 株式会社iCARE フェロー(QAE技術顧問)
    ○ B-Testing(個人事業主)
    ● 社外活動
    ○ JaSST Review実行委員長
    ○ WACATE実行委員長
    ● 執筆活動
    ○ 『Agile Testing Condensed』(翻訳)
    ○ 『Testing in DevOps』(翻訳)
    ○ 『The BDD Books Discovery』(翻訳)
    ○ 『テストコードの注入から始める
    レガシーコードのリファクタリング』(技術同人誌)
    SNS上の
    アイコン

    View full-size slide

  3. 当日の参加者の業種&職種

    View full-size slide

  4. アジェンダ
    ● はじめに
    ● テストの目的
    ● 何をテストすべきか
    ● どうやってテストケースを作るのか
    ● QAはどのように開発者と一緒に仕事をするのか
    ● テストの勉強方法
    ● まとめ

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. ゲームQAにおける2つのテスト領域
    世界観
    システム
    部分

    View full-size slide

  12. ゲームQAにおける2つのテスト領域
    世界観
    システム
    部分
    かけるコストを
    減らしたい
    時間を
    確保
    したい

    View full-size slide

  13. 今日話すのはシステム部分のテスト
    世界観
    システム
    部分
    かけるコストを
    減らしたい
    時間を
    確保
    したい

    View full-size slide

  14. 世界観も含めた話は以下の資料を参考に…
    ゼロから始める「テスト設計」の書(ゲームテストの世界) - JaSST’17 Kyushu

    View full-size slide

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

    View full-size slide

  16. 質問です
    テストの目的って何でしょう?

    View full-size slide

  17. 当日の参加者の回答

    View full-size slide

  18. テストの目的とは何か?
    ● 欠陥の検出
    ● 対象ソフトウェアの品質レベルが十分なことの確認
    ● 意思決定のための情報の提示
    ● 欠陥の作り込みの防止
    実装前に行うこともある
    テストの7原則①テストは「欠陥がある」ことしか示せない

    ISTQBテスト技術者資格制度
    Foundation Level シラバス 日本語版
    Version 2011.J02より

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. 何をテストすべきか
    https://jp.freeimages.com/photo/target-1306247

    View full-size slide

  23. ● パスワードは4文字以上12文字以下の
    英数字のみを許容する。
    ● パスワードを3分以内に4回以上
    間違って入力すると、
    アカウントを5分間ロックする。
    https://www.pexels.com/photo/man-in-brown-shirt-writing-on-noteb
    ook-3202028/
    引用:概説 テスト分析
    例題(チャット禁止!)

    View full-size slide

  24. 例題(チャット禁止!)
    あなたが考えた
    ● テスト内容
    ● 気になった内容
    ● 起こりそうなバグ
    を、手元のメモ帳に
    書いてください。
    ※何個でもOK!
    ※チャットには
     まだ書かないで!
    (4分)
    ● パスワードは4文字以上12文字以下の
    英数字のみを許容する。
    ● パスワードを3分以内に4回以上
    間違って入力すると、
    アカウントを5分間ロックする。
    https://www.pexels.com/photo/man-in-brown-shirt-writing-on-noteb
    ook-3202028/
    引用:概説 テスト分析

    View full-size slide

  25. ● オフラインの方へ
    ○ 考えた内容を
    隣の人と共有
    ○ 話し合って
    他に思いついたら追加
    ● オンラインの方へ
    ○ テキストに記入
    ■ 何個でも可
    https://www.pexels.com/photo/man-working-on-laptop-while-woman-takes-notes-3153199/
    例題

    View full-size slide

  26. オンライン参加者の回答(抜粋)
    ● パスワードの文字数テスト
    ● パスワードに含まれる文字の種類テスト
    ● アカウントのロック時間テスト
    ● 何も書かずに決定する
    ● パスワードの時間が最初から3分か最後から3分か
    ● みんな大好きSQLインジェクション
    ● サマータイムスイッチ時に1時間ロックされるか
    ● 通信環境の影響によるリトライのリクエストが
    飛んだ場合の判定はどうするか?
    ● 前回と同じパスワードを使った場合
    間違いの1回としてカウントしない (連打防止)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 設計・開発時点

    View full-size slide

  30. テスト時点

    View full-size slide

  31. テスト時点
    追加コストが発生!
    ● チケット起票のコスト
    ● 開発内容を思い出すコスト
    ● 修正するコスト
    ● もう一度テストするコスト
    ● 関連しそうな部分にデグレードが無いか確認するコスト
    ● 起票したチケットを完了にするコスト

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. テストの目的とは何か?(再掲)
    ● 欠陥の検出
    ● 対象ソフトウェアの品質レベルが十分なことの確認
    ● 意思決定のための情報の提示
    ● 欠陥の作り込みの防止
    実装前に行うこともある
    テストの7原則①テストは「欠陥がある」ことしか示せない

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  38. 機能を作る≠顧客へ価値を提供する
    https://www.ipa.go.jp/files/000045962.pdf#page=13

    View full-size slide

  39. 使用性の例
    次の画像を見て判断してください。
    化粧室に行くには、
    左折、直進、右折の
    どの方向へ行けば良い?
    (画像が出たらすぐに投票してね)

    View full-size slide

  40. 使用性の例
    化粧室に行くには、
    左折、直進、右折の
    どの方向へ行けば良い?

    View full-size slide

  41. 参加者の回答

    View full-size slide

  42. 使用性の例
    面白いデザインだ!
    採用!
    看板作成者
    どこに何があるのか
    分からない!
    利用者

    View full-size slide

  43. 使用性の例
    並び変えるだけでも
    分かりやすくなる
    https://note.openvista.jp/2011/redesigning-shinjuku-building-sign

    View full-size slide

  44. 「何をテストすべきか」で伝えたいこと
    ● 実装前に考えられるテストは存在する
    ○ 例えば設計レビューの場で
    ○ 「こういうテストを考えています」
    という話も聞けると良いな
    ● 「機能を作る」と「顧客へ価値を提供する」は
    同義ではない
    ○ 機能を作ることに没頭せず、
    顧客が本当に欲しい物が何かを考えましょう

    View full-size slide

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

    View full-size slide

  46. テスト実行するまでの過程
    テスト
    分析
    テスト
    設計
    テスト
    実装
    テスト
    実行
    テストプロセス(JSTQBより)
    参考:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02
    何をテスト
    するか
    それをどう
    テストするか
    テストの実行に
    必要なものすべて
    を準備したか
    テストスイート
    を実行する

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. 答え(その1)
    プルダウンの一番下の値を使う(沖縄県)
    →プルダウン内のスクロール、配列エラー確認(i[47])

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  59. 境界値分析
    https://jp.freeimages.com/photo/linux-login-1497422

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  62. 12
    4
    有効
    無効 無効
    3 13
    境界値分析で考える
    パスワードは4文字以上12文字以下

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  65. カバレッジは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 full-size slide

  66. カバレッジは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 full-size slide

  67. カバレッジは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 full-size slide

  68. カバレッジは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 full-size slide

  69. カバレッジは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 full-size slide

  70. 12
    4
    有効
    無効 無効
    3 13
    欠陥は局所的に発生する
    パスワードは4文字以上12文字以下
    テストの7原則④欠陥の偏在

    View full-size slide

  71. 12
    4
    有効
    無効 無効
    3 13
    もう1箇所テストできるならば…
    パスワードは4文字以上12文字以下
    テストの7原則④欠陥の偏在

    View full-size slide

  72. 12
    4
    有効
    無効 無効
    3 13
    0文字はnull処理などの可能性がある
    パスワードは4文字以上12文字以下
    テストの7原則④欠陥の偏在
    0

    View full-size slide

  73. 「どうやってテストケースを作るのか」で伝えたいこと
    ● 全てを闇雲にテストすると膨大なケース数と時間が
    発生するが、その数を削減できる手法がある
    ● そのテストを行う理由をテストケース名にする

    View full-size slide

  74. QAやテスターは
    どのように
    開発者と一緒に
    仕事をするのか
    https://www.pexels.com/photo/woman-in-black-coat-1181346/

    View full-size slide

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

    View full-size slide

  76. QAやテスターは何をするの?
    これだけテストが充実できれば
    QAやテスターは必要ないのでは?
    →ここまでの発表以外にQAやテスターは、
    1. システムテストレベルを見たい!
    2. 世界観のテストを行いたい!
    3. CheckingではなくTestingを行いたい!
    4. テスト以外も行いたい!
    ※QAやテスターがいない場合、誰かor全員が担うべき

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  81. 世界観のテストを行いたい!
    世界観
    システム
    部分
    テスターは
    ここを
    やりたい!

    View full-size slide

  82. Testingをしたい!
    https://www.infoq.com/jp/news/2009/12/testing-or-checking

    View full-size slide

  83. Testingをしたい!
    https://www.infoq.com/jp/news/2009/12/testing-or-checking
    Checking

    意図通り動くか確認する作業


    Testing

    なんとかして製品を破壊する作業

    TDDで書くテストは
    ほとんどchecking

    View full-size slide

  84. テスト以外も行いたい!
    私の
    経験

    View full-size slide

  85. テスト以外も行いたい!

    View full-size slide

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

    View full-size slide

  87. テスト以外も行いたい!

    View full-size slide

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

    View full-size slide

  89. テスト以外も行いたい!
    私の
    経験

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  92. 質問をするテスト活動の事例
    https://speakerdeck.com/nihonbuson/example-mapping https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt
    https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  95. 「何をテストすべきか」でオススメの書籍
    https://www.amazon.co.jp/dp/4297105063/ https://leanpub.com/bddbooks-discovery-jp
    オススメポイント
    ● テストケースの
    作成前に
    考えるべき
    話が書かれている

    View full-size slide

  96. 「どうやってテストケースを作るのか」でオススメの書籍
    https://www.amazon.co.jp/dp/4817197668 https://www.amazon.co.jp/dp/429711061X/
    オススメポイント
    ● テスト技法の
    解説が詳しい
    (左の書籍)
    ● テスト技法に
    関する問題を
    豊富に掲載
    (右の書籍)

    View full-size slide

  97. テスターと開発者の協働に関するオススメの書籍
    https://leanpub.com/agiletesting-condensed-japanese-edition
    オススメポイント
    ● アジャイルテストについて
    100ページ弱で
    簡潔に語っている
    ● 全世界のQAやテスターの
    知見が書かれている

    View full-size slide

  98. ゲームテストに関するオススメの書籍
    https://www.amazon.co.jp/dp/4274230678/
    オススメポイント
    ● 前半はよくあるバグを紹介し
    後半はテスト技術を説明
    ● できるだけ多くの人に
    伝わるような用語選定の工夫
    ○ ゲーム業界は会社特有の
    方言が特に多い
    ○ 複数社のQAが著作に携わる
    ○ 巻末にあるゲームテストの
    用語集も豊富
    8/28

    新発売!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  101. CodeZine Academyにて講座も用意しています
    https://event.shoeisha.jp/cza/agile-testing

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide