探索的テストってなんですか？
アジャイル時代のソフトウェアテスト

高橋寿一 情報工学博士

誰？こいつ？
知識ゼロから学ぶプロジェクト管理
著者： 勝呂暖生
出版社： 翔泳社



現場の仕事がバリバリ進む ソフトウェアテス
ト手法
著者： 高橋寿一、湯本剛
出版社： 技術評論社

知識ゼロから学ぶ ソフトウェアテスト
著者： 高橋寿一
出版社： 翔泳社

経歴 学歴– フロリダ工科大学大学院でCem KanerとJames Whittakerに学ぶ– 広島市立大学でソフトウェアテストで博士号取得
 職歴– 米国Microsoft– 独SAP– 日本の電機会社

The World’s Most Innovative Companies in 2014

*The Innovation Premium is a measure of how much investors have bid up the stock price of a company above the value of its existing business based on
expectations of future innovative results (new products, services and markets) . Members of the list must have $10 billion in market capitalization, spend at
least 2.5% of revenue on R&D and have seven years of public data.

Salesforace

January 7, 20155

AmazonGoogle

１日に65,000回のビルド

1日に1.2億テストケース実行

コード変更毎にテストケースが走るゆっくり手動でテストとかしてませんか？

旧来のテストとは 網羅的 – 全機能ちゃんとチェックしたりする。さらにはその機能組み合わせたりする お金がかかる – 品質に関わる投資はどんなプロジェクトでも50%を超えている 時間がかかる－ 最初のリリースから数か月のテストしてませんか

銀行システム・家電・交通システム・なんか高価なソフトウェア

クラウド・アジャイルの新しいテストとは 早い 安い そこそこの品質

Androidアプリ・Webアプリ・SNS↓

新しいテストの枠組みが必要

提案する新しいテストのスタイル

 探索的テスト– Kent Beck(XPを作った人)は基本的にシステムテストや受け入れテストに関して定義していない。
– アジャイル・XPで早く開発できるようになったのに、重いテストは誰も受け入れない。それなら軽い探索的テストは最適。Daily releaseにも耐える。

探索的テストの歴史
Exploratory testing has always been performed byskilledtesters. In the early 1990s, ad hoc was too often

synonymous with sloppy and careless work. As a result, a group of test
methodologists (now calling themselves the Context-Driven School)
began using the term "exploratory" seeking to emphasize the dominantthought process involved in unscripted testing, and to begin to develop
the practice into a teachable discipline. This new terminology was first

Cem Kaner

published byin his book Testing Computer
Software[1] and expanded upon in Lessons Learned in Software
Testing.[4] Exploratory testing can be as disciplined as any otherintellectual activity.

探索的テストとは？


ソフトウェアテストの一つのスタイル

個人に自由意志を持たせるとともに責任をより明確にする

 一個人のテスト活動である

 継続的にテスト活動を洗練させる

探索的テストは以下の活動を行う

学習– テスト設計– テスト実行– テスト結果を報告
 成熟したテスト活動– テスト関連の

並行して行う上記の活動をプロジェクト期間中

うーん、よくわからなかったりする．．．

ソフトウェアを理解する

同時実行

テストケース設計

テストケースを実行する

そして一つ一つの細かいテストケースは書かない!
そんな暇があったら実際にテストしようぜ！

旧来のテストケースベースのテストをネガティブに言うと
 テストケースドキュメントなんて時間かかるしメンドウだから書かない！そんな時間があったらテストする時間にあてたほうがいい（テストケースの作成）

 だいたい製品テストなんてどこにバグが出るかわからないし、触ってみていろいろテストするとわかるじゃん！（テストケースの実行）

 ばかの一つ覚えのように繰り返しテストやったって意味ねーよ。開発者の修正とか、製品の癖とか考えながらスキルのあるテスト担当者がテストするからたくさん回帰テストのバグが見つかるんだよ（回帰テスト）

テストケースベースのテスト
 テスト設計・ケース作成を早い段階で行う
 テストリリースが出てきて、その早い段階で作ったケースを実行する
 同じテストケースをたくさん実行するテストケースベースのテストの限界□ 靴をはいてください□ 犬を抱いてください

要求仕様は間違いというより、記述しきれてないものがバグとなる

探索的テストのやり方

探索的テストのPass/Fail基準

テストプロセス
 製品の目的を明確にする(Identify the purpose of the product)

 機能を明確にする(Identify functions) 弱いエリアを叩く(Identify areas of potential instability.)

 テスト実行及びバグを記録(Test each function and record problems.)

 上記を継続的に実行する(Design and record a consistency verification test.)

テストプロセス
 製品の目的を明確にする(Identify the purpose of the product)

 機能を明確にする(Identify functions) 弱いエリアを叩く

Identify areas of potential instability.

 テスト実行及びバグを記録(Test each function and record problems.)

 上記を継続的に実行する(Design and record a consistency verification test.)

機能を明確にする(Identify functions) 製品をウオークスルー(Walk through)する。製品がどういった機能を有しているか

 重要機能のリストアップ– オンラインヘルプ– ツールバー– 右クリック、ダブルクリック– メニュー

以上を通して基本機能をテストするとも言える

テストプロセス
 製品の目的を明確にする(Identify the purpose of the product)

 機能を明確にする(Identify functions) 弱いエリアを叩く(Identify areas of potential instability) テスト実行及びバグを記録(Test each function and record problems.)

 上記を継続的に実行する(Design and record a consistency verification test.)理論的には継続開発では７％のファイルからすべてのバグが出る

テストコスト大

テストコスト小

新規開発

次年度開発

Googleアルゴリズム

Score =𝑛𝑖=011+𝑒− 12𝑡𝑖 + 12

弱いエリアを叩く(Identify areas of potential instability)

データの交換が発生する機能（オブジェクトの埋め込み、ファイル変換）

他のソフトウェアとイベントを共有機能 (目覚まし機能、メール送信)あまり使わないと思われる複雑に組み合わさったデータ入力をハンドルする機能

ファイルをネットワーク越しにオープンさせる機能

エラーや例外処理からの復帰機能

オペレーティングシステムとデータを交換させる機能（初期値）



オペレーティングシステムにサイズが依存する機能（メモリ）が少ない状態、サイズの大きいファイル）弱いエリアを叩く考え方

James Whittakerのアイディア

入力
処理

計算

ソフト
ウェアはデータ保存

出力
処理File://c:\auxまったく文章を書かないわけではない！各プロセスについてタスクシートを書く！

タスクの記述(Task Description)

なにをやろうとしているのかを記述

探索アプローチガイド(Heuristics)

このガイドラインなり、アイディアが探索的テストをどのように進めていくかを記述する。やるべきタスクを羅列するのではなく、どういう考え方でテストするかを記述する。例えば動詞を全部羅列するとかもアイディアです。

結果(Results)

どういう品質のものがリリース可能か。
どのように終わらせる。

You can say you’re done whenFAQ

探索的テストの利点・欠点

探索的テストの利点・欠点
 利点– 抜群に投資効果が高い– 早くバグを見つけられる– たくさんのバグを見つけられる理論的にはない。悪くてもテストケースベースのテストと同等

 欠点：

探索的テストの利点・欠点
 利点– 抜群に投資効果が高い– 早くバグを見つけられる– たくさんのバグを見つけられる

テストに費やす時間

テストケースベースのテスト

探索的テスト

1

2

3

4
日程

56

探索的テストの利点・欠点
 利点– 抜群に投資効果が高い– 早くバグを見つけられる– たくさんのバグを見つけられる

フューチャー

A

探索的テスト
テストケースベースのテスト
フューチャー

B

0

10

20

30

4050

コード
網羅率
探索的テスト2-3%

83%

テストケース
ベースのテスト時間

コード
網羅率91%
探索的テスト＋α83%

時間

探索的テストの注意点

探索的テストの注意点
 探索的テストに100％頼らない– テストケースベースのテストに100％頼らないというのと同じ
 探索的テストはトレーニングを十分受けたテスト担当者によってなされる 非機能テストを探索的テストでアプローチしないかも．．．

探索的テストの注意点 探索的テストに100％頼らない– テストケースベースのテストに100％頼らないというのと同じ– １つのテスト手法に頼らない– 所詮テストで見つけられるバグは５０％以下

QA活動の種類 (Activity)

レンジ

カジュアルなデザインレビュー
Informal design review

25%-40%フォーマルデザインレビュー
Formal design inspection

45%-65%

インフォーマルなコードレビュー
Informal code reviews

20%-35%

フォーマルコードインスペクション
Informal code inspection

45%-70%モデル化やプロトタイプの作成
Modeling and prototyping.

35%-80%

個人的なコードチェック
Personal desk-checking of code

20%-60%

ユニットテスト
Unit test

15%-50%

新機能テストNew function (component) test

20%-35%

統合テスト
Integration test

25%-40%

回帰テスト
Regression test

15%-30%

システムテスト
System test

25%-55%小規模のベータテスト（10サイト以下）Low-volume beta test(<10 site)

25%-40%

大規模のベータテスト（1000サイト以上）
Low-volume beta test( > 1000)

60%-75%

探索的テストの注意点
 探索的テストに100％頼らない– テストケースベースのテストに100％頼らないというのと同じ
 探索的テストはトレーニングを十分受けたテスト担当者によってなされる 非機能テストを探索的テストでアプローチしない開発者の生産性は10倍以上

探索的テストはトレーニングを十分受けたテスト担当者によってなされる Microsoftの実験– 事前にバグを入れ込んだソフトウェアにおいて、トレーニングを受けていないテスト担当者は総バグの10%しかみつけられなかったが、トレーニングを受けたテスト担当者は65%のバグを見つけた。

探索的テストの注意点
 探索的テストに100％頼らない– テストケースベースのテストに100％頼らないというのと同じ
 探索的テストはトレーニングを十分受けたテスト担当者によってなされる 非機能テストを探索的テストでアプローチはしないかも．．．

非機能要求の重要性
パフォーマンス
ユーザビリティ
セキュリティ

信頼性
相互互換性メインテナンス性
正確性
障害許容性
移植性
02

46810

非機能要求の探索的テスト
 パフォーマンステスト

 ユーザビリティテスト

 セキュリティテスト

 信頼性テスト

ユーザビリティテスト
探索的テスト

テストケーステスト

ドキュメンテーション
Documentation

84

ＧＵＩ

70

49

143%

矛盾点Inconsistency

53

167%

機能欠如
Missing function

98

96

パフォーマンス
Performance

3941

技術的バグ
Technical defect54

66

ユーザビリティ
Usability195

間違った振る舞い
Wrong behavior

263

239

タイプ

探索的テスト/テスト
ケーステスト（％）
200%

102%

95%
95%
380%
110%

信頼度成長曲線m ( t )  a (1  e
発見されたバグの数

190

263

3

44

4

31

522

615

7118790)

250

200

フォールトの数

テスト実行時間(週)

 bt

150

100

50

002

46810週フォールト

指数型モデル12

1416

end