ひたすらに自動テストを進めてきた人達がハマっている課題4選(ShanonAdventCalendar2016・2日目)

このエントリーをはてなブックマークに追加
こんにちは

凄惨生産性チームinomataです。
生産性チームとは機能開発チームの生産性を向上することをミッションにしているチームです。
具体的には自動テストの環境を良くしたり、デプロイのツールを作ったりしてます。

今回はShanonAdventCalenderが企画されました。その2日目という事で、自動テストを推進していく上での戦略について書きます。
戦略といっても主にシャノンにおける課題洗い出し回です。
大変な課題を華麗に乗り越えた話。とかだったらもっとよかったんですけどね。
ただ、今自動テストを掲げてまい進している人はこうならないように注意してください。同じ問題にハマっている人は共感してください。解決方法を知っている人は教えてください。

はじめに

今回の自動テストというのは、主にSeleniumで行うインテグレーションのテストについてです。特に断りが無ければこの文脈です。
Seleniumを使ってはいるのですが、Javaなどでテストコードは書かず、IDEで作成されたHTMLをJavaに変換して実行しています。(http://shanon-tech.blogspot.jp/2011/11/Selenium.html)
テストの実行はAWS上で行っています。必要なときに必要な数だけEC2を立ち上げて実行できる仕組みになっています。(http://shanon-tech.blogspot.jp/2016/06/awsSelenium.html)

自分たちの自動テストはイケてる!!

シャノンではかなり前から自動テストの推進に取り組んでいます。おかげで、今では大量のテストケースを簡単に実行することが出来ます。
リリース時にはこれらのテストを全てパスすることを条件にしているので、リリース時の安心度はすごく高いです。実にイケてます。


いや、自分たちの自動テストはイケてなかった。。。

しかし、これらのテストは全て実行するのに2-3時間かかります。さらに不安定なテストが存在するので追加で何回か実行したりします。
そんなこんなでOKが出るまで結構時間かかります。自動テストの全パスをリリース基準に掲げているので、巷のイケてるwebサービスの会社のように毎日リリースなんて到底出来ません。毎週リリースも出来ません。
現在はそこまで頻繁にリリースするような戦略をとっていないので、それに関してはとりあえずいいのですが、リリースの判断基準の判定が遅くなります。リミットが迫っていると冷や汗モノで精神的に悪いです。
前述のようにAWSを使っているので、沢山使うとお金がかかります。請求額を見ると結構なものです。
自動テストによって早いフィードバックをもたらしたいと思っているので、時間がかかるテストは実にイケて無いです。

イケてないポイントをまとめてみましょう。

イケてないポイントまとめ

1.全てのテストの結果がわかるまで時間がかかる
 a.単純に長い
 b.不安定による再実行
2.時間が長いととよりお金がかかる

次にこれらを改善するべき要件をまとめてみましょう

改善したい要件

1.テストの実行時間は短くしたい
2.品質を落としたくない
3.安く上がるようにしたい

といったところでしょうか?・・・難しいですね。まるで、テストはコストがかかるという事がよくわかっていない経営者が言いそうなセリフです。
しかし、我々としても今が最適化された姿では無い事を知っているので、現状の課題を整理していきたいと思います。
なお、要件1,2を満たすには、現状維持のままAWS利用の追加投資をするとある程度解消するのですが、正直割りにあわないと思っています。(そんなお金どこにあるのかという話ですが)


テストケースの管理がよくない

現在Seleniumのテストケースはgitで管理されていますが、どんなテストがどこで行われているかはうまく管理されていません。
テストケースの内容は、テストケースの名前からなんとなく察するか、中身を詳細まで見るしかないのですが、そこまでやってもわかるのは動作内容くらいで、何のためのテストなのかという目的まではわかりません。
こうなってしまうと、テストケースの流用というのが正しいのかわからず、
そうなると、当然同じようなテストが複数作られてきます。これはムダです。自動テストの内容が簡単に把握できる上手な手段が必要です。
余談ですが、それっぽい名前のテストがあってそれがJenkinsで実行されている場合、そのジョブが青くなっていると人々はそれっぽい名前の機能はこれでテスト済みだと思ってしまいます。
もしそのテストの中身がぜんぜん違ったら、あるいはたいしたテストをやっていなかったら目も当てられません。

なんでもインテグレーションのテストでやってしまう

開発プロセスは、開発者がユニットテストを作成して、QA(テストをする人)がSeleniumの自動テストを作成するという体制でした。QAはノンプログラマーな場合が多いので、品質に責任を持つ人が自分たちがやりやすい方法でテストを作ります。
つまりSeleniumのテストが増えていきやすい状況にあります。
このことから、どういう目的のテストをどのテストレベルで行うかという事はよく検討して取り掛かるべきです。
狙いとしては、ユニットテストなど実行の速いコードベースのテストで担保するべき内容のテストはそっちでやりたいです。(何がどこまで出来るのかあまりよくわかっていないので、誇大妄想かも知れませんが)
また非同期処理の動作や外部のサービスを利用する機能を担保する場合(例えばメールを送信して受け取るなど)はモックなどをうまく使わないと動作が不安定なテストになりやすいです。
また、以前述べたように開発者と事前に話しが出来ていればこのあたりの解決は意外と簡単かも知れません。機能のテスタビリティにもつながりそうです。(http://shanon-tech.blogspot.jp/2016/03/blog-post.html) 

テスト内でデータと実行をやっている。

現在どのテストでもデータを作成して検証するというテストがほとんどです(データを作成する事自体のテストというのも当然ありますが)。テストの中でデータを作成してテストをするとなると、それだけ時間がかかります。
動的なデータが必要ない場合は事前にデータを作成しておいて、それを使う方がスマートでしょう。これはデータ駆動型と呼ばれるの自動テストの戦略(?)です。
ただ、その場合は事前に用意しておいたデータを利用することになりますが、そのデータは定期的にメンテナンスする必要があるか、その手段はどうするか、などを検討しておかないと後で痛い目を見そうです。

全部の自動テストを実行しなければならない

リリースには全ての自動テストをパスさせなければなりません。この前提を疑うのはどうでしょうか。
機能やサービスによっては、あえてテストをしないという戦略もありだと思います。例えば問題発生時のバックアッププランを整備して、ユーザーにとって品質を落とさずにいられればこれは十分な戦略だと思います。
また、サービスや機能とテストの影響範囲が明確であれば、テストの部分的な実行で良いかも知れません。
あと、個人的に"念のため"のテストは嫌いです。
エンジニアたるもの、テストをやるなら影響範囲を見極めて、十分なテストをやるというポリシーであるべきだと思っています。
そうでなければ、結局人海戦術に負けてしまいます。テストエンジニアのフィールドで戦うなら一騎当千のチカラが必要です。



まとめ

品質に落とさずに実行時間を短く出来る案をいろいろ考えてみました。
 基本的にはムダを省く
 内容(目的)は変えず手段を変えて速くする
といった部分に終始しました。わりと王道な案が出てきましたが、いざ実行するとこれが難しく時間もかかります。さてどうしたものでしょうか。でも銀の弾丸はありません。
何にでも言えることですが、こういったことを地道に積み重ねなければ明るい未来は待っていないのです。今後シャノンのQA事情がどう成長するのか乞うご期待!

それでは!

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...