2014年9月 JaSST北海道

作る・流すだけじゃない！
テスト自動化を運用に乗せる為のもう一工夫

株式会社SHIFT 横田 真

AGENDA
1. 自己紹介

2. はじめに
3. 課題：作る・流すでは運用できないテスト自動化
4. 施策1：テストスクリプトのパーツ化
5. 施策2：テスト結果切り分け
6. 結び：成果・課題・今後の展望

2

AGENDA1.自己紹介2. はじめに
3. 課題：作る・流すでは運用できないテスト自動化

4. 施策1：テストスクリプトのパーツ化
5. 施策2：テスト結果切り分け
6. 結び：成果・課題・今後の展望

3

自己紹介
横田真
mail：makoto.yokota@shiftinc.jp
所属
株式会社SHIFT ソフトウェアテスト事業部
職務内容
機能テスト設計～シナリオテスト設計及びテスト実行管理を担当

会社概要
株式会社SHIFT

社名
本社〒 106-0041 東京都港区麻布台2-4-5 メソニック39MTビル12F

札幌〒 060-0001北海道札幌市中央区北1条西3丁目2井門札幌ビル8F

福岡〒 810-0001 福岡県福岡市中央区天神1-15-6綾杉ビル8F

インド・プネ

6F,Pride Icon, Mundhwa Bypass Road, Kharadi, Pune - 411014.

拠点

シンガポール 24 Peck Seah Street #04-03 Nehsons Building
従業員数
交通アクセス
電話番号

400名(2014年3月現在)

神谷町駅 1番出口より 徒歩5分
03-6809-1128(代表)FAX

03-6809-1197

URL

http://www.shiftinc.jp/

代表取締役
相談役

※契約社員・パート含む

丹下 大
加藤 隆哉

サイバード

海野 恵一

アクセンチュア 元代表

元代表

ミドクラ 代表取締役
スウィングバイ2020 代表取締役

SHIFTのテスト領域
プロジェクト管理・戦略
テスト管理・戦略
要求

デバッグ

テスト計画

要件定義

インス
ペク
ション

基本設計

詳細設計

システムテスト設計

デバッグ

結合テスト設計

単体テスト設計

デバッグ
デバッグ

コーディング

受入テスト

システムテスト実施

結合テスト実施

単体テスト実施

AGENDA
1. 自己紹介2.はじめに
3. 課題：作る・流すでは運用できないテスト自動化
4. 施策1：テストスクリプトのパーツ化
5. 施策2：テスト結果切り分け
6. 結び：成果・課題・今後の展望

7

2.はじめに：参画案件

統合型ECサイト構築パッケージ評価案件に参画中

E-Commerce(EC)のパッケージソフト
ECサイトの構築・運営業務をサポート※E-Comｍerce：電子商取引

8

2.はじめに：参画案件

統合型ECサイト構築パッケージ評価案件に参画中

バックエンド・フロントエンドのテスト全般（設計・実行・自動化）を担当⇒SeleniumIDEの自動テスト作成をご依頼頂き作業中

9はじめに：ソフトウェア開発の現状

短期間開発サイクルに対応したテスト実施を迫られている
開発

サイ
クル
リリース

最近の開発体制の特徴
・開発期間が短い
・複数案件が同時に進行
・機能数は増加10

2.はじめに：ソフトウェア開発の現状

短期間開発サイクルに対応したテスト実施を迫られている

最近の開発体制の特徴
・開発期間が短い
・複数案件が同時に進行
・機能数は増加

開発

サイ
クル
リリース

リリース

開発

開発

開発

開発

開発

短いサイクル短いサイクル短いサイクル

短いサイクル

短いサイクル

リリー
ス

リリー
ス

リリー
ス

11リリー
ス

2.はじめに：ソフトウェアテストの現状

テスト対象機能は増え続ける

前バージョンの機能も保証→ Version Up毎に対象機能は増える
VerUpで2機能追加された場合876543
2
10V1V2
現行機能

12V3
新機能

2.はじめに：ソフトウェアテストの現状

テスト対象機能は増え続ける

前バージョンの機能も保証→ Version Up毎に対象機能は増える
VerUpで2機能追加された場合876543
2
10V1V2
現行機能

13V3
新機能

2.はじめに：テスト工数の確保・テストの効率化手段

回帰テストを自動化してテスト工数を確保する

保守機能増加=回帰テスト工数増加⇒回帰テスト工数削減に向けて品質管理チームは『テスト自動化』を進めている

14

AGENDA
1. 自己紹介
2. はじめに

3.課題：作る・流すでは運用できない
テスト自動化
4．施策1：テストスクリプトのパーツ化

5．施策2：テスト結果切り分け
6．結び：成果・課題・今後の展望
15

3.作る・流すでは運用できないテスト自動化

3つのステップ：作成・運用・展開

・テストスクリプトを作成する→ 実装作業・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
16

3.作る・流すでは運用できないテスト自動化

3つのステップ：作成・運用・展開

・テストスクリプトを作成する→ 実装作業・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
17

3.作る・流すでは運用できないテスト自動化：手段

ツール：Selenium IDEで作業

・FirefoxのAddOn→ 環境構築が容易
・テストの記録、編集、デバッグを行う→ 技術習得面のイニシャルコスト低18

3.作る・流すでは運用できないテスト自動化：手段

Selenium IDE：Suiteファイル

Suiteファイル Caseファイルのリンク集
Caseファイル
Caseファイル
Caseファイル

19

3.作る・流すでは運用できないテスト自動化：手段

Selenium IDE：Caseファイル

Caseファイル テストスクリプトが記載

20

3.作る・流すでは運用できないテスト自動化：シナリオ

今回自動化したシナリオ概要

初期設定

商品作成
購入
受注・配送
シナリオ例

他にも・・・
会員登録・変更
決済方法
ポイント利用購入
クーポン
ユーザランク割引⇒400本のテストシナリオ
21

3.作る・流すでは運用できないテスト自動化：3つのステップ

3つのステップ：作成・運用・展開

・テストスクリプトを作成する→ 実装作業達 成・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
22

3.作る・流すでは運用できないテスト自動化：2つめのステップ

3つのステップ：作成・運用・展開

・テストスクリプトを作成する→ 実装作業達 成・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
23

3.作る・流すでは運用できないテスト自動化：実導入

実導入

実際にテスト実行してみましたが・・・

24

3.作る・流すでは運用できないテスト自動化：スピード不足

開発サイクルのスピード・テストスクリプトメンテナンスのスピード25

3.作る・流すでは運用できないテスト自動化：スピード不足

開発サイクルのスピード ＞メンテスピード・結果切り分け

開発サイクルにテストサイクルが追い付かない26

3.作る・流すでは運用できないテスト自動化：課題1

メンテナンス工数の不足

・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足

27

3.作る・流すでは運用できないテスト自動化：課題2

メンテナンス工数の不足

・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
28

3.作る・流すでは運用できないテスト自動化：対応課題の決定

解決すべき課題・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる⇒課題を解決し運用に乗せる
29

AGENDA
1. 自己紹介

2. はじめに
3. 課題：作る・流すでは運用できないテスト自動化

4.施策1：テストスクリプトの共通パーツ化
5. 施策2：テスト結果切り分け
6. 結び：成果・課題・今後の展望

30

4.施策1：テストスクリプトの共通パーツ化

解決すべき課題・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
31

4.施策1：テストスクリプトの共通パーツ化

解決すべき課題・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
32

4.施策1：テストスクリプトの共通パーツ化

共通パーツ化

共通パーツ化？

33

4.施策1：テストスクリプトの共通パーツ化

施策前のシナリオ状態

初期設定

初期設定

初期設定

商品情報取得 商品情報取得 商品情報取得
購入(SMP)

購入(PC)

購入(携帯)

受注・配送

受注・配送

受注・配送

34

4.施策1：テストスクリプトの共通パーツ化

いくつかの処理に分けて考える

初期設定

初期設定

初期設定

商品情報取得 商品情報取得 商品情報取得
購入(SMP)

購入(PC)

購入(携帯)

受注・配送

受注・配送

受注・配送

35

4.施策1：テストスクリプトの共通パーツ化

同じ処理をしている個所を調査初期設定

初期設定

初期設定

商品情報取得 商品情報取得 商品情報取得
購入(SMP)

購入(PC)

購入(携帯)

受注・配送

受注・配送

受注・配送

36

4.施策1：テストスクリプトの共通パーツ化

共通パーツ化：パーツを他シナリオと共有・流用

初期設定
商品情報取得購入(SMP)

購入(PC)
受注・配送
37

購入(携帯)

4.施策1：テストスクリプトの共通パーツ化

実作業開始

共通パーツ化作業開始

38

4.施策1：テストスクリプトの共通パーツ化

重要な機能確認を行うシナリオに絞って実施

自動化済みのシナリオは400本→ 105本をまずは施策対象に

39

4.施策1：テストスクリプトの共通パーツ化

重要な機能確認を行うシナリオに絞って実施

自動化済みのシナリオは400本→ 105本をまずは施策対象に(選定基準)ボトルネックになる処理を多く含む
重要なシナリオ40

4.施策1：テストスクリプトの共通パーツ化

重要な機能確認を行うシナリオに絞って実施

自動化済みのシナリオは400本→ 105本をまずは施策対象に(選定基準)
ボトルネックになる処理を多く含む
重要なシナリオ→今後残りのシナリオでも再利用性の高い共通パーツが出来ると見込み
41

4.施策1：テストスクリプトの共通パーツ化

ECサイトで特に重要な機能・金額計算機能
小計・税金・割引計算
・フロントエンド～バックエンドのデータ連携機能
商品情報
ユーザランク
発注完了
42

4.施策1：テストスクリプトの共通パーツ化

機能を洗い出してから共通パーツ化作業を行う

・多くのシナリオで使用すると思われる機能を洗い出し・カテゴリーに分けたシナリオ内で共通する機能の洗い出し・環境(PC・スマートフォン)間の共通処理
43

4.施策1：テストスクリプトの共通パーツ化

共通パーツ化に向かない処理

・使用回数の少ない機能・可変IDが使用されている処理

44

4.施策1：テストスクリプトの共通パーツ化

共通パーツ化に向かない処理

・使用回数の少ない機能・可変IDが使用されている処理※可変ID
オブジェクトIDが画面内で動的に設定される構成
45

4.施策1：テストスクリプトの共通パーツ化

同じ処理をまとめ、パーツ化する機能を決定

1,672パーツ667パーツが同じ処理

46

4.施策1：テストスクリプトの共通パーツ化

実作業

共通パーツ化47

4.施策1：テストスクリプトの共通パーツ化

Selenium IDE：共通パーツファイル作成

CaseファイルaCaseファイルb
Caseファイルc48

4.施策1：テストスクリプトの共通パーツ化

Selenium IDE：共通パーツファイル作成

共通パーツaCaseファイルaCaseファイルb
Caseファイルc

共通パーツb
共通パーツc49

4.施策1：テストスクリプトの共通パーツ化

Selenium IDE：Suiteファイル変更

Suiteファイル Caseファイルのリンク集
CaseファイルaCaseファイルb
Caseファイルc50

4.施策1：テストスクリプトの共通パーツ化

Selenium IDE：Suiteファイル変更

Suiteファイル Caseファイルのリンク集
共通パーツaCaseファイルaCaseファイルb
Caseファイルc

共通パーツb
共通パーツc51

4.施策1：テストスクリプトの共通パーツ化

パーツ数を40%削減

1,672パーツ → 1,005パーツに削減
修正対象大幅削減→修正時間短縮→修正漏れ防止52

5.施策2：テスト結果切り分け

解決すべき課題・テストスクリプトのメンテナンス
機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
53

AGENDA
1. 株式会社SHIFT
2. はじめに
3. 課題：作る・流すでは運用できないテスト自動化
4. 施策1：テストスクリプトの共通パーツ化

5.施策2：テスト結果切り分け
6. 成果・課題・今後の展望
54

5.施策2：テスト結果切り分け

解決すべき課題・テストスクリプトのメンテナンス

解 決

機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
55

5.施策2：テスト結果切り分け

解決すべき課題・テストスクリプトのメンテナンス

解 決

機能追加・仕様変更→ スクリプト修正工数の不足
・テスト結果切り分け
機能不具合・スクリプトミス・環境要因→ 切り分けに時間が掛かる
56

5.施策2：テスト結果切り分け

テストスクリプトがエラーとなった個所をリスト化

テストスクリプトが止まる(エラーとなる)原因

・テストスクリプト起因のエラー・ソフトウェア起因のエラー→テスト実行者が判断できるもの
開発が調査しないと判断できないもの⇒過去実績を分析し、リスト化し開発チームと内容を協議
57

5.施策2：テスト結果切り分け

開発側とエラー発生時の対応切り分けの線引きをしておく

テスト実施者がどこまで判断するか定義→テスト実施者の調査時間短縮
開発担当者の切り分け時間短縮

58

5.施策2：テスト結果切り分け

フローチャートを準備し不具合切り分けをわかりやすく

59

AGENDA
1. 株式会社SHIFT

2. はじめに
3. 背景
4. テスト自動化へのステップ
5. 施策1：テストスクリプトのパーツ化
6. 施策2：テスト結果切り分け

7.成果・課題・今後の展望
60

7.成果・課題・今後の展望

成果：2つの施策で修正工数・切り分け工数圧縮

メンテナンス時間

617.成果・課題・今後の展望

成果：2つの施策で修正工数・切り分け工数圧縮

メンテナンス時間
55%圧縮／1シナリオ

62

7.成果・課題・今後の展望

成果：2つの施策で修正工数・切り分け工数圧縮

メンテナンス時間
55%圧縮／1シナリオ
9h×105本＝945h(≒6人月)→4h×105本＝420h(≒2.8人月)

63

7.成果・課題・今後の展望

展望：シナリオの拡張

・テストスクリプトを作成する→ 実装作業・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
64

7.成果・課題・今後の展望

展望：シナリオの拡張・テストスクリプトを作成する→ 実装作業達 成
達 成・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
65

7.成果・課題・今後の展望

展望1：シナリオの拡張・テストスクリプトを作成する→ 実装作業達 成達 成・テスト自動化を運用に乗せる→ 実行・メンテナンス・結果のフィードバック
・テストシナリオを展開する→ カバレッジの向上
66

7.成果・課題・今後の展望

展望2：WebDriver化

Selenium IDE → WebDriver
・携帯電話の実機での自動実行
・OSの違い・OSのVer.の違い・ブラウザの違い→シミュレータでは難しい確認ができる

67

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

68