DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜

DeNAの品質を⽀えるQAの 取り組み 〜標準化から実践まで〜 河野 哲也 システム本部 品質管理部 QC第⼆グループ #denatechcon #denatechcon

発表のサマリ • サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA⽴ち上げの⼯夫点や実践例を紹介する • 話さないこと ⇔ 話すこと • テクノロジー観点のテスト技術 ⇔ 泥臭いテスト技術 • テスト⾃動化 ⇔ テスト設計 • 単体テスト／結合テスト ⇔ 機能テスト／システムテスト 2 #denatechcon

市場調査 1. 本業がQA／テストの⽅ 2. 開発もQAも両⽅やっている⽅ 3. QAはやっていないけど組織やチームの観点でQAに興味がある⽅ 開発 開発 テスト 内部リリース プロダクト QA テスト 3 #denatechcon

DeNA 品質管理部：QAの位置づけ • QAは外部仕様を対象としたテストを担当 • ほとんどは⼿動テスト 開発 開発 テスト 単体テスト・結合テスト 内部リリース プロダクト QA テスト 機能テスト・システムテスト 4 #denatechcon

発表のサマリとアウトライン • サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA⽴ち上げの際の⼯夫点や実践例を紹介する • アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部⾨・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA⽴ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 5 #denatechcon

⾃⼰紹介：河野 哲也(FB:Tetsuya Kouno ) • 現職 • システム本部 品質管理部 QC第⼆グループ • 主にヘルスケアサービス全般のQA取りまとめ • 部⾨横断改善活動の旗振り • 新規サービスのQA⽴ち上げ • 経歴 • • • • 通信機器メーカでハードウェアQA（10年弱） 電気通信⼤学で社会⼈⼤学、⼤学院前期・後期課程＋フリーのコンサル ⽇⽴製作所でソフトウェアQA・部⾨横断のプロセス改善（6年弱） DeNAでWeb・モバイルのQA（1年4ヶ⽉） • 得意技：テスト分析・テスト設計 • 委員：ソフトウェア品質シンポジウム委員、 ソフトウェアシンポジウムPC委員、品質管理学会会員 #denatechcon 6

DeNA 品質管理部 • ⼤⼩様々なサービス・プロダクトのQA業務を担当 • 開発は現在拡⼤中、開発プロセス・品質レベルもまちまち • 開発拡⼤に伴いQAメンバも増加中 • テストベンダ各社から派遣されたメンバが多くを占めている • 技術レベルや経験領域のばらつきも無視できない 品質管理部 QC1G QC2G SWET ゲームQA PFチーム CIチーム HCチーム AMチーム 7 #denatechcon

横断的な課題 1. テストの進め⽅が各チームによってバラバラで 統制が取れていない 2. 世の中⼀般のテスト⽔準に対して現状の⽴ち位置が 分からない 3. テスト技術のばらつきが⼤きく、テストケースの質 が安定しない 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない 8 #denatechcon

取り組み・施策 1. テストの進め⽅が各チームによってバラバラで 統制が取れていない ⇨テストプロセスの標準化 2. 世の中⼀般のテスト⽔準に対して現状の⽴ち位置が 分からない ⇨TPI NEXTによるテストプロセスのアセスメント 3. テスト技術のばらつきが⼤きく、テストケースの質が 安定しない ⇨標準テスト観点の整備 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない ⇨テストメトリクス収集の仕組み作り #denatechcon 9

取り組み・施策 1. テストの進め⽅が各チームによってバラバラで 統制が取れていない⇨テストプロセスの標準化 2. 世の中⼀般のテスト⽔準に対して現状の⽴ち位置が 分からない⇨TPI NEXTによるテストプロセスのアセスメント 3. テスト技術のばらつきが⼤きく、テストケースの質が 安定しない⇨標準テスト観点の整備 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない ⇨テストメトリクス収集の仕組み作り 課題に対し適切な施策を導出し、施策のボタンを⼀つずつ押していくことが重要 ボタンの順番を間違えない・ハードルを上げない・焦らない 10 #denatechcon

発表のサマリとアウトライン • サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA⽴ち上げの際の⼯夫点や実践例を紹介する • アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部⾨・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA⽴ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 11 #denatechcon

組織横断の改善事例 • テストプロセスの標準化 • 標準化の流れと標準プロセスの概説 • TPI NEXTによるテストプロセスのアセスメント • TPI NEXTの概説とアセスメント結果の紹介 • 標準テスト観点の整備 • JaSSTʼ19 Tokyo で発表予定のため詳細はそちらで報告 • テストメトリクス収集の仕組み作り • 仕組みの概説 12 #denatechcon

標準テストプロセス Slack/ Confluence JIRA ( ) DB JIRA 13 #denatechcon

テストプロセスの標準化の流れ（PFDによる表現） • 詳細はこちら（ブログ内にスライドのリンクがあります） DeNA Engineersʼ Blog :QA Night #1 開催レポート（第⼆部） https://engineer.dena.jp/2018/12/qa-night-1-2.html PFチーム のテスト プロセス ⾒える 化 PFチーム のテスト プロセス HCチーム のテスト プロセス ⾒える 化 HCチーム のテスト プロセス CIチーム のテスト プロセス ⾒える 化 CIチームの テスト プロセス CIチーム のテスト プロセス ⾒える 化 AMチーム のテスト プロセス #denatechcon 共通は積集合にする 和にすると⼤変 プロセス の⽐較・ 共通化 PFD(Process Flow Diagram)で表現 共通的な テスト プロセス 名称の 定義 JSTQB ⽤語集 など 実際の テスト 業務 ドキュメ ンテー ション 標準テスト プロセス⽂書 標準 テスト プロセス QAメンバが ハンドブック的に 利⽤できる 14

• https://engineer.dena.jp/2018/12/qa-night-1-2.html

標準テストプロセス Slack/ Confluence JIRA ( ) DB JIRA 15 #denatechcon

標準テストプロセスをベースとした改善施策 Slack/ Confluence JIRA QA QA QA ( ) DB JIRA 16 #denatechcon

TPI NEXTによるテストプロセスのアセスメント • ⽬的 • 把握：現状の各チームのテストプロセスを共通のものさしで把握する • 改善：世の中の標準的な視点で改善ポイントを探る • 各チームの代表的なサービスのテストプロセスを対象にアセスメント • TPI NEXT：テストプロセス改善モデル • テストプロセス成熟度の評価／テスト成熟度マトリクス⇨⾒える化 • 157のテスト活動に関するチェックポイントに回答することにより評価 例）テスト戦略はプロダクトリスクに基づいている テスト戦略には適切なテスト設計技法を含めている • 評価結果に基づく改善／クラスタセット⇨改善のための指針 • テストプロセスというよりはテスト活動全体に対しての改善 17 #denatechcon

アセスメント結果 TPI NEXT 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% QC1G PF C&I HC AM • ⻑所：利害関係者との コミットメント／ コミュニケーション／関与 の度合い • プロセス的な観点ではなく 事業部との関係性を重要視 • 開発プロセスに応じて 臨機応変に対応している • 短所：テスト戦略／ ⾒積もりと計画／ メトリクス／テストツール • テスト計画に戦略的視点がない • データに基づく活動担っていない • ツールの検討が体系だっていない 18 #denatechcon

標準テスト観点の整備 • チーム横断で活⽤可能な標準テスト観点を整備している PFチーム テスト観点 分析 過去のテスト 成果物(PF) 過去のテスト 成果物(HC) 共通化 ・整理 分析 過去のテスト 成果物(CI) 過去のテスト 成果物(AM) テスト 観点 リスト 分析 分析 AMチーム テスト観点 #denatechcon 標準 テスト 観点 教育 コンテンツ 導⼊⽤の 資料として活⽤ 教育 コンテンツ 作成 テスト 観点 リスト 適⽤ ⼿順 テスト 観点 リスト テスト 観点 リスト チーム横断で 使えるように 共通化 まずはチーム単位で テスト観点の整理 試⾏ 評価 結果 19

標準テスト観点の⼀例 • 約900観点を導出・整理した 観点タイトル ログイン Level1 複数ブラウザからの多重ログ イン ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ Android-Android ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ Android-iOS ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ iOS-iOS ログイン 複数アカウントの切り替え ログイン 既存アカウントへのログイン ログイン 連続認証失敗 #denatechcon Level2 失敗回数許容上限の超過 Level3 20

テストメトリクス収集の仕組み作り • テスト活動に関わるメトリクスの収集 • 標準テストプロセスをベースに収集データを定義 • ⼀通りのプロセスが終了したらデータを登録する • メトリクスの活⽤例（GQMによる表現） • Goal１：テストプロセスの各プロセスの⼯数割合がわかっている • Question1：案件ごとの各プロセスの⼯数は全体に対してどれくらいか？ • Metric1：テスト計画・テスト設計・テスト実⾏の⼯数 • Goal2：テスト計画・振返りが徹底できているか把握できている • Question2：案件ごとのテスト計画・振返りの⼯数は全体に対して どれくらいか？ • Metric2：テスト計画・振返りの⼯数、全体の⼯数 21 #denatechcon

標準テストプロセスに従わないと データが取れないので、 データ収集には⼀定の強制⼒がある 収集データの例 Slack/ Confluence JIRA 作業 時間 ( ) DB JIRA 不具合 件数 22 #denatechcon テスト 項⽬数

組織横断の改善事例 • テストプロセスの標準化 • 標準化の流れと標準プロセスの概説 • TPI NEXTによるテストプロセスのアセスメント • TPI NEXTの概説とアセスメント結果の紹介 • 標準テスト観点の整備 • JaSSTʼ19 Tokyo で発表予定のため詳細はそちらで報告 • テストメトリクス収集の仕組み作り • 仕組みの概説 23 #denatechcon

発表のサマリとアウトライン • サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA⽴ち上げの際の⼯夫点や実践例を紹介する • アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部⾨・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA⽴ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 24 #denatechcon

QA⽴ち上げ実践事例：アウトライン • 背景／コンテキスト • ⽴ち上げ時にやったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 25 #denatechcon

事例の背景 • 開発とのコミュニケーション開始が2017年12⽉ • 企画が柔らかい段階で声をかけてもらった：重要ポイント • このタイミングでQAの⽴ち上げ開始 • 「開発と⼀緒にやること／決めること」 「QA内部でやること／決めること」 を洗い出し⼀つずつ解決していく • 昨年にWebβ版ローンチ、現在アプリ開発中 • 現状、QAは⽴ち上げ期から安定期にシフト 26 #denatechcon

開発のコンテキスト • 4名が専任、1名オンデマンド • サーバ、フロント、プロダクト、ビジネス、デザイン • ドキュメンテーションできるほど⼯数・予算的に余裕がない • β版の開発 • 顧客に提供できる最⼩限のプロダクト（Webサービス） • 現在はアプリ開発中 • 開発プロセス：リーンスタートアップ開発＋ アジャイル・スクラムのプラクティスをいくつか導⼊ • QAの単位：実装の終わった機能からQAにリリース（QAサイクル） • 基本的には機能テスト以降を実施 • 開発者はローカル環境で簡単な機能テストを実施してリリース 27 #denatechcon

QAのコンテキスト • メンバ構成 • Webβ版QA対応 • 2017年12⽉〜：1名専任、1名オンデマンド対応 • 2018年4⽉〜7⽉：2名専任、1名オンデマンド対応 • アプリQA対応 • 2018年9⽉〜：1名専任、1名オンデマンド対応 • 経験豊富なメンバをアサインできたわけではない • ただし技術的な観点においてモチベーションが⾼いメンバ • QAの制約 • 低予算での対応 ⇨テスト⼯数が限られており詳細なテスト項⽬を設計する時間が無い • 開発ドキュメントが不確定（変更が多い） 28 #denatechcon

QA⽴ち上げ実践事例：アウトライン • 背景／コンテキスト • ⽴ち上げ時にやったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 29 #denatechcon

QA⽴ち上げ時のビュー • 2つのビューで検討する • 開発⇔QA：開発とQAとの仕組み • QA内部：QA内部の仕組み QA 開発 技術 ⼈ プロセス 30 #denatechcon

QAの⽴ち上げのときに何をやりますか？ • 例えば、 QAメンバの調達・調整 テストプロセスの検討 開発 開発 テスト QA 内部リリース ⼈ プロダクト 技術 プロセス 31 #denatechcon

開発⇔QAでやったこと／決めたこと 【基本⽅針：エンジニアが開発にフォーカスできるように⽀援する】 • 開発状況ヒアリング • 開発のリソースの把握：どこまでドキュメントを作れるのか？ • スケジュールと予算：どの期間でどれくらいのQAリソースが必要なのか？ • 対象サービスと品質レベル：必要なQAスキルは？QAのボリュームは？ • 開発プロセスを踏まえたテストプロセス • テスト対象のリリースフロー：プロセスを回す単位を決める(QAサイクル) • 細かい機能の実装が終わった段階でリリースされる • QAからの貢献も⼀緒に考える⇨【QAで外部仕様書を作成する】 • インシデントレポート（バグチケット）の運⽤定義 • ⼊⼒項⽬の定義、処理フローの定義とそれらの開発者との合意形成 • 開発⇔QAのやり取りのインフラ • コミュニケーション⼿段、ドキュメント 32 #denatechcon

QA内部でやったこと／決めたこと 【基本⽅針：アジリティのあるテストを⽬指す】 • 標準テストプロセスの実装【詳細解説】 • テスト計画書、テスト仕様書、テスト完了報告書 • 成果物をどのレベルまで作るかを決める • 探索的テストの導⼊ • ユーザビリティ観点のテスト、など • テスト設計の実践【詳細解説】 • テスト設計技法にこだわる • スクラムプラクティスの導⼊ • バックログ管理／朝会と Daily Scrum • WeeklyのKPTとテスト業務のプランニング 33 #denatechcon

QA⽴ち上げに検討が必要なことリスト【⼀般化】 • QAで確保できるリソースの調整 • 予算、⼈員、スキル • 開発プロセスを踏まえたテストプロセスの構築 • 作成するテスト成果物の定義とテンプレ作成 • テスト計画書、テスト仕様書、テスト報告書 • 特にテスト仕様書をどこまで細かく書くかは今後のテスト⼯数や スピードに⼤きく影響するので注意が必要 • インシデントレポートの運⽤⽅法の定義 • 開発⇔QAのやり取りのインフラ • QAチームのマネジメント • チームビルディング • テスト業務の割り振り：誰がどの業務を担当するのかを決める #denatechcon 34

QA⽴ち上げ実践事例：アウトライン • 背景／コンテキスト • ⽴ち上げ時にやったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 35 #denatechcon

標準テストプロセスの実装 • 開発形態やQA状況に応じて標準をテーラリング • テスト設計技法を活⽤してテスト設計を軽く・スピーディーにする • テスト設計の段階でデザインとDev環境を⾒ながら最新の仕様を確認する • テスト仕様書をベースに最新の仕様を反映した外部仕様書を作成する リリース単位 の仕様 仕様 共有会 共有会 メモ テスト 計画 テスト 計画書 テスト 結果 報告書 テスト 設計 テスト結果 報告書 作成 PRD 標準 テスト観点 デザ イン 環境 外部仕様書 #denatechcon ＋ Dev 環境 外部 仕様 作成 テスト 仕様書 JIRAの プロジェクト テスト 実⾏ 36 不具合 チケット

標準テストプロセスとの対応 Slack/ Confluence JIRA ( ) DB JIRA 37 #denatechcon

QA⽴ち上げ実践事例：アウトライン • 背景／コンテキスト • ⽴ち上げ時にやったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 38 #denatechcon

テストの例：アドホック • ⼤きな流れ：テスト計画→テスト設計→テスト実⾏ 1. 2. 3. 4. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する #denatechcon この仕様をベースに テスト対象サービスを触りながら テストをしては⾏けない ⇓ どんなテストをやるのかを テスト設計しないといけない 39

テストの例：仕様の書き写し • ⼤きな流れ：テスト計画→テスト設計→テスト実⾏ 1. 2. 3. 4. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する #denatechcon No. 1 確認内容 エントリー画⾯の「規約同意」がチェック済みになると「エ ントリー」ボタンが活性状態になること 2 エントリー画⾯でエントリーコードを⼊⼒し、「エント リー」ボタンを押下し、エントリーコードが無効だった場合 はエラーメッセージを表⽰すること 3-1 エントリーコードが有効だった場合、エントリーに成功しパ スワード登録URLが記載されたメールが当該ユーザーのメール アドレスに送付されること 3-2 4-1 URLには有効期限があり、１０分で期限切れとなること パスワード登録画⾯で「パスワード⼊⼒」と「パスワード （確認⽤）⼊⼒」が⼀致していればパスワード登録すること 4-2 パスワードは６⽂字以上８⽂字以内とし、⽂字種別は「⼩⽂ 字、⼤⽂字、数字、記号」とし、その範囲以外の場合はエ ラーメッセージを表⽰すること 仕様を書き写すだけでは不⼗分 40

テストの例：⼤中⼩項⽬ • ⼤きな流れ：テスト計画→テスト設計→テスト実⾏ 1. 2. 3. 4. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する #denatechcon No. 1 2 3 4 5 6 7 8 9 ⼤項⽬ 中項⽬ ⼩項⽬ エントリー 規約チェック OFF ボックス 画⾯ ON エントリー 無効 コード 有効 パスワード URL 期限切れ︓10分経過 登録画⾯ 有効期限 期限内︓10分以内 パスワード 桁数が最⼩値-1 桁数が最⼤値+1 ⼩⽂字、⼤⽂字、数字、記号 以外 10 確認⽤パスワードと不⼀致 11 12 有効︓桁数が最⼩値 有効︓桁数が最⼤値 ⼤中⼩項⽬でも不⼗分 41

テストの例：テスト設計技法によるテスト設計 • ⼤きな流れ：テスト計画→テスト設計→テスト実⾏ 1. 2. 3. 4. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する エントリーコードが有効だった場合、 エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合は エラーメッセージを表示する #denatechcon テスト設計技法を使ってテスト設計する 42

テスト設計の実践：テスト設計技法にこだわる • 今までのテスト設計 • ⼤中⼩項⽬でのテスト観点の整理→ローレベルテストケースの作成 • 上記ドキュメントでは外部仕様を表現できない • テスト設計技法を使いこなす • 技法を勉強しながら、勘所を習得→【ペアテストデザイン】 • QAメンバには新しい技術を習得したいという意欲が必要 • テスト設計技法を使って作成したテスト仕様書は 外部仕様として活⽤できる • 参考資料 • JaSSTʼ18 Kyushu 基調講演 「品質・仲間・技術と向き合ってテスト設計技法の⼒を引き出す」 http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf 43 #denatechcon

• http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf

テスト設計の例：うるう年の計算 • うるう年は以下で決まる (引⽤：ソフトウェアテスト技法ドリル) １）⻄暦年が４で割切れる年はうるう年 ２）ただし、⻄暦年が１００で割切れる年は平年 ３）ただし、⻄暦年が４００で割切れる年はうるう年 例：２０１２年と２０００年はうるう年、２０１３年と２１００年は平年 44 #denatechcon

テスト設計の例：うるう年の計算 • うるう年は以下で決まる (引⽤：ソフトウェアテスト技法ドリル) １）⻄暦年が４で割切れる年はうるう年 ２）ただし、⻄暦年が１００で割切れる年は平年 ３）ただし、⻄暦年が４００で割切れる年はうるう年 例：２０１２年と２０００年はうるう年、 ２０１３年と２１００年は平年 #denatechcon ⼊⼒データ 出⼒データ 2000年 うるう年 2100年 平年 2012年 うるう年 1999年 平年 45

テスト設計の例：うるう年の計算 • うるう年は以下で決まる (引⽤：ソフトウェアテスト技法ドリル) １）⻄暦年が４で割切れる年はうるう年 ２）ただし、⻄暦年が１００で割切れる年は平年 ３）ただし、⻄暦年が４００で割切れる年はうるう年 例：２０１２年と２０００年はうるう年、２０１３年と２１００年は平年 原因 ⼊⼒データ 結果 出⼒データ #denatechcon 1 2 3 4 400で割切れる年 ○ - - - 400で割切れないで100で割切れる年 - ○ - - 100で割切れないで4で割切れる年 - - ○ - 4で割切れない年 - - - ○ ● 平年 うるう年 - - - - ● - ● - ● - 46

テスト設計の例：ストップウォッチ 1. 2. 3. 4. 5. 6. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 動いている最中にスタートボタンを押すと 停止する 停止状態でスタートボタンを押すと そこから再スタートする 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引⽤：ソフトウェアテスト技法ドリル） 47 #denatechcon

テスト設計の例：ストップウォッチ 1. 2. 3. 4. 5. 6. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 動いている最中にスタートボタンを押すと 停止する 停止状態でスタートボタンを押すと そこから再スタートする 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引⽤：ソフトウェアテスト技法ドリル） #denatechcon 1 2 3 4 5 6 7 8 デフォルト ○ ○ - - - - - - 動作中 - - ○ ○ - - - - 停⽌中 - - - - ○ ○ - - ラップ表⽰中 - - - - - - ○ ○ スタートボタン ○ - ○ - ○ - ○ - ラップボタン - ○ - ○ - ○ - ○ - - - - - - - - - - - - - ● - - ● - - - ● - - ● 停⽌中 - - ● - - - - - ラップ表⽰中 - - - ● - - - - 無効 - ● - - - - ● - 原因 現在の状態 ボタン 結果 遷移後の状態 デフォルト 動作中 48

テスト設計の例：ストップウォッチ 1. 2. 3. 4. 5. 6. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 動いている最中にスタートボタンを押すと 停止する 停止状態でスタートボタンを押すと そこから再スタートする 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引⽤：ソフトウェアテスト技法ドリル） ラップ 初期状態 デフォ ルト 停止中 スタート スタート スタート 動作中 ラップ ラップ ラップ 表示中 #denatechcon 49

テスト設計の例：ストップウォッチ 1. 2. 3. 4. 5. 6. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 動いている最中にスタートボタンを押すと 停止する 停止状態でスタートボタンを押すと そこから再スタートする 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引⽤：ソフトウェアテスト技法ドリル） ラップ 初期状態 デフォ ルト 停止中 スタート スタート スタート 動作中 ラップ ラップ ラップ 表示中 50 #denatechcon

テスト設計の実践：テスト設計技法にこだわる • 今までのテスト設計 • ⼤中⼩項⽬でのテスト観点の整理→ローレベルテストケースの作成 • 上記ドキュメントでは外部仕様を表現できない • テスト設計技法を使いこなす • 技法を勉強しながら、勘所を習得→【ペアテストデザイン】 • QAメンバには新しい技術を習得したいという意欲が必要 • テスト設計技法を使って作成したテスト仕様書は 外部仕様として活⽤できる • 参考資料 • JaSSTʼ18 Kyushu 基調講演 「品質・仲間・技術と向き合ってテスト設計技法の⼒を引き出す」 http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf 51 #denatechcon

• http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf

ペアテストデザインの実践例：申請系の機能 • ホワイトボードにスケッチをしてテスト設計技法の勘所をメンバと共有 52 #denatechcon

ペアテストデザインの実践例：申請系の機能 • スケッチをベースに成果物としてきちんと整理する 前状態 CB可能額 1番⽬に実⾏する機能／アクション 期間 ※ 申請 申請取消 確認ダイアログ 確認ダイアログ 2番⽬に実⾏する機能／アクション 期間 ※ 申請 申請取消 確認ダイアログ 確認ダイアログ 1 2 3 4 5 6 7 8 9 10 11 12 13 有効（≧1,000円） - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（＜1,000円） ◯ - - - - - - - - - - - - 有効（申請期間中） ◯ - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（申請開始前） - ◯ - - - - - - - - - - - 無効（申請期間締め後） - - - - - - - - - - - - - OK（申請する） - - ◯ ◯ - ◯ ◯ - - - - - - NG（キャンセルする） - - - - ◯ - - ◯ ◯ - - - - OK（申請取消） - - - - - - - - - ◯ ◯ - - NG（キャンセルする） - - - - - - - - - - - ◯ ◯ 有効（申請期間中） - - - - - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（申請開始前） - - - - - - - - - - - - - 無効（申請期間締め後） - - ◯ - - - - - - - - - - OK（申請する） - - - - - - - - ◯ - ◯ - - NG（キャンセルする） - - - - - - - ◯ - ◯ - - - OK（申請取消） - - - - - - ◯ - - - - - ◯ NG（キャンセルする） - - - - - ◯ - - - - - ◯ - 確認項⽬ 期待値 画⾯遷移 CB申請画⾯ 再表⽰ - - - - ◯ ◯ ◯ ◯ - ◯ - ◯ ◯ 申請完了ダイアログ→ホーム画⾯ - - - ◯ - - - - ◯ - ◯ - - ⾮活性状態であること ○ ○ ○ - - - - - - - - - - 活性状態であること - - - - ○ - ○ ○ - ○ - - ○ ⾮活性状態であること - - - - - - - - - - - - - 活性状態であること - - - ○ - ○ - - ○ - ○ ◯ - 「次の申請期間︓mm/dd-mm/dd」 - ○ ○ - - - - - - - - - - 「申請期間中︓mm/dd まで」 ○ - - - ○ - ○ ○ - ○ - - ○ 「申請取消可能期間︓mm/dd まで」 - - - ○ - ○ - - ○ - ○ ○ - ≧1,000円であること - - - - ◯ - ◯ ◯ - ◯ - - ◯ 「\0 ￥◯◯を申請済み」であること - - - ◯ - ◯ - - ◯ - ◯ ◯ - 当⽉分の履歴が表⽰されないこと - - - - ◯ - ◯ ◯ - ◯ - - ◯ 当⽉分の履歴が表⽰されること - - ◯ ◯ - ◯ - - ◯ - ◯ ◯ - 当⽉分の履歴が表⽰されないこと - - - - ◯ - ◯ ◯ - ◯ - - ◯ 当⽉分の履歴が表⽰されること - - ◯ ◯ - ◯ - - ◯ - ◯ ◯ - @CB申請画面 「キャッシュバックを申請する」ボタン 「キャッシュバック申請を取消」ボタン 申請期間表⽰（ラベル、⽇付） CB可能額 CB申請履歴 @獲得履歴画面 CB申請履歴 #denatechcon 53

ペアテストデザインの実践例：プッシュ通知 • ホワイトボードに スケッチをして テスト設計技法の 勘所をメンバと共有 54 #denatechcon

ペアテストデザインの実践例：プッシュ通知 • スケッチを成果物としてきちんと整理する 55 #denatechcon

ペアテストデザインを続けると • 当たり前にテスト設計できるようになってくる 56 #denatechcon

ペアテストデザインを続けると • 当たり前にテスト設計できるようになってくる 57 #denatechcon

テスト設計を実践するためには • テスト設計がそれなりにできるリーダが必要 • テストデザインにツッコミを⼊れる⼈が必要：ペアテストデザイン • メンバ間で批判的にレビューするような形式でも良い （ただし、ちょっとつらくなるかも） • テスト設計ができるリーダがいない場合 • テスト設計コンテストを利⽤する (テスト設計コンテストʼ19 申込受付中 締切3⽉6⽇) • ただし部下にお任せにしないで、リーダも⼀緒にやる • 査読のある社外発表に投稿して批判を受ける 58 #denatechcon

テスト設計技法導⼊による効果 • 技法を使ったテスト設計が当たり前になる • テスト設計技法をベースとしたコミュニケーションが取れる • テスト仕様書の理解性が⾼い • 技法の選定→技法で設計、の2段階でレビューできる • テスト仕様書が外部仕様書の代わりになる • テスト設計技法は仕様を整理するための⽅法でもある ⇒テスト仕様書の設計情報を外部仕様として活⽤できる • ⼤中⼩項⽬のテスト仕様書だと 情報量が多すぎて外部仕様としては⾒通しが悪く、保守性も悪い 59 #denatechcon

まとめ：DeNAの品質を⽀えるQAの取り組み • イントロダクション：背景と課題 • 組織横断の改善事例【部⾨・組織の視点】 • 標準テストプロセス • QA⽴ち上げ実践事例【特定のプロダクトの視点】 • やったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 60 #denatechcon

宣伝：DeNA QA Night #2 やります！ • ⽇時：３⽉６⽇（⽔）１９時〜 • 会場：株式会社ディー・エヌ・エー 会議室 • ゲストスピーカー：奈良 隆正 ⽒／⻄ 康晴 ⽒ • 当⽇のコンテンツ • パネルディスカッション • DeNA ゲームQAの発表 61 #denatechcon

ご清聴ありがとうございました 質問・コメントあれば気軽に声かけて下さい！ DeNAの品質を⽀えるQAの取り組み 〜標準化から実践まで〜 河野 哲也 システム本部 品質管理部 QC第⼆グループ #denatechcon #denatechcon

#denatechcon 63 #denatechcon