～負けないテスト戦略～

JaSST Kansai実行委員
2010/07/23

角口勝隆
亀井浩気

y.kadoguchi@2010.07.23

はじめに ソフトウェア開発プロジェクトにおいては、品質面・納期遅延・人員不足・コスト超過などのリスクや、想定外の出来事により、失敗プロジェクトに陥ることがあります。
 いわゆるQCD(品質・コスト・納期)を計画通りに満たしたプロジェクトの成功率は、３１．１%と言われています。
(日経コンピュータ2008年12月1日号より)
 比喩的に「3K」といわれるIT業界において、どのような状況下でも最低限の成功を納めるための、「負けない為のテスト戦略」を目的として、当ミニワークショップでは、現場で必要となるスキルの一端に触れて頂くことを目的とします。
2

y.kadoguchi@2010.07.23

本日の進め方
前半・テスト戦略について
・テスト観点の大切さ
・目的の明確化
・情報の読み取り方（観点の広げ方）

後半・評価基準での優先度付けについて
・状況変化への対応について（状況判断と柔軟な対応）

3y.kadoguchi@2010.07.23

戦略と、戦術について
 戦略 →目標、目的
 方針、人・物・金の調整、政治的駆け引き等
 有利な状況を作り出すこと

 戦術 →目的を達する施策
 目的や指標を達成するためにとられる、具体的な手段や手法のこと
 与えられた状況下で、最善の手を尽くすこと

つまり、戦略(テスト計画)に検討不足や不備があれば、３Ｋの状態に陥りやすいといえる。
4

y.kadoguchi@2010.07.23

テスト戦略は、計画時に決定する
 テスト計画書には、何を書くのか？
 例
テスト計画

分析が重要！
分析漏れ・不足があると、すべての計画に影響が出る。

テスト戦略
テスト対象分析（テスト観点抽出）
要件
アーキテクチャ
テスト設計（テストケース）
スケジュール、コスト
体制、必要な能力
リスク

5y.kadoguchi@2010.07.23

テスト分析とは？
 どのような視点で、分析するのか？
要求書・仕様書類
テストスキルアプリケーションの知識
ユーザの視点エラー事例

技術的な知識分析

各種チェックリスト
品質特性

最適なツールの適用と応用方法
市場のトレンド

テスト計画・テスト観点(着眼点)・適用ツール/手法

法規・規則6

y.kadoguchi@2010.07.23

なぜ、観点を抽出するのか？
 例えば、「セブンイレブンのロゴを書いてください」と、依頼した場合、どのようになるでしょうか？
Ｓｅｖｅｎ Ｅｌｅｖｅｎ？
ＳＥＶＥＮ ＥＬＥＶＥＮ？
 ７‐ＥＬＥＶＥＮ？
 これまで、何度も目にしてきたのに、いざとなると思い出せません。

7y.kadoguchi@2010.07.23

テスト観点＝ねらいどころ 答えは、最後が「ｎ」で小文字であることに、気付いてましたか？

 観点：「大小文字の違いに注意すること」

重要：観点があれば、気付きやすい。
観点が無ければ、見えているのに、気付かない。
つまり、見逃しやすい。
8y.kadoguchi@2010.07.23

本日のお題 グループ演習で、ある製品開発プロジェクトにおけるテストチームの立場で、以下を体験しましょう。
前半 ①目的の明確化
 ②情報の読み取り方（観点の広げ方）後半 ③評価基準での優先度付けについて
 ④状況変化への対応について（状況判断と柔軟な対応）

9y.kadoguchi@2010.07.23

あなたの適正をチェック！
 手元の用紙を、縦に４つ、折り目をつけてください。
 １番下の枠に、大きく氏名を記入。
 １番上の枠に、以下の質問の答えを記入。

青・さわやか・Cool・派手ではない

あなたが好きな色を１つあげて下さい。
その色をあらわす言葉のイメージを３つあげて下さい。
例：青色「さわやか」「Cool」「派手ではない」

10

y.kadoguchi@2010.07.23

あなたの適正をチェック！
 ２番目の枠に、以下の質問の答えを記入。

あなたの好きな動物を１つあげて下さい。
その動物をあらわすイメージを３つあげて下さい。
例：ゾウ「大きい」「瞳が優しい」「動じない」

 ３番目の枠に、以下の質問の答えを記入。

通路の向こうから、誰かが歩いてきます。
その人は、何歳ぐらいの人でしょうか？
※：あまり悩まず、直感的に答えてくださいね

11y.kadoguchi@2010.07.23

それでは、グループをつくりましょう！
 座席の、前から奇数番目の方。
 後ろを向いて、偶数番目の席の方と、ペアになってください。
 テーブル単位で、グループになってください。
 自己紹介の後、先ほどの適正チェックでの共通点について、グループ内で似たような人を探してみてください。
 一番多い共通点が、グループ名になります。
例：青いゾウさんチーム
12

y.kadoguchi@2010.07.23

適正チェックの回答 （回答は、当日のみ公開）※どうしても知りたい方は、
y.kadoguchi@gmail.com までメールを。

紙は、ネームプレートとして、リユースしましょう！

13

y.kadoguchi@2010.07.23

あなたの立場 あなたは、社内の有識者を集めた検証チームに所属します。
 あなたの所属するXXXX電子では、ハードウェア（センサー）の開発力に定評はあるものの、ソフトウェア開発技術が未熟。
 ライバル企業（他グループ）との差別化を図るため、ハードウェア（センサー）を活かした機能を、ソフトウェア開発により実現したい。

XXXX電子XXXX電子├経営層├経営層├企画チーム├企画チーム├ハード開発チーム├ハード開発チーム├ソフト開発チーム├ソフト開発チーム├検証チーム：├検証チーム：
製品の出荷判定に製品の出荷判定に強い権限を持つ
強い権限を持つ（出荷停止の権限を持つ）（出荷停止の権限を持つ）

 ライバル企業に打ち勝つために、低価格・高機能・高品質の達成が必須。
 まずは、デザインレビューの前に、テスト計画を作成するところから、ストーリーは始まります。
14

y.kadoguchi@2010.07.23

開発する製品の、プロジェクト概要です。
 ある腕時計の「クリスマス限定モデル」を開発します。
 プロジェクト要件は以下のとおりです。
 開発期間は６カ月。(検証期間は２カ月)
 必要な予算は必ず出るが、追加申請はNG。

15

y.kadoguchi@2010.07.23

健康管理時計の機能
１．時計表示 現在の年月日、時分秒を表示する
２．設定

時刻や、個人情報(年齢、身長、体重)の設定が可能

３．通知

時報や、アラームを鳴らす

４．健康（次のページに、詳細を記載します）
管理機能：
16

y.kadoguchi@2010.07.23

開発する「健康管理機能」について
 健康管理機能の要件は以下の通りです。

カロリー消費計

体温計

血圧・脈拍計用途

加速度センサーで運動量を計測

体調のチェックが可 血圧と脈拍を測定
能可能

表示

毎日の消費カロリー ボタン操作で、体温 ボタン操作で、血圧を表示
を表示と脈拍を表示

通知

一日の目標クリアで、 体調不良時、アラー 基準値オーバーでム通知
ファンファーレ♪
アラーム通知細かい機能や仕様は、グループで自由に追加してください17y.kadoguchi@2010.07.23

ここまでの準備、OK？
 プロジェクト要件や、開発する機能は理解できましたか？
 それでは、デザインレビューに先立ち、テスト計画を作成します。
 まずは、テスト計画の目標、目的を検討しましょう！

y.kadoguchi@2010.07.23

本日の進め方
前半・テスト戦略について
・テスト観点の大切さ
・目的の明確化
・情報の読み取り方（観点の広げ方）

後半・評価基準での優先度付けについて
・状況変化への対応について（状況判断と柔軟な対応）

19

y.kadoguchi@2010.07.23

ワークショップ演習でのルール
 グループ内で、一人１回以上は発言すること。
 出したアイデアや発言は、批判・否定しないこと。
 奇抜なアイデアや、気付きは歓迎すること。

20

y.kadoguchi@2010.07.23

テスト戦略立案（１） 目的の明確化。

検証作業における目的
健康管理時計を実機検証し、出荷可能な品質であるか合否判定する。
＃１：説明書に記載されている機能が、正常動作すること＃２：センサーの精度や、判定条件に大きな誤差が生じないこと＃３：実用に耐えうること
＃４ …
：

21

y.kadoguchi@2010.07.23

テスト戦略立案（２）グループ演習１
・他に具体的施策が無いか、みんなで検討してください。【１０分間】

 目的を成功に導くために、具体的施策を検討。
＃目的

具体的施策（手段）１例）マニュアルに記載され 例）時計機能を、うるう秒含めてテストするている機能が正常動作す ・ること
・２例）精度や判定に大きな誤差がないこと

例）測定範囲（身長、体重）の事前明確化
・・

３例）実用に耐えうること

例）ある程度の障害に耐えうるか、耐障害テストを行う
・

似たような施策は、抽象化して分類しておいてください。
22

y.kadoguchi@2010.07.23

どんな施策がでましたか？
 どんな施策が出たでしょうか？
 次は、テスト対象物を分析する演習です。
 当ワークショップ演習での分析には、自由発想法の「ペルソナ」 と、「品質特性」を用いましょう。

テストに役立つ発想法については、JaSST’10 Tokyoのシンポジウムレポートで「レビュー眼」を探してください

23y.kadoguchi@2010.07.23

分析の視点について
 分析には、段階に応じて以下４つの視点（ビュー）があります ユーザービューを「ペルソナ法」で、仕様ビューを「品質特性」で検討してみましょう。
ユーザービュー

要求分析

適格性確認テスト

方式設計

バグビュー

仕様ビュー

結合・機能テスト

詳細設計
実装

設計・実装ビュー

単体試験（部品など）実装確認

24

y.kadoguchi@2010.07.23

ペルソナ法とは？
 仮想ユーザを定義し、それぞれの仮想ユーザの立場から、利用方法（用い方）や、利用される場面を検討する発想法のひとつ。
 目立花子 ２５才、おしゃれに気遣うＯＬ、腕時計は仕事にも使えるデザインが良い。etc…
 三洋太郎 ３４才、アウトドア大好き、エコロジーにも気遣う。

腕時計は頑丈なものが良い。etc…

 ある意味、「なりきり」での思考が大事！
25

y.kadoguchi@2010.07.23

品質特性とは？
 「品質特性」とは、品質を構成する要素（特性）。
 「ISO/IEC９１２６ 品質特性」の概要を紹介します。
機能性要求に対する仕様の正しさ、および仕様に対するプログラムの正しさ

信頼性

機能が正常に動作し続けられるかどうか

使用性

使いやすさ、わかりやすさ

効率性

目標時間内で、決められたことを実現・処理できるか

保守性

障害解析（故障時の原因のわかりやすさ）、修正、テストのしやすさ

移植性

他の環境への移しやすさ、応用性の高さ
26

y.kadoguchi@2010.07.23

機能性

品質特性での検討例「要求機能」と、「品質特性」を照らし合わせて、「ねらいどころ」を検討する
１．表示

現在の年月日、時分秒を表示する

２．調整

ボタンで、時刻の調整が可能

３．通知

時報や、アラームを鳴らす

アウトドア派の場合

信頼性目的に正確で長年の利合っている あるか？
用に耐えうか？
どこまで正 るか？
確であるべきか？
OL２５歳の場合何年先まで表示可能？

ピッタリ合うこと・オフィス内でもうるさくない・アウトドアでも音が聞こえる

カロリー計

条件通りに動作すること不明点は、デザ
インレビューなどで事前に確認／指摘する
27

y.kadoguchi@2010.07.23

グループ演習２（１５分）
 品質特性の検討と、利用者の立場での視点を活かして、実際の機能についてテスト観点（ねらいどころ）をグループで考えてみましょう！
 出てきたアイデア(テスト観点)は、紙に書き出してください。
 鋭いツッコミ満載の、面白いアイデアを、お待ちしています！
 不明点は、「仕様の不備（検討不足）」として、記録してください。

28

y.kadoguchi@2010.07.23

観点抽出演習のルール
 テスト観点は、確認すべき「ねらいどころ」。
 グループ内で、一人１つ以上は出すこと。
 出した観点は、批判・否定しないこと。
 奇抜なアイデアや、気付きは歓迎すること。
 観点は、「～であること」と、書き出すこと。
 仕様の不明点は、後で確認できるように記録すること。

それでは、よーい スタート！！
29

y.kadoguchi@2010.07.23

分析の視点について
 設計・実装ビューにもとづいて、実際の機能についてテスト観点（ねらいどころ）を検討してみましょう！
ユーザービュー

要求分析

適格性確認テスト

方式設計

バグビュー

仕様ビュー

結合・機能テスト

詳細設計
実装

設計・実装ビュー

単体試験（部品など）
実装確認

30

y.kadoguchi@2010.07.23

テストのセオリーパターンとは？
 テスト設計で、よく使われる発想観点をパターン化したもの。
正常系「願望」や「制約」など、通常利用する上での要求・要件を検討する

異常系

そうではないケース、誤操作の結果など、エラー発生時の動作を検討する。
（数値にNullなど）

境界系「不具合は境界値に潜む」という格言があるように、ゼロの値、プラスマイナス１の値での動作を検討する

限界系

どこまで耐えられるのか？どこまでの値を保証するのか？極限状態を検討する。（下限についても検討する）
初期状態から、イベント(ボタンONなど)による結果を、一連の流れで整理／検討する。

状態遷移
組合せ複数の機能や状態の組合せを検討する。（表形式にすると、組合せの漏れや検討不足を見つけやすい）31

y.kadoguchi@2010.07.23

グループ演習３（１０分）
 設計・実装ビューにもとづいて、実際の機能についてテスト観点（ねらいどころ）をグループで考えてみましょう！
 出てきたアイデア(テスト観点)は、紙に書き出してください。
 鋭いツッコミ満載の、面白いアイデアを、お待ちしています！
 不明点は、「仕様の不備（検討不足）」として、記録してください。

32

y.kadoguchi@2010.07.23

観点抽出演習ルールのおさらい テスト観点は、確認すべき「ねらいどころ」。
 グループ内で、一人１つ以上は出すこと。
 出した観点は、批判・否定しないこと。
 奇抜なアイデアや、気付きは歓迎すること。
 観点は、「～であること」と、書き出すこと。
 仕様の不明点は、後で確認できるように記録すること。

それでは、よーい スタート！！

y.kadoguchi@2010.07.23

エラー推測の解説（解説のみ）
 バグビューにもとづいて、実際にテストを進める上でのリスクや不具合を検討してみましょう。
ユーザービュー

要求分析

適格性確認テスト

方式設計

バグビュー

仕様ビュー

結合・機能テスト

詳細設計
実装

設計・実装ビュー

単体試験（部品など）
実装確認

34

y.kadoguchi@2010.07.23

エラー推測とは？
 予めリスクを検討し、そこに狙いを定めて検証を行うやり方。
 リスクとは、「不具合や危険に遭う可能性（まだ顕在化していない不確定要素）」と定義します。
 テスト計画時は、リスクや不具合発生の可能性を出すことに、専念すると良いです。（対策の検討は、後に切り分けて実施）
 リスクは、以下３つの観点で検討するとスッキリします。
 プロダクト（製品の不具合、欠陥） プロジェクト（人,部品調達,金）
 プロセス（段取り,手法・方法）
35

y.kadoguchi@2010.07.23

エラー推測の例
 「壊れた状態」や、「うまくいかないケース」について、考察した例
不具合内容 発生原因

テスト要件

うるう年で日 うるう年の判定ロジックに不 ・２０１２年２月２９日を表示可能であること
付が狂う
正・２１００年２月２９日は表示されないこと
 コツ
 「…かもしれない」と、最悪のケースや、不具合内容を想定する。
 実際に作る場面や、使う場面を想像する。
 絶対という言葉は、”絶対”にない。先入観を持たず、多角的に検討！

36

y.kadoguchi@2010.07.23

参考文献
 レビューのコツは“なんでやねん!?”～レビュー眼～ (筆者)
http://jasst.jp/archives/jasst10e.html#project3
 テスト設計のとっかかり (加藤大受著)
http://jasst.jp/archives/jasst07k/pdf/T1.pdf
 ソフトウェア品質保証入門（奈良隆正・保田勝通 著）
 日経情報ストラテジー 2006年9月号 (日経BP社)

37

y.kadoguchi@2010.07.23

休憩タイム
 前半では、機能仕様を元に多角的な分析を行い、テスト観点を洗い出しました。
 後半は、発散したテスト観点を、如何に限られた期間・コストの中で、実施するのか、演習を行います。
 休憩を入れますので、乞うご期待の上、リフレッシュください。

38