やらなイカ？

たぶん、iOS/Androidアプリの開発・テスト関係。

Selenium勉強会＠サイボウズに行ってきました #selenium_cybozu

Testing

10/20にサイボウズ株式会社さんで開催された『Selenium勉強会＠サイボウズ』に行ってきました。

connpass.com

以下、メモ残したものだけ。内容すべて拾ってはいないので注意。

Selenium Conference 2015 参加報告

サイボウズの宮田さんより。

  • Selenium Conferenceは今年で5回目。今回はポートランドで開催。
  • 初日はワークショップ、2・3日目はセッション。セッション動画は公開されている
  • ランチ時も含めて、参加者間での議論も活発だった

面白かったセッションの紹介

  • FacebookのSimonさんのKeynote
  • Selenideの話
    • Selenide == Javaで書かれたSeleniumクライアントラッパー
    • smart waiting: shouldHave()で画面遷移・描画を待ってくれる
    • collection
    • automated screenshot
    • sizzle selectors
    • profiler
    • fast setVelue: JSでsetValueを置き換える（setValueの実行が遅いのを改善）
  • Selenium Grid Auto scale
    • AWSで構築
    • hub一つで、250並列
    • hub二つで、500並列
    • ネットワーク帯域を増やして、1000並列

テンプレートエンジンにMixer2を使うとSeleniumでのテストもラクになるかもよという話

ビズリーチの渡辺さんより、テンプレートエンジンMixer2がSeleniumによるテストと親和性が高いという話。

  • Mixer2は、Javaで書かれたテンプレートエンジン
  • DSLでなく、htmlのspan id/class指定を置き換えるエンジン -> SeleniumでXPath書かずに済む
  • XHTMLとJavaのObject変換が双方向 -> テストコード側では、パースして得たJava Objectに対してassertを書くことができる

SikuliXを知っていますか？

小原さんより、SikuliXの紹介と、Seleniumとの連携について。

  • sikulixからseleniumを呼ぶ
  • sikulixをライブラリとして使う
  • sikulix IDEで簡単にコードを書いたり、実行できる
  • Sikuliの開発をMITから引き継いだ時、xをつけてsikulixになった

本当にメンテナブルなSeleniumの運用について考えてみた

一休.comの赤坂さん

  • Seleniumのテストは、リグレッションテスト向けに書いて実行している
  • テストケースは30、8並列で実行
  • 本番環境は5〜7分、ステージングでは8〜10分
  • 最低限のシナリオ
  • 運用していくためにはどうするか
    • Page object design patternは手段の一つ
    • メンテナを増やす
      • 説明会、ドキュメント、継続的にアウトプット、自分でメンテしないで機能を実装した担当者にやらせる
      • フォローは喜んでやる

kintone開発を支えるSeleniumテスト

ふたたびサイボウズの宮田さん。kintoneの開発での実例。

  • 自動テストは一度壊れて放棄。『継続的デリバリー』を読んで再チャレンジ
  • テストケースは1000くらい
  • QAがテスト設計、PGが自動化実装
  • Java + WebDriver
  • 新機能追加時に受け入れテストも書いている
  • 既存機能は、手の空いた時に追加。優先順位はリスクを考慮してQAが決定
  • メインブランチに変更が入るたびテスト実行。落ちたらチャットで晒しあげられる
  • メンテナンス性
    • page object
    • 失敗時にスクショを撮る。動画も試したがリソースが辛かったのでやめた
  • コード品質を高める
  • 安定性の向上：リトライ回数。画面遷移待ちなどはラッパー（Selenideなど）でサポートされている
  • 実行時間；余計なテストは作らない、単体テスト等でカバー
  • IE, Safariはやってない

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

Seleniumデザインパターン & ベストプラクティス

Seleniumデザインパターン & ベストプラクティス

クックパッドエンジニアのトークナイト 〜クックパッドテストエンジニアのあり方〜 に行ってきました #cooketn

Testing

クックパッド株式会社さんで開催された『クックパッドエンジニアのトークナイト 〜クックパッドテストエンジニアのあり方〜』に行ってきたメモ。

connpass.com

クックパッドテストエンジニアのあり方

松尾さんのスライドに沿って、要所要所で t_wadaさん、諸橋さん、yoshioriさん含めたパネルディスカッションが入る進行。

www.slideshare.net

以下、メモ。

  • クックパッドでは、"Quality Improvement"と位置づけられている。品質"保証"ではない
  • 呼び方：QA、テストエンジニア、テスター、etc...
  • 募集から見てみると、やはり様々
    • Test Engineer @Google
    • Senior Software Engineer @Netflix
    • SWET @DeNA
    • テストエンジニア @cookpad
  • Qualityとは？
    • 「品質とは誰かにとっての価値である」
    • あなたのビジネスは何を生業としていますか？
      • 自動車など、製造業：腐食など経年劣化まで含めて保証 -> Quality Assuranceという考え方
      • 受託開発：納品のため。合意形成した指標を満足する。また、それを示す。 -> これもQuality Assuranceでok
      • サービス業：利用時の品質、ISO 25000, ISO 9241, ITILなど。対人なので「保証」はそぐわないのでは？
        • 価値検証を「しっかり素早く」し、改善を繰り返して品質を「向上」させる
          • TDD/BDD、自動化されたテスト、内部品質を高める
  • TDDと品質
    • 5年くらい前に炎上した話題。5年経過した今は？
    • t_wadaさん：
      • 厳密なTDDをやってる人は少ないけど、自動テストを書いている人は増えている、という印象。業界/会社ごとに乖離している。
      • 炎上の原因。「テスト駆動開発」の「テスト」という言葉。testでなくchenkだよねという話。「テストとは対象を破壊しようとする試み」（マイヤーズ『ソフトウェアテストの技法』）を前提とすると、TDDのテストとはcheckingである。
      • 開発者テストは書く習慣がつくと、なかなかやめない。
      • 割り切って考えられるエンジニアが増えた。「それはTDDじゃない」みたいなTDDの定義の話でなく、自分のスタイルでテストは書く、という方向。
  • サービスの開発速度を高めるために補完されるテスト
  • テストエンジニアに求めているもの
    • t_wadaさん：テスト書きすぎ問題。適切に減らすのが難しい。どこまでテストするのか
      • see: 直交表、ペアワイズ法。ツールとして、PICT、PictMaster
    • 諸橋さん：不具合のパターン、ユーザのイレギュラー操作を突くテストケース
  • サービスの開発速度を高めるための組織
    • 専業化していく？ Quality Engineer, Software Engineer in Test, Test Engineer, etc...
    • クックパッドでは、今：土台作り、テスト環境の改善。発展させていきたい

ソフトウェア・テストの技法 第2版

ソフトウェア・テストの技法 第2版

  • 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
  • 出版社/メーカー: 近代科学社
  • 発売日: 2006/08
  • メディア: 単行本
  • 購入: 7人 クリック: 267回
  • この商品を含むブログ (46件) を見る

質疑応答

  • テストエンジニアを募集したけど集まらなかった
    • テストエンジニアはそもそも少ない
    • 欲しいスキルセット、応募側のスキルセットの解離があるのでは？ GoogleやNetflixのように、ちゃんと名前をつけるべきでは？
    • 海外/外資だとQAの地位が高い。知識も高い。まず松尾さんが高給取りになるべき
  • テストコードがないプロジェクト
    • まず自分だけでもテストを書く。徐々にまわりに広げる
    • 先にCIサーバを立てて、静的解析やインスペクションだけでもまわす。周りに、面白そう、楽そう、という印象を与えて広める
  • テストの過不足、十分性
    • 足りている状態を定義、どこをokのラインとするか。正常系を優先とか。リスクの高低で評価する
    • 組み合わせテストも、組み合わせ数の十分性がレポートとして出ているので基準にできる。判断根拠の資料は残すべき。
  • End to Endテストは誰が書くべきか
    • 諸橋さん：E2Eのシナリオも開発者が書く限りchecking。テストエンジニアによってtestingに持っていく
    • yoshioriさん：black box/white boxで考える。E2Eはblack boxで中身を知らない人が書くべきなので、分業が理想
    • 松尾さん：checkingは自動で判断できるところまで。ユーザビリティなど人間がやるところがtestingという切り分け
    • t_wadaさん：気付かないものは気付けないので、それが開発者テストの限界。テストエンジニアが探索テストで見つけた不具合を自動テストで再現して自動テストに取り込んでいく。checking を拡張してtestingに。ランダム性、揺らぎを取り入れることで自動テストを拡張する

所感

特に「開発者テストをやってる人」「テストエンジニア」どちら向けともアナウンスされていないイベントでしたが、参加者も両方混在だったような雰囲気でした。

テストエンジニアに求められるものはどんどん高度化していく（けどまだ地位が低い）ので、うまく開発者側と補完しあえる組織の事例が増えていくといいですね。