何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

Testing Casual Talks #2 に行ってきました #testingcasual

テスト 学習 ポエム

atnd.org

最初にまとめ

  • なぜ、参加したのか
    • 今年に入ってからテスト周りの学習をしているが勉強会には参加できていなかったので
    • 本の読書会だと個人的事情で全部は参加しづらいが、一発ものだと参加しやすい
    • テスト周りでの求職あったらいいな。
  • 結果としてどうだった？
    • 内容には満足。*1
    • 久しぶりに勉強会の懇親会に参加したがボッチで参加したので人と話すのが難しかった。
      • でも、少し話せて面識ない人と話すリハビリになったし、刺激を受けられた。
    • 自分もその一端を担っていたSI業界との意識の差に分かっていたことだけどズシリと来るものがあった。

以下はほぼ自分用メモのまんまです。
ヒカリエがオシャレすぎてビビりながら入場

そして発表が始まりました。

"How to test code with mruby"

GMOぺぱぼのhsbtさん

内容

ミドルウェアのテストの話。 シングルバイナリなのでmrubyはミドルウェアに組み込みやすい ex)ngx_mruby nginxやapacheの中でちょっと複雑な処理をしたいときに役に立つ 例えばアプリ側で普通やるdigest hashをnginxの段でできる。 Ruby のテストは簡単(CRubyの場合) test-unitを当初使ってみたとのこと 環境周りばmockでぼかしているのでモヤっとする ngx_rubyの振る舞いをテストできている訳じゃない。 モックとスタブを使いすぎると何をテストしているんだか分からなくなる。 現状cross platformなテストになっていない。CIも回っていない nginx.confをどんどんmrubyに置き換えていきたい。

感想

正直、mrubyをどういう場面で使うのか具体例が組み込みかと思って遠い存在的に感じていたけど、急に身近に感じられた。 面白そうだな。

"スクラムにおけるQAメンバー(非開発者)の関わり方を模索してみた"

ガイアックスの境野さん

内容

Scrum テストメンバーの関わり方についてテストを書かないQAの人に向けた話っぽい
スクラムのプラクティスを取り入れた開発(社内で2例目)
QA（コードが書けない人）がチームに入っていく。（初めから）
要件定義にQAが入って定義を充実させる（完了条件をはっきりさせるとか）

  • スプリントごとにテスト
    テストがスプリント内に収まらない問題
  • 振り返りはKPT
    • K:要件ヒアリングで仕様が詰められる
      まとめてテストより細かくテスト
    • P:テストがスプリント収まらなかった
      テスト項目の想定
      機能単位でのテストになった
    • T:テストのやり方、内容を変える（正常系をさらっとなぜなら開発者が書いてるから）
      ストーリーごとにテストする

ガイアックスでQAチームの技術力がもっと欲しいとのこと
関連でDeNAにSWETとというチームがある。

"大規模Webサービスのブラウザテスト自動化・並列化"

DeNAのdeme0607さん

speakerdeck.com

内容

NBPF (Next Browser Platform) 次世代ブラウザプラットフォームに関わる話。

効率的なリグレッションテストができた（自動化できたので）

  • 自動テストでは担保できないこともある
    • UI
    • 機種依存

QA工数を新機能やUI検証に集中

  • ブラウザ自動テストの拡充の問題点
    • ブラウザ自動テストは実行時間がかかる
      • HTTPリクエスト, Ajax, Mail
    • 実行するテストケースを削減するのはさけたい
      • テストの並列化による
      • テストの処理が互いに衝突しないように

  • 問題点

    • 大規模サービスの環境構築コストが大きい
    • 環境依存の問題にテストで気づけない
      • 本番環境、テストデータ
    • DB操作によるテストデータ作成
      • 仕様変更に追従しづらい
      • 実環境DBをテストから操作する（やばくね？）

  • 不安定なテスト

    • TimeOutError Ajaxのタイミング
    • テストの失敗に慣れてしまう

  • どうするか？

    • 地道にテストを修正していく
    • 不安定なテストを分析する

  • 不適切な実行計画

    • マシンリソースを最大限使いたい
    • テスト結果集計APIを利用
    • 過去のテスト結果から分散した形で割り振るようにする*2

  • 今後の課題

    • データ作成　APIの充実
    • 分散実行ノードを動的に増やす仕組み
    • push型ではなく、pull型の実行

感想

LT

"ECサービスの負荷テストの裏側"

@kenchan さん

speakerdeck.com

内容

初めて負荷テストを行った際の話
gatlingを使って負荷テストの結果のレポートを出していたが…。

  • レポートから見えるもの
    • ざっくりしている
      • 詳しく見たい
    • 分布を詳しく見たい
    • 時系列のデータが見たい
      • どのタイミングで負荷があがる？
      • アプリの特性把握ができた

感想

あまり負荷テストをやったことがないのでふぇーっと聞いていただけ。
不勉強な領域だったなぁ。

継続的Webセキュリティテスト

本日福岡から来たという市川さん

www.slideshare.net

内容

VAddy OWASP ZAP（Javaのセキュリティテスト） CIのフローに乗せるのが大変

感想

発表中に「あれ？この話どっかで聞いたな？」と思ってそれが気になり全然メモできず。
あとで調べたらJenkins Conference 2015のLTにいらしていた方でそちらを聞いていたので既視感があったんだとおもいます。*3

» Jenkins ユーザ・カンファレンス 2015 東京 – セッション/LT 日本Jenkinsユーザ会

"serverspecとかのカジュアルな話"

yudoufuさん

speakerdeck.com

内容

インフラ担当で自動テスト
サーバー構築はChef化していた
動きが予想が違ったらもう一度VMを作り直して通しチェック
チェック作業が辛い
インフラの人が少ないし通しテストは大変
ChefにServerspec最初から入っている

  • 振る舞いのテストの自動化
    • infratasterというのがある
    • Issueに暫定対応が載っていた

感想

正直、僕の目にはこれでcasualなの！？というくらい高度な話をしているように見えたのだけど、今はもう場所によっては当たり前になっているのかな？
うおおおお！！ていう感想。

"カジュアルなテスト&仕様書としてJSON+node requestのご提案"

k12u kawamotoさん

speakerdeck.com

内容

立ち上げ時期でテストガチガチではない感じ
Web APIサーバーの仕事
面倒でも仕様書、フロントエンドとの連携を
テストコード書くの正直面倒（楽にできるなら楽にやる）
JSON SChemaでやるかとももったけどボツにした
ルールが必要十分なものを確保できない
JSONで仕様書にできる
実装、仕様、仕様書の不備がCIでfailする
* Web開発の気持ち
* 単体テスト中心 * API開発が普通になると * 仕様がViewになる

感想

正直、事前に公開されていたタイトルと実際のタイトル*4が異なっていて事前公開のタイトルに意識がいっていた自分はリアルタイムでは内容がいまいち頭に入らず、あとから見直してやっと何言っていたのか分かるという状態でした。
なんも構えず聞けばよかった…。

全体としての感想

*1:個人的には得るものがあった

*2:実行時間の長いケースから順に実行するということ？

*3:内容もかなり切り口が異なる同じ内容だったけど、それはそれで色んな視点を提供してくれるので良いこと。LTだし、casualだし。

*4:もしかして内容も？