テスト設計コンテスト’17「話題沸騰ポット(GOMA-1015型)」
テスト設計

目次
1.はじめにチーム紹介
チームの立ち位置
テスト設計の流れ

2.テスト要求分析
テスト要求分析の流れ
仕様把握と機能要求分析
非機能要求分析
因子水準表

Page 2/25

3.テストアーキテクチャ設計
アーキテクチャ設計の流れ
テストアーキテクチャ全体俯瞰図
機能アーキテクチャ
非機能アーキテクチャ
システム全体俯瞰図

4.テスト詳細設計
テスト詳細設計の流れ
機能テスト詳細設計
非機能テスト詳細設計

5.まとめ

1.はじめに

Page 3/2X
3/25

チーム紹介

チーム名

いしえもん
リーダー

あずにゃん

ODA

ばやしこ

いいだぬき

発表者

でこパン４６２は入社２年目～４年目のテスト経験の浅いひよっこチーム。
普段の業務ではシステムテストを担当している。
今回はテスト設計技術向上のため、コンテスト参加を決めた。

1.はじめに

Page 4/25

チームの立ち位置
話題沸騰ポットメーカー
胡麻印まほうびん（株）

総合テスト委託

テスト専門会社（株）でこパンテスト部

製品開発部【提供資料】
・話題沸騰ポット（GOMA-1015型）
要求仕様書 第6版
・話題沸騰ポット（GOMA-1015型）
要求仕様書 第7版

テスト設計チーム
温度制御専門チーム
テスト実装チーム…でこパン４６２チームが担当

単体テストと結合テストは、胡麻印まほうびんで完了している。
でこパン４６２チームは 総合テストのテスト設計 を担当する。

1.はじめに

Page 5/25

テスト設計の流れ
・話題沸騰ポット（GOMA-1015型）要求仕様書 第6版
・話題沸騰ポット（GOMA-1015型）要求仕様書 第7版

・テストアーキテクチャ全体俯瞰図
・機能アーキテクチャ
・非機能アーキテクチャ・システム全体俯瞰図

IN

OUT

IN

テスト
要求分析

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

テスト
詳細設計

OUT

IN

OUT

・QAシート・機能USDM・状態遷移図／状態遷移表
・非機能要求分析（マインドマップ・非機能テスト一覧）
・因子水準表・機能テスト詳細設計
・非機能テスト詳細設計

テスト
実装

テスト
実施

…でこパン４６２チームが担当する「総合テスト」の範囲…成果物

2.テスト要求分析

Page 6/25

テスト要求分析の流れ②①因子水準表
状態遷移図
状態遷移表

テストベース
読み込み

機能USDM

QAシート③
非機能マインドマップ＜テスト要求分析全体像＞

非機能テスト一覧

2.テスト要求分析

Page 7/25

仕様把握と機能要求分析①
1.テストベースの理解
メンバー各自でテストベースを読み込んだ後、わからない点や疑問に思った点をディスカッションした。
解決しなかった疑問点は、「QAシート」に記載して管理を行った。
疑問点を
QAシートに記入

SEから回答をもらい疑問点を解消

疑問点は開発元SEに確認を行い、仕様を確定した。（今回はでこパン462のメンバーがSEとして回答）

2.テスト要求分析
2.機能USDMの作成【機能USDM】

Page 8/25

各要求仕様に項番を付与⇒下流工程とのトレーサビリティを確保

仕様理解作業の結果多くの不明点が挙がり、要求仕様書外の仕様が出た。
テスト設計・実施において、要求仕様書だけでは不十分!!

QAシートで挙がってきた仕様を追記

要求仕様書+
QAシートで洗い出された仕様

テスト設計・実施は、「機能USDM」を元に行う!!

2.テスト要求分析

Page 9/25

仕様把握と機能要求分析②【状態遷移図】

ポット全体沸騰/保温行為の図を作成

仕様理解の際、ポットの振る舞いが複雑であることがわかった。
「状態遷移図」 を作成!!（ツールを活用）

状態の仕様を俯瞰・把握しやすくした。
また、振る舞いの漏れを失くすため、状態遷移図を元に 「状態遷移表」 を作成!!
挙がった不明点は仕様確定後「機能USDM」に追加。

【状態遷移表】状態×イベントで不明点や無効な組み合わせが出てきた

2.テスト要求分析

Page 10/25

機能分析により、要求仕様書から 「仕様や機能に関するテスト観点」 を洗い出すことができた！

因子水準表

テストベース
読み込み

状態遷移図
状態遷移表
機能USDM
QAシート

非機能マインドマップ

非機能テスト一覧

しかし、「ユーザ視点」 や 「実際の使用環境」 など、テスト観点や要求に不足がある!!
そこで、非機能分析を行い、洗い出しを行った。

2.テスト要求分析
非機能要求分析①
マインドマップA

マインドマップB

A.思いついたものから洗い出し

B.品質特性から洗い出し

Page 11/25

AとBを合体・整理した「非機能マインドマップ」 を作成!!

2.テスト要求分析

Page 12/25

非機能要求分析②
整理した非機能マインドマップをテストタイプと紐付け、「非機能テスト一覧」を作成！
【非機能テスト一覧】

テストタイプから観点を抽出・追加観点が当てはまらないテストタイプについては、テストタイプから観点を抽出した。

2.テスト要求分析
因子水準表因子と水準を洗い出し、因子水準表を作成した。

【因子水準表】詳細設計工程、およびテスト実施はこの水準を利用して行う。

Page 13/25

3.アーキテクチャ設計

Page 14/25

アーキテクチャ設計の流れ
テスト設計
テスト要求分析

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

テスト
詳細設計

目的に沿ったアーキテクチャをそれぞれ作成！
①下流工程に生かす②全体を把握できる・テストアーキテクチャ全体俯瞰図
・機能アーキテクチャ
・非機能アーキテクチャ・システム全体俯瞰図

3.アーキテクチャ設計

Page 15/25

テストアーキテクチャ全体俯瞰図【テストアーキテクチャ全体俯瞰図】

テスト要求分析で多くの観点を洗い出すことが出来た。
そこで、今度は洗い出した観点を整理するために、全体を俯瞰出来る図を作成した。
機能テスト+
非機能要求分析で出した各テストタイプ
上記をテストタイプ毎にまとめ、総合テストで実施するテスト全体の俯瞰図を作成！
テストアーキテクチャ設計では、さらにテスト条件の精査を行い、テスト実施が行いやすい単位にまとめていった。

3.アーキテクチャ設計

Page 16/25

機能アーキテクチャ
要求分析で作成した「機能USDM」を更に整理し、同時に確認できるテスト条件をまとめた。
【機能アーキテクチャ】

同時に確認できるテスト条件を関連IDで紐付け実施対象外のため除外

テスト条件をまとめることで、実装及び実施工程での無駄を省いた！

3.アーキテクチャ設計
非機能アーキテクチャ①

Page 17/25【非機能アーキテクチャ】「非機能一覧」のテスト条件を表形式で整理し、「非機能アーキテクチャ」を作成。

②①
テスト条件の精査

非機能のテスト条件毎にIDを付与⇒テスト詳細設計とのトレーサビリティを確保

また、「優先度」を付与し、アーキテクチャに記載した。
①テスト条件毎に3段階で付与（★表記）②テストタイプ毎に優先度の平均値を算出付与した優先度は、テストの実施順決定に使用。

3.アーキテクチャ設計

Page 18/25

非機能アーキテクチャ②
非機能アーキテクチャを元に、テスト実施順を3パターン作成した。
→状況に合わせたテスト実施が出来るように配慮！
【①優先度の高いテスト条件から実施】【②優先度の高いテストタイプから実施】【③テスト条件、テストタイプ共に優先度が高いものから実施】①、②を合わせたテスト実施順

状況に合わせて、テスト実施順を調整・決定する！

3.アーキテクチャ設計
システム全体俯瞰図

Page 19/25【システム全体俯瞰図】

課題
・話題沸騰ポットの動作や状態が複雑→このため、メンバー間で仕様認識のズレが生じやすいシステム全体を俯瞰できる図を作成！
システムの動作と全体像をチーム全員で共有できるようにした

4.テスト詳細設計

Page 20/25

 テスト詳細設計の流れ
テスト設計
テスト要求分析

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

テスト詳細設計要求分析～アーキテクチャ設計で洗い出したテスト条件を元に、テスト詳細設計を行う。
・機能USDM・機能アーキテクチャ
・因子水準表・非機能アーキテクチャ
・因子水準表機能テスト詳細設計

非機能テスト詳細設計

4.テスト詳細設計Page 21/25

機能テスト詳細設計①
要求分析で作成した「機能USDM」ベースのテストで、要求仕様の確認を行うことにした。
【機能テスト詳細設計】

テスト条件からテストケースに落とし込む

4.テスト詳細設計

Page 22/25

機能テスト詳細設計②
機能テストではUSDMベースのテストを行うが、それだけでは、機能間の組み合わせテストを十分に行うことが出来ない！
テストの漏れ・抜けに繋がる可能性!!

新たに「状態×操作テスト」のテストケースを作成・実施することにした！

【状態×操作表】

因子と水準からオールペア法でテストケースを作成

4.テスト詳細設計

Page 23/25

非機能テスト詳細設計①【性能テスト】
テスト条件
PER-001
沸騰にかかる時間が適切であること・沸騰にかかる時間とは？
・適切な時間とは？
PER-002
保温温度に達する時間が適切であること

PER-001
沸騰ボタンを押下してから、沸騰完了のブザーが鳴るまでの時間が20分以内であること②因子と水準の分析
温度

水量

常温

水位メータが1つ点灯する水道水位メータが2つ点灯する

60℃

水位メータが3つ点灯する

90℃

水位メータが4つ点灯する

98℃

PER-003
給湯するのにかかる時間が適切であること

ID： PER-001
テスト条件： 沸騰にかかる時間が適切であること
期待結果： 沸騰ボタンを押下してから、沸騰完了のブザーが鳴るまでの時間が20分以内であること
テストパターン： 温度（常温、水道、60℃、90℃、98℃）
その他条件： 水量（水位メータが4つ点灯する）

4.テスト詳細設計

Page 24/25

非機能テスト詳細設計②【非機能テスト詳細設計】

テストケース毎にIDを付与⇒テスト実装とのトレーサビリティを確保

テスト条件からテストケース作成

ID： PER-001
テスト条件： 沸騰にかかる時間が適切であること
期待結果： 沸騰ボタンを押下してから、沸騰完了のブザーが鳴るまでの時間が20分以内であること
テストパターン： 温度（常温、水道、60℃、90℃、98℃）
その他条件： 水量（水位メータが4つ点灯する）※性能テストより一部抜粋

非機能テストの詳細設計は、テストタイプ毎に、テスト条件からテストケースを作成した。
また、ユーザビリティテストについては、アンケート形式でテスト実施することにした。

5.まとめPage 25/25

全体
Point!!

工程間のトレーサビリティを意識！

→上流工程で要求やテスト条件にIDを付与し、トレーサビリティを重視したテスト設計を行った。 下流工程（テスト実装等）作業における抜け・ 漏れ防止や、仕様変更時の修正対応のしやすさを考慮した。
Point!!

新しいことへのチャレンジ！

→① テストアーキテクチャ設計への初挑戦。次工程に生かせるアーキテクチャを目指した。

② ユーザビリティテストの詳細設計にて、アンケート形式のテスト設計を行った。
普段行わないようなテスト設計とユーザ目線の品質検証を意識した。

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