テストの自動化を見極める 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