DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
•
13 likes•7,577 views
DeNA Tech Con で河野が発表した資料です。当日の資料を一部修正しています。
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
- 2. #denatechcon 発表のサマリ •サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA立ち上げの工夫点や実践例を紹介する •話さないこと ⇔ 話すこと • テクノロジー観点のテスト技術 ⇔ 泥臭いテスト技術 • テスト自動化 ⇔ テスト設計 • 単体テスト／結合テスト ⇔ 機能テスト／システムテスト 2
- 3. #denatechcon 市場調査 1. 本業がQA／テストの方 2. 開発もQAも両方やっている方 3. QAはやっていないけど組織やチームの観点でQAに興味がある方 3 開発 QA テストテスト開発 プロダクト 内部リリース
- 4. #denatechcon DeNA 品質管理部：QAの位置づけ •QAは外部仕様を対象としたテストを担当 • ほとんどは手動テスト 4 開発 QA テストテスト開発 単体テスト・結合テスト 機能テスト・システムテスト プロダクト 内部リリース
- 5. #denatechcon 発表のサマリとアウトライン •サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA立ち上げの際の工夫点や実践例を紹介する •アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部門・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA立ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 5
- 6. #denatechcon 自己紹介：河野 哲也(FB:Tetsuya Kouno ) • 現職 • システム本部 品質管理部 QC第二グループ • 主にヘルスケアサービス全般のQA取りまとめ • 部門横断改善活動の旗振り • 新規サービスのQA立ち上げ • 経歴 • 通信機器メーカでハードウェアQA（10年弱） • 電気通信大学で社会人大学、大学院前期・後期課程＋フリーのコンサル • 日立製作所でソフトウェアQA・部門横断のプロセス改善（6年弱） • DeNAでWeb・モバイルのQA（1年4ヶ月） • 得意技：テスト分析・テスト設計 • 委員：ソフトウェア品質シンポジウム委員、 ソフトウェアシンポジウムPC委員、品質管理学会会員 6
- 7. #denatechcon DeNA 品質管理部 • 大小様々なサービス・プロダクトのQA業務を担当 • 開発は現在拡大中、開発プロセス・品質レベルもまちまち • 開発拡大に伴いQAメンバも増加中 • テストベンダ各社から派遣されたメンバが多くを占めている • 技術レベルや経験領域のばらつきも無視できない 7 品質管理部 QC1G QC2G PFチーム CIチーム HCチーム AMチーム ゲームQA SWET
- 8. #denatechcon 横断的な課題 1. テストの進め方が各チームによってバラバラで 統制が取れていない 2. 世の中一般のテスト水準に対して現状の立ち位置が 分からない 3. テスト技術のばらつきが大きく、テストケースの質 が安定しない 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない 8
- 9. #denatechcon 取り組み・施策 9 1. テストの進め方が各チームによってバラバラで 統制が取れていない ⇨テストプロセスの標準化 2. 世の中一般のテスト水準に対して現状の立ち位置が 分からない ⇨TPI NEXTによるテストプロセスのアセスメント 3. テスト技術のばらつきが大きく、テストケースの質が 安定しない ⇨標準テスト観点の整備 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない ⇨テストメトリクス収集の仕組み作り
- 10. #denatechcon 取り組み・施策 10 1. テストの進め方が各チームによってバラバラで 統制が取れていない⇨テストプロセスの標準化 2. 世の中一般のテスト水準に対して現状の立ち位置が 分からない⇨TPI NEXTによるテストプロセスのアセスメント 3. テスト技術のばらつきが大きく、テストケースの質が 安定しない⇨標準テスト観点の整備 4. テストに関するメトリクスが収集できていないため データに基づく議論ができていない ⇨テストメトリクス収集の仕組み作り 課題に対し適切な施策を導出し、施策のボタンを一つずつ押していくことが重要 ボタンの順番を間違えない・ハードルを上げない・焦らない
- 11. #denatechcon 発表のサマリとアウトライン •サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA立ち上げの際の工夫点や実践例を紹介する •アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部門・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA立ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 11
- 12. #denatechcon 組織横断の改善事例 •テストプロセスの標準化 • 標準化の流れと標準プロセスの概説 •TPI NEXTによるテストプロセスのアセスメント • TPI NEXTの概説とアセスメント結果の紹介 •標準テスト観点の整備 • JaSST’19 Tokyo で発表予定のため詳細はそちらで報告 •テストメトリクス収集の仕組み作り • 仕組みの概説 12
- 14. #denatechcon テストプロセスの標準化の流れ（PFDによる表現） • 詳細はこちら（ブログ内にスライドのリンクがあります） DeNA Engineers’ Blog :QA Night #1 開催レポート（第二部） https://engineer.dena.jp/2018/12/qa-night-1-2.html 14 PFチーム のテスト プロセス HCチーム のテスト プロセス CIチーム のテスト プロセス CIチーム のテスト プロセス 見える 化 見える 化 見える 化 見える 化 PFチーム のテスト プロセス HCチーム のテスト プロセス CIチームの テスト プロセス AMチーム のテスト プロセス プロセス の比較・ 共通化 共通的な テスト プロセス 名称の 定義 JSTQB 用語集 など 標準 テスト プロセス ドキュメ ンテー ション 標準テスト プロセス文書 実際の テスト 業務 PFD(Process Flow Diagram)で表現 QAメンバが ハンドブック的に 利用できる 共通は積集合にする 和にすると大変
- 16. #denatechcon 標準テストプロセスをベースとした改善施策 16 キックオフ 議事録 インフラ 整備 発注 DB キックオフ テスト計画書作成 （概算見積もり） テスト計画書 ・テスト方針 ・概算見積もり ・スケジュール テスト 設計 開発 ドキュメント テスト 仕様書 テスト 項目書 標準 観点 一覧 外部発注 準備 テスト 項目 設計 外部発注 処理 テスト見積 (詳細＋チェック) テスト見積書 実績値・参考値 標準見積書 開発レビュー ＋ QAレビュー 開発レビュー ＋ QAレビュー 過去トラブル ・Slack/メール ・Confluence ・ドライブ ・JIRA テスト 実行 テスト対象 不具合 の現象 JIRAの プロジェクト テスト 進捗の 報告 テスト 結果 報告書 の作成 不具合 の起票 報告 メール テスト 結果 報告書 サインオフ 合意形成 QA レビュー 振り返り ナレッジ ナレッジ の蓄積 レビュー
- 17. #denatechcon TPI NEXTによるテストプロセスのアセスメント •目的 • 把握：現状の各チームのテストプロセスを共通のものさしで把握する • 改善：世の中の標準的な視点で改善ポイントを探る • 各チームの代表的なサービスのテストプロセスを対象にアセスメント •TPI NEXT：テストプロセス改善モデル • テストプロセス成熟度の評価／テスト成熟度マトリクス⇨見える化 • 157のテスト活動に関するチェックポイントに回答することにより評価 例）テスト戦略はプロダクトリスクに基づいている テスト戦略には適切なテスト設計技法を含めている • 評価結果に基づく改善／クラスタセット⇨改善のための指針 • テストプロセスというよりはテスト活動全体に対しての改善 17
- 18. #denatechcon アセスメント結果 18 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 利害関係者のコミットメント 関与の度合い テスト戦略 テスト組織 コミュニケーション 報告 テストプロセス管理 見積もりと計画 メトリクス 欠陥管理 テストウェア管理 手法の実践 テスト担当者のプロ意識 テストケース設計 テストツール テスト環境 TPI NEXTアセスメント結果（各チーム達成率） QC1G PF C&I HC AM • 長所：利害関係者との コミットメント／ コミュニケーション／関与 の度合い • プロセス的な観点ではなく 事業部との関係性を重要視 • 開発プロセスに応じて 臨機応変に対応している • 短所：テスト戦略／ 見積もりと計画／ メトリクス／テストツール • テスト計画に戦略的視点がない • データに基づく活動担っていない • ツールの検討が体系だっていない
- 20. #denatechcon 標準テスト観点の一例 観点タイトル Level1 Level2 Level3 ログイン 複数ブラウザからの多重ログ イン ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ Android-Android ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ Android-iOS ログイン 複数端末からの多重ログイン OS別アプリの組み合わせ iOS-iOS ログイン 複数アカウントの切り替え ログイン 既存アカウントへのログイン ログイン 連続認証失敗 失敗回数許容上限の超過 20 • 約900観点を導出・整理した
- 21. #denatechcon テストメトリクス収集の仕組み作り • テスト活動に関わるメトリクスの収集 • 標準テストプロセスをベースに収集データを定義 • 一通りのプロセスが終了したらデータを登録する • メトリクスの活用例（GQMによる表現） • Goal１：テストプロセスの各プロセスの工数割合がわかっている • Question1：案件ごとの各プロセスの工数は全体に対してどれくらいか？ • Metric1：テスト計画・テスト設計・テスト実行の工数 • Goal2：テスト計画・振返りが徹底できているか把握できている • Question2：案件ごとのテスト計画・振返りの工数は全体に対して どれくらいか？ • Metric2：テスト計画・振返りの工数、全体の工数 21
- 23. #denatechcon 組織横断の改善事例 •テストプロセスの標準化 • 標準化の流れと標準プロセスの概説 •TPI NEXTによるテストプロセスのアセスメント • TPI NEXTの概説とアセスメント結果の紹介 •標準テスト観点の整備 • JaSST’19 Tokyo で発表予定のため詳細はそちらで報告 •テストメトリクス収集の仕組み作り • 仕組みの概説 23
- 24. #denatechcon 発表のサマリとアウトライン •サマリ • ゲーム以外の領域にフォーカスする • 組織全体に対しての課題とその改善事例を報告する • 新規サービスのQA立ち上げの際の工夫点や実践例を紹介する •アウトライン • イントロダクション：背景と課題 • 組織横断の改善事例【部門・組織の視点】 • 標準テストプロセス・TPI NEXT・テスト観点・メトリクス • QA立ち上げ実践事例【特定のプロダクトの視点】 • 標準テストプロセスの実装、テスト設計の実践 24
- 26. #denatechcon 事例の背景 •開発とのコミュニケーション開始が2017年12月 • 企画が柔らかい段階で声をかけてもらった：重要ポイント •このタイミングでQAの立ち上げ開始 • 「開発と一緒にやること／決めること」 「QA内部でやること／決めること」 を洗い出し一つずつ解決していく •昨年にWebβ版ローンチ、現在アプリ開発中 • 現状、QAは立ち上げ期から安定期にシフト 26
- 27. #denatechcon 開発のコンテキスト • 4名が専任、1名オンデマンド • サーバ、フロント、プロダクト、ビジネス、デザイン • ドキュメンテーションできるほど工数・予算的に余裕がない • β版の開発 • 顧客に提供できる最小限のプロダクト（Webサービス） • 現在はアプリ開発中 • 開発プロセス：リーンスタートアップ開発＋ アジャイル・スクラムのプラクティスをいくつか導入 • QAの単位：実装の終わった機能からQAにリリース（QAサイクル） • 基本的には機能テスト以降を実施 • 開発者はローカル環境で簡単な機能テストを実施してリリース 27
- 28. #denatechcon QAのコンテキスト • メンバ構成 • Webβ版QA対応 • 2017年12月〜：1名専任、1名オンデマンド対応 • 2018年4月〜7月：2名専任、1名オンデマンド対応 • アプリQA対応 • 2018年9月〜：1名専任、1名オンデマンド対応 • 経験豊富なメンバをアサインできたわけではない • ただし技術的な観点においてモチベーションが高いメンバ • QAの制約 • 低予算での対応 ⇨テスト工数が限られており詳細なテスト項目を設計する時間が無い • 開発ドキュメントが不確定（変更が多い） 28
- 31. #denatechcon QAの立ち上げのときに何をやりますか？ • 例えば、 QAメンバの調達・調整 テストプロセスの検討 31 開発 QA テスト開発 プロダクト 内部リリース 人 プロセス技術
- 32. #denatechcon 開発⇔QAでやったこと／決めたこと 【基本方針：エンジニアが開発にフォーカスできるように支援する】 • 開発状況ヒアリング • 開発のリソースの把握：どこまでドキュメントを作れるのか？ • スケジュールと予算：どの期間でどれくらいのQAリソースが必要なのか？ • 対象サービスと品質レベル：必要なQAスキルは？QAのボリュームは？ • 開発プロセスを踏まえたテストプロセス • テスト対象のリリースフロー：プロセスを回す単位を決める(QAサイクル) • 細かい機能の実装が終わった段階でリリースされる • QAからの貢献も一緒に考える⇨【QAで外部仕様書を作成する】 • インシデントレポート（バグチケット）の運用定義 • 入力項目の定義、処理フローの定義とそれらの開発者との合意形成 • 開発⇔QAのやり取りのインフラ • コミュニケーション手段、ドキュメント 32
- 33. #denatechcon QA内部でやったこと／決めたこと 【基本方針：アジリティのあるテストを目指す】 •標準テストプロセスの実装【詳細解説】 • テスト計画書、テスト仕様書、テスト完了報告書 • 成果物をどのレベルまで作るかを決める •探索的テストの導入 • ユーザビリティ観点のテスト、など •テスト設計の実践【詳細解説】 • テスト設計技法にこだわる •スクラムプラクティスの導入 • バックログ管理／朝会と Daily Scrum • WeeklyのKPTとテスト業務のプランニング 33
- 34. #denatechcon QA立ち上げに検討が必要なことリスト【一般化】 • QAで確保できるリソースの調整 • 予算、人員、スキル • 開発プロセスを踏まえたテストプロセスの構築 • 作成するテスト成果物の定義とテンプレ作成 • テスト計画書、テスト仕様書、テスト報告書 • 特にテスト仕様書をどこまで細かく書くかは今後のテスト工数や スピードに大きく影響するので注意が必要 • インシデントレポートの運用方法の定義 • 開発⇔QAのやり取りのインフラ • QAチームのマネジメント • チームビルディング • テスト業務の割り振り：誰がどの業務を担当するのかを決める 34
- 36. #denatechcon 標準テストプロセスの実装 • 開発形態やQA状況に応じて標準をテーラリング • テスト設計技法を活用してテスト設計を軽く・スピーディーにする • テスト設計の段階でデザインとDev環境を見ながら最新の仕様を確認する • テスト仕様書をベースに最新の仕様を反映した外部仕様書を作成する 36 リリース単位 の仕様 仕様 共有会 テスト 実行 共有会 メモ テスト 計画書 テスト 計画 テスト 仕様書 テスト 設計 テスト 結果 報告書 テスト結果 報告書 作成 外部仕様書 PRD JIRAの プロジェクト 不具合 チケット 外部 仕様 作成 標準 テスト観点 Dev 環境 デザ イン 環境 ＋
- 39. #denatechcon テストの例：アドホック • 大きな流れ：テスト計画→テスト設計→テスト実行 39 1. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる 2. エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する 3. エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる 4. パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する この仕様をベースに テスト対象サービスを触りながら テストをしては行けない ⇓ どんなテストをやるのかを テスト設計しないといけない
- 40. #denatechcon テストの例：仕様の書き写し • 大きな流れ：テスト計画→テスト設計→テスト実行 40 1. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる 2. エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する 3. エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる 4. パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する No. 確認内容 1 エントリー画面の「規約同意」がチェック済みになると「エ ントリー」ボタンが活性状態になること 2 エントリー画面でエントリーコードを入力し、「エント リー」ボタンを押下し、エントリーコードが無効だった場合 はエラーメッセージを表示すること 3-1 エントリーコードが有効だった場合、エントリーに成功しパ スワード登録URLが記載されたメールが当該ユーザーのメール アドレスに送付されること 3-2 URLには有効期限があり、１０分で期限切れとなること 4-1 パスワード登録画面で「パスワード入力」と「パスワード （確認用）入力」が一致していればパスワード登録すること 4-2 パスワードは６文字以上８文字以内とし、文字種別は「小文 字、大文字、数字、記号」とし、その範囲以外の場合はエ ラーメッセージを表示すること 仕様を書き写すだけでは不十分
- 41. #denatechcon テストの例：大中小項目 • 大きな流れ：テスト計画→テスト設計→テスト実行 41 1. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる 2. エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する 3. エントリーコードが有効だった場合、エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる 4. パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合はエラーメッセージを表示する 大中小項目でも不十分 No. 大項目 中項目 小項目 1 エントリー 画面 規約チェック ボックス OFF 2 ON 3 エントリー コード 無効 4 有効 5 パスワード 登録画面 URL 有効期限 期限切れ：10分経過 6 期限内：10分以内 7 パスワード 桁数が最小値-1 8 桁数が最大値+1 9 小文字、大文字、数字、記号 以外 10 確認用パスワードと不一致 11 有効：桁数が最小値 12 有効：桁数が最大値
- 42. #denatechcon テストの例：テスト設計技法によるテスト設計 • 大きな流れ：テスト計画→テスト設計→テスト実行 42 1. エントリー画面の「規約同意」チェックボックスが チェック済みになると、 「エントリー」ボタンが活性状態になる 2. エントリー画面でエントリーコードを入力し、 「エントリー」ボタンを押下する エントリーコードが無効だった場合は エラーメッセージを表示する 3. エントリーコードが有効だった場合、 エントリーに成功し パスワード登録URLが記載されたメールが 当該ユーザーのメールアドレスに送付される URLには有効期限があり、１０分で期限切れとなる 4. パスワード登録画面で「パスワード入力」と 「パスワード（確認用）入力」が一致していれば パスワードを登録する パスワードは６文字以上８文字以内とし、 文字種別は「小文字、大文字、数字、記号」とし、 その範囲以外の場合は エラーメッセージを表示する テスト設計技法を使ってテスト設計する
- 43. #denatechcon テスト設計の実践：テスト設計技法にこだわる •今までのテスト設計 • 大中小項目でのテスト観点の整理→ローレベルテストケースの作成 • 上記ドキュメントでは外部仕様を表現できない •テスト設計技法を使いこなす • 技法を勉強しながら、勘所を習得→【ペアテストデザイン】 • QAメンバには新しい技術を習得したいという意欲が必要 • テスト設計技法を使って作成したテスト仕様書は 外部仕様として活用できる •参考資料 • JaSST’18 Kyushu 基調講演 「品質・仲間・技術と向き合ってテスト設計技法の力を引き出す」 http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf 43
- 45. #denatechcon テスト設計の例：うるう年の計算 • うるう年は以下で決まる (引用：ソフトウェアテスト技法ドリル) １）西暦年が４で割切れる年はうるう年 ２）ただし、西暦年が１００で割切れる年は平年 ３）ただし、西暦年が４００で割切れる年はうるう年 例：２０１２年と２０００年はうるう年、 ２０１３年と２１００年は平年 45 入力データ 出力データ 2000年 うるう年 2100年 平年 2012年 うるう年 1999年 平年
- 46. #denatechcon テスト設計の例：うるう年の計算 • うるう年は以下で決まる (引用：ソフトウェアテスト技法ドリル) １）西暦年が４で割切れる年はうるう年 ２）ただし、西暦年が１００で割切れる年は平年 ３）ただし、西暦年が４００で割切れる年はうるう年 例：２０１２年と２０００年はうるう年、２０１３年と２１００年は平年 46 原因 1 2 3 4 入力データ 400で割切れる年 ○ - - - 400で割切れないで100で割切れる年 - ○ - - 100で割切れないで4で割切れる年 - - ○ - 4で割切れない年 - - - ○ 結果 - - - - 出力データ 平年 - ● - ● うるう年 ● - ● -
- 47. #denatechcon テスト設計の例：ストップウォッチ 47 1. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 2. 動いている最中にスタートボタンを押すと 停止する 3. 停止状態でスタートボタンを押すと そこから再スタートする 4. 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 5. 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる 6. ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引用：ソフトウェアテスト技法ドリル）
- 48. #denatechcon テスト設計の例：ストップウォッチ 48 1. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 2. 動いている最中にスタートボタンを押すと 停止する 3. 停止状態でスタートボタンを押すと そこから再スタートする 4. 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 5. 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる 6. ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引用：ソフトウェアテスト技法ドリル） 原因 1 2 3 4 5 6 7 8 現在の状態 デフォルト ○ ○ - - - - - - 動作中 - - ○ ○ - - - - 停止中 - - - - ○ ○ - - ラップ表示中 - - - - - - ○ ○ ボタン スタートボタン ○ - ○ - ○ - ○ - ラップボタン - ○ - ○ - ○ - ○ 結果 - - - - - - - - 遷移後の状態 デフォルト - - - - - ● - - 動作中 ● - - - ● - - ● 停止中 - - ● - - - - - ラップ表示中 - - - ● - - - - 無効 - ● - - - - ● -
- 49. #denatechcon テスト設計の例：ストップウォッチ 49 1. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 2. 動いている最中にスタートボタンを押すと 停止する 3. 停止状態でスタートボタンを押すと そこから再スタートする 4. 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 5. 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる 6. ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引用：ソフトウェアテスト技法ドリル） 動作中 停止中 ラップ 表示中 初期状態 スタート スタート ラップ ラップ ラップ スタート デフォ ルト
- 50. #denatechcon テスト設計の例：ストップウォッチ 50 1. デフォルト状態でスタートボタンを押すと ストップウォッチが動き出す 2. 動いている最中にスタートボタンを押すと 停止する 3. 停止状態でスタートボタンを押すと そこから再スタートする 4. 停止状態でラップボタンを押すと リセットされデフォルト状態に戻る 5. 動いている最中にラップボタンを押すと 表示は停止するが内部は動いているラップ 表示状態になる 6. ラップ表示状態でラップボタンを押すと 計測開始からのトータル時間から再開する (引用：ソフトウェアテスト技法ドリル） 動作中 停止中 ラップ 表示中 初期状態 スタート スタート ラップ ラップ ラップ スタート デフォ ルト
- 51. #denatechcon テスト設計の実践：テスト設計技法にこだわる •今までのテスト設計 • 大中小項目でのテスト観点の整理→ローレベルテストケースの作成 • 上記ドキュメントでは外部仕様を表現できない •テスト設計技法を使いこなす • 技法を勉強しながら、勘所を習得→【ペアテストデザイン】 • QAメンバには新しい技術を習得したいという意欲が必要 • テスト設計技法を使って作成したテスト仕様書は 外部仕様として活用できる •参考資料 • JaSST’18 Kyushu 基調講演 「品質・仲間・技術と向き合ってテスト設計技法の力を引き出す」 http://www.jasst.jp/symposium/jasst18kyushu/pdf/S4.pdf 51
- 53. #denatechcon ペアテストデザインの実践例：申請系の機能 • スケッチをベースに成果物としてきちんと整理する 53 1 2 3 4 5 6 7 8 9 10 11 12 13 前状態 CB可能額 有効（≧1,000円） - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（＜1,000円） ◯ - - - - - - - - - - - - 期間 ※ 有効（申請期間中） ◯ - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（申請開始前） - ◯ - - - - - - - - - - - 無効（申請期間締め後） - - - - - - - - - - - - - 申請 確認ダイアログ OK（申請する） - - ◯ ◯ - ◯ ◯ - - - - - - NG（キャンセルする） - - - - ◯ - - ◯ ◯ - - - - 申請取消 確認ダイアログ OK（申請取消） - - - - - - - - - ◯ ◯ - - NG（キャンセルする） - - - - - - - - - - - ◯ ◯ 期間 ※ 有効（申請期間中） - - - - - ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ 無効（申請開始前） - - - - - - - - - - - - - 無効（申請期間締め後） - - ◯ - - - - - - - - - - 申請 確認ダイアログ OK（申請する） - - - - - - - - ◯ - ◯ - - NG（キャンセルする） - - - - - - - ◯ - ◯ - - - 申請取消 確認ダイアログ OK（申請取消） - - - - - - ◯ - - - - - ◯ NG（キャンセルする） - - - - - ◯ - - - - - ◯ - 期待値 CB申請画面 再表示 - - - - ◯ ◯ ◯ ◯ - ◯ - ◯ ◯ 申請完了ダイアログ→ホーム画面 - - - ◯ - - - - ◯ - ◯ - - @CB申請画面 非活性状態であること ○ ○ ○ - - - - - - - - - - 活性状態であること - - - - ○ - ○ ○ - ○ - - ○ 非活性状態であること - - - - - - - - - - - - - 活性状態であること - - - ○ - ○ - - ○ - ○ ◯ - 「次の申請期間：mm/dd-mm/dd」 - ○ ○ - - - - - - - - - - 「申請期間中：mm/dd まで」 ○ - - - ○ - ○ ○ - ○ - - ○ 「申請取消可能期間：mm/dd まで」 - - - ○ - ○ - - ○ - ○ ○ - ≧1,000円であること - - - - ◯ - ◯ ◯ - ◯ - - ◯ 「0 ￥◯◯を申請済み」であること - - - ◯ - ◯ - - ◯ - ◯ ◯ - 当月分の履歴が表示されないこと - - - - ◯ - ◯ ◯ - ◯ - - ◯ 当月分の履歴が表示されること - - ◯ ◯ - ◯ - - ◯ - ◯ ◯ - @獲得履歴画面 当月分の履歴が表示されないこと - - - - ◯ - ◯ ◯ - ◯ - - ◯ 当月分の履歴が表示されること - - ◯ ◯ - ◯ - - ◯ - ◯ ◯ - CB申請履歴 申請期間表示（ラベル、日付） 画面遷移 CB可能額 1番目に実行する機能／アクション 2番目に実行する機能／アクション 確認項目 CB申請履歴 「キャッシュバック申請を取消」ボタン 「キャッシュバックを申請する」ボタン
- 58. #denatechcon テスト設計を実践するためには •テスト設計がそれなりにできるリーダが必要 • テストデザインにツッコミを入れる人が必要：ペアテストデザイン • メンバ間で批判的にレビューするような形式でも良い （ただし、ちょっとつらくなるかも） •テスト設計ができるリーダがいない場合 • テスト設計コンテストを利用する (テスト設計コンテスト’19 申込受付中 締切3月6日) • ただし部下にお任せにしないで、リーダも一緒にやる • 査読のある社外発表に投稿して批判を受ける 58
- 59. #denatechcon テスト設計技法導入による効果 •技法を使ったテスト設計が当たり前になる • テスト設計技法をベースとしたコミュニケーションが取れる • テスト仕様書の理解性が高い • 技法の選定→技法で設計、の2段階でレビューできる •テスト仕様書が外部仕様書の代わりになる • テスト設計技法は仕様を整理するための方法でもある ⇒テスト仕様書の設計情報を外部仕様として活用できる • 大中小項目のテスト仕様書だと 情報量が多すぎて外部仕様としては見通しが悪く、保守性も悪い 59
- 60. #denatechcon まとめ：DeNAの品質を支えるQAの取り組み •イントロダクション：背景と課題 •組織横断の改善事例【部門・組織の視点】 • 標準テストプロセス •QA立ち上げ実践事例【特定のプロダクトの視点】 • やったこと／決めたこと • 標準テストプロセスの実装 • テスト設計の実践 60
- 61. #denatechcon 宣伝：DeNA QA Night #2 やります！ • 日時：３月６日（水）１９時〜 • 会場：株式会社ディー・エヌ・エー 会議室 • ゲストスピーカー：奈良 隆正 氏／西 康晴 氏 • 当日のコンテンツ • パネルディスカッション • DeNA ゲームQAの発表 61