システムテスト自動化カンファレンス2017-2 – connpassに行ってきました。

テスト自動化について普段あれこれ言っているわりには初参加でした。（毎年業務都合とかで行けなかった）

以下、当日のメモと感想です。

テスト自動化と機械学習（STAR機械学習分科会紹介） / 早川 隆治さん(STAR)

メモ

テスト自動化研究会の中の分科会の紹介

機械学習の利用が容易になってきたおかげで、テストやテスト自動化にも応用できそうになってきた。

  • 特徴抽出の壁
  • フレーム問題
  • シンボルグラウンディング

あたりが技術的に解決されてきた。

人工知能ブームは今第三のブーム。

今は学習用データが大量に手に入ることで、ディープラーニングができるように。

（一説によると）自動化にも第三の波が来ている。

  • 第一：ベンダーの自動テストツール
  • 第二：Seleniumを始めとするOSSツール
  • 第三：AIドリブン

機械学習をかじる→いろんなことに使ってみたくなる

  • エラーの重要度判定
  • エラーメッセージのグルーピング、類似バグ検索
  • 画面崩れ自動判定
  • 適切なユーザビリティからの逸脱検出

などなどなど。

研究会のワーキンググループに、AI詳しい方是非来てください。ゼロから作るDeep Learningを読んだりしています。

感想

画面崩れ自動判定は確かにできるととても嬉しいですね。自分が自動化業務をしていても、お客さんからの要望の多いところです。機械学習方面はさっぱり知らないままで来ていたのですが、このセッションを聞いたのをキッカケに本を１冊読んでいます。


人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)
Amazonで見る

翻訳者の同僚が語る「初めての自動テスト」 / 太田 健一郎さん(STAR)

メモ


初めての自動テスト ―Webシステムのための自動テスト基礎
Amazonで見る

この本は

  • マネージャ
  • テスター
  • 開発者

の３者に対してアプローチできる本。太田さんは特にマネージャに読んでみてほしい。

現実問題、テストのピラミッドが逆ピラミッドになりがち。よくない。

UIテストに寄って来がちなのは、ぱっと見でわかりやすいことが大きい。

「おお動く動く」と言って「自動テストですべてを網羅しよう」とかわけわからないことを言い始める。

統合テスト（APIテスト）は最近フォーカスされていることが多い。

作成が簡単なのでテスターに向いている、は疑問。

テスターはUIから統合まで見る。開発はUIと統合については強力しつつ、主に単体テストを行う。

テストスイートは生物

役割分担をしつつ、壁を作らない。

本書だと、玉川さんが付けた注釈がとても実践的で評判が良い。玉川さんが日々テスト自動化を実践しているがゆえ。

自動テストで大切なこと（本書全般で言っていること）

  • 整理
  • 役割分担
  • 協調

ピラミッドの構成にするには後付けでは難しいので、プロジェクトの早い段階でこの形を想定して進めないといけない。

一度作ったUIテストを捨てるためには、UIテストを作るコストをいかに下げるか、が大事。そうしないと、ピラミッドの上を小さくするのは難しい。

テストが原因で３割調査しないといけない、といったものは思い切って捨てるべき。

「テスト自動化」という言葉が、後付け感があってよくない。

自動化への抵抗感を無くす。が大事。

炎上しているところは、自動化じゃなくてテストで炎上している。

感想

太田さんと小井土さんの漫談になった本セッション。実際自動化業務してる身としてもあるあるで楽しかったです。

本書で紹介されているテストのピラミッドという考え方がとても便利で、いろんなことの説明がつけやすくなるんですよね。（使わせてもらってます）

特に最後のほうに太田さんがおっしゃっていた、「テスト自動化、というワードはあとから自動化する感じがあってよくない」というのは本当にそうだなと思います。

私はこの発言を、

  • 開発プロセスのはやい段階から品質とそれを担保するテストについての検討が必要
  • そのなかで「ここは繰り返しなんどもやるし、この段階で自動化しましょうか」といった話が出てくるべき
  • プロダクトもそこそこ出来上がってから品質が悪いからといって「今あるテストを自動化して万事解決させよう」は違うでしょ

ということ、と捉えました。

からの「炎上しているところは、自動化じゃなくてテストで炎上している」でK.O.

色んな人に聞いてほしいセッションでした。

GebとSpockではじめるシステムテスト自動化 / 大中 浩行さん

メモ

ここでは「システムテスト」を画面触って行うE2Eテストとする。

  • E2Eのつらみ
    • データのセットアップ
    • 実行時間
    • 落ちたり落ちなかったりするテスト

→E2Eの難易度増大。

  • システムの疎結合化
  • 非同期処理が増える

→結果、結合テスト一発勝負、的なスタイルに。

ストーリーでなくジャーニーをテストする

ジャーニーとは

→ストーリーより大きな粒度のもの。

「相互に合意され、共同で所有される必要」

  • 一つだけわかっていること
    • テストの自動化は、ユーザーストーリーを網羅する、ことではない
    • メンテナンス対象のシステムが１つ増える、くらいの覚悟が必要（伊藤：わかる）
  • Gebの話
    • GroovyによるSeleniumWebDriver拡張
    • Groovyの言語機能を活かした簡潔な記述が出来るよ
    • DOMへのアクセスがjQueryライク
  • Spockの話
    • BDDスタイルのテスティングフレームワーク
  • Gebを採用した理由
    • E2Eのテストを自動化検討したものの、「絶対うまく行かないじゃんこれ」というのが目に見えていた
    • キャプチャアンドリプレイは無理
    • SPAは画面遷移が非同期なので、画面遷移毎に待機を手動で追加しないといけない（死）
    • 周囲にGroovyをやっている人が多かったから
  • Geb+JUnitで作ったプロトタイプ渡したらいつのまにかGeb+Spockになっていた
  • GebにはBDDスタイルのSpockが向いている。JUnitなどはユニットテストフレームワークなので、E2Eテストのストーリーは記述しづらいのでは。そうなるとE2EテストにはBDDのほうが向いている。
  • Geb、ビルドに関するワークフローや処理が単純なものはmavenが向いていると思う。が、Gebによるテストは細かい制御が求められる。→そうなるとGradleが向いている。
  • Geb、非同期処理が書ける。生Seleniumに比べて遥かに書きやすい。
  • 非同期処理の待ちは辛いので、処理状況を取得できるAPIを用意するなどしたほうがいい。でないとDBポーリングしたり、手で実行しながら待機秒数を延ばしたりと辛いことになる
  • SPAの場合、ハングしたときなどスクショだとわからない。
    • じゃあ動画を録画しましょうとか始まる。
    • OSSだけで画面録画が出来るかどうかやってみた

→できはした

[http://blog.fieldnotes.jp/entry/recordiing-selenium-test]

  • クロスブラウザ
    • １ブラウザでも安定させるのきついのに・・・
    • まずは１つ安定させてからクロスにしようぜ、と提案する。いつも。
  • ブラウザ切り換えがめんどくさすぎる。コードでやるのは。
    • →そこで、WebDriverManagerを使おう。[https://github.com/bonigarcia/webdrivermanager]
  • Geb、IDEの補完が効かなくてつらいと言われる。
    • →IntelliJ IDEA使おう

システムテストを自動化するということは、「メンテナンスするシステムが１個増える」くらいに考えた方が良い

  • 自動化してコスト削減！は、新しいことを何も産まない。
  • コスト削減の仕事がしたいわけではない！
  • 自動化によって「何が減らせるか」ではなく、「新しいことができるようになる」に目を向けて欲しい
    • たとえば、システムテストを自動化することで、インフラがサービス水準の改善のための時間を避けるようになった。という例も。
    • 複数の異なるレイヤーのテストが自動化されることによって、
      • 継続的なサービス改善の基盤ができた
      • 手動テストが「魅力的品質」のテストに注力できるようになった

Q：ユーザストーリーを全部カバーすればいいわけではない、というのはどういうことか

A：単体テストだとカバレッジの話になると思うが、UIだとコストが辛い。企画サイド＝プロダクト責任を持つ人達と、どこを落とし所にするかを話し合って合意することがだいじ。

感想

実は最初もう一方の並行セッションに行こうと思ってたのですが、席がいっぱいで仕方なくGeb+Spockセッション側にきたら、結果的に楽しかったです（失礼）

システムテスト（＝ここではUIで行うE2Eのテスト）を自動化するにあたって、ユーザストーリーを網羅することが目的ではないよね、というのは同意。あとはそこをどうやって「全部自動化して幸せにして！！」というお花畑に説明するか、が自動化エンジニアとして試されているかもと思いました。

TypeScript + PhantomJSを利用した効率的なテスト実施 / 西川 諒さん

メモ

アスタミューゼってどんな会社なの？（このあとのテストの話のバックグラウンドとして

  • 事業開発／コンサル
  • 採用・キャリア　←　西川さんココ
  • 特許検索システム

運営しているのが「転職ナビ」というサイト。職種に応じて「◯◯転職ナビ」というサイトが個々にあって、その数約400。

転職ナビのテストの話

  • チームが部長入れて６名。週に1~3回のリリースを行っている。
  • 当初はサイトも機能も少なく、PCサイトしかなかったので手動でテストを行っていた。
  • モバイル対応をし始めて、手動テストがギリギリなんとかできる、くらいのレベル。
  • 登録フォームを改修したら、なんとモバイルでユーザ登録できない不具合が発生。

→PCとモバイルでフロントの作りが違って、手動ではもうムリ→自動テスト導入しよう

スコープを「ユーザ登録処理」に絞った。最低限のユーザビリティ確保をしたいため。

チームにはScalaエンジニアしかいなかったので、選ぶとしたら

  • Java
  • JavaScript
  • Scalaのいずれか。

メンテ出来る人はなるべく多いほうがいいよね、と思ってJavaScriptにした。そこでPhantomJS

Gitでテストコードを管理。JenkinsでCIサーバに落としてきて、対象のAPサーバにテスト実行。いたってシンプル。

自動テストを導入して

  • ユーザ登録処理の品質が上がった
  • 試験はSlackから実行できるので、だれでもできるようになった
  • 障害発生時に、最低限のサービス生存確認ができるようになった　←　ココがでかい。サーバからエラーログ飛んできているときなんかに「サービス自体は提供レベルなのかどうか」を速やかに確認できる。
  • 登録フォームの障害に早く気づくようになった

これで一件落着とはいかず、

  • 登録フォームへの経路増加
  • サービス拡充で登録バリエーション増加
  • そもそものサイト数が増加

して、メンテコスト増加。つらい。

そして新メンバーがやってきたりで、もう破綻。→テストを見直そう。

  • 既存コードを利用。
  • メンテナンスコストを抑える。
  • 誰でもメンテナンス出来るようにする。

→これを実現するために、TypeScriptを使うことにした

  • Scalaエンジニアでも実装できるようになった。静的型付け的な意味で。
  • あとは西川さんがメンテできるようになった。
  • TypeScriptからPhantomJSへのコンパイルを挟んだだけで、成果を上げることができた。

その後、サイト毎の登録フォームを出し分けたい、なんて依頼が来た。

TypeScriptに置き換えてリファクタリングしたところ、PhantomJSそのまま書くよりもファイルあたりの平均ステップ数が減った。

とはいえ色々とデメリットもあって。

  • 実装時
    • JavaScriptがエラーなく生成できても、PhantomJSが動くわけではない
  • 全体
    • PhantomJSの開発が止まっている

ということで、今後

  • SeleniumやChromeHeadlessに置き換え
  • 自動テストの拡充
  • 登録フォーム以外にも

！！！人募集！！！

Q：なぜコミット時にテストを回すことにしなかった？

A：本番については、コミット毎だと負荷が高いので。

Q：部長さんは何をチェックしている？

A：エビデンスを見るわけではなく、自身で叩いている、受入れ試験をしているイメージ。

Q：JavaScriptを選んだ理由

A：Scalaエンジニアだけでなく、フロントエンドエンジニアも使えるものがよかった。そうなるとJS。むしろフロントエンドエンジニアがPhantomJSを勧めてくれた。

感想

まず、楽しかったです。トーク的な意味で。

  • 歩くヒューマンエラー
  • 部長が死ななくなった

などのパワーワードが生まれたセッションがこちらになります。

とはいえ話の内容はかなりまっとうなもので、

  • 全員が価値とリスクを認識して
  • だれもが関わりをもてる

ようにすることが、自動テストで効果を得るために必要だよね！という話だと理解しました。

自動化困難な状況での活動方法 / 石川 達也さん

メモ

WindowsAPIを呼んで操作するFriendlyというツールを作っている石川さん

自動化困難な状況の困難とは

  • 関係者の理解
  • 操作
  • 期待値比較

関係者の理解

客さんは期待度が高くなりがち。キャプチャリプレイに神がかったバージョンみたいなのを期待している。

実際のテスト設計やテスト対象を触りながら「ここは自動化できそうですねー」を説明する。できればその場で簡単に実装して動かしてみせる。

単に工数を減らすのではなく、他にどういった効果があるのかを説明。

また、過去の例から試算した値を出すと理解してもらえることもある。「ROI出してくれ」って言われるのが苦手だったんだけど、試算して出すと喜ばれる。

説明力、がオートメーターには大事

操作

エミュレート方式とAPI方式がある、と石川さんは考えている。

エミュレート方式だと問題が色々あって難しい。スリープしまくることになったり、マウス操作とかで保守性が低くなりがち。

API方式はSeleniumやFriendly。

自動化は自動操作力。

テスタビリティは自分で上げる。

だけど撤退も必要。そのためには初期調査が重要ですね。

期待値比較

画像比較よりは、元データをダンプしてそれを比較するようにしたほうがいい。

トラブルの元になりがち。

感想

説明力が必要、というのが耳が痛い話です。その通りです。

公募LT大会

荻野恒太郎さん UIテストを自動化する前の1.5年にやったこと

  • テストも成長する
    • あとはスクリプト作成するだけ、になれば早い
    • その前に何をするか、が重要
      • CI基盤、テスト自動化基盤、本番環境基盤をつくる
      • ここがテストを成長させる基盤
    • テスト実行が自動化されると、ボトルネックが他に移る
  • テスト自動化エンジニアの育成
    • 良いテスト設計と良いテストスクリプト設計は別
    • 開発とQAがペアでテスト自動化する
  • QAマネージャの育成

折田武己さん: “IoT基盤を活用したテスト時間の短縮”

  • 折田さんフリーランス
  • どうやってシステムテストの時間を短縮するのか、のお話
  • 開発終盤に出てくる。ほとんどのプロジェクトで全部回せない。
  • ラズパイクラスター化でテスト自動化したら結構良かった！
    • はやい：テストクライアントとしては。
    • 安い：5000円で済む
    • 小さい：PCの中に16台ぶっこんでパーソナルクラウドを作ってる
  • ラズパイクラスター化で問題になるテストシナリオの整合性問題など、ブログに追加していくぜ！

Yoshida Nozomiさん: “テストも開発もするモバイルエンジニアのためのXCUITest/Espressoのすすめ”

  • モバイルアプリ方面のE2Eテストについて、もともと開発の人がAppium使ってみた
  • 今だとXCUITest/Espresso便利
  • Appium、実際使ってみたらそこまで両OSで結果が一致しない。Viewの階層レベルで一致しなかったり。
    • 環境設定も大変だったり
    • 勉強量つらい、検索したらJavaの話にRubyの返事が返ってきたりしていて辛い
  • モバイルアプリ書いてる人にとっては、Espresso / ECUITestでよさそう
    • 環境構築コスト低い（ライブラリ足すだけ）
    • HTTPサーバとかはさまないので安定
    • 開発とテストが同じIDEで出来るのでスムーズ
    • いつものデバッガがそのまま使える
  • デメリットもあって
    • プロダクトとテストでコードの管理をちゃんとしないといけない

t_hysshさん: “gaugeによるe2eテスト”

  • ゲージによるE2Eテスト
  • UATが唯一のドキュメントでありテストとして実行可能である、という前提
  • SPEEDAの開発ではきれいなピラミッドになっている
  • ストーリーに対するE2Eテストで、ドキュメントとしての表現力とプログラムとしての表現力どちらも大事

みずのりさん: “テストケース構造をモデル化しよう！：テストカタマリー紹介”

  • 自動化に向いているところを明確にしよう。
  • が、テスト管理がごちゃごちゃになってはいないか
  • テストケースを構造化しよう
    • 【かんそう】構造化、ひとつの軸では無理では。
  • テストケースの塊をテストカタマリーとする。これをclassで表現する。
  • クラスなのでそこらのUMLモデリングツールを使えばグラフィカルに表現できる。
  • 英語だけど論文化もしてるので見てね