JaSST’14  Tokyo
セッション C4-2  17:35～18:05(30分)

探索的テストを活用したシステム開発手法の提案

2014/3/7
株式会社NTTデータ
技術開発本部  プロアクティブ・テスティングCOE
熊川  一平

Copyright © 2013 NTT DATA Corporation

自己紹介• 熊川 一平 （くまがわ いっぺい）l 所属l 株式会社ＮＴＴデータ  技術開発本部
プロジェクトマネジメント・イノベーションセンタ
プロアクティブ・テスティングCOE 主任l テスト・品質保証に関する技術支援、研究開発
主としてテスト自動実行ツールの技術調査、普及活動に従事l 活動l 執筆・講演歴l ITPro（日経BP社）
実践！テスト自動化の勘所～実装・実行の自動化「キーワード駆動テストによるGUIテストの効率化」
http://itpro.nikkeibp.co.jp/article/COLUMN/20121023/431821/l Micro  Focus  テストソリューション  カンファレンス
テストツールを使ったプロセス改善のコツ、NTTデータが教えます
http://special.nikkeibp.co.jp/ts/article/ac0g/147403/l Borlandソリューションカンファレンス
テスト自動化を成功させるには？  ～NTTデータの事例～
http://special.nikkeibp.co.jp/ts/article/acab/158682/
Copyright © 2013 NTT DATA Corporation

2

目次
1.
2.
3.
4.

探索的テストとは？
SI事業における探索的テスト
探索的テスト活用の課題
探索的テストの活用方法について

Copyright © 2013 NTT DATA Corporation

3

探索的テストとは？

Copyright © 2013 NTT DATA Corporation

4

探索的テストの定義

テスト対象製品の学習、テスト設計、テストの実行を同時並行に行う技法。テスト担当者は製品を探索しながらテストの設計と実行を進めていく。

テストケースを事前に用意せず、テストをしながら怪しそうなところを探してテストしよう。

※知識ゼロから学ぶソフトウェアテス
ト【改訂版】、高橋寿一、翔泳社より
Copyright © 2013 NTT DATA Corporation

5

開発の現場でよく見る光景○○開発にてテスト実施者

このテストの結果ってこんな感じで良かったんでしたっけ？
機能設計者

…大丈夫。
でも、この機能って全角の入力できたかなぁ…？
テスト実施者

心配なんで全角入力したらバグが見つかっちゃいました。
機能設計者

やっぱりそうかー。
この部分の仕様、揉めたもんなぁ。
Copyright © 2013 NTT DATA Corporation

6一般的な探索的テストのメリット／デメリット• テストケースを作成する従来のテストに⽐比べバグの摘出効率率率が良良い• 使いやすさ、魅⼒力力といった評価しづらいテストを実⾏行行できる• 弱点をピンポイントに攻めるテストができる

Copyright © 2013 NTT DATA Corporation• 探索索的テストだけではテストを完了了できない• テスト担当者にスキルが要求される• ⾒見見つけたバグの再現性が低い

7

SI事業における探索的テスト

Copyright © 2013 NTT DATA Corporation

8

SI事業の特殊性

利用者

責任期間

SI

他人

大きい長い

自社開発

自分/他人

大きい長い

日曜プログラマ

自分

小さい

短い

Copyright © 2013 NTT DATA Corporation

9テストの可監査性

SI事業者のテストではテストに可監査性・客観性が求められる
テスト/バグ密度

信頼度成長曲線

テストケース表

上限

下限

Copyright © 2013 NTT DATA Corporation10公式なテストと組み合わせる必要がある

公式なテスト

⾮非公式なテスト

システムテスト
AP結合テスト
AP単体テスト• 事前にテストケースを作成し、要件を順番通りに検証する• テストケースは事前に作成せず、検証対象を特に定めない• 再現性／客観性／可監査性に優れる• 再現性／客観性／可監査性に乏しい• テスト1回あたりに必要な⼯工数が⼤大きい• テスト1回あたりに必要な⼯工数が⼩小さい

Copyright © 2013 NTT DATA Corporation

11

SI事業における探索的テスト活用案

Copyright © 2013 NTT DATA Corporation

12バグ発見工程の前倒しに活用する

V字モデル(探索的テスト無)

単体テスト

機能的なバグであっても運用対処で修正が見送られる

結合テスト

システムテスト開発終盤で見つかるバグは手戻工数が大きい

受入テスト

軽微なUIの修正は工期と工数の影響から断念されがち=バグ
Copyright © 2013 NTT DATA Corporation

13バグ発見工程の前倒しに活用する

探索的テストを並行実施した場合
単体テスト全てのバグが探索的テストで見つけられるわけではない
結合テスト

システムテスト

受入テスト

探索的テスト

終盤に見つかるはずだったバグの一部が序盤で摘出される
Copyright © 2013 NTT DATA Corporation

手戻工数が少なく、UIの修正が行いやすく、運用対処にも逃げないで済む=バグ
14

バグ発見工程の前倒しに活用する

探索的テストを追加した場合
スモークテスト/ビッグバンテ
ストに近い単体テスト

探索的テスト

結合テスト

システムテスト

受入テスト

結合テスト初期/前に実施することでバグの発見を早める=バグ
Copyright © 2013 NTT DATA Corporation

15

バグ発見工程の前倒しに活用する

バグは早く見つければ見つけるほどQCDに良い影響が出る。
単体テスト

探索的テスト

結合テスト

システムテスト

受入テスト

バグ摘出効率の良い探索的テス
トを活用して、バグ摘出工程のフロントローディングを目指す。

Copyright © 2013 NTT DATA Corporation

16

探索的テスト活用の課題

Copyright © 2013 NTT DATA Corporation

1
7

さぁ探索的テストをしてみようと思ったが…

Why

探索的テストをする理由が受け入れられるか？

What

何をターゲットに探索的テストをするのか？

Who

誰が探索的テストをすべきなのか？

Where

どんな環境で探索的テストをすればいいのか？

When

探索的テストはいつ始めて、いつ終えるのか？

How

探索的テストの具体的な手順は？

課題

Copyright © 2013 NTT DATA Corporation18

課題①：探索的テストをする理由が受け入れられるか？

Why

探索的テストをする理由が（お客様に）受け入れられるか？

まずは内部のQCD向上施策として実施しよう。

探索的テストはAns

⾮非公式なテスト

現段階で見積もりに探索的テストを入れたり探索的テストを理由に品質状況を説明することは難しい。
あなたがお客様だったら以下の報告は受け入れられますか？
- このプログラムはAさんが1週間探索的テストをしたからバッチリです
あくまでもCopyright © 2013 NTT DATA Corporation

⾮非公式なテスト として始めることをおすすめします。
19

課題②：何をターゲットに探索的テストをするのか？

What

何をターゲットに探索的テストをするのか？

異常が見た目に現れやすいソフトウェアがおすすめ。

Ans

Error !

バッチ系や基盤系のシステムは、テスト結果やソフトウェアの状態が確認しづらく、探索しにくいことがある。
Copyright © 2013 NTT DATA Corporation

UIのあるシステムの方が、実行結果や状態を確認しやすく、次のテスト観点を探索しやすい20課題③：誰が探索的テストをすべきなのか？

Who

誰が探索的テストをすべきなのか？
バグの探索が出来るように業務ノウハウがある人物が望ましい。探索の偏りを避けるため、テスト経験はバリエーションを取り揃えたほうがいい。

Ans

事例例
開発経験の浅い新人と、開発経験の多いベテランで探索的テストを実施して結果を比較。（探索的テストの実施方法は後述）
見つけたバグの数
新人

6件

ベテラン

6件

Copyright © 2013 NTT DATA Corporation

見つけたバグの重大度

重大度

新人

ベテラン

大22

中12

小3221

課題④：どんな環境で探索的テストをすればいいのか？

Where

どんな環境で探索的テストをすればいいのか？

見つけたいバグによるが、構築に手間の掛からない環境が望ましい。

Ans

探索的テストはUIなどの使用性を除く、非機能要件のテストにあまり向かない(※)
また、環境構築に手間がかかると、その分実行できるテスト回数が減少してしまうので、あまり構築に手間の掛からない開発環境などが良いと思われる。
イメージ図
探索的テストの実施可能回数

環境構築に必要な工数
Copyright © 2013 NTT DATA Corporation※知識ゼロから学ぶソフトウェアテス
ト【改訂版】、高橋寿一、翔泳社より
22

課題⑤：探索的テストはいつ始めて、いつ終えるのか？

When

探索的テストはいつ始めて、いつ終えるのか？

継続課題。信頼度成長曲線との相性がいいと思われる。

Ans

公式なテストにおける信頼度成長曲線の扱い方は難しい。
（テストケースの消化速度、テスト順序の入れ替えによる信頼度のねつ造など）
探索的テストにおいては信頼度成長曲線との相性が良いと考えられる。
よくある曲線
開始時期は任意。
だが、単体テストが終わっていないとフィードバックの得やすいUIからのテスト実行が難しいケースが多い。

Copyright © 2013 NTT DATA Corporation

探索的テストにおいては・探索するところが無くなってきた・探索してもバグが出なくなってきたを意味する。

23

課題⑥：探索的テストの具体的な手順は？  (1/8)

How

探索的テストの具体的な手順は？

Ans

次頁参照。

システムの適切な振る舞いについての仮説（メンタルモデル）を作る。
仮説を反証するようなテストを１つまたは複数個、設計する。

仮説に反する結果を評価する。

仮説が証明されるか反証されるまでこの手順を繰り返す。

Copyright © 2013 NTT DATA Corporation

一般的な探索的テストの実施手順は左の通り。でもこれだと具体的に何をすればいいのかわからない。⇒  属人性が極めて高い。
スキルも経験も異なる様々な人的リソースを活用しなければならないSI事業では、もう少し具体的な手順が必要。
私が実際に探索的テストを実施した際の手順を紹介します。
24

課題⑥：探索的テストの具体的な手順は？  (2/8)
１：テスト環境の構築

任意の環境に、フィードバックの得やすいテスト環境を構築する。

２：ユーティリティの準備

テストの環境構築や、事前条件を整えるために必要な作業を補助するユー
ティリティを用意する。

３：参照ドキュメントの準備

探索的テストの指針や、探索補助のためのドキュメント類を用意する。

４：スモークテスト

スモークテストとして正常系代表テストを実施する。このテストが通過するまで以降のプロセスは実施しない。

５：バグの探索スモークテストor前回のテストを通じてバグの潜んでいそうな箇所を観察する。抽出した観点をマインドマップに記述する。

６：テスト実行

マインドマップからテストする観点を選択し、テストを実行する。
結果は簡単に記録・報告する。テスト実施後、「５：バグの探索」に戻る。

７：対処と振り返り

８：計画反映Copyright © 2013 NTT DATA Corporation開発者はバグが報告されるたび、修正要否を判断して対処を行う。
修正後、回帰テストと再テストを行う。
探索的テストの結果から品質状況を分析し、今後のテスト計画を見直す。

25

課題⑥：探索的テストの具体的な手順は？  (3/8)
３：参照ドキュメントの準備

探索的テストの指針や、探索補助のためのドキュメント類を用意する。

どこを攻めるかどう攻めるか

マインドマップ

意地悪漢字(※)

システム構成図
チェックリスト

過去のトラブル

前工程の品質状況
摘出バグ数
10

エラー推測観点集

50
A機能  B機能  C機能  D機能  E機能

うるう日
Null
全角/半角ゼロ除算…

※ 意地悪漢字”JaSST2010 Hokkaido,鈴木  三紀夫様
Copyright © 2013 NTT DATA Corporation26

課題⑥：探索的テストの具体的な手順は？  (4/8)
５：バグの探索

Copyright © 2013 NTT DATA Corporation

スモークテストor前回のテストを通じてバグの潜んでいそうな箇所を観察する。抽出した観点をマインドマップに記述する。

27課題⑥：探索的テストの具体的な手順は？  (5/8)
５：バグの探索スモークテストor前回のテストを通じてバグの潜んでいそうな箇所を観察する。抽出した観点をマインドマップに記述する。

ToDo管理システム  の  件名  に  正常  な  半角文字  を  入力する  テストをしよう。

Copyright © 2013 NTT DATA Corporation28

課題⑥：探索的テストの具体的な手順は？  (6/8)
５：バグの探索

Copyright © 2013 NTT DATA Corporation

スモークテストor前回のテストを通じてバグの潜んでいそうな箇所を観察する。抽出した観点をマインドマップに記述する。

29

課題⑥：探索的テストの具体的な手順は？  (7/8)
６：テスト実行

マインドマップからテストする観点を選択し、テストを実行する。
結果は簡単に記録・報告する。テスト実施後、「５：バグの探索」に戻る。

バグの⾒見見つかった観点には印をつける。

Copyright © 2013 NTT DATA Corporation

実施したテスト/実施しなかったテストがわかるように通過したテストにも印をつける

30

課題⑥：探索的テストの具体的な手順は？(8/8)
７：対処と振り返り

開発者はバグが報告されるたび、修正要否を判断して対処を行う。
修正後、回帰テストと再テストを行う。

テストの実施バグと思わしき事象の確認

解析が困難          orバグでないリスクとして管理
Copyright © 2013 NTT DATA Corporation

バグ
解析• 探索索的テストは⾮非公式なテストなので、全てのバグに完全な対応をしようとは考えない。
• 解析が困難な場合や、バグでないと判断される場合は、以降降の⼯工程に備えてリスクとして管理理する。

• バグと判断できた場合は、本来どのバグと判断テストフェーズで摘出すべきだった本来摘出すべき バグかを確認する。
⼯工程を特定する
バグの起票• 本来摘出すべきフェーズでの品質評
価時に、探索索的テストで摘出したバグの件数をカウントする場合/しな通常のい場合の評価を⾏行行う。
バグ管理へ
31

適用結果

社内開発において、探索的テストの早期実施によるバグ摘出工程の前倒しを検証
結果l ベテランと新人の2名による探索的テストで、12件のバグを発見l バグ摘出工程が前倒しになることで、回帰テスト工数が削減され、10%の開発工数が削減。（テストだけでみると25%の削減）
l また、公式なテストだけではシステムテストでないと発見できなかったバグを早期に見つけることで修正を実施できた。
（システムテストで見つかっていたら運用対処であった。）
気付きl テスター2名のマインドマップを比べると以下のような特性があった。
Ø ベテランは経験に基づいてバグを探索する。
過去のトラブル事例や、これまでの品質傾向を重視する。
Ø 新人は観点リストなどに基づいてバグを探索する。
エラー推測観点や、チェックリスト、また異常操作を重視する。

l 公式なテストに追加する形で、非公式なテストをすることに対して否定的な意見や拒否感があった。
Copyright © 2013 NTT DATA Corporation

32

探索的テストの活用方法について

Copyright © 2013 NTT DATA Corporation

3
3

まとめ
SI事業でも探索的テストは活用できるl 可監査性・客観性が求められるSI事業では、探索的テストだけでテストを完遂することはできない。公式なテストと非公式なテストをうまく組み合わせることが重要。（並行実施、先行実施、弱点強化など）
l テスターは業務ノウハウがある人物を中心に、様々な属性を持つ人物をアサインするのが良い。ただ、SI事業では限りあるリソースの中、スキル・経験・文化も異なるメンバーで開発するため、一定の手順を定めたほうが良い。
特に見つかったバグの対処や管理方法などは重要。
l マインドマップや観点リストなど、テスターに気付きを与える様々なアイテムを用意しておくと、テスト経験のない人物であっても探索がしやすくなる。
今後に向けた課題l 探索的テストの終了条件は明確に定義できませんでした。実施する際は他のスケジュールの兼ね合いなどから、関係者で終了日や実施日数を決めると良い。
l 非公式なテストに対する拒否感は必ずある。事前に十分に説明をおこなったり事例を重ねていく必要がある。
Copyright © 2013 NTT DATA Corporation34

探索的テストに興味があるなら活用ポイント

UT

⼯工数削減したい

商⽤用バグのすり抜けを減らしたい

ここで実施

ここで実施

探索

ITST

• 結合テストの前に探索索的テストでバグを出すことで、後⼯工程のテストで⾒見見つけるよりも少ない⼯工数でバグを修正できる。
• 運⽤用対処やUI改善が実施でき、顧客満⾜足度度が向上する。
• UT以降降継続して実施しても良良い。
Copyright © 2013 NTT DATA Corporation

UTI
TST

探索

• STまですり抜けてしまったバグを探索索的テストで抽出できる。
• 設計書からテストを実施しないため、設計書からテストケースを作成する従来のテストとは違う観点のテストができる。

効果的な受⼊入テストがしたい

ここで実施
UTIT

探索

ST

• 受⼊入テストの時点で、後⼯工程で⾒見見つかるバグが摘出できる。
• 請負ベンダと違う観点で効果的な受⼊入テストができる。
※上記はITまで委託した場合

35探索的テストに興味があるなら活用ポイント
⼯工数削減したい

商⽤用バグのすり抜けを減らしたい

ここで実施

ここで実施

効果的な受⼊入テストがしたい

ここで実施

S
I
探は例
TT索
事
用活の！
トう
• 結合テストの前に探索索 テ•ス
STまですり抜けてし しょ• 受⼊入テストの時点で、的ま的テストでバグを出すまったバグを探索索的テ
後⼯工程で⾒見見つかるバグ
索し探有ことで、後⼯工程のテスストで抽出できる。
が摘出できる。
共ん
トで⾒見見つけるよりも少• 設計書からテストを実• 請負ベンダと違う観点
どん
ない⼯工数でバグを修正施しないため、設計書で効果的な受⼊入テスト
どできる。
からテストケースを作ができる。
UT

探索

I
TST

• 運⽤用対処やUI改善が実施でき、顧客満⾜足度度が向上する。
• UT以降降継続して実施しても良良い。
Copyright © 2013 NTT DATA Corporation

UTI
TS
T

探索

成する従来のテストとは違う観点のテストができる。

UT※上記はITまで委託した場合

36

Copyright © 2011 NTT DATA Corporation

Copyright © 2013 NTT DATA Corporation