読者です 読者をやめる 読者になる 読者になる

Web Service QA Meeting Vol.1に参加してきました #webqa.meeting

昨日(7/13)、Web Service QA Meeting Vol.1 があったので参加してきました。

peraichi.com


ツイート上では、 #webqa.mtg とか #webqa *1とか書かれていましたが、きっと #webqa.meeting が正解なんだと思います。

登壇者のメンツ及び観衆のメンツがそうそうたるメンバーでした。

今回の勉強会は事前のプレゼンを聞いて、投票の結果、多数を占めたプレゼン3名が実際に発表できるという形式でした。

発表順に、発表の内容とか感想とかを書いていきます。

 

若手枠 Webの自動テストの進化

自己紹介

  • 木住野奈夫人
  • 株式会社ネクスト

自動テストを始めるきっかけ

  • 影響範囲がわかりづらい
  • 手動テストでは見きれない
  • メインの機能がシンプル

→自動テスト向き

 

ネクストの自動テスト

  • テストタイプはシステムテスト
  • 一般的な自動テストには問題があった(次の項以降で紹介)

自動テストの導入

  • Selenium IDEでユーザーシナリオ
  • DOMで取得
    • プログラムっぽいことが難しい
    • 記述が重複する
    • 追加も改修も大変

テストのスクリプト

  • Selenium WebDriverの導入
  • ページオブジェクトの導入
  • テスト量産する
  • 全機能の網羅を目指す
    • 1200ケース作成
    • 週4回のテスト実行
  • 量産は成功したがメンテナンスコストがかかる
  • テスト実施、結果確認メンテナンスが大変
    • 「今日、結果確認しかしてないじゃん」
  • 操作再現によるE2Eテストの限界

自動テストの最適化

  • 新しいテスト手法の開発
    • データ駆動
    • 期待値の分解
データ駆動

テストスクリプトとテストケースを分解すること

期待値の分解
  • テストケースの分解
    • 問い合わせを行う
    • ページを開く
    • ページ上でJSが走る
    • 問い合わせボタンを押す
    • ページ上でJSが走る
  • 期待値を3パターンに分ける
HTTPステータスチェックテスト
  • E2Eテストとくらべて実行速度が速い
  • エラーが少ない
    • タイミングのズレによるエラーも少ない
JSチェックテスト
  • E2Eテストと比べて
    • 実行速度が速い
    • バグの検出率が速い
E2Eテスト

主要機能は従来のままで

 

感想

ステータスチェックのテストについて考えるところがあって…とか思ったけど、 @kokotatata さんが既に語っていました。(先を越されてしまった…)

 

kokotatata.hatenablog.com

 

発表者の木住野さんがその場にいたということもあり、イベント後の懇親会でもこの部分は熱く語ったのですが、自分としてはステータスチェックは大きく分けて2つの目的があるかなと。

 

1. テストケースの1つとして

ページを開くという動作そのものに対してのテストケースとしての意味です。

これは今回の発表で木住野さんが伝えていた内容だと思います。

特に、ページ数が500万ページという膨大な数を保障するというところに重きを置いた方法なんだと感じました。

 

2. 自動テストの前処理として

ギア本第6章でいう、前処理のチェックの項目としての意味もあると思います。

(下のスライドの8枚目の部分です)

 

www.slideshare.net

ステータスコードが正しく返ってこないページに関しては、それ以上ブラウザの自動テストをやっても意味がないので、それを判断するためには必要なのではないかと考えています。

 

前処理をどのようにして行うか、テストケースをどのようにするかなどは、ギア本の読書会の中で意見を聞いて、以前の記事にまとめているので、そちらも参考にしていただければと思います。

nihonbuson.hatenadiary.jp

 

ベテラン枠1 WebサービスのソフトウェアQAと自動化戦略

自己紹介

  • 中川 勝樹
  • 株式会社ディー・エヌ・エー
  • SWET(Software Engineer in Test)グループ
    • 『テストから見えてくるグーグルのソフトウェア開発』に刺激を受けた
  • Testing Casual Talks主催者

Testing Casual Talks #2については、以前に記事でまとめています。

nihonbuson.hatenadiary.jp

やっていること

  • 自動テストコード作成
  • テスト基盤環境構築
  • 自動化技術の応用・実用化など

WEBサービスのQAを考える

  • WEB以外の分野のQAとは
    • ハードウェアの製品は人命に関わることが多い。
    • QAで必ず取り除かなければいけない
    • 出荷後に全ての製品をアップデートするのはほぼ不可能
  • WEBサービスのQAを考える
    • 多少の問題は後からでもリカバリ可能
    • 様々なユーザーに使ってもらって初めて分かる事実がある
    • 価値提供のスピードを落としたくない
  • WEBサービスのQAでやりたいこと
    • いかにQAのスピードを落とさず"リリースさせるか"

テスト戦略

MVCモデルから考える

  • Viewは統合テスト中心
    • 自動化出来る部分とできない部分がある
  • Modelは単体テスト中心
    • テストが重複しがち
  • Controllerはグレーボックスを行う
    • 開発者がしっかりテストする

Modelのテスト

Viewのテスト

  • ユーザーシナリオに沿ってE2Eテスト
  • 表示・レイアウトの確認
  • ユーザビリティテストは手動テストで

Controllerのテスト

  • 重複する部分はやらない
  • ViewとModelからトータルでしっかり抑える

エンジニアの三大美徳

  • 怠惰
  • 短期
  • 放漫

まとめ

  • 如何にスピード感を落とさずにリリースさせるかが重要
  • そのために必要なことは揃っている状態であるべき
  • テスト戦略
    • 無駄なところはやらない
    • 自動化出来る部分は自動化する

感想

「いかにQAのスピードを落とさず"リリースさせる"か」という考え方は刺激を受けました。

この「リリースさせる」という考え方は難しいと感じていて、この考え方をもって実行できる裏側には、最低限保障すべき基準が存在しているのではないかと思っています。

流石に主要機能のページ遷移すら上手く行かないのにリリースするというのは出来ないと思うので。

それが機能やバグの優先度なのか、それともリリースの最低基準なのか、はたまたそんな基準は無くても上手く回っているのか聞いてみたかったです。

 

ベテラン枠2 WEB系おっさんQAの失敗と後悔と不思議なバグ

取っていたメモが消えてしまっていました…。*2

なので感想だけ。
色々な話(ネタ?)が放り込まれていましたが、一番印象に残っているのは「ヤマミト」の話*3です。
帰る間際に登壇者の山本さんと少しだけ話をしたのですが、その時の「どこまでテストをすれば良いんだよ」という言葉が合わせて印象に残りました。

 

テストケースを減らす施策というのはなかなか難しくて、その代わり無駄なテストケースを増やさないようにするためにテスト設計をきちんと行おうという話に行きがちだと思っています。
しかし今回紹介されていたバグとかまで考慮すると、適切(と一般的には思われる)テストケースを作ったがために、抜けが発生してしまう恐れがあるなと感じました。
(五十音をアからンまで最低1回は使うようなテストケースを作ろうと設計時に普通は考えないと思います)

 

全体の感想

面白い試みだと感じました。
特に今回は第1回なので、次回以降も継続的に続いていくような勉強会になって頂ければと思います。(次回もすぐにある予定らしいですよ!)

現在、定期的に開催されているWEBQA関係の勉強会は「Ques」「Testing Casual Talks」の2つぐらい(しかもTesting Casual Talksは最近再開した勉強会)だったので、こういう関連の勉強会が増えてくれれば嬉しいです。

あ、ギア本の読書会も続いていますので、この記事を読んで下さっている方は是非!(ギア本には載っていない現在のQAの話とかも合わせて行っています)

 

*1:#webqaというツイートが多数を占めていたのは、twitterハッシュタグではドットが入ったら終わるという仕様のためです。

*2:「WEB系おっさんQAの失敗と後悔と不思議なバグ」というタイトルのファイルの中身が「WebサービスのソフトウェアQAと自動化戦略」に関することだったと分かった時、すごいショックを受けました…

*3:他の人のテストケースは全て通るのに、「ヤマモト」だけ「ヤマミト」と表示されてテストケースが失敗する話