潜在不具合炙り出しテスト～テストは計画的に～中岫 信
東京エレクトロン ソフトウェア・テクノロジーズ(株)1Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

目次
• 背景
• 炙り出しプロジェクト– テスト計画– テスト設計以降• まとめ

2
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

背景

3
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

悩み

お客様に今まで以上に快適にシステムを使ってもらうためにはどうしたら良いだろうか？

4
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

提案

少なくてもシステムが止まるような重要な不具合は解消したい

今以上に運用面を考慮したテストが必要だ！！
5
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

炙り出しプロジェクトの始動

6
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

炙り出しプロジェクトとは？
• システムに潜在している運用に関わる不具合をテストによって炙り出すプロジェクトのことである。

システム

7
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

想定する大まかな作業の流れ
テスト
計画
テスト
設計

GOAL
テスト
この当りの話が実装
メイン
テスト
実行

8
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30まずはテストの計画
テスト
計画
テスト
設計

GOAL
テスト
実装
テスト
実行

9
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

状況と対策
状況

工数

拠点予測
対策

共有絞込み
10

Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

実施可能な量の予測• プロジェクトに与えられた期間で使用できる工数を算出• 与えられた期間で消化できるテストケース数を過去データより算出– 単位時間当たりのテストケース作成数– 単位時間当たりのテスト実行数などなど⇒ これらをスケジュール化
11
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

機能の絞り込み• お客様が良く使用され、かつ、運用インパクト、製品インパクトの大きい機能をピックアップ• 過去不具合データより、機能と不具合の発生頻度をマッピング※ハザードマップと呼んでます⇒これらの情報からプライオリティ付け

12
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

テストプロセス、手法の共有• 実行するテストプロセスを定義し、アウトプットのレベルを統一⇒PFDの作成• 対象の機能に対するテストの内容を合わせるためテスト方法を統一– 運用を意識したテスト– 炙り出すために対象機能をくまなくテストとは言ったものの・・・
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

13いままでだってQAでもテストは行っている

いままでと同じテストだと意味がない

運用面を考慮していないわけではない

網羅的に今までと異なる観点のテストを導く良い方法はないだろうか？

14
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

閃きスープカレー表(※)を利用できないだろうか？

※JaSST’09 Hokkaidoで紹介されたテスト手法 15
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

スープカレー表とは？
• 機能観点と顧客観点のマトリクスで、• 機能観点をご飯、顧客観点をスープに見立て、• ご飯をスープにくぐらせて食べるスープカレーのように機能観点を顧客観点にくぐらすことで、• 機能観点と顧客観点を結びつけてテスト観点を導く手法。
顧客観点

機能観点

テスト観点
16
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

初めて取り入れる手法なので本当に効果がまずは手法のあるの？
検証

スープカレー方式

いきなり本番はリスクが大やり方が良くわからない

17
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

検証
特定の機能に絞って、手法を試用使える手法なのか？
今までとは異なる観点が出てきた
使えそうな手法だ
使い方に問題はないか？
使い方はわかった
手順が人によって異なる観点の幅が人によって異なる
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

課
題
18

課題の解決へ• 導入手法の手順を整備とレクチャー– 手順書作成– 全員一度経験するまで、特定の担当者が観点出しに参加する• 観点の幅をあわせるため– 最低限考えるテスト観点を設定⇒スープカレー表をテンプレート化手法の採用、運用へ
19
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

手法を取り入れたプロセス
テスト計画書を作成する
機能仕様書
機能仕様書NGの仕分けを行う

進捗を管理する
管理マップ
管理マップ
テスト計画書
テスト計画書

テスト分析・設計をする

簡易BTS
簡易BTS

スープカレー表スープカレー表
テストケースを作成

スケジュールの調整を行う

BTSにテストNGの情報を記載

テスト観点をテストケースに落とす

一次見積もりを行う
テスト仕様書テスト仕様書

テスト結果報告書
テスト結果報告書

二次見積もりを行う
テストを実施する
一次見積もり
一次見積もり

二次見積もり
二次見積もりProcess Flow Diagram

Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

20

目的、手法をテスト方針として整理
テストレベルシステムテスト

テストタイプ

機能テスト、および、非機能テスト、エラー推測テスト

テスト目的

製品不良を引き起こさず、顧客の製品処理が続けられる。
装置を停止せずに顧客の製品処理が続けられる。
そのためのテストを実施し、問題なく装置が使える事を確認する。

テストベース

機能仕様書

テストウェア

テスト観点・概要(スープカレー表)
テスト仕様書
管理マップテスト結果報告書(顧客提出用含む)
簡易BTS

テスト手法

ブラックボックス
スープカレー表

テストリスクNGが発生した場合は、不具合かどうかの切り分けフェーズにて切り分けを行う。
不具合の内容により顧客インパクトある場合は、修正スケジュールを検討し、顧客報告する。
ただし、重大不具合が発生した場合は、都度緊急取り込みの判断をする。
21

Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

これまでの一式を整理
テスト計画
テスト方針

PFD

手法手順

管理マップ

スケジュール

BTS

22
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

計画の次はテストの設計
テスト
ポイント
計画
• 大きな機能の単位でスープカレー表を作成
テスト• 詳細機能に対して観点出しを実施
設計• 作った表は使い捨てにしないテスト• 出てきた観点の見直し
実装
テスト
実行

GOAL

23
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

設計したらテストを実装
テスト
ポイント
計画
• 作成したテストケースの量が予想以上に多い場合は、テス
テストケースの選定を行う
GOAL
設計
テスト
実装
テスト
実行

24
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

実装できたらテストを実行
ポイント
テスト
•計画
テストのNGは簡易的なBTSで管理• テストケース数とその消化率で進捗管理
テスト
設計
テスト
実装
テスト
実行

GOAL

25
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

全テストケースを消化GOAL!!
テスト
計画
テスト
設計GOAL
テスト
実装
テスト
実行

26
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

ではない
テスト
ポイント
計画
• テストのNG結果を確認し、それは不具合なのか？暗黙的なテスト仕様なのか？を仕分ける
GOAL
設計• 不具合の場合は、不具合の影響度を確認し、対応スケジュールを考える テスト
実装
テスト
実行
結果
仕分け

27
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

そして振り返りを実施
テスト
ポイント
計画
• 次の機能の検証の前に振り返りを行うことも大事
テスト
設計
テスト
実装
テスト
実行
結果
仕分け
Phase2へ

GOAL

振り返り
28

Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

まとめ

29
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

やったこと• テスト計画の実施• 新たな手法の導入

30
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

わかったこと• テスト計画で狙っていた不具合が発見できたた
め、機能や観点の絞込みの手法が正しかったと言える• 本格的に運用する前に手法を検証することで、効果と問題点の整理ができ、導入がスムーズになること• スープカレー表は網羅的にテスト観点を導くのに効果的な手法であること

31
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

つぎにやること• システムテストを考える上で、誰が、いつ、どのように、その機能を使うのかをもっと具体的に考えること• 今回の炙り出しで得たことを開発プロセスの上流工程に取り入れること

32
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

ご清聴ありがとうございました

33
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

34
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

Appendix

35
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

ハザードマップ

大分
類

中分
類

小分
類

A
顧客
影響が
大

製品不良、システム停止（搬送、画面）等、生産に影響を及ぼす重大なもの
0：影響なし1：影響あり3：かなり影響あり

過去トラ（社外）や社内不具合の多いもの
0：過去3年間累積 ～x件1：過去3年間累積 x～x件
3：過去3年間累積 x件以上

過去トラ（社外）や社内不具合の多いもの
0：直近1年のB1ランク以上はx件
1：直近1年のB1ランクがx件
3：直近1年のB1ランクがx件以上

B
欠
陥が多
い

C
欠
陥が多
い

累積

直近

D
性能に
影
響
有E
機能が複
雑

F
テス
トが大変

G
経験
者の意
見

開発者、関係者の過去の経
験上、左記含めてリスクがあると思うもの
0：ほとんどない
1：ある
3：かなりある

計変更時のテストが、環境、パターン等により大変なもの
0：それほどでもない
1：そこそこ大変
3：かなり大変

機能の相関関係を示す
0：単体機能で構成
1：2つまでの機能で構成
3：使用環境下で動的に変化する機能安全性、信頼性、パフォーマンスに関係するもの
0：影響なし1：影響あり3：かなり影響あり

36
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

テスト対象とした品質特性
品質特性

副特性

品質特性

合目的性
正確性
機能性

時間効率性
効率性

相互運用性

解析性

機能性標準適合性

変更性

成熟性
信頼性

保守性

安定性

回復性

試験性

信頼性標準適合性

保守性標準適合性

理解性

環境適応性

習得性
使用性

資源効率性
効率性標準適合性

セキュリティ

障害許容性

副特性

運用性
魅力性
使用性標準適合性

設置性
移植性

共存性
置換性
移植性標準適合性

Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

37

スープカレー表
概要• 縦軸に「機能観点」、横軸に「顧客観点」• 機能観点
どんな機能を使うのか(機能要求)• 顧客観点– その機能はどのような目的で存在しているか？(目的機能)– その機能が特定の利用状況で顧客満足を満たせるか？(想定ユーザ)– その機能がどのように動作するか？（非機能要件）

38
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

スープカレー表イメージ機能

目的

想定ユーザ

非機能観点

39
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

今回のスープカレー表
テンプレート
縦軸• 機能
横軸• 機能の目的• 想定ユーザ装置を使用するユーザはある程度決まっているため、ここは省略• 非機能観点
ベースの観点として品質特性とエラー推測を利用• 仕様の不明点
仕様に対する不明点、疑問点、などのメモ
40
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

採用したスープカレー表テンプレート
機能観点

顧客観点

機能

機能目的

非機能エラー推測

信頼性

階層
1

階
層
2

具体例

階層
3

成
熟性

障害
許容性

効率性

回復性

時
間効率性

資源
効率性

排除繰
り返し

例
外

境
目

順
序
入替

同時

代替
手段

異常手順

仕様の不明
点

観点出しのベースとなるテストのカテゴリ
テストのカテゴリに対する例
汎用的な言葉で整理
41
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30

テストケースの選定基準•以下の視点で5段階でポイントを割り振り、ポイントの低いものを間引く
a. 手順がお客様の運用上、実施可能かどうかを考える
b. テストケースで期待する結果が出なかった場合に発生する事象のシステムへどれぐらい影響を与える度合
c. 機能毎の過去に発生した不具合のランク割合をもとに、ハインリッヒの法則当てはめて、潜在するかどうかを考える
d. テストケースがどのテストレベルを確認•

ポイントをつけた後は機械的に間引くが、間引いたテス
トケースの中に必要なテストケースまで間引いていないか再度確認する

42
Makoto Nakakuki / Tokyo Electron Software Technologies Limited / EDS SQA / Rev.2.00 / 2010/08/30