テスト設計コンテスト’16 決勝@日本大学理工学部

カラオケシステムのテストを設計した話
2016年3月9日

チーム名：しなてす
あみー、めい、まえたさん、はるはる
発表する人
しなてす

1

チーム紹介• テスト設計コンテスト出場にあたり、チーム名を決めようぜ！というときに、メンバーの時間的中間点である品川でソフトウェアの品質を語っていたという背景から、 “品川”と“品質”の品をメインに省略して、「しなてす」としました。
• メンバーはいろんな会社の４人で、WACATE２０１２夏でWACATEに初参加したメンバーを中心に結成しています。
あみー• 今回4回目の参加で、昨年初優勝！目指せ2連覇！！
まえたさん

はるはる

しなてす

めい2

発表の流れ
1
2 テスト
要求
分析

何をどんな目的でテストするのか

背景・テスト全体像

3 テストアーキテクチャ
設計

どのようにテストするのか

4

テスト
詳細
設計

個々のテストをどのようにするのか
しなてす3１．背景、全体像• 今回しなてすはカラオケ機器開発メーカーA社に依頼され、開発チームと協力しながらシステムテスト工程を担当する第三者・・・という設定。
カラオケシステムの開発者
B社(カラオケ事業の展開)

A社(カラオケ機器を開発)

開発依頼

サプライヤ

開発・運用・利用店舗での 保守依頼
運用依頼

しなてす
テストの(第三者検証)
相談

カラオケ装置 音響開発チーム 専門家

C社(サーバの開発・運用・保守)
カラオケシステムの開局・閉局

カラオケシステムの利用者
オーナー

しなてす

ボックス店ユーザ

協力してテストを進める

ナイト店ユーザ4１．背景、全体像• テストプロセス
テストベース

テスト
要求
分析

テストアー
キテクチャ
設計

TD01

テスト要求
分析書
・テストの全体像
・テスト観点モデル

しなてす

テスト
詳細設計

TD02

テストアーキテクチャ設計書
・テスト観点同士の関係性
・テストアーキテクチャ

TD03

テスト詳細
設計書
・テストケース5

２．テスト要求分析• テストプロセス
テストベース

テスト
要求
分析

テストアー
キテクチャ
設計

TD01

テスト要求
分析書
・テストの全体像
・テスト観点モデル

しなてすテスト詳細
設計

TD02

テストアーキテクチャ設計書
・テスト観点同士の関係性
・テストアーキテクチャ

TD03

テスト詳細
設計書
・テストケース6

２．テスト要求分析• 目的– テスト対象であるカラオケシステムのテスト要求を見出すこと

何をどんな目的でテストするのかまとめるプロセス
ステークホルダ一覧
テストの全体像・目的の確認

テストの全体像

テスト観点の抽出

テスト観点
モデル

テストベース

しなてす7

２．テスト要求分析• 目的– テスト対象であるカラオケシステムのテスト要求を見出すこと

何をどんな目的でテストするのかまとめるプロセス
ステークホルダ一覧
テストの全体像・目的の確認

テストの全体像

テスト観点の抽出

テスト観点
モデル

テストベース

しなてす8

２．テスト要求分析【ポイント0】テスト目的の確認• 今回のカラオケシステム開発の目的である2点現行機とのリプレイスや他社機との入れ替えを促進する。
快適でリッチな経験を利用者に提供する。
本システムがこれらを達成することを保証したい。

？
しなてす

9

２．テスト要求分析【ポイント1】テストレベルの定義– システムの目的を達成するために検証すべきこと検討した。
現行機とのリプレイス
他社機との入れ替えシステムが仕様通りに動くことの検証☑システムが、仕様書に明示されている機能要求、機能外要求、状態遷移どおりに動作することをテスト

快適でリッチな体験

現行機・他社機より開発機の性能や機能が優れていることの検証

さまざまな利用シーンで正常動作することの検証

さまざまな利用シーンでユーザが良い体験をできることの検証☑ベンチマークの取得と比較→これはA社の担当とする。

☑ユーザがとりうるシ ☑左で抽出した利用ステムの利用方
方法で、利用者が法を抽出
良い経験をできる☑それらの利用方法
かテストで問題なくシステムが動作することをテスト
10

２．テスト要求分析【ポイント1】テストレベルの定義– 目的達成のため、検証すべきことを段階的に達成するよう、ステップで捉えた。
– それらのステップに名前をつけ、テストレベルとして扱う。
テストレベル名称

テストレベルの目的

アプリケーション
仕様テスト（アプリ仕様テスト）
アプリケーション
利用テスト（アプリ利用テスト）
ユーザ経験テスト【ステップ1】
仕様書に明示された要件の動作を保証する。
【ステップ2】
利用シーンにおける動作保証をする。
【ステップ3】
利用シーンにおいて利用者が良い経験ができることを保証する。

11

２．テスト要求分析【ポイント1】テストレベルの定義• 各テストレベルを誰が担当するか、ステークホルダの特性を踏まえてテストチーム編成の検討を行った。
設計・実装

テスト

客観的にテストします

ユーザ経験テスト
A社
テスト依頼

アプリ利用テスト

しなてす
担当

指示
結果報告
アドバイス

デバッグ依頼アプリ仕様テスト

仕様は任せて！

A社担当

選出されたユーザユーザとして正直に評価するわ！

12

２．テスト要求分析• 目的– テスト対象であるカラオケシステムのテスト要求を見出すこと

何をどんな目的でテストするのかまとめるプロセス
ステークホルダ一覧
テストの全体像・目的の確認

テストの全体像

テスト観点の抽出

テスト観点
モデル

テストベース

しなてす

13

２．テスト要求分析【ポイント2】 アプリ利用・ユーザ経験テストの観点の抽出– システム利用者の要求を実現するためのカラオケシステムの使われ方や機能（これをサービスと呼ぶ）を導出し、利用者の利用シーンにおける動作を確認するためのテスト観点を作成した。
タイムライン
ユーザのタイムライン

オーナーのタイムライン①待機中③常時サービスの対象者
ボックス店
ユーザ

ナイト店
ユーザ

オーナー

○

○

○

①待機中

○

○

①待機中

○

○

利用シーンから抽出した
対象者の持つ要求
これから登場する新しい機器を接続したい
会話をしたい時間をつぶしたい
居心地のよい空間を提供したい
曲間に採点ゲームをやめたい

対象者が受けるサービス

要求No

これから登場する新しい機器を接続・利用する

RQ_01

カラオケが気にならない

RQ_02

歌唱していないときに採点ゲームをやめる

RQ_03①利用者の要求を、要求の発生時期で並べ、タイムラインの網羅を意識して受けたいサービスを抽出した

しなてす

14

２．テスト要求分析【ポイント2】 アプリ利用・ユーザ経験テストの観点の抽出要求
No

サービスの対象者
ボックス店
ユーザ

ナイト店
ユーザ

オーナー

RQ_01

○

○

○

RQ_02

○

○

RQ_03

○

○

RQ_04

○

○

対象者が受けるサービス

カラオケシステムに期待すること（テスト観点）②サービスを基に、カラオケシステムにこれから登場する新しい機器を接続でき、認識・使用できること期待すること（テスト観点）を導いた
歌っていない時間に、曲を流しBGMにできること

これから登場する新しい機器を接続・利用する
カラオケが気にならない

楽曲再生以外の動作時にカラオケ装置本体の動作音がうるさくないこと
外部入力映像の音量バランスが適当であること

歌唱していないときに採点ゲームをやめ 曲間に採点ゲームの設定を変えられることる
全国ランキングと採点結果が比較できること
全国ランキングと採点結果の比較を見る③ズームイン、ズームアウトを行い、テスト観点を適切な粒度に整えたユーザ経験テストの観点を示した。

カラオケシステムに期待すること（アプリ利用テストのテスト観点）

親観点

テスト観点

楽曲再生、マイク、映像、テロップが連携して機能すること

右の2つは上の観点の子観点であることを示している。 複数のマイクの入力、テロップが連携しテスト子観点

カラオケシステムに期待する（ユーザ経験テストのテスト観

子観点
ボックス店構成で楽曲再生、マイク、映像、テロップが連携して機能することナイト店構成で楽曲再生、マイク、映像、テロップが連携して機能すること

ボックス店構成で歌を歌えるこ

ナイト店構成で歌を歌えること
複数人で同時に歌えることて機能すること歌っていない時間に、曲を流しBGMにできること

しなてす

歌っていないときに曲を流せる

15

２．テスト要求分析【ポイント2】 アプリ利用・ユーザ経験テストの観点の抽出– アプリ利用テスト、ユーザ経験テストの観点抽出のための取り組
みではあったが、アプリ仕様テストの観点も出てきたので、観点が適切なテストレベルで扱われるよう見直した。
テスト観点

テスト子観点

質問事項

仕様で定めている
BB/NB環境でサーバやリモコン等の機器と接続できること対応する
テストレベル

対応するテストレ
ベルの理由

要求
No

アプリ仕様

3-1-1通信種別設
定 のテストに包含されるため

RQ_50

障害による悪影響が小さくなること

テスト観点ID

RQ_51,RQ_
TVP-S-011
54,RQ_59
機器トラブルの原因や対処法が分かりやすく伝えられること
障害発生時にも最低限動作すること

どのような機器トラブル アプリ利用/を想定し、どのような対ユーザ経験応をするか？(TQ_30)
機器トラブル発生時の最低限のカラオケシステ
ムが提供する機能は何アプリ利用か？(TQ_23)④導いたテスト観点を、適切なテストレベルに振り分けた

TVP-S-011-1

TVP-S-011-2

観点を扱うべき
テストレベル16

２．テスト要求分析【ポイント3】 テスト観点抽出時からテストコンテナを活用– テストコンテナとはいくつかのテスト観点の意味をもった塊である。
– テストコンテナを並べ関係を示すことで、全体が俯瞰しやすい。
– しなてすはこれ以降この形式を一貫して使用し、要求分析とアーキテクチャ設計間の追跡性を確保した。

しなてす

17

２．テスト要求分析• テスト要求分析の成果物(テスト観点モデル)
アプリ利用
テスト

アプリ仕様
テスト

しなてす

3つのテストレベルそれぞれのテスト観点モデルを作成した。

ユーザ経験テスト18

３．テストアーキテクチャ設計• テストプロセス
テストベース

テスト
要求分析

テストアー
キテクチャ
設計

TD01

テスト要求分析書
・テストの全体像
・テスト観点モデル

しなてす

テスト
詳細設計

TD02

テストアーキテクチャ設計書
・テスト観点同士の関係性
・テストアーキテクチャ

TD03

テスト詳細
設計書
・テストケース

19

３．テストアーキテクチャ設計• 目的– テスト要求をテストしやすい単位にグルーピングし、テスト実装・実行する優先度を踏まえたテストの構造を設計すること。

どのようにテストするのかテストの全体構造を決めるプロセス
テストの全体像

テスト設計
方針の確認

テスト設計方針

テスト観点
モデル

テストベース

しなてす

テスト観点
モデルの整理

テストアー
キテクチャ
構築

テストアーキテクチャ

テスト観点同士の関係性

20

３．テストアーキテクチャ設計• 目的– テスト要求をテストしやすい単位にグルーピングし、テスト実装・実行する優先度を踏まえたテストの構造を設計すること。

どのようにテストするのかテストの全体構造を決めるプロセス
テストの全体像

テスト設計
方針の確認

テスト設計方針

テスト観点
モデル

テストベース

しなてす

テスト観点
モデルの整理

テストアー
キテクチャ
構築

テストアーキテクチャ

テスト観点同士の関係性

21

３．テストアーキテクチャ設計【ポイント1】独立性の高いテストアーキテクチャの構築– テスト観点モデルで示した3ステップ構造をそのまま使うと、後ろのステップのテストがなかなか始められない。
– 各テストチームの作業の独立性を高めることに重きを置くこととした。
ユーザ経験テスト（一般ユーザが実施）

他チームの進捗に影響されにくい！

アプリ利用テスト(しなてすが実施)
アプリ仕様テスト(開発チームが実施)

しなてす

22

３．テストアーキテクチャ設計【ポイント1】独立性の高いテストアーキテクチャの構築– アプリ仕様テストとアプリ利用テストについて、前提として実施しておくべきテストのテスト観点を分析し、マトリクスにまとめた。
– テスト観点同士の依存関係を明らかにした。
アプリ仕様テスト(先のステップ)のテスト観点
アプリ利用テスト(後のステップ)のテスト観点

しなてす

アプリ仕様テストのテスト観点
が、アプリ利用テストの前提として実施しておくべきテストの観点であれば○をつける。
23

３．テストアーキテクチャ設計【ポイント1】独立性の高いテストアーキテクチャの構築– マトリクスから、テスト観点同士の依存関係の強弱を分析– ○の多さなどから“先にやっておくと良いテスト“を明らかにした
行に記載された観点は、横の○が多いほど、前提にしなければならないアプリ仕様テストのテストが多いことを示す。

列に記載された観点は、縦の○が多いほど、そのテストを必要とするアプリ利用テストのテストが多いことを示す。
しなてす24

３．テストアーキテクチャ設計【ポイント1】独立性の高いテストアーキテクチャの構築– アプリ仕様テストを○の多さや機能の塊で①～④のコンテナに分けた。
– アプリ利用テストは次の観点で3グループに分類した。
A) ①だけを前提として実施できるテスト観点
B) ①②を前提として実施できるテスト観点
C) ①～④すべてを前提として実施できるテスト観点
A) カラオケの基本サービス

B) 特定の条件下で振る舞われるサービス

多くのサービスで使用される機能①

特定のサービスで使用される機能②

C) サプライヤ機
能を用いるサービス
カラオケ
付随機能
③

サプライヤ機能
④25

３．テストアーキテクチャ設計【ポイント2】テスト定形化の実現– アプリ仕様テストからユーザ経験テストまで、同じような操作、確認事項が何度か出現することが見込まれる。
– 定型化できるテストとできないテストが見えるようにすることにした。
種類定形化しやすい
テスト
定形化しにくいテスト特徴・テストケースレビューの省力化が期待できる。
・テストケース作成を幅広いエンジニアが担当できる。
・テストケースレビューをより丁寧に実施する必要がある。
・テストケースはカラオケの操作や性質を知り尽くしたベテランを中心に作成してもらうのが良い。

テスト担当者アサイン時の情報として活用

しなてす

26

３．テストアーキテクチャ設計• テストコンテナモデル– テスト観点の独立性を高めたモデルであり、アプリ仕様テストがすべて終わらなくても、アプリ利用テストのテストを始められる。
– テスト要求分析時のモデルよりも柔軟にテストの運用が可能になる。
ユーザ経験テスト

アプリ利用テスト“先にやっておくと良い”
テスト

しなてす

アプリ仕様テスト27

３．テストアーキテクチャ設計• テストアーキテクチャ
設計の成果物(アプリ利用テストのアーキテクチャ抜粋)– 柔軟にテストの運用が可能に。
– 感覚ではなく、組織的・戦略的なテスト実行が可能に。
– 影響範囲の確認が容易に。

しなてす

先にすべき
テスト

後からすべきテスト28

４．テスト詳細設計• テストプロセス
テストベース

テスト
要求
分析

テストアー
キテクチャ
設計

TD1

テスト要求
分析書
・テストの全体像
・テスト観点モデル

しなてす

テスト
詳細設計

TD2

テストアーキテクチャ設計書
・テスト観点同士の関係性
・テストアーキテクチャ

TD3

テスト詳細
設計書
・テストケース29

４．テスト詳細設計• 目的– テスト観点モデルとテストアーキテクチャに基づき、テスト観点からテストケースを作成すること。

個々のテストをどのようにするのか考え、実装していくプロセス
Opefy定義表

テストベース

テスト観点モデル

テスト
アーキテクチャ

しなてす

テストケー
スの構造検討シナリオテスト
テストケーステンプレーﾄテスト
実装

テストケース

ユーザテスト
テストケーステンプレーﾄ30

４．テスト詳細設計• 目的– テスト観点モデルとテストアーキテクチャに基づき、テスト観点からテストケースを作成すること。

個々のテストをどのようにするのか考え、実装していくプロセス
Opefy定義表

テストベース

テスト観点モデル

テスト
アーキテクチャ

しなてす

テストケー
スの構造検討シナリオテスト
テストケーステンプレーﾄテスト
実装

テストケース

ユーザテストテストケーステンプレーﾄ

31

４．テスト詳細設計【ポイント1】 シナリオテストのテストケースの構造検討– 操作内容と期待結果、その根拠の記載元は、同一条件下において変わることはない。1か所にまとめ、テストケースから呼び出すことで、テスト実装時のブレがなくなる。
– キーワード、操作内容、確認事項、確認事項の根拠となる仕様、これを定義した表をOpefy定義表と名付け、実装に利用した。

Opefy定義表(操作内容と確認事項を1か所に定義)

テストケース(Opefyで定義した操作を呼び出す)
操作

操作

操作内容 確認事項

操作1

Aする

Bになっていること

操作2

DするEになっていること

確認事項の根操作1
拠となる仕様操作2
仕様書C-1
操作3
仕様書C-2

操作3

GするHになっていること

仕様書I-3

操作内容
Aする
操作・・・

確認事項

Bになっていること 仕様書C操作内容 確認事項
確・・・
拠

操作2 Dする
操作
操作1 ・・・

Eになっていること 仕操作内容 確認事項
・・・操作3 操作1 Aする
操作2 ・・・

しなてす

確認事項
拠となる仕Bになっている・・・

32

４．テスト詳細設計• テスト詳細設計の成果物(アプリ利用テスト テストケース)
テスト観点ID

TVP-S-001-2

テスト観点

ナイト店構成で楽曲再生、マイク、映像、テロップが連携して機能すること前提条件

カラオケ装置本体と周辺外部機器（スピーカ、マイク、モニター、ビルコインボックスなど）が接続されていること
営業形態設定がナイト店であること
課金形態が楽曲単位であること
操作と確認事項
カラオケ装置本体が営業状態であることが自動入力される
予約済の曲が20曲未満であること

シナリオ1
№

Opefyに定義したキーワー
ドを選択すると…

キーワード
1 課金(単曲モード)

操作
演奏可能になるために必
要なお金をビルコインボッ
クスへ課金する

確認事項
注意事項
課金後、楽曲演奏が可能になること（スタート／やり直しボタンが点滅すること）

2 スタート/やり直し「スタート/やり直し」ボタンを押下する「スタート/やり直し」ボタンの入力を受け付けること

3 予約（直接入 曲番号の直接入力で予約 予約ができること力）を行う

予約する曲はテスト用に提供される楽曲とする

シナリオを通 テロップを見ながら歌うことができること。具体的には次の点を確認する。
・スピーカーから、音声が出力されることして確認する・映像が外部モニタに表示されること事項
・マイクが使用できること
・テロップが表示され、遅延がないこと

しなてす

33

４．テスト詳細設計【ポイント2】 ユーザ経験テストのテストケースの構造検討– ユーザ経験テストでは選出した一般ユーザに操作してもらい、その結果を評価してもらう。
– ユーザが「良い経験」をできるか検証するために、サービス利用時の感情を訪ねるような項目が必要であり、それをテストケーステンプレー
トに設けた。

？
しなてす34

４．テスト詳細設計• テスト詳細設計の成果物(ユーザ経験テスト テストケース)
テスト観点ID

TVP-S-001-1

テスト観点

ボックス店構成で歌を歌えること
カラオケ装置本体と周辺外部機器（スピーカ、マイク、モニターなど）が接続されていること
営業形態設定がボックス店であること
カラオケ装置本体が営業状態であること
予約済の曲が20曲未満であること前提条件

ユーザがサービスを利 テストの目的詳細 1. ボックス店構成でユーザが気持ちよく歌唱できることを検証する。
2. サービスを受けるための操作感に問題がないことを検証する。
用したときの好きな曲を予約して歌ってください。
感情を調査 操作のお願いする項目
操作した結果について
質問1

気持ちよく歌うことはできましたか？また、それはどうしてですか？

回答1
質問2

機器の操作で良かった点や不便を感じた点はございましたか？

回答2

35

まとめ

2 テスト
要求分析

本システムの目的
1①現行機・他社機との入れ替え②快適でリッチな体験を達成することを保証したい
3 テストアー

キテクチャ
テスト目的に応える設計
アプリ仕様テスト
4
テスト
アプリ利用テスト
詳細
ユーザ経験テスト テスト要求の独立性を高め設計の3ステップ
柔軟な運用を可能にする
テストアーキテクチャ
テストケースの実装容易性、保守性を高めるＯｐｅｆｙ定義表
しなてす

36

参考文献・参考資料• 「改訂版 組込みソフトウェア向け開発プロセスガイド(ESPR)」, IPA/SEC, 2007
• 「SSFに基づくテスト技術スキルフレームワーク」, ASTER, iVIA, JaSST’10 Tokyo,
2010• 「ソフトウェアテスト標準用語集(日本語版)」,ASTER, 2012
• 「PFDの書き方」,清水吉男, 2009
• 「テスト設計チュートリアル」資料,ASTER, 2015
• テスト設計コンテスト2013～2015 決勝出場チームの成果物• 「カラオケの楽曲のジャンル」、http://www.clubdam.com/• 「難聴になる時間と音量」、http://toppatu.com/genin_onkyougaishou.html

しなてす37