20170710 hifive-test-meetup

1. DevOpsの実践に向けた
自動テスト
10th-Jul-2017
Naoya Kojima
@jugemix

2. プロフィール
 私について
 業務アプリケーションの開発者
 業務システムのアーキテクチャ・フレームワーク、品質に関心があります
 日本 Selenium ユーザコミュニティ に参加しています
 得意分野
 アプリケーション開発
 Java / Spring Framework etc.
 自動テストの環境構築、実装
 キーワード駆動テストアプローチ

3. 突然ですが、質問です
開発
テスト
その他

4. 突然ですが、質問です
DevOpsの定義

5. DevOpsとは
 業務と開発・運用が協力しあい、事業におけ
る価値創出サイクルを継続改善する活動
 引用元
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E
3%83%AB:Devops.svg

6. DevOpsの目的
 ビジネスにおける市場のニーズを受けて、
迅速に開発、テスト、リリースをし、市
場の反応を迅速に開発へフィードバック
すること
 引用元
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A
4%E3%83%AB:Devops-toolchain.svg

7. DevOpsに求められること
 市場の反応を「迅速に」開発にフィードバックすることが目的
 「素早く」、「頻繁に」、「安全に」実践する必要がある

8. DevOpsのプラクティス（一例）
 開発・テスト
 継続的インテグレーション（CI）
 自動テスト
 リリース
 継続的デリバリ（CD）
 リリース管理
 Infrastructure as Code（IaC）
 ロードテスト・自動スケーリング
 監視・フィードバック
 可用性監視
 アプリパフォーマンス監視
 自動回復
 構成管理
 プロビジョニング
 運用テスト
 ユーザテレメトリ
 フォールト挿入

9. DevOpsに対する現場のイメージ
 CI/CD、自動テストといった手法を導入すること
 注意点
 手段が目的化しがち
 DevOpsな体制が求められるようになった背景を意識することが大切

10. DevOpsに取り組む上での課題
 ビジネス価値の創出を改善する自分
たち（組織やプロジェクト）にとっ
て重要だと思うことを考える
 市場の反応を「迅速に」開発に
フィードバックすることが目的
 「素早く」、「頻繁に」、「安全
に」実践するプラクティスから選択
してみる
 出来ていること、出来ていないこと
を知る事からはじめる
http://devopsassessment.azurewebsites.net

11. 自動テスト自体の目的
 反復作業の効率化
 テストデータ準備
 テスト実行
 テスト結果の検証
 手間の掛かる作業の効率化
 複雑な手順のテスト実行
 テスト結果集計作業の効率化
 テスト実行結果の集計作業
 人為ミス、やり直しの排除

12. DevOpsにおける自動テストの目的
 問題の早期検出
 ソースコードの変更毎にテストできる
 安全性の担保
 テストが行われずにリリースされるという状況を回避できる

13. DevOpsの実現に必要なテスト
 DevOpsの実現には自動テストは必要
 DevOpsの目的は、市場の反応を「迅速に」開発にフィードバックすること
 素早くフィードバックを得るために欠陥が無い状態でのリリースが必要
 欠陥対応に追われ新たな要求に取り組むことが出来なくなってしまう

14. テスト戦略
機能テスト
探索的テスト
ユーザビリティテスト
単体テスト
コンポーネントテスト
パフォーマンステスト
負荷テスト
自動と手動
自動 ツール
手動
 アジャイルテストの４象限

15. 自動テストに対する要求
機能テスト
探索的テスト
ユーザビリティテスト
単体テスト
コンポーネントテスト
パフォーマンステスト
負荷テスト
自動と手動
自動 ツール
手動
 要求事項の整理

16. 単体テスト・コンポーネントテスト
 ソースコードに必要な要素を、プログラマが理解できるようにすること
 単体テストツール
 TDD（テスト駆動開発）
 技術面での問題に関して、タイムリーにフィードバックを得られること
 単体テストツール
 ビルドツール
 ビルド自動化/CIツール
 ソースコード管理ツール

17. 機能テスト
 業務面での要求の実現についてタイムリーにフィードバックを得られること
 単体テストツール
 テスト自動化ツール
 ビルドツール
 ビルド自動化/CIツール
 ソースコード管理ツール

18. 自動テストの設計 1/3
 機能テストの実行タイミング
master
develop
request
request
リ
モ
ー
ト
ロ
ー
カ
ル
merge
push
merge
検証環境
自動テスト実行
デプロイ
本番環境
リソース作成

19. テストシステムビルダー（Maven）
テストランナー（Pitalium based JUnit）
TestCaseLoder（POI）
テストケースファ
イル（Excel）
テストステップ
ファイル（Excel）
TestClass
KeywordInvoker
Class
Abstruct Keyword
Class
Concrete Keyword
Class
PageLocator Class
自動テストの設計 2/3
 テストシステムの構造
Programming Part
Ptaliumに「WebDriverの管理」、
「レポート」機能を委譲
selenium-javaを利用した「操
作」、「ロケータ」の記述箇所

20. 自動テストの設計 3/3
 デプロイメントパイプラインのイメージ
開発PC
Git 検証環境 本番環境
Maven
ビルドジョブ
Jenkins
検証環境
Azure・AWSなどIaCが可能な
環境を使うとテストしたいとき
に環境を構築できる。
本番環境用
リソース作成にとどめ
るという手もある。
自動テストプログラム
を実行する

21. プラクティスの選択
 開発・テスト
 継続的インテグレーション（CI）
 自動テスト
 単体テスト、コンポーネントテスト
 機能テスト
 リリース
 継続的デリバリ（CD）
 リリース管理
 Infrastructure as Code（IaC）
 ロードテスト・自動スケーリング
 監視・フィードバック
 可用性監視
 アプリパフォーマンス監視
 自動回復
 構成管理
 プロビジョニング
 運用テスト
 ユーザテレメトリ
 フォールト挿入

22. まとめ
 自動テストの目的（要求）を意識すること
 目的を達成する為に必要な構造を検討すること
 プラクティスを実践してみて初めて気付く事もありました
 何を自動化すべきか検討すること

23. 本日はありがとうございました