「テスト自動化の８原則」を経営者はまず理解しろ！

３月１９日
システムテスト自動化カンファレンス2017

にいってきた！ので、その内容をメモメモ

---

■あいさつ・諸注意
・今回は、アーキテクチャ
・YAHOO　きおいちょうオフィスは写真厳禁

■快適・簡単・安心なアプリE2Eテストの実行環境
・自己紹介
・取り上げる話題：アプリE2EテストのUI環境
・アジャンダ（省略）

・ヤフーのアプリ開発について
　１００を超えるアプリ、ダウンロード　３億8千万超える
　開発体制：２０００名以上、サービスごとにチームが分離
　アジャイルスクラム導入しているところも

・アプリ開発テスト環境
　自動化進んでいる
　開発
　GITにコミット
　CI上で単体テスト＆ビルド
　社内アプリ配布サイトにデプロイ
　ダウンロードして手動テスト

　アプリキャット
　　E２Eテストを追加

・開発の背景
　E2Eテスト自動化に取り組んでいるところ
　　→テストケース開発
　　　CI連携に手が回らない
　　　Macを必要なだけおくことが出来ない、動かす稼動状況安定しない

　アプリE2Eテストの実行環境の整備大変
　　テスト対象のアプリのビルド　　　環境構築大変
　　テスト実行端末の起動・初期化　　初期化大変
　　テストスクリプト実行　　　　　　並列実行難しい
　　結果保存、プロジェクトに周知　　手作業だと忘れる

　気づき
　　アプリのE2Eテストの実行環境整備はサービスの開発と両立しない
　　実行環境は全社共通で整備したほうがいい

　→Applicat

　　ヤフーの規模で快適に使える
　　簡単にCIにつかがる

・特徴
　Appiumを採用
　並列実行可能

・自社開発を決めるまで
　クラウドサービスの利用検討
　　Sauce Labs
　　AWS Device ふぁーむ
　　Xamarin

　メリット
　　結果安定、スケール、スピード
　デメリット
　　社外にアプリを出す、クローズドなAPIが使えない
　→自社開発

　テストフレームワーク
　Appium（あぴーむ）
　OS標準（Expresso/XCUITEST)→ios
UIオートメーション、UIオートメーカー
　→仕様の安定性、抽象化

・Appiumでのテストをスケールさせる
　端末の排他制御・実行待ち・冗長構成がスケールさせるために足りない
　AppiumをスケールアウトさせるOSS
　　Selenium Grid
　　　複数のAppiumへのアクセスを振り分けるLBのようなもの
　　Selenium Grid　Router
　　　GridへのLB
　Grid/Grid Routerでは大規模な運用は難しい
　GridRouterとテスト実行がSPOF

　→フルスクラッチ

　キューとワーカーを使う

　テスト実行キュー
　　テスト実行をWork Queueで管理
　　　並列実行
　　　Workerを増やすことでスケールアウト可能へ

・安定したテスト実行のための工夫
　ビルド
　　社内標準のCIツール上でビルドされたバイナリでテストを実行

　ipaファイル　アプリとメタデータがZIPでまとめられたファイル
　　→テスト実行できない
　　→メタデータを置き換える：再署名
　　fastlaneのsighを利用

　端末の初期化
　　初期化ができていないとテスト結果がぶれる
　　実機のリセットは難しい
　　　全てのアプリを削除
　　　keyChainはアプリからしか消せない
　　iosのテスト前初期化用アプリ
　リトライ機能
　　テスト失敗時、同条件の別端末で再実行するリトライ
　デバイス監視
　　実機との接続が切れることがある
　　定期的にデバイスの接続を確認、接続切れたらアラート
　安定して実行されるように

・他にも・・
　ライブラリの提供
　　YAHOO JapanIDのログイン
　　ネットワーク設定
　ログイン機能
　　ほとんどのアプリで実装
　　テストケースにアノテーションを付けるだけで、ログイン状態に出来る

　ネットワーク設定機能
　　WebAPIリクエストのあて先を変える

　フレームワークの整備
　　テストの書き方のサポート
　　　PageObjectパターン
　　　適度なタイミングで画面遷移待ち

・まとめ

・最後に　募集してるよ

■Q&A
・かわったこと
　E２Eテストに取り組んでくれる人が増えた
・実機VSシミュレーター
　サービス側のニーズがあった（端末固有の問題）
・複数端末テスト
　まだ取り組めていない
・他のアプリに依存するケース
　将来的にできるようにしたい
・Grid Routerの限界
　Grid１０くらいにしておいたほうが・・
　Grid Router　１００くらい、ただし、SPOFのほうが問題
・エビデンスは
　アップロードして、参照できるように

---

■普通の開発ってなんだ？
・アンタだれ
・ナンデキタン？
・茶番（登壇に至るまで）
　２つの仕事をしている
　　　ふるぼっこされたり
　　　自動化したり
　→ひよる
・今日は自動化
　Gitサーバーにある：メンテしにくさ
　自動化の道具を使う
　　CI
　　Jenkins
　　Sonarqube
　　Slack連携
　　UnitTest→自動テスト
　顰蹙を買う
・つくりなおす
　Android
　フラットにおいてある
　作り直してもらう
　→DDDのレイヤードアーキテクチャ
　　MVP
・若年性Ststicおじさん
・これをしたい
　　CIやテスト
・仕事として成立する理由
　　バギー
　　技術的負債のあるコード品質
　新しく作る：
　　技術的負債を返上するチャンス：リプレイス・リメイク
　　　→長期化の兆しがあるとき
・なんでした？
　一般化してみると
　　不満が多い
　　やりにくい形を解消
　　結局同じ
　理由
　　時間的制約
　　育ってきた環境
　　作法
　　定石
　　過去の経緯
　　組織の壁

　プログラマーのパートナーの壁、専属、突然の指令、基準なき検査機関、バグ

　言い訳に強いコード

　シンゴジラ
　「ここではどう動いても人事査定には影響新バイから、自由に発言してかまわない」

　言い訳に津用コードを書いている感じがするなら
　　人系やプロセス疑ったほうが良いかもねー？
　　純然たる勉強不足もある

・普通の開発
　ソース
　　思想がある
　　設計がアル
　　FW選定
　　→出来る限りの虫食い問題にする
　環境
　　CI/CDがある（考慮がアル）
　　環境調達にある程度自由が利く
　プロセス
　　出来る限りノイズがある
　　よくわからない手続き承認がない
　　テストに理解がある
　　　書いても怒られない
　　変えていける
　人
　　教育不要
　　苦手克服

・機能追加が修正の能力が１と感じたら１である
　開発の後半には、新規機能の追加はラクになっている

・ちょっとまて、それは理想の現場？

Q&A
　いくつぐらい、普通の現場？
　１つ。あるはある

---

■テスト自動化システム　成長記
　継続的に運用するために何をしてきたか？

・アジャンダ

・自動テストを継続していくときの障害
　コスト
　環境の維持
　人に依存

・テスト自動化サービス（Lynx)とは
　自動テストを実施するうえで必要なことを全て代行

・誕生
　Selenium WebDriver
　テスト内容：GUITest
　　シナリオテスト
　Selenium Grid
　　シナリオテスト：回帰テスト
　　機能テスト

・２０１３年ｔ月
　顧客増えた、スクリプト増えた、バージョンアップが頻繁
　重複するコーディングが多い
　共通関数記化、テンプレート化

　毎回同じ・・・自動化エンジン
　パターン、都度違う→Excel

・アーキテクチャ
　　Jenkins
　　エクセル
　エンジニア・テスターでの作業を分離できた

・対応
　config対応
　　Excel→スクリプトは作成できても、時間は変わらない
　DDT
　結果送信：テスト通知
　レスポンスタイム測定
　ダッシュボードの作成・報告書の廃止
　オフショア

・アーキテクチャ
　AWS上に構築
　任意に実行可能

・規模感
　対応キーワード：４３種類
　テストステップ数　８万ステップ
　エラー発生数　１０件以上
　バグ発見数　約１～２件／月

・OpenCVを使って画像認識をして押している

・今後の課題

■Q&A
・IDが動的に変わる場合
　　変わらないでいいところを見つけ、それでいいですか？
　　自動化しやすい提案

・ご検知とチューニング
　チューニング sleepをいれる
　slackで報告
　→タイムアウトが多い

・AWSってパフォーマンス安定しないよね
　で、レスポンスの取り方？
　→情報収集中

・オフショア
　テストラボを外に持っていった
　ダナンは日本語読める
　日本側に残さないと、技術のこらない

---

■テスト自動化８原則

１．手動テストはなくならない
２．手動でおこなって効果のないテストを自動化しても無駄である
３．自動化テストは書いたことしかテストしない
４．テスト自動化の効用はコスト削減だけではない
５．自動テストシステムの開発は継続的に行うものである
６．自動化検討はプロジェクト所期から
７．自動テストで新種のバグが見つかることはまれである
８．テスト結果分析という新たなタスクが生まれる

※テスト自動化研究会のサイトに出ている

・策定の経緯

・こんなことありましたか？
　全てのテストを自動化しようとして苦闘した
　自動化すればコストは減るはずだ
　自動化したもののメンテナンスが大変

・テスト自動化の８原則
　経営者はまず理解しろ！

・手動テストはなくならない
　自動化できないもの
　ROI的に割に合わないよね
　最初の1回は手でやったほうがいい
　あんなに自動化好きなGoogleは１０％～２０％は手動
　ケースを作るのは手動
　　テスト実行とレポートが自動化できる
　　テスト観点を与えてあげれば自動化できるけど

・手動で行っても効果のないテストを自動化しても無駄である
　GIGO
　手動で効果のないテストを行っている組織に明日はない

・自動テストは書いたことしかテストしない
　自動化されたテストは視野が狭くなる
　　→質はがたおちになる
　つまんないテスト：枯れたテストを自動化する

・テスト自動化の効用はコスト削減だけではない
　そもそも、コスト削減のハードルは高い
　バグの改修速度が上がった
　デリバリーを早める：製品の進化の速度があがる
　あき時間の活用
　銀行：影響管理分析をしないでCICDを行った

・自動テストシステムの開発は継続的に行うものである
　一度にすべてを自動化できない→おそらくする必要もない
　構成管理も必要。継続管理。開発プラットフォームと思ったほうがいい

・自動化検討はプロジェクト初期から
　自動化されると思うと、コーディング規約も変わる
　あとからだとやりにくい：ID振るのに
　ツールをそろえる：グルーコードがふえる
　製品コードとあわせておいたほうが(ICSTでGoogleが）

・自動テストで新種のバグが見つかることはまれ
　基本的にデグレが見つかる
　自動テストはセイフティテスト
　殺虫剤のパラドクス：ソフトウェアテスト７原則

・テスト結果分析という新たなタスクが生まれる
　自動テストでフェイルがでたとき、あとで人間が確認
　自動化した場合、あとでまとめて大量に行うことになる
　　バグの種類は同じ：それをまとめる仕組みもいれないと
　結果分析が負担にならない自動テストを考えなくてはならない

・つづきはまたいつか

■Q&A
・効果のあるないの判断
　～なったら～できる→に「こと」とつけるテスト
　同値分割のクラシフィケーション
・要求段階で自動化を決めたほういい
　遅くとも計画まで
・結果分析の自動化？
　自動化しないとスケールしない
・継続的システムテスト
・ファジングは新種のバグみつからない
　みつかるかも・・→「まれ」である
・自動化に向いたシナリオ
　正しく動作することは無理
・２００画面のテスト
　優先度次第
・テスト自動化のフェイルはインシデントでバグと決まったわけではない
　　→一次仕分けしていない

---

■機械学習を活用したテスト自動化システムの設計

・自己紹介

・今日のお話：Magic Podの概要

１．概要
　機械学習の技術を活用した自動テストWebサービス
　　ディープラーニング技術などを利用
　　現在はモバイルアプリ向けのみ
　これまでつくった数々のツールのノウハウを凝縮
　magic potから解明

・開発状況
　アルファユーザーテスト
　機能ギャップを埋めている

・最終目標
　人間向けの手動テストケースをAIが理解し自動実行
　多くはUI手動テスト→フォーカス

２．設計する
（非公開の予定）
・２．１　テスト実行エンジン
　捜査対象の指定範囲は何がいい
　　画像テンプレートマッチ　→画面変化に弱い
　　座標指定　→画面変化に弱い
　　システム情報で指定　→画面変化に強い
　システム情報指定の問題点
　　内部構造の理解
　　システム情報に外部からアクセスできない
　　見つからないときのエラー原因
　　開発者：システム情報のキープはあまり考えてくれない
　検索ボタン、名前入力エリア
　　→Magicロケーター findbyMagic

・要素技術
　見た目から特定→CNNのディープラーニングでTensorFlow,Chainer
　位置関係でラベル付け→Captioning　SVMで

　画像解析
　　１．領域分割
　　２．各領域をCNNにかけて物体認識
　　３．OCR
　　４．Captioning
　　２，３，４の結果をマージして表示

　１＆２が時代遅れ＆低速なので

・全体像
　２とおり
　　テスト実行時ロケーター計算方式
　　テスト作成時ロケーター計算方式

１．テスト実行時ロケーター計算方式
　画像解析
　選んでテスト作成
　Mocaテストコードに変換
　コマンドラインから実行、CIから実行
　実行時にサイド画像解析
　Appium要素計算
　Appium実行

２。テスト作成時ロケーター計算方式

　画像とUIツリー情報をアップロード
　画像解析＆ロケーター計算
　選んでテスト作成
　実行前にUIマップ
　そのままAppium実行

・改良
　物体認識ロジックのカイゼン
　UI操作をAppium非依存に
　内部で使用するロケーターをよりRobastに

２．２　スクリプトの生成
　キャプチャ＆リプレイ　サポートすべきか
　→画面のUIをサーバーにおいて作る
　問題
　　１つのUIが複数の画面状態
２．３　スクリプトの形式
　表形式
　プログラムコード
　→相互変換可能
　表形式からスクリプト：できている
　Sahagin　テストコードをASTに
　　Gebもやってきた
　あらゆるテストコードを表形式に？→できない

３．細かい機能デモ

---

■自動化アーキテクチャにまつわるスキル
1割くらいがオートメーター
AutomationtestSSF
・だれ　
　STAR(システムテスト自動化研究会）こみっター
・２０１５年アルファ版発表、β版の差分
・自動化アーキテクチャにまつわる箇所
・

・そもそもテスト自動化とは
　開発者より
　　バイナリを作る前
　テスターより
　　繰り返し操作、リソースを有効に
　ユーザー（運用）より
　　受け入れチェック
　→現場ごとに範囲、種類異なる
　　学習すべきことが変わる
　　AutomationTest.SSF（スキル標準フレームワーク）

・何が嬉しいの
　現場の人が学習するための指標を作れるようにする

・想定使用方法

・全体像
　テスト自動化戦略の策定
　テスト自動化システムの開発
　自動テストケースの開発・実行
　テスト自動化関連の管理

　テスト自動化システム
　　自動化戦略で考えること
　　テスト自動化システム
　テストケース　　　モニタリング
　SUI I/F　　　　　　駆動　判定　レポート
　　　　　　　　　　初期化・あとしまつ
　　　　ユースケース

　アルファ版

・再検討して

　β版：めちゃ増えてる

・テスト自動化アーキテクチャ
　　そもそもアーキテクチャとは　IEEE1471の定義

　ソフトウェアシステムアーキテクチャ構築の原理
　３つのスキル
　　技術的スキル
　　ビジネスの知識（ドメイン知識）
　　ソフトスキル
　　　→情報キャプチャ、促進、交渉、コミュニケーション、柔軟性

　テスト自動化アーキテクチャ共通の特徴
　　継続的に運用
　　つなぎ方・つなぐシステムが変わる

　テストプロセスとの関連
　　テスト設計→自動化
　　テスト実装
　　テスト実行
　　テスト報告

　分け方・つなぎ方

・SSFの解説に入る前に
　２つの想定ロールを定義
　　テスト自動化マネージャー
　　テスト自動化エンジニア
　※兼任も可

・システム関連の管理
　上手くテスト自動化すすめること
　計画の策定：見積もり
　教育：開発、実行、運用、スキル把握
　保守：構成・変更管理
　テストベース：前提資料全部
　効果の予測と測定：KPIの設定・測定
　　　→　数字でものを言う／複数のインジケーター／自動記録・収集
　フィードバックサイクルの構築・実施
　テスト技術戦略の策定：テスト技術の蓄積（体系化、規格・RFC)

・テスト自動化戦略の策定
　ライフサイクルと戦略をまとめる
　テスト戦略の分析：目的、要求、自動化できるテストの識別、効果予測
　要件定義：テスト自動化要件の調査、制約の調査、他の手段、まとめる
　状況把握：開発プロセスの状況把握、テスト対象の理解、
　スコープの設定：範囲の設定、徹底度、粒度
　開発プロセス：
　ツールの選定：使用ツール、連携ツール、フィージビリティ（制約、スケール）
　テスト対象、プロセス管理：変更点の識別

・テスト自動化システムの開発
　システム作ること
　設計：アーキテクチャ、実行プロセス、自作部品、運用ルール、容易性向上
　実装：作る、既存のものの変更、連携、環境構築
　検証・妥当性確認

・自動テストケース
　実行する部分なので、みなさんあとで確認してください。

・まとめ

・今後の展望
　微調整
　パイロット利用
　レビュー
　パブリックコメント
　公開