非プログラマ集団ではじめるテスト自動化〜SeleniumIDEを採用した経緯

前回から間があいてしまいましたが、
非プログラマ集団ではじめるテスト自動化第2話です。
今回はSelenium IDEを採用した経緯をお話したいと思います。

導入を選定したのは2015年初頭頃であり、
現在状況も変わっている部分もあると思いますので、不足点あるとご指摘いただければ幸いです。

#Seleniumを使う目的
主に以下のテストの自動化を対象としました。
####対象
・手入力のテスト(文字種、文字数制限のテスト)
・表示内容のテスト(エラーメッセージ、表示項目のチェック)
・検索条件のテスト

####解決できる問題
・再帰試験として既存の試験項目をすべて実施することの時間的な制約
・同じ試験を繰返すことによる、検証者の心理的な負担
・影響個所の洗い出し漏れによるデグレの発生
・開発⇔検証者間の仕様齟齬
・エビデンスの取得

#実装メンバーについて
品質管理メンバー内で進める事を前提に考えており、
プログラマ経験の無いテスター3〜4名でのスタートを想定していました。
そのため、ある程度のルール化や実装のしやすさ、容易に導入できることを重視しました。
また、テスターとして仕様を理解しているのがアドバンテージだと思いましたので、そのメリットを活かせればという思いもありました。

#Seleniumの実装方法の選定
Seleniumには大きく分けてSelenium WebDriver/Selenium IDEと2通りの実装方法がありますので、それぞれのメリット/デメリットを整理の上、選定しました。
Seleniumの概要の理解は下記が参考になりました。
Seleniumとは
Selenium何とかっていうツールがやたら色々あるのはどういうわけなのか

##Selenium WebDriver方式による実装
####特徴
・テスト実行時のブラウザ操作を、JavaScriptではなく、ブラウザの拡張機能やOSネイティブの機能を使い、
JavaやRubyにてプログラミング実装をする。

####メリット
・javascriptによるブラウザのセキュリティ制約を解決。
・メソッド化や共通化ができるので、メンテナンスが容易
・WebDriverスクリプトはコマンド主体でテストが容易に実施できるため、CIツールとの相性もいい。

####デメリット
・プログラミング未経験者にとってはJavaやRuby等のプログラミングの理解から始める必要がある。
・Seleniumとプログラミング2点の問題が生じ、切り分けに時間を要する事が想定される。
・Selenium Builderという統合ツールもあるが、後述するSelenium IDEほど使い勝手はよくない。
　Selenium IDEから比較すると以下が不足している
　• 簡単に記録できるAssert・Verifyコマンドが、verifyTextPresentコマンドのみ
　• 変数を複数のテストケース間で共有できない
　• Firefox以外のブラウザでの再生
　• データ駆動テスト
　• if文、for文、while文

##Selenium IDEによる実装
####特徴
Firefoxにプラグインをインストールする事で、容易にテスト自動化を開始できる。
Webブラウザの操作を記録できる。

####メリット
・Seleniumの仕様を理解するには一番わかりやすいツール。
　※Seleniumの実装やエラーの切り分けにはある程度のコツがいるため、初心者にはSeleniuIDEからはじめるのがとっかかりやすい。
・テストケースを直感的に作ることができる。
・統合環境の為、ほぼ完結してテストケースを作ることができる。
・アプリとして枯れている為、動作もある程度安定している。

####デメリット
・独自のRCコマンドを覚える必要がある。
・WebDriverスクリプトの読み込みができない
・WebDriverが主流になっているので、ノウハウ等情報が少ない。
・CIツールとの連携ができない。
・SeleniumIDEが読み込み/保存を主体とするのは旧形式（RCコマンド）のため、コマンド実行に寄るノウハウやCIツールとの連携の情報が不足している。
　※ただし、Webdriver方式にエクスポートする事はできるので、無駄になる事はない。
・条件分岐やループ処理などが入るとjavascriptの知識が必要で、処理が複雑化する。
・Seleniumコマンドをメソッド化できない。
　※javascriptコマンドをメソッド化できるが、メソッド化は限定的なものになる。
・マルチブラウザにほぼ対応できない。
　※一部できる方法もあるようだが、いろいろと制約があるようで、最新のブラウザでは実行できなかった。
・まとめて実行できるレベルがテストスイート単位になり、テストスイートが増えれば増える程運用が難しくなってくる。

#Selenium IDEを採用した決め手
一人で自動化を進めるのは困難であり、品質管理メンバー（非プログラマ）の協力があって進められるものだと思いましたので、スタート時には飲み込みやすさや使い勝手の良さ、導入や運用のしやすさを重要しました。

また、Slenium IDEの最大のデメリットはCIツールとの連携がしづらい点ですが、運用の工夫をすれば
CIツールが無くても自動化テストはできますし、そこまで困る事はありませんでした。
ただし、テストスイートをたくさん増やしてまとめて実行する等のケースには向かないと思います。

ソースをまとめてWebDriver方式にコンバートしてくれるツールや、
置換バッチを作れば容易にWebDriver化できることも分かりましたので、
作ったソースが無駄になる事はない事も分かりました。

Selenium IDEのデメリットもいろいろとあげましたが、以上がSelenium IDEを採用した経緯です。

Slenium IDEを使っての運用やWebDriver方式への移行方法などについては、次回お話してみたいと思います。