Slide 1

Slide 1 text

組み込み開発のテストと ゲーム開発のテストの違い グリー株式会社 QAグループ シニアマネージャー 堀⽶ 賢

Slide 2

Slide 2 text

2 ⾃⼰紹介 ⽒名と所属 主な仕事内容 略歴 堀⽶ 賢(ほりごめ さとし) Customer & Product Satisfaction部 QAグループ シニアマネージャー 障害削減、QAコスト最適化の推進 リスクマネジメント、プロダクト品質向上提案 QAグループ技術向上の推進 など 組み込み系ソフトウェアのテスト技術者を経て グリーに⼊社。ベンダ連携やテスト内容の改善、 メンバーの技術向上に向けた勉強会開催など幅 広く活動中。 CEDECに過去4回登壇

Slide 3

Slide 3 text

3 今回お話する前提 製品例 開発プロセス 開発期間 テスト規模 組み込み開発 ゲーム開発 ウォーターフォール型 (派⽣開発が多い) アジャイル型 (新規と運⽤がある) 半年〜数年 新規︓1〜2年(増加傾向) 運⽤︓数⽇〜数週間 数⼗⼈ 新規︓10〜20⼈ 運⽤︓数⼈ ※期間、規模は⼀例です。 ※あくまで個⼈の経験/⾒聞の範囲となるため、⼀般論と異なる内容も含まれます。

Slide 4

Slide 4 text

4 今回お話すること 1.構成管理の違い 2.テスト設計⽅法の違い 3.テスト体制の違い 4.さいごに

Slide 5

Slide 5 text

5 今回お話すること 1.構成管理の違い 2.テスト設計⽅法の違い 3.テスト体制の違い 4.さいごに

Slide 6

Slide 6 text

6 ソフトウェアの更新管理 組み込み開発 ゲーム開発 フェーズ 開発 α β1 βn … 既存機 能実装 追加機能 実装① … 追加機 能実装 n β1不具 合修正 βn不具 合修正 特徴 α β … 基本機 能実装 アセット変更 本番デ ータ⼊ 稿 仮データ⼊ 稿 … インクリメンタルな開発で、各フェーズご とに計画された機能を実装する。 バージョンは規則的に設定され、更新タイ ミングがそのまま開発のマイルストンにな る。 イテレーティブな開発で、随時アセットを 更新/変更する。 バージョン内での開発要件が流動的で、要 件リストなどを⽤いることがある。 テスト⽤ビルドのバージョンは都度確認。 … …

Slide 7

Slide 7 text

7 仕様の更新管理 組み込み開発 ゲーム開発 運⽤ 特徴 既存モデルの仕様書をベースに、新規機能 分を追加し、バージョンをインクリメント する。 要件追加等で開発中に変更があった場合、 変更分とバージョンを更新する。 開発の全体像となる機能は、箇条書きや要 件ベースでドキュメント化されることがあ る。 仕様の変動が多いため、都度の更新はせず にリスト管理などで運⽤する。 v1.0.0 既存機能 v1.1.0 追加機能込 変更管理 シート 仕様書 開発要件 リスト

Slide 8

Slide 8 text

8 ゲームのテストに活⽤した点 ・ゲーム開発は、仕様/ソフトウェアの変更や追加、削除が多くプロジェクトの変動性が⾼い。 ・マクロな視点で、⾒積もりやテスト内容をコントロールすることが重要(その上でテスト技術が⼤事)。 変更が多いため、ミ クロな視点になりが ち マクロな視点で全体 をコントロールする ことが重要 ・場当たり的なアサイン ・テストの重複 ・計画的なアサイン ・重複の抑制

Slide 9

Slide 9 text

9 今回お話すること 1.構成管理の違い 2.テスト設計⽅法の違い 3.テスト体制の違い 4.さいごに

Slide 10

Slide 10 text

10 テスト設計⽅法の特徴 組み込み開発 ゲーム開発 開発の特 徴 ・仕様の変動が少なく、段階的に機能開発 する ・機能不具合が返品や事故につながる可能 性があるため、安⼼/安全を重視する ・仕様の変動が多く、実装済の機能に対し ても後から変更されることがある ・ユーザーから⾒た価値が変動しやすく、 市場において、より魅⼒的であるかを重視 する テスト設 計の特徴 ・⾼いカバレッジを達成するためにテスト アーキテクチャ設計をする ・機能テストは詳細なローレベルテストケ ースを⽤いる ・経験ベースのテストや探索的テストは機 能テストを補完するかたちで実施する ・組み合わせや条件を網羅するためにテス ト設計技法を適⽤する ・仕様変更に対応するため、⼀部機能につ いては抽象度の⾼いハイレベルテストケー スを⽤いる ・経験ベースのテストや探索的テストは機 能テストと並⾏して⼀定の⼯数をかけて実 施する ・状態の変化や設定の境界を網羅するため にテスト設計技法を適⽤する

Slide 11

Slide 11 text

11 ゲームのテストに活⽤した点 ・仕様の変動が多いため、テストの抽象度が⾼く属⼈化しやすい。また網羅性が確認しづらい。 ・テストケース詳細化の粒度とテスト観点の教育、網羅性の可視化などが重要。 機能 ⼿順 期待結果 チュートリアル チュートリアルを進⾏する チュートリアルが問題なく進⾏する こと ※テストケース例 機能 事前条件 ⼿順 期待結果 チュートリ アル 開始 インストール 後の初回起動 ゲームを開始する チュートリアルが始ま ること クエス ト ↑から継続し て進⾏ クエストへの案内 を選択する クエストの説明が始ま ること ・・・ 観点説明資料 マニュアル等 + ・属⼈化しやすい ・テストできているか不明瞭 ・⼀定⽔準でテストできる ・テスト内容が明確

Slide 12

Slide 12 text

12 今回お話すること 1.構成管理の違い 2.テスト設計⽅法の違い 3.テスト体制の違い 4.さいごに

Slide 13

Slide 13 text

13 稼働場所とアサイン⽅法 組み込み開発 ゲーム開発 オンサイ ト オフサイ ト 開発担当 テスト担当 テスト リーダー テスト メンバー テスト メンバー 接続互換性テスト、多端末テストなど で稼働する可能性あり。 開発担当 テスト担当 テスト リーダー スタジオ リーダー テスト メンバー テスト メンバー ※テストメンバー は固定アサイン ※テストメンバー は都度アサイン

Slide 14

Slide 14 text

14 ゲームのテストに活⽤した点 ・スケジュールの変動が多いことなどから、固定したアサインが難しい。 ・精度の⾼いテストを実現するために必要な情報連携を意識したテストスタジオとの関係構築が重要。 ⾃ 社 ス タ ジ オ テスト担当 テスト リーダー スタジオ リーダー テスト メンバー テスト メンバー 密な状況連携 ・アサインミスの抑制 ・テスト精度の向上

Slide 15

Slide 15 text

15 今回お話すること 1.構成管理の違い 2.テスト設計⽅法の違い 3.テスト体制の違い 4.さいごに

Slide 16

Slide 16 text

16 さいごに ソフトウェアテストの対象ドメイン例 ・ソフトウェアテストのアプローチは様々で、対象ドメインの違いで変わってくるが共通することも多々ある ・それぞれの特徴を認識して、参考にすることで現場課題の解決につながる可能性がある

Slide 17

Slide 17 text

17