USAを利用したテスト
USM States Architecture

著：タニタガワー6

１．目次• チーム紹介• はじめに プロジェクト背景• U.S.Aとは何か 概要＆キーワード• U.S.A詳細 USMから各ステイトへ• 基本設計～詳細設計 各ステイトの紹介

１．チーム紹介 タニタガワー6とはこんにちは！タニタガワー6です！

１．チーム紹介– 構成員紹介
そこそこ実務経験の長いメンバー！しかし！一緒に仕事をしたことは無かった！
我々は、我々の為に、我々が、共通で使えるテスト設計の何かを生み出してみようじゃないか！
ビリヤード、梅酒

双子の育児
レコードコレクター

タニタガワー(u)ガンダム、ガンダムタニタガワー(h)タニタガワー(n)タニタガワー6
タニタガワー(kb)タニタガワー(kr)買い物、映画鑑賞

タニタガワー(i)

映画、包丁研ぎ

ドラゴンボール
ドラゴンボールZ
ドラゴンボール超生まれたものが・・・・・・・はい、コチラ！

User story mapping States Architecture
略して USM States Architecture
もっと略してU.S.A

U.S.Aはまだ生まれたばかり、これからの成長が期待できるテストアーキテクチャ
いまココあたり

UserStoryMapping
StatesArchitecture

U.S.Aのモデル図
非機能観点を集約したテスト

上流工程にフィードバックできるメモ
メモカード

CNBS

非機能要件のカバー領域⇒Satisfactionを追求
楽しく使えることを見る

各ステイト
アイデア
カード
各ステイトへのINPUT

ユーザー
ストーリー
テスト

ストーリー
カード

USM

タスク
カード

ユーザーの要求の達成度合いの測定

機能テスト
機能テストで品質の土台を確保

QA
カード

T4QA
メモカード
下流工程にフィードバックできるメモ

機能要件のカバー領域⇒goodを追求
ちゃんと使えることを見る

探索テストで品質の隙間を狙う
6

２．はじめにプロジェクト背景

２．はじめにプロジェクト背景• ASTER通信カラオケシステムは、WF（ウォーターフォールモデル）で開発されている。

• 顧客内プロジェクトでは、通信カラオケシステム（＝本機）のユーザー、オーナー、サプライ
ヤーに関わる全ての機能を全般的にテストしている。但し確立されたテストアーキテクチャを使用してはいない。
• 顧客は自らのテストにより、本当にカラオケユーザーの要求を満足する製品となり得たかどうかに不安を抱えている。
• 今回は顧客からタニタガワー６に対して、カラオケユーザーの要求を優先的に扱うテストを設計してほしいとの依頼があった。

タニタガワー6は、この背景に最適な新テストアーキテクチャ：U.S.Aを用いたテスト設計を行うことにする。
• テストスコープは後述する

ステイト

で規定する

３．U.S.Aとは何か

U.S.Aが生まれた背景

製品はユーザーの要求の解決策のあつまり要求：カスタマーの要求にこたえたい
要求：新曲をいち早くリリースしたい

USM

要求分析

USMで要求をダイレクトに捉えたテストを確実に行い、夢の詰まった製品へ！

設計

開発

テスト

メンテ

要求：カラオケがしたい
要求：サーバ能力増強
したい

USMはフェーズで異なるものではない＝テストにも応用。

USMを開発との共通言語として扱う＝要求や優先度の合意を早期に形成
あらゆる工程へのフィードバックが容易である＝フィードバックに一定の根拠

夢の詰まった新製品・新サービス

３．U.S.Aとは何か
U.S.Aを成り立たせるキーワード
U.S.A

User Story Mapping States Architecture
USMを発想の中心にとらえ、そこから生み出される様々なカードをテストに利用する。
すべては製品の要求をダイレクトにとらえるユーザーストーリーをベースに発想を拡散させ、生まれたものを利用するアーキテクチャである。
ステイト「何をするか」ということを宣言した独立した存在。
テストにおいてはどのようなテストをするかということを明示的に宣言する。
テストタイプと定義しないのは、このステイトにはテストに関わらず様々なモノをいれこんで役割を与えることができる拡張性のため。

３．U.S.Aとは何か
U.S.Aを成り立たせるキーワード
USM

User Story Mappingの略称。Jeff Pattonが考案。
ユーザーストーリーを時系列・優先度別に並び替えたマップを作成する。
要求の全体像の認識をチーム全体で共有でき、優先度が分かりやすくなって必要な開発・リリースに集中することができる。
カード

U.S.Aでは、従来のUSMの際に「ユーザーストーリーカード」「アクティビティカード」「タスクカード」 に加え、「QAカード」「アイデアカード」「メモカード」を作成する。
カードに書かれた内容（情報）が各ステイト設計のインプットとなる。

４．U.S.A詳細

USMからU.S.Aへ4.U.S.A詳細
U.S.Aで重要なのはUSMから各ステイトへのINPUT洗い出し
要求分析
レビュー

基本設計
レビュー

詳細設計
レビュー

１）ペルソナの設定
２）USM作成
３）カードの抽出と分類

４）各ステイトのINPUT（カード、＋α）を準備※ ＋αのINPUTはテストスコープに応じて検討

５）各ステイトのテストスコープに準拠したテスト設計

６）基本設計に準拠したテストケース設計

４．U.S.A詳細 USMの作り方
USMはテスタ－、開発者、上位層 全員の共通認識として機能する
ポイントはあくまでユーザーを主軸に据えることユーザー(ペルソナ)を設定する

検討課題

ユーザーが実現したいストーリーを設定する
行動(Activity)を時系列に並べる
ユーザーストーリーを実現出来るタスクを抽出し、時系列に並べる。
作成中に出てきた、QA/アイデア/メモもマップに貼り付ける
ペルソナ＆USMの妥当性評価

検討課題

４．U.S.A詳細 ペルソナの作り方主役であるペルソナの設定

ペルソナは複数作成する• 最も重要視するユーザを「プライマリペルソナ」として定義する• 次に重要視するユーザを「セカンダリペルソナ」として定義する• 例：20～30代社会人、60～70代女性• ユーザーを複数用意することで、ペルソナ間での要求の違いがあった場合でも対応出来る
外的なスペック(年齢、職業、出身地など)を決める• なるべく詳細に。現在のスペックとは関係ない事柄も決める
内的なスペック(性格、趣味嗜好など)は、偏らないように• 外的スペックを持つ層の最大公約数になるようにテストに都合の良いようにペルソナを作らない
谷田川 ぺる子• あくまでも実際に存在するユーザーを想定する

４．U.S.A詳細 USM
USMの例
ぺる子・1人カラオケに行く
QA
メモ

アイデア
アクティビティ
タスク
ユーザーストーリー

当PRJのU.S.A
UserStoryMapping ペルソナの欲求States
主に非機能観点をArchitecture
集約したテスト上流工程にフィードバックできるメモ利用時の品質特性
メモカード

CNBS

非機能要件のカバー領域⇒Satisfactionを追求
楽しく使えることを見る

各ステイト
アイデア
カード

品質の土台を確保

性能指標
トレンド

ユーザーストーリー
テスト

ストーリー
カード

USM

タスク
カード

機能テスト

各ステイトへのINPUT

機能要件リスト

テスト技法
テスト観点(機能性）

ユーザーの要求の達成度合いの測定

QA
カード

機能要件のカバー領域⇒goodを追求
ちゃんと使えることを見る

T4QA
テスターの経験

メモカード

意地悪観点

下流工程にフィードバックできるメモ探索的テスト

18

５．基本設計～詳細設計

各ステイトの紹介

ステイト１：ユーザーストーリーテスト（User-Story-Testing）
ユーザーストーリーテスト(User-Story-Testing)はUSM上のストーリーそのものについて行うテストである。

各USM上のユーザーストーリーがどれぐらい達成されているか、つまり「ユーザーの要求がどれぐらい満足に達成されているか」について測るために行う。
総合評価
定性的な性能(UX) について、☆1~5までで総合的な評価をつける

設計フロー
１．INPUTの整理
２．代表ユーザーストーリーの選定
３．ユーザーストーリーごとの性能指標選定
４．テストケース作成

テスト手順はアクティビティ、タスクを時系列で並べる

定性的な評価テスト実施者に自然言語で期待してもらう
その時、以下の評価ポイントを意識して記述してもらう・操作方法は分かりやすかったか、直感的に操作出来たか
・使っていて快適だと感じたか
定量的な評価
各操作・機能に関わる指標を定義し収集する・各操作(Activity)毎の所要時間
・所要時間の内の待ち時間(操作していない時間)
・各操作(Activity)毎の必要操作数(手数)・その他 取得可能な指標

ステイト2：機能テスト（Kinou-testing）
USMからのINPUT「タスクカード」と「機能要件一覧」をマッピングし、高優先度の機能から順に機能性のテスト観点を検討し、テスト目的を定め、「テスト技法」を適用する。
１. 高優先タスクと機能要件一覧のマッピング
３. テストケース設計（テスト条件、手順、期待値）
マッピング
2. テスト基本設計

テスト観点の設定
テスト目的の設定
テスト技法の決定

例：組み合わせテスト（ペアワイス法）

テスト条件組み合わせ
テスト手順設計
期待値設計

ステイト3：T4QA（ Test for QA ）T4QAはUSMを好奇心を持ってみることで生まれる「QAカード」をテストに応用
意地悪観点やテスターの経験に基づく探索テストを行う。

テスター目線

USM

テスト実行
ここで電源をブチーッとな！

開発者目線

・出てきたQAを精査
・新たに追加するテストパ
ターンなどはないか等、カードを元に膨らませる

ここはハードウェアとやり取りが頻繁だから弱い
ユーザー目線

こんな機能使わない。。あるのが知らなかった

メモ化
前工程、後工程へのフィードバックステイト4：CNBS（ Customer-NeedsBasedSystem-testing ）USMで生み出されたペルソナのアクティビティに対する欲求、及びシナリオの隙間・気付きをインプットにした主に非機能観点を集約したテスト。
USMからは「アイデアカード」をINPUTとする。
ペルソナのアクティビティに対する欲求・「○○だったら嬉しい」・「○○だったら不満」
これがアイデアカード

ペル子の欲求：
検索結果は早く出てほしい
利用時の品質>効率性：
検索開始から結果出力までの時間

６．最後にご清聴
まだまだ煮詰め足りないUSAではありますが、改良の余地があり、新規に生まれたテストの粒度の為、今後も研究をしていきたいと思います。
また、これだけで必要十分なテストにはならないと考えているので、現時点では既存のテストと併用して活用をすべきだとも考えております。
これにかかるコストと効果に関しては今回の期間では算出できなかった点は今後研究を進めていく中で検討をしたいと考えております。

ありがとうございました！

参考文献

タイトル：ユーザーストリーマッピング

著：ジェフ・パットン

・製品の使い勝手を定量的に評価し UX 向上を実現
https://www.ipa.go.jp/files/000057838.pdf