著：タニタガワー6

USAを利用したテスト

USM States Architecture

１．目次

•チーム紹介

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

• U.S.Aとは何か 概要＆キーワード

• U.S.A詳細 USMから各ステイトへ

•基本設計～詳細設計 各ステイトの紹介

こんにちは！タニタガワー6です！

１．チーム紹介 タニタガワー6とは

タニタガワー6

１．チーム紹介– 構成員紹介

そこそこ実務経験の長いメンバー！しかし！一緒に仕事をしたことは無かった！

タニタガワー(n)

タニタガワー(u)

タニタガワー(kr)

タニタガワー(i)

ビリヤード、梅酒

タニタガワー(h)

タニタガワー(kb)

我々は、我々の為に、我々が、共通で使えるテスト設計の何かを生み出してみようじゃないか！

買い物、映画鑑賞

ガンダム、ガンダム

ドラゴンボールドラゴンボールZドラゴンボール超

映画、包丁研ぎ

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

生まれたものが・・・・・・・はい、コチラ！

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

いまココあたり

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

6

CNBS

機能テスト

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

T4QA

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

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

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

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

ストーリーカード

アイデアカード

各ステイトへのINPUT

各ステイト

タスクカード

QAカード

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

メモカード

メモカード

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

U.S.Aのモデル図

非機能観点を集約したテスト

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

UserStoryMappingStatesArchitecture

プロジェクト背景

２．はじめに

２．はじめに

プロジェクト背景

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

• ASTER通信カラオケシステムは、WF（ウォーターフォールモデル）で開発されている。

• 顧客内プロジェクトでは、通信カラオケシステム（＝本機）のユーザー、オーナー、サプライ

ヤーに関わる全ての機能を全般的にテストしている。但し確立されたテストアーキテクチャを

使用してはいない。

• 顧客は自らのテストにより、本当にカラオケユーザーの要求を満足する製品となり得たかどう

かに不安を抱えている。

• 今回は顧客からタニタガワー６に対して、カラオケユーザーの要求を優先的に扱うテストを設

計してほしいとの依頼があった。

• テストスコープは後述する ステイト で規定する

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

３．U.S.Aとは何か

製品はユーザーの要求の解決策のあつまり

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

USMを開発との共通言語として扱う＝要求や優先度の合意を早期に形成

あらゆる工程へのフィードバックが容易である＝フィードバックに一定の根拠

要求：カラオケがしたい

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

要求：新曲をいち早くリリースしたい

要求：サーバ能力増強したい

要求：カスタマーの要求にこたえたい

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

要求分析 設計 開発 テスト メンテUSM

３．U.S.Aとは何か

U.S.Aを成り立たせるキーワード

U.S.A

ステイト

「何をするか」ということを宣言した独立した存在。テストにおいてはどのようなテストをするかということを明示的に宣言する。テストタイプと定義しないのは、このステイトにはテストに関わらず様々なモノをいれこんで役割を与えることができる拡張性のため。

User Story Mapping States ArchitectureUSMを発想の中心にとらえ、そこから生み出される様々なカードをテストに利用する。すべては製品の要求をダイレクトにとらえるユーザーストーリーをベースに発想を拡散させ、生まれたものを利用するアーキテクチャである。

３．U.S.Aとは何か

U.S.Aを成り立たせるキーワード

USM

カード

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

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

USMからU.S.Aへ

４．U.S.A詳細

4.U.S.A詳細

U.S.Aで重要なのはUSMから各ステイトへのINPUT洗い出し

要求分析

基本設計

詳細設計

１）ペルソナの設定

２）USM作成

３）カードの抽出と分類

４）各ステイトのINPUT（カード、＋α）を準備

※ ＋αのINPUTはテストスコープに応じて検討

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

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

レビュー

レビュー

レビュー

ユーザー(ペルソナ)を設定する

ユーザーが実現したいストーリーを設定する

行動(Activity)を時系列に並べる

ユーザーストーリーを実現出来るタスクを抽出し、時系列に並べる。作成中に出てきた、QA/アイデア/メモもマップに貼り付ける

ペルソナ＆USMの妥当性評価

４．U.S.A詳細 USMの作り方

USMはテスタ－、開発者、上位層 全員の共通認識として機能する

ポイントはあくまでユーザーを主軸に据えること

検討課題

検討課題

４．U.S.A詳細 ペルソナの作り方

主役であるペルソナの設定

•最も重要視するユーザを「プライマリペルソナ」として定義する

•次に重要視するユーザを「セカンダリペルソナ」として定義する

•例：20～30代社会人、60～70代女性

•ユーザーを複数用意することで、ペルソナ間での要求の違いがあった場合でも対応出来る

ペルソナは複数作成する

•なるべく詳細に。現在のスペックとは関係ない事柄も決める

外的なスペック(年齢、職業、出身地など)を決める

•外的スペックを持つ層の最大公約数になるように

内的なスペック(性格、趣味嗜好など)は、偏らないように

•あくまでも実際に存在するユーザーを想定する

テストに都合の良いようにペルソナを作らない谷田川 ぺる子

４．U.S.A詳細 USM

USMの例

ぺる子・1人カラオケに行く

ユーザーストーリー

アクティビティ

タスク

アイデア

メモ

QA

18

CNBS

機能テスト

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

T4QA

USM

品質の土台を確保

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

探索的テスト

主に非機能観点を集約したテスト

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

ストーリーカード

アイデアカード

各ステイトへのINPUT

各ステイト

タスクカード

QAカード

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

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

メモカード

メモカード

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

利用時の品質特性

性能指標

トレンド

機能要件リスト

テスト技法

テスト観点(機能性）

意地悪観点

テスターの経験

ペルソナの欲求UserStoryMappingStatesArchitecture

当PRJのU.S.A

各ステイトの紹介

５．基本設計～詳細設計

ステイト１：ユーザーストーリーテスト（User-Story-Testing）

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

各USM上のユーザーストーリーがどれぐらい達成されているか、

つまり「ユーザーの要求がどれぐらい満足に達成されているか」について測るために行う。

設計フロー１．INPUTの整理

２．代表ユーザーストーリーの選定

３．ユーザーストーリーごとの性能指標選定

４．テストケース作成

総合評価定性的な性能(UX) について、☆1~5までで総合的な評価をつける

定性的な評価テスト実施者に自然言語で期待してもらうその時、以下の評価ポイントを意識して記述してもらう・操作方法は分かりやすかったか、直感的に操作出来たか・使っていて快適だと感じたか

定量的な評価各操作・機能に関わる指標を定義し収集する・各操作(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