テスト設計コンテスト　フロア展示資料

「話題沸騰ポット（ＧＯＭＡ－１０１５型）」テスト設計書～

安全なポットを使っていただくために～

【チーム紹介】

ＮＥＣのＳＷＱＣ活動のひとつに「テスト技術者交流会」があり、ＮＥＣグループ関係会社を含め約２００名のメン

バーが在籍。この交流会ではこれまで下記のような活動をしてきた。

・結合テストにおけるテスト観点のモレヌケ防止を目的にした「テスト設計テンプレート」の作成

・同テンプレートのＮＥＣグループ内への展開

・ＮＥＣグループ向けテスト技術シンポジウムの開催

「チームｎｅｍａ」はこの交流会の中で有志を募り結成。

【メンバー】

根間、小池、葛西、下前、鬼頭、岩崎、山口、春田

チームｎｅｍａ：フロア展示資料

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01 話題沸騰ポットの開発体制

話題沸騰ポットの開発とテスト設計の位置づけ

製品責任者 製品開発チーム 製品製造チーム 品質保証チーム マーケティング/販売 チーム ソフトウェア(SW) 開発チーム ハードウェア(HW) 開発チーム 品質管理チーム テストチーム テストチーム 製品責任者 製品開発チーム 製品製造チーム 品質保証チーム マーケティング/販売 チーム ソフトウェア(SW) 開発チーム ハードウェア(HW) 開発チーム 品質管理チーム テストチーム テストチーム 話題沸騰ポットの開発プロセスの想定（一部） 企画 フェーズ 要件定義 フェーズ 製品企画 製品 企画書 要求検討 要求仕様書製品 ＳＷ ＳＷ 要求仕様 要求仕様 ＳＷ 要求検討 ＨＷ 要求検討 ＨＷ 要求仕様 品質 要求分析 品質 要求仕様 事故事例 ＳＷ設計 ＨＷ設計 ＳＷ ＳＷ テスト テスト 設計 設計 エミュレータ 設計開発 ＳＷ設計書 ＨＷ設計書 _ＨＷ開発 ＨＷ ＳＷ ＳＷ テスト テスト 設計書 設計書 ＨＷ テスト設計 ＨＷテスト 設計書 ＳＷ開発 ＳＷ エミュレータ ＳＷ ＳＷ テスト テスト （１） （１） ＨＷテスト 組み込み 試作品 ＳＷ ＳＷ テスト テスト （２） （２） ＨＷテスト （利用者） 量産判定 SWテスト 結果 ＨWテスト 結果 合否判定 設計 フェーズ テスト フェーズ ソフトウェアテストに関するチームの位置づけ テスト設計チーム 要求分析 設計 製造 結合テスト システムテスト 要求分析 設計 製造 結合テスト システムテスト ソフトウエアテストを実施するのは、 製品開発チームの中の テストチームと想定 ＳＷ開発チームとテストチームの関係 今回は結合テストフェーズを想定。 設計フェーズ内での設計レビューに 用いるテスト設計と想定。 各チーム間で相互レビューを行う。

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

事故事例データの分析とメーカーの対応

事故事例の分析では、

事故の重篤性と要因分析を実施。

↓

火災ややけどなどの重篤な事故比率が高い。

↓

事故要因分析とソフトウェア対応可否を検討

A：火災発生 19% B:人的損傷 34% C:物的損害 32% D:注意喚起 11% 対象外 4% A：火災発生 B:人的損傷 C:物的損害 D:注意喚起 対象外 音割れ ラジオに雑音が入る 本体ではないものの トラブル 変質 フッ素加工の剥がれ 焦げ付き 傷がつく 変色・変形 本体に発生する トラブル 腐食 漏電 発煙 故障 発火 ショート 吹きこぼれ 危険を引き起こ す原因 感電 火災 やけど けが 直接の危険 事象 分類 音割れ ラジオに雑音が入る 本体ではないものの トラブル 変質 フッ素加工の剥がれ 焦げ付き 傷がつく 変色・変形 本体に発生する トラブル 腐食 漏電 発煙 故障 発火 ショート 吹きこぼれ 危険を引き起こ す原因 感電 火災 やけど けが 直接の危険 事象 分類 取り扱い説明書の分析から メーカーの対応を 垣間見ることができる。

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

テスト設計の標準化について

～テスト設計テンプレート～

ヌケモレ要因 対策 経験 による テスト観点の偏り 幅広いドメインの有識者や経験者を参画させる。エン タープライズ向けシステム（SI）、組み込み系システム、 OS（基本ソフト）やミドルウェアなどの汎用ソフト、業務 パッケージソフトなどの経験者を集めた。 テスト技法や 技術に関する 知識不足 技法や手法を体系化してカテゴリ化することとした。こ れにより、知識が十分でない技術者がテストを行う際 のガイドとしての役割を果たすようにしている。 記述の冗長性 冗長的な記述を回避し網羅性を高めるためには、テ スト観点のカテゴリ化を行う。また、テスト観点からテ ストケースを導出するためのヒントワードを追加し、観 点からぶれないように工夫した。 機能テスト エラー処理 Ｉ／Ｆ 計算ミス・誤差 境界値 機能テスト エラー処理 Ｉ／Ｆ 計算ミス・誤差 境界値 非機能 移植性テスト インストーラビリティテスト 障害対応テスト セキュリティテスト 信頼性テスト 性能テスト 運用テスト 操作性 非機能 移植性テスト インストーラビリティテスト 障害対応テスト セキュリティテスト 信頼性テスト 性能テスト 運用テスト 操作性

テスト設計のヌケモレ要因について

テスト設計の機能/非機能の観点

テスト設計テンプレートの構造

テスト設計テンプレートの利用の流れ

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

要求分析からテスト設計まで

（１）要求分析から機能視点とユーザー視点でのテスト設計

電気ポット ソフトウェア ハードウェア 要求 仕様書 _要求分析テスト テスト_設計 エミュレータ 機能視点 テスト ユーザー視点 テスト テスト設計テンプレート 機能テスト 競合・タイミング エラー処理 Ｉ／Ｆ 計算ミス・誤差 境界値 機能テスト 競合・タイミング エラー処理 Ｉ／Ｆ 計算ミス・誤差 境界値 非機能 機器構成テスト 保守性テスト 移植性テスト インストーラビリティテスト 障害対応テスト セキュリティテスト 信頼性テスト 性能テスト 運用テスト 操作性 非機能 機器構成テスト 保守性テスト 移植性テスト インストーラビリティテスト 障害対応テスト セキュリティテスト 信頼性テスト 性能テスト 運用テスト 操作性 フィールド品質 事故事例 データベース 事故事例分析 テスト 観点 設計フェーズ内での設計レビューに用いるテスト設計と想 定。テスト設計の結果は、各チーム間で相互レビューを行う。 電気ポットは開発中である想 定である。そのため、開発の フェーズに応じてテスト設計 が活かされるように留意する。 テスト設計のプロセスフローは仕様の要求分析をマインドマッ プで行い、テスト設計レベルまで行う。このとき、事故事例分 析結果を反映させることで、安全性を確保する。 その結果をテストのカテゴリが用意されているテンプレートに 転記する。

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

要求分析からテスト設計まで

（２）要求分析からテスト設計までのステップ

要求仕様書の項目 ブランチ（１） ↓ ふた 要求仕様書の項目 ブランチ（１） ↓ ふた 要求項目内の条件 ブランチ（３） ↓ ふた閉？ 要求項目内の条件 ブランチ（３） ↓ ふた閉？ 要求項目内の条件 ブランチ（２） ↓ アイドル？ 要求項目内の条件 ブランチ（２） ↓ アイドル？ 要求項目内の条件 ブランチ（４） ↓ 水位？ 要求項目内の条件 ブランチ（４） ↓ 水位？ 設定内容 キーワード抽出 ↓ 状態＝沸騰 条件の追加 ブランチ（３－１） ↓ 蓋センサ≧３秒 条件の追加 ブランチ（４－１） ↓ 水位＝適正 蓋に対する 要求（機能）ごとに 分 析 観点ごとに観点ごとに 分 析 ２ ＜水量適正時の処理＞pot-220-21 蓋が閉じられ、水量が適正な場合、 沸騰行為をする。 （説明）水量については、pot-280を参照 ＜蓋「閉」を確認する＞pot-220-１１ 蓋センサーが3sec以上onになったら、 蓋が閉じられたと判断する。 要求pot-220 アイドルの状態で 要求pot-220 蓋を閉じたら、 要求pot-220 水位を確認し、 要求pot-220 条件に合えば沸騰行為をする。 【沸騰行為】 関連する機能を ブランチ内に追加 【保温行為】 機 能 テ Ｉ／Ｆ 計算ミス・誤差 境界値 機 能 テ Ｉ／Ｆ 計算ミス・誤差 境界値 非 機 能 運用テスト 操作性 非 機 能 運用テスト 操作性 分 析 １ ステップ 分析手順 【分析１】 初期分析 要求仕様書から、テスト観点の対象とな るものを列挙・整理・検討・詳細化・体系 化する STEP１： 要求仕様書の項目をブランチ（１） STEP2.： 条件をブランチ（２） STEP3： 設定項目をキーワードとして抽出 STEP4： 要求の条件が詳細化されているもの をブランチ化する。 【分析２】 詳細分析 分析１で書き出したブランチの中で、明 確になっていない条件や状態、動作がな いか検討し、確認が取れた事実も随時書 き込み、実現すべき機能を明確にする 【分析３】 観点追加 分析１で機能性が認められるものはテス ト設計テンプレートの観点を対応させ、ブ ランチにする。 要求仕様書からマインドマップで要求分析をし、テスト設計までの手順 を３つのステップで定義。

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

要求分析からテスト設計まで

（３）マインドマップによるテスト設計からテンプレートへの移行

テスト設計テンプレートへの転記 テスト設計テンプレートへの転記 マインドマップによる分析 マインドマップによる分析 １ ２ ３ ４ ５ 要求仕様書からテスト設計までをさらに詳細化。 ①マインドマップの最初の条件のブランチを「機能テスト」の列に転記 ②各機能における条件、設定内容をテスト観点に記入 ③テスト観点導出に使用したキーワードを「ヒントワード」に記載 ④テスト対象により実施を○または×をつけて明確化 ⑤要件番号を付記してトレーサビリティを確保

チームnema（ID:1320008） パネル展示資料、文書番号：nema-4-01

要求分析からテスト設計まで

（４）ユーザー視点テスト

電気ポット

ソフトウェア ハードウェア 要求 仕様書 _要求分析テスト テスト_設計 エミュレータ 機能視点 テスト ユーザー視点 テスト サーミスタの水温検知が正常の場合と異常になる場合 項番 サーミスタの状況（Ｔ） 説明 結果 （Ｔ－１） ＞ 【検知した水温が過小】 既に高温になっていてもさらに沸騰 し続けるリスクが高まる 過熱 （Ｔ－２） ＜ 【検知した水温が過大】 低温にも係わらず高温と感知するた め、いつまでも保温状態のまま 湧かない （Ｔ－３） ポットに入っ ている水 （湯）の温度 ＝ サーミスタが 検知した温 度 【温度を正しく検知】 正常 水位センサーが水量を正しく検知した場合と異常になる場合 項番 水位センサーの状況（Ｗ） 説明 結果 （Ｗ－１） ＞ 【検知した水量が過小】 満水を感知できずに沸騰し、湯が噴 出すリスクがある。 あふれる 【検知した水量が過大】 ポットに入っ 水位センサ ーが検知し サーミスタの水温検知が正常の場合と異常になる場合 項番 サーミスタの状況（Ｔ） 説明 結果 （Ｔ－１） ＞ 【検知した水温が過小】 既に高温になっていてもさらに沸騰 し続けるリスクが高まる 過熱 （Ｔ－２） ＜ 【検知した水温が過大】 低温にも係わらず高温と感知するた め、いつまでも保温状態のまま 湧かない （Ｔ－３） ポットに入っ ている水 （湯）の温度 ＝ サーミスタが 検知した温 度 【温度を正しく検知】 正常 水位センサーが水量を正しく検知した場合と異常になる場合 項番 水位センサーの状況（Ｗ） 説明 結果 （Ｗ－１） ＞ 【検知した水量が過小】 満水を感知できずに沸騰し、湯が噴 出すリスクがある。 あふれる （Ｗ－２） ＜ 【検知した水量が過大】 少ない湯量を検知できないため、空 でも保温、沸騰する可能性がある。 過熱 （Ｗ－３） ポットに入っ ている水量 ＝ 水位センサ ーが検知し た水量 【水量を正しく検知】 正常 事故リスク分析結果、温度検知異常と水量検知異常の２つが重大な事故要因 ・温度検知異常につながるサーミスタ ・水量検知異常の要因になる水位センサー そのため、サーミスタの水温の検知状態でどのような結果になるか、 また水位センサーの検知状態でどのような結果になるかを整理し、 ユーザー視点テストは、安全性を確認するために行う。 実施対象は、ポットに実装されたソフトウェアであり、実施は 手作業で行う。その際、安全性を確認するための環境を作り テストを行う。