公開用テストカタマリーワークショップ（説明のみ）

12017/09公開用テストカタマリーワークショップβ版
テストカタマリー
ワークショップ
説明のみVer
STUDIO IBURI
Presents

こちらの提供でお送りいたします
胆振の中心
苫小牧
胆振地区

いきなり注意事項！
こちらの資料は2017/09/17に紹介しました
「テストカタマリーワークショップ」における
テストカタマリーの説明のみをPickUpしたものです。
謎の記法の確認にご使用ください。
また、次ページより
テストカタマリーワークショップβ版に対しての
注意事項をいくつか事前に示しておきます。

注意事項：テストカタマリー＆手法について
本ワークショップでは「テストカタマリー」の記法を
実際の業務でも役立てて貰えるように
例題を含めて用意してみております。
ただし、テストカタマリー記法は「テスト設計手法」に
依存しており、皆様と手法が異なる場合には使いづらい
…という場合も多分にあると思われます。
ただ、記法も複数の手法でお試しされることで
より良くできるとも思いますので、
テキトーにカスタマイズしてみてください。
⇒ んで、カスタマイズしたらフィードバックくださいｗ

注意事項：学習の優先順位
本資料は特においしい部分「記法を用いたモデリング」
の学習を中心として考えております。
また、テストカタマリーはテスト技法の使用を
考慮した構造化を行っておりますので、その理解には
テスト技法の知識は「必須」と考えております。
テスト技法（同値分割、デシジョンテーブル辺り）が
使える前提で、資料では説明をしております。

注意事項：まとめ
１．使いづらいと思った人は
カスタマイズでも考えてください。
２．テスト技法の説明は優先順位的に
やりませんよー。

コンテンツ
・イントロダクション
～テストカタマリーの簡単な説明
・第1部：テストカタマリーで
テストを表現してみよう
・第2部：自分たちのテストを
描いてみよう

コンテンツ
描いてみよう

モデルが必要な背景
現在のテスト現場で遭遇する問題:
1. テスト規模拡大と複雑化
2. 文書表現の偏り
3. 継続的に変更され続ける

モデルが必要な背景
まー、このへんは
別資料あるから
読んでくれや
関連情報：
InSTA2017：
“Test Conglomeration”
- Proposal for Test Design Notation Like Class Diagram（論文）
http://ieeexplore.ieee.org/document/7899074/
OSC2017 in Hokkaido ：
「もしかして、テストって誰でもできると思っちゃってませんか？最新のテストの動向を知りたくないですか？」
https://www.slideshare.net/tef-do/tefdo-osc2017-in-hokkaido-07152017

モデルが必要な背景：規模の拡大と複雑化
1.テスト規模の拡大と複雑化
システムシステム
System
Appli-
cation
Appli-
cation
Application
Process Process Process
Function
Function
Function
Class
Class
Func
Class
Method
Method
・・・
テスト技法
テストプロセステスト方針
テスト設計
システムテスト
回帰テスト
モンキー
テスト
探索的テスト
性能テスト
機能テスト
負荷テスト
巨大で複雑

⇒異なる「スキル」を持つ多くのテストエンジニアがテスト設計へ
テスト
設計
テスト
設計
テスト
設計
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
ばらつきが
発生する

⇒異なる「スキル」を持つ多くのテストエンジニアがテスト設計へ
テスト
設計
テスト
設計
テスト
設計
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
≠
異なるテスト設計
再検討することは
非常に困難
テスト
設計
テスト
設計

モデルが必要な背景：文書表現の偏り
2.文書表現の偏り
⇒大きなシステムには多くの文書があるが…
書くのも面倒で、読むのも退屈…
Real System

Real System
ドキュメント
ドキュメント無効な
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント

Real System
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
XXX は XXX で、 XXX は XXX を含み,
XXX, XXX, XXX かつ XXX
XXX は XXX で …
ドキュメント
参考書は
こちら

⇒従来型のテスト文書スタイル（大・中・小の3レイヤ型）
Large Middle Small
push button
release button
・・・
lock
lid open
・・・
TestCase
2.6 hot water
supply
supply
not supply
テスト仕様
大中小
Powered by…

モデルが必要な背景：継続的な変更への対応
3.継続的な変更
⇒変更が発生すると複雑なものが…
Real System
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
XXX は XXX で、 XXX は XXX を含み,
XXX, XXX, XXX かつ XXX
XXX は XXX で …
ドキュメント
Large Middle Small
push button
release button
・・・
lock
lid open
・・・
TestCase
2.6 hot water
supply
supply
not
supply
テスト仕様
大中小

⇒変更が発生すると複雑なものが…
Real System
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
機能
追加
仕様
変更
仕様
変更
機能
追加

⇒変更が発生すると複雑なものが…さらに複雑に！！
Real System
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
ドキュメント
機能
追加
仕様
変更
仕様
変更
機能
追加
ドキュメント
ドキュメント
ドキュメント

モデルが必要な背景：結果として
結果として…
System System
Real System
Document
Document Document
Document
Document
Document
Document
Additional
Feature
Additional
Feature
Additional
Feature
Additional
Feature
Document
Document
Document
Test
Design
Test
Design
Test
Design
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
テストケース
テストケース
テストケース
テストケース
テストケース
テストケース
ドキュメントレビューで
漏れの検出は難しい
ばらつきによって
テストケースが漏れる
テストケースが
漏れてしまう

モデルが必要な背景：結果として
結果として…
System System
Real System
Document
Document Document
Document
Document
Document
Document
Additional
Feature
Additional
Feature
Additional
Feature
Additional
Feature
Document
Document
Document
Test
Design
Test
Design
Test
Design
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
テストケース
テストケース
テストケース
テストケース
テストケース
テストケース
ドキュメントレビューで
漏れの検出は難しい
ばらつきによって
テストケースが漏れる
レビューで漏れを
見つけにくい
製品不具合

モデルで解決したい問題
2点の問題を取り上げる…
System System
Real System
Document
Document Document
Document
Document
Document
Document
Additional
Feature
Additional
Feature
Additional
Feature
Additional
Feature
Document
Document
Document
Test
Design
Test
Design
Test
Design
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
テストケースまたは
テスト設計のばらつき
ソフトウェアテストの概要を
文書で表現するのは難しい

モデルで解決したい問題の解決へ…
問題の解決として…
System System
Real System
Document
Document Document
Document
Document
Document
Document
Additional
Feature
Additional
Feature
Additional
Feature
Additional
Feature
Document
Document
Document
Test
Design
Test
Design
Test
Design
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
Quality Attributes
+ Guideline Suitability : Userbility
Userbility
+ Other OS : Compatibility
Compatibility
Feature/UI
~ Alert in the background : Compatibility
+ Confirm each function : FunctionalSuitability
<<Alert>>
Timer
+ Unfavorable Stress : PerformanceEfficiency
+ Number of data : PerformanceEfficiency
Stopwatch
1.グラフィカルな
表現
2. モデルを使うことで
メンテナンスが向上

モデルで解決したい問題の解決へ…
問題の解決として…
モデルを使おう！
System System
Real System
Document
Document Document
Document
Document
Document
Document
Additional
Feature
Additional
Feature
Additional
Feature
Additional
Feature
Document
Document
Document
Test
Design
Test
Design
Test
Design
Test
Case
Test
Case Test
CaseTest
Case
Test
Case
Test
Case
Test
CaseTest
Case
Test
Case
Test
Case
Test
Case Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
Test
Case
A
B
C
Quality Attributes
Userbility
Compatibility
Feature/UI
<<Alert>>
Timer
Stopwatch
1.グラフィカルな
表現
2. モデルを使うことで
メンテナンスが向上
+ XXXX()
+ XXXX
Timer
+ XXXX()
+ XXXX
Timer
TimerBehabior SelectMusic
「Timer」テストの詳細とテストケースの関連
Concrete Test Case
Concrete Test Case
Concrete Test Case
Concrete Test Case
Concrete Test Case
Concrete Test Case
3.一貫した表記を使用した
段階的なデザイン

と、いうことで…
「モデリング」が
役立ちそう！
なので、モデリングの方法を学んでみましょう^^)b
で、実際には？
とりあえず、
見た目が
良さそうな感じ
使いこなせると
クールそうで
モテそう？

参考：表とモデル（図）の比較
比較観点表モデル（図）
巨大化、複雑化
への対処
（デメリット）
単純につくると
巨大化しやすい
（メリット）
まとめ方により階層的に
わかりやすい表現がしやすい
複雑になる程工夫が必要
（メリット）
複雑な関連性を整理しやすい
作業の
やりやすさ
（メリット？）
単純な組合せ検討を
作業化して空白を
埋める作業にできる
（デメリット？）
読み書きに対して
ある程度の知識が必要で、
教育が必要となる
網羅しやすさ
抜けの
確認しやすさ
巨大化すると全体確認、
抜けがわかりづらい
（メリット）
全体を見やすいため、
大きな抜けを確認しやすい
（メリット）
組合せの抜けがないか
網羅的に確認しやすい
何らかの詳細な組合せは
確認がしづらく、抜けるかも。
…表、便利
だよね
※記載は思いつき
レベルです

カタマリー発想までの流れよりコメント
テストカタマリー構築メンバーにおける
「趣味」と「得意分野」により、
次の要素の影響が大きく出ている可能性が高いです。
・ゆもつよメソッド（ゆもつよさんファン×２で構築）
・組込みよりの分野
…そのため、興味や分野の近い人にはやりやすいかも。
（逆に興味や分野が異なる人は使いづらい可能性も）
コメント頂ければ、記法のアップデートを考えまーす。

テストカタマリーを支える知見
テストカタマリーを支える知見は次があります。
・テスト技法（テスト技法ドリル）
・ゆもつよメソッド
・VSTeP
・JSTQB FL/AL
・UMLモデリング、astah*ツール
・DDD（ドメインモデリング）
・RDRA
・デマルコ構造化設計
※追加中
・UML Testing Profile 2.0 「巨人の肩の上に立って」
（Standing on the shoulders of Giants）
※Goldratt氏の論文名
各種手法を参考に
構築しております。
ひとまずテスト技法
を知っていればOK

テストカタマリーの直接関連情報
Blog情報：
その他情報：
テストカタマリーの紹介：まとめ
http://blog.amateur-factory.jp/?eid=1444276
テストカタマリーを活用したテスト設計プロセス案：まとめ
http://blog.amateur-factory.jp/?eid=1444278
Test Conglomeration - Proposal for Test Design Notation Like Class Diagram（論文）
http://ieeexplore.ieee.org/document/7899074/
OSC2017 in Hokkaido 「もしかして、テストって誰でもできると思っちゃってませんか？最新のテストの動向を知りたくないですか？」
https://www.slideshare.net/tef-do/tefdo-osc2017-in-hokkaido-07152017
テスト設計コンテスト'17 OPENクラス決勝戦レポート
http://aster.or.jp/business/contest/contest2017.html
あんがい
情報ある

テストカタマリーの概要
テストカタマリーとは
• STUDIO IBURIという謎の団体が打ち上げた記法
• テストカタマリー：テストの塊
• テスト観点とテストカテゴリ、抽象的なテストケースを
クラス図を利用して表現する記法
特徴
• UTPとVSTePの中間くらいのモデリング
• テストの概要の整理がメイン
• UMLモデリングツールが使えればそれでお手軽に描ける

テストカタマリーのアイデア
テストカタマリーのアイデアの原型
テストを行うべき
なんとなくの領域

テストスコープ

分割されたテストスコープ

優先順位を決定する
High priority
Low priority

・Test Case１
・Test Case２
…
テストの詳細設計
分割した
テストスコープの
一部

一連のテストケースを持つ
分割されたテストスコープを
「テストカタマリー」
と定義。
・テストケース１
・テストケース２
…
テストスコープの一部
=テストカタマリー
テストケース
詳細
塊

…
テストケース
詳細
塊
UMLクラス図の流用
アラーム登録
+各機能 : 機能特性
~登録数 : 性能効率性
…
+アラーム登録 : 各機能
+アラーム解除 : 各機能
~最大登録数検証 : 登録数
…
iOS時計アプリ
アラーム登録

…
テストケース
詳細
塊
アラーム登録
…
…
抽象テストケース
ロジカルテストケース

…
テストケース
詳細
塊
アラーム登録
…
…
各ロジカルテストケースから
具体的なテストケースを作成
※テスト詳細設計で実施
アラーム解除編集画面にて登録解除
アラーム画面にて登録解除
未登録のときに登録解除
複数の具体的テストケース

…
テストケース
詳細
塊
Divided Test Scope
全体的なテスト範囲が、
1枚の絵で描ける
Quality Attributes
Userbility
Compatibility
Feature/UI
<<Alert>>
Timer
Stopwatch

テストの俯瞰表現から詳細の表現を行うことができる。
Quality Attriutes
App Compatibility
+ Navigation : Usability
+ Guideline Suitability : Usability
App Userbility
+ Memory Leak : Performance efficiency
+ Long Run Process : Reliability
Long Run
+ Process Multiple App : Compatibility
+ Multiple process in an App : Compatibility
Co-Existence
Feature/UI
+ Cooperate with other Apps : Compatibility
~ Unfavorable Stress : Performance efficiency
+ Correctness of analysis : Functional suitability
+ Confirm each function : Functional suitability
<<Alert>>
Bedtime
~ Operation Response : Performance efficiency
~ Number of data : Performance efficiency
<<Resister/Edit/Delete Data>>
World Clock
~ Alert in the background : Performance efficiency
<<Alert>>
Alarm
<<pattern>>
Resister/Edit/Delete Data
<<pattern>>
Alert
<<Alert>>
Timer
+ Unfavorable Stress : Performance efficiency
+ Number of data : Performance efficiency
Stopwatch
<全体俯瞰：カタマリー全体図>
<<pattern>>
<<Alert>>
Alarm
<<pattern>>
Alert
+ Check with Stress() : Unfavorable Stress
+ Check with other Apps() : Alert in the background
+ Confirm Snooze() : Confirm each function
+ Confirm Alerm() : Confirm each function
Notify Alarm
+ Operate from Siri() : Cooperate with other Apps
+ Check max registration data() : Operation Responce
+ Delete Alarm() : Confirm each function
+ Edit Alarm() : Confirm each function
+ Register Alarm() : Confirm each function
Register/Display Alarm
<詳細確認：カタマリー詳細図>

<<pattern>>
<<Alert>>
Alarm
<<pattern>>
Alert
+ Check with Stress() : Unfavorable Stress
+ Check with other Apps() : Alert in the background
+ Confirm Snooze() : Confirm each function
+ Confirm Alerm() : Confirm each function
Notify Alarm
+ Operate from Siri() : Cooperate with other Apps
+ Check max registration data() : Operation Responce
+ Delete Alarm() : Confirm each function
+ Edit Alarm() : Confirm each function
+ Register Alarm() : Confirm each function
Register/Display Alarm
テストカタマリー：超簡単まとめ
ざっくりと次の内容くらいです。
Quality Attriutes
App Compatibility
+ Navigation : Usability
+ Guideline Suitability : Usability
App Userbility
+ Memory Leak : Performance efficiency
+ Long Run Process : Reliability
Long Run
+ Process Multiple App : Compatibility
+ Multiple process in an App : Compatibility
Co-Existence
Feature/UI
+ Correctness of analysis : Functional suitability
<<Alert>>
Bedtime
World Clock
<<Alert>>
Alarm
<<pattern>>
<<pattern>>
Alert
<<Alert>>
Timer
+ Unfavorable Stress : Performance efficiency
+ Number of data : Performance efficiency
Stopwatch
全体を俯瞰して
表現ができる
編集画面にて登録解除
複数のテストケースに対応
全体俯瞰内の
1つのカタマリーを
詳細に表現できる
最下層に抽象
（ロジカル）テスト
ケースを並べる
１つのロジカル
テストケースは
複数の具体的
テストケースに対応

コンテンツ
描いてみよう

コンテンツ（詳細）
テストケースを
カタマってみよう！
※JOJO第1部では
少年編に相当

ワーク①内容
例として、テストケースが存在している状況を想定して
カタマリー化して（カタマって）みましょう！
テスト
ベース
テストケーステストケーステストケース
テストケース
+・・・
+・・・
…

ワーク①：テストカタマリーを作ってみよう！
テストベース＆テストケースがある場合に、
テストカタマリーを作ってみるとして…
テストケーステストケーステストケーステストケース
参加申込みチケット
+通常参加時に論文採録Noが
グレイアウトで入力できないこと
+論文採録者時に論文採録No
が入力できること
+チケット種別の選択可能な・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
…
テストケースを
単純にカタマリーに
展開すると大変に！
※自由に使えるので全ケース
埋め込みも否定はしません

+通常参加時に論文採録Noがグレイアウト
で入力できないこと
+論文採録者時に論文採録Noが
入力できること
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
…
大量のテストケースを単純にカタマるのではなく…
テストケース
テストケース
大量のテストケース

グルーピング＆整理してカタマりましょう。
テストケース
テストケース
テストケーステストケース
テストケース
テストケース
グループA
グループB
グループC 参加申込みチケット
+グループA
+グループB
+グループC
…
グルーピング＆整理
+通常参加時に論文採録Noがグレイアウト
で入力できないこと
+論文採録者時に論文採録Noが
入力できること
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
+・・・
…

ワーク①：テストケースをグルーピングしよう
まずはテストケースを「目的」か「技法」で
グルーピングします。
そしてグループに適当な「名前」を付けてみます。
テストケース
テストケース
テストケース
グループA：名前
※同値分割でグループ目的or技法で
グルーピング
＆整理
テストケース
グループB：名前
※DTでグループ
グループC：名前
※性能XX確認でグループ
グルーピングがうまい場合には
不足のテスト、重複なども
確認することができます。

ワーク①：グループをカタマリーへ展開
グループ化したテストケースをカタマリーへ展開します。
テストケース
グループA：名前
※同値分割でグループ
テストケース
グループB：名前
グループC：名前
…
グループの右側の↑辺は
ある程度空けといてください
グループA：名前XXX
グループB：名前XXX

解説：カタマリーの持つテストケースの粒度
注意：個々の解説では、テスト技法の
知識がある前提でお話します。
⇒つまりは、技法の説明はしません。

テストケースの粒度：別テストベースで紹介
一旦、別の仕様でテストケースの粒度を紹介します。
現在時間：１７:００:１５
おとなこども
計算
料金表
おとな（15才以上）1000円
こども（14才以下）500円
10:00-17:59入場通常料金
18:00-19:59入場 +300円
※上記時間以外は購入不可
計算結果：
時間：１７：００：１６
おとな：１枚
支払いは１０００円です
購入計算画面購入画面
・通常料金チケットは18:05まで使用（入場）可能です
・計算ボタンを押したタイミングで時間が決定します
・購入者の妥当性チェックはシステム上はありません
・ユーザビリティは（あえて）考慮してませんので
テストからも外していただいてOKです
・妥当性はあまり気にせず＋深読みしなくてよいです
購入種別（選択式）

テストケースの粒度：仮に４つの段階を紹介
比較的抽象的なテストケース粒度では…？
参考：レベル３
テストケース
入場時間購入種別（通常料金）
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
購入種別（夜間料金）
こども
おとな
500
円
1300
円
800
円
レベル１：処理だけを特定したテストケース
（例）購入計算処理のロジック/入出力を確認する
レベル２：入出力のパラメータ項目まで表現したテストケース
（例）購入種別と入場時間から計算結果を確認する
購入計算
処理
？？
購入計算
処理
計算結果
購入種別
入場時間
具体化
抽象化

より詳細なテストケースでは…
レベル３：同値クラスを用いて組合せ論理条件（ルール）まで表現したテストケース
（例）購入種別：おとな、入場時間：通常料金時間で結果1000円
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
こども
おとな
500
円
1300
円
800
円
（例）
CFDとDTで
関係性を図示
レベル４：実際の値まで具体化したテストケース
（例）購入種別：おとな、入場時間：10:00:00 で結果1000円
・#3-1 購入種別：おとな、入場時間：10:00:00 で結果1000円
…
具体的な
値を設定
#1 #2 #3 #4 #5 #6
1 購入種別
1 おとな - - ○ ○ - -
2 こども - - - - ○ ○
2 入場時間
1 購入不可時間
00:00:00-09:59:59
○ - - - - -
2 通常料金時間
10:00:00-17:59:59
- - ○ - ○ -
3 夜間料金時間
18:00:00-19:59:59
- - - ○ - ○
20:00:00-23:59:59
- ○ - - - -
#1 #2 #3 #4 #5 #6
1 購入不可 ○ ○ - - - -
2 1300円 - - - ○ - -
3 1000円 - - ○ - - -
4 800円 - - - - - ○
5 500円 - - - - ○ -
入力条件
期待結果

全体を示すとこの通りになります。
（例）購入計算処理を確認する
（例）購入種別と時間から計算結果を確認する
購入計算
処理
？？
購入計算
処理
計算結果
購入種別
入場時間
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
こども
おとな
500
円
1300
円
800
円
（例）
CFDで関係性を図示して
デシジョンテーブルで
表現することができる
…
具体的な
値を設定
具体化
抽象化
#1 #2 #3 #4 #5 #6
1 購入種別
1 おとな - - ○ ○ - -
2 こども - - - - ○ ○
2 入場時間
00:00:00-09:59:59
○ - - - - -
10:00:00-17:59:59
- - ○ - ○ -
18:00:00-19:59:59
- - - ○ - ○
20:00:00-23:59:59
- ○ - - - -
#1 #2 #3 #4 #5 #6
1 購入不可 ○ ○ - - - -
2 1300円 - - - ○ - -
3 1000円 - - ○ - - -
4 800円 - - - - - ○
5 500円 - - - - ○ -
入力条件
期待結果
各レベルの例
レベル１：購入計算処理のロジック/
入出力を確認する
レベル２：購入種別と時間から
計算結果を確認する
レベル３：購入種別：おとな、
入場時間：通常料金時間
で結果1000円
レベル４：購入種別：おとな、
入場時間：10:00:00
で結果1000円

テストカタマリーに配置する粒度
テストカタマリーに配置するテストケース粒度は…
購入計算
処理
？？
購入計算
処理
計算結果
購入種別
入場時間
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
こども
おとな
500
円
1300
円
800
円
（例）
…
具体的な
値を設定
具体化
抽象化
#1 #2 #3 #4 #5 #6
1 購入種別
1 おとな - - ○ ○ - -
2 こども - - - - ○ ○
2 入場時間
00:00:00-09:59:59
○ - - - - -
10:00:00-17:59:59
- - ○ - ○ -
18:00:00-19:59:59
- - - ○ - ○
20:00:00-23:59:59
- ○ - - - -
#1 #2 #3 #4 #5 #6
1 購入不可 ○ ○ - - - -
2 1300円 - - - ○ - -
3 1000円 - - ○ - - -
4 800円 - - - - - ○
5 500円 - - - - ○ -
入力条件
期待結果
テストカタマリーに記述する
テストケースの粒度は
ここでの「レベル１～２」を推奨
※「ロジカルテストケース」相当
テストケースの詳細化は
テスト詳細設計で実施
各レベルの例
レベル１：購入計算処理のロジック/
入出力を確認する
レベル２：購入種別と時間から
計算結果を確認する
レベル３：購入種別：おとな、
入場時間：通常料金時間
で結果1000円
レベル４：購入種別：おとな、
入場時間：10:00:00
で結果1000円

参考：テストケースの粒度と呼び名＠ISTQB
ISTQB/JSTQBでの呼び名を整理したものです。
購入計算
処理
？？
購入計算
処理
計算結果
購入種別
入場時間
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
こども
おとな
500
円
1300
円
800
円
（例）
…
具体的な
値を設定
具体化
抽象化
#1 #2 #3 #4 #5 #6
1 購入種別
1 おとな - - ○ ○ - -
2 こども - - - - ○ ○
2 入場時間
00:00:00-09:59:59
○ - - - - -
10:00:00-17:59:59
- - ○ - ○ -
18:00:00-19:59:59
- - - ○ - ○
20:00:00-23:59:59
- ○ - - - -
#1 #2 #3 #4 #5 #6
1 購入不可 ○ ○ - - - -
2 1300円 - - - ○ - -
3 1000円 - - ○ - - -
4 800円 - - - - - ○
5 500円 - - - - ○ -
入力条件
期待結果
低位
レベル
テスト
ケース
具体的
テスト
ケース
高位
レベル
テスト
ケース
論理的
テスト
ケース
ハイレベル
こちら
ロジカル
こちら
※用語集では
ハイレベル=ロジカル
ですが、
AL TAの説明を考慮

テストカタマリー推奨のテスト粒度
テストカタマリーは「ロジカルテストケース」※特にレベル1～2
相当の抽象度のテストケースを持つことを推奨します。
テストケース
ロジカルTC-A：名前
※同値分割でグループ
テストケース
ロジカルTC-B：名前
ロジカルTC-C：名前
+ロジカルテストケースA
+ロジカルテストケースB
+ロジカルテストケースC
…
※各ロジカルテストケースは
デシジョンテーブル1～2つくらい相当
さらなる詳細化は後のプロセスで実施
目的が異なると分けることを推奨

ワーク①：カタマリーの例
例を載せておきます。
+論文採録No入力可否 … No1-2に対応
+論文採録No異常入力 … No3-5に対応
+チケット種類の数対チケット種別 … No6-8に対応
+チケット名文字数対チケット種別 … No9-11に対応
+チケット種類の数対価格確認表 … No12-14に対応
+チケット名文字数対価格確認表 … No15-17に対応
+価格確認表操作レスポンス … No18に対応
+レスポンシブでのチケット名表示 … No19-21に対応
+参加者種別の入力判定・価格反映 … No22-25に対応
+参加者種別・チケット種別価格反映 … No26-27に対応

ワーク①：カタマリーの例、その２
同じ内容がこうなるような人もいるかも？
+論文採録Noの入力確認 … No1-5に対応
+チケット登録に対するふるまい確認 … No6-17に対応
+価格確認表操作レスポンス … No18に対応
+レスポンシブでのチケット名表示 … No19-21に対応
+参加者種別入力組合せ確認 … No22-27に対応

テスト詳細設計
0 1 10 11
※0と10超過は
設定できない
チケット種類の数
参考：ロジカルテストケースとテストケース
上位から考える場合には、ロジカルテストケースまで一度考えた
後に、テスト詳細設計で具体的テストケースをつくります。
+論文採録No入力可否
+論文採録No異常入力
+チケット種類の数対チケット種別
+チケット名文字数対チケット種別
+チケット種類の数対価格確認表
+チケット名文字数対価格確認表
+価格確認表操作レスポンス
+レスポンシブでのチケット名表示
+参加者種別の入力判定・価格反映
+参加者種別・チケット種別価格反映
テストケース
チケット種類1個
テストケース
テストケース
テスト詳細設計
参加者種別
通常参加
論文採録者
論文採録No
システム登録なし
入力無し
通常参加
費用
画面遷移
負荷
有効
論文採録
者費用

+論文採録No入力可否
+論文採録No異常入力
+チケット種類の数対チケット種別
+チケット名文字数対チケット種別
+チケット種類の数対価格確認表
+チケット名文字数対価格確認表
+価格確認表操作レスポンス
+レスポンシブでのチケット名表示
+参加者種別の入力判定・価格反映
+参加者種別・チケット種別価格反映
参考：テストケース仕様書を作る場合
テストケース仕様書を作成する場合や、テスト管理ツールにて
テストケースを管理する場合に階層構造はシンプルです。
No テスト名
No テストケース
BusST申し込みシステム
論文採録No入力可否
1 参加者種別->通常参加　選択時に論文採録Noがグレイアウトで入力不可
2 参加者種別->論文採録者　選択時に論文採録Noが入力できること
チケット種類の数対チケット種別
3
チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が1個の
場合、表示されるドロップダウンリストが1つしかないこと
4
チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が2個の
場合、表示されるドロップダウンリストが2つあること
5
チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が10個
の場合、表示されるドロップダウンリストが10個あること
チケット名文字数対チケット種別
・・・
各入力説明
試験カテゴリ
テストカタマリーのもつ
テストケースは青点線範囲
ロジカルテストケースの
テストケース範囲は赤点線

キガカリーを
追加しよう！
青年編に相当

カタマリーの空き部分に書く情報を紹介
先ほど空けておいた部分について紹介します。
…
この部分について
紹介してみます。

カタマリーの空き部分にキガカリーを追記
先ほど空けておいた部分について紹介します。
各ロジカルテストケースに対応する
「キガカリー（≒テストケースの目的）」を記述します。
…
この部分について
紹介してみます。
→「キガカリー」を記述

キガカリーの説明：注意事項
注意：この「キガカリー」部分は特に「手法依存」
ですので、あわない人は無視してもOKです。
※構造化目的でカタマリーを使ってももちろんよいです。
少なくとも現場で
簡単に説明して
すぐ使えるものでは
なさそうかと…

カタマリー、ロジカルテストケースとキガカリー
テストカタマリーでは、該当部分にキガカリーを
入れることを推奨しております。
+ロジカルテストケースA：キガカリー
+ロジカルテストケースB：ふるまい
+ロジカルテストケースC：異常値
…
キガカリー（仮名）
テスコン＠Studio Iburiでは
KQF(Key Quality Factor)と呼ぶ
人によっては
テストカテゴリ
テスト観点、かも
※キガカリーの例
ふるまい、レスポンス、ボリューム、
処理中異常、同時入力、データ互換、
入力値異常、異常操作…
命名は
めんどいので
ここでは
キガカリー
と呼びます

テストカタマリーの本当の書き方
テストカタマリーでは、クラス図の「属性」部分にも
キガカリーを書くようにはしております。
※具体的な書き方と書く理由は別途説明します。
+ふるまい：機能適合性
+異常値：信頼性
+レスポンス：性能効率性
…
+ロジカルテストケースA：キガカリー
+ロジカルテストケースB：ふるまい
+ロジカルテストケースC：異常値
…
キガカリー
ロジカル
テストケース
with キガカリー

キガカリーについてざっくり説明
・テストケースの持つ目的（意図）を明示する。
・テストの範囲を決めるため、抜けの確認に役立つ。
・知識の蓄積やパターン化もできる。
・「テスト観点（の、とある抽象度範囲）」もしくは
「テストカテゴリ」と同等と考えてよい。
キガカリー
予約
…
+曲Noで予約登録をする：ふるまい
+予約TAT確認：レスポンス
…
・テストカタマリーは複数のキガカリーを持つ
・ロジカルテストケースは１つのキガカリーと対応
ロジカル
テストケース
with キガカリー

キガカリーについての詳細～ここから
ここから
キガカリーの詳細説明
※未成熟な内容です

なぜキガカリー？：作った背景より
参考：ゆもつよメソッド（マトリクス）の構造より
※ソフトウェアテストPress Vol10. 今こそ聞きたいテストの上流設計より引用
機能名機能小分類データ操作音声操作 …
検索キュー 1件 1件
データ送り 2件 -
再生 1件再生 1件 5件
・・・
データ送り× データ操作
１件再生 × データ操作
１件再生 × 音声操作
つくったメンバーがゆもつよメソッドファン
テスト手法としてキガカリー設定が役立つと判断した。
※テスト手法次第で設定する必然性はない。

なぜキガカリー？：作った背景より
参考：ゆもつよメソッド（マトリクス）の構造より
※ソフトウェアテストPress Vol10. 今こそ聞きたいテストの上流設計より引用
・・・
キガカリーに相当
つくったメンバーがゆもつよメソッドファン
テスト手法としてキガカリー設定が役立つと判断した。
※テスト手法次第で設定する必然性はない。

なぜキガカリー？：他手法との関連
ゆもつよメソッド
・・・
VSTeP / NGT ※テスト観点に基づくテスト開発方法論VSTePの概要より引用
三角形
具体抽象
直線
不成立
成立
二等辺△
不等辺△
正三角形…
・・・動作環境
ﾈｯﾄﾜｰｸ
ﾌﾟﾗｯﾄﾌｫｰﾑ
ﾊｰﾄﾞｳｪｱ
OS…
・・・

なぜキガカリー？：他手法との関連
ゆもつよメソッド
・・・
VSTeP / NGT ※テスト観点に基づくテスト開発方法論VSTePの概要より引用
三角形※どのテストケースでテスト観点を
カバーしているか関連付けたい
⇒対応する観点が「キガカリー」相当
具体抽象
直線
不成立
成立
二等辺△
不等辺△
正三角形…
ﾈｯﾄﾜｰｸ
OS…
・・・
テストケース
テストケース
テストケース

なぜキガカリー？：技法との対応
紹介したように、ロジカルテストケースから、
テスト技法を用いて具体的テストケースに落とし込みますが、
この「テスト技法」との対応もできていると便利です。
（例）購入種別と入場時間から計算結果を確認する（ロジカルテストケース）
キガカリー「ふるまい」では、主にCFD、DTを使いテストケースをつくる。
購入計算
処理
計算結果
購入種別
入場時間
こども
おとな
1000
円
購入
不可
購入不可時間
20:00:00-
23:59:59
購入不可時間
00:00:00-
09:59:59
夜間料金
18:00:00-
19:59:59
通常料金
10:00:00-
17:59:59
こども
おとな
500
円
1300
円
800
円
#1 #2 #3 #4 #5 #6
1 購入種別
1 おとな - - ○ ○ - -
2 こども - - - - ○ ○
2 入場時間
00:00:00-09:59:59
○ - - - - -
10:00:00-17:59:59
- - ○ - ○ -
18:00:00-19:59:59
- - - ○ - ○
20:00:00-23:59:59
- ○ - - - -
#1 #2 #3 #4 #5 #6
1 購入不可 ○ ○ - - - -
2 1300円 - - - ○ - -
3 1000円 - - ○ - - -
4 800円 - - - - - ○
5 500円 - - - - ○ -
入力条件
期待結果
「ふるまい」確認のため、
CFD/DTを用いて検討する

参考：テスト観点の範囲に対する概念MAP
三角形
具体抽象
直線
不成立
成立
二等辺△
不等辺△
正三角形…
ﾈｯﾄﾜｰｸ
OS…
品質特性など
・機能適合性
・性能効率性
etc
具体的な
パラメータ
同値クラス
単位の項目
テスト観点
（テストカテゴリ）
キガカリー
ブンルイー
感覚的な範囲の想定なので
もう少し具体的な事例や
表現方法の整理が必要
ﾃﾞｰﾀ操作
音声操作

キガカリーとは？：キガカリーの概念について
・テストケース/テストケースのグループは目的（意図）を持つ
あわせて、目的のないテストケースは意味がない
・テスト技法で導出されたテストケースも目的を持っている
同値クラス：結果に影響する入力値を確認する
境界値：不具合に繋がりやすい同値設定の境界部分を確認する
DT/ドメイン分析：関係のある複数パラメータ組合せを確認する
テストケースの目的（意図）
については、
JaSST関西の資料も参考
https://www.slideshare.net/Nori
yukiMizuno/jasst17-kansai

キガカリーとは？：キガカリーの概念について
・テストケース/テストケースのグループは目的（意図）を持つ
あわせて、目的のないテストケースは意味がない
・テスト技法で導出されたテストケースも目的を持っている
同値クラス：結果に影響する入力値を確認する
境界値：不具合に繋がりやすい同値設定の境界部分を確認する
DT/ドメイン分析：関係のある複数パラメータ組合せを確認する
・カタマリーでは目的を実現するテストケースを明確にしたい
※某テスト観点では、テストケースに割り当てる方法は明示していない
・カタマリーではテストケースのグループが１つの目的に対応
※これはある意味仮説的、複数の目的に対応する場合もあるかもしれない

キガカリーとは？：他手法との関連
※把握・理解している内容で説明
・ゆもつよメソッド：
テストケースはいずれかの
テストカテゴリに属する。
テストカテゴリが、
そのテストケースの目的（意図）を示す。
・VSTeP：テストケースの目的（意図）をモデリングしている。
ただし、テストケースに割り当てる方法を明示はしていない。
・・・
三角形
具体抽象
直線
不成立
成立
二等辺△
不等辺△
正三角形…
ﾈｯﾄﾜｰｸ
OS…
・・・

キガカリーとは？：キガカリーの役立つ点と例
ざっくりと体感的に役立つ点を記載しておきます。
・テストの範囲を決めることができる、
ざっくり特定するのに役立つ（例：予約×ふるまい）
・説明する際に役に立つ
・抜けている部分を確認しやすい
・知見の蓄積ができる
・パターン風の「キガカリーセット」を使うと考えやすく役に立つ
・抽象的な表現を活用すると、全体を考えやすい
予約
…
+曲Noで予約登録をする：ふるまい
+予約TAT確認：レスポンス
…
予約×ふるまい
予約×レスポンス
ざっくり範囲がわかる
ユーザ操作パターン
…
機能適合性
- 結果網羅
ふるまい
- 結果網羅
機能排他
状態遷移
- 性能評価
性能効率性
ボリュームストレス
レスポンス
「テスト条件」とも
呼んでよいかも

キガカリーとは？：別の言葉で表してみる
別の言葉で表すと、次のようなものとなりそう。
・保証すべきもののキーワード
・確認したいもの
・テストの関心ごと
・テストケースの目的/意図
・気がかり事項/リスク
≒ テスト観点上のとある抽象レベル。
≒ テストカテゴリ。
自分の理解が
間違っている
可能性も
ありますが…

キガカリーについての詳細～ここまで
ここまで
キガカリーの詳細説明
だん

キガカリーの説明：再度注意事項
注意：再度言っておきますが、「手法依存」です。
キガカリーがあると役立つ場合には使用して、
うまくいかない場合には使わなくてもよいです。
ワークショップでは
キガカリーを考えて
カタマリーを
つくってみます

ワーク②：キガカリーの例
作成したカタマリーの各ロジカルテストケースに
キガカリーを追加することを考えてみます。
+ロジカルテストケースA：
+ロジカルテストケースB：
+ロジカルテストケースC：
…
キガカリーの例
テストケースの分類
を意識している
人ならやりやすい
キガカリーの例
※↓にこだわる必要はありません
・ふるまい/論理性
・異常操作
・レスポンス/応答速度
…

ワーク②：回答例
キガカリーを追加したカタマリーの例。
+論文採録No入力可否：単体パラメータ確認/ふるまい
+論文採録No異常入力：入力値異常
+チケット種類の数対チケット種別：単体パラメータ確認/ふるまい
+チケット名文字数対チケット種別：単体パラメータ確認/ふるまい
+チケット種類の数対価格確認表：単体パラメータ確認/ふるまい
+チケット名文字数対価格確認表：単体パラメータ確認/ふるまい
+価格確認表操作レスポンス：レスポンス
+レスポンシブでのチケット名表示：表示くずれ有無
+参加者種別の入力判定・価格反映：単体パラメータ確認/ふるまい
+参加者種別・チケット種別価格反映：有則組合せ確認/ふるまい

キガカリーを属性部にも記載します。
メソッド引数部分に網羅基準（Done基準の明確化等に使う）
を記述します。
これで、astah*の機能を
フルに活用してますｗ
※使えばいいってもんじゃない
さらに詳細なカタマリーの記法では…
キガカリーを表示
※対象キガカリー：上位分類
という構成で記述してます
ロジカルテストケース名
（網羅基準）
：対象のキガカリー
…という記述です。
+ 論文採録No異常入力(異常時処理確認) : 入力値異常
+ 入力値異常 : 異常値
+ 参加者種別・チケット種別価格反映(結果網羅) : 有則組合せ確認
+ 参加者種別の入力判定・価格反映(結果網羅) : 単体パラメータ確認
+ レスポンシブでのチケット名表示(表示確認) : 表示くずれ有無
+ 価格確認表操作レスポンス(性能評価) : レスポンス
+ チケット名文字数対価格確認表(結果網羅) : 単体パラメータ確認
+ チケット種類の数対価格確認表(結果網羅) : 単体パラメータ確認
+ チケット名文字数対チケット種別(結果網羅) : 単体パラメータ確認
+ チケット種類の数対チケット種別(結果網羅) : 単体パラメータ確認
+ 論文採録No入力可否(結果網羅) : 単体パラメータ確認
+ 表示くずれ有無 : 使用性
+ レスポンス : 性能効率性
+ 有則組合せ確認 : 機能適合性
+ 単体パラメータ確認 : 機能適合性

正式に記述したカタマリーの例＠astah*
全部書くと
ちょっと
メンドイので、
効果を感じない
部分は外してOK
ワーク②：回答例（astah*使用時の正式記述）

キガカリーの参考：現場の言葉を使おう
ほぼ同じ概念に対して複数の表現ができる場合が…
⇒ふるまい？論理性？ロジック？有則組合せ？
困った時には「現場にあわせた（しっくりくる）言葉」
を選んでおきましょう。
例：
・ふるまい / 論理性確認 / ロジック
単体パラメータ確認＆有則組合せ確認
・レスポンス / 応答速度
操作レスポンス＆通信速度＆処理レスポンス
・ボリューム / サイズ大データ処理
… 現場でよく使っている言葉
を用いることで意見交換が
やりやすくなります。

キガカリーの参考：キガカリーシリーズ
キガカリーは蓄積することで役立つ情報となります。
※整理して全体を示したものを「ブンルイー」と呼ぶ
　仕様書出図後の仕様変更、ユーザ固有の環境、MWとのIF
　メモリがあふれた時、ハード的なエラー
　想定外、数値、起動、終了、割り込み、タイミング
抜けやすい観点
無し、増加、減少、他に、一部、
逆、異なる、早い、遅い、前、後
詳細
参考：HAZOP
ﾘﾄﾗｲ（成功）、再接続（成功）、規制、
再送、未接続でHHH、未契約でGGG、
契約外、無応答
リカバリ
エラー、異常、NG、例外、XX失敗、
ﾘﾄﾗｲｵｰﾊﾞｰ、ﾀｲﾑｱｳﾄ、不正、Reject、
状態不一致、障害、同期はずれ、想定外／未知
異常系
信頼性、異常系
ガイドワード
外側、例外、間、対象、類推
そ、れ、あ、た、る
狙いどころ
パステスト
構造テスト
競合
状態
カバレッジ
構造
両立性テスト
構成テスト
データ互換性テスト
拡張性テスト
ストレステスト
ロードテスト
ユーザビリティテスト
信頼性テスト
回復性テスト
ロバストネステスト
セキュリティテスト
シナリオテスト
機能組合せテスト
機能テスト
※ゆもつよメソッドより
移植性
保守性
効率性
使用性
信頼性
機能性
置換製
共存力
インストールのしやすさ
順応性
テストのしやすさ
安定性
変更のしやすさ
分析のしやすさ
資源の活用度
時間挙動
魅力
操作のしやすさ
学習のしやすさ
理解のしやすさ
復元力
フォールトレランス
成熟度
セキュリティ
相互運用性
正確性
適切さ
手続きテスト
ドキュメンテーションテスト
サービスアビリティテスト
リカバリーテスト
信頼性テスト
インストーラビリティテスト
互換性/コンパチビリティテスト
設定/コンフィグレーションテスト
ストレージテスト
性能/パフォーマンステスト
セキュリティテスト
ストレステスト
ボリュームテスト
機能テストを意味する（テストレベルのFunction Testと分けている）
Procedure Testing
Documentation Testing
Serviceability Testing
Recovery Testing
Reliability Testing
Installability Testing
Compatibility/conversion Testing
Configuration Testing
Storage Testing
Performance Testing
Security Testing
Usability Testing
Stress Testing
Volume Testing
Facility Testing
開発プロセス改善の指標となる（改善、予防）
リリース後の品質リスクを見積もる（リスク）
要件を満たすことを保証する（保障）
欠陥やバグを検出する(検出)
「バグゼロ」の落とし穴
テストは条件次第
殺虫剤のパラドックス
欠陥の偏在
初期テスト
完全なテストは不可能
テストは欠陥があることしか示せない
一般的なテストの必要性
テストの原則
移植性
保守性
効率性
使用性
信頼性
機能性
テストタイプ一覧
Myersの
システムテストカテゴリ
品質特性（ISO9126）
汎用観点
（追加予定）
負荷時使用
シナリオ（シーン）
要求
物理特性
仕様/機能
水温変化の規定
起動、アップデート
競合
状態遷移
ロジック
仕様適合
外観検査
特性/精度
タイミング変化
H/W
ポットのシステム
ロジック
高温層を用いた加速確認
環境
ユースケース
要求
負荷時仕様
連続
振る舞い
水質
負荷時性能
分かりやすさ
H/W
要求
仕様/機能
H/W性能
レスポンス
状態遷移
ロジック
環境（電圧、温度、振動・衝撃）
意地悪
タイミング変化
競合
仕様適合（当たり前品質）
量産における品質安定性
長期使用可能な耐久性
ユーザにとっての使用性
安全性
テスコン'12@東京
タイミング、状態信頼性テスト
機能、状態、環境組合せ（無側の確認）
連続テスト
取説・シナリオテスト
機器性能評価/スペック評価
構造テスト/ユーザ提供の状態確認
機能テスト
安全性テスト
参考：テストタイプ一覧
ノイズのタイミングへの影響
アクティブノイズ
割込み操作、タイミング
動的分析
時系列での検討
ワンプレートスタイルで分析
シナリオベース
メモ
タイミング、状態信頼性テスト
割込み
操作
ノイズ
静的分析（内部構成）
アクティブノイズ
外部環境
使用環境
静的分析（外部構成）
ワンプレートスタイルで分析
システム、構成ベース
メモ
機能、状態、環境組合せ（無側の確認）
CPU
メモリ
確認項目
タイマも使用する
沸騰、保温の繰り返し
水を補充しながら連続操作
連続操作
夜沸騰して朝まで保温連続稼動
家庭環境
コンビニ環境
繰り返しで使用される環境を活用
想定シーン
連続テスト
状態網羅テストシナリオ
タイマ
ロックON時
ロックOFF時
構造テスト/ユーザ提供の状態確認
音声、ブザー通知
LED表示
液晶表示
表示
カルキ抜き
節電タイマ機能
タイマ機能
便利機能
エラー検知
ロック機能
安全機能
吐水量
容量
沸騰機能
保温機能
基本機能
想定ユーザテスト
エキスパートレビュー
方法
満足度
分かりやすさ
操作学習
操作認識
主観評価、アンケート
企業イメージへの配慮
ユーザと環境に合せる
操作のしやすさ
理解のしやすさ
見つけやすさ、見易さ
評価基準
温度異常を知る
水位センサ異常を知る
水が満水を知る
水が空になったことを知る
温度を見る
水位を確認する
タイマ使用を止める
時間を計る
給湯ロックを解除する
給湯ロックを行う
カルキ抜きを行う
沸騰させる
モード切替
60℃
90℃
98℃
保温する
給湯する
操作
各テストフレーム
（システム/ユーザ）
競合表に従った状態、ボタン組合せパターン競合表
チャタリング想定
状態網羅（遷移表ベース、2スイッチ）
タイマボタン
エラーの割込みパターン想定
沸騰行為
状態網羅（遷移表ベース、2スイッチ）温度制御
状態網羅（遷移表ベース、2スイッチ）水位メータ
解除ボタン
保温ボタン
沸騰ボタン
状態遷移
構造テスト
モード遷移時間
保温制御精度
精度
範囲
サーミスタ水温検出
温度推移
保温時間
保温性能
温度制御
吐水量の確認給湯量
給湯口
給湯
条件網羅ブザー
条件網羅ポンプ
デバイス：出力
条件網羅サーミスタ
条件網羅第n水位センサ
条件網羅満水センサ
条件網羅蓋センサ
デバイス：入力
条件網羅水位メータ
条件網羅温度/モード表示窓
条件網羅保温ランプ
条件網羅沸騰ランプ
条件網羅ロックランプ
条件網羅タイマ残り時間表示枠
操作パネル：出力
条件網羅給湯ボタン
条件網羅保温設定ボタン
条件網羅沸騰ボタン
条件網羅解除ボタン
条件網羅タイマボタン
操作パネル：入力
デバイス機能
ヒータへの制御出力の妥当性確認ヒータ制御
温度判定のロジック確認、パターンによる妥当性検証温度判定
水位判定の論理組合せ条件網羅水位判定
エラー発生条件の条件網羅エラー判定
状態遷移×構造テストで確認状態網羅
ボタン入力の論理判定条件網羅
保温モード
ボタン入力の論理判定条件網羅
ロック/解除
サブ機能
状態遷移×構造テストで確認状態網羅タイマ
給湯停止
給湯する
ふるまいが目的に適合していること
ボタン押下時の有則組合せ
給湯
ミルク
節約
高温
各モード保温
カルキ抜き
沸騰
アイドル
ふるまいが目的に適合していること
ボタン押下時の有則組合せ
温度制御
メイン機能
メイン機能、サブ/サポート機能、デバイス機能の3層で検討
仕様->保温モード×機能テスト
仕様->ロック/解除×機能テスト
仕様->温度制御×機能テスト
仕様->給湯×機能テスト
仕様->タイマ×機能テスト
詳細分割（メモ）
機能テスト
蓋状態が獲得できない時の起動時処理確認
状態×ボタンを押しっぱなしにした場合の振る舞い確認（All Pair）
沸騰中に蓋を開けた場合の加熱停止
水が無い、少ない場合の沸騰ボタン押下
温度が上がらないエラー
温度上がりすぎのケース
ノイズ、環境
HW故障
HWの異常、故障による要因
無意識
わざと、意地悪
人による要因
検討方法（メモ）
安全性テスト（機器及びユーザ）
各テストフレーム
（ソフトウェア/機器）
テスコン'13
テストタイプベース
おまえは
今まで設計した
テストの種類を
覚えているのか？
※マインドマップ
蓄積の例
詳細はヒミツ

キガカリーの参考：キガカリーシリーズ
キガカリーは蓄積することで役立つ情報となります。
※整理して全体を示したものを「ブンルイー」と呼んでおります。
品質特性
製品
利用時リスク回避性
利用状況網羅性利用時有効性
満足性
利用時効率性
機能適合性
性能効率性
互換性使用性信頼性
セキュリティ
保守性移植性
欠陥検出戦略/ガイドP（っぽい）ワード
ガイドP
異常値
並行処理
不具合確認
通信費
処理重ね
タイミング
機能組合せ機器組合せフェールソフト
機能適合性
使用性
- 使いやすさ
- 分かりやすさ
ナビゲーション
- 異常時処理確認
異常値
入力値異常
異常操作
登録キュー超過入力
- 性能評価
性能効率性
- 正常動作確認
- 信頼性評価
信頼性
ボリューム
同時入力・処理途中取消
不具合確認
- 2因子網羅
機能組合せ
- 性能評価
処理重ね
タイミング
- 結果網羅
ふるまい
操作レスポンス - 正常復旧確認
復旧処理
処理中異常
互換性
周辺機器
割込み処理
- 結果網羅
機能排他
HWリソース
CPU量
メモリ量
ディスク
大きなデータ
（ファイル
等）を扱う
ストレス
瞬間的な負荷
状態遷移
- 因子網羅
- 2因子網羅
機器組合せ
因子組合せ
キューデータへの同時処理
ファイル異常
信頼性や性能効率性の一部だが、
ドメインで特に気にする部分を明示
機器対応
規格・プロトコル対応
セキュリティ
不正利用
データ互換コンテンツ互換
レスポンス
通信速度
長時間使用
- 学習性 : int
見やすさ
不定値入力
Ver.170125
フェールソフト
縮退運転片肺運転
- 通信費評価
通信費
音声処理重ね
負荷時のタイミング
映像処理重ね
最大処理時の負荷
制御時タイミング
ジャンプタイミング
歌いやすさ
コンテンツ処理重ね
※某テスコン
における
キガカリー
の分類例
＝ブンルイー

現場では、誰かが作ったテストケースの実施もあれば、
誰かの作ったカタマリーを引き継いで作業もあるかも。
また、抜けを確認するには複数名の意見が大事です。
※議論と共有時は、ことばだいじ。
実際の業務では、言葉あわせも重視しておきましょう。
XXの処理速度
を確認して…
レスポンスの確認は
システムとして大事だよ
「処理速度」と
「レスポンス」って
同じなのかな？
現場では…

もいっちょ
カタマってみよう！
波紋習得後

投稿論文情報設定
+・・・
+・・・
…
参考：テストカタマリーの流用方法
カタマリーをそのまま流用は難しいかもですが…
ふるまいﾚｽﾎﾟﾝｽ
異常XX ・・・
+ロジカルテストケースA：ゾクセー
+ロジカルテストケースB：ゾクセー
+ロジカルテストケースC：ゾクセー
+ロジカルテストケースX：ゾクセー
+ロジカルテストケースY：ゾクセー
+ロジカルテストケースZ：ゾクセー
キガカリーを用いることで
テストを考えやすくできます。
流用

+・・・
+・・・
…
参考：キガカリーのパターン化
例えば、ユーザの入力に対応する機能という共通点で
キガカリーは似たものになるかもしれません。
+・・・
+・・・
…
ふるまいﾚｽﾎﾟﾝｽ
異常XX ・・・
共通キガカリー

+・・・
+・・・
…
参考：キガカリーのパターン化
例えば、ユーザの入力に対応する機能という共通点で
キガカリーは似たものになるかもしれません。
⇒共通キガカリーをパターンとして表現できます。
+・・・
+・・・
…
ユーザ入力パターン
~ ふるまい
~ 入力値異常
~ レスポンス
…
パターンが定義する
キガカリーを
使用することで
検討がやりやすい

参考：キガカリーパターンの例
某コンテストで使用したパターンの例
~ 信頼性
~ 使用性
~ 性能効率
~ 異常値
~ 機能適合
ユーザ接点機能
~ 信頼性
~ 相互運用
~ 性能効率
~ 並行処理
~ 異常値
~ 機能適合
IF接点機能
~ 信頼性
~ 機能適合
機能共通
~ 信頼性
~ 性能効率
~ 機能適合
制約有機能
~ 相互運用
~ 信頼性
~ 性能効率
~ 並行処理
~ 機能適合
ストレージアクセス
~ 信頼性
~ 使用性
~ 性能効率
~ 異常値
~ 機能適合
+ 予約登録因子組合せ(2因子網羅) : 因子組合せ
+ 機能組合せ : 機能組合せ
+ タイミング : タイミング
~ 信頼性 : 信頼性
~ 使用性 : 使用性
~ 性能効率 : 性能効率性
~ 異常値 : 異常値
~ 機能適合性 : 機能適合性
<<ユーザ接点機能>>
予約をする
全体を見たいときには
（スペースの都合上）
ステレオタイプで
パターンを表してます+ 機能組合せ
+ タイミング
予約をする
+ フェールソフト
<<制約有機能>>
<<IF接点機能>>
配信をする
+ 使用性
+ 処理重ね
+ タイミング
<<制約有機能>>
歌う

カタマリーの
知見まとめ
DIOとのバトル

参考：カタマリー記法まとめ
カタマリー単体の記法については、別途まとめてます。

参考：カタマリーが大きすぎる場合
１つのカタマリーが大きすぎる場合、分割を推奨。
「has-a」を用いて分割を明示。
参加申込みチケット：単体パラメータ
参加申込みチケット：組合せ・品質特性
参加申込み登録画面
他要素

参考：分割の例
例えば、DFDの階層と対応して分割を行うなど。
1-6 予約
をする
リモコン　
（LAN/赤外線）
パネル
モニタ
予約入力
検索入力
1-6* 検索
をする
予約
表示
スピーカ検索結果
予約キュー
1-6_1 予約
登録をする
登録予約曲、　　
削除、順番変更
予約曲入力
予約操作
予約時表示　　
（割込み有無）
営業開始、
営業停止
2-3_1 予約
表示をする予約時表示
割り込み曲、
後回し曲
1-6*_1予約
系操作をする
予約入力
オーナー設定保存データ
予約表示
マスク
検索結果　
帳票データ
本体モニタ
1-6-4 予約確
認表示をする
予約一覧
予約確認表示
予約確認操作
楽曲履歴データ
+ 機能組合せ
+ タイミング
予約をする
~ 信頼性
~ 使用性
~ 性能効率
~ 異常値
~ 機能適合
+ 予約同時入力(正常動作確認) : 同時入力・処理
+ 予約TAT確認(性能評価) : 操作レスポンス
+ 操作手順の確認(分かりやすさ) : ナビゲーション
+ 予約オプション設定を確認する(結果網羅) : ふるまい
+ 検索結果から予約登録をする(結果網羅) : ふるまい
+ 曲Noで予約登録をする(結果網羅) : ふるまい
~ 同時入力・処理 : 信頼性
~ 操作レスポンス : 性能効率性
~ ナビゲーション : 使用性
~ 異常値入力 : 異常値
~ ふるまい : 機能適合性
予約系操作をする
+ キュー同時操作を確認する(正常動作確認) : キューデータへの同時処理
+ キュー登録、操作、削除時入力(正常動作確認) : 同時入力・処理
+ 予約途中、処理中取り消し(正常動作確認) : 途中取消
+ キュー最大個数時処理(異常時処理確認) : 登録キュー超過入力
+ 予約をキューから削除する(結果網羅) : ふるまい
+ キューの順番変更を行う(結果網羅) : ふるまい
+ 後回し登録を確認する(結果網羅) : ふるまい
+ 割込み登録を確認する(結果網羅) : ふるまい
+ キューへの追加と順番を確認する(結果網羅) : ふるまい
+ キューデータへの同時処理 : タイミング
~ 同時入力・処理 : 信頼性
~ 途中取消 : 信頼性
~ 登録キュー超過入力 : 異常値
予約登録をする
予約キュー処理検討 >OPモデル
+ 予約確認（キュー）表示を確認する(結果網羅) : ふるまい
予約確認表示をする
+ 予約時表示を確認する(結果網羅) : ふるまい
予約表示をする
+ 予約削除時の動作確認(正常動作確認) : 途中取消
+ データの多い場合(性能評価) : ボリューム
+ 楽曲履歴登録を確認する(結果網羅) : ふるまい
~ 途中取消 : 信頼性
~ ボリューム : 信頼性
楽曲履歴登録をする
+ 予約登録因子組合せ(2因子網羅) : 因子組合せ
+ 機能組合せ : 機能組合せ
+ タイミング : タイミング
~ 信頼性 : 信頼性
~ 使用性 : 使用性
~ 性能効率 : 性能効率性
~ 異常値 : 異常値
~ 機能適合性 : 機能適合性
予約をする

ざっくりまとめ
・カタマリー単体構造、考え方をじっくり紹介したよ。
・記法や考え方についてはA4にまとめた内容をみてね。

第1部・完！
テストを表現してみよう完

コンテンツ
描いてみよう

描いてみよう
カタマリー図の
バリエーション
ストレイツォ

テストカタマリーのバリエーション
テストカタマリーの各図バリエーションを紹介してみます。
画面以外：品質特性ベース
+ UI準拠 : ユーザビリティ
ユーザビリティ
+ 別アプリ同時動作 : 互換性
+ アプリ内複数機能動作 : 互換性
+ OS通知同時表示 : 互換性
共存（互換性）
+ OS互換 : 移植性
OS互換
各画面対応
~ 登録データ数 : 性能効率性
+ 各機能確認 : 機能適合性
<<データ登録・編集・削除>>
世界時計
- メモリリーク : 性能効率性
- 連続時動作 : 信頼性
連続動作（信頼性）
+ 想定以上の負荷 : 性能効率性
+ リソース連携 : 互換性->相互運用性
+ バックグラウンド通知 : 互換性
アラーム
~ バックグラウンド通知 : 互換性
タイマー
+ 分析の正確さ : 機能適合性
ベッドタイム
ストップウオッチ
<<pattern>>
データ登録・編集・削除
~ 想定以上の負荷 : 性能効率性
~ バックグラウンド通知 : 互換性
<<pattern>>
アラート通知
+ 負荷時確認(性能評価) : 負荷時バックグラウンド動作
+ 他アプリ動作時(通常動作) : バックグラウンド通知
+ スヌーズ処理確認(結果網羅) : ふるまい
+ アラーム動作確認(結果網羅) : ふるまい
+ 負荷時バックグラウンド動作 : 性能効率性
アラーム通知
アラーム
+ Siriからの操作(結果網羅) : リソース連携
+ 操作応答確認(性能評価) : 操作レスポンス
+ データ登録最大確認(性能評価) : 登録データ数
+ アラーム削除(結果網羅) : ふるまい
+ アラーム編集(結果網羅) : ふるまい
+ アラーム登録(結果網羅) : ふるまい
アラーム登録・表示
+ 負荷時確認(性能評価) : 負荷時バックグラウンド動作
+ 他アプリ動作時(通常動作) : バックグラウンド通知
+ スヌーズ処理確認(結果網羅) : ふるまい
+ アラーム動作確認(結果網羅) : ふるまい
+ 負荷時バックグラウンド動作 : 性能効率性
アラーム通知
+ 曲データ選択(結果網羅) : リソース連携
- リソース連携 : 互換性->相互運用性
ライブラリ曲選択
<<pattern>>
データ登録・編集・削除
編集画面にて登録解除
具体的テストケース
全体図
詳細図
エンティティ（塊）
１つに着目して
テストケースを具体化へ
全体の１つを
詳細で示す

公開用テストカタマリーワークショップ（説明のみ）

公開用テストカタマリーワークショップ（説明のみ）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 公開用テストカタマリーワークショップ（説明のみ）

Similar to 公開用テストカタマリーワークショップ（説明のみ） (20)

More from Noriyuki Mizuno

More from Noriyuki Mizuno (20)

Recently uploaded

Recently uploaded (8)