探索的テストから考える現場の工夫(Slideshare)

探索的テストから考える
テスト現場の改善
都築将夫(TEF東海)

タイムテーブル
16：00～16：30 工夫した事例
16：30～16：35 休憩
16：35～16：55 現場での工夫について
付箋に記入する時間
16：55～17：00 休憩
17：00～17：25 みなさんと議論(1)
17：25～17：30 休憩
17：30～17：55 みなさんと議論(2)

2012/11/30 JaSST'12 Tokai SIG 2

自己紹介
• 開発課開発グループ所属のテスター：6年
• 開発課テストグループ所属の
テスター兼テストリーダ：1年
• 第3者検証課 (開発課対応)テスト部隊所属の
テストリーダ兼テスター：現在(0.75年程)
• 主な業務
– 業務用組み込み機器のファームウェアテストリーダ
兼テスト担当：2年程前～現在
• 社外活動
– 2010年春から、TEF東海原因分析勉強会&メトリクス勉強
会で活動中。また、TEF東海合宿を企画&運営。

こんな話題でお話が出来れば
① 探索的テストって何ぞや？
② 探索的テストを軸にテストの工夫について、
みなさんと共有し実践に繋げたいが、
どうすれば･･･
③ そもそも、チームとしての環境作りって
どうすれば･･･


こんな話題でお話が出来れば
• JaSST'12東海の名称、
テストの目的考えよう
～「これまでの築き」と「これからの気付き」～
ということで…

(1)みなさんで「これまでの築き」を発信。
(2)みなさんと「これまでの築き」を共有。
(3)みなさんと「これまでの築き」にイイね！と
「気付き」を探索。

『週明けから小さな工夫を始めてみよう！』

工夫した実例
① 私の悩み (※コンテキストの説明)

② テスト工程ふりかえり (※コンテキストの説明)

③ 悩みを解決するには… (※コンテキストの説明)

④ (ここで…)探索的テストとは？ (※定義の説明)

⑤ 昨年(2011年)工夫したこと (※工夫の足跡)

⑥ 気づいたこと (※工夫の足跡)

⑦ JaSST'11東海発表後のある日… (※気付き)

⑧ 文献の内容と考えたことの比較 (※気付き)


①私の悩み -その１-
• 潜在バグが検出し切れず、市場バグが発生し、
時間面&金銭面の損失が出た。
– 修正工数/バグ対応工数の増大
• 新規/差分/派生開発に必要な工数が確保できない。
• お客様がS/Wを利用できないことによる、
経済的損失が出るだけでなく、
製造元/開発元に対する不満が出てくる。
• PMやQA、技術営業、製造ライン等の対応工数も増大。
– テスト工数の増大
• 疲労が溜まるだけでなく、メンタル面でダメージがある。


①私の悩み -その２-
• 開発現場で、一部のテスターさんが
スクリプトテスト(※)であまり考えずに
テスト実施しており、作業をやるだけの
テストに留まることがある。
(※すでに記述されているテスト順序通りに実行するテスト方法)

• (記述漏れやあいまいな記述がある)
外部仕様書が原因のバグが多発しており、
テスターが多くバグ指摘し、
バグ修正後にバグ修正確認に追われがち。


①私の悩み -その３-
• 外部仕様書やS/W設計書で出戻り工程が発生し、
上流工程の工数が膨らむが、
納期は変えられないため、
下流工程であるテスト工数が短縮され、
テストケースを網羅的に考える時間が無くなる。
• 結局、テスト実施時に考えながら、
小さな工夫をしてバグを見つけるのが精一杯。


②テスト工程ふりかえり
• PFD(Process Flow Diagram)でテスト工程をふりかえる
S/W 設計や実装を
考え過ぎた外部仕様書外部仕様書レビュー前
のアイディア作成外部仕様書
経験ベースの
アドホック
類似機能の
レビュー実施
外部仕様書
完成した
外部仕様書
コピペ& モデフテストベース
レビュー前のァイ法でテスト入手
テストケースケース作成

テスト分析
改訂されたした成果物
経験ベースのテストケース
アドホックテスト分析を
レビュー実施実施
テスト条件&
テスト実施後、手順のメモテスト設計を
誤字脱字や実施
内容修正程度の
改訂実施テスト技法で
テスト設計テストケース
レビュー後のした成果物
テストケース作成
追記の形で
テストケース本来の
作成現行の
テストケーステストケース

②テスト工程ふりかえり
1. テストケース作成時、外仕の欠陥が
指摘できるようなテスト設計を実施しつつ、
発想を膨らませる仕組みがあまり無かった。
2. スクリプトテスト実施時、
テストケース＋αのα部分の発想が
非常に貧弱であった。
3. スクリプトテスト実施の時、
バグがほとんど出ない機能に力を入れすぎた。
4. スクリプトテスト実施が楽しめなかったため、
モチベーションの維持に苦労した。

③悩みを解決するには…
• テスト設計書作成工数の確保が
不可能な状況(※)かつ限られた工数の中、
創造的なテストが実施しやすい工夫として、
探索的テストに着目した。
※お客様から納期の前倒しや開発予算が削減されるなど...
• 刻一刻と変化するプロジェクトで
状況毎に最適なテストを考えたとき、
動的に考える余地を残した
テストのアプローチが必要では？と
探索的テストに着目した。

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


• SQuBOK：ソフトウェア品質知識体系
– テスト対象に関して「適切な振舞い仮説」を作り、
動作させながらテスト設計、テスト実行を
同時並行的に行うテスト。
– 指示書がある「チャーター付き探索的テスト」では、
テストの戦術や、リスク、行うべきことの
ガイドラインが示される。
• 書籍：実践アジャイルテスト
– 学習/テストの設計/テストの実行を
1つのテストアプローチに組み合わせたもの。


• 私のイメージ
<スクリプトテスト> <探索的テスト>


⑤昨年(2011年)工夫したこと
• 限られた工数の中、潜在バグが潜むテスト対象に対し、
何が問題なのか、何のテストが不足しているか、
テスト実施しながら考える仕組みを
テスターさんと考えた。(※時折、設計者も)
• テスターさんと議論して考えた結果、
テストチャータ(※)を活用して探索的テストを
実施しつつ、製品やプロジェクトが抱える弱点を
見つけることにした。
※テスト目的を明記したもの。
テスト実施法のアイデアを含む場合もある。
探索的テストにて使用。


• 探索的テストを実施しやすいよう、
テストチャータ作成に必要な情報は何か、
下記モデルを考え、テスターさんと共有した。

構成/設定
(テスト環境)
動作
(ソフトウェア内部処理)

操作/外乱(※操作に含む) 出力
(テスト実行/異常操作&異常環境) (テスト表示結果)


• 例えば、探索的テストを実施しやすいように
テストチャータとして
「テスト実行マトリクス」で表現し共有した。
相
手
故
機
障
器
検
と
出
通
信

　　
　動作　　　操作
　　　 …
通
A F
M
メ信
通通 S P
P モケ
ー
信信 I G
開終 C A
U リブ
破
始了破破
壊
破ル
壊壊壊断
線
定期通信 1 2 3 4
相手機器と通信イベント発生時通信 5 6 7 8
相手機器故障検出 … 9
故障検出 H /W 故障検出 31 32 33 34
通信経路断線検出 55
… … … … … … … …
通信状態表示 86 87 88
診断画面通信テスト 89 90 … 91
通信履歴表示 92 93 103 104

• 「テスト実行マトリクス」を2名のテスターで
テスト実施結果をベースに
何のテスト実施するかアイディアを出しながら、
探索的テストを実施した。
相
[第3段階] 故
手
機
障
第2段階の結果から、操作を他の動作でテスト
同じ検
出
。器
と
通
信
[第2段階] 　　　
　　
　動作　　　操作 …
通
第1段階でバグが出た動作を通通
A
S
F
P
M
メ
モ
信
ケ
P ー
他の操作でテスト。信信
開終
I
C
G
A
U
破
リブ
始了破破
壊
破ル
壊壊壊断
線
[第1段階] 定期通信 1 2 3 4
バグ発生時のリ相手機器故障検出
相手機器と
スクが
通信イベント発生時通信
…
5 6 7 8
9
[３]
H /W 故障検出
大きいものからテスト
故障検出実行。
通信経路断線検出
31 32 33 34
55
… … … … … … … …
通信状態表示 86 87 88
診断画面通信テスト [1]89
通信履歴表示
90 … 91 [2]
92 93 103 104


• 出したアイディア
1. 操作と操作を組合せたら、
我々が意図した動作になるだろうか？
2. 時間間隔を例えば100ms単位で操作を変えたら、
システムはクラッシュするだろうか？
3. システム構築の時に、
陥りやすいミスは無いだろうか？
4. 今まで実施したテストで、
手薄と思われるテストは何か？
5. バグ指摘で多かった機能のテストは
詳細に追求したのだろうか？

• 工夫した結果(「イイね！」)
1. バグ検出能力(※)は、スクリプトテスト実施時と
比較すると約5倍にUPした。
※テスト工数あたりのバグ検出数

2. スクリプトテストでは見つけられなかった
潜在バグ(※)を7件検出した。
※操作のタイミングによるバグ、H/W絡みのバグ、
S/W設計漏れによるデッドロック状態のバグなど
3. (探索的テスト実施後に)別の開発でスクリプト
テストを実施したところ、50件程度のバグ指摘の
うち、10件程度の潜在バグを発見した。

• 問題に対する課題
1. テスト対象の製品に潜在バグの存在を認識したが、
バグを作り込まないような設計については、
探索的テストのみでは解決できない。
2. そもそも、
テスト設計に必要な工数を確保した上で、
外部仕様の不備をテスト実施前に指摘し、
下流工程でバグが発生しにくい仕組みが無いと、
開発全体の出戻り工数増大の問題は、
根本的に解決できない。


⑥気づいたこと
• 探索的テスト実施時、
– 疑問に思った内容が、
実は潜在バグを見つける貴重な情報となった。
– これまでのテスト仕様書で記述すべき内容
(手順や条件)があいまいであった。
– 独りで黙々と考えるより、
仲間とワイワイと議論しながら
テスト実施したほうが、良いアイディアが浮んだ。
– チームとして、立ち位置の異なる方の経験や感性に
触れると、自分では気づかない観点を発見した。


⑦JaSST'11東海発表後のある日…
• 探索的テストに関する文献を見たところ、
(ほんの一部ですが)
テスターさんと一緒に考えていた内容と
文献で言及している内容が似ていることに
気づいた。


⑧文献の内容と考えたことの比較
A) Cem Kaner, "Tutorial in Explotary Testing"
– AI QUEST Conference, Chicago, April 2008
– http://www.kaner.com/pdfs/QAIExploring.pdf
B) Cem Kaner, "Exploratory Testing." (Keynote address)
– Quality Assurance Institute Worldwide Annual
Software Testing Conference, Orlando, FL,
November 2006.
– http://www.kaner.com/pdfs/ETatQAI.pdf
C) 実践アジャイルテストテスターとアジャイルチームのための実践ガイド
– Lisa Crispin Janet Gregory 著
山腰直樹増田聡石橋正章訳, 榊原彰訳/監訳, 翔泳社

• A)"Tutorial in Explotary Testing"の内容(キーワード)
– Learing(学習)
• 学習
– 製品の振る舞いと失敗
• 学習行動
– テスト対象の製品と関連製品の歴史を調査
• モデルを作る/適用する
– テストで模擬&管理&分析(物理モデル&ビジネスプロセス)
– 製品の利用パターン(使い方)
• あらゆるモデル
– 誰が何によってどう影響されるのか？


– Learing(学習)
• 暗黙的な仕様
– ユーザマニュアルドラフト版
– UI標準やスタイルガイドの刊行
– 内部メモ
– 営業プレゼンや販売コンセプト管理
– バグ票(インシデントレポート)
– 最新バージョン時の開発スタッフインタビュー
– 市場バグ記録
– テスト結果の使用性
– 資料の参照内容


– Learing(学習)
• Active Reading(能動的読書)
– 資料を読み込みときの情報探索
» 情報収集した質問と回答に答える
» 情報カテゴリを作る
» 質問/挑戦/厳密なところを読むこと
– 体系化すると･･･
» 古い知見と新しい知見を関連づける


– Learing(学習)
– 資料の情報記憶のための計画
» SQ3R
Survey：調査
Question：質問
Read：読む
Recite：列挙
Review：ふりかえり/見直し
– 記録したノート


– Learing(学習)
– “Cubing”(6観点から検討する技術)
» Describe(記述)：物理的属性/機能的属性
» Compare(比較)：何に似ている？/何故そう思ったか？
» Associate(連想)：アイディアや製品などを
何から考えついたか？
» Analize(分析)：構成の中を掘り下げ/どう関連づけたのか？
/どう同時に働きかけたのか？
» Apply(適用)：ユーザ(自分)が何に適用できるのか？
» Evaluate(評価)：立場を明確化/良い(or悪い)特徴&実行
&設計&アイディアをリスト化

• B)"Exploratory Testing."の内容(キーワード)
– Controversy(論争)
• 探索的テストは、機能テストのみではない。
• テスト探索者という緊急ツールのようなもの。
• ブラックボックステストを補助するもの。
• ひらめきを補助するツール。
• 定性的分析ツール。
• 探索的テストは、用意周到な準備を求められてこそ、
とても複雑なテストを導入することができる。
– シナリオテストは、古典的な例。
– 拡張されたシナリオは、テストの設計と価値を理解する手助け
になり、開発や最初の実行で最も学ぶことができる。

• B)"Exploratory Testing."の内容(キーワード)
– 学習理論や認識の表現で理解を促進する。
– いくつかの誘導モデルがある
• FMEA(Failure mode & Effects analysis)は、
バグカタログに適用される
• 状態モデル
– モデル
• シンプルな表現(理解/操作/システムなどの予測)
• 学際的な基本のテスト
• どのように痕跡や報告状態を学ぶか
– ワークフロー分解
– ダッシュボード(計器盤)

• C)"実践アジャイルテスト"の内容(キーワード)
– 問題について考えること。
– テストを行うにつれて、
テスト中にあるシステムを学習し、
新しいテストを設計するために役立つ情報を
用いることができる。
– 探索的テストの価値ある副産物は、
探索的テストを通じて学習した結果。


テスト(開発)現場を思いだそう！
(1)「テスト実施時、テスターさんからユニークな
アイディアを提案されたり、気の利いたテストを実施したり、
インシデントレポートで鋭い指摘を頂いたことがありますか？
(2)「開発ドキュメントの設計レビューの場で、
良い意味で想定外の指摘を頂いたことはありますか？
(3)本日のJaSST'12東海のセッションで、
「イイね！」と思ったアイディアはありますか？

みなさんの思い浮かべたエピソード等、付箋に記入して下さい。

付箋の内容をみなさんで共有し、
みなさんとテストの工夫について考えてみましょう！

探索的テストから考える現場の工夫(Slideshare)

Recommended

Recommended

More Related Content

Similar to 探索的テストから考える現場の工夫(Slideshare)

Similar to 探索的テストから考える現場の工夫(Slideshare) (20)

Recently uploaded

Recently uploaded (8)

探索的テストから考える現場の工夫(Slideshare)