1.
「探索的テストを探索してみよう！」
-Explore Exploratory Testing都築 将夫(TEF東海)

2.
本日の流れ
(1)自己紹介
15：05～15：15
(2)探索的テストとは？
15：15～15：25
(3)JaSST'12東海SIGでの気付き 15：25～15：45
(4)探索的テストに必要な要素 15：45～16：45
(5)探索的テストの5要素
16：45～17：00
(6)まとめ
17：00～17：05
2013/11/15
JaSST'13 Tokai SIG
2

3.
自己紹介
•業務歴
– 開発課：7.5年間(0.5年間は兼務) テスト担当
– 第3者検証課：1.5年間～(現在) テストリーダ担当
•主な業務
– 組み込み機器のF/Wテスト管理＆担当
•社外活動
– 2010年春から、TEF東海(※)の勉強会で活動中。
また、TEF東海合宿を企画&運営など、諸々活動中。
※Testing Engineer's Forum: ソフトウェアテスト技術者交流会の地方部会
→ 詳細は、 swtest.jp を参照下さい。
2013/11/15
JaSST'13 Tokai SIG
3

4.
本SIGの目標
•JaSST'13東海のタイトル、
「Beyond The Testing
～その殻を壊せ！もっと先へ～」
ということで…
(1)みなさんで「場当たり的テスト」から脱却しよう!
(2)みなさんで「探索的テストの要素」を探索しよう!
(3)みなさんと「工夫駆動テスト設計」で探求しよう!
『既存の殻を壊して、次なる時代を開拓するがね!』
2013/11/15
JaSST'13 Tokai SIG
4

5.
(1)自己紹介
•お名前
•ご所属(差し支えない範囲でOKです)
•開発現場での得意技
•本SIGに参加した理由
•探索的テストのイメージ
2013/11/15
JaSST'13 Tokai SIG
5

6.
(2)探索的テストとは？ -定義•JSTQB：ソフトウェアテスト標準用語集
– 非公式なテスト設計技法の一つ。
– テストを実施する過程で、
テスト担当者がテスト実施情報を活用しながら
テスト設計をコントロールし、
積極的に質の高い新しいテストケースを設計する。
[After Bach]
2013/11/15
JaSST'13 Tokai SIG
6

7.
(2)探索的テストとは？ -定義•SQuBOK：ソフトウェア品質知識体系
– テスト対象に関して「適切な振舞い仮説」を作り、
動作させながらテスト設計、テスト実行を
同時並行的に行うテスト。
– 指示書がある「チャーター付き探索的テスト」では、
テストの戦術や、リスク、行うべきことの
ガイドラインが示される。
2013/11/15
JaSST'13 Tokai SIG
7

8.
(2)探索的テストとは？ -定義•Exploratory Testing Explained (satisfice.com)の
記事によると
– 「学習/テスト設計/テスト実行を同時に行うこと」
– 「テスターが新しいテスト設計やより良いテストを
実行して得られた情報を利用して実行することで、
活発に制御する範囲でテストすること。」
– 「探索的テスト」という専門用語は、
Cem Kanerの"Testing Computer Software"という書籍で、
主に非スクリプトテスト(※)を含むプロセスと
教えやすい実務で開発することを手始めに考えた。
※既に記述されているテスト順序通りに実行するテスト方法
2013/11/15
JaSST'13 Tokai SIG
8

9.
(2)探索的テストとは？-私の定義•下記要素を踏まえた進化型テストアプローチ
1. 過去プロジェクト＆類似プロジェクトの
「テスト実施結果」「インシデントレポート」
「市場不具合」等、ありとあらゆる情報を収集。
2. テスト対象の「弱点」「教訓」「変化」の要素を抽出し、
テストチャータ(指示書、ガイドライン)として利用。
3. テストチャータを用いたテスト実行結果から、
次に実施するテストケースを検討し、
テストチャーターを動的に変化。
4. テスト実施結果やメンバーからの開発情報を積み重ねつつ、
学習しながらテストを実行。
2013/11/15
JaSST'13 Tokai SIG
9

10.
(3)JaSST'12東海SIGでの気付き
1.情報源
2.ふりかえり内容
3.○○が多い/○○な傾向
4.観察
5.推測
6.教訓
7.○○をやってみた
2013/11/15
JaSST'13 Tokai SIG
10

11.
(3)JaSST'12東海SIGでの気付き
1.情報源
下記7点の情報を地道に収集し、開発の
コンテキスト(背景)を把握。
①
②
③
④
⑤
⑥
⑦
ソフトウェア設計書レビューの指摘リスト
ソフトウェア設計者同士の質問メモ
外部仕様書の更新(変更/追加/削除)部分
開発者の過去の設計資料
製品の市場不具合関連ドキュメント
開発で気になるキーワードのメモ
インシデントレポートの不具合発生原因
2013/11/15
JaSST'13 Tokai SIG
11

12.
(3)JaSST'12東海SIGでの気付き
2.ふりかえり内容
＜開発側＞
①
②
③
④
⑤
市場不具合関連ドキュメントの不具合発生原因
反省会(ふりかえり)資料 or ホワイトボード資料
インシデントレポートの設計見直し内容
開発者と愚痴を含んだ過去の立ち話
レビューで極端に指摘が多い or 少ない機能や
モジュール
2013/11/15
JaSST'13 Tokai SIG
12

13.
(3)JaSST'12東海SIGでの気付き
2.ふりかえり内容
＜テスト側＞
① テストケースで不足した or 無かった要素(条件等)
② 過去のテストケースで、
テスト実施内容が解釈によって分かれるもの
③ コピー&ペースト&モディファイなテストケース
④ インシデントレポートで多く指摘した機能
⑤ 網羅的に実施しなかったテストケース
2013/11/15
JaSST'13 Tokai SIG
13

14.
(3)JaSST'12東海SIGでの気付き
3.○○が多い/○○な傾向
① 仕様書の備考欄に記述されている割に、
実は重要な仕様
② 仕様書の説明が複雑な機能
③ 1機能を複数の部署 or 会社で設計した
モジュール
④ 特定の設計者の癖(関数名の間違いなど)
⑤ 関数名や機能名が類似しているところ
⑥ 出力が不安定になりやすい機能
2013/11/15
JaSST'13 Tokai SIG
14

15.
(3)JaSST'12東海SIGでの気付き
4.観察
① テスト対象の表示値やLED等の出力の変化
② 仕様書の変更頻度
③ 仕様書の更新時間帯(特に深夜)
④ 設計者席の雑踏度(問い合わせ頻度)
⑤ 設計レビューで揉めた機能 or キーワード
⑥ 設計レビューで何度もを実施している機能
2013/11/15
JaSST'13 Tokai SIG
15

16.
(3)JaSST'12東海SIGでの気付き
5.推測
① 設計書が無い状態で外部から内部処理を推測
② 過去の不具合が多発するモジュールの挙動
③ 入力や外乱の候補(ノイズ、誤操作)
④ 開発メンバーがミスしやすいタスク
⑤ 不具合現象から引き起こす損害(失敗事例)
2013/11/15
JaSST'13 Tokai SIG
16

17.
(3)JaSST'12東海SIGでの気付き
6.教訓
① ふりかえりで次回プロジェクトへの取り組み
② ベテラン技術者の経験談(失敗したこと)
③ 開発でよく失敗する処理に関わる機能
④ 表示系デバイスの連打入力
⑤ 市場不具合の再発防止策
2013/11/15
JaSST'13 Tokai SIG
17

18.
(3)JaSST'12東海SIGでの気付き
7.○○をやってみた
① 自分がやったことのない操作
② 操作手順をポンチ絵で検討
③ エラーメッセージから検討した
異常な一連の操作(運用ミス)
④ エラー解消に至る操作
(トラブルシューティング)
⑤ テスト実行に関わる要素(操作や条件)の
組み合わせ
2013/11/15
JaSST'13 Tokai SIG
18

19.
(4)探索的テストに必要な要素
•これまでの話やみなさまのプロジェクトで
苦労した経験を踏まえ、
『探索的テストに必要な要素』
を検討してみよう！
2013/11/15
JaSST'13 Tokai SIG
19

20.
(4)探索的テストに必要な要素
•これまでの話やJaSST'13東海での気付き、
みなさまの豊富なプロジェクトの経験を踏まえ、
探索的テストに必要な要素を形にしよう！
– テストチャータ(探索的テストのガイドライン)を
テンプレートとして、探索的テストに必要な要素を
付箋に書き入れてみよう。[15分]
– みなさんで考えたテストチャータを共有し、
知見と知見の化学変化を起こしてみよう！ [10分]
2013/11/15
JaSST'13 Tokai SIG
20

21.
(4)探索的テストに必要な要素
•テストチャータ(探索的テストのガイドライン)
<探索目的>
What
Where
When
<テスト対象の探索ポイント>
入力
出力
内部処理
2013/11/15
気になる事/関心事
JaSST'13 Tokai SIG
21

22.
(4)探索的テストに必要な要素(一例)
•テストチャータ(探索的テストのガイドライン)
<探索目的>
What
Where
When
頻繁な仕様変更 テストが手薄 仕様書最終版
<テスト対象の探索ポイント>
入力
出力
やったことが無い操作
出力が不安定な値
内部処理
気になる事/関心事
レビューで揉めた機能
頻繁にテスト失敗した機能
2013/11/15
JaSST'13 Tokai SIG
22

23.
(5)探索的テストの5要素
1.
2.
3.
4.
5.
製品探索
テスト設計
テスト実行
経験則によるテスト
レビュー可能な結果
2013/11/15
JaSST'13 Tokai SIG
23

24.
(5)探索的テストの5要素
1.製品探索
•潜在的な不安定領域とデータ処理の型、
製品の目的と機能を発見し、記録する。
– 潜在的な不安定領域
•既存の製品なら、市場クレームの情報。
– データ処理の型
•構造体の予約領域
– 製品の目的や機能
•何のために製品を利用しているのか？
•製品が動作することで、何が変化するのか？
2013/11/15
JaSST'13 Tokai SIG
24

25.
(5)探索的テストの5要素
2.テスト設計
•製品の操作、観察、価値の戦略を決める。
– 製品の操作と観察
•どのように使用するのか？
•どのような動きをするのか？
– 製品の価値
•製品があるとうれしいこと
•製品がなかったら困ること
2013/11/15
JaSST'13 Tokai SIG
25

26.
(5)探索的テストの5要素
3.テスト実行
•どのように製品が動作するかについて
(1)仮説からの情報を利用し、
(2)振る舞いを観測し、
(3)製品を操作する。
2013/11/15
JaSST'13 Tokai SIG
26

27.
(5)探索的テストの5要素
4.経験則によるテスト
•経験則は、どう実施かを決めることを手助けする
経験的常識またはガイドライン。
(1)経験的常識
– 産業機械など
電源用ランプが消灯状態でボタンを押下後、電源ON。
– エレベータ
[↑]ボタンを押下すると、下の階から上昇したカゴが停止。
(2)ガイドライン
– 社内開発規約「MISRA Cの規約に沿って実装すること。」
2013/11/15
JaSST'13 Tokai SIG
27

28.
(5)探索的テストの5要素
5.見直し可能な結果
•探索的テストは、結果指向プロセスである。
– スクリプトテスト実施後の結果をベースに
探索的テストで何をテスト実施するのか決める。
– 探索的テスト実施後の結果から次テストで
何のテストを実施するのかを決める。
•要求の特定を見つける成果物を作り出す。
– 特に、レビュー可能で保証するため、
正当化できるテスト結果が重要。
2013/11/15
JaSST'13 Tokai SIG
28

29.
(6)まとめ
•探索的テストに必要な要素を検討してみた。
•普段の開発現場で感じたことや気付いたことを
メモして、メンバーで共有しつつまとめると、
何の目的で何を探索してテストを実施するか、
整理できる。
•探索的テストを通じて、製品を深く知り、
これからの製品作りをどのように進めるか、
提言してみよう！
2013/11/15
JaSST'13 Tokai SIG
29

30.
参考文献
•Exploratory Testing Explained (Satisfice, Inc)
– http://www.satisfice.com/articles/et-article.pdf
•General Functionality and Stability Test
Procedure(James Bach)
– http://www.satisfice.com/tools/procedure.pdf
•A Tutorial in Exploratory Testing(Cem Kaner)
– http://kaner.com/pdfs/QAIExploring.pdf
2013/11/15
JaSST'13 Tokai SIG
30