「第二回 システムテスト自動化 標準ガイド 読書会」を開催してきた
「第二回 システムテスト自動化 標準ガイド 読書会」を開催してきた
著者:ふじさわゆうき
更新日:2015/05/24
読書会概要
ソフトウェアのシステムテストの自動化に取り組むエンジニアにとってバイブルともいえる名著の「システムテスト自動化 標準ガイド」を1回2章ずつ進めていこうという勉強会です。
前回、第1章と第2章で、今回は、第3章、第4章でした。
- ハッシュタグ
- 2015/04/18(土)
- 2015/05/23(土)
関連ブログ・記事
- 勉強会レポートブログ
- 第2回テスト自動化標準化ガイド読書会におけるディスカッションメモ
関係者への御礼
- 「第3章スクリプティングの技法」を担当してくださった、@TakaakiOnoさん, @d_noguchiさん, @camxxmaさん、ありがとうございました。作成していただいた発表資料が良くまとまっていて、さらに、ディスカッションを盛り上げてただき感謝です。
- 「第4章 自動比較」を担当してくださった、@toku_toku3さん、ありがとうございました。3日徹夜したうえで発表していただいたのにも関わらず、良くまとまっていてよかったです。私なら3徹した後にあの発表は無理です(笑)
- いしじあつしさん、会場の手配、準備、片づけ、懇親会会場の手配、発表者のフォローなど色々と、コミュニティ運営、お疲れ様でした。いしじあつしさんさんがいなければ、今回も勉強会が成立しませんでした
- 前回に引き続き、司会、進行を担当してくださった、@nihonbusonさん、ありがとうございました。当日、スムーズに勉強会を進めることができたのは@nihonbusonさんのお蔭です
- 一緒に懇親会で語った@kanno_kannoさん、@_mirerさん、@azusaさん、@HiroakiTakahashiさん、ありがとうございました。最近の私の悩みや失敗談に突っ込みをいただき参考になりました。アドバイスを踏まえて、「相手の立場を理解する」ってことを意識して仕事を進めていきたいと思います。ブログでかける範囲で一番、印象に残ったのは「良いエンジニアの条件として、学歴は関係が無い。GitHubに自分のコードを上げたり、ツイッターで技術系の投稿を多くしたり、プログラムが好きだったり、そういうことが重要だ」ってところでした。
- 参加者の皆様も、一緒にディスカッションを盛り上げていただきありがとうございました。
- nedateさん、masatoshiitohさん、Programmerさん、makopi23さんsazanamiさん、dd_takakazuさん、megurunsさん、kz_suzukiさん、takahiro_itoさん、yamanotakahiroさん、sodaさん、shige-ponさん、i8_5327637さん、masafumi_umemuraさん、kuniiskywalkerさん、ANA_KUMAさん、yoshizawaさん
第3章スクリプティングの技法
- 共有スクリプトの短所について、「私の仕事上でも困っているなー」ってこと。
私が所属している自動化チームの現状としては「構造化スクリプティング」「共有スクリプト」「データ駆動スクリプト」を組み合わせて、スクリプトを作っているけれど、「共有スクリプト」の管理は、正直、困っています。自動スクリプトを書いていると「あれ?このロジック、似たようなやつが複数あるじゃん」みたいな感じですね。解決していきたいな。。
- 共有スクリプトの長所
- 似たようなテストを実装する工数が少なくなる
- メンテナンスコストがリニアスクリプトより小さくなる
- あからさまな繰り返しをなくせる
- 共有スクリプトにもっと知性を持たせることができる
- 共有スクリプトの短所
- 把握、ドキュメント化、名前付け、保管の対象となるスクリプトが増える
- すべてのテストに特有のスクリプトが必要となりメンテナンスコストが高いまま
- 共有スクリプトはテスト対象ソフトウェアの 一部分に特化されたものになりがちである
- キーワード駆動スクリプトをできている会社がいたことに驚き
- 参加者の方も交えて、「現在実施しているスクリプティングはどれでしょうか?」というディスカッションをしたところ「キーワード駆動スクリプト」を実施している会社様が3社ほどいました
- 1社目は、現状は、「カオス」の一言でした。組織的には、テスト作成者とテストオートメータが分かれていて、その方は、テスト作成者側の人だったのですが、「こっちのキーワードが通るようになると、あちらのキーワードが失敗になる」みたいな現状とのことです。きっと、良い点もあると思うのですが、悪い点のほうが目立ってしまって、「カオス」って感じなんでしょう。
- あと、残り2社は、「うまく回っている」とのことでした。ただ、上手くいっている要因は、聞く時間がありませんでした。是非、今後、参考にさせてほしいです
第4章スクリプティングの技法
- 動的比較、実行後比較をわけて解説する必要はあるのだけど、わかりにくい
- 動的比較とは、テストケースを実行しながら比較する手法のこと
- 色々なツールでサポートされており人がチェックするのと同じように、画面に表示され るものをチェックするのに適している
- 実行後比較とは、テストケースを実行した後に行われる比較のこと
- 生成されたファイルやDBなど、画面出力以外のものを比較する際によく用いられる !
- サポートしてるテスト実行ツールがあまりないの で、個別のツールを利用することが多い
- 動的比較というと、xUnit系でassertすることが代表的。しかし、Eclipseだと、「動的比較」だし、Jenkinsだと、実行後に比較結果がでるという意味で「実行後比較」に思える
-
「動的比較」「実行後比較」の話で後者が、「後で人が確認する」「失敗したときに確認する」みたいに解釈されているようで、難しいなと思った。比較するのはあくまで機械ですね。/
「第二回 システムテスト自動化 標準ガイド 読書会」に参加してきたhttp://t.co/uy3dwD46Rv
— Kazu SUZUKI (@kz_suzuki) May 24, 2015
- 上記ツイートのように「実行後比較」というと人が比較するものと勘違いが発生したりする
- 画像比較は自動化しなくてもいいんじゃないかな
- 画像比較は、出席者の方もいっていたが、センシティブなので自動比較はしていないとのこと
- 自動化するなら、imagemagickを使う
- Comparing -- IM v6 Examples
- まとめで「ビットマップの比較を避ける」みたいのがあるし
- センシティブとロバストの度合いはとても重要
- 画像比較のようなものが一番センシティブ
- assertで一つ一つ期待値と実行結果を一つ一つ比較していくのがロバスト
- という理解
- センシティブの感度を下げていくのはフィルター(常に失敗してしまう日付を固定文字に置き換えたりすること)を使うことで実現できる
- センシティブなテストに対して、どの程度までフィルターをかけて、ロバストにしていくのか?その追及は、私のチームでも実施していきたい
次回の勉強会予定
- 7月4日(土)に次回開催予定
- 5章、6章です