はじめての共同作業
テスト設計コンテスト‘21 U-30クラス 決勝戦

金田直純 仲澤圭汰
2021/9/18(土)Contents
1.コンセプト
2.プロセス全体像と強みの外観
3.各アクティビティの強み詳細
1.テスト計画
2.テスト要求分析
3.テストアーキテクチャ設計
4.テスト詳細設計
5.テスト実装

4.結論

コンセプト~はじめての共同作業の課題設定~

コンセプト
私たちの課題： 網羅的なテストを設計、実行したい 各ステークホルダにテスト活動の価値ある情報を伝えたい👦
テストチーム

テストケース50件中Passが40件、Failが10件です

ミクロな視点

マクロな視点
このテストを実行すると、どの要求がテストできたのか

👦
マネージャ

テスト目的に沿ったテスト活動なのか👦
品証

このテスト観点はどの仕様を確認できるのだろう👦
設計

どのテストケースを優先して実行したほうが良いのだろう
👦
テスト
請負

品質の高いテスト活動を行い、ステークホルダに分かりやすく伝えることができれば、ステークホルダの意思決定に貢献できる

コンセプト①：高品質なテスト分析・設計
コンセプト②：ステークホルダの意思決定への貢献

プロセス全体像と強みの外観~テストベース・プロジェクト要求補足書をベースにテストプロセス設計~

プロセス全体像と強みの外観
テストベース・プロジェクト要求補足書をベースにテストプロセス設計
ポットの市場
事故事例

テストベーステスト
戦略
プロジェクト
要求補足書

テスト計画

テスト目的に合致した
テスト戦略策定とテスト要求分析戦略策定

要求仕様ベースとリスクベースのテスト分析

テスト
要求分析

ラルフチャート・FL表

テストコンテナ(評価モデル)

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

テスト観点
一覧表
(全体)

テスト
観点レビュー

目的の応じたテスト観点の構造化

テストコンテナ(実行モデル)

テスト実行

テストケース一覧

テスト手順一覧
テスト
詳細設計

テストデータ一覧
テスト実装

テストコンテナを活用したリプラン
テストカバレッジ管理

テスト設計技法適用しテストデータ抽出

テスト計画~システムテストのスコープ・指針を明らかにする~テスト計画の強み① テスト目的に適合したテスト戦略策定
システムテストのスコープを明確化するために、テストベース・プロジェクト要求補足書から、テスト対象のシステムアーキテクチャを推測し、各テストレベルのスコープを定義した
システムアーキテクチャ
外部仕様

ユースケース要求(テストベース)

Software内部仕様ユースケース

ModeControl

Diag

Lock
Control

Hardware

Other Hardware
取手,貯水部,ポンプ,水路,給水線※Applicationに影響がないもの

Timer
Control

リスク要求(リスク分析)
Error
Control

機能市場を想定したシナリオ

ユーザに特定の価値を与える要求(複数の機能で実現される要求)

機能レベルの内部仕様

Run Control

関数
関数

Communication

関数レベルの内部仕様

テストレベル / スコープ
受け入れテスト市場を想定したシナリオテスト

システムテスト
テストベースとの合致性のテスト
リスク低減・評価のためのテスト

結合テスト
システムの内部機能に対する機能・非機能テスト

単体テスト
関数に対する機能・非機能・構造テスト

ハードウェアテスト

Circuit※Softwareに影響がありユーザとインタラクト(操作/観測)があるもの

リスク要求(テストベース)

Temp.
Control※システムアーキテクチは想像で記載

Sensor/Device

Cover

Lamp

Display

ButtonBuzzer

電子部品の内部仕様

Tap

Outlet

Water
Level

(電子部品)
電子部品の仕様合致性(性能,素材,デザイン)テスト

ハードウェアテスト
ハードウェアの内部仕様(ハードウェア部品)
ハードウェアの仕様合致性(性能,素材,デザイン)テスト

システムテストのスコープ• テストベースとの合致性のテスト• リスク低減・評価のためのテスト

テスト計画の強み② テスト目的に適合したテスト要求分析戦略
テスト目的に合致したテスト要求分析を実現するために、テストベース分析結果からテスト要求分析戦略を検討
システムテストの目的
目的①：テストベースとの合致性のテスト
目的②：リスク低減・評価のためのテスト

テストベース分析結果(課題)
要求によってユーザとのインタラクトが明確でないケース
要求実現のために必要な仕様が漏れているケース

市場を想定したリスクに対してシステムへの要求が不足
FTA : Fault Tree Analysis

テスト要求分析戦略
ラルフチャートによるユーザとのインタラクト特定関連仕様マトリクスによるテスト観点の網羅的分析
アクティブノイズ分析によるボトムアップのリスク分析
FTAによるトップダウンのリスク分析

テスト要求分析~システムテスト戦略・テスト要求分析戦略に従いテスト観点を抽出~

テスト要求分析 ラルフチャートの上流適用
テスト分析戦略①：
ラルフチャートを上流適用し、ユーザーへ価値を与える振る舞いに着目したテスト観点・リスク要因のテスト観点の網羅的な抽出手法：要求からテスト観点を抽出する際に、ラルフチャートを参照しながらテスト観点を拡充していく

ラルフチャートのI/Oを参照しテスト観点も抽出する

ユーザーが行う可能性があるアクティブノイズ

システムテストのOutput

システムテストのInput••

ラルフチャートのアクティブノイズからリスク観点のテスト観点を抽出

要求ベースでテスト観点を抽出するときに、ユーザーに与える価値が何かという視点で抽出可能要求から出てきたテスト観点に加え、ユーザーのアクティブノイズによって引き起こされる可能性のあるテストしなければならないテスト観点を抽出可能

テスト要求分析 関連仕様マトリクスの活用
テスト分析戦略②：
関連仕様マトリクスにより、仕様の関連からテスト観点を網羅的に抽出、変更時の影響度分析への耐久性向上

手法：
要求仕様からテスト観点を抽出する際に、他の要求仕様で関連する仕様があるか否かを同時に抽出しマトリクス化する〇

テスト観点を抽出した…
直接関連する仕様には○

…

…

…

pot-221-13〇

pot-221-12〇

pot-221-11〇

pot-220-31…

〇

pot-220-21

pot-210-TReq-001〇

pot-220-11

pot-210-TReq-001

pot-210-12

pot-210-TReq-001

pot-210-11

テスト観点ID

△△△

△

△

△

… 抽出したテスト観点に関連した…
…
…

他の要求仕様には△① 他の要求仕様にまたがるシステムの振舞を網羅的に抽出可能② 仕様変更が発生した際にどのテスト観点に影響が発生するか抽出可能

テスト要求分析 FTAによるリスクベーステスト
テスト分析戦略③：
仕様外のリスクを抽出するために、FTAによるリスク分析を行い、市場を想定したリスクを低減手法：
対象製品を使用する際に発生する危険事象をトップ事象として、FTAにより故障モードを洗い出し、市場を想定したリスク観点のテスト観点を抽出
市場で発生する危険事象の内、最も危険な事情をトップ事象と設定する抽出した故障モードに関するテスト観点を抽出

FTAを実施し、トップ事象が発生する時の故障モードを洗い出す

故障モード

対策機能

テスト観点

ヒータ故障

ハードウェア断線

ヒータが故障し、水温が異常になった場合は、ハードウェア断線によりヒータをOFFすることを確認する

温度エラー検知

温度エラー検知した際に、ヒータ加熱を中止し、ヒータをOFFすることを確認する

…

…

…

要求仕様に含まれていないリスクを抽出することが可能となり、想定外のリスクに対してもテスト観点抽出しテスト実施する事が可能
FTA : Fault Tree Analysis

テストアーキテクチャ設計~目的の応じたテスト観点の構造化~

テストアーキテクチャの強み 目的に応じたテストコンテナモデル
目的：
テスト観点の十分性・妥当性の評価とフィードバックを実現
ステークホルダへのテスト観点の合意形成を実現

手段：2つの視点でアーキテクチャを捉える
テスト観点のテスト目的への合致性を示す→評価モデル
テスト観点の実行優先度を示す→実行モデル

構造化されていないテスト観点の課題
テスト観点
ユーザがコンセントを差すと、(システムはデフォルト設定を行い、)システムは各出力I/F
テスト目的に沿ったでアイドル状態であることをユーザに通知する。
※蓋センサonの時、沸騰行為に遷移するのでアイドル状態の確認のため蓋はあけておテスト活動なのかく。
ユーザがコンセントを抜くと、システムは各出力I/Fでシステム停止中であることをユーザに通知する。
【アクティブノイズから抽出】ユーザがコンセントを連続で抜き差しした場合に、システムはアイドル状態とシステム停止状態を繰り返し、各出力I/Fで正確にその時の状態をユーザに通知する。
(蓋が開いているかつ水位が正常の時)、ユーザが蓋を閉めると3s後に、システムは各出力I/Fで沸騰状態であることをユーザに通知する。
(蓋が開いているかつ水位が正常の時)、ユーザが蓋を閉めると3s未満の間は、(システムはアイドル状態を継続し)、システムは、各出力I/Fでアイドル状態であることをユーザに通知する。
(蓋が開いているかつ水位が異常(満水)の時)、ユーザが蓋を閉めると、(システムはアイドル状態を継続し)、システムは、各出力I/Fでアイドル状態であることをユーザに通知することを確認する。
(蓋が開いているかつ水位が水位が異常(空)の時))、ユーザが蓋を閉めると、(システム
このテストを実行すると、はアイドル状態を継続し)、システムは、各出力I/Fでアイドル状態であることをユーザにどの要求がテストできたのか通知することを確認する。
ユーザが蓋を開けた状態でコンセントを差すと、(システムはアイドル状態になり(沸騰行為へ遷移せず))、システムは、各出力I/Fでアイドル状態であることをユーザに通知する。
ユーザが蓋を開けたら1s後に、システムは各出力I/Fでアイドル状態をユーザへ通知する。
ユーザが沸騰ボタンを100ms押したら、システムは各出力I/Fで沸騰状態をユーザへ通知する。
【アクティブノイズから抽出】ユーザが沸騰ボタンを100ms以上長押しても、(システムは一度沸騰状態になるとそれを継続し)、システムは各出力I/Fで沸騰状態をユーザへ通知する。
【アクティブノイズから抽出】ユーザが沸騰ボタンを100ms未満短押しても、(システムは保温状態を継続し)、システムは各出力I/Fで保温状態をユーザへ通知する。

このテスト観点はどの仕様を確認できるのだろう

どのテストケースを優先して実行したほうが良いのだろう👦
品証

構造化することによるテスト観点の評価を実現
テストコンテナ 評価モデル
要求仕様ベース

👦設計

👦マネージャ

優先度S

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

Pot-210Pot-220

リスク

テスト観点

xxx

テスト観点

優先度A

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

xxx

xxx
リスク

優先度B

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

Pot-xxx

Pot-xxx

xxx

xxx

優先度C

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

優先度D

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

xxx

👦
テスト
請負

リスクベース

テストコンテナ 実行モデル

xxx

xxx

リスクxxx

テスト目的との関係を構造化
対象要求との関係を構造化

テスト優先度との関係を構造化

テスト観点のテスト目的に対する妥当性・十分性を評価できる
テスト詳細設計以降の活動順序を客観的に決定できるテストアーキテクチャ設計-テストコンテナ評価モデル目的：
テスト観点の十分性・妥当性を評価

手段：
テストベースに対するテスト観点をテストの目的により構造化
テスト分析技法 要求ID

テストコンテナ
評価モデル
要求仕様ベース

Pot-210
テスト観点

xxx

xxx

xxx

Pot-xxx

Pot-xxx

xxx

xxx

xxx

xxx

リスク

要求仕様ベース

pot-210B

pot-210

ユーザがコンセントを抜くと、システムは各出力I/Fで
pot-210-TReq-002 システムテスト
システム停止中であることをユーザに通知する。

D

pot-220

テスト観点

pot-220

リスク
pot-310

xxx
リスク
xxx

テスト観点ID テストレベル 優先度

ユーザがコンセントを差すと、(システムはデフォルト設定を行い、)システムは各出力I/Fでアイドル状態であることをユーザに通知する。
pot-210-TReq-001 システムテスト※蓋センサonの時、沸騰行為に遷移するのでアイドル状態の確認のため蓋はあけておく。

リスクベース

Pot-220

テスト観点(蓋が開いているかつ水位が正常の時)、ユーザが蓋を閉めると3s後に、システムは各出力I/Fで沸騰状 pot-220-TReq-004 システムテスト
態であることをユーザに通知する。
(蓋が開いているかつ水位が正常の時)、ユーザが蓋を閉めると3s未満の間は、(システムはアイドル状態
pot-220-TReq-005 システムテストを継続し)、システムは、各出力I/Fでアイドル状態であることをユーザに通知する。
【アクティブノイズ】沸騰中に給湯ボタンを押しても給pot-310-TRisk-055 システムテスト
湯されないこと

CDC

pot-310【アクティブノイズ】沸騰直後に給湯ボタンを押しても
pot-310-TRisk-056 システムテスト
給湯されることC

pot-320【アクティブノイズ】保温行為のとき、保温設定ボタン
pot-320-TRisk-067 システムテスト
を短押ししてもモードが切り替わらないことD

pot-330【アクティブノイズ】コンセントを連続で抜き差ししても、アイドル状態となり、沸騰ランプと保温ランプを消灯
pot-330-TRisk-081 システムテスト
し、操作パネルの温度／モード表示窓に、サーミスタの温度（℃）の数値は表示しないC

pot-330【アクティブノイズ】コンセントを連続で抜き差ししても、アイドル状態となり、温度制御を行わないため、水 pot-330-TRisk-082 システムテスト
温が変化しないこと

C

リスクベース

テスト分析技法で構造化することによるテスト観点のテスト目的に対する妥当性・十分性を評価できる

テストアーキテクチャ設計-テストコンテナ実行モデル
手段：客観的指標でテスト観点の評価と構造化

目的：
テストアーキテクチャ設計以降のアクティビティ優先度評価

優先度 要求ID

テストコンテナ
実行モデル
優先度S

TRisk-xxx
TRisk-xxx
TReq-xxx

具体的な優先度の評価方法は、各テスト観点に対して「発生した時のリスク」「主機能への影響度」の2軸し、両者の評価結果を組み合わせて優先度(S,A,B,C,D)を決定した

S

pot-250
pot-260

TRisk-xxx
TRisk-xxx
TRisk-xxx

pot-250

A

優先度A

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

pot-250

pot-210

優先度B

優先度C

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

B
pot-220
pot-220C
pot-220

優先度D

TRisk-xxx
TRisk-xxx
TReq-xxx

TRisk-xxx
TRisk-xxx
TRisk-xxx

pot-210D

pot-210

テスト観点

テスト観点ID テストレベル テスト技法

ユーザが解除ボタンを100ms以上押すと、(システムが安全と判断する条件下では、)ユーザは給湯のロックを行うことができ、システム pot-250-TReq-024 システムテスト
はユーザへロック状態をユーザへ通知する。
ユーザが給湯ボタンを押すと、(システムが安全と判断する条件下でpot-260-TReq-028 システムテスト
は、)給湯ボタンを押している間、ユーザは給湯を行うことができる。
【アクティブノイズから抽出】ユーザが解除ボタンを長押ししても、(システムは1度だけロック状態を切り替え、)システムはユーザの意図し pot-250-TRisk-026 システムテスト
ない給湯ロックの解除・ロックを防ぐことができる。
【アクティブノイズから抽出】ユーザが解除ボタンを短押ししても、(システムはロック状態を切り替えず、)システムはユーザの意図しない pot-250-TRisk-027 システムテスト
給湯ロックの解除・ロックを防ぐことができる。
ユーザがコンセントを差すと、(システムはデフォルト設定を行い、)システムは各出力I/Fでアイドル状態であることをユーザに通知する。
pot-210-TReq-001 システムテスト※蓋センサonの時、沸騰行為に遷移するのでアイドル状態の確認のため蓋はあけておく。
(蓋が開いているかつ水位が水位が異常(空)の時))、ユーザが蓋を閉めると、(システムはアイドル状態を継続し)、システムは、各出 pot-220-TReq-007 システムテスト
力I/Fでアイドル状態であることをユーザに通知することを確認する。
(蓋が開いているかつ水位が正常の時)、ユーザが蓋を閉めると3s後に、システムは各出力I/Fで沸騰状態であることをユーザに通知 pot-220-TReq-004 システムテストする。
(蓋が開いているかつ水位が異常(満水)の時)、ユーザが蓋を閉めると、(システムはアイドル状態を継続し)、システムは、各出力I/F pot-220-TReq-006 システムテスト
でアイドル状態であることをユーザに通知することを確認する。
ユーザがコンセントを抜くと、システムは各出力I/Fでシステム停止
pot-210-TReq-002 システムテスト中であることをユーザに通知する。
【アクティブノイズから抽出】ユーザがコンセントを連続で抜き差しした場合に、システムはアイドル状態とシステム停止状態を繰り返し、 pot-210-TRisk-003 システムテスト
各出力I/Fで正確にその時の状態をユーザに通知する。

要求仕様ベース
要求仕様ベース
リスクベース

リスクベース

要求仕様ベース

要求仕様ベース
要求仕様ベース
要求仕様ベース
要求仕様ベース
リスクベース

評価した優先度により構造化することで、テスト詳細設計以降の活動順序を客観的に決めることができる

テスト詳細設計~テストコンテナを活用したリプラン~~テストカバレッジ管理~

テスト詳細設計の方針 テストコンテナを活用したリプラン
課題 (はじめての共同作業が直面・・・)
テスト実行の予定開始期日までテストケース・テスト手順・データが1つも提供できず、請負先のテスト実行が開始できないことが判明→テストチームのテスト詳細設計・テスト実装と請負テスト実行を並列して進める必要がある
課題に対する施策
テストコンテナ 実行モデルにおける優先度(S,A)のテスト観点を対象にテスト詳細設計以降のプロセスを実施
施策前の見込み
テスト実行開始予定日に納入物が間に合わない

9/18
テスト実行開始予定

課題

テスト
要求分析

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

テスト詳細設計

テスト実装

テスト実行

課題に対する施策

テスト
要求分析

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

テスト詳細設計

テスト実装

優先度S,A

優先度S,A

今回のテスト詳細設計以降の納入成果物

S,A

テスト詳細設計
優先度B,C,D

テスト実装

優先度B,C,D
B,C,D

テスト実行

テスト実行

優先度S,A

優先度B,C,D

テスト実行の予定開始期日までに優先度S,Aのテストケース・テスト手順・データの納入を実現し、予定通りテスト実行開始

テスト詳細設計 テストカバレッジ管理
目的：
レビューや進捗管理の場で、ステークホルダとの合意形成と説明力向上のために、テストカバレッジ管理を簡易化する
手法：
テスト観点とテストケースを１対１に限定することでテストカバレッジ管理簡易化と説明力を向上させる

Pass

ステークホルダ（マネージャや品証）は要求に対するテスト観点がすべてOKになったか否かを確認したい

Fail

テスト観点：テストケース ＝１：１の場合

テスト観点：テストケース ＝１：多の場合
要求仕様

テスト観点

テストケースData

テストケースData

テストケース

Data

テスト観点

テストケースData

1/2 Pass

テストケースData

1/3 Pass

総合的なカバレッジ管理：複雑要求仕様カバレッジ管理：複雑テスト観点カバレッジ管理：複雑

要求仕様

テスト観点

テストケース

Pass

Data
Data

Data
テスト観点
Fail

総合的なカバレッジ管理：改善
要求仕様カバレッジ管理：複雑テスト観点カバレッジ管理：容易

テスト観点とテストケースを１対１にすることで要求に対するテスト観点のカバレッジをステークホルダが理解しやすくなる

テストケース

Data
Data

テスト実装~テスト設計技法適用した網羅的テストデータ実装~

テスト実装 テスト設計技法による網羅的テストデータ実装目的：
テストケースに対し、適切なテスト技法を使用することで網羅的なテストデータを作成する
手法：
各テストケースの入力仕様と出力仕様からテスト技法を判断し、選択したテスト技法によりテストデータを作成する
一連の流れでシステムの振舞を見たいテスト観点の場合

入力仕様の組み合わせが複数条件考えられるテスト観点の場合
テスト観点

入力仕様

出力仕様

テスト観点

解除ボタン: 解放,押下
給湯ボタン:押下…

ロックランプ :消灯,点灯
給湯口：停止,給湯

事後
状態

入力仕様

ユーザが給湯ボタンを押すと、給湯ボタンを押している間、ユーザは給湯を行うことができる。

事前状態

蓋センサoffの時、沸騰行為を止める。

沸騰行為

アイドル

蓋：閉

ユースケーステスト

ディシジョンテーブル
1
条件 止める操作

蓋を開ける
給湯ボタンを離す
空第1水位≦水位＜第2水位
第2水位≦水位＜第3水位
第3水位≦水位＜第4水位
第4水位≦水位＜満水
満水

動作 給湯を止める

YN
N
NN
NN
NX

アイドルに遷移

X

2
NY
N
NNNN
N
X

3N
N
Y
N
N
N
N
N
X
X

4N
N
N
Y
N
N
N
N

5N
N
N
N
Y
N
N
N

6N
N
N
N
N
Y
N
N

7N
N
N
N
N
N
Y
N

8N
N
N
N
N
N
N
Y
X
X

１：沸騰行為中にする
２：沸騰行為中の期待動作になっているか確認する
３：水温を測定し、100℃に達する前に蓋を開ける
５：温度制御が停止し、アイドル状態になる
６：アイドル状態の期待動作になっているか確認する
７：水温を測定し、水温が低下していることを確認し、温度制御が止まっていることを確認する

テストデータを闇雲に作成するのではなく、テスト技法により網羅的にテストデータを実装した

結論~はじめての共同作業の強み~

結論 はじめての共同作業の強み◼高品質なテスト分析・設計◼テスト目的に合致したテスト戦略策定とテスト要求分析戦略策定◼要求仕様ベースとリスクベースのテスト分析を徹底◼テスト設計技法による網羅的なテストデータ実装◼ステークホルダの意思決定への貢献◼目的やステークホルダに応じたテスト観点の構造化◼テストコンテナを活用した臨機応変なリプラン◼ステークホルダと合意形成がしやすいテストカバレッジ管理
ご清聴頂きありがとうございました。