JaSST ‘10 Kansai

ミニワークショップ後編～負けないテスト戦略～

資料作成：亀井浩気
２０１０／０７／２３

ワークショップ後半の目的

期間・コストが限られている中で、商品としての価値および製品品質を確保するための「負けないテスト戦略」を掘り下げる。

目次①テスト項目の優先順位付け②状況把握とテスト戦略の見直し③まとめ

3

たくさんテストケースがある中での気付き• 「何からする？」「どれからやればいいの？」→テストスキルが高いテスト担当者は、テストの実施順番が重要である事を意識している。
• 「このテスト項目は必要なの？」→テストスキルが高いテスト担当者は、テスト項目に重要なものとそうでないものがある事を意識している。

4

つまり…
• 現状のテスト項目は優先順位付けされていない。

3476

14512736

品質リスク(値が大きさを表す)• 品質リスクの大きなテスト項目から実施することにより、効率的にテストを進められる。
不具合による工程へのダメージをコントロールできる。
実施順番
7766544332

1

リリース基準15

品質と品質リスク、テストの関係ユーザーの製品品質に対する認識領域←品質リスク

テスト領域※今回のワークショップ前半で抽出したテスト観点から作成する。

6

十分なテストユーザーの製品品質に対する認識領域を全てテストした。

テスト領域

⊃
ユーザーの製品品質に対する認識領域7

不完全なテスト
ユーザーの認識する製品品質領域を全てテストできていない。

ユーザーの製品品質に対する認識領域

⊄

テスト領域

8

リスクベースドテスト
ユーザーの認識する製品品質領域を全てはテストできていないが、重要な部分はテストした。

ユーザーの製品品質に対する認識領域

⊃

テスト領域

9

どこに、重点を絞るべきか？

• 状況に応じて、的を絞るには、「状況判断力」が必要。
– 判断力＝決断力。
– 決断するためには、状況判断のための材料（つまり評価基準）が必要である。

10

優先順位を決める方法の満たすべき条件• 「定量的」な基準を用いた方法であること• 「広い視野に立った」方法であること

11

定量的とは…
• 定量的とは、対象の量的な側面に着目することであり、再現性があり、理論的に説明する事が出来る。
• リスクベースドテストにするか、魅力的品質を突き詰める事にするか、どのような観点でテスト項目の優先度を決めるにしても、関係者の意識あわせをするためには定量的な値であるべき。
• 定性的であると、直感や個人的印象によるため、信頼性や客観性に乏しいと判断されることが多い。
12広い視野に立つとは…
• 例えば、誰が重要なテスト項目と判断するか？

• ユーザー：顧客の要求は絶対。
→利用者の要求分析から、機能に対する優先度を把握。

• プロジェクト：作るからには、魅力ある製品を作りたい。
→この製品のアピールポイントはここだ！

• 開発者：設計・実装上、心配な部分が出てくる。。。
→この部分は、バグの影響が大きいかも・・・→この部分は、複雑だしバグがあるかも・・・• プロダクト：商品の性質上、この部分は重要→ユーザに危害を加える可能性あり。

13

今回のワークショップでは“評価軸“に注目
今回のワークショップでは、標準的な方法として、リスクベースドテストで使用される、 評価軸を取り上げていきたいと思います。

次に示すのは、Rick D.Craigらの著書「体系的ソフトウェアテスト入門」に記載されているリスク分析を流用した方法です。

14

Rick D.Craigらによる評価軸
ソフトウェアのリスク分析プロセスの概要①

BSチームを結成する⑤ 数値を割り当てる⑨ 「足切り線」
を設定する②

機能の一覧を作成する⑥

リスク度を算出する軽減策を検⑩ 討する③

障害の可能性を判定

値をレビュー⑦ ／修正する④ 障害の影響を判定

機能に優先⑧ 度を付ける

15

Rick D.Craigらによる評価軸
ソフトウェアのリスク分析プロセスの概要①

BSチームを結成する

ワークショップ
前半の内容
テスト観点の②一覧を作成する③⑤ 数値を割り当てる⑨ 「足切り線」
を設定する⑥

リスク度を算出する軽減策を検⑩ 討する

値をレビュー
障害の可能
ワークショップ⑦ ／修正する
性を判定

後半の内容
⑧

④ 障害の影響を判定

テスト観点に優先度を付ける

16

Rick D.Craigらによる評価軸
ソフトウェアのリスク分析プロセスの概要：
テスト観点を「障害の可能性」と「障害の影響」の2つの評価軸で点数付けを行い、この点数よりリスク度を算出し、テスト優先度を決定する。

障害の可能性障害の影響高い場合

３３中程度の場合

２２低い場合１１

リスク度 = (障害の可能性) ＋ (障害の影響)
17

演習１（１０分）

提示した評価軸を用いて、テスト項目の優先順位を決めてください。
演習内容
・テスト観点表（ワークシート２）を元に、提示した評価軸（障害の可能性、障害障害の影響）で評価し、テスト項目の優先順位を検討してください。
・ペルソナで検討した仮想ユーザの立場でも考えてください。
・テストを実施せずに、リリースした場合の、影響（障害可能性、影響）を検討してください。

解答欄
テスト観点 障害の可能性

障害の影響 リスク度 優先順位

※リスク度 = (障害の可能性) ＋ (障害の影響)
19

優先順位の確認• 予想通りの優先順位となっていますか？
• これでテスト計画ができました。

20

目次

①テスト項目の優先順位付け②状況把握とテスト戦略の見直し
③まとめ

21

テストを進めるうちに・・・
テスト設計で、• 「テスト項目、たくさん出しました。」• 「あれもこれもテストしたいですね～」• 「開発側、ここまで考えてるかな？」• 実際にはハードウェアやドライバ周りなどの開発の遅れがあったりしますよね• このような場合においては、プロジェクトの進行が滞らないように戦略の見直しが必要となります• 今回は、さらに別の状況を考えてみましょう22ワークショップでの制約• 腕時計開発プロジェクトにおいて、経営層から次のような要望があった。
• 「２週間後の展示会に出して、マーケティングを有利に進めたい。」• 動くものを出さなければならない！
検証開始後２週間で展示会へ出す

23

要望の分析
• 開発状況を把握すると、一部ハード/ソフトウェアについて、残り2週間では、完全な動作が難しいと判明した。
• 「マーケティングを有利にする機能を優先。」とのこと。
• 限定される機能があって良いのか、経営層の承認が必要• この展示会バージョンのために追加予算はないため、途中リリースとして、「機能限定展示会バージョン」をテストすることになった→テストを後回しにできる項目が生じる。
→よって、テストの優先順位を変える（＝戦略を見直す）

24

品質とテストの関係で表現すると・・・
テスト領域を、減らさざるを得ない顧客の製品品質に対する認識領域
テスト領域
マーケット性の高い機能が重要と判断されている

25

品質とテストの関係(理想の対応)
重要部分にポイントを絞る！

顧客の製品品質に対する認識領域

テスト領域
ユーザーが特に重要部分は重点的に！
魅力的だとする領域

26

評価軸

障害の大きさや影響範囲から評価した、先ほどの評価軸では、経営層の要求を満たせない。
→テスト観点の再評価が必要！

→優先度を、再検討しましょう。

27

リスク分析の前提条件

一般消費者が利用する上で、何に障害があるとリスクが高いと言えるでしょうか？

展示会において、何に障害があるとリスクが高いと言えるでしょうか？

28一般消費者と展示会の状況の違い• 展示会では、専門のオペレータが全てを操作する– つまり、操作の指定や教育が可能• 展示会では、動作する時間が限られている– つまり、日付をまたいだり、長時間の稼動は不要

29

演習２（１０分）

機能限定展示会バージョンを前提として、テスト観点の優先順位を再度決定する。
演習内容・リスクを再評価して、テスト項目の優先順位を決定する。

30

解答欄
テスト観点 障害の可能性

障害の影響 リスク度 優先順位

※リスク度 = (障害の可能性) ＋ (障害の影響)
31

優先順位の確認• 予想通りの優先順位となっていますか？
• 経営層が、客観的な判断を下すことが可能でしょうか？

32

目次

①テスト項目の優先順位付け②状況把握とテスト戦略の見直し
③まとめ

33

ワークショップ後半の流れ① テスト観点の抽出
経営層から要望「2週間後にとりあえず動くもの」②

テスト観点の優先順位の決定③ 新たな評価軸での見直し

制約
経営層から要望「より早い納品と、マーケティングに有利な機能の完成は必須」④ テスト観点の優先順位の再決定
34

制約への対処方法• 制約は大きく２つに分類される– 事前に対策可能な制約

可能な限り、事前に抽出し、対策を行っておく。
– 随時対策が必要な制約

ノウハウを溜めておき、制約が発生した際に、柔軟に対応する。
35

ミニワークショップのまとめー１• 製品開発では様々な制約がある。その中で、商品的価値を確保するためには、優先順位の高いテスト項目から実施する必要がある。
• 今回のワークショップでは、評価軸を用いて、状況に応じたテストの順番を変える方法を体験した。
• テストに対する制約は多々あり、これらに対して柔軟に対応できてこそ、”負けないテスト戦略”である。

36

ミニワークショップのまとめー２• 昔から「段取り８分、実行２分」といわれるように、事前に必要な事項を検討することは、重要です。
• テストの観点(テストの狙い所)を予め検討するということは、テスト設計だけではなく、デザインレビューや作業量見積もりにも役立ちます。
• 本日は「ミニワークショップ」ということで、現場で活用できるスキルの一端に触れて頂きました。
今日体験した演習内容が、現場で活かせれば幸いです。

37

参考文献
Rick D.Craigらの著書「体系的ソフトウェアテスト入門」
 「基本から学ぶテストプロセス管理」Rex Black振り返りセッションのご案内• ミニワークショップは、いかがでしたか？
• この後、テクニカルセッションが終わったあと、「振り返りセッション」があります。
• 「振り返りセッション」の目的は、得た知識・気付きを、自分の中で思い返すだけではなく、全体で共有し、さらに広げる、• つまり、「振り返り」ではなく「振り替えり」。
• 良い知識をアウトプットし、共有し合いましょう!!

39

付録：制約と、評価軸の例• 負けないテストのために、考慮すべき事項– プロジェクトの制約– プロセスの制約– プロダクトの制約

40

付録：プロジェクトの制約例1• 発売時期の制約：
世界初、クリスマス商戦→機能独自性• 修正時間の制約：
開発メンバと設計メンバの距離、バグ表の共有→不具合発生の影響度• テスト時間の制約：
少ない工数、顧客との調整の遅れ→発生頻度、影響度• 他組織との連携の制約：→別組織、あるいは雇用形態が異なるテスト部隊と一緒に作業を分割してやらないといけない。
41

付録：プロジェクトの制約例２• 資源の制約：テスト対象が少ない、壊れるテスト項目がある、資金的問題、テスト環境(恒温槽)• テスタの制約：

モチベーションの高さが不足？、スキルの適合？、人数が少ない？

42

付録：プロセスの制約例• 開発プロセスの制約
ウォーターフォール、アジャイル• 承認手続きの制約
ドキュメント志向、顧客承認がいる• 進捗の制約
前工程の遅れ、実機の納品がテスト後半になる• 仕様の正確性の制約：
仕様変更を連発する顧客、急な仕様変更

43

付録：プロダクトの制約例• 特別なテスト環境が必要となる制約
水深20mでも動作する、年度でミリ秒誤差のない精度の高い時計、電波時計、GPS時計、(美人時計)、100m先から見える時計

44