システムテスト自動化の動向と勘所

1. 1 システムテスト自動化の動向と勘所 2016/01/15 株式会社 SHIFT 太田健一郎

2. 2  SHIFTのテスト自動化サービス  自動化の選定方法とROI  環境構築とビルドの自動化 AGENDA

3. 3 SHIFTのテスト自動化サービス 3

4. 4  自動化のメリット・難しさ  SHIFTの自動化サービス  自動化カウンセリング・可否判断  自動化基盤構築  テストスクリプト作成  導入実績紹介 SHIFTのテスト自動化サービス

5. 5 人の作業だけに頼る開発プロセスの課題自動化のメリット・難しさ検証スタート時に問題が噴出担当者がいないとリリース作業ができない回帰テストに膨大な工数がかかるリリースに使ったモジュールのバージョンがわからない  開発者のPCでは動作するのに検証環境では動作しない  大量のバグで検証作業がブロックされ、進められない  環境の更新作業が属人化しており、「ビルド職人」がいないと何もできない  環境の種類が多い場合、ビルド作業だけでもチームが必要  どの環境にどのバージョンのモジュールがいつリリースされたかという情報が不明確 or Excelなどの管理票頼り  既存機能のテストに押されて、重要な新規機能のテストに十分な工数を割けない  影響範囲を絞りきれず、毎回大量のテストを実行せざるを得ない

6. 6 CI＆自動テスト活用で「安心できる」開発プロセスを実現自動化のメリット・難しさ ⇒ デイリービルドで問題の早期発見 ⇒ 自動ビルド＆デプロイで属人化の防止 ⇒ ビルド履歴の管理で追跡可能性を実現 ⇒ 自動テストで繰り返し作業の軽減コンパイルや静的解析のレポートにより、ソースコードの問題を開発中に発見 Selenium等のテストツールと連携し、自動テスト・レポートを実施ワンクリックデプロイを設定することによりビルド職人不在でも作業が可能各環境の各モジュールがいつ・どこで作られたかを完全に追跡検証スタート時に問題が噴出担当者がいないとリリース作業ができない回帰テストに膨大な工数がかかるリリースに使ったモジュールのバージョンがわからない

7. 7 単なるツール導入だけでは解決できない課題が多数テスト自動化に対する誤解  ツールを導入すれば、簡単に実現できる  全部自動化すれば回帰テストの工数がゼロになる  単純作業なので、安価な労働力で実現できるいざ始めてみると突き当たる様々な課題  自動化を意識していない作りのせいで、うまく自動化できない  自動テストで何を検証しているのか分からない  テストの結果が不安定で、不具合発見に使えない  アプリケーションのリリースごとに膨大なメンテナンスが必要  不具合でテストが失敗しているのに、誰も気づいていない ... etc ▶ ツールの機能だけでなく、運用時の課題を解決できる経験知と適切な導入ステップ、ツールに関係のない設計ノウハウが必要自動化のメリット・難しさ

8. 8 導入フェーズをしっかりと設け、メリットを最大化 SHIFTの自動化サービス

9. 9 自動化カウンセリング＆可否判断 SHIFTの自動化サービス開発プロセスにうまく自動化を導入すると、工数削減・オペレーションミスの削減・属人化の防止など様々なメリットを享受することができます。しかし、闇雲にツールを導入したりいきなりテストを書き始めようとしたりすると工数ばかりがかかってなかなか効果を得られないことも多くあります。そのような失敗を防ぐため、経験豊富なコンサルタントがお伺いし現在の開発環境・開発プロセス・課題をヒアリングした上で着手すべきポイントをお勧めします。実際にアプリケーションやソースコードを短期間で調査して自動テストに向いているかどうかの判断を行う場合もあります（一部サービスは有償となります）。テストツールの可用性チェックレポート例右のように、頻繁に登場する部品について操作可・不可を調査しレポートします。また、テストシナリオの観点からも自動化の可否をレポートします。

10. 10 自動化基盤構築 SHIFTの自動化サービス安定した品質の自動テストを作成したり自動化で業務を効率化したりできるようにするため、ベースとなる部分の構築を行うサービスです。活動内容は、カウンセリングの結果とお客様のご希望により選択いたします。  CIツール導入 (ビルド自動化)  CIツール（Jenkins）を導入し、ビルドやデプロイ・自動テストの実行など開発中に発生する繰り返し作業を自動化する支援を行います。  GUIテスト基盤構築・ガイドライン作成  画面のGUIを通したテストを自動化するためのガイドラインを作成します。  特に、アプリケーション独自のUI部品があるようなケースではここでベースを作成することで量産体制に入った際に非常に楽になります。

11. 11 GUI自動テスト作成 SHIFTの自動化サービス画面のGUIを通したテストはどうしても打鍵に時間がかかり、システムが大きくなるほど既存機能のリグレッションテストの工数は大きくなります。そのようなテストの工数を削減する自動スクリプトの作成・メンテナンスをSHIFTのテストエンジニアがお手伝いします。製品の変更にすばやく対応できるよう、保守性の高いテストスクリプトを構築するノウハウも備えています。ツールはOSSであるSeleniumを使うことが多いですが、対象アプリケーションやテストの目的次第で各種有償ツールでご対応している場合もあります。

12. 12 ハンズオントレーニング SHIFTの自動化サービス社内で自動化を進めていきたいお客様向けに、半日〜2日程度で自動テストの書き方・CIツールの使い方等をトレーニングいたします。トレーニングには大きく二種類あります。  カスタマイズしたトレーニング  前頁の「自動化基盤構築」を実施したお客様には、お客様ご自身の製品を対象としたガイドライン・サンプルを使って自動テストを書く方法を体験していただきます。  実案件適用への壁がないため、すぐに業務で役立つ知識が身につきます。  標準トレーニング（ヒンシツ大学）  トレーニング単独でご利用いただく場合には、Selenium（GUIテスト自動化ツール）もしくはJenkins（CIツール）のハンズオントレーニングをご用意しています。  実際に手を動かす部分の比重が大きく、チームに自動化を取り入れたい若手エンジニアの方にぴったりの内容です。

13. 13 導入実績紹介実績例① 金融系パッケージソフトカスタマイズ案件  IT工程のテスト自動化  対象システム：Javaアプリケーション  使用ツール：SilkTest  概要  キーワード駆動テストを採用。キーワードを解釈するエンジンから自作し、工数はかかったがITのほぼ8割（8000ケース）を自動化することに成功  すべてを手動で実施した場合の工数：約30人月  構築工数：エンジン＋キーワード作成5人月、スクリプト＋データ18人月  構築期間：エンジン＋キーワード作成2ヶ月、スクリプト＋データ6ヶ月程度  完成後の実行時間と運用工数：PC4台で約1.5日で自動実行、その後NGケースの再実行や確認に約1.5人日（3人×0.5日）  効果  通常手動の3倍程度かかると言われる初期構築を手動とほぼ同じ工数で作成できたため、今後のカスタマイズ案件でも使うことを考慮すればかなり高いROIを達成  ITa後半からスクリプトの作成を開始し、手動であればほぼ不可能なテストの再実行を高頻度で行うことができ、品質の向上に寄与

14. 14 導入実績紹介実績例② コンシューマ向けWebサイトの回帰テスト案件  毎日小さなリリースが入るWebサイトの回帰テスト自動化  対象システム：Webアプリケーション  使用ツール：Geb（最近のメインツール、Seleniumのラッパー）  概要  小さいリリースのたびに長時間かけてテストをするのは避けたいが、ユーザに影響の出る課金周りの機能を中心にしっかりと回帰テストしたいという要望に応えるため並列でテスト実施できる環境を構築  1.5ヶ月（2人月）程度のサイクルで構築⇒前回部分を運用しながら新規構築を繰り返す  完成後の実行時間と運用工数：PC4台で約1時間で自動実行、その後NGケースの再実行や確認に約1時間  効果  ①と同じく、手動ではほぼ達成不可能な回数のテストを実施  比較的短時間でテストを回すことで、主に環境面の問題を早期に発見し安定運用に寄与

15. 15 導入実績紹介実績例③ 電子書籍アプリの回帰テスト自動化  スマホアプリの自動化の立ち上げ  対象システム：iOSアプリ/Androidアプリ/管理画面（PC）  使用ツール：Appium, WebDriver, RSpec, Jenkins  概要  ベースとなる1つのアプリ＋出版社/雑誌ごとに派生するアプリの全体を素速くテストするための仕組み作り  ツール選定＋基礎調査：1ヶ月、ベースアプリでのケース作成：1週間、派生アプリのケース作成：2週間、その後運用環境の作成  テスト対象、環境  対象を絞り、核となる10ケース程度から始めることで安定を維持  PC側は全画面（60〜70）アクセステスト＋基本機能  運用環境ではMac上にJenkinsを立てて、スマホアプリについてはシミュレータ使用で 1日に1〜2回実行（1アプリあたり20〜30分）  ロングランテスト  効果  主に検証環境の配布後のチェックに使用し、配布直後の混乱を防止

16. 16 導入実績紹介実績例④ ECアプリのテスト自動化プロセス策定  スマホアプリのテスト自動化のモデルを作成する  対象システム：Androidアプリ（※iOSは環境要因で断念）  使用ツール：Calabash, Xamarin Test Cloud  概要  自動化可否判断〜ケース作成のプロセスや測定すべきKPIを決定  実際に対象アプリのテストケースを作成し、上で作成したモデルをブラッシュアップ  事前調査：1週間、テストケース作成：2週間、その他の活動：2週間  テスト対象、環境  基本機能40ケースを自動化（元々の対象46ケースのうち、6ケースは実装不可）  テストケースはローカルPCに加え、Xamarin Test Cloud上で2機種検証も実施  効果  テスト自動化立ち上げ時のモデルを作り、横展開しやすい状態を構築  ※運用面の課題は残る

17. 17 自動化の選定方法とROI 17

18. 18 1. 自動化へのSTEP 2. テスト対象の選定の考え方 3. ROI 18

19. 19  テスト対象の把握  仕様  アーキテクチャ  自動化する範囲の選定  ツールの選定、フィージビリティチェック  自動化基盤構築  テストスクリプトを作成するためのフレームワーク整備  継続的に実行するためのCI環境構築  テストスクリプトの作成  テストスクリプトの運用大まかなSTEP 19 ある程度行き来が発生

20. 20  テスト対象の把握  仕様  アーキテクチャ  自動化する範囲の選定  ツールの選定、フィージビリティチェック  自動化基盤構築  テストスクリプトを作成するためのフレームワーク整備  継続的に実行するためのCI環境構築  テストスクリプトの作成  テストスクリプトの運用「反復しながら改善すること」が重要 20 少ないテストケースでも良いので、素早く全体像を作り上げる ↓ 内容を開発チームへ周知し、プロセスに取り込んだ上で改善していく

22. 22  最初に取り組むべき対象  その後、テストを増やしていく戦略（下に行くほどROIが下がる）テスト対象を目的別のTest Suiteに分け、少しずつ増やしていく 22 Seleniumデザインパターン & ベストプラクティスDima Kovalenko, 2014 スモークテストスイート最低限の機能が動いている（機械が火を吹かない程度）ことを確認するテストマネーパススイート (組み込み機器の場合、ライフラインスイート) アプリケーション全体における主要な経路のテスト ECサイトやオンラインバンキング等の場合、売上に直結する or クレームの原因となる「ユーザのお金が動く」トランザクションについて重点的に見るテスト不具合駆動不具合の再発を防ぐ目的で作成する新機能駆動新しい不具合を発見する目的で、開発に追い付きながら作成する必要があるフルリグレッション既存機能について、スモーク/マネーパススイートに入っていないものを入れていく 99%カバレッジすべての機能を詳細にテストする

23. 23  対象の選定で解決すべき部分  テストケース・テストデータの数が多い  確認内容が細かすぎる（センシティブ）  自動テストの実装で解決すべき部分  １つ１つのテストケースの実行時間が長い  テストケースが相互依存している  デバッグが困難保守性を下げるアンチパターン 23 システムテスト自動化標準ガイド Mark Fewster, Dorothy Graham, 1999

24. 24  自動化が容易なテスト  テスト自動化ツールとクライアントの処理で完結するもの  フォーム入力、ボタン押下による画面遷移  タイトル、表示されているテキスト、要素の活性・非活性のチェック  ファイルアップロード  メール受信  テストケースに依存関係が存在しないもの  順序を入れ替え、もしくは並列実行しても問題のないもの  自動化困難なテスト（※不可能かどうかは環境にもよるが原則優先度を下げる）  テスト自動化ツールで操作しにくいもの  ドラッグアンドドロップ  モーダルダイアログ（JavaScriptのwindow.showModalDialog()で開くもの）  アプリケーション側の作り込み、APIの用意が必要なもの  日付変更などアプリケーション側の設定変更が必要なもの  複数ユーザ同時操作など、タイミング依存の動作  別のツールや手動の組合せが必要なもの  音声や画像の確認  帳票の確認テスト自動化の向き、不向きから選定 24 システムテスト自動化標準ガイド Mark Fewster, Dorothy Graham, 1999 期待値画像を準備して画像比較をすることである程度可能もしくは、必要な操作だけを自動実行した後に結果チェックを目視で行う

26. 26  自動化の効果は大きく3つ  コスト削減  効率の向上  ソフトウェア品質の向上  ROIの計算方法  運用コストに入るもの  実行に関わるコスト：自動テストのセットアップ、実行後の分析、障害報告、テスト結果の報告等  保守に関わるコスト：仕様変更に合わせたテストスクリプトの改修  インフラ・ツールのコスト：HW費用、各種ツールのライセンス費用等自動化のROIの考え方 26 利益 : （手動で運用を続けるコスト(t) ー自動テストの初期開発コストー自動テストの運用コスト(t)）投資 : （自動テストの初期開発コスト＋自動テストの運用コスト(t)）ここに、「欠陥コストの差分(t)」として自動テストを実施しなかった場合に起こったであろう欠陥によるコストを載せる考え方もありますテスト自動化のROIを計算してみよう（@IT）太田健一郎 http://www.atmarkit.co.jp/ait/kw/test_roi.html

27. 27  ROI以外のKPI  1テストケースあたりの実行時間  ツールベンダーのデモ等では一見速くなるように見える  自動化されたテストの方が、テストケースの独立性を保つための事前事後処理、同期処理のために遅くなる可能性が高い  この向上を目標にしない方が良い  トータルの実行時間  並列実行により速くすることが可能  ただし、テスト環境(アプリケーション、データベース)を共有した状態で並列実行するとシステムテストレベルではシステムへの副作用により、他のテストケースに影響を与えてしまう可能性が高い  データベースを使わないインメモリのユニットテストであれば、テストの独立性を高めることが容易であるため、並列実行の効果が高い  テストケースを並列実行可能にするためには排他処理などテスト対象アプリケーション側の作り込みも必要となる  テスト環境を複数用意し、テストを振り分け、並列実行するのが対コスト効果が高い  この場合、アプリケーションのビルド＆デプロイの自動化も必須となる ROI以外のKPIと課題 27

28. 28 環境構築とビルドの自動化 28

29. 29  デプロイと自動テストの関係  JenkinsとSelenium Grid  Jenkins x Selenium組合せパターン  ビルドのポータブル化と課題  Docker - 環境構築の自動化環境構築とビルドの自動化

30. 30 デプロイと自動テストの関係 30

31. 31 デプロイと自動テストの関係開発準備要件定義設計コーディング静的解析単体テストデプロイ GUI テスト不具合管理リリース開発テストリリース広い意味でのテストの自動化 (CI/CD) 自動テスト専用の環境デプロイ自体の自動化通常のテスト自動化の範囲

32. 32  開発チームがデプロイしてくれないと自動テストが開始できない  手動テストとかち合って自動テストが失敗する  開発側の変更(コードやコンテンツ)に連動して自動テストが実行されないため、真の意味でのCIとならない  テストの並列実行の環境を簡単に複製できない  →自動テストの効果を高めるためにはアプリケーションのビルド、テスト環境へのデプロイまでを開発対象に含めるべき自動テストの専用の環境がないと・・・ 32

33. 33 JenkinsとSelenium GRID 33

34. 34 Jenkinsのマスター・スレーブ 34 マスタースレーブスレーブスレーブ  作業指示  必要なプログラム  結果指示と結果収集だけをする実際のビルドやテストを実施する

35. 35 Selenium GRID 35

36. 36 Jenkins x Selenium組合せパターン 36

37. 37  ファイルをダウンロードして、中身を確認するようなテストケースではSelenium Gridが使用できない Selenium GRIDを使わない 37 Jenkins マスタースレーブスレーブスレーブ Seleniu mを実行できる環境

38. 38  Jenkinsのマスター・スレーブとSeleniumのHub, Gridの両方を管理するのを容易化する Jenkins Selenium Pluginを使う 38 Jenkins マスター兼 SeleniumHub スレーブ兼ノードスレーブ兼ノードスレーブ兼ノード Seleniu m GRIDのノードでもある

39. 39  並列実行、OS・ブラウザの組合せテストの効率を最大化する Jenkins と Selenium GRIDを分離 39 マスタースレーブスレーブ

40. 40 ビルドのポータブル化と課題 40

41. 41 アプリケーションライブラリ・フレームワークミドルウェア実行言語 OS 一般的なレイヤ構造 41

42. 42 EC-CUBE Silex IIS/Apache/PostgresSQL PHP Debian 例えば、OSS ECパッケージのEC-CUBE3だと 42

43. 43 アプリケーションライブラリ・フレームワークビルドツールミドルウェア実行言語 OS ビルド環境 43 ビルド成果物環境

44. 44 ビルド成果物環境アプリケーションライブラリ・フレームワーク Gradle/Maven ミドルウェア Java CentOS Jenkinsスレーブ 44

45. 45 Selenium FireFox/Chrome Xvfb Java CentOS Selenium GRIDノード 45 環境

46. 46  テスト対象のアプリケーションのビルドとデプロイ  アプリケーションを一からビルドとデプロイをするのはマニュアルやスクリプトがあっても非常に大変  Jenkins  Jenkinsのインストール自体は簡単だが、スレーブのビルド環境の構築がアプリケーションに依存し大変  Seleniumの実行だけの場合でもOS, Java, Gradle/Mavenが必要になる  Selenium GRID  Selenium GRIDの環境を一から作るのも同じく大変ビルドと自動テストの環境構築 46

47. 47 Docker - 環境構築の自動化 47

48. 48 仮想化とコンテナ 48

49. 49  Go言語で書かれている  パフォーマンスが物理マシンとほぼ変わらない  Linuxカーネルを使っている環境であればどこでも動作する  環境の変更・作り直しが容易にできる  開発用の環境がすぐに用意でき、かつ本番環境と同じものを利用できる  Dockerfileを利用してインフラの設定をコードベースで管理できる Docker 49 http://lab.sonicmoov.com/development/docker-tutorial/

50. 50  複数のコンテナの管理を容易にするツール  コンテナの増加・減少を容易に実施できる  YAMLファイルで記述する Docker Compose 50

51. 51 デモ：EC-CUBE3 マルチブラウザ自動テスト 51

52. 52  テスト自動化のROI  とりあえずやってみようというトライアル的な段階から  ROIや他のKPIなど明確な成果を求められるようになってきた  テスト自動化の対象の広がり  単一環境直列実行ではROIが悪い  ROIの向上と実行時間の短縮化  環境構築、ビルド、デプロイの自動化までを含むようになってきた  並列実行が前提になってきた  コンテナ技術、プロビジョニングなど修得すべきスキルが広がっている  IoTのテスト自動化はこれから議論される段階  従来の組み込みの自動化とどこが違うのか？  同じ：リアルタイム、非同期  違い：大量データまとめ

システムテスト自動化の動向と勘所

健一郎太田