システムテスト自動化カンファレンス2017-2 に参加してきたので、その感想。 https://testautomationresearch.connpass.com/event/71564/

テスト自動化と機械学習（STAR機械学習分科会紹介）

機械学習を使ってテスト自動化出来る部分あるよねって話

• 機会学習を活かしたテスト自動化の案
  • 正確なアイコンや切れていない文字を学習させてUIのテスト
  • エラーメッセージを学習し既知のエラーなのか新しいエラーなのか判定
  • システム操作をAIに行わせ、システムが意図通り使われているかUI, UXの観点でテスト

この中でもユーザビリティの強化にディープラーニングを使うっていう発想は面白かった。

翻訳者の同僚が語る「初めての自動テスト」

「初めての自動テスト」という書籍の紹介（会場で少し安くなってたので後で買った）
とりあえずUIテストで100％網羅は無理！という観点は大切だと思った。

質疑応答であったけど、まずはAPIテストから始めてUIがある程度安定してきたらUIテストを実施するのがいいらしい。
自動テスト基盤が出来ていない内にUIテストから入って100％網羅しようとするのはアンチパターン。

また、UIテストは必要なくなったら捨てられる方がいいので、テスト作成コストは低い方がいい。
テストが安定していることも大事で7割OKで3割ダメならそのテストは捨てた方がいい。
不安定なUIテストよりも安定的なユニットテストへ切り替えていくことも大事。

GebとSpockではじめるシステムテスト自動化

https://www.slideshare.net/mobile/setoazusa/automation-systemtest-bygeb
もう一個のセッションとどっち出るか迷ったけど、使ったことないツールの方を聞いてみることにした。

システムテストとは
テストを自動化する前にテストの分類を共通認識として持っておくことが大事。
（実施する工程に関わらず規模の大きさで分けるGoogleのテスト分類はわかりやすいなと思った）
その上でシステムテストでは何をすべきかというと、ユーザーストーリーではなくジャーニーでテストすると良いみたい。
（ジャーニーは定義が難しいけど複数のストーリーの集まりみたいなもの）

ここで大事なのは定義よりも、システムテストの範囲を最終的にサービスの品質を決定する人と相互に合意を取っておくこと。
テストで100％網羅するのは無理という前提で、どこまでを品質として担保しておきたいのか合意しておかないと、結局テスト範囲の線引きが曖昧になってしまう。
「システムテストを自動化するということはメンテするシステムがもう一つ増えるぐらいの覚悟が必要」っていうのはなるほどと思った。

テストケース作成で大事なこと
htmlのidやclass属性を利用してテストケースを書かないこと。
これをやってしまうとシステムテストとアプリケーションロジックが密結合になってしまう。
その結果、例えば「フロント側リファクタリングしたぜ！ → テスト全滅。。。」があり得る。

Geb + Spockを利用したテスト
ビルドのフローが単純ならMavenが向いているが、Gebによるテストはスクリプトとして細かい制御が求められるのでGradleが向いてる。
（クロスブラウザだったりテスト環境の切り替えだったり）

ただ、クロスブラウザのテストを初めからやる必要はなく、まずは単一のブラウザで挙動が安定してからクロスブラウザでテストした方がいい。
（クロスブラウザで確認したいのは結局UI崩れとかだけだったりするので）
クロスブラウザのテストをする際はブラウザの切り替えをしてくれるWebDriverManagerがオススメ。

ちなみに何故Spockなのかというと初めはJUnitでプロトタイプ作ってたけど開発現場に渡してみたらいつの間にかSpockになってた（笑）

テスト自動化の目的
テスト自動化の目的をコスト削減に向けるべきではなく、自動化によって新しいことが出来るという部分を目指すべき。
（自動化自体は何も新しいものは生み出さないので、コスト削減が目的になるとジリ貧になってしまう）
例えば継続的なサービスの改善基盤構築だったり、手動テストを「魅力的品質」ものだけに注力出来るということだったり。

「当たり前品質」の部分は自動テスト、「魅力的品質」の部分は手動テストという感じで継続的なサービス改善ができる環境だとだいぶ魅力的だなーと思った。

TypeScript + PhantomJSを利用した効率的なテスト実施

Webサービスを作っている現場でのテスト自動化例のセッション

テスト自動化の経緯
元々PCのみだった登録フォームをモバイル向けにした際、実はモバイル側でちゃんと登録出来ていないことが発覚したことから自動テストを導入した。

TypeScript + PhantomJSにした経緯
初めはPhantomJSだけでテストしていて、テストケースもあまり構造化していなかった。
ただ、テスト対象ページの導線追加やテスト対象ページの増加につれてメンテナンスコストも増加し、放置すれば確実な死が待っている状況になったｗ

以下の前提条件で検討した結果TypeScriptを利用することにした。

• PhantomJSの既存コードを利用
• テストコードを構造化
  • 可読性を上げ、メンテナンスコストを抑える
• 誰でもメンテ出来るようにする
  • JavaScript以外でもテストケースが書ける
    （現場がScalaエンジニアだったので）

TypeScriptにすることで以下のようなメリットがあった。

• 静的型付けが出来る
• 大抵の記述エラーはコンパイル時にわかる
• 他にもTypeScriptだと出来ることの恩恵がいくつか
• コード量もPhantomJSの時と比べて約半分になった

やっぱり静的型付けってTypeScriptの魅力だし、色々出来る辺りはさすがMSだなーと思った。

今後の課題
セッションのタイトル見た段階で気になってたけど、やっぱりPhantomJSの開発終了宣言は困っているみたい。
今後はSeleniumかHeadless Chromeに置き換えていきたいということだった。

自動化困難な状況での活動方法

https://www.slideshare.net/mobile/tatsuyaishikawa7334/stack2017-83774154
テスト自動化ツールを作成している企業の方のセッション

テスト自動化導入あるある
よくある誤解

• キャプチャリプレイがあればすべて解決するはず
• ランダムに実行させて問題のあるところ見つけてください
• AI使ってなんとかならないのですか

自動化出来る部分と自動化出来ない部分をちゃんと整理して導入する必要がある。

エミュレート方式
キーボードやマウス操作をエミュレートしてテストする方式

• 直感的にわかりやすいし万能感はある
• アプリとしてどこまで進んでいるかわかりにくい
• マウス操作の方は保守性の高い記述が難しい

ここで登壇者の方が作られているFriendlyという結合テストツールで連続してクリックするデモを見せてもらった。
ただ連続でクリックしてカウントするだけだったけど、ダブルクリックにならないように出来るだけ早くクリックするというのは地味に凄いと思った。

API方式
システムのAPIを叩く方式

• タイミング依存の問題が起きにくいので運用コストを下げることが出来る
• 人間の操作とは完全には一致しない

テスタビリティを上げる
テスタビリティを上げるためにはテスト用のAPIを作っておくことも大事。

テストデータが画像になってしまう場合は可能なら元データをテキストにしてダンプした上でテストするのがいいらしい。
（画像自体でテストしてしまうと1ドットのズレ等ですぐエラーになってしまうため）
最終手段だが画像自体でテストするなら絶対に画像が一致する条件を開発時に決めておくと良い。

「自動テストで何より大切なのは正確さ」ということだった。
自動テストが不安定だったら心理的安全が得られないから確かに大事だよね。

公募LT

色々な内容があって結構楽しかった。
テスト自動化環境が整う前にテストのスキルだったり設計だったりに投資しておくことも大事だし、テストツールも色々あるから色々な手段でテスト自動化を目指していけるというのが大事だなーと思ったのが漠然とした感想。
テスト用マシンとしてラズパイ16台をPC筐体に突っ込んでパーソナルクラウド化して使ってるという方がいて面白かった。

全体のまとめ

どの企業の方も導入に際してかなり苦労しているなーという感じだった。
その上でどうやって導入していったかというのが色々聞けたのが一番大きかったかな。