TESTAUTOMATORJaSST’13 Tokyo セッションB2なれる！Test Automator-テスト自動化を成功に導く3つの真実2013/1/30
テスト自動化・TABOK研究会

セッションの流れ
ホームルーム
1時限目: テスト自動化の現場より
2時限目: 真実1. テスト自動化のスコープ
3時限目: 真実2. テスト自動化のROI
4時限目: 前半まとめ
5時限目: 真実3.パネルディスカッション～これから求められる”Automator”
テスト自動化エンジニア像とは～閉校

講師紹介：
1時限目: テスト自動化の現場より
本山絢子（もとやま じゅんこ）
Wistron Information Technology ＆Services (Japan) Inc. （ウィツ株式会社）

2時限目: 真実1. テスト自動化のスコープ
畠山 さつき（はたけやま さつき）株式会社エスイープランニング

3時限目: 真実2. テスト自動化のROI
近江 久美子（おうみ くみこ）
SIer勤務講師紹介：
真実3. パネルディスカッション～これから求められる”AUTOMATOR”テスト自動化エンジニア像とは～パネリスト ：朱峰 錦司 NTTデータ
NTTデータ中島 良樹 日本オラクル
日本オラクル
畠山 さつき本山 絢子
近江 久美子

モデレータ：
松木 晋祐
ASTER/ACCESS

リファレンスTABOKATI
米国ATI(Automated Testing Institute)策定の「自動テストに関する知識体系(BOK)」
BOK(Body of Knowledge)は、関連する職能団体によって定義される専門領域を構成する概念、用語、および活動などの完全セットを表す用語。
SWEBOK, PMBOK, SQuBOK, REBOK, BABOK等が有名

コミュニティ

テスト自動化研究会
ASTER/SGST「テスト自動化」を主たるミッションとしてソフトウェア開発に貢献する「テスト自動化エンジニア」にはどのようなスキルが必要なのか？高いス
キルとはどんな水準なのか？を研究、啓蒙する有志による研究会。
今年度はTABOKを中心に上記を議論。

Specal Thanks

テストツール WG
ASTER
日本におけるテストツールの普及と活用を啓蒙すべく集まった、ベンダー
ニュートラルのWG。国内外数十に登るテストツールベンダ、リセラー、及びユーザ企業が参画。2012年には「テストツールまるわかりガイド」を刊行。ほか、セミナー等も活発に行われている。

・ASTERのサイトにてASTERのサイトにて無料配布中のサイトにて無料配布中！
無料配布中！
・あなたの組織
・あなたの組織のツール
組織のツール導入のツール導入レベルはどれぐらい導入レベルはどれぐらい？
レベルはどれぐらい？
自己診断チェック
自己診断チェック付
チェック付きテスト自動化研究会とテストツールＷＧ
 テストをよりクリエイティブなものにしていくた

めに活動している「同志」

ベンダーの技術者が中心になり、テストツールを使って開発現場をより良くしていくために活動中

テストの自動化に取り組む現場の技術者が集まり、自動化をソフトウェア開発の要素技術として確立するために活動中１時限目

テスト自動化現場より
テスト自動化研究会
本山

絢子

自己紹介
本山絢子（もとやまじゅんこ）•（所属） Wistron Information Technology ＆Services(Japan) Inc.

（ウィツ株式会社）•テクニカルコンサルティングサービス（TechnicalConsulting Services略してTCS）を主なサービスとする部門に昨年まで所属⇒

さまざまな SIer 様のエンプラ系案件に参画

これまでの主なテスト自動化経験
2003年(〜30人月) Ant + Junit + Cactus
始めての自動化経験(ただし単体テストレベル)
200X年(約500人月) Junit + DBUnit＋EMMA
データ投入、チェック、環境クリア、などの自動化
20XX年(約200人月) Ant + Junit + DBUnit +FindBugs + CheckStyle + Cobertura
静的解析、カバレッジ、レポートまでを自動化

テスト自動化プロジェクトの現状
多くのプロジェクトで製造、単体テスト工程における
 工数増加 品質低下が発生⇒炎上、テスト自動化は中止に…

とある自動化プロジェクト

総合試験に向けたスケジュール遅延
マスタスケジュール
詳細設計

実装・単体テスト

結合テスト

総合テスト

実際(参画時)基本設計

詳細設計

テスト自動化により基本設計

詳細設計

実装・単体

結合

テスト自動化によりリカバリしたい！！

どのようなテスト自動化を⾏ったか？
1.

業務コンポーネントのテストは全て自動化
テスト対象の難易度、重要度に関わらず全てのコンポーネントにスクリプトを作成

2.

ＦＷ同梱の画面系テストツール導入 の失敗
調査工数を割り当てできなかった為、同梱されていた画⾯入⼒自動実⾏のツール導入は断念

3.

カバレッジツール、静的解析ツールの導入
解析ツールの結果が一定基準を超えるまで完了とできないルールを設けることに自動化の結果
1.

業務コンポーネントのテストは全て自動化
スクリプト記述工数が肥大化してしまった
スクリプト習得期間⾒積もり漏れによる遅延発生

2.

ＦＷ同梱の画面系テストツール導入の失敗

バグ修正のたびに数⼗個もの項目入⼒を伴うテストを⼿動で実⾏することになり、ミスも誘発

3.

カバレッジツール、静的解析ツールの導入

カバレッジを上げるためだけに工数を費やし、品質に関わらないところで時間がかかっていた誤った自動化適用のその後…
マスタスケジュール
詳細設計

実装・単体テスト

結合テスト

総合テスト

実績
基本設計

詳細設計

自動化スクリプト
当
初予
製造工数増加定の約２⇒スケジュール遅延倍！！

実装・単体テスト

結合

結合テスト期間低下
品質⇒やむなく短縮

社内ワースト３の残念なプロジェクトに…

どうしてこうなった？
マスタスケジュール
詳細設計実装・単体テスト

結合テスト

期待値
基本設計

詳細設計

実装・単体

総合テスト

結合

1.スケジュールを直ちに短縮
2.品質改善を⾒込める

問題はテスト自動化に対する過度な期待

テスト自動化に対する誤解

テスト自動化はプロジェクトに関わるあらゆる問題を解決する万能薬である⇒

大きな誤解ですテスト自動化10の誤解 ドラフト
# 誤解の内容
1 テスト自動化ツールで、壊れた（開発）プロセスを修復できる。
2 自動化テストで多数の新たな欠陥が見つかる。(またはその逆）
3 自動化テストは、手動テストを置き換える。

①スコープに関する誤解

4 レコード＆プレイバックは効果的なテスト自動化のアプローチである。
5 一つのツールですべてのテストフェーズを統合できる
6 テスト自動化は、100％の自動化が、テスト自動化成功を意味する。（→100％自動化すべきである）
7 テスト自動化ツールは直ちにテストスケジュールを短縮できる。
8②ＲＯＩに関わる誤解

自動化のコスト＝ツールソフトウエアのコスト＋テストスクリプト開発コスト（メンテナンスコスト等がぬけている）( 過大評価と過小評価の両方を含めていますので注意！）

9 単位時間あたりのテスト実施時間が極端に短くなるわけではない。場合によっては遅くなる場合もある。
10 テストの自動化は、テストスクリプトを実装することだけだと考えている。 (それだけを工数に含める）
テストの自動化は、テストチームだけできてそれで上手くいくと思っている。（日本はロールが明確に別れていないがための項目かも）（グレイボックスなしに効果的な自動化ができると思っている？）設計からいろいろ仕込むべきテスト自動化ツールは、実行だけを自動化する
12
テストの自動実行だけではない
11

誤解の多くが①スコープと②ＲＯＩに帰着する

13 自動化は体系的（ビッグバン的に）導入しないと必ず失敗してしまう

14 アジャイルにおけるテスト＝ユニットテスト＝自動テストだと思っている今回のプロジェクトを振り返ると
 スコープに関する誤解

業務ロジックを全て自動化しようとし、スクリプト製造工数が膨らんでいた効果が得やすい部分にも関わらず、画⾯系テストの自動化を断念

 ROI に関する誤解スクリプト記述⽅法習得期間の⾒積もり漏れ

テスト自動化を成功に導くには自分達にとって自動化するとおいしいところを明確にしよう
そのために重要な２つの観点

１．スコープ
２．ＲＯＩ

2時限目
テスト自動化のスコープ
自動化研究会畠山

さつき

テスト自動化を成功に導くには自分達にとって自動化するとおいしいところを明確にしよう
そのために重要な２つの観点

１．スコープ
２．ＲＯＩ

教科書
・テストツールまるわかりガイド（入門編）
・TABOK(Test Automation Body Of Knowledge）
・JSTQB(Japan Software Testing Qualifications Board）
シラバス

TABOKの示す自動化のスコープ
一般的に、テスト自動化は次の４つに分けられる
Unit
Integration
Functional
Performance
TABOK 2.1 Test Automation Types

V字モデルとテスト自動化開発の成果物

ユーザ要求
ユーザ要求

要求分析

テスト分析
テスト分析

テスト設計
テスト設計

システム
システム
要件
要件

要求定義書
画面仕様書

テスト分析
テスト分析

テスト設計
テスト設計

設計
設計

基本設計書

テスト分析
テスト分析

テスト設計
テスト設計

実装
実装

詳細設計書

テスト分析
テスト分析 テスト設計
テスト設計 テスト実装
テスト実装 テスト実⾏
テスト実⾏ 報告書作成
報告書作成受 入 テスト

開発の作業

テストの作業（プロセス）

テスト実装
テスト実装

テスト実⾏
テスト実⾏

テスト実⾏
テスト実⾏

報告書作成
報告書作成

報告書作成
報告書作成

シ ステム
テスト

テスト実装
テスト実装

テスト実⾏
テスト実⾏

報告書作成
報告書作成

ユ ニット
テスト

ソース
コード

テスト実装
テスト実装

コード解析
コード解析
モニタリングとコントロールモニタリングとコントロール
ソフトウェア管理
ソフトウェア管理
インシデント管理
インシデント管理

テストツールまるわかりガイド 図3-2 V字モデルとテストに必要な作業の対比テスト自動化システムの３要素

Drive–

操作

Judge–

判定

Report–報告自動化の適用判断のポイント
Q.テスト自動化を適用する際に、一番に気をつけたいポイントは次のうちどれ？
1.テストケースを正確に★ 2.テスト結果を明確に
3.テスト結果を適切にDrive
Judge

できるかできるか

Report できるか

V字モデルとテスト自動化
開発の作業

開発の成果物

ユーザ要求
ユーザ要求

要求分析

システム
システム
要件
要件

要求定義書
画面仕様書

テスト分析
テスト分析

テスト設計テスト設計

設計
設計

基本設計書

テスト分析
テスト分析

テスト設計
テスト設計

実装
実装

詳細設計書

テスト分析
テスト分析 テスト設計
テスト設計 テスト実装
テスト実装 テスト実⾏
テスト実⾏ 報告書作成
報告書作成

受 入 テストJudge

テストの作業（プロセス）
テスト分析
テスト分析

テスト実装
テスト実装

テスト実装
テスト実装

テスト実⾏
テスト実⾏

テスト実⾏
テスト実⾏

報告書作成
報告書作成

報告書作成
報告書作成

シ ステム
テスト

テスト実装
テスト実装

テスト実⾏
テスト実⾏

難

報告書作成
報告書作成

コード解析
コード解析

ユ ニット
テスト

ソース
コード

テスト設計
テスト設計

易

モニタリングとコントロール
モニタリングとコントロール
ソフトウェア管理
ソフトウェア管理
インシデント管理
インシデント管理

テストツールまるわかりガイド 図3-2 V字モデルとテストに必要な作業の対比テストタイプと自動化
 機能テスト 非機能テスト

パフォーマンステスト

ロードテスト

ストレステスト

ユーザビリティテスト

相互運用テスト

保守性テスト

信頼性テスト

移植性テストなど

 構造テスト 部分変更のテスト

確認テスト
回帰テスト

自動化の適用判断のポイント
テスト結果を明確に Judge できるかJその他のテストの作業と自動化
 スモークテスト

リリースの都度⾏われる動作確認
 テストデータの作成

UIを使用した膨大なテストデータの準備

自動化の適用判断のポイント
テスト結果を明確に Judge できるかJ

テスト自動化 成功への真実１
テスト自動化のスコープはテストレベル
テストプロセス
テストタイプ＋

Judge
テスト結果を明確にできるかで、判断する！

テストの結果を明確にJudgeできるか仕様が確定していない
仕様が曖昧

難

Judge

Judge

自動化導入の一歩を踏み出すなら繰返し実⾏する

ROIが高い！

回帰テスト
スモークテストから⼿を付けるのがオススメ！

テスト自動化を成功に導くには自分達にとって自動化するとおいしいところを明確にしよう
そのために重要な２つの観点

１．スコープ
２．ＲＯＩ

3時限目

テスト自動化のROI
テスト自動化研究会
近江久美子

テスト自動化を成功に導くには自分達にとって自動化するとおいしいところを明確にしよう
そのために重要な２つの観点

１．スコープ
２．ＲＯＩ

有効なはずの自動化、なぜ失敗？
自動化できるスコープが判ったら、すぐに全部を自動化すべきでしょうか？
⇒ NO!
- 業務ロジックを全て自動化しようとし、スクリプト製造工数が膨らんでいた（ 「テスト自動化現場より」より再掲）

ROIについて考えてみましょう ROI＝Return On Investment
 投資収益率- 投資によってどれだけの利益がうまれたか？

利益

投資ROIの評価？

ROIの評価で、負担を節約、利益を出せるところだけ自動化！
…何をどのように評価しますか？

ROI評価で考えるべき要素の例
導入に必要なスキル スクリプト作成の自動化ツールのレ負荷のトレーニング
ポートの分析のた
コスト
スクリプトメンテめの時間
ナンスの負荷自動化により可能になった
テストのテスト設計の負荷サポートやライセンスな 自動テスト可能なつくりにど保守契約に要するツールの動作にするためのコスト
コスト
必要な環境の構築コスト
スクリプトのツール起因の新技術の導入等によるメンテナンスのためのトラブルへの利用技術の変化に対応する技術伝承のコスト対応負荷
⼿間
ツールの購入コスト

欠陥修正後の確認テストにかかる時間

ツールのバージョンアップへの対応負荷

ツールの動作環境のメンテナンスのコスト…

ROI評価で考えるべき要素を洗い出す軸と例
ツール／テストプロセス／人／プロダクトについて、時間軸で考える
時間
導入前〜導入プロジェクト
ツール
テストプロセス人
プロダクト

ツールの購入コスト
スクリプト作成の負荷

導入後〜ソフトウェアライフサイクル全体サポートやライセンスなど保守契約に要するコスト
欠陥修正後の確認テスト
実⾏にかかる時間

導入に必要なスキルのスクリプトのメンテナンスのたトレーニングコスト

めの技術伝承のコスト

自動テスト可能なつくりにする

新技術の導入等による利用技術ためのコストの変化に対応するコスト

ROI評価で考えるべき要素を洗い出す軸と例
ツール／テストプロセス／人／プロダクトについて、時間軸で考える
時間
導入前〜導入プロジェクト
ツール
テストプロセス人
プロダクト

ツールの購入コスト
スクリプト作成の負荷

導入後〜ソフトウェアライフサイクル全体サポートやライセンスなど保守契約に要するコスト
欠陥修正後の確認テスト
実⾏にかかる時間

導入に必要なスキルのスクリプトのメンテナンスのたトレーニングコスト

めの技術伝承のコスト

自動テスト可能なつくりにする

新技術の導入等による利用技術ためのコストの変化に対応するコスト

ROI評価で考えるべき要素を洗い出す軸と例
ツール／テストプロセス／人／プロダクトについて、時間軸で考える
時間
導入前〜導入プロジェクト
ツール
テストプロセス人
プロダクト

ツールの購入コスト
スクリプト作成の負荷

導入後〜ソフトウェアライフサイクル全体サポートやライセンスなど保守契約に要するコスト
欠陥修正後の確認テスト
実⾏にかかる時間

導入に必要なスキルのスクリプトのメンテナンスのたトレーニングコスト

めの技術伝承のコスト

自動テスト可能なつくりにする

新技術の導入等による利用技術ためのコストの変化に対応するコスト

ROI評価で考えるべき要素を洗い出す軸と例
ツール／テストプロセス／人／プロダクトについて、時間軸で考える
時間
導入前〜導入プロジェクト
ツール
テストプロセス人
プロダクト

ツールの購入コスト
スクリプト作成の負荷

導入後〜ソフトウェアライフサイクル全体サポートやライセンスなど保守契約に要するコスト
欠陥修正後の確認テスト
実⾏にかかる時間

導入に必要なスキルのスクリプトのメンテナンスのたトレーニングコスト

めの技術伝承のコスト

自動テスト可能なつくりにする

新技術の導入等による利用技術ためのコストの変化に対応するコスト

ROI評価の着目点
 人やプロダクトそのもの、ソフトウェアライフサイクルプロセス全体も関係する
 求められる情報やスキルも多い要素は洗い出せても…
 それぞれの要素についての投資と収益を、どこに着目して評価する？
 費用だけ気にすればよい？

ROI評価の着目点、TABOKより
 費用に着目- 投資と利益の費用、つまり費用の⾯から評価- 自動化前後を比較
 時間に着目- 時間の投資と利益から評価、つまり効率向上の⾯から評価- 自動化前後を比較
 リスクに着目- 自動化しないことのリスクとリスクが損失に変わった場合のコストから評価
TABOK 1.3 Automation Return-on-Investment (ROI)より

ROI評価の着目点、どれを採用？
どれも完璧ではない－選択の必要がある
 費用に着目- 費用以外の利点が⾒えない

例：カバレッジ向上

 時間（効率性）に着目- 手動テストでできず、自動化されたことでできるようになったテストは？

TABOK 1.3 Automation Return-on-Investment (ROI)より

ROI評価の着目点、どれを採用？
どれも完璧ではない－選択の必要がある
 リスクに着目- 自動化前と比較しなくてよく、他の2つの⽅法の問題をカバーする- ただし、精緻なリスク分析とリスク顕在化時の損失の計算が必要

TABOK 1.3 Automation Return-on-Investment (ROI)より

テスト自動化 成功への真実2

ROIの評価では何に着目するか、評価対象の明確化が必要
コスト

時間

リスク

ROI評価が失敗したら？
必要な要素の漏れ

着目点の選択誤り

適切にROI評価できずおいしい自動化は困難に
テスト自動化による効果を⾒落とす
例

自動化しないと実現できないテストがあり、リリース延期
テスト自動化による問題を⾒落とす
例

ツールの導入による想定外のプロセス変更を余儀なくされ予算超過

ROI評価まとめ

自動化で何を改善するか踏まえ必要な要素と着目点を導き、適切なROI評価を⾏う全部最優先？
では全部評価しましょう

ROIの評価自体の負荷も考慮が必要

テスト自動化を成功に導くには自分達にとって自動化するとおいしいところを明確にしよう
そのために重要な２つの観点

１．スコープ
２．ＲＯＩ

4時限目

前半まとめ
テスト自動化研究会
近江久美子

スコープとROIを正しく⾒極めたら？
 スコープに関する誤解

業務ロジックを全て自動化しようとし、スクリプト製造工数が膨らんでいた効果が得やすい部分にも関わらず、画⾯系テストの自動化を断念
 ROI に関する誤解スクリプト記述⽅法習得期間の⾒積もり漏れ「1時限目

テスト自動化現場より」より

テスト自動化にあたり⾏なうこと
スコープの問題にはテスト結果のJudgeが明確にできるテストを選定。自動化の目的を達成するだけでなく、自動化を実現しやすいテストから着手する

ROIの問題には必要な要素と着目点からROIを評価し、最大化できる進め⽅、優先順で自動化する。
例えば、繰り返し⾏なうテストを最優先とする

スコープ、ROIともに•継続的に自動化のスコープを⾒直し、ROIが最大化される状
態を保つスコープとROIを正しく⾒極めたら
 スコープを正しく⾒極めたら業務ロジックから実現容易な部分を予定工数内で自動化、バグ検出の一部前倒しに成功
調査工数を設けて画面系テストの自動化を真っ先に実現、テスト実⾏時間を短縮

 ROI を正しく⾒極めたら多大な習得期間が必要なテストの自動化は後回し。
代わりに繰り返し⾏なう回帰テストの自動化に注⼒し、オペミスなく再現性の⾼いテストで効率アップ

負荷は無理ない程度、自動化部分は効果享受！

テスト自動化を成功に導くには重要な２つの観点そして「真実」
１．スコープ
２．ＲＯＩ

３つ目の「真実」ー テスト自動化を導入、維持、成功させる

３．テスト自動化エンジニアとは？
考えてみましょう
4時限目までの参考文献「TEST AUTOMATION BODY OF KNOWLEDGE (TABOK)」Automated Testing
Institute, 2011年「テストツールまるわかりガイド（入門編）」ASTERテストツールWG, 2012年「テスト技術者資格制度 Foundation Level シラバス 日本語版」International Software
Testing Qualifications Board(Japan Software Testing Qualifications Board翻訳）,
2011年

5時限目

パネルディスカッション〜これから求められる”AUTOMATOR”
テスト自動化エンジニア像とは〜
テスト自動化研究会
ツールWG

講師紹介：
パネリスト ：
朱峰 錦司 NTTデータ
NTTデータ中島 良樹 日本オラクル
日本オラクル
畠山 さつき本山 絢子
近江 久美子

モデレータ：
松木 晋祐
ASTER/ACCESS

お題その1
テスト自動化
テスト自動化エンジニアに自動化エンジニアに求エンジニアに求められる技術、技術、どちらかひとつとどちらかひとつと言われればA.プログラミング
A.プログラミング技術
プログラミング技術？
技術？
B.テスト
B.テスト設計技術
テスト設計技術？
設計技術？

お題その2

これから生まれるテスト自動化エンジニアに最初に伝えたいひとつのこと

お題その3(予備)テスト自動化が常識な世界でのテストマネジメントとは

TEST
AUTO

MATO

R

ご清聴、ありがとうございました！