でこパン462

Page
1/8
Page 1/2X
チーム紹介だよ―♪

チーム名

いしえもん
リーダー

あずにゃん

ODA

ばやしこ

いいだぬき

発表者

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

でこパン462

Page
2/8

テスト設計の流れ

次は機能観点の説明！
・テストアーキテクチャ全体俯瞰図
・機能アーキテクチャ
・非機能アーキテクチャ・システム全体俯瞰図・話題沸騰ポット（GOMA-1015型）
要求仕様書 第6版
・話題沸騰ポット（GOMA-1015型）
要求仕様書 第7版

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

IN

OUT

IN
テスト
要求分析

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

テスト
詳細設計

OUT

IN

OUT

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

・機能テスト詳細設計
・非機能テスト詳細設計

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

 テスト詳細設計
テスト設計

テスト設計

②

テスト実施

テスト
実装

因子水準表
①

状態遷移図
状態遷移表

テストベース
読み込み

テスト
要求分析

機能USDM

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

テスト
詳細設計

QAシート

非機能テスト一覧

テスト
詳細設計

目的に沿ったアーキテクチャをそれぞれ作成！
①下流工程に生かす・機能USDM・機能アーキテクチャ
・因子水準表機能テスト詳細設計

・非機能アーキテクチャ
・因子水準表非機能テスト詳細設計②全体を把握できる＜テスト要求分析全体像＞

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

要求分析～アーキテクチャ設計で洗い出したテスト条件を元に、テスト詳細設計を行う。

③
非機能マインドマップ

テスト
要求分析

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

Page
3/8

要求分析：機能観点

次は非機能観点に進むですよ1.テストベースの理解
メンバー各自でテストベースを読み込んだ後、わからない点や疑問に思った点をテスト設計・実施は、「機能USDM」を元に行う!!

ディスカッション！
解決しなかった疑問点は、「QAシート」に記載して管理！

疑問点をQAシートに記入

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

2.機能USDMの作成

QAシートで挙がってきた仕様を追記【機能USDM】

仕様理解作業の結果【状態遷移図】

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

多くの不明点が挙がり、要求仕様書外の仕様が出た！

要求仕様書

+
QAシートでテスト設計・実施において、要求仕様書だけでは不十分!!

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

洗い出された仕様

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

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

でこパン462

Page4/8

要求分析：非機能観点

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

次はアーキテクチャ設計だ！

因子水準表
状態遷移図
状態遷移表

テストベース
読み込み【因子水準表】機能USDM

因子と水準を洗い出し、因子水準表を作成した。

QAシート

非機能マインドマップ

非機能テスト一覧「ユーザ視点」 や 「実際の使用環境」 など、テスト観点や要求に不足があるぞ。。。

非機能要求分析
マインドマップA

マインドマップB

A.思いついたもの

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

整理した非機能マインドマップをテストタイプと紐付け、「非機能一覧」を作成！

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

テストタイプから観点を抽出・追加

でこパン462

Page
5/8

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

課題
・話題沸騰ポットの動作や状態が複雑→このため、メンバー間で仕様認識のズレが生じやすい
テスト要求分析で多くの観点を洗い出すことが出来た。
そこで、今度は洗い出した観点を整理するために、全体を俯瞰出来る図を作成した。

システム全体を俯瞰できる図を作成！
システムの動作と全体像をチーム全員で共有できるようにした機能テスト+
非機能要求分析で出した各テストタイプ

上記をテストタイプ毎にまとめ、総合テストで実施するテスト全体の俯瞰図を作成！
テストアーキテクチャ設計では、さらにテスト条件の精査を行い、テスト実施が行いやすい単位にまとめていった。

次は機能、非機能のアーキテクチャ設計！

でこパン462
機能アーキテクチャ

Page
6/8
要求分析で作成した「機能USDM」を更に整理し、同時に確認できるテスト条件をまとめた。

同時に確認できるテスト条件を関連IDで紐付け

続いて機能テスト詳細設計！

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

実施対象外のため除外非機能アーキテクチャ①【非機能アーキテクチャ】

非機能アーキテクチャ②
非機能アーキテクチャを元に、テスト実施順を3パターン作成した。

「非機能一覧」のテスト条件を表形式で整理し、→状況に合わせたテスト実施が出来るように配慮！

「非機能アーキテクチャ」を作成。

【①優先度の高いテスト条件から実施】②

非機能のテスト条件毎にIDを付与⇒テスト詳細設計とのトレーサビリティを確保【②優先度の高いテストタイプから実施】①

テスト条件の精査【 ③テスト条件、テストタイプ共に優先度が高いものから実施】

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

①、②を合わせたテスト実施順

でこパン462

Page
7/8

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

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

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

テスト条件からテストケースに落とし込む【状態×操作表】

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

でこパン462

Page
8/8

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

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

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

水量

常温

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

水道

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

60℃

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

90℃

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

98℃

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

ID： PER-001
テスト条件： 沸騰にかかる時間が適切であること
期待結果： 沸騰ボタンを押下してから、沸騰完了のブザーが鳴るまでの時間が20分以内であること
テストパターン： 温度（常温、水道、60℃、90℃、98℃）
その他条件： 水量（水位メータが4つ点灯する）【非機能テスト詳細設計】
非機能テストの詳細設計
は、テストタイプ毎に、テスト条件からテストケースを作成した。
また、ユーザビリティテストについては、アンケート形式でテスト実施することにした。

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