2018/9/28に開催されたDeveloperSummit関西での発表スライドです。 https://event.shoeisha.jp/devsumi/20180928

1. 2018年、テスト自動化の
「これまで」と「これから」

2. 石川達也
Codeer代表取締役
Windowsテスト自動化
ライブラリFriendly開発
Microsoft MVP 2014～
趣味はギターとOSSライブラリ作成
通常の開発
テスト自動化コンサル
社長業

3. 水野昇幸
ソリューションエンジニア
大規模プロジェクトでのシステム設計/テスト自動化
TOC/TOCfE
WARAI/JaSST北海道実行委員
InSTA2017/InSTA2018論文投稿

4. Windowsアプリを意のままに操作するためのライブラリ
弊社製品FriendlyはMicrosoft MVP Showcaseで2位になりました。
http://blogs.msdn.com/b/mvpawardprogram/archive/2014/11/04/mvp-showcase-winners.aspx
IPAの「先進的な設計・検証技術の適用事例報告書 2015年度版」に掲載。
http://www.ipa.go.jp/sec/reports/20151118.html

5. Test Assistant Pro
Code と Tool のシナジー効果！
あなたのプロジェクトに Just Fit！

6. 2018年
テスト自動化

7. ソフトウェアテストのニューノーマル ～テストの新たな常態・常識～ ベリサーブナビゲーション2018年3月号 辰巳敬三氏 より引用＋追記
2005 2010 201520001995
Linux
Windows3.1
WindowsNT
HTML/HTTP
WWW
Netscape
IEEE802.11
(WiFi)
Java
Internet
Explorer
J2EE
XML
Apache Software
Foundation
iPhone iPad
.NET Ruby on Rails
SOAP
Eclipse
Ajax
Hadoop
Android
OpenStack HTML5
Amazon
Yahoo
eBay
Google
Salseforce
SouceForge
LinkidIn
iTunes
Facebook
Flickr
Youtube
Twitter
Netflix
Spotify
Airbnb Uber
Bitcoin
LINE
Instagram
Pinterest
Slack
Snapchat
Booch法
オブジェクト指向
デザインパターン
UML
Software
Architecture
XP アスペクト指向
アジャイル宣言
JUnit
UML2.0
Scrum
TDD BDD
MicroServices
Continuous Integration
DevOps
Continuous Delivery
Hudson
GitHub
AWS Microsoft Azure
Jenkins
Docker
Kubernetes
Jenkins2.0
Pipeline Plugin
XRunner
WinRunner
LoadRunnner
by Mercury
Architecture-based
Testing
Agile Testing
Search-based
Testing Concolic Testing
Agile Testing
(Crispin&Gregory)
Continuous Testing
Chaos Engineering
(Netflix)
WebTest QuickTest
Software TestAutomation
(Fewster & Graham)
Selenium
Testing as a Service
Appium
Chaos Monkey(Netflix)
Sapienz
bugspots
Magic Pod
SapFix
Friendly
Sikuli Infer

8. // 2018年 色々なツールがあります。
AIも使えるし、もう簡単に自動化できる！

9. そんな話をしに来たわけではない！

10. そんな簡単にいくわけないやろ！
2018年、未だ銀の弾丸は発見されていない。
“柔軟”に”考え抜いて”
プロジェクトに “Just Fit” する
自動テストを”作らなければならない”！
でもその分”効果”を出すことはできます！
基本は実装

11. 2018年
テスト自動化
Winner & Loser

12. 「原理原則では・・・（現実と乖離）」
「自動にして、漏れがあったら誰が責任を取るんだ！」
「そんな時間ないですよ、ウチのシステムでは無理」
「単体テストは義務だから書いてます。
正直開発の足を引っ張る存在でしかないんですけどね。」
「とにかくスクショがいるんですよ」
「たまにエラー出てますけど修正する時間ないので放置してます」
「自動テスト？正直役にたってないですね」
※気持ちはわかるが闇が深い
// Loser

13. 「お、この作業は負荷高いなー。自動化でコスト下げれないかな？」
「ここは、ユニットテスト書くの難しいな。システムテストで叩いとこうか。」
「この部分はユニットテストこれだけあれば、
開発中のデグレードは防げるよね。
システムテストはリリース前に手動でやろう。
画面の詳細な表示もついでに見るしね。」
「ここは難しいけど、大事な機能だからシステムテストまで自動化しよう
プロダクトにテスト用の機能組み込んだら何とかなるよね。」
「自動テスト？十分な費用対効果でてるよ。」
// Winner

14. ・ビジネス的な視点
（自動化する目的が明確
・より良い成果を求めるチーム、キーパーソン
柔軟に貪欲に。
・全員で効果を体感しないと続かない。
（でないと手間増えただけになる
徹底的に“効果“にこだわる！
// この差は何？

15. 「原理原則では・・・（現実と乖離）」
「自動にして、漏れがあったら誰が責任を取るんだ！」
「そんな時間ないですよ、ウチのシステムでは無理」
「単体テストは義務だから書いてます。
正直開発の足を引っ張る存在でしかないんですけどね。」
「とにかくスクショがいるんですよ」
「たまにエラー出てますけど修正する時間ないので放置してます」
「自動テスト？正直役にたってないですね」
※気持ちはわかるが闇が深い
// Loser

16. 「原理原則では・・・（現実と乖離）」
「自動にして、漏れがあったら誰が責任を取るんだ！」
「そんな時間ないですよ、ウチのシステムでは無理」
「単体テストは義務だから書いてます。
正直開発の足を引っ張る存在でしかないんですけどね。」
「とにかくスクショがいるんですよ」
「たまにエラー出てますけど修正する時間ないので放置してます」
「自動テスト？正直役にたってないですね」
※気持ちはわかるが闇が深い
// Loser
隙を見て
原住民蜂起へ
↓
ロスト
テクノジー化
感覚的ROI
カバレッジ教
ガベージ自動化
割れ窓放置
⇒験担ぎへ

17. 現場でテスト自動化が行われない理由としては
コスト感と効果を感じない部分がある。
※いわば、感覚的なROIがあわない。
現状の手間
追加の手間
得られる
手間削減効果
そんな金と工数、何処からでるの？
＜対処システム自体がそもそも複雑＞
＜ツールにコストがかかる＞
＜実施のむずかしさに対処ができない＞
効果そんなにないでしょ？
＜効果感がない＞
// Loser - 感覚的ROIが合わない

18. // ROIを数値的に”試算”して共有する
試算しかできないが、（正直、正確ではない）
その過程で少なくとも目的は共有できる
項目 工数（人日）
テスト実装工数 +800 + 120 + 90 = 1010
調査設計 -20×10×2 = -400
実装 -20×10×2 = -400
不具合修正 -20×20×2 = -800
テスト工数 -300×3×2 = -1800
その後の緊急リリース -24×5 = -120
合計 -2510
実装者 20人
テスト担当者 20人
期間 1年×2
【試算に使った条件】
・自動テストは1回目開始前に大量に作成。
プロジェクト中にも追加、メンテは発生している。
・調査設計、実装工数は一人あたり10人日は削減できている。
・不具合修正はテストフェーズで見つかる不具合数とその後の
修正→周辺確認→場合によっては再修正の分を加味している。
・テストは手動ならリリースまでに全チェックは3回は実行していると考える。
自動化しているテストを手動でやるなら300人日は必要。
削減工数 : 試算上は2510人日削減
（バージョンアップリリース二回分で試算）
プロジェクトの規模

19. ・仕様変更によるメンテ工数は受け入れる
（やるなら覚悟決めて工数取っておく
・テスト失敗でリリースできなくてもテストを恨まない
（で済むテストを作っておく。
文句を言わず失敗した原因調査のコストを払う。
// Investmentも前向きに受け入れる

20. // テスト自動化パターン言語
テスト自動化パターン言語プロジェクト
http://kencolle.github.io/AutomationPatternLanguage/
求む!英雄
3分クッキング
インディジョーンズ
クラウドトーク
自動化ハイ
全体像を描く
ビッグバン
自動化
ついで症候群
建て増し旅館
皮をむく
ダッシュボード
まずは”効く”
ところから
皮もおいしく
信頼性バトル
テスト仕分け
ヤブ医者と
ブラックジャック
俺たち全員
ブラックジャック
アンチ
自動化
験担ぎ
もっと、
人間らしく
自動家を作る
テストだけとか
勿体無い!
原住民蜂起
文明の曙
強くて
ニューゲーム
割れ窓の
放置
自動化開始のためのパターン 自動化導入期のパターン 自動化定着、あるいは終焉のパターン
: アンチパターン
: グッドパターン
分割して
統治せよ
操作と
シナリオの分割
もっと○○
されるべき
サグラダ・
ファミリア
砂漠を緑に
ピンを
生やす
無限に
広がる夢
初期から
計画
素振り大事
うるさい人が
いなくなる
～始祖消滅
ゴミ山発生
GIGO

21. 2018年
価値あるテスト

22. 任意のタイミングである一定の品質を保証する
・開発中
・テスト/不具合修正フェーズ
・リリース
・運用中の急なバグFix
不具合発見とはちょっと違うんですよね
// 価値

23. それはテストを実装した分だけ。
“量” だって大事。
”実行速度”も大事。
もちろん何が実装されているか、
“把握”していることはもっと大事！
// ある一定の品質？
質×量

24. 単に実施するテストケースを増やせばよいという訳では
ないですが、世界的に考えるとGoogleやFacebookでは…
②Facebookのはなし＠ICST2018 Dulma Churchill氏
100人の開発、2週間のリリース、100万以上のユーザ
マニュアルプロセスはスケールしない、自動化が必要
10%のエンジニアが自動化している
420万の独立したテスト
1日あたり1億5000万のテスト実行数
※平均して各テストが毎日に35回実行される
// 世界的な状況
①Googleのはなし＠JaSST’18 Tokyo John Micco氏

25. ※ただし台数増やすと、複雑さは増し相応の運用コストは発生します。
そもそもテストケースも増えると運用コストは増える・・・。
不安定なテスト（最近はFlakyって言うらしい）が出てくれば
コストは跳ね上がる。これを抑え込めるかが勝負。
ものによっては失敗したらもう一回やる仕組みも入れています（ごめんなさい
数十台でオーケストレーション。
（ Windowアプリだし。案件的にもクラウド使えない。
数万件のテストが毎晩実行されて既存品質を守っています。
// Codeerのお客様でも

26. // 実行トリガ
短時間で終わるユニットテストだけの場合は
コミットのタイミングで全実行でよいが、
システムテスト込みで量が増えるとそうもいかない。
Googleなんかはコミットのタイミングで
依存関係を解析して必要なテストを実行しているらしい。
Codeerのお客様で多いのは、特定の時間＋必要に応じて開始ボタンで全実行。
もちろん、サーバーで全実行だけでなくローカルでも単品で実行します。

27. もちろん、ゴミのテストケースをいくら自動化しても意味ないです。
（自動テストケース数が評価基準なら…ｹﾞﾌﾝｹﾞﾌﾝ）
ガベージイン、ガベージアウト…
// ガベージ自動化
2020年までのすべての日付
購入人数1～100名まで
すべて確認できるように自動化しました！
入園予定日
チケット購入
購入人数
Webチケット購入画面
※休園日は選択
できません。
06月23日（金）
おとな 名 こども 名01 01

28. // 質を高める
“質” を高めるということは、「より役立つテストケースを増やす」
ということになります。
そのためには、次のようなものが必要です。
・テスト技法の活用
・テスト技法を活用できるテスト全体の設計
（テストスイートアーキテクチャ）
・そのテストを継続的に作成および
メンテできるプロセスの整備
・ツールによるえー感じの支援
テスト設計コンテスト：STUDIO IBURI資料より
http://aster.or.jp/business/contest/contest2017/pdf/presentation_studio_iburi.pdf
テストベース：機能⇒DFD参照モデル
<<ユーザ接点機能>>
演奏系操作をする
+ 異常値
<<機能共通>>
演奏準備をする
<<ユーザ接点機能>>
SE操作をする
+ 機能組合せ
<<ユーザ接点機能>>
検索をする
+ 機能組合せ
+ タイミング
<<ユーザ接点機能>>
予約をする
<<ユーザ接点機能>>
オーナー設定をする
+ 機能組合せ
+ 異常値
+ セキュリティ
<<機能共通>>
課金判定をする
+ 機能組合せ
+ 異常値
+ 互換性
+ 性能効率性
<<機能共通>>
曲間表示をする
+ フェールソフト
<<ストレージアクセス>>
<<ユーザ接点機能>>
バックアップをする
+ フェールソフト
<<制約有機能>>
<<IF接点機能>>
<<ユーザ接点機能>>
配信をする
+ フェールソフト
+ 使用性
+ セキュリティ
+ 機器組合せ
<<IF接点機能>>
営業状態判定をする
営業状態状態遷移>状態遷移
＜機能グループ＞コンテンツを使う
+ セキュリティ
+ 互換性
<<IF接点機能>>
録音、録画をする
+ 機能組合せ
+ 不具合確認
<<IF接点機能>>
<<ユーザ接点機能>>
開局操作をする
引下げ不具合分析>シーケンス図
＜機能グループ＞歌う
<<制約有機能>>
映像再生する
<<ユーザ接点機能>>
設置時設定をする
<<制約有機能>>
演奏をする
演奏状態遷移>状態遷移
<<IF接点機能>>
採点をする
<<IF接点機能>>
HDD障害の通知をする
+ 異常値
<<機能共通>>
カロリー表示をする
<<制約有機能>>
楽曲演奏する
+ 不具合確認
+ 信頼性
<<IF接点機能>>
プログラムを更新する
プログラム更新処理>アクティビティ図
+ 処理重ね : 処理重ね
+ タイミング : タイミング
<<制約有機能>>
コンテンツを使う+ 使用性
+ 処理重ね
+ タイミング
<<制約有機能>>
歌う
テストベース：機能外要求、記述されている気がかり事項
+ 機器組合せ
+ 周辺機器
外部機器互換
+ 移植性
新採点移植確認
+ セキュリティ
セキュリティ
+ 通信費
通信費確認
「＋」項目はパターン以外
で追加した品質要素となる
テスト要求モデル
（網羅ビュー）
①機能のテスト
②機能外要求のテスト

29. とは言え、少しづつ積み上げるしかない。
一気に作ることは難しい。
（無理に一気に作ると、不安定なテストが入り込みやすい。
しかし自動テストは積み上げができる。
既存システムでは日々の作業、リリース前作業を分析し
導入効果の高い部分からつけていく。
// 質×量
1
2
3
4
5
1
2
1
3
2
1
3
2
1ex
5
3ex
6
メンテナンスは必要。
増やすだけではなく
いらなくなったテストは捨てる。
必要に応じて強化、統合したりもする。
1ex

30. 2018年
効果を出すために

31. ・ツールの選定、作成
→Codeerでは
Windowsアプリ → Friendly
Web → Selenium
フレームワークはシステムテストではNunitが多い
・自動単体テスト、自動システムテスト、手動テストの分配
→ここは特にポイント。
・テスタビリティを上げるためのプロダクト側の設計
→単体テストはあたり前だが、システムテストでも
// プロジェクトごとに最適化
基本は・・・
プロジェクトごとにベストプラクティスを考えることが重要

32. テスト用に使いやすいインターフェイスを追加で作る
（組込み機器でテスト用にピンを使うところから命名）
・Webアプリ
→ JavaScript に仕込む(Seleniumから呼ぶ)
・.NetWindowsアプリ
→普通に実装(Friendlyから呼ぶ)
・Win32アプリ
→DLL公開関数(Friendlyから呼ぶ)
// ピンを出す
テスタビリティを上げるために
プロダクトに手を入れるのは
悪いことではないですよ。

33. 組込みだって、工夫次第では自動化で成果を出せる
// 柔軟な発想
現状の手間 実施するテスト 検出するバグ
あんまりバグが
見つからない
なぜ、組込みシステム における テスト および テスト自動化 は難しいのか
https://www.slideshare.net/NoriyukiMizuno/etwest2018

34. 組込みだって、工夫次第では自動化で成果を出せる
// 柔軟な発想
現状の手間 実施するテスト 検出するバグ
ツール
この部分
を強化
現状の手間 実施するテスト 検出するバグ
あんまりバグが
見つからない
ちょっとバグが
見つかるように

35. 組込みだって、工夫次第では自動化で成果を出せる
// 柔軟な発想
現状の手間 実施するテスト 検出するバグ
この部分
を強化
あんまりバグが
見つからない
現状の手間 実施するテスト 検出するバグ
さらにバグが
見つかるように
自動化＋
ツール

36. 組込みだって、工夫次第では自動化で成果を出せる
// 柔軟な発想
現状の手間 実施するテスト 検出するバグ
自動化＋
ツール
現状の手間 実施するテスト 検出するバグ
テストを見直して
バグをより発見へ
もっとバグが
見つかるように！

37. // ツールの分類
テストケース
データ要素
手順 期待結果
テストケース
データ要素
手順 期待結果
テストケース
データ要素
手順 期待結果
テストケース
データ要素
手順 期待結果
Control
（テスト対象制御）
Behavior
（対象のふるまい）
Report
（結果収集、報告）
Judge
（テスト結果判定）
Monitor
（テスト結果監視）
Test Scenario
Scheduler
テスト
データ
結果及び
データ
テスト
成績
テスト
成績
テスト
成績
テスト
成績
異常通知
異常、NG
発生時
Drive
（テスト駆動）
自動テストシナリオ
Test Scenario
SUT Layer
Tool Layer
テストケース仕様書
※システムテストの時
テスト
成績書
Generate
（データ生成）
Data Layer
参考：ET-WEST2014
組込み開発でのSWテスト自動化のライフサイクル

38. 対象のスコープを限定するっていうのは
通常のプロジェクトをやりきる上で非常に大事
当然、普通のプログラムでも。
なんにでも、どんだけ広い範囲のですか？
将来的にって、異世界に転生した後の話ですか？
結局なんでもできるは何にもできない。
「ネイティブなアセンブラ書いたらなんでもできるよ」
「キーとマウス入力をエミュレートしたら人間と同じことができるよ」
↑理論上は可能。2018年現実的に無理。
そんなん言ってる暇あったら
今のプロジェクトに合わせこんだらええねん。
綺麗にスリムに実装したら、それだけで拡張性あるわ。
// スコープを限定する

39. 【Friendlyもプロジェクトごとに最適化されたテストを作るために作られた】
ある日の石川は悩んでいた。
このアプリを自動でテストしたい。
でも、その時使っていたツールでは
「ここ」ってとこに限ってテスト作成ができない。
そのツールは確かに汎用的ではあるんだけど
それゆえ、制限が多すぎる。
別に世界中のアプリに通用しなくてもよくて
“このアプリだけ”でいいんだよ。
なんとかならんか？
// 最適化

40. 普通にプログラムするAPI使えたら
ゴリッゴリに操作できるよね。
確かにプロジェクトごとに
実装しないといけない部分は多いけど。
プログラミングスキルは必須だけど。
“でも意味あるものが作れる！成果が出せる！”
【Friendlyもプロジェクトごとに最適化されたテストを作るために作られた】
// 最適化

41. これをテスト作成ツールまで
プロジェクトごとに最適化するのが
TestAssistantProです。
興味ある人はこの後声かけてください。
懇親会も行きます。
// 最適化

42. 2018年現在、私の経験では、システムテストでも
自動化するにはプログラミングスキルが必須！
運用も含め”トラブル”は出て当たり前。
それを解決する力が必要。
高価なツールを買って評価チームに丸投げは逆に
安物買いの銭失いになる！
全員がそうである必要はないが、
最低一人はプログラムに詳しいメンバーが
自動化にかかわっている必要がある。
// プログラミングスキル

43. 例えば・・・
先日Codeerで受注した案件で作ったWindowsアプリは
単体テストのみ自動化した。
Friendlyは使ってない。（使いたかったけど
規模と仕様そしてプロダクトの設計から判断。
逆にレガシーアプリのテスト自動化依頼の場合は
単体テストはあきらめることがほとんど。
Friendlyで最上段から叩く。
目的はアプリを品質高く使える状態にしてリリースすること。
テスト自動化は手段なので、最適なものを選択すればよい。
// 目的と手段を間違わない

44. 2018年 今まさに顕著化している問題（そして今後も

45. まだまだ現役！
// 深刻なアプリケーション高齢化問題
Friendlyでのテストコンサル依頼は大部分これです

46. ・新しい機能をどんどん追加している
・組み合わせがあるからテスト量は雪だるま式に増える
・予算、人は増えない（むしろ減る場合もある
・今年はまだ余裕があっても（まだ新しいと思ってても）来年は？
・たとえリプレースしても古い機能を捨てれないことが多い
（つまり多機能
// 本当にまだまだご健在
機能 テスト量 人 予算

47. これは自動化しないと無理っしょ
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・

48. ご清聴ありがとうございました
“効果”を出すことにこだわって
皆さんのプロジェクトに
“Just Fit” する自動テストを
“工夫”して作り上げてください！