話題沸騰ポット（GOMA=1015型）
テスト設計コンテスト U-30
テスト設計報告
パナソニックITS株式会社 あんだーズ♪
2018年2月24日 原山 譲

1

あんだーズ♪紹介
テスト設計チーム「わんだーズ♪」のあんだー30なメンバです♪

普段の業務：車載器のテスト（機能リーダ）
挑戦したいこと：①テスト設計の一連の流れを経験すること（チーム方針）わんだーズ♪は８人メンバーで、テスト設計を分担して行っておりました②２年間勉強してきたテスト技術を発揮すること
普段の業務で品質保証の考え方を学習
JaSST、WACATEなどに参加し、品質を学習
JSTQB FL/ALを受験し、テスト技術を学習
2

テスト計画（テスト方針→テスト目的）
D1あんだーズ♪のテスト計画

D0.2
ASTERからのOEM開発の依頼背景P1.1
依頼背景からあんだーず♪の方針を検討するD1.1
あんだーズ♪のテスト方
針

P1.2
テストベースからテストスコープを定義する

D1.2
あんだーズ♪のスコープ
定義

P1.3
テストベースからテスト目的を導出する

D1.2
あんだーズ♪のテスト目
的D0.1ASTERテストベース
D0.1.1「話題沸騰ポット要求仕様書 (GOMA‐1015型) 第７版」
D0.1.2「ASTER U30 テスト設計コンテスト テストプロジェクト
要求補足書」

D0.4
ステークホルダーからの情報（テスコン実行委員/審査員）

3

ソフトウェアの品質保証の考え方（方針①）• ソフトウェアの品質を確保するために、一般的にソフトウェアが持ちうる品質とテストの関係を考える
ソフトウェアが持ちうる品質【品質保証のステップ】

想定されていない品質＝テスト不可能な範囲①ソフトウェアが満たすべき品質を想定する
ここで想定されていない品質についてはテストすることができず、テストの網羅性対象外となってしまう。
ステークホルダーにヒアリングすることや様々な情報を参照することで多くの品質を想定できるようにする。

想定している
品質＝テスト可能な範囲

テストしない範囲①想定できたソフトウェア品質②ソフトウェアに求める品質

100％
テストする範囲

テスト網羅率③実際に設計したテスト
ケース0％②テストする範囲を決定する①の想定している品質の中で、製品の使用シーン・方法によっては、考慮不要な品質も存在する。ソフトウェアに求める品質を決定することで必要なテストする範囲（テスト網羅率100％ ）を決定する。ここでテストする範囲は、ソフトウェアに潜む品質リスクを求められるレベルまで軽減できること（テストのゴール）とする。
③テストする範囲に対する必要な網羅率を計測する
テスト網羅率は、必要なテストケース数に対する実際に作成したテストケースの割合とする。
4

ソフトウェアの品質保証の考え方（方針②）• 欠陥の偏在

事前にテスト設計したテスト

探索的テスト

テスト対象

原則 4：欠陥の偏在（ソフトウェアテスト標準用語集 （日本語版））
ソフトウェアが持ちうる品質
テストは、モジュールごとの欠陥密度の予測や直近の観察結果に比例してテストの焦点を絞ら想定されてテストし ①想定できたなければならない。リリース前のテストで見ついない品質
ない範囲 ソフトウェア品質
かる欠陥や運用時の故障の大部分は、ある特定＝テストの少数モジュールに集中する。
不可能な範囲想定している
品質＝テスト可能な範囲②ソフトウェアに求める品質テストする範囲

100％
テスト
網羅率

偏在した欠陥に集中②テストする範囲を決定する～テストする範囲（テスト網羅率100％ ）を決定する。
ここでテストする範囲は、ソフトウェアに潜む品質リスクを求められるレベルまで軽減できること（テストのゴール）とする。
欠陥はある特定のモジュールに集中することから実施済みのテストから得られた欠陥情報から、より品質リスクを軽減できるように動的に実施するテストの変更を行う

0％5

2017年度（前回）のプロジェクト組織体制
株式会社◯◯◯
温度制御

A
ST
E
R

システム開発システム全体（温度制御以外）

開発部門（結合テストまで）

テストケース仕様
テスト手順サンプル

テストベース

温度制御専門チーム
話題沸騰ポットシステム
テスト（ホワイトボックス、PID制御）

テスト
設計チーム

テスト手順書

テスト対象の責務分担

6

2018年度のプロジェクト体制とスコープ定義
プロジェクト制約のため、手動のみのテストとする

パナソニックITS株式会社
ハードウェア

AST
E
R

システム開発（結合テストまで）

テストベース

話題沸騰ポット

ソフトウェアあいであズ★
テストケース仕様
テスト手順サンプル

わんだーズ♪

システムテストハードウェアテストチーム

あんだーズ♪

テスト手順書わんだーズ♪にはハードウェアメンバもいるよ

テスト対象の責務分担

7

プロジェクト要求からテスト目的の導出• テストベースとソフトウェアのふるまいの合致性を検証する• 人体への危害のリス
クが想定用途の範囲内で許容できる水準であること• 改善のフィードバッ
ク
曖昧さ

記述不足

エラー

矛盾
改善提案
テストベースに対する徹底的なテスト（仕様書網羅率100％）

リスク分析をもとにした
品質リスク軽減仕様QA／他メーカー取扱説
明書をもとにした仕様書改善

基本テスト方針は上記とする。でも、それで売れるの？過去不具合は？
8

ビジネスステークホルダ（ASTER）へのヒアリング- 温度制御は対象外
話題沸騰ポット（GOMA=1015型）【ヒアリング結果】

2018 U-30テストベース

2017 U-30テストベース
テスト対象
テスト対象外(考慮は必要)

1 ハードウェア構成とハードウェア要求仕様- 温度制御は対象

テスト対象

話題沸騰ポット（GOMA=1015型）

テスト対象外(考慮は必要)★変更箇所

2 操作要求仕様

1 ハードウェア構成とハードウェア要求仕様

2 操作要求仕様

3 温度制御行為★変更箇所

3 温度制御行為

4 温度制御方式★変更箇所

4 温度制御方式

5 エラー検知

5 エラー検知

6 状態遷移6 状態遷移7 イベント

7 イベント• 温度制御機能に不具合報告があったわけではない（暗黙のプロジェクト背景があるわけではない）（Y氏）• 温度制御機能が対象じゃな
いと面白くないよね（Y氏）• 温度制御機能が対象じゃな
いとソフトウエアのテストではなく、ハードウェア主体のテストになっちゃう（S氏）
温度制御機能はASTERの注目機能であり、特に品質を確保する必要がある
9

テスト対象商品の背景から想定購入者を確認• 屋台• イベントブース

店主が使用• 小規模な飲食店• コンビニエンスストア• イートインコーナー

店主が使用

一般の顧客が使用

10

テスト目的に表れない気にすべき点の導出
売れるようにするためには、何が必要？
それぞれの想定オーナーが求める品質を確認
想定オーナー

当たり前品質 一元的品質 魅力的品質

屋台オーナー【店主が利用】

・沸騰時に蒸気を噴出しないこと
・沸騰到達時間が短い
・高温モードで98℃で保温されること ・消費電力が少ない
・節約モードで90℃で保温されること ・保温性能が高いこと
・蓋を開けているときに沸騰しないこと ・利用可能期間が長いこと
・空焚きしないこと
・エラー検出できること
・ポット洗浄剤が使用できること・沸騰時に蒸気を噴出しないこと
・沸騰到達時間が短い
・高温モードで98℃で保温されること ・消費電力が少ない
・節約モードで90℃で保温されること ・保温性能が高いこと
・蓋を開けているときに沸騰しないこと ・利用可能期間が長いこと
・空焚きしないこと
・エラー検出できること
・ポット洗浄剤が使用できること・沸騰時に蒸気を噴出しないこと
・沸騰到達時間が短い
・高温モードで98℃で保温されること ・消費電力が少ない
・節約モードで90℃で保温されること ・保温性能が高いこと
・蓋を開けているときに沸騰しないこと ・利用可能期間が長いこと
・空焚きしないこと
・エラー検出できること
・ポット洗浄剤が使用できること・沸騰時に蒸気を噴出しないこと
・沸騰到達時間が短い
・高温モードで98℃で保温されること ・消費電力が少ない
・節約モードで90℃で保温されること ・保温性能が高いこと
・蓋を開けているときに沸騰しないこと ・利用可能期間が長いこと
・空焚きしないこと
・エラー検出できること
・ポット洗浄剤が使用できること
・ミルクモードで60℃で保温されること
・ロック／ロック解除が動作すること・沸騰時に蒸気を噴出しないこと
・沸騰到達時間が短い
・高温モードで98℃で保温されること ・消費電力が少ない
・節約モードで90℃で保温されること ・保温性能が高いこと
・蓋を開けているときに沸騰しないこと ・利用可能期間が長いこと
・空焚きしないこと
・エラー検出できること
・ポット洗浄剤が使用できること
・ミルクモードで60℃で保温されること
・ロック／ロック解除が動作することイベントブースオーナー【店主が利用】

小規模店舗オーナー【店主が利用】
コンビニオーナー【一般の顧客が利用】

イートインコーナーオーナー（商業施設オーナー）【一般人が利用】・転倒時にお湯が溢れないこと・空になるまで給湯できること

・転倒時にお湯が溢れないこと・空になるまで給湯できること

・転倒時にお湯が溢れないこと・空になるまで給湯できること【求められる品質】---安全--• 沸騰時に蒸気を噴出しないこと• 転倒時にお湯が溢れないこと---安全以外---

・自動ロックすること・転倒時にお湯が溢れないこと

・自動ロックすること・転倒時にお湯が溢れないこと• ポット洗浄剤が使用できること• 沸騰到達時間が短い• 消費電力が少ない• 保温性能が高いこと

赤字の箇所は仕様書に記載されていないが、求められる品質• 利用可能期間が長いこと
当たり前品質：満たされなければ購入されない →優先度大
一元的品質 ：満たすほど、購入につながる →優先度中・小 • 空になるまで給湯できること
魅力的品質 ：満たすほど、購入につながる →優先度中11

あんだーズ♪のテスト目的• テストベースとソフトウェアのふるまいの合致性を検証する• 人体への危害のリス
クが想定用途の範囲内で許容できる水準であること• 改善のフィードバッ
ク
曖昧さ

記述不足エラー

矛盾
改善提案
テストベースに対する徹底的なテスト（仕様書網羅率100％）

リスク分析をもとにした品質リスク軽減

温度のソフトウェア制御に着目し、特に品質リスク軽減を目的とする仕様QA／他メーカー取扱説
明書をもとにした仕様書改善

暗黙の品質要求に着目し、仕様書の改善提案を図る
12

テスト要求分析
何が人体への危害に繋がるかなど、ドメイン知識を収集・分析
三色ボールペンを用いた仕様の読み込み→改善のフィードバック

D0.1.1「話題沸騰ポット要求仕様書 (GOMA‐1015型) 第７版」

P2.1
三角ボールペン法を用いて要求仕様書を読み込む

D2.1
すごく重要文、まぁ重要文、気になる文が線引きされた要求仕様書

P2.7
あんだーず♪のテスト計画を踏まえて温度制御の合致性を検証する方法を検討
する

D2.9
温度制御の合致性の検証検討

D1
あんだーズ♪のテスト
計画
D0.3
テストや電気ポットに関する情報D0.3.1
電気ポットのリコール情報

様々な資料を元にドメ
イン知識の収集を行う→改善のフィードバック

D0.3.2
電気ポットの電気機械器
具品質表示規程

D0.3.3
国民生活センターの電気ジャーポットの安全D0.3.4
TIGER(PIG-S型)の取扱説
明書
P2.5
あんだーズ♪のテスト計画を踏まえて、市場シェアを調査し、参照する取扱説明書を決定する

P2.14
あんだーズ♪のテスト計画を踏まえて、リスク分析を行う

D0.3.5象印(CV-DM)の取扱説明書

D2.10
品質リスクレベル定義表

P2.2
あんだーズ♪のテスト計画を踏まえて、リコール情報から気にすべきことの抽出する

P2.8
仕様不明点の聞き込みを行う

P2.13
温度制御の合致性の検証検討か
らテスト観点一
覧へ反映する

D2.3
QA管理表

P2.9
QA回答を元に仕様書を補完する

D0.12
つながる世界のソフトウェ
ア品質ガイドP2.10
品質ガイドをもとにテストすべきことの思考を発散させる

P2.6
あんだーズ♪のテスト計画を踏まえて、シェア上位2社の取扱説明書から気にすべきこと抽出す
る

D2.5
品質ガイドベースのマインドマップ

P2.11
マインドマップから気にすべきことをテスト観点一覧へ反映する

P2.3
あんだーズ♪のテスト計画を踏まえて、品質表示規定から気にすべきことを抽出する

P2.4
あんだーズ♪のテスト計画を踏まえて、国民生活センター報告書から気にすべきことを抽出す
る

D2.4
社内仕様書

P2.12
マインドマップから因子水準一覧
表を作成するD2.6
テスト観点一覧

P2.13
社内仕様書より機能分類表を作成する

D2.8
機能分類表

品質特性に着目した社内仕様とテスト観点の整理と紐付け→ふるまいの合致性の検証

D2.7
因子水準一覧

D2.2
取扱説明書に記載されるような、仕様規定されるべき要求

リスク分析をもとにした
品質リスクの識別→品質リスク軽減13

テスト要求分析（改善のフィードバック）
要求仕様書の理解を深める• 三色ボールペン技法による仕様書の読み込み
赤：（客観最重要）…客観的に見て「すごく大事」と思ったところに引く。
青：（客観重要）…「まあ大事」というところに引く。
緑：（主観大切）…自分が勝手に「おもしろい」と感じたところに引く。

不明点はQAで明確化

14

テスト要求分析（改善のフィードバック）
様々な情報を調査し、必要な観点の洗い出しを行う

リコール情報国民生活センターの資料

テスト観点

品質表示規定シェア上位２社の取扱説明書
15

テスト要求分析（ふるまいの合致性）
品質ガイドを用いたマインドマップ作成による漏れの軽減

品質ガイド

16

テスト要求分析（リスク分析）
発生頻度と被害の大きさからリスクレベルを決定する
①発生頻度
レベル
基準例
3：高-日常的に発生
１月に１回以上発生
2：中-まれに発生
１年に1回以上発生
1：低-極めてまれに発生 数年に1回発生②被害の大きさ（影響度）
レベル
定量的基準値
3：高-重大な影響
１億円以上
2：中-中程度の影響
100万円以上～1億円未満
1：低-軽微な影響
100万円未満

定性的基準値（人命）定性的基準例（範囲）
死亡者が発生全社に及ぶ被害が発生
入院が必要な被害者が発生
１事業に及ぶ被害が発生
応急処置のみで対応可能な被害者のみ １部門に及ぶ被害が発生

リスクレベルを設定する
リスク管理ID 危害
RSK-001空焚きによる発煙・発火の発生
RSK-002ロック機能動作しないことによる火傷
RSK-003満水状態における吹きこぼれによる火傷

発生頻度 被害の大きさ リスクレベル
23622422417

テストアーキテクチャ設計• テストタイプを定義し、テストアーキテクチャ設計書を作成
P3.2
テスト計画とテストタイプからテストアーキテ
クチャを検討する

D1
あんだーズ♪のテスト計画

D2.6
テスト観点一覧

P3.1
要求分析結果からテストタイ
プを検討するD3.1
テストアーキテ
クチャ設計書

D3.2
テストタイプ定義

D2.4
社内仕様書
18

テストアーキテクチャ設計の検討
・品質特性に合わせてテスト観点としてまとめている
・普段の業務でも使用しているテストタイ
プ型を使用している→品質特性毎に保証するテストタイプを決定し、テストタイプ型を選択

19

テストアーキテクチャ設計• 品質リスクの高い（人体への危害の可能性がある）テストタイプから優先実施し、リスクの低いテストタイプを後に実施
システムテスト
テストサイクル①

保証型テスト

信頼性テスト

機能性テスト

リスクレベル大きい

検出型テスト
互換性テスト

状態遷移

探索的テストテストサイクル②
信頼性テスト
リスクレベル小さ
い

状態遷移以外
性能効率性テスト
リスクレベル小さ
いカテゴリ
テストサイクル①
保証型テスト

検出型テストテストサイクル②

使用性テスト
リスクレベル大きい

カテゴリの目的
早期の品質リスクの軽減（人体への危害のリスクが想定用途の範囲内で許容できること）
テストベースとソフトウェアのふるまいの合致性の確認
想定ユーザーに対して性能が保証されていることの確認
テストサイクル①と保証型テストの不具合状況をチャータとしたピンポイントの不具合検出
デグレによって、品質リスクが増加していないことの確認

20

テスト詳細設計• テストアーキテクチャ設計書と因子水準一覧からテストケースの作成
下流工程でもリスクレベルを表現することで、品質リスクの高い順での評価実施を可能とする
D3.1
テストアーキテクチャ設計書

D2.6
テスト観点一覧

P4.1
アーキテクチャ設計書をもとに、テストケースの雛形を検討する
P4.2
社内仕様書に対してテスト観点一覧のマッピングを行う

D4.1
テストケース雛形

D4.2
社内仕様書➖テスト観点一
覧トレース表D2.4
社内仕様書

リスクレベルを表現

D2.7
因子水準一覧
D2.8
機能分類表

D2.9
温度制御の合致性の検証検討
D2.10
品質リスクレベル定義表

P4.3
テスト観点一覧と因子水準表を元にテストケースを作成する

D4.3
テストケース21

探索的テストの実施方針（１）■事前準備① テスト対象であるポットシステムの機能分割を行う
表１.機能分類表を作成する② 設計済みのテストを実行し、実施データをまとめる
不具合の発生に対して、以下の内容を集計する• 不具合内容• リスクレベル• 発生した機能分類１, ２• 操作内容（連打やタイミングなども含む）

表１.機能分類表

機能分類1 機能分類2機能１
機能２・・・

機能１-１
機能１-２
機能２-１
機能２-２・・・
22

探索的テストの実施方針（２）■探索的テスト実施① [設計]事前準備②、および探索的テスト実施③をインプットにリスクレベルの高い不具合が頻出している機能分類をチャータとして設定する② [実施]チャータを元にテスト実行を行う③ [報告]テスト実施結果を報告する（事前準備②の内容）
テスト実施結果とテスト目的を比較し、テストの十分性を評価する。
①～③を繰り返し、テストの十分性を満たすまで実施する※不具合が頻出しすぎる機能に対しては、根本的な対策が必要であることを報告する
23

おわりに
• ソフトウェアの品質を確保するために、一般的にソフトウェアが持ちうる品質とテストの関係を考える
ソフトウェアが持ちうる品質【品質保証のステップ】＝テスト不可能な範囲①ソフトウェアが満たすべき品質を想定する
ここで想定されていない品質についてはテストすることができず、テストの網羅性対象外となってしまう。
ステークホルダーにヒアリングすることや様々な情報を参照することで多くの品質を想定できるようにする。

徹底的なドメイン分析
想定されてテストし ①想定できたにより実現いない品質ない範囲 ソフトウェア品質
想定している
品質＝テスト可能な範囲②ソフトウェアに求める品質

100％
テストする範囲

探索的テストによりピ③実際に設計したンポイントでの網羅性テスト
ケースも確保テスト
網羅率0％②テストする範囲を決定する①の想定している品質の中で、製品の使用シーン・方法によっては、考慮不要な品質も存在する。ソフト
ウェアに求める品質を決定することで必要なテストする範囲（テスト網羅率100％ ）を決定する。ここでテストする範囲は、ソフトウェアに潜む品質リスクを求められるレベルまで軽減できること（テストのゴール）とする。
③テストする範囲に対する必要な網羅率を計測する
テスト網羅率は、必要なテストケース数に対する実際に作成したテストケースの割合とする。
24