aretan.jp

https://test-engineers-meetup.connpass.com/event/50496/

QAとは別にテストエンジニアの組織： サイボウズ DeNA
テスト基盤を構築している： アカウンティングサースジャパン 楽天
兼務状態で悪戦苦闘中： リクルートライフスタイル freee

MicroservicesにおけるAPI自動テストにまつわるエトセトラ DeNA @okita¶

Google SETを参考にSWETを始めた、独自のVisionをもとに活動の幅を広げる
SET,SE,SETI

RESTful　API開発のスタイル
リソース設計をしっかりする、リソース定義をしっかり行い責務割り当てをきちんと設計
JSON Hyper SchemaでAPI specificationを定義
JSON Schema draft4に対応、OpenAPI specification(swagger)
開発者が開発しながらテストも開発
　コンポーネントテスト
　コンポーネント統合テスト
　システム統合テスト
SWETによるテスト
　テスト対象をきちんと分析したテスト
そのほか、APIのオーケストレーションによるシナリオテスト

これ以外にはFuzzingとか、naokishimizu/yapc-2014
JSON Schema自体のテストをやるようにした
システム統合テストならではのバグ検出数が少ない
検出されるバグが致命的ではない
書いたテストがサンプルになりわかりやすい
TDDと同様にリソースデザインの助けになる

スキーマ定義に対するテストとそのメトリクス（qiita）

JSON schemaの静的解析
$refを解決できるかとか
propertyのtypoがないかとか

システム統合テストで出ていた問題が早めに検出できるように

コード生成
JSON Schemaからコード生成、HTTP Client, API Dashboard
OpenAPI specification swagger-codegen

テストする際にDB直でいれずに、対象アプリケーションを利用して挿入する

SelenideによるDSL風E2Eテスト基盤開発の実例 アカウンティングサースジャパン¶

SelenideとはSelenium WebDriverを抽象化してUI Testに特化している
IDEによるサポートを意識してる

仕様を作成した人がテストをかけるようにしたい

PageObjectPatternを拡張、BasePage, Page

テストシナリオでSelenium/Selenideの実装を隠蔽する
全面的に日本語メソッドにした。

入力項目が多いのでBuilder Patternでデータ登録できるように
Mix-inによる画面共通項目の一元化　implementsしていく

Manage Pipeline of Performance Test with Jenkins 楽天¶

matome.userlocal.jp
Performance TestのPlatform化した

要件定義　エッジアクセス、どれぐらいのQPS
テストコード　テストコード自体が間違ってる可能性
サーバー作成　知識がない、権限がない
テスト実行　負荷試験する方がたりないかもしれない
クライアントが複数になるとクライアントの協調を取らねばならない
複数のテストエンジニアが同じサーバーでやるとリソース不足になる
テスト評価　各サーバーのログを取ってこないといけない
サーバー削除　権限がないとか、使ってるの消したらつらい

これを改善するためにGatling + Jenkinsでやった
Jenkins Pipelineを使ってパラレル実行をしてる

サイボウズ テストエンジニアリングチーム 生産性向上チーム¶

受け入れ試験自動化 Seleniumテスト１５００件、４８並列で２０分　APIは２０００件
目的、いつでもリリースできる状態、変化に強くなる、常に一定以上の品質が担保される
新機能とかリファクタリングに心が向くようになる
技術周りはkintoneチームを支える。。。を参照してください
テストのチームが２つあって、QAはテスト設計、devは自動化をする
QAからDevに試験観点がシェアされるので、実装が捗る
DevからQAだとこの試験いらないんじゃね？とかが働く
予想外のメリット：
　QAの試験以前に一定以上の品質が担保される
　テスト設計の制度があがる
　DevとQAのコミュニケーションが捗る
DevQAトークナイトでソニー永田さんから話を聴く
アジャイルでは暗黙知が多くなりがちだから、対話が大事
フィードバックループを構築する
繰り返し継続して信頼関係を作る
devだけで自動化するとdevによりすぎて意味がない
QAだけで自動化するとソフトの実態に合わないテスト

ツールやプロセスにとらわれると手段と目的が入れ替わりがち
自動化戦略、どこまで自動化するかを考える
HRTは大切にしましょう

ドメインをスペックにしていく freee株式会社¶

複雑なドメインへの立ち向かい方について話します
給与ってどう計算されてるか知ってる？
計算間違いがあってはならない
自分たちの開発だけじゃなくて、税率がかわってくる
単体テストがたくさんあっても本当に正しいかわからない
変更を恐れずにどんどん更新していきたい
ドメインスペシャリストによるテストがちゃんとうごくようにしたい
社労士さんと手を組んで、一緒にテストを作っていく
Googleスプレッドシートに書いていくだけで、テストケースが作れる
がんがん変更できるようにAPIスペックをする
ドメインスペシャリストがAPIテストを書いてるって思うと心強くない？
まとめ：ドメインスペシャリストをテストに巻き込む仕組みを作ろう
カバレッジは、社労士さんに重要なのをリストしてもらっている

自動化を支えるCI/CDツールの私の選択 リクルートライフスタイル¶

ブッキングテーブルというサービスをやっている、密かにSET活動中
ミッション：テスタビリティをあげて開発生産性を上げる
何をするか：サービスの品質を向上させるためにボトルネックを解消する

Jenkins, Travis, Circle, Codeship, werker, drone
いっぱいある

メインで解決したかったこと、CI/CDツールの選定理由とか
CI単体テストに５時間かかるようなものもあった
CI単体テストの速度の重要性、早く見つけた方が対策費用が抑えられる
遅くなったら：コミットが混じる、作成者が忘れる、テスト結果に興味がなくなる
オンプレ前提なのでCircleとJenkinsから選ぶ事に
比べたらJenkinsしか選べない。。。
Googleもやってるテストサイズの導入
静的解析、SonarQube、SideCIなども導入したい