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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 当日の参加者の回答

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. 設計・開発時点

    View Slide

  30. テスト時点

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. 参加者の回答

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 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 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 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 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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


    Testing

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    新発売!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide