テストの自動化を見極める

Joe Fernandes（Oracle）Alex Di Fonzo（Synchronoss Technologies）

テストの自動化にまつわる3つの誤った定説

1. テストを自動化すると、かならずソフトウェア品質が向上する

2. すべてのアプリケーション開発プロジェクトまたはテスト・チームにおいて、自動化されたテスト・ツールの使用が可能となる

3. 自動テストとは、全テストを実施するか、まったく実施しないかのどちらかである

テストの自動化についての3つの現実

1. テストの自動化には高額な初期投資が必要となるが、一方でROIの向上を実現できる

2. 自動テスト・ツールを使いこなすにはスキルとトレーニングが必要である

3. 自動テストを実行している会社でも、一部は手動テストをおこなっている

テストに関する実際のデータ

• 業界の調査によると、すべての機能テストのうち75%は

まだ手動で実行されている

質問1：

• 現在でも手動テストへの依存度が高い会社が多いのはなぜですか。

なぜ手動テストなのか

• 時間：テスト・チームが、手動テストの代替手段について調べたり、ツールの使用方法やスクリプトの構築/管理方法を学んだりする時間を確保できない

• アプリケーションの複雑性：アプリケーションによっては、テストの自動化に適していない場合や、複雑すぎて自動テストに適していない場合がある

• スキルセット：テスト実施者（ビジネス・アナリストなど）の中には、テスト自動化ツールを使いこなすために必要なスキルを持っていない場合がある

• コスト：会社が自動テスト・ツールを所有していなく、予算不足でツールに投資できない

• ジョブ・セキュリティ：テスト実施者または品質保証（QA）部門が、手動テストに

慣れていて十分満足しており、自動化を進めることに不安を感じている

• 認識：組織自体に、自動で実行可能なテストがあるという認識が欠けている

質問2：

• 手動テストが自動テストよりも適しているのは、どのような場合ですか。

手動テストが適切な場合

• 主観的な検証：操作性やルック・アンド・フィールなど、人が主観的に検証する必要があるアプリケーション機能については、手動テストが唯一の選択肢となる場合が多い

• 新規機能/変更機能：開発中の新規アプリケーション機能や頻繁に

バージョン・アップや変更がおこなわれる機能の場合、自動スクリプトの作成は時間の無駄となる可能性がある

• 戦略的開発：テスト実施者の特別な注意を必要とする戦略的なアプリケーション機能については、常に手動でテストを実施したほうがよい場合がある

• 複雑な機能：とくに複雑なアプリケーション機能の場合、テストの自動化には大きな課題が伴う可能性が高い（時間およびコスト面での投資が利益を上回る）

質問3：

• 手動テストの代わりに自動テストをおこなったほうがよいのは、どのような場合ですか。

自動テストが適切な場合

• リグレッション・テスト：新規バージョンに引き継がれる既存のアプリケーション機能を再テストする場合（アプリケーションがまったく新しいものである場合を除き、通常は大半が該当）

• スモーク・テスト：ビルドの品質に関する高水準の評価を迅速に取得し、より詳細なテストの実施/中止の決定をおこなう場合

• 静的なテストと繰返しテスト：繰返しが多く、テスト・サイクルごとの変更が比較的少ないテストのタスクを自動化する場合

• データ駆動型テスト：アプリケーション機能のテストにおいて、同一の機能に対して多様な入力や大規模なデータセット（ログイン、検索など）を使用して検証をおこなう必要がある場合

• 負荷テストとパフォーマンス・テスト：代わりに実行できる手動テストがない場合

Oracle Application Quality Management：品質に対するライフ・サイクル・アプローチ

Oracle Test Manager for Web Applications

Oracle Load Testing for

Web Applications

Oracle Functional

Testing for Web Applications

アプリケーション

要件に基づく

テスト計画の設計

手動テスト・ケースと

自動テスト・スクリプトの

開発

負荷テストの実行と

アプリケーション・パフォーマンス

のチューニング

機能テストの実行による

アプリケーション要件の

検証

設計

設計

設計

テスト

テスト

テスト

開発

開発

開発

チューニング

チューニング

チューニング

Test Manager for Web Applicationsテスト・プロセス管理

• 一元化されたWebベース・

コンソールからのテスト・

プロセスの管理

• テスト要件の定義

• 手動/自動テスト・ケースの

開発

• 欠陥に関する文書化と追跡

• レポートの作成

Functional Testing for Web Applications機能テスト/リグレッション・テスト

• Webアプリケーションと

Webサービスのトランザクション

の自動化

• 綿密な機能テスト・ケースの

実行

• 自動リグレッション・テスト・

スイートの作成

• 機能的なアプリケーション障害の

特定と関連レポートの作成

• 機能テスト・スクリプトの再利用

による負荷テストの実施および24時間365日の監視

Load Testing for Web Applications負荷テスト/パフォーマンス・テストおよびチューニング

• エンドユーザーの動作を

シミュレートする現実的な負荷

テスト・シナリオの作成

• 何千もの同時ユーザーへの対応

が可能なスケーラビリティ

• 機能的なコンテンツ検証の負荷

条件下での実行

• サーバー側のパフォーマンスの

監視と、エンドユーザーの

応答時間との関連づけ

• パフォーマンス・ボトルネックの

特定と解決

Synchronoss Technologies

著者プロフィール：Alex Di Fonzo

• Synchronoss Technologies, Inc.で15年間にわたり品質保証管理者を

務めてきたソフトウェア・テスト業界におけるベテラン。販売の自動化

およびトランザクション管理のシステムに関する幅広い経験を備えてい

る。現在とその前のポジションの両方で、品質保証部門の開設に携わり、

ゼロから築きあげた経歴をもつ。

議題

• Synchronoss Technologiesの概要

• 会社概要

• Synchronoss Technologiesの品質保証（QA）プロセス/サイクル

• 自動テストか手動テストかを見極める評価プロセス

• 自動化：成功のポイント

• e-Testerによる自動化

• ROIの自動化（コスト対利益）

• まとめ

Synchronoss Technologiesの概要

• Synchronoss Technologiesは、世界トップ・ランクの通信サービス・プロバイダ

に対してオンデマンドのトランザクション管理ソフトウェアを提供している業界屈

指の企業です。同社では、既存のネットワークを介した高度な有線/無線サービ

スおよびIPサービスの電子サービス開発および管理の自動化、同期、そして簡

易化を実現できるソフトウェア・プラットフォームを提供しています。

• ニュージャージー州Bridgewaterに本社を置き、ペンシルベニア州Bethlehem、

バージニア州Herndon、ワシントン州Bellevueにオフィスを構えています。

Synchronoss Technologiesの品質保証（QA）プロセス/サイクル

• アプリケーション：

• 外部と内部の両方で使用

• 簡単な説明、トランザクション管理

• 頻繁な機能変更

• テスト・プロセス：

• アジャイルからエクストリームまで

• プロジェクト、クライアント、およびアプリケーション別のテスト・サイクル

• わずか6週間のソフトウェア開発ライフ・サイクル（要件、開発、テスト）

• 2ヵ月に1度、3週間のテスト実施

自動テストか手動テストかを見極める評価プロセス

• 新機能 - テスト・ケース - 手動テスト - 作業/許可 - リリース - リグレッション用

自動スクリプト作成

• 自動化機能の評価は、プロジェクト・チーム全体で担当し、全ソフトウェア開発

ライフ・サイクル（SDLC）をとおして実行する必要がある

• Functional Testing for Web Applications（旧e-Tester）の使用にかかわらず、

ビルドおよびスクリプト作成を自動ユニット・テストを含めて毎晩実施することで、

ビルド・ファイル、DB、構成、GUIの検証が可能

自動テストか手動テストかを見極める評価プロセス

• 要件の確認

• 対象機能の自動化が可能かどうか

• 開発に必要なものがある場合、それは何か

• テスト・ケース作成の時期

• 対象機能の自動化が可能かどうか

• 可能な場合は、スクリプト作成の簡易化を図るためにテスト・ケースを作成（ステップごと）

• テスト実行時

• テスト・ケースが明確で正確かどうか

• 結果は予測可能か

• 期待する結果を得るために、テストを何度も実行する必要があるか

自動テストか手動テストかを見極める評価プロセス

• 考慮事項

• プラスの側面

• 生産性は向上するか

• テスト・カバレージは改善されるか

• テストの正確性は向上するか

• テストに対して多量のデータ入力が必要か

• 操作はGUI中心かどうか

• マイナスの側面

• 人的な介入が必要

• サード・パーティのシステムが必要

• テストの結果を予測できない

• 機能変更の頻度はどの程度か

自動化：成功のポイント

• 教訓• 80%安定して変更されない機能を自動化する

• 開発時にはコントロールとフィールドに一意の名前を使用する

• リグレッション・テストをサポートするためのバルク・データ・ロードを見逃さない

• スクリプトの管理を忘れずに評価に組み込む

• できる限り一般的なスクリプトを作成する

• URL、ユーザーID、およびパスワード用の制御ファイルを使用する

• 経営陣は常にリグレッションは100%自動化すべきであると考えているが、

達成可能なことを適切に予測するなかで、こうした考えをコントロールしていく必要がある

Functional Testing for Web Applications（旧e-Tester）による自動化

• 必要な要素

• すべてのコントロールとフィールドに一意の名前がつけられている

• テスト・ハーネス

• QAのみが管理をおこなっている安定性の高い環境

• 定評のあるアプリケーション

• 常にデータのロードについて考慮すること - Synchronoss Technologiesでは、

リグレッション・テストに使用するデータのロードを自動化することで、

手動リグレッション・テストの生産性を28%向上させることに成功

• 機能が変更されたり、スクリプト更新が必要となったりするため、将来的なテスト

の評価にはスクリプトの管理を含めること

Functional Testing for Web Applications（旧e-Tester）による自動化

• スクリプト管理

• プロジェクトごとに専用のe-Testerデスクトップを使用する

• 自動化に携わるメンバーは、プロジェクト・チームと協力しあい、安定性が高く変更の少ないアプリケーション領域で作業をおこない、生産性向上を図れるようにする

• スクリプト用のネーミング規則を作成し、その規則を遵守する

• スモーク・テストについては、迅速かつ確実に実現できる

• スクリプトを夜間実行し、結果を翌朝確認することで、問題の開発について提案をより迅速に実行できる

ROIの自動化

• ROI計算時に考慮する項目

• ツールへの投資

• 習熟期間

• ツール

• アプリケーション

• 従業員の仕事に対する満足度

• 実現できること：• 夜間のテスト

• 電子メールによるテスト・レポートの送信

• それまでと同一または少ない時間でより広範囲のテスト・カバレージに対応

• 再利用性の高いテスト

• より高速なテスト・カバレージ

• 実現できないこと：

• 上記すべての即時実行

• 自動化に対する予測と実際の導入については、注意深くコントロールする必要がある

まとめ

• 実行すべきこと

• この文書をガイドラインとして使用し、各自のプロセスに合わせて変更する

• 自動化に対する予測をコントロールする

• QAZone（現在はOTNからアクセス可）を使用して、ヒントや操作方法、情報などを取得する

• 実行すべきでないこと

• 開発チームのサポートなしで自動化を試行したり、実際に自動化を実施したりする

• 自動化できることについて過大評価する

• 第三者に自動化に関する予測を設定させる

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

付　録

追加情報

search.oracle.com

または

oracle.com