Testing Casual Talks #2行ってきた。
もう一週間も前だけど行ってきたのでメモを残す。
発表者はDeNAのテスト専任チームSWETの方や、ペパボのインフラの方などWeb系がやはり多かった。
発表内容は以下。
- mruby のテスト方法についての試行錯誤
- スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた
- 大規模 Web サービスのブラウザテスト自動化・並列化
- ECサービスの負荷テストの裏側
- 継続的Webセキュリティテスト
- Casualにインフラテストへ入門した話
- カジュアルなテスト&仕様書として JSON+node requestのご提案
@hsbt mrubyのテスト方法についての試行錯誤
アプリケーションサーバのnginxのconfigファイルにmrubyを埋め込むことで設定に対するテストが記述できるという話。
現状の分析として、アプリケーションに対するテスト、サーバ構築に対するテストは進んできているが、 ミドルウェアに対するテストはうまくできていないという課題があるという。
コードならテストできるのに…
-> ミドルウェアの設定ファイルをコードとして記述してしまおう!
-> コードだからテストできる!
という発想らしい。
スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた 境野高義 (@sakaimo)
スクラムチームにQAが最初から最後まで参画するという話。
スプリントの最初の要件定義と、最後のテストに対してPO、開発、QAが関わっていく体制。
仕様の漏れや矛盾がスプリントの最初に摘出できた。
KPTでの分析をしていて、 Problemとしては、QAの性として機能単位でまとめてテストしてしまっていた、 期間的な問題で正常系テストが中心となり異常系までスプリント内でいかなかったなどが挙げられていた。 Tryとしては、ストーリーを予め作成し、スプリントとストーリーを同期させながらテストしていくこと、 プロダクトオーナーを交えて軌道修正をしていくこととしていた。
@deme0607 大規模Webサービスのブラウザテスト自動化・並列化
DeNAのテスト専門チームSWET(Software Engineer in Test)の方の話。
テーマは以下。
- ブラウザ自動テストの構築
- テスト並列化による高速化
- 並列化したテストの向上
ブラウザ自動テストを構築することで、基本的なテストケースは自動化され、人間(QA)がやらなければならない検証に工数を割くことができるようになったという。 新機能や画面はやはり人が試さないと効果を確かめられない。
しかし、ブラウザ自動テストは通信やスナップショットの作成など結構時間がかかる。遅いからといってテストケースを削ると品質が落ちる。 -> 並列化による高速化をした。 ただし、並列化すると遊んでいるノードがもったいないなどの問題が生じるので、実行計画の最適化アルゴリズムを組むなどしているらしい。 cf ビンパッキング問題 - Wikipedia
また、ブラウザの自動テストは落ちやすいという傾向がある。 頻繁にテストが失敗していると、これは落ちても良いテスト、これは落ちてはいけないテスト、などを判断する職人を生んでしまう。 そこで、過去のテスト結果を集計して、「よく落ちるテスト」、「突然落ちるようになったテスト」を分類して、 落ちたらいけないテストをSlackに通知する仕組みを作ったそうだ。
「ECサービスの負荷テストの裏側」@kenchan
負荷テストのツールGatlingの紹介と、レポートで埋められなかった部分を自分たちで解析したという話。
レポートからはレスポンスタイムの最大最小平均値などが出るが、データのばらつきや時系列での分析もしたかった。
->テストの生ログを抽出してgoogle spreadsheetへぶち込みグラフ化。1万件までは耐えられる。
「serverspec x infratasterを使ったサーバテスト入門のカジュアルな話（仮）」@yudoufu
サーバ構築に対して振る舞いテストをやってしまおうという話。 serverspecは設定のテストはできるが動作のテストはできない。 結局ブラウザでポチポチしないといけないので辛い -> TestKitchenで振る舞いテストもできるぞ!
追加の設定項目も少ないのですぐに導入できるらしい。
