JaSST‘20 Hokuriku

継続的テストに向けたテスト自動化～テスト自動化の事例と推進への課題～
2020/01/24
三菱電機株式会社 情報技術総合研究所
都築 浩平
1©2019 Mitsubishi Electric Corporation

はじめに
今日お話しすること◎テスト自動化の事例

・パブリッククラウド活用【JaSST’18 Hokkaido発表内容】
・テスト管理との統合の事例など◎継続的テスト・組織的な展開に向けた考察

・課題分類し、今後何をすべきか考えてみた話

対象外

×最新の自動化技術研究
×開発の内容詳細
×組み込み・産業機器制御
×定量的な評価2©2019 Mitsubishi Electric Corporation

目次
三菱電機紹介テスト自動化取り組み（～50分目標）
継続的テストへの課題（～80分目標）

3©2019 Mitsubishi Electric Corporation

三菱電機紹介4©2019 Mitsubishi Electric Corporation

事業分野

複数の事業群による事業活動の展開

引用：三菱電機の経営戦略（2019年5月）,(https://www.mitsubishielectric.co.jp/ir/data/management_report/index.html#strategy)

5©2019 Mitsubishi Electric Corporation

事業と研究所

事業／サービスをまたいだ技術開発支援
研究所
事業
経営／企画
サービス／プロダクト

研究

開発

開発支援

生産

運用／保守

ココの取組みについて

基盤技術開発サービス／プロダクト
…

事業
事業
…

6
©2019 Mitsubishi Electric Corporation

事業と研究所

研究開発と取り組みの位置づけ
ココ

引用：三菱電機の研究開発戦略（2019年2月）,(https://www.mitsubishielectric.co.jp/ir/data/management_report/index.html#strategy)

7©2019 Mitsubishi Electric Corporation

テスト自動化取り組み
8©2019 Mitsubishi Electric Corporation

取り組み全体

自動化検討・構築・実装と展開を実施
IoTシステム開発
リグレッションテスト自動化
アジャイルでテスト設計しながら自動化検討

製品開発
移行

ハンズオンで技術展開

別開発に展開ペアプロで技術展開

IoTシステム開発
受け入れテスト自動化
Webシステム開発
テスト管理との統合

2017

2018

2019
9
©2019 Mitsubishi Electric Corporation

IoTシステム開発
リグレッションテスト自動化

製品開発
移行

IoTシステム開発
受け入れテスト自動化
Webシステム開発
テスト管理との統合

2017

2018

2019
10
©2019 Mitsubishi Electric Corporation

IoTシステム開発
リグレッションテスト自動化
開発背景など11©2019 Mitsubishi Electric Corporation

背景

IoTシステムのアジャイル開発でテスト自動化検討
開発についてオンプレで稼働していたIoTシステムの、パブリッククラウドへの移行を目的としたプロト開発
本開発ではAWS (Amazon Web Services)を利用

クラウドネイティブなアーキテクチャを検討、アジャイル開発にて動作確認しながら進めていくことにリグレッションテストの自動化検討を担当(1人)
機能(API)テスト部分

テスト対象
クラウド

PC、スマートフォンなど
IoTシステムイメージ

機器、センサーなど
12©2019 Mitsubishi Electric Corporation

背景

複数組織またいだメンバでPoC実施
開発体制
人：事業場所(設計など), 研究所(設計支援・テスト設計),
関係会社(実装・テスト)
場所：遠隔
指示

事業本部

研究所
IoTシステム開発（クラウド）

指示

関係会社

PoC

IoTシステム開発（機器）
IoTシステム開発（アプリ）13©2019 Mitsubishi Electric Corporation

IoTシステム開発
リグレッションテスト自動化
自動化内容

14
©2019 Mitsubishi Electric Corporation

課題

開発/テスト自動化システムは複雑・運用負荷高い
開発プロセスと自動化システム
実装
ユニット
ユニット デプロイ
アプリ
ビルド
アプリ
ユニットデプロイ
ビルド
テスト
アプリ
ビルド
テスト デプロイ
テスト
テスト
テスト
テスト

CIサーバ
実装＋
運用管理

開発者

コード管理
サーバ

ビルド
サーバ

・各サーバ管理（OS, MW, ログ, 冗長化…）
・死活/性能監視, アクセス権限管理
・CIジョブ設定の複雑化/ボトルネック化
など

実装
テスト

ビルド

機能
テスト

開発/テスト自動化システム
構成管理
サーバ
デプロイ

[テスト環境]IoTシステムテスト
クライアント機能テスト
15©2019 Mitsubishi Electric Corporation

解決アプローチ(1)マネージドサービスによる自動化基盤で負荷抑制
開発プロセスと自動化システム
実装
ユニット
ユニット デプロイ
アプリ
ビルド
アプリ
ユニットデプロイ
ビルド
テスト
アプリ
ビルド
テスト デプロイ
テスト
テスト
テスト
テスト

実装
テスト

ビルド

機能
テスト

開発/テスト自動化システム
実装

マネージドサービス活用

開発者◎開発に集中できる

運用管理

クラウド
ベンダー

デプロイ

[テスト環境]IoTシステム

機能テスト
16©2019 Mitsubishi Electric Corporation

解決アプローチ(1)マネージドサービスによる自動化基盤で負荷抑制

マネージドサービスですべて解決？
開発プロセスと自動化システム

⇒NO

実装
ユニット
ユニット デプロイ
アプリ
ビルド
アプリ
ユニットデプロイ
ビルド
テスト
アプリ
ビルド
テスト デプロイ
テスト
テスト
テスト
テスト

実装

ビルド

機能
テスト

開発/テスト自動化環境

マネージドサービス活用

開発者◎開発に集中できる

実装
テスト

運用管理

クラウド
ベンダー

デプロイ

[テスト環境]IoTシステム

機能テスト
17©2019 Mitsubishi Electric Corporation

解決アプローチ(2)

機器側の独自仕様への対応を考慮した切り分け
テスト自動化するための要件を整理
マネージドサービスでどこまで可能か？
要件

・API模擬・成否判定

独自プロトコルなど考慮しなきゃいけなさそう…
連携拡大に向けてより柔軟な拡張性がほしい・レポート機能・アジャイル適用マッチするマネージドサービスはなさそうだ
保守を考えると作り込みはしたくない…

・自動実行/トリガー・サーバ管理マネージドサービスで解決できそう◎

・・・

・・・

・・・

[*] CI：継続的インテグレーション

18
CD：継続的デリバリー ©2019 Mitsubishi Electric Corporation

解決アプローチ(2)

機器側の独自仕様への対応を考慮した切り分け
テスト自動化するための要件を整理
要件

要素

・API模擬
・成否判定

ドメイン
特有

・レポート機能・アジャイル適用

テスト
汎用領域

・・・

・・・

・自動実行/トリガー・サーバ管理・・・

テスト自動化システム

テストコード
テストフレームワーク
自動化基盤

CI/CD
汎用領域
[*] CI：継続的インテグレーション

マネージドサービス
19
CD：継続的デリバリー ©2019 Mitsubishi Electric Corporation

解決アプローチ(2)

機器側の独自仕様への対応を考慮した切り分け
テスト自動化するための要件を整理

ココも少し

本開発での具体的な実現方式
要件

実現方式

・API模擬
・成否判定

ドメイン
特有

・レポート機能・アジャイル適用

テスト
汎用領域

テストフレームワーク
Cucumber

・自動実行/トリガー・サーバ管理

CI/CD
汎用領域

自動化基盤
AWSマネージドサービス

・・・ 本日お話しする範囲

・・・

・・・

[*] CI：継続的インテグレーション

テスト自動化システム

テストコ実装JAVA(+JUnit)20
CD：継続的デリバリー ©2019 Mitsubishi Electric Corporation

実施内容
要件

テスト自動化システム

テストコ実装JAVA(+JUnit)テストフレームワーク
Cucumber
自動化基盤
AWSマネージドサービス

・レポート機能└ 導入容易性・アジャイル適用└ 効率性
・自動実行/トリガー└ 独立性・保守性
・サーバ管理├ OS , MW , NW
├ 冗長化, 監視└ ログ管理21©2019 Mitsubishi Electric Corporation

実施内容
すべて自動でスケール、
管理コンソールより状態監視可能

システム全体構成
自動化基盤リージョン③テスト自動実行④テスト結果自動生成
試験結果

ストレージ
サービス

結果画面

テスト対象リージョン

実行

テストクライアント(ビルドサーバ)

監視サービス②自動構築・
自動停止

ビルド
サービス

バージョン管理サービス

パイプラインサービス

単体試験
テスト自動化基盤⑤HTML形式で結果確認

パイプラインサービス

ソースコード
(テスト)

開発基盤
開発基盤
開発基盤

マネージド
サービス

[テスト環境]IoTシステム
検知

①デプロイ
デプロイ
サービス
ビルド
サービス
バージョン管理サービス

ソースコード
（アプリ）

開発者

22
©2019 Mitsubishi Electric Corporation

実施内容

要件
すべて自動でスケール、
管理コンソールより状態監視可能・レポート機能

システム全体構成
自動化基盤リージョン③テスト自動実行④テスト結果自動生成
試験結果

ストレージ
サービス

テストクライアント(ビルドサーバ)②自動構築・
自動停止

マネージドサービスで構成
ビルド
サービス

結果画面

実行

バージョン管理サービス

パイプラインサービス

テスト自動化基盤⑤HTML形式で結果確認

ソースコード
(テスト)

マネージド
サービス

└ 導入容易性
テスト対象リージョン[テスト環境]・アジャイル適用
IoTシステム
検知
└ 効率性
監視
サービス
・自動実行/トリガー①デプロイ└ 独立性・保守性
デプロイ
サービス
・サーバ管理パイプラインサービス
ビルド✔OS , MWサービス├, NW✔冗長化,バージョン管理
├
監視
開発基盤
開発基盤
開発基盤
└ ログ管理 サービス
ソースコード
（アプリ）

開発者

23
©2019 Mitsubishi Electric Corporation

実施内容
本自動化基盤のポイント(1)監視サービスによるトリガー

構成情報の変化を検知してテスト実行
アプリ開発とテストのパイプラインを分離⇒開発基盤側の変更(追加/削除)に左右されず、保守性◎分散したアーキテクチャにも対応可能

マネージドサービスの設定変更の検知・テスト実行も可能

各サービスの管理用APIの実行を監視している (CloudTrail)⇒テスト対象側のサーバレス/マネージドサービス特有の設定や障害原因となりやすい設定値の変更を監視可能
例：Lambdaのメモリ容量やタイムアウト値
DynamoDB（データベースサービス）のキャパシティ など

24©2019 Mitsubishi Electric Corporation

実施内容
本自動化基盤のポイント(2)

テスト実行ログビルドサーバの実態はコンテナ
ビルドサービス(AWS CodeBuild)は、
ログ管理サービス(CloudWatch Logs)とデフォルトで連携⇒ビルドサーバでの標準出力がログとして自動保存されるため、API実行ログを標準出力するだけでよく、ログ管理が容易に
ビルドサービスの管理コンソール画面例

25©2019 Mitsubishi Electric Corporation

実施内容
本自動化基盤のポイント(2)

テスト実行ログ要件・レポート機能
ビルドサーバの実態はコンテナ└ 導入容易性
ビルドサービス(AWS CodeBuild)は、 ・アジャイル適用
ログ管理サービス(CloudWatch Logs)とデフォルトで連携└ 効率性
・自動実行/トリガー⇒ビルドサーバでの標準出力がログとしてストレージサービス(S3)✔独立性・保守性└に自動保存・管理されるため、API実行ログを標準出力としてテスト実行時に出力するとログ管理が容易に
・サーバ管理✔OS , MW , NW├
ビルドサービスの✔冗長化, 監視├管理コンソール画面例
✔ログ管理
└

26
©2019 Mitsubishi Electric Corporation

実施内容
要件

テスト自動化システム

テストコ実装JAVA(+JUnit)テストフレームワーク
Cucumber
自動化基盤
AWSマネージドサービス

・レポート機能└ 導入容易性・アジャイル適用└ 効率性
・自動実行/トリガー└✔独立性・保守性
・サーバ管理├✔OS , MW , NW├✔冗長化, 監視└✔ログ管理27©2019 Mitsubishi Electric Corporation

実施内容
テストフレームワークのポイント(1)レポーティング

Cucumber利用
実行したテストシナリオ別のテスト通過数やエラー数、各ステップでかかった時間など確認可能
レポートはHTMLやJSON形式で出力可能(プラグイン利用)⇒静的ホスティング・IPアクセス制限させたストレージサービス(S3)に送付することで、レポートの閲覧・管理が容易に
開発者が別途準備しなくても、最新のテスト結果を常に確認可能
ビルドログの最後に送付先URL出力
URL取得

ブラウザに
貼付けで閲覧

テスト通過数・
エラー数など28©2019 Mitsubishi Electric Corporation

実施内容
テストフレームワークのポイント(2)Cucumber

振る舞い駆動でテストファーストな開発を実現するために考案されたフレームワーク
テストケースを自然言語で記述

顧客と技術者との間の、言葉と理解の共有容易化
そのままテストコードとなるのでPull Requestベースのやり取りが可能⇒要件とテスト実装の乖離を抑制 ・・・ 手戻り削減
余計なドキュメント作成減らせる ・・・ オーバーヘッド抑制

29©2019 Mitsubishi Electric Corporation

実施内容
テストフレームワークのポイント(2)CucumberGherkin書式

振る舞い駆動でテストファーストな開発を実現
 下記のようなファイルがそのままテストコードとして扱われる
するために考案されたフレームワーク
sample.feature
テストケースを自然言語で記述@feature-tag
顧客と技術者との間の、言葉と理解の共有容易化
Feature:ログインしてユーザを識別できる

そのままテストコードとなるのでPull Requestベースのやり取りが可能
Whenなどのステップの@scenario-tag01
組み合わせで記載する
Scenario: ユーザ登録してログインする⇒要件とテスト実装の乖離を抑制
・・・ 手戻り削減
Given: “ユーザ登録”ページを表示している
余計なドキュメント作成減らせる・・・ オーバーヘッド抑制
When: “ログイン名”フォームに”melco”と入力する
And: “E メール”フォームに”xxxxxxxxxx@xxx.xx.xxx”と入力する
And: “新規作成”ボタンを押下する
Then: “melco ユーザが作成されました。”と表示されていること@scenario-tag02
Scenario: ログイン済みユーザの情報表示する…
参考：Cucumber公式Webサイト (https://cucumber.io/)30©2019 Mitsubishi Electric Corporation

実施内容
テストフレームワークのポイント(3)

保守性の高いテストコード記述が可能
Cucumberの応用的な使い方

各ステップを振る舞い・データのまとまりとしてモデル化して記載すると、キーワード駆動として保守性の高いテスト記述とすることが可能
例：“API種別を表すキーワード”＋”データセットを表すキーワード”とすると、顧客側と認識共有しやすく、コード構造化もしやすい

Stateパターンとして、データ部を状態として実装するとテストケースが増えてもロジックに変更なく追加できる…など# テストケース記載例
Scenario: ユーザログインする
When: ログイン用APIを”正常な顧客Aデータ”で実行#API種別：ログイン用APIを<>で実行#データ ：正常な顧客Aデータ
31©2019 Mitsubishi Electric Corporation

実施内容
テストフレームワークのポイント(3)

保守性の高いテストコード記述が可能
キーワード駆動テストとしての活用

要件・レポート機能
テストケースの”Given”や”When”, “Then”などを振る舞い・データ└✔導入容易性のまとまりとしてモデル化して記載すると、キーワード駆動として保守性の高いテスト記述とすることが可能 ・アジャイル適用└✔効率性
例：対象APIがSOAP(Simple Object AccessProtocol)のようにデータボディのXMLで詳細データをやりとする場合、・自動実行/トリガー“API種別を表すキーワード”＋”データセットを表すキーワード”└✔独立性・保守性とすると、顧客側と認識共有しやすく、コード構造化しやすい…など
・サーバ管理Stateパターンとして、データ部を状態として実装するとテストケースが増えてもロジックに変更なく追加できる…など ├✔OS , MW , NW
# テストケース記載例├✔冗長化, 監視目指していた自動化
Scenario:
ユーザログインする└✔ログ管理When: ログイン用APIを”正常な顧客Aデータ”で実行が実現できた#API種別：ログイン用APIを<>で実行#データ ：正常な顧客Aデータ

32©2019 Mitsubishi Electric Corporation

実施内容（追加）要件

テスト自動化システム

テストコ実装JAVA(+JUnit)・API模擬、成否判定└ 保守性

テストフレームワーク
Cucumber
自動化基盤
AWSマネージドサービス

33©2019 Mitsubishi Electric Corporation

実施内容
テストコード構成イメージ
ビルド設定(.yaml)pom.xml
テストケース(.feature)

テスト結果出力

ビルドサーバ
DataFormat

TestDataSet

API
データ形式定義API
Request データセット

機器通信
データ形式定義API
Responseデータセット
データ生成

Cucumber

API (ロジック)

ステップ定義API Client

Runner

テスト結果(.html)S3

利用

テスト結果送信

実
行

API実行

API
Request 構築
API
Response 解析

凡例： ファイル

[テスト対象]IoTシステム機能

レスポンス確認パッケージ

34©2019 Mitsubishi Electric Corporation

実施内容
テストコードのポイント
ビルドサーバビルド設定
DataFormat
テストケース追加は(.yaml)
他テストコードに影響なし
API
データ形式定義
pom.xml

API
Request データセット

機器通信
データ形式定義API
Responseデータセット

テストケース(.feature)

TestDataSet

利用// サンプル
テスト結果出力
Scenario:
認証成功
RunnerWhen ログインAPIを“正常な顧客Aデータ”で実行
Then レスポンス200が返ってくる
実
テスト結果
Then “正常な”ログインAPI応答か行… (.html)
Scenario:認証失敗
テスト結果送信
…

S3

データ生成

IoTシステム// サンプル…
API実行
API (ロジック)
public enum SetState {①シナリオファイル作成 Cucumber

ステップ定義②対応データセット作成[テスト対象]

API Client

正常な顧客Aデータ {API@override
Requestpublic
構築String getData() {レスポンス確認
API // データセット作成
Response 解析…
//ロジックにデータ引き渡し
return data;
…
機能
パッケージ
ファイル
35
凡例：
©2019 Mitsubishi Electric Corporation

効果とまとめ～30分

開発者の負荷抑制しながらテスト自動化を実現◎テスト自動化基盤にマネージドサービス活用
回帰テストの自動化を実現

手動で確認していたテストが、気がつけば終わっている状態になった

自動化環境の運用負荷抑制

テストコード以外はほぼ気にしなくてよくなった◎マネージドサービス利用コスト

毎日1回テスト実行(5分)、テストコード・レポートなどそれぞれ月
10GB以下すると、5USD/月以下(マネージドサービスそれぞれ月1USD未満)△テストコードの実装負荷が高め

36©2019 Mitsubishi Electric Corporation

IoTシステム開発
リグレッションテスト自動化

製品開発
移行

IoTシステム開発
受け入れテスト自動化
Webシステム開発
テスト管理との統合

2017

2018

2019
37
©2019 Mitsubishi Electric Corporation

IoTシステム開発
受け入れテスト自動化
開発背景など38©2019 Mitsubishi Electric Corporation

背景

IoTシステムの開発で受け入れテスト自動化検討
開発についてIoTシステムのクラウド側開発

本開発ではAWS (Amazon Web Services)を利用

製外実装による、リリースを複数回に区切った反復開発
機器依存でクラウド側の状態・応答が複雑に変化するため、テスト手順が複雑・手動実施負荷が高い
受け入れテストの自動化検討を担当(2人)
機能(API)テスト部分

テスト対象
クラウド

PC、スマートフォンなど
IoTシステムイメージ

機器、センサーなど
39©2019 Mitsubishi Electric Corporation

背景

複数組織またいだメンバで開発実施
開発体制
人：事業場所(設計・受入テスト), 研究所(テスト自動化設計),
製外(実装・テスト)
場所：遠隔
指示

研究所
IoTシステム開発（クラウド）

事業本部
支援

Dev(Prd)

受け入れ

発注

実装

製外

IoTシステム開発（機器）
IoTシステム開発（アプリ）40©2019 Mitsubishi Electric Corporation

IoTシステム開発
受け入れテスト自動化
自動化内容

41
©2019 Mitsubishi Electric Corporation

課題と解決アプローチ

マネージドサービス利用で自動化負荷軽減

基本的に同じアプローチで実施

開発側に合わせて実装はPython, フレームワークも合わせる
要件

実現方式

・API模擬
・成否判定

ドメイン
特有

・BDD

・・・

テスト
汎用領域

テストフレームワーク
pytest-bdd

・自動実行/トリガー・サーバ管理

CI/CD
汎用領域

自動化基盤
AWSマネージドサービス

・・・

・・・

[*] CI：継続的インテグレーション

テスト自動化システム

テストコ実装Python(+Pytest)

42
CD：継続的デリバリー ©2019 Mitsubishi Electric Corporation

課題と解決アプローチ

マネージドサービス利用で自動化負荷軽減

基本的に同じアプローチで実施

開発側に合わせて実装はPython,
フレームワークも合わせる
pytest-bdd

要件
実現方式
 Pythonで利用可能なBDDライブラリ Pytestのプラグインなので、レポート出力のpytest-htmlや、並列テストのテスト自動化システム
・API模擬ドメイン
pytest-xdistとそのまま連携可能
・成否判定
特有
テストコ実装 CucumberのJSON形式レポートを出力することが可能
Python(+Pytest)

・BDD

・・・

https://github.com/pytest-dev/pytest-bdd

・・・

テスト
汎用領域

テストフレームワーク
pytest-bdd

・自動実行/トリガー・サーバ管理

CI/CD
汎用領域

自動化基盤
AWSマネージドサービス

・・・[*] CI：継続的インテグレーション

43
CD：継続的デリバリー ©2019 Mitsubishi Electric Corporation

実施内容

ビルドサーバ内で機器シミュレータも実行
システム全体構成

テスト自動実行

テスト環境

Internet
自動テスト用AWS環境AWSCodeBuild

テスト自動実行ビルドサーバAWS
CodeCommit

ペアプロ的に
テスト実装

S3

API
テスト
実行

ソースコード(テスト)

クライアント模擬テストシナリオ
定義

応答検証

API

ステップ関数定義

API呼び出し

要求・応答
データ(json)

AWS連携
ビルド定義

機器
シミュレータ実行

実行ログ

CodeBuild

テスト結果(html)

HTTPS

機器模擬
機器シミュ
レータ

MQTT
機器ログ

S3

HTML形式で結果確認
44©2019 Mitsubishi Electric Corporation

効果とまとめ～40分

複雑なテスト手順も自動化により効率化◎テスト自動化基盤にマネージドサービス活用
自動化基盤は前例そのまま活用で効率的に導入時はペアプロでのテストコード実装でスムーズにチーム内展開△テストケース追加時の負荷がそれなりにある
要求・応答用データの作成に手間がかかる
複数人でステップ追加していくと、重複部分が増えていく△非機能試験にそのままスケールしない
ビルドサーバ(コンテナ)内でクライアント・機器すべて模擬△エラー解析に時間がかかる
クライアント・機器模擬など疎結合で改善しやすい反面、ログ分析が面倒45©2019 Mitsubishi Electric Corporation

IoTシステム開発
リグレッションテスト自動化

製品開発
移行
IoTシステム開発
受け入れテスト自動化

Webシステム開発
テスト管理との統合

2017

2018

2019
46
©2019 Mitsubishi Electric Corporation

Webシステム開発
テスト管理との統合
開発背景など47©2019 Mitsubishi Electric Corporation

背景

Webシステムのプロト開発でテスト自動化検討
開発についてデータ可視化・分析関連のWebシステム

本開発ではAWS (Amazon Web Services)を利用

研究所内に閉じた、リリースを複数回に区切った反復開発
自由度高くツール／サービス利用可能

テスト自動化とテスト管理との統合検討を担当
機能(API, GUI)テスト部分
研究所
プロト開発

テスト対象

クラウド
PC、スマートフォンなど
Webシステムイメージ48©2019 Mitsubishi Electric Corporation

Webシステム開発
テスト管理との統合
実施内容

49©2019 Mitsubishi Electric Corporation

課題と解決アプローチ

自動テストとプロジェクト管理ツールの統合

自動テストは同じアプローチ、テスト管理にJIRA利用
テスト結果のシームレスな管理を目指す
要件

プロセス統合実現方式

プロジェクト管理

JIRA (server)

テスト管理

Xray

テスト自動化システム

ドメイン特有テストコ-ドPython (+Pytest)

テスト汎用領域

テストフレームワーク

pytest-bdd

CI/CD汎用領域

自動化基盤

AWSマネージドサービス

50©2019 Mitsubishi Electric Corporation

課題と解決アプローチ

自動テストとプロジェクト管理ツールの統合

テスト管理ツール

自動テストは同じアプローチ、テスト管理にJIRA利用
 検討当時はJIRA Server版にしかXray対応してなかった
テスト結果のシームレスな管理を目指す⇒ 現在はCloud版でも利用可能な模様
要件
実現方式

プロセス統合プロジェクト管理

JIRA (server)

テスト管理

Xray

https://marketplace.atlassian.com/apps/1211769/xray-test-management-for-jira?hosting=cloud&tab=overview

 CucumberがSmartBearに買収された(2019/6)ので、今後はZephyrも注目？

テスト自動化システム

ドメイン特有テストコ-ドPython (+Pytest)

テスト汎用領域

テストフレームワーク

pytest-bdd

CI/CD汎用領域https://cucumber.io/blog/news/cucumber-acquired-by-smartbear/
自動化基盤
AWSマネージドサービス

51©2019 Mitsubishi Electric Corporation

実施内容

テスト結果を自動で集計、トレーサビリティ確保
システム全体構成
IP固定
(EIP)

Internet
GUI/APIテスト
自動実行

テスト自動化VPC
NAT
gateway

自動起動・
自動停止

ビルドサーバ

CodeBuild
ソースコード(テスト)

ビルドサーバからREST APIでテスト結果(*.json)を自動送信
プロジェクト管理用環境
VPC

Webシステム(テスト対象)

IP制限

EC2

ALB
WAF

テスト結果
（HTML）S3

JIRA

Route 53

テスト管理画面

ソースコード（アプリ）

テストケース作成・
コード(.feature)出力
テスト結果、カバレッジ、
要件トレーサビリティ確認など

52©2019 Mitsubishi Electric Corporation

実施内容
テスト管理との統合ポイント

テスト結果管理・集計の負荷を削減
画面例

要件(ストーリー)

対応するテスト内容

テスト結果※画面は発表用のサンプル

53©2019 Mitsubishi Electric Corporation

効果とまとめ

要件に紐づいたテスト状況を管理可能に◎テスト自動化基盤にマネージドサービス活用
自動化基盤は前例そのまま活用で効率的にテスト自動化とプロジェクト管理を統合、テスト管理の負荷を削減△プロジェクト管理サーバの管理負荷
Cloud版のJIRA+Xrayなど利用すれば負荷削減できるかも△プロジェクト管理の設定、テスト管理連携の設定・管理負荷色々できる反面、設定項目も多くて少し煩雑

現在も試行錯誤中…
54©2019 Mitsubishi Electric Corporation

事例全体
今後の課題

55
©2019 Mitsubishi Electric Corporation

今後の課題～50分

継続的テストを実現していきたい

自動化対象

機器含めたE2Eテスト、非機能テストの自動化

導入時

テストコード実装負荷

プロジェクト計画時にテスト自動化のコストも意識

保守／展開時テスト・テスト対象複雑化によるエラー発生時の解析難化
非同期のテストなど
テストでもAPMやログ分析などモニタリング技術との連携

テスト自動化基盤の運用ルール・ガバナンス

自動化基盤自体のログは？セキュリティは？……
自動化担当者まかせでいいの？

使われない・保守されなくなることもというわけで、後半に続きます56©2019 Mitsubishi Electric Corporation

継続的テストへの課題
57©2019 Mitsubishi Electric Corporation

継続的テストとは？

様々なテスト観点をまとめたもの

明確な定義はないが、以下の３つを含んだ考え方
Automated/CI：
開発環境の変化をトリガーとして実行され、他の開発プロセスに組み込まれる

Plan

Code

Build

Test

DeployRelease Operate※独立して追加されるものではない

Shift-right：
本番環境上でのテスト

A/Bテスト、カナリアテスト…
カオスエンジニアリング

Release

動くものをテストしながら反復開発
非機能要件も早い段階でテスト

CodeShift-left：
より上流工程でのテスト

58©2019 Mitsubishi Electric Corporation

話の流れ
課題の分類観点を抽出
取り組みから
世の中の状況から

網羅的にはならずとも、
ある程度俯瞰的に見たい

分類観点のまとめ
課題検討
継続的テスト実現に向けてすべきこと

59©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
取り組みからプロト開発以降で活用されない、横展開されない
サービス開発内で継続的に実施されない
サービス／事業を跨いだ組織的な展開ができない
何が起こってる？

継続性×

事業
サービス／プロダクト

使われない

PoC

Dev(Prd)

使われない

Ops

自動化
共有されないサービス／プロダクト

使われなくなる
組織展開×

共有されない事業

60©2019 Mitsubishi Electric Corporation

本発表における継続的テスト
Automated/CI：
開発環境の変化をトリガーとして実行され、他の開発プロセスに組み込まれる

Plan

Code

Build

Test

DeployRelease Operate※独立して追加されるものではない

Shift-left：
より上流工程でのテスト

CodeShift-right：
本番環境上でのテスト

Release

動くものをテストしながら反復開発
非機能要件も早い段階でテスト

A/Bテスト、カナリアテスト…
カオスエンジニアリング

Transmitted：
横展開可能なテスト

Transmitted
61©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
取り組みからサービス開発のための仕組み・規程整備が必要
既存のHW製造プロセス・体制そのまま継承してしまっている

ドメインごとの知識・技術で局所最適化されてきており、共通的な情報システム技術を取り扱うためのリソースが圧倒的に不足
事業

何が原因？

サービス／プロダクト

縦割り組織⇒人・環境が違う、サイクルになってない

PoC

Dev(Prd)Ops

領域以外のスキル不足、
共通組織リソース不足
サービス／プロダクト事業

セキュリティ／コスト
要件違う、そのまま使えないと使わない

お金の出どころが違うと、技術提供しにくい政治的な問題

62©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
取り組みからサービス開発のための仕組み拡張／整備が必要
既存のHW製造プロセス・体制そのまま継承してしまっている

ドメインごとの知識・技術で最適化されてきており、共通的な情報システム技術を取り扱うためのリソースが圧倒的に不足

組織体制・規程だけの問題？
事業 何が原因？
縦割り組織⇒人・環境が違う、サイクルになってない
具体的に何？
サービス／プロダクト
Ops
PoC
Dev(Prd)⇒継続性・組織展開の観点を
領域以外のスキル不足、
共通組織リソース不足
もう少し掘り下げてみる
サービス／プロダクト事業

セキュリティ／コスト
要件違う、そのまま使えないと使わない

お金の出どころが違うと、技術提供しにくい政治的な問題

63©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から

DevOpsの文脈でも組織へのスケールがポイント
４つの柱
・コラボレーション
・アフィニティ・ツール
・スケーリング
Jennifer Davis, Ryn Daniels, Effective DevOps,(https://www.oreilly.co.jp/books/9784873118352/)

ジーン・キム,ケビン・ベア,ジョージ・スパッフォード ,The DevOps 逆転だ! 究極の継続的デリバリー ,(https://shop.nikkeibp.co.jp/front/commodity/0000/P85350/)

3つの道
・フローの加速・素早いフィードバック
・実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ること

ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス ,The DevOps ハンドブック 理論・原則・実践のすべて,(https://shop.nikkeibp.co.jp/front/commodity/0000/P85480/)64©2019 Mitsubishi Electric Corporation

世の中の状況から課題の分類観点抽出
継続性：DevOpsのプラクティスから65©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から

DevOpsと関連要素の相関モデル(1)
心理的安全文化変更プロセス
明確化
鈍重な
変更プロセス－－

バーンアウト－
継続的
デリバリー

コード保守性モニタリング
パフォーマンス観点のモデル

クラウド

可用性
災害復旧テスト
自動デプロイ疎結合
アーキテクチャトランクベース
開発

SWデリバリーと運用
パフォーマンス
SWデリバリー
パフォーマンス

組織
パフォーマンス

継続的
インテグレーション
自動テスト

凡例：

構成要素
目的
相関

－ 負の相関参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

66©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から

DevOpsと関連要素の相関モデル(1)State of DevOps Report
組織
心理的安全文化
パフォーマンス
変更プロセス
 当該レポート作成しているDORA(DevOps Research and Assessment)は、
SWデリバリーと運用－
バーンアウト明確化2018/12にGoogleが買収している
パフォーマンス
鈍重なSWデリバリークラウド－
変更プロセス
パフォーマンス－
継続的デリバリー
コード保守性

災害復旧テスト
自動デプロイ疎結合
アーキテクチャトランクベース
開発

可用性

モニタリング

継続的
インテグレーション

自動テスト
https://www.devops-research.com/dora-joins-google-cloud.html

凡例：

構成要素
目的
相関

－ 負の相関参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

67©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から

DevOpsと関連要素の相関モデル(2)
心理的安全文化変更プロセス
明確化
鈍重な
変更プロセス

使いやすさ
コード保守性
疎結合
アーキテクチャトランクベース開発－

バーンアウト

社内情報共有－外部情報活用 －

技術負債

－

－

ワークリカバリー
クラウド

可用性

継続的
デリバリー
－

SWデリバリーと運用
パフォーマンス －SWデリバリー
パフォーマンス

組織
パフォーマンス－

モニタリング
生産性観点のモデル

生産性
自動デプロイ
継続的インテグレーション
自動テスト

災害復旧テスト
凡例：

構成要素
目的
相関

－ 負の相関参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

68©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から

プロセス内の自動化は前提、どう連携するかが重要
DevOpsパフォーマンス別の自動化・インテグレーションプラクティス
Low

Medium

High

Elite

自動ビルド

64%

81%

91%

92%

自動ユニットテスト

57%

66%

84%

87%

自動受入テスト

28%

38%

48%

58%

自動性能テスト

18%

23%

18%

28%

15%

28%

25%

31%

39%

54%

68%

72%

17%

38%

60%

69%

29%

33%

24%

69%

本番環境モニタリング統合 13%

23%

41%

57%

上記以外

14%

5%

4%

チャットツールやチャット 自動セキュリティテスト
ボットと、自動化環境
テスト環境自動構築
を連携
自動デプロイ(本番環境)
チャット統合本番環境監視ツール
や可視化ツールと、自動化環境を連携

9%

参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

69©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から自動化だけではなく複数要素の考慮必要
プロセス統合変更プロセス
明確化

－
情報共有

鈍重な
変更プロセス

社内情報共有
－

技術保守性
使いやすさ

バーンアウト
－

継続的
デリバリー

コード保守性
疎結合
アーキテクチャトランクベース
開発

組織
パフォーマンス

心理的安全文化

可観測性
モニタリングSWデリバリーと運用
各要素は技術プラクティスなどであり、
パフォーマンス
課題分類観点とするには粒度細かいので、
SWデリバリー
今回は、２つのモデルの各要素に対して、
クラウド
パフォーマンス
このように分類してみた
可用性
自動化／効率性

災害復旧テスト

自動デプロイ
継続的インテグレーション

ココだけ見てもダメ

自動テスト
分類観点

参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

70©2019 Mitsubishi Electric Corporation

世の中の状況から課題の分類観点抽出
組織展開：DevOpsの戦略から

71©2019 Mitsubishi Electric Corporation

課題の分類観点を抽出：
世の中の状況から実践的なスキル習得やリソース確保の観点も重要
DevOpsパフォーマンス別のスケーリング戦略

リソース不足、継続サポートの負荷理論と実践の断絶、排他的な専門家

Low

Medium

High

Elite

トレーニングセンター

27%

21%

18%

14%

COE (研究所)

34%

34%

20%

24%

PoCプロジェクト

41%

32%

20%

16%

PoC as Template

16%

29%

29%

30%

PoC as a Seed

21%

24%

29%

30%

24%

51%

47%

57%

19%

19%

11%

9%

ボトムアップ活動

29%

39%

46%

46%

マッシュアップ

46%

42%

34%

38%

より実践的にスキル習得 実践的なコミュニティ
できているかに差がある
ビックバン (トップダウン)
失敗要因

戦略・リソース不足
参考：
Dr. Nicole Forsgren, Dr. Dustin Smith, Jez Humble, Jessie Frazelle, “Accelerate: State of DevOps 2019”, (https://cloud.google.com/devops/)

72©2019 Mitsubishi Electric Corporation

分類観点のまとめ

73©2019 Mitsubishi Electric Corporation

分類観点のまとめ
自動化／効率性マニュアル作業をいかに減らせるか

可観測性

本番環境からの迅速なフィードバックが
可能か

規程整備

目的に合った規程が整備されているか

プロセス統合プロセス間に無駄な作業がないか

技術保守性

他の人がすぐ使える技術か
変更しやすいかリソース

十分な人材・期間・金が確保可能か

情報共有

ナレッジを迅速に共有可能か

スキル習得

迅速・実践的なスキル習得が可能か

単一組織内での継続性に関連組織展開に関連

複合的で重なっているところ多そうだが、ひとまず今回はこれをベースに課題掘り下げてみる

74©2019 Mitsubishi Electric Corporation

課題検討

75
©2019 Mitsubishi Electric Corporation

課題検討
規程整備

プロセス統合自動化／効率性

サービス開発にあった組織体制・規程になってない
継続性・開発/変更管理時の、プロセス間の必要成果(outcome)自動化非対応→自動出力した試験レポートをそのまま成果とできない、そもそも自動でバージョン
管理されていても別途成果物として出力が必要→承認したというアウトプットが必要／会議での承認が必要だったりと、チャットボット
連携した承認フロー自動化など難しい→一時的なPoCプロジェクト形態で、開発・本番環境間での自動化・連携が困難

組織展開
・必要成果、承認フローは規程・規則として定められている→チームレベルで変更不可／例外的・一時的な措置としてのみ許可→このフローを前提とした運用外部委託、継続的／横展開が困難
76©2019 Mitsubishi Electric Corporation

課題検討
規程整備

プロセス統合自動化／効率性製造業とプロセス規程
具体化
input⇒[プロセス]⇒output⇒[outcome]⇒input⇒[プロセス]⇒…
・開発/変更管理時の、プロセス間の必要成果(outcome)自動化非対応
例：[単体試験]⇒試験結果(データ)⇒[単体試験成績書⇒レビュー]⇒…
・必要成果、承認フローは規程・規則として定められている
 HW製造では、法律・規約⇒…⇒HW を遵守するために細かにドキュメント化・承認フローを実施、効率化のために分業・縦割りで最適化
 製造過程に入ってしまってからの手戻りは致命的なため、プロセスの必要成果に問題がないかを、手動ベースの多重チェックで保証・管理してきた• 管理責任は開発チーム外、外部の人間が理解できる形に落とし込む必要 プロセスを厳格に守らせるために、必要成果・承認形態を規程・規則として定め、それに沿った組織体制に• 抜け漏れなく・作成手間を省けるように、様式化⇒手動作成が前提• 人・環境が異なると、コア技術以外の暗黙知も毎回明文化する必要
過剰に厳格、管理責任がチーム外に存在
77©2019 Mitsubishi Electric Corporation

課題検討
技術保守性

スキル習得

リソース

サービス／事業ごとに要件が異なり展開しにくい
事業コア技術外のスキル不足、共通技術支援のリソース不足
組織展開
・事業所ごとの要件をすべて取り入れた標準化は困難→ツール・技術の標準化・提供は、提供側での保守が前提のため誰もやりたがらない→HW製造では事業ごとに一から十まで標準化／ガイドライン化してきている→継続的なサポート体制の構築にはリソース不足
・事業ごとに自動化⇒要件違う部分が疎結合にできてない⇒横展開できない→クラウド／オンプレ、OSS利用、独自作りこみ、有償ツールのライセンス費用…
・自動化技術者と、テスト実行・実装・保守担当が異なる→自動化導入に伴うスキル習得をコストと捉えられてしまう→使い方の明文化を求められる⇒提供側のコスト
・縦割りの組織体制による分業・マルチタスクで、スキル習得する余裕がない→サービス／プロダクトごとの機能実現に対する検討で手一杯→プロセス改善のためのタスクとして自動化の優先度下げられてしまう
78©2019 Mitsubishi Electric Corporation

課題検討
技術保守性

スキル習得

リソース

サービス／事業ごとに要件異なり展開しにくい
Googleの事例
事業コア技術外のスキル不足、共通技術支援のリソース不足

 トランクベース開発＆社内共有、他チームからの改善・コミット
組織展開
 定期的なリファクタリングによる技術負債の軽減と、新メンバのスキル習得
・事業所ごとの要件をすべて取り入れた標準化は困難→ツール・技術の標準化・提供は、提供側での保守が前提のため誰もやりたがらない→HW製造では事業ごとに一から十まで標準化／ガイドライン化してきている→継続的なサポート体制の構築にはリソース不足
・事業ごとに自動化⇒要件違う部分が疎結合にできてない⇒横展開できない→クラウド／オンプレ、OSS利用、独自作りこみ、有償ツールのライセンス費用…
・自動化技術者と、テスト実行・実装・保守担当が異なる→自動化導入に伴うスキル習得をコストと捉えられてしまう→使い方の明文化を求められる⇒提供側のコスト
https://www.infoq.com/jp/news/2019/11/google-software・縦割りの組織体制による分業・マルチタスクで、スキル習得する余裕がない
engineering/?itm_source=infoq&itm_medium=popular_widget&itm_campaign=popular_content_list&itm_content=→サービス／プロダクトごとの機能実現に対する検討で手一杯→プロセス改善のためのタスクとして自動化の優先度下げられてしまう
79©2019 Mitsubishi Electric Corporation

課題検討
情報共有

可観測性

標準化や情報共有、事業ごとへの適用に時間がかかる運用からのフィードバックの仕組みがない
組織展開
・情報共有はしていても、要覧・ガイドラインの共有まで→全社共通の要覧・ガイドライン化には、関連事業ごとに確認必要で時間がかかる→疎結合になっておらず情報過多、ナレッジからの落とし込み・適用が難しい
・標準化に向けたコミュニティなどは数多くあるも、定期的な情報交換にとどまる→一緒になって実践的に取り組むためのリソース・場所・権限がない
継続性
・プロト開発などはその場限りの体制で、フィードバックの仕組みがない→研究所・横通しの組織へのフィードバックがない／遅い、高頻度の担当者配置
換えでカバーしている現状
・運用外部委託な組織体制で、本番稼働中のサービスに関する情報取得が困難→Shift-rightな、継続的改善を目的とした仕組みが考慮できてない(丸投げ)80©2019 Mitsubishi Electric Corporation

継続的テスト実現に向けてすべきこと

課題と1対1対応する解決策検討は難しそうだけど、何ができるか・すべきか考えてみる81©2019 Mitsubishi Electric Corporation

継続的テスト実現に向けて・開発/変更管理時の、プロセス間の必要成果(outcome)自動化非対応
・必要成果、承認フローは規程・規則として定められている
・運用外部委託な組織体制で、本番稼働中のサービスに関する情報取得が困難

・プロセス統合に向けた規程整備→小さく早く改善していくことを前提とした、開発プロセスOutcomeの整理・再定義→プロセスごとの承認者・管理責任者の整理・再定義→変更管理や構成管理、リリース管理の自動/軽量化

・継続的なサービス改善サイクルのための組織編制→運用時におけるトイル削減を成果とするような、各役割の評価制度の再定義
トップダウンによる変革必要・プロセス間の自動化→テスト結果レポート自動作成、承認フロー連携（チャット連携）、テスト管理連携
ボトムアップでもやっていけそう

82©2019 Mitsubishi Electric Corporation

継続的テスト実現に向けて・事業所ごとの要件をすべて取り入れた標準化は困難
・事業ごとに自動化⇒要件違う部分が疎結合にできてない⇒横展開できない
・自動化導入に伴うスキル習得をコストと捉えられてしまう・プロセス改善のためのタスクとして自動化の優先度下げられてしまう
・全社共通の要覧・ガイドライン化には、関連事業ごとに確認必要で時間がかかる・疎結合になっておらず情報過多、ナレッジからの落とし込み・適用が難しい

・仕様書・ドキュメントからコードベースの情報共有へ→自動化・コード化はコスト削減手段ではなく、コア技術であるとの文化醸成→当たり前に自動化コードを書ければ、費用対効果の悪化を抑制できる→コードベースなら既存のCIの仕組みで効率的に管理・統合可能・社内共有リポジトリによるコードベースの技術共有→基盤／ツール提供ではなくコードの共有→チーム外(各事業所)からの修正・コミットで継続的改善→リファクタリングによるスキル習得
ボトムアップでとりかかれそう83©2019 Mitsubishi Electric Corporation

継続的テスト実現に向けて・標準化に向けたコミュニティなどは数多くあるも、定期的な情報交換にとどまる
・プロト開発などはその場限りの体制で、フィードバックの仕組みがない

・より実践的なコミュニティ活性化に向けたLab環境の整備→パブリッククラウド活用、チーム内への展開から実施→活発な情報発信を促すための、参加・発言の敷居を下げる仕組み／文化醸成
・本番環境の可観測性を考慮したモニタリング技術→テストとAPM・サービス監視の統合、Shift-left→本番環境テストで、ビジネス判断を簡単にできるような仕組み、Shift-right
ボトムアップでとりかかれそう

今後も継続して活動・課題検討を進めていきます84©2019 Mitsubishi Electric Corporation

さいごに
85
©2019 Mitsubishi Electric Corporation

継続的テスト実現に向けて継続的なボトムアップ活動、トップダウンへ働きかけ
ボトムアップ・草の根活動から
組織全体展開のためには？

⇒事業サービス責任者に、成功体験を・ボトムアップ活動での成功前例づくり
・事業で失敗しないように、ボトムの段階でうまく失敗しいていく技術
・失敗をマイナスとしない評価観点の変革などが必要
86©2019 Mitsubishi Electric Corporation