Shanon Advent Calendar 2017 の25日目。
トリを飾る生産性チームのinomataです。
最後なので、1年間の総復習的な成果や反省にできればかっこよかったかな？とか思いながら勉強会参加レポートを書いてます。
ということで、去る12/10に行われたシステムテスト自動化カンファレンス2017-2に行ってきたので、個人の感想と意訳と共にまとめたいと思います。
公式
https://sites.google.com/site/testautomationresearch/
発表資料は順次公開されると思います。
システムテスト自動化カンファレンスは前回開催されたのが今年の2月で、今年2回目の開催です。しかも今回は、部屋ごとにセッションを変えたりと回を重ねるごとに規模が増しているようで、自動テストの注目度の高さがうかがえます。
テスト自動化と機械学習（STAR機械学習分科会紹介） / 早川 隆治さん(STAR)
このカンファレンスの主催でもあるテスト自動化研究会(STAR)で行ってる、機械学習を使ったテストの自動化への応用を検討する分科会の紹介でした。
アルゴリズム、ハードウェアといった基盤が安価に手に入る時代になって、機械学習が身近になってきました。それをテストの自動化にも応用できないか？ということでいくつか検討されているようです。
例えば、自動テストのエラーメッセージを学習データとして類似バグの検出、画面の崩れ、ユーザビリティからの逸脱の検出などが紹介されてました。
これらはまだアイディアの段階で特に具体的なものは特にありませんでした。
また発表資料には、すでにある機械学習等を使ったツールがいくつか紹介されていて、大変興味深いものでした。
別のセッションの話での話で、機械学習やディープラーニングは自動テストのツール導入やコンサルタントをしてる人はよく言われるそうです。
「AIでいい感じにできないか？」って。ツールを求める人はまだ、というかまた夢を見るようになってきたのかもしれません。
実際、「AIでいい感じ」にできたら面白そうですけどね。
翻訳者の同僚が語る「初めての自動テスト」 / 太田 健一郎さん(STAR)
「初めての自動テスト」という本の紹介です。翻訳者の玉川紘子さんが出られないというので、代打で太田さんが発表することになったそうです。
webシステムにおける自動テストの考え方やプロセスをどうすれば上手くいくかという内容から始まり、具体的にコードを書いて動かしてみる内容のようです。中でもテストのピラミッドという考え方がすごく重要で、これを達成するようにプロセスを作っていかないとダメで、
「私が行く現場はすべてこのピラミッドが逆転している」と言っていました。
そのほかセッション中でいくつかに気になった事をいくつか紹介。
・UIテストはいらなくなったら捨てられるようにする。捨てられるようにするには作りやすくしてコストを下げないといけない。
・自動テストは7割の打率でも3割の調査コストが発生する。不安定なテストはコストが高いからダメ。
・ピラミッドが逆転して出来上がったものを後からどうにかするのはすごく難しい。アプリ含めて最初からそこに目指しておくべき。
・自動テストはプログラム感を出すと、非プログラマ(SIer、テストエンジニア)が抵抗感を出す。実際現場、自動テストでもVBAを使ってるという話をしたら「自分でもわかる」と協力を得られた。
・「ツールを買ったから」といってそれに固執するのは失敗しやすい
・自動テストは全員参加で行う。他人のやること、といって壁を作るとうまく回らない。
ダメな感じで出来上がったものをどうにかしていくのはすごく難しい、というのは何回もおっしゃっていましたが、これは地道にやっていくしかないのでしょうか。。
楽天のレジャー・サービスにおける自動化の取り組みとその効果 / Fumikazu Fujiwaraさん
自動テストを導入したことの事例発表です。手動テストのみで自動テストが無かった時には、テストの実施と開発へのフィードバックがボトルネックになっているという問題がありました。
分析すると、
- データの作成が時間かかる
- パターンの網羅が複雑で大変(手順ミスなどがある)
- リグレッションテストに時間かかる(影響範囲テストの結果が開発に早く通知できない)
- データの作成を自動で生成する
- パターン網羅は同じ手順が繰り返し実施できる
- リグレッションテストは実施の自動化+CI+チャットツールの組み合わせで素早くフィードバック
ツール選定では、要件と自分たちのスキルを照らし合わせて有償ツールを選んだとのこと。有償ツールは導入コストが高いので敬遠されがちだが、チームのスキル不足とスクリプトの開発のしやすさを勘案して、有償のほうを選んだとのことでした。ランニングコストまで考えないとダメですね。
How we automate E2E tests at Mercari / 根本 征さん
自動テスト関連の活動の事例発表です。自動テストに関連する活動を行う上で、
- 認知
- 安定化
- not only test automation
「認知」とは、知って使ってもらうことの取り組み。知られていないと同じようなフレームワークが乱立したりで無駄が発生してしまう背景があったそうです。また、使ってもらうためには使いやすいようにしておく(jenkinsの実行を押すだけで結果がわかる)仕組みも重要とのことです。
「安定化」とはコスト削減の取り組み。自動化の失敗を調べるのは結構時間がかかって、コストが高いです。スクリーンショットをとるなどで原因を特定しやすくしているとのことです。環境のメンテナンスも重要で、最近は自前で用意するよりもクラウドサービスに寄せてしまったほうが楽になる場合があり、積極的に利用しているという話でした。
「not only test automation」とは、テストスクリプトを作成するだけではなく、関連する事柄にも自動化の仕組みを取り入れる取り組み。テストデータの自動生成、リリースの作業、検証端末の管理など、開発からリリースに関連するプロセス全体で自動化に取り組んでいるようです。このあたりはZapierというツールをうまく利用しているみたいです。
SI-Toolkitでテスト自動化を実現する現場で遭遇した出来事 / 桑原 雄一さん
SI-Toolkit WT というツールのデモと導入の話でした。https://sitoolkit.org/
SI-Toolkit WTは発表者の桑原さんが作成されているもので、Seleniumをベースにした自動テストのツールです。特徴としては、
- テストケースがxlsから作成できる(SeleniumIDEのhtmlを表形式にしたデータ構造になっていた)。
- 並列実行が可能。
- クロスブラウザにも対応
割と簡単に非プログラマでも扱えるツールですが、導入をするというのは難しいもの。「簡単であろうと、今から新しいものを覚える」という事に抵抗感が出やすいので、導入の際にはプロジェクトの計画の中に、学習等の準備計画もしっかり入れておくことが重要。これは工数の話だけでなく、どのフェーズに来たら誰がどの作業を行うという、プロジェクト全体の作業計画まで落とし込むと上手くいったとのことです。
また、自動テストを定着させるためにも専任のスタッフを用意したほうが良いとのことでした。
自動化困難な状況での活動方法 / 石川 達也さん
Friendryを使った自動テストの実施に関するセッションでした。Friendryとは発表者の石川さんの会社が開発しているWindowsアプリを自動で操作するライブラリです。
http://www.codeer.co.jp/
キャプチャリプレイツール(マウスやキーの操作を記録、再生させるツール)と違って内部APIを操作するので、動作が安定しています。
自動テストでは正確さ(安定性)こそ重要で、正確さのテスタビリティを上げるために専用のAPIを作るとのこと。テスト用のAPIを作成することを「ピンをはやす」と表現していました。ハードウェアがテストのために専用のピンをつけることに由来するみたいです。
自動テストは万能なツールではないので、できないものはあきらめる(別の手段で品質を担保する)というのも重要です。本セッションの中で「画像の比較をするのはとても難しい」という話がありました。画像の比較は1ドットずれるとNGになってしまいます。また、1ドットのずれを許容するように作るにしてもそれはそれで難しくなるし、何ドットのずれまで許容するか？という事を考えることも難しくなります。
LT
LTは5名の方が登壇していました。面白かったものとしていくつか紹介します。- テストクライアント用のPCを用意するにしても、PCは高いし置く場所もない。クラウドも高い。ということでRasberryPIでテストクライアントを作った。省スペース+安価で用意できた。
- Appiumは巷のうわさほど楽では無く(環境構築、OS互換性など)結構しんどい。モバイルの自動テストは自分たちにあったツールや手段をよく検討したほうがよさそう。
最後に所感など
技術的な面では最初にAI関連の話題が来ていて、テスト自動化にもAI技術への応用、あるいはクライアントの期待が高まってる印象でした(チュートリアルでやっていたMagic Podはまさにそれですね)。また、初めて知るツールがいくつか紹介されていて大変興味深いものでした。このあたりもぼちぼち調査してみたいところです。運用的な面では、自動テストをいかに正確に、早く結果を返せるかということに誰もが試行錯誤しているようでした。しかし、テストだけではどうにもならない面もあり、プロダクトをどういう作りにしておくか、開発プロセスはどうするか、どういう組織構造で役割や責任をどう割り当てるか、という製品開発全体を対象として考えないといけない面もいくつか垣間見られ、自動テストの本質的な難しさを改めて実感したカンファレンスでした。
それでは！また！
