Agileとテスト自動化導入の勘所
Dec 7, 2018
Ayana Yoshida, Kotaro Ogino
Rakuten, Inc.

JaSST’ 18 Tokyoのクロージングパネルから始まるAIとQAの話は

JaSST’18 Tokyo レポート
http://www.jasst.jp/symposium/jasst18tokyo/report.html

2018/11/13 アクセス

アジャイル

テスト自動化当たり前検索2

本日お持ち帰りいただきたいこと3本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

4

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

5

① おさらい6

① おさらい・アジャイルとは何か？
・アジャイルでのテスト自動化の役割
7

アジャイルとテスト自動化のおさらい: バリューストリームマッピング

8アジャイルとテスト自動化のおさらい: バリューストリームマッピング

9アジャイルとテスト自動化のおさらい:アジャイルとは何か？

10アジャイルとテスト自動化のおさらい:アジャイルとは何か？

11アジャイルとテスト自動化のおさらい:アジャイルとは何か？

顧客の要望を
知り

価値を
提供する

モノづくりをし12アジャイルとテスト自動化のおさらい:アジャイルとは何か？

・顧客の要望を知り・モノづくりをし・価値を提供する

13

アジャイルとテスト自動化のおさらい:アジャイルとは何か？

・顧客の要望を知り・モノづくりをし・価値を提供する
ソフトウェア開発に共通
14

アジャイルとテスト自動化のおさらい:アジャイルとは何か？

・顧客の要望を知り・モノづくりをし・価値を提供する
ソフトウェア開発に共通

・少しずつ✖ ・素早くアジャイルの特徴
15

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

16

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

17アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

18

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

顧客に価値を少しずつ届ける

顧客に価値を素早く届ける19

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

顧客に価値を少しずつ届ける

顧客に価値を素早く届ける
20

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

顧客に価値を少しずつ届ける

少しずつフィードバック

素早く
フィードバック

顧客に価値を素早く届ける21

アジャイルとテスト自動化のおさらい:アジャイルとは何か？（少しずつ、素早く）

顧客に価値を少しずつ届ける

顧客に価値をチームにフィードバックを少しずつフィードバック

素早く
フィードバック

顧客に価値を素早く届ける22

アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

役割

顧客に価値を少しずつ・素早く届ける

チームにフィードバックを少しずつ・素早く届ける

アジャイルのプラクティス

•
•
•
•
•
•

スクラム
ユーザーストーリーマッピング
リーンスタートアップ
スクラム
テスト駆動開発
継続的インテグレーション• 継続的デリバリー

23

アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

役割

顧客に価値を少しずつ・素早く届ける

チームにフィードバックを少しずつ・素早く届ける

アジャイルのプラクティス

•
•
•
•
•
•
•
•
•

スクラム
ユーザーストーリーマッピング
リーンスタートアップ
スクラム
テスト駆動開発
継続的インテグレーション→テスト自動化！
継続的デリバリー→テスト自動化！
24

アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

顧客に価値を少しずつ届ける

少しずつフィードバック

素早く
フィードバック

顧客に価値を素早く届ける25

アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

少しずつフィードバック

素早く
フィードバック
26アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

テスト自動化でフィードバックを作る

少しずつフィードバック

素早く
フィードバック27アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

28

アジャイルとテスト自動化のおさらい:アジャイルにおけるテスト自動化の役割

少しずつ、素早くチームにフィードバックするための仕組み

29

まとめ①
① おさらい・アジャイルとは何か？
・アジャイルでのテスト自動化の役割
30

まとめ①
① おさらい・アジャイルとは何か？
→少しずつ、素早く・アジャイルでのテスト自動化の役割→チームにフィードバック

31本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）③ 導入事例（技術面）

32

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）③ 導入事例（技術面）

33

② 導入の勘所

34

② 導入の勘所・新しいアイデア導入のTips

35

導入の勘所：36

導入の勘所：

ここまで見てきて良いことづくめのアジャイルとテスト自動化ですが、

37

導入の勘所：新しいアイデアの導入には障壁がある

38

導入の勘所：新しいアイデアの導入には障壁がある

新しいアイデアの導入では一般的に・チームに経験者がいないこと
・周りに仲間がいないこと
・もともとあるルールなどが障壁にアジャイル・テスト自動化の導入でもこれらは障壁に成りうる
39

導入の勘所：障壁をテスト自動化の例で考えると

40

導入の勘所：障壁をテスト自動化の例で考えると

41

導入の勘所：障壁をテスト自動化の例で考えるとテスト自動化を導入したい！

42

導入の勘所：障壁をテスト自動化の例で考えるとテスト自動化を導入したい！

自動化経験のある
エンジニアがいない

43

導入の勘所：障壁をテスト自動化の例で考えるとテスト自動化を導入したい！

自動化経験のある
エンジニアがいない

他の部署の周りに自動化の仲間を増やしたり仲間がいない44

導入の勘所：障壁をテスト自動化の例で考えるともともと別のルールやプロセスがある

テスト自動化を導入したい！

自動化経験のある
エンジニアがいない

他の部署の周りに自動化の仲間を増やしたり仲間がいない45

導入の勘所：新しいアイデアの導入には障壁がある

46

導入の勘所：新しいアイデアの導入には障壁がある

障壁がある場合
どうすれば乗り越えられるのか？

47

導入の勘所：新しいアイデアを組織に導入するための教科書

48

導入の勘所：新しいアイデアを組織に導入するための教科書

川口恭伸 監修 木村卓央, 高江洲睦, 高橋一貴 訳

吉羽龍太郎、原田騎郎 訳

2014年01月, 丸善出版

2017年01月, 技術評論社

49

導入の勘所： Fearless Change

50

導入の勘所： Fearless Change

知ってもらう・勉強会(25)
・著名人を招く(27)・トークン(42)

仲間を増やす・コネクター(8)・相談できる同志(39)

説得する・達人を味方に(14)“48のパターンのチートシートを作りました”
http://kawaguti.hateblo.jp/entry/20140228/1393522489
2018/11/13 アクセス・将軍の耳元でささやく(48)・経営層の支持者(28)51導入の勘所： Fearless ChangeからのTips

52

導入の勘所： Fearless ChangeからのTips

新しいアイデアを導入するには・知ってもらう・仲間を増やす・説得するなどの啓蒙活動が重要になる
53

導入の勘所： 変革の軌跡の付録”楽天のDevOpsエンジニアのストーリー”

54

導入の勘所： 変革の軌跡の付録”楽天のDevOpsエンジニアのストーリー”

55

導入の勘所： 変革の軌跡の付録”楽天のDevOpsエンジニアのストーリー”

自動化など
の技術面

勉強会や
研修などの文化面
56

導入の勘所： 変革の軌跡からのTips

57

導入の勘所： 変革の軌跡からのTips

新しいアイデアを導入するには
・文化面
・技術面
両面からの活動が重要になる

58

ということで、、、

59

ということで、、、① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

60

ということで、、、① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

本日の残り時間は、文化面と技術面での導入事例のお話をします

61

まとめ②
② 導入の勘所・新しいアイデア導入のTips

62

まとめ②
② 導入の勘所・新しいアイデア導入のTips→仲間を増やす、説得するなど→文化面、技術面の両面から
63

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

64

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

65

③ 導入事例（文化面）

66

・組織を変える啓蒙活動③ 導入事例（文化面）

67

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む
4. XXは後からついてくる682018 エンジニアでもない私が達成したこと

DevOpsTraining
Program69

DevOps研修の成果を表す数字たち

DevOps Training
Program

20
30 人以上の技術/知識を持つエンジニアに講師を依頼
400 名以上が研修に参加 (東京/札幌/仙台/大阪)
個以上の研修を約半年間で作成

70Tech Confの成果を示す数字たち

70 以上のスピーカーが集結
1802000 以上の参加者

以上の楽天エンジニアがボランティアで活躍(東京/札幌/仙台/大阪/名古屋/仙台/中国/シンガポール/インド/アメリカ)

71

ここに至るまでの3年間

2015後半2016前半2016後半TECH HR英語研修担当
TOEIC/英会話レッスンの運営

2017前半2017後半2018

DevOps研修 企画運営
Tech Conf 2018 企画運営

アジャイルやテスト自動化、それ以外にも何か新しいことを皆さんの組織に取り入れたいときの参考になることを祈りつつ、
この間、どのように業務内容や組織を変えて来たかをお話します。72

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む
4. XXは後からついてくる73

2016 - 小さなことからやってみた

2015後半2016前半2016後半2017前半2017後半2018

Tech Conf 初ボランティアスタッフ
ヨガセッションを企画運営
セキュリティーの部署の研修運営をお手伝い
74このとき大事にしてたこと

コラボ精神
セキュリティー研修
自分にできることを考えた• HRオペレーションの提供• HRデータの提供/管理

ヨガセッション
自分が巻き込める人を考えた• インストラクター• ドリンクスポンサー• 空間デザイン(アロマ)

1:1のコラボレーションから
複数のコラボレーションへ75

コラボを見た周囲の反応「なんか盛り上がってるね！」「楽しそうだね！」「クオリティー高いね！」→ やりがいを感じる
76

DevOps研修ができるまで１

2015後半2016前半2016後半2017前半2017後半2018

テクニカルスキル研修の部署ができ、協力・情報交換するようになる→ やりたいことが明確になる
77

DevOps研修ができるまで２

2015後半2016前半2016後半2017前半2017後半2018

テクニカルスキル研修の部署に異動→ エンジニアとコラボして研修を作成するスタイルが確立
78

DevOps研修ができるまで３

2015後半2016前半2016後半2017前半2017後半2018

DevOps研修担当になる (Docker, テスト自動化, 継続的デリバリー, インフラデザインパターンの研修を企画運営)
Docker研修時にはミートアップも開催→

外部にも盛り上がりが広がり始める
79

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む
4. XXは後からついてくる80

DevOps研修ができるまで4

たくさん開発できたものの、参加者アンケート結果はイマイチ…

よりよい研修を目指して2018年、研修計画を立て直す！
2018Q1作成の報告書資料より抜粋

社員が求めていたのは最新のトピックとハンズオンに加えて、楽天での事例/使用方法
クラウド研修• パブリッククラウドのスキル• 社内でのクラウド使用方法

研修内容/参加対象者の細分化
81DevOps研修ができるまで5
やるべきことを決めたものの・・・

ハードルだらけ！

楽天での事例/使用方法

社内講師(または社内を知る講師)が必要

クラウド研修社内にクラウド7種類

研修内容/参加対象者の細分化

細分化により研修数増加

20以上

の
研修作成

研修プログラムの組織編成
トレーニングチーム

プログラム責任者

Programming

Security

Big Data

トレーナー

研修作成者は2,3名
通常、3〜6ヶ月かけて1つの研修を作成する

一体何年かかる!???

AI

82

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む
4. XXは後からついてくる832017年DevOps研修プログラム組織編成

他のプログラムよりも多くの人を巻き込み３ヶ月で４つ作成
研修プログラムの組織編成
トレーニングチーム

プログラム責任者

Programming2017 DevOps研修プログラムの組織編成

トレーニングチーム
吉田プログラム責任者
荻野

Security

Big Data

AI

ポイント１
どの研修も企画会議を運営

社内トレーナー
6名

社外トレーナー
３名

ポイント２
トレーナーがひとりぼっちじゃない84

2018年DevOps研修プログラム組織編成

さらに多くの人を巻き込み半年で20個作成
トレーニングチーム
吉田

社内トレーナー
31名

Infrastructure
Design Pattern

CI

CD

Chef

プログラム責任者
荻野+1名

Monitoring

社外トレーナー7名

ポイント１
相方も増やした

ポイント２
社外の方ともコラボ

Test Automation

Docker3 private cloud
2 Public Cloudポイント３
もちろんぼっちじゃない

2 EC platform85

2018年DevOps研修プログラム

継続的
デリバリー
継続的インテグレーションCI

インフラデザインパターン

テスト
自動化

モニタリングCD
Docker2 パブリッククラウド
2 EC プラッ
トフォーム

Chef
3 プライベートクラウド
86

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む
4. XXは後からついてくる87

後からついてきたもの１

組織変更• HRが扱う研修範囲の変化• 他部署とのコラボ• 社外講師とのコラボ• トレーナー30名体制
88

後からついてきたもの２

人望• 研修依頼の増加• 質問/依頼の増加• この人とやればできると言われることが増えた• 他のことも一緒にやるようになった• 何やら大きい話が入ってくるようになった89

導入事例(文化面)

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む4. 組織変更・人望は後からついてくる90振り返ってみてやってきたことをまとめてみたらFearless Change
でした…！

91

実はこんなことをしていました 1/4

組織全体から理解を得るために(マネージャーレベル)
TECHの組織編成
カンパニー
CTO

アピールした！

Tech
Division

達人を味方に(14)CIO

役員

DevOps研修
担当役員

種をまく(22)
将軍の耳元でささやく(48)

経営層の支持者(28)マネージャー
エンジニア

相方を作った！
コネクター(8)達人のレビュー(31)
相談できる同志(39)92実はこんなことをしていました2/4

組織全体から理解を得るために(エンジニアレベル)
TECHの組織編成
カンパニー
CTO

マーケティングした！

Tech
Division
CIO

役員

マネージャー
エンジニア

DevOps研修
担当役員

電子フォーラム(10)トークン(42)

イベントやった！
勉強会(25)
著名人を招く(27)93マーケティング事例

Facebookはもちろんこまめに投稿→↓あらゆるコミュニケーションツールを駆使
社内掲示板, Viber, Yammer, Hipchat, Slack, …

94

イベント事例

GoogleCloud
onBoardDocker Meetup

Test Meetup

https://dockerjp.connpass.com/event/68798/
2018/11/23 アクセス95

実はこんなことをしていました 3/4

たくさんの人を巻き込むために飲みに誘いまくった！
みんなを巻き込む(33)
恐れは無用(46)
何か食べながら(9)
協力を求める(6)グループのアイデンティティ(13)ミーティングより深い話
トレーナー同志も繋がる96

実はこんなことをしていました 4/4

巻き込まれた人たちがやりがいを感じられるように仕組みを作った！
やってみる(17)振り返りの時間(5)小さな成功(2)次のアクション(19)
体験談の共有(32)

企画/作成

他の研修の例を参考に改善
振り返り“やってみる”を促す
研修実施

参加者アンケート実施
他の研修や前回の結果と比較

97

NPSが信じられないくらい上がった事例*NPS＝参加者満足度を表す数値(-100から+100)

参加者の満足度はトレーナーの自信に不可欠とある研修で１回目と２回目の結果が大幅UP

70

80

60

93 UP!

40

20

-23

0
2018-04-02
-20

-40

2018-07-02

やったこと
1) 問題点の洗い出し
2) 他の研修のいい例を提案
3) 自部署対象にトライアル
4) 振り返りミーティング5) 改善点の洗い出し
98振り返ってみて

Fearless Change以外にも、まだあった！！

Fearless Change➕

•

Fearless Bulldozer
恐れ知らずのブルドーザー

99Fearless bulldozer 1/4

構わず突進• 返事なくてもまたメールする• チャットもする• 席にも行く• 定例設定＆毎回ファシリテート• 完成を待つだけじゃなく進捗を確認する• 問い合わせが熱そうならヒアリングを設定• 頼られたときは求めてる以上のサポートを
100

Fearless bulldozer 2/4

無邪気な無知• 知らないことを隠さない• たくさん質問して教えてもらう• でも自分が正しいと思えば意見も言う

101

Fearless bulldozer 3/4

相方絶対論• 陰口に負けない• 何か変えようとすると必ず抵抗勢力は現れると悟る• 抵抗勢力と戦うよりも味方を増やすことに力を入れる• 絶対的に信頼できる相方を作る• 自分にはまらない相手もはまることが多い• 自分への文句は相方にいくようになる• フォローしてくれるし後で教えてくれる ひとりで頑張るよりも頑張れる！
102

Fearless bulldozer 4/4 - Core
一番大事にしているのは、初心に返って、コラボ精神• １人でやるよりも複数でやる方が大きいことができる• たくさんのアイディアとたくさんのスキル• 同じタイプの人も違うタイプの人も• 興味を持ってくれたらとにかく誘ってみる そして、みんなにプラスになるようにやってみる103Technology Conferenceも同じ小さいことから始めていたら、組織変更や人望が後からついてきた

2015後半2016前半2016後半Tech Conf 初ボランティア
ヨガセッションを企画運営

2017前半2017後半

2018

全企画運営

アワードセレモニー企画運営
その他手伝えるところを積極的に手伝う1042018 Tech Conf x Fearless Bulldozer

いろいろやってみた！ たくさん巻き込んだ！

スタイリッシュな演出

参加者層の拡大

スタッフ層の拡大

参加型スタイルサテライト数の拡大
105導入事例(文化面)まとめ ー 恐れずにやってみて下さい！

恐れ知らずのブルドーザー改革
1. 小さなことからやってみる
2. やってみてダメなら変える
3. 巻き込めそうな人をどんどん巻き込む4. 組織変更や人望は後からついてくる+ Fearless Bulldozer

Fearless Change
構わず突進
無邪気な無知
相方絶対論
コラボ精神
106

まとめ③

・組織を変える啓蒙活動③ 導入事例（文化面）

107

まとめ③

・組織を変える啓蒙活動→構わず突進 →無邪気な無知→相方絶対論 →コラボ精神③ 導入事例（文化面）

108

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

109

本日お持ち帰りいただきたいこと① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

110

④ 導入事例（技術面）

111

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン④ 導入事例（技術面）

112

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

113

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

114

①検索基盤開発チームでのシステムテスト自動化

状況：スクラム/CIなどのアジャイル手法は導入済み

行動：①自動化専門チーム②テスト自動化コストの削減③開発とテストの協働

問題：システムテストで見つかった 結果：バグ修正日数が５日から２日にバグ修正の手戻り(5日)要因：システムテストを最後に実行
解決：継続的システムテスト

115

②ID基盤開発チームでのDevOps導入

状況：4拠点・100名以上の開発体制 行動：①セルフサービスQA環境

問題：結合バグが大量に発生
要因：個々のチームが独自に結合

解決：パイプラインの自動化②カバレッジ改善③スケーラブル開発環境

結果：結合バグの改善(3/週→1/週)
バグ修正日数の改善(10日→2日)

116

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

117

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

118導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック~

119導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック~

パイプライン（テスト）の自動化=リードタイムの改善（最短1日）

120

導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック~

パイプライン（テスト）の自動化=リードタイムの改善（最短1日）
頻繁なテストから設計へのフィードバック121導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック~

パイプライン（テスト）の自動化=リードタイムの改善（最短1日）
頻繁なテストから設計へのフィードバック

品質とリードタイムの改善
122

テスト自動化は頻繁なフィードバックを作る123

導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック①~

毎日システムテストを実行しているプロジェクトのバグカーブ

青線
毎日ソースコード変更が可能に

赤線
毎日バグが見つかる

124

導入事例（技術面）:導入事例の考察 ~頻繁なフィードバック②~

頻繁なフィードバックは
バグ修正期間を大幅に短縮する
特に欠陥特定期間が大幅に短縮

理由：
・ソースコード変更からテスト実行までの期間が短い（多くの場合1日）
・欠陥特定のための調査範囲を最小化することができる
125

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

126

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン

127アジャイル ✖ テスト自動化:テスト自動化の５つのパターン

128アジャイル ✖ テスト自動化:テスト自動化の５つのパターン

パターン
テスト自動化モジュールの設計はプロダクト設計とご一緒に
テスト自動化モジュールはプロジェクトメンバーにも使ってもらえるように

品質特性
保守性/テスト容易性

使用性

複数のテストを同時に実行しても大丈夫

平行性/独立性

テストスクリプトはパッと見で分かるように

習得性/保守性

何回実行しても同じテスト結果

信頼性/再現性
129

パターン①: テスト自動化モジュールの設計はプロダクト設計とご一緒に

状況：これから自動テストを導入する/外部から自動テストを導入した
問題：プロダクトの設計に自動テストが振り回される
要因：独立したシステムとして自動テストが設計されている
解決：プロダクトと自動テストを一つのシステムとみなす
行動：設計チームの統合とFeature Flagなどの実装
結果：テストの実装・実行が簡単に！
プロダクト
モジュール

一緒に設計！！
一緒に設計！

自動テスト
モジュール

システム

130

パターン① ：補足

システム

システム

プロダクト
モジュール

自動テスト
モジュール

設計チーム

設計チーム

システム

プロダクト
モジュール

自動テスト
モジュール

設計チーム

プロダクトから自動テスト設計を改善：ABテストなど
テストからプロダクト設計を改善：Feature Flagなど
131

パターン②:テスト自動化モジュールは、プロジェクトメンバーにも使ってもらえるように

状況：テストチームに自動テストを導入した
問題：自動テスト導入の効果がテストのコスト削減に限定
要因：プロジェクトメンバーから自動テストが実行不可能
解決：プロジェクトメンバーからも自動テストを実行可能に
行動：テスト実行とテストレポートUIの用意
結果：プロジェクト全体で生産性が改善！
プロダクト
モジュール

自動テスト
モジュール

プロジェクトメンバー
みんなが使えるように
PDM/PJM

開発

QA

132

パターン② : 補足

テスト環境構築のUI

テストレポート

自動テスト実行のUI

エンジニア以外でも誰でもテストが実行可能に

133

パターン③:複数のテストを同時に実行しても大丈夫

状況：結構な量のテストを自動化した
問題：複数のテストを同時に実行すると問題が起きる
要因：テストシナリオやテスト環境の独立性が担保されていない
解決：テストの独立性を担保する
行動：テストシナリオとテストデータの独立性
プロダクトモジュール
結果：テストを並列して実行可能に
テストシナリオ１

複数のテストシナリオを並列に実行可能に！

テストシナリオ２

自動テスト
モジュール

アプリケーションDB

テストシナリオ3
134

パターン③ ： 補足

135

パターン④:テストスクリプトはパッと見で分かるように

状況：結構な量のテストが自動化されている問題：テスト結果からバグを特定するのに時間がかかる
要因：テスト観点と条件がテストスクリプトからわかりにくい
解決：Behavior Driven Development(BDD)などの記述を採用する
行動：BDDの採用とテスト条件を明確に
結果：テスト結果の分析が簡単に！
キレイなテスト設計と自動テストは異なる？！

テストシナリオ：ログイン機能
事前条件設定：このテストシナリオ専用のテスト対象環境を構築する
アプリケーションとデータベースが正常に起動していなければテストをエラー終了する
ユーザAのパスワードをxxxで登録する
ユーザAがデータベースに登録されていなければテストをエラー終了する
テスト条件：
ユーザー名とパスワードを入力しログインボタンをクリック
実際値と期待値の比較：表示されるページのメッセージを期待値と比較する
事後操作：
ユーザAがデータベースに登録されていなければテストをエラー終了する
ユーザAを削除
テスト対象環境を廃棄
テスト条件：
テストケース番号 ユーザ名 パスワード 期待値
001
A
xxx
ログインできました
002
Ayyy
ユーザ名かパスワードが間違っています
003
B
xxx
ユーザ名かパスワードが間違っています
・・・

136

パタンーン④ :補足1(BDDで記述する)

シナリオ例：ログイン
テストシナリオ：ログイン機能
事前条件設定：ユーザーがシステムに登録されていること
テスト条件：
ユーザー名とパスワードを入力しログインボタンをクリック
実際値と期待値の比較：表示されるページのメッセージを期待値と比較する

BDDでの記述の例
Scenario：login
Given the user is registered in the system
When the user inputs username and password then clicks login button
Then the user should see the specific message on the screen
137パタンーン④ :補足2(テスト条件を明確に)

ログイン機能のテスト条件の例
If ( user is registered)
ソースコードif ( password is correct)change login status to logged inprint “ログインできました”
else
print “ユーザー名かパスワードが間違っています”
else
print “ユーザー名かパスワードが間違っています”

テストベース
テスト条件
テストスクリプト
テストベースから分析した
テスト条件を
テストスクリプトにそのまま記述する

テスト条件：
テストケース番号 ユーザ名 パスワード 期待値
001
A
xxx
ログインできました
002
Ayyy
ユーザ名かパスワードが間違っています
003
B
xxx
ユーザ名かパスワードが間違っています 138

パターン⑤:何回実行しても同じテスト結果

状況：結構な量のテストを自動化した問題：実行するたび異なる結果になるテストが存在する (Flaky Test)
要因：テストの実行のたびに、テスト環境に変更が加えられている
解決：テスト環境をクリーンに保つ
行動：前処理・後処理とエラー処理の自動化
結果：信頼出来るテスト結果！
テストシナリオ１
実行1

実行のたびに結果が異なると調査が大変

テストシナリオ1
実行2

自動テスト
モジュール

アプリケーションDB

テストシナリオ1
実行3
139

パターン⑤ ：補足

前処理
テストシナリオ：ログイン機能
事前条件設定：このテストシナリオ専用のテスト対象環境を構築する
テスト対象環境が正常に起動していなければテストをエラー終了する
ユーザAのパスワードをxxxで登録する
ユーザAがデータベースにテストをエラー終了する
テスト条件：
ユーザー名とパスワードを入力しログインボタンをクリック
実際値と期待値の比較：表示されるページのメッセージを期待値と比較する
エラー処理
前処理
事後操作：
ユーザAがデータベースに登録されていなければテストをエラー終了する
ユーザAを削除
テスト対象環境を廃棄
後処理

140

アジャイル ✖ テスト自動化:テスト自動化の５つのパターン

パターン
テスト自動化モジュールの設計はプロダクト設計とご一緒に
テスト自動化モジュールはプロジェクトメンバーにも使ってもらえるように

品質特性
保守性/テスト容易性

使用性

複数のテストを同時に実行しても大丈夫

平行性/独立性

テストスクリプトはパッと見で分かるように

習得性/保守性

何回実行しても同じテスト結果

信頼性/再現性141

まとめ④・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン④ 導入事例（技術面）

142

総まとめ

143

総まとめ
① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

144

総まとめ
① おさらい145

総まとめ① おさらい・アジャイルとは何か？
→少しずつ、素早く・アジャイルでのテスト自動化の役割→チームにフィードバック

146

総まとめ
② 導入の勘所147

総まとめ② 導入の勘所・新しいアイデア導入のTips→仲間を増やす、説得するなど→文化面、技術面の両面から
148

総まとめ

③ 導入事例（文化面）

149

総まとめ

・組織を変える啓蒙活動→構わず突進 →無邪気な無知→相方絶対論 →コラボ精神③ 導入事例（文化面）

150

総まとめ

④ 導入事例（技術面）

151

総まとめ

・テスト自動化の導入事例
・導入事例の考察
・テスト自動化の５つのパターン④ 導入事例（技術面）

152

総まとめ
① おさらい② 導入の勘所③ 導入事例（文化面）④ 導入事例（技術面）

153

155

なぜアジャイルとテスト自動化が”今“必要なのか？
156

JaSST’ Tokyo 18
基調講演

クロージングパネル“JaSST’18Tokyo_ご報告書(ご協賛)”より
JaSST’18 Tokyo レポート
http://www.jasst.jp/symposium/jasst18tokyo/report.html
2018/11/13 アクセス

157

JaSST’ Tokyo 18でのギャップ

・GoogleのJohn Miccoの基調講演の内容-(Agileの導入やテスト実行自動化は100%完了している前提)-数百万件〜数億件のテストが自動化されている世界で、テスト結果の確認を機械にやらせたい（自動化したい）

・会場質問から感じたギャップ-「本当に100%自動化されているのか？」と繰り返される質問に自動化しない言い訳を探しているように感じた・パネルディスカッションで伝えたかった事-Googleみたいな企業ではテスト実行の自動化は当たり前-テスト実行以外の領域の自動化に乗り出している
158

テスト自動化の対象領域
テストプロセスSpec/
Design

テスト
要求分析

テスト設計

テスト実装

テスト実行

テスト
終了作業

テスト
レポート

テスト結果
データベース

テストケース

現在の自動化対象
159

AIとQAのモデル: 仮定=“AI は素早くテスト設計やテスト結果を学習可能”
・触る
・持つ

・クリック
・文字入力

アクション
テスト

知識

学習

対象

学習

環境
・画像
・触覚

フィードバック

テスト対象

・応答
・エラー

環境

160

テスト自動化の対象領域
テストプロセスSpec/
Design

テスト
要求分析

テスト設計

テスト実装

テスト実行

テスト
終了作業

テスト
レポート

テスト結果
データベース

テストケース

現在の自動化対象
161

テスト自動化のメリット

現在の自動化・テスト実行の生産性向上-コスト削減-工数の削減-カバレッジ向上

162

“次のテスト自動化=テストでのAIの利用”の対象領域とフィードバック
テストプロセスSpec/
Design

テスト
要求分析

フィードバック

テスト設計

テストケース

次の自動化の対象領域

テスト実装

テスト実行

テスト
終了作業

テスト
レポート

テスト結果
データベース

現在の自動化対象 次の自動化の対象領域
163

テスト自動化のメリット

現在の自動化

次の自動化

・テスト実行の生産性向上 ・テスト設計の改善-コスト削減・テスト終了作業の改善-工数の削減⇒テストプロセスに-カバレッジ向上
フィードバックループを作ることで可能に164

“次のテスト自動化=テストでのAIの利用”の対象領域とフィードバック
テストプロセスSpec/
Design

テスト
要求分析

John Miccoさんの論文はここ

フィードバック

テスト設計

テストケース

次の自動化の対象領域

テスト実装

テスト実行

テスト
終了作業

テストケースやテスト結果の品質を向上したい

テスト
レポート

テスト結果
データベース

現在の自動化対象 次の自動化の対象領域
165

“次のテスト自動化=テストでのAIの利用”領域の事例
Microsofot: Visual Studio IntelliCode

Facebook: SapFix and Sapienz

・コードフォーマッターの自動化
・少しスマートな静的解析

・バグ修正の自動化

Visual Studio IntelliCode
https://visualstudio.microsoft.com/services/intellicode/
2018/11/13 アクセス

“Finding and fixing software bugs automatically with SapFix and Sapienz”
https://code.fb.com/developer-tools/finding-and-fixing-software-bugsautomatically-with-sapfix-and-sapienz/
2018/11/13 アクセス
166

”次のテスト自動化=テストでのAIの利用”の実施可能要件

・フィードバックループを可能にする
逐次的なテストプロセス

・テストケースとテスト結果コーパス構築を可能にする
テスト自動実行技術
・AI技術利用を促進する
AIとテスト技術に精通したエンジニア
167

自動化しないための言い訳を探している場合ではない！！
168

”次のテスト自動化=テストでのAIの利用”の実施可能要件

・フィードバックループを可能にする
逐次的なテストプロセス

アジャイル

・テストケースとテスト結果コーパス構築を可能にする
テスト自動実行技術

テスト自動化・AI技術利用を促進する
AIとテスト技術に精通したエンジニア
169