自動販売機のテスト を設計した話

2015年2月21日

チーム名：しなてす

あみー、めい、まえたさん、はるはる

1 しなてす

発表する人

テスト設計コンテスト’15 決勝戦@東洋大学

チーム紹介

• テスト設計コンテスト出場にあたり、チーム名を決めようぜ！というときに、メンバーの時間的中間点である品川でソフトウェアの品質を語っていた という背景から、 “品川”と“品質”の品をメインに省略して、 「しなてす」としました。

• メンバーはいろんな会社の４人で、WACATE２０１２夏でWACATEに 初参加したメンバーを中心に結成しています。

• 今回3回目の参加で、決勝に初参戦です！

2 しなてす

あみー めい

まえたさん

はるはる

発表の流れ

3

テスト 要求 分析

テストアーキテクチャ

設計 テスト 詳細 設計

テスト全体像、コンセプト 1

2

3

4

しなてす

何をどんな目的で

テストするのか

どのようにテスト

するのか

個々のテストを

どのようにするのか

１．テスト全体像、コンセプト

• 今回しなてすは自動販売機メーカーに依頼され、ユーザ視点でのテストを実施する・・・という設定。

• チームのコンセプト

• そのために、誰のためのテストかを強く意識した。

4

？

？

？

？ このテストは誰のため？

しなてす

皆に「喜ばれるテスト」をしたい

１．テスト全体像、コンセプト

5

• テストプロセス

テスト 要求 分析

テストアーキテクチャ

設計

テスト要求 分析書

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

テスト 詳細 設計

テスト詳細 設計書

TD01 TD02 TD03

しなてす

・ステークホルダ図 ・テスト方針 ・ステークホルダの関心事 ・テスト要求リスト

・テストケース

・テスト条件・装置対応表 ・テスト条件関係図 ・テストアーキテクチャ

テストベース 自動販売機 業界知識

顧客ヒアリング結果

２．テスト要求分析

• 目的

– テスト対象である自動販売機のテスト要求を見出すこと

6 しなてす

ステーク ホルダ分析

ステーク ホルダの

関心事整理

テスト要求 リスト

ステーク ホルダ図

ステークホルダ の関心事

テスト方針 策定

所有者の安心に 対する

テスト要求整理

テスト方針

顧客ヒアリング結果

自動販売機 業界知識

テストベース

※これ以降のプロセスでも参照されるが、簡単のために省略

インテーク テストのテスト

要求整理

何をどんな目的で

テストするのかまとめるプロセス

２．テスト要求分析

• 【ポイント1】 ステークホルダ分析

– 誰のためにどういうテストをするか？という問に対して答えを出すべく実施。ステークホルダ図で整理した。

7

自動販売機所有者

電力会社

購入者

飲料 メーカー

自動販売機メーカー

補充員 保守員

営業 (窓口)

★自販機開発者

★・・・テストを見る人

(同一の 場合も)

経営者

しなてす

良い報告をしたい

売れる自販機を作ってほしい

今回の立場： 第三者検証会社 ユーザ視点のテストを依頼されている

所有者次第

しなてす

ステーク ホルダ 分析

ステーク ホルダ図

顧客ヒアリング結果

自動販売機 業界知識

２．テスト要求分析

• 【ポイント2】 ステークホルダとコンセプトからテスト方針を策定

→ステークホルダ毎の自動販売機への要望を考慮し、テスト方針を「自動販売機所有者が安心して設置できる自動販売機であることをテストする」とした。

8

クレームや故障が少ない物がいい！

自動販売機 設置者

しなてす

ステーク ホルダ図

テスト方針 策定

テスト方針

購入者も自動販売機が 当たり前のように使えて 不満にならない

メーカーも 自動販売機が 置かれて満足

２．テスト要求分析

• 【ポイント3】 インテークテスト

– システムテストから参加するしなてすは、本格的なテストの前にスムーズにテストできるか確認することを目的に、基本動作のテストを設計した。

9 しなてす

テスト要求 リスト

テスト方針 策定

テスト方針

インテーク テストのテスト

要求整理

自動販売機設置者の 安心を保証するテスト

本格的なテストの前の 基本動作確認テスト

２．テスト要求分析

• テスト要求分析の成果物(テスト要求リスト) テスト要求とテスト条件をまとめたリスト(USDM) 要求の階層構造と要求の理由を表現しやすいため採用した。

10

テスト要求

テスト条件

※ テスト要求・・・何をどのような目的でテストするか表現したもの テスト条件・・・テストケースによりテストできるシステムのアイテムやイベント

しなてす

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

• 目的

– テスト要求をテストしやすい単位にグルーピングし、テスト実装・実行する優先度や報告のしやすさを踏まえたテストの構造を設計すること。

11 しなてす

テスト条件 のグルーピ

ング

質問事項の明示

テスト アーキテクチャ

テスト要求 リスト

テスト条件の関係検討

テスト条件 関係図

テストグルーピングの検討結果

質問事項

どのようにテストするのか

テストの全体構造を決めるプロセス

テスト条件の保守性向

上

テスト条件・ 装置対応表

テスト条件 グルーピング方針検討

重複テスト条件の排除

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

• 【ポイント1】 テストするかたまりの検討

– テストする単位のグルーピング方法(まとめ方)はいろいろ考えられる。評価ポイントを設け、今回のテストにおいて適切なまとめ方をレビューし決定した。

12 しなてす

テスト条件 のグルーピング方針検討

テストグルーピングの検討結果

テスト要求 リスト

関連作業

まとめ方 評価ポイント

テスト条件のテストタイプでまとめる

テスト要求の優先度でまとめる

・・・

テスト 実装

テストケース作成しやすさ

★★★★ ★(不考慮)

テスト 実行

テスト実行(操作、結果確認)しやすさ

★★★★ ★(不考慮)

報告 品質の報告しやすさ ★★★ ★★★★★

保守 装置変更時のテストケース保守しやすさ

★(不考慮) ★(不考慮)

検討結果 採用。ただし～

採用。ただし～

保守性向上策は別途対応する

テスト条件のまとめ方の検討結果(抜粋版)

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

• 【ポイント2】 テストの重複排除の検討

– テスト条件には類似のものがあったため、そのままではテストケースの重複が心配された。そのため、類似のテスト条件を可視化し、状況を把握できるようにした。

13 しなてす

テスト要求 リスト

テスト条件の関係検

討

テスト条件 関係図

テスト条件関連図

テスト条件Ｂ

テスト条件Ａ

テスト条件Ｂが検証のなかで、 テスト条件Ａも同時に検証でき

ることを示す。

商品切れ時に商品選択 できないこと

売切れランプが 設定どおりの明るさ で点くこと

例

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

• 【ポイント3】 テストアーキテクチャ設計

– テスト条件を、テスト条件のテストタイプとテスト要求の優先度でまとめた。 ※優先度 ＝ (テスト不足で発生しうる)不具合の影響度 × 不具合の発生頻度

14 しなてす

テスト 条件のグルーピング

テスト アーキテクチャ

テスト条件 関係図

テストグルーピングの検討結果

インテーク テスト

優先度高 優先度中 優先度低

機能テスト

障害テスト

機能テスト

障害テスト

エージング テスト

機能テスト

障害テスト

頻度低 頻度中 頻度高

1 2 3

影響度低 1 優先度1 優先度2 優先度3

影響度中 2 優先度2 優先度4 優先度6

影響度高 3 優先度3 優先度6 優先度9

優先度は高・中・低 の3段階に分類

テストアーキテクチャの概観

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

• テストアーキテクチャ設計の成果物(テストアーキテクチャ全体像)

15 しなてす

テストを始める 条件を明示

テストするかたまり

テストタイプ

次のスライドは この辺を抜粋します

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

• テストアーキテクチャ設計の成果物(テストアーキテクチャ個々抜粋)

16 しなてす

質問IDに該当する、テストベースへの質問事項が解決

されてからテストした方が よいことを表す

このテスト条件は、代替に示された テストでも検証できることを表す

(テスト条件間の関係の検討結果を 反映したもの)

テスト条件

４．テスト詳細設計

• 目的

– テスト要求リストとテストアーキテクチャに基づき、テスト条件からテストケースを作成すること。

17

テストケース

テスト要求 リスト

テスト 技法の検

討

テスト 実装

適用する テスト技法一覧

テスト アーキテクチャ

しなてす

個々のテストをどのようにするのか

考え、実装していくプロセス

４．テスト詳細設計

• 【ポイント1】 テストケースをキーワードとデータとに分けた

– 正常系のテストでは、ある操作とそれに伴う確認事項がテストケース間で繰返し出現する。一方でテストの入力値となるデータはテストケース毎に異なる。

– そこで、操作・確認事項(キーワード)とデータとに分けて、テストケースを作成しやすくした。キーワード定義をOpefy定義と名付けた。

18 しなてす

テストケース

テスト要求 リスト

テスト 実装

テスト アーキテクチャ

Opefy定義表 (操作内容と確認事項を定義)

操作 操作内容 使用する値 確認事項 確認する値

操作1 「A」をBする A 「C」がDになっていること C

テストケース (Opefyで定義した操作を選択し、具体値を当てはめる)

操作 操作内容 「A」 確認事項 「C」

操作1 「A」をBする 具体値 「C」がDになっていること 具体値

操作2 ・・・ ・・・ ・・・ ・・・

４．テスト詳細設計

• テスト詳細設計の成果物(Opefy定義表とテストケース)

19 しなてす

操作 操作内容 操作時に

使用する値 確認事項

確認時に

使用する値

入金 「金種」と「枚数」の値に従って、紙幣投入口または硬貨投入口に金を入れる

金種,枚数 ・金額表示機に「表示」に書かれている値が表示されること

・販売可能な商品ボタンが点灯していること

表示

Opefy定義表(例)

順番

操作

操作内容 金種 枚数 確認事項 表示 金種 枚数

1 入金

「金種」と「枚数」の値に従って、紙幣投入口または硬貨投入口に金を入れる

1000 1 ・金額表示機に「表示」に書かれている値が表示されること

・販売可能な商品ボタンが点灯していること

1000

2 返金

返金ボタンを押す - -

・商品の販売ボタンを消灯すること

・返金動作中、釣銭払出動作中ランプを点滅すること

・「金種」と「枚数」に書かれた値通り返金されること

・金額表示機に「表示」に書かれている値が表示されること

・入金可能な状態になること

1000 1

Opefy定義表を利用したテストケース(例)

テストケース作成時は 操作手順と使用するデータ

を考えればよい

まとめ

20 しなてす

テスト 要求 分析

テストアーキテクチャ

設計 テスト 詳細 設計

皆に喜ばれるテスト

1

2

3

4

自分たちの安心 と関係者の満足を 両立するための テスト方針設定と テスト要求抽出

無駄なテスト排除と テスト実装から報告まで のしやすさを実現する テストアーキテクチャ テストケースの

属人性排除を実現する Ｏｐｅｆｙ定義表

参考文献・参考資料

• 「改訂版 組込みソフトウェア向け開発プロセスガイド(ESPR)」, IPA/SEC, 2007

• 「SSFに基づくテスト技術スキルフレームワーク」, ASTER, iVIA, JaSST’10 Tokyo, 2010

• 「ソフトウェアテスト標準用語集(日本語版)」,ASTER, 2012

• 「テスト要求分析の概念」,鈴木三紀夫, JaSST’12 Tokyo, 2012

• 「USDMを活用した要件定義の改善(ユースケース記述からUSDMへ)」,矢野恵生、古畑慶次, SPI Japan 2010, 2010

• 「テスト設計チュートリアル」資料,ASTER, 2014

• テスト設計コンテスト2014 決勝出場チームの成果物

21 しなてす