5分でできるWebテスト自動化 - Jenkins x Selenium

いろいろあって、しばらく投稿さぼってました、、、＾＾；
ここ最近アウトプットをさぼり気味なので、今日からまた再開します。


さて、テストクラスタの方やWeb系エンジニアであれば、SeleniumというWebテストの自動化ツールについて聞いたり、実際に利用したことがあると思います。


Selenium IDEなどを使ってテストスイート単位で自動化することもできますが、JenkinsというCIツールを使えば、テスト実行およびレポーティングまで完全自動化することができます。


JenkinsはWindowsマシンでも簡単に構築できます。
今回はツールのセットアップ（Windows版）と基本的な使い方まとめたいと思います。


尚、Seleniumはスタンドアローン版がセットアップされていることを前提にしています。
（セレマニア｛注：Seleniumオタク｝のひとは、特に説明不要だと思うので、JavaやPythonなど、各自好きな言語でかかれたテストコードを直接起動してください＾＾； ）

環境構築

 

参考サイト

JenkinsにSelenium Html Reportをいれてみた。 | SeedsLight:

http://seedslight.com/wp/archives/185

１.JDKインストール＆環境変数設定

https://www.google.co.jp/search?q=JDK

※JREではなく、JDKが必要なので注意（DL前にOracleに登録が必要）

JAVA_HOME=C:\Program Files\JavaFX\javafx-sdk1.3

SDK直下のbinにもパスを通す。

２．JenkinsのDL

http://jenkins-ci.org/

Windows版をDL

３．ダウンロードした jenkins.war を直接起動

java -jar jenkins.war

→デフォルトでは　http://localhost:8080　にサーバーが立つので、ブラウザからアクセスして確認。

※セキュリティーソフトなどでブロックされる場合は、適宜設定変更してください。

ジョブ作成

次に自動実行のためのジョブを作成します。

１．新規ジョブ作成

とりあえずフリースタイルを選択します。

２．作業用フォルダの設定

スクリプトを実行する場合は、カスタムワークスペースを設定。
※スクリプトをフルパスで指定する場合は必要ないかもしれませんが、一応設定します。

３．ソースコード管理

利用しない場合は「なし」を選択

４．ビルドトリガ設定

ここではスクリプトの実施タイミングを設定します。

     
↓書き方の例（詳細はJenkinsのヘルプを参照）

# 1分ごとに
* * * * *
# 毎時5分(1時間に一度)

5 * * * *

# 30分に一回
*/30 * * * *

５．ビルド手順追加

Windowsバッチからのスクリプト実行の場合は、「Windowsバッチコマンド」を選択する。

以下はSeleniumスタンドアロンサーバーの例。

rem Firefox

java -jar selenium-server-standalone-2.18.0.jar -htmlSuite "*chrome" "http://www.google.com" "C:\selenium\suite02.html" "c:\selenium\result01.html"

rem Chrome(日本語が化ける？)

java -jar selenium-server-standalone-2.18.0.jar -htmlSuite "*googlechrome" "http://www.google.com" "C:\selenium\suite03.html" "c:\selenium\result02.html"

＊＊＊

手始めに以下のようなサンプル用コマンドを書いて、ジョブの実施のみを確認してもOKです。

echo im enjoying testing with Jenkins!

date /T

＊＊＊

６．成果物保存

作業ディレクトリにあるスクリプト実行結果ファイルをバッチ実行毎にアーカイブする場合は、「成果物を保存」にチェックを入れて、

**/result*.html

のような形式で保存ファイルを指定します。

上記例ではファイル名がresultで始まり、拡張子がhtmlであるファイル（サブディレクトリも含む）をアーカイブします。

実行結果確認

１．ルートメニューで確認

２．プロジェクトメニュー

直近のビルド成果物や、即時実行、設定などが可能です。

３．ビルドログ

プロジェクトメニューの左側ににある「ビルド履歴」から遷移します。

「コンソール出力」でこのビルド実施時に出力されたコンソールのログ情報が確認できる。

また、「ビルドの成果物」で、バッチ毎に保存したファイルがDLできる。

最後に

JDKインストールに時間がかかるかもしれませんが、びっくりするぐらい簡単に自動テスト環境が構築できますので、ぜひ試してみてください。

いやー　このシステムは開発してくれた神プログラマに感謝感激ですね。

テストにおけるヒューマンリソースの効率性

最近悩みがあります。

それはテストにおける人の管理についてです。

狼を撃つ銀の弾丸がないのは、ソフトウェアテストにおいても同じです。

でも、”テストを実施する”という作業自体には、プログラマほど専門知識がなくてもこなすことはできることは事実です。（意味のある、効率の良いテストを実施できるか否かは別にして、、、）

テストに関して経験の浅い組織では、「テストなんて誰でもできるでしょ」と安易に考えがちですが、

それはテストを設計したり、管理したりする人の負担を無視した危険な発想です。

そして"狼を..."の話に戻りますが、やっぱりそれなりの経験があるひとをアサインし、効率の良い配置で、コミュニケーションを十分にとりながら進行していくことで、初めて意味のあるテストができるようになります。

前置きが長くなりましたが、用は「それなりの経験があるひとをアサインし、効率の良い配置」という部分が悩ましい点なんですね。

当然テストを管理する人間だけでなく、テストを実行するためのリソースは必要です。ではテスト実施のための専任担当者がいたとして、テストが終わった後に、彼らは何をすればいいのでしょうか？

ソフトウェアや開発の勉強？ テストの上流プロセスの勉強？

ともかく人数が多すぎると、あぶれてしまうんですね。。。。

今の時代、品質にそれほどお金を掛ける余裕はない組織が多いと思います。そんな状況でテスト担当がいっぱいいても、単にコスト部門と見なされる可能性が高いです。

すぐに思いつく対策はいくつもありません。

１．より効率的なテストを実施するために勉強する時間が必要であると上層部を納得させる

２．単発で仕事してくれる派遣会社に頼る

３．努力と根性を武器に最少人数で乗り切る

４．ほかの部署から人を借りる

一番最悪なのは3番でしょう。離職率が跳ね上がり、それに反比例して品質は下落します。

品質の重要性を意識している会社なら、1番の選択肢もありえるのではないでしょうか？

2番は結局管理のコストがかかりますね。

４番は表面上は金のかからない方法ですが、そもそもテストに関してネガティブな先入観を持ってる人が多い組織では、どの部署も人を出すことを渋るでしょう。

4番が良い気がしますが、プロセスをスムーズにまわすためには、啓蒙活動を通して正しいソフトウェアテストの知識を広めてからでないと、うまくいかない気がします。

どれも一長一短ですね。

20

JSTQB カンファレンス in 2010

JSTQB カンファレンス in 2010
http://jstqb.jp/event/conference2010.html

10月14日開催です。

Rex Blackさんいらっしゃるみたいですが、同氏のチュートリアルは大人気で、発表後すぐに締め切ってしまいました。

セッションには参加する予定なので、そのうちまとめなど書こうと思います。

ソフトウェアテストメトリクス

最近ソフトウェアメトリクス収集に関するQAガイドラインを作ったので、
その内容を少しだけ書こうと思います。

 「計測できないものは制御できない」とは、著名なソフトウェア工学者トム・デマルコさんの言葉です。
 メトリクスとは指標を意味し、ソフトウェアメトリクスとは「ソフトウェア開発プロセス全般に亘って、定性的な情報を数値化して計測管理すること」を指します。

品質管理はプロセス管理であるという原則に従って、QAプロセスもある程度数値化して管理
するとこが重要だと考えます。たとえば何か問題が発生したとき、数値化して管理していないと上層部に対する報告も主観的であいまいなものになり、本来のQAの目的である「リスク管理」が正しく実施できなくなってしまいます。またメトリクスをほかの部署に対するマーケティングに利用したり、上層部対する予算確保の根拠などにも利用できます。

このメトリクスを決めるにあたって、注意するべきポイントがあります。

1. メトリクスの評価対象はあくまでプロセスそのものであり、個人の業務評価に使用してはならない
2. 収集の目的を明確にしなければならない
3. メトリクス用データ収集作業が、実務を阻害してはならない

まず１番に関して補足すると、特にマネジメント層にある人は部下の業務評価の材料としてメトリクスを利用しようと考える傾向があるのではないかと思います。しかしこれは大きな間違いで、そんなことをしたら、部下は積極的にメトリクス導入に賛成せず、また正直にデータを集計したりもしないでしょう。メトリスクの収集はあくまでプロセスの管理・向上を目標としていることを明確にすることが大切です。
２番はあえて言及するほどことではないかもしれませんが、メトリクスの収集にあたってはその指標をどんな目的で使うのかを共通認識として持つことが大事です。データの意味や目的がはっきりしていないと、それを有効に使うことはできません。
３番も非常に重要で、メトリクス収集は通常業務の妨げにならないように、その仕組みを体系化し、簡単に繰り返し実行できるようにすることが求められます。つまり最初から欲張って完璧なデータを収集しようとせずに、簡単に実践できて結果が見えやすい指標から試すことが大事です。

ここまでが、ソフトウェアテストメトリクス導入のおおまかな指針です。実際にどのような値を収集するかは、その会社のビジネスモデル、開発プロセス、品質管理方針などによって千差万別だと思います。一般的な指標としては、DRE（欠陥除去率）やTCE（バグの総数に占めるテストケース貢献率）などがあります。


それぞれの指標をどのように収集・活用していくかに関しては、また後日書きたいと思います。

60

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合

プレジデント 5.17号から。

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合、QAマネージャーはどうすればいいのでしょうか？

選択肢はいろいろあると思いますが、最も重要なことは、まわりの状況をよく観察しその命令の背景を探ることです。

命令の内容が一見無計画で場当たり的に見えても、実際に調べてみると、その裏には、ステークホルダー（主に経営者、投資家、親会社など）の意向や政治的な妥協が潜んでいる可能性もあります。そのような場合に、「この計画は欠陥だらけで会社にとっても不利益にしかならない」などど声を張り上げても、まったく無意味です。

批判した本人は会社やユーザーを第一に考えて、論理的、道義的に意義を唱えたつもりでも、他人にとっては単なる戦略に対する批判者ぐらいの印象しか持ってもらえないでしょう。命令した本人でさえも、問題を分った上で自覚的にやっている場合もあります。

批判を繰り返していると、次第に周りから疎まれてしまいます。私も一度このような状況に陥ったことがあります。

大事なことは「合理的な理由を論理的に主張したとしても、それが会社（上司）の意図と合わなければ会社組織の中では何の価値も生まない」ということを理解することです。息苦しいですね、、、、

もちろんいざという時は、戦うことも必要でしょう。でも、負け戦をやるのは賢い方法ではありません。

とは言っても、無理難題を全て引き受けていたら、自分も部下も潰れてしまいます。そうならないためにできることは４つあります。

１．直属の上司または同僚に命令の背景に関して相談すること
２．自分はどの程度裁量を持てるのか確認すること
３．責任の範囲を明確にすること
４．リスクに関して事前に言及しておくこと

１に関しては、やはり命令の背景を知ることで、その本質が見えてくる場合があるためです。知ってみると実は命令そのものは重要ではなく、単なる政治的理由でやるということが決まっただけのケースもあります。つまり、単に実行すればいいだけでその内容までは問わない、というようなまったく無意味なケースもあるということです。

このような場合に、正面きって批判することは体力のムダでしょう。会社にとっても不利益にしかならないので、いかにコストを抑えて"やったことにするか"を真剣に考えましょう。


２と３は命令を遂行するにあたって、自分の責任はどこにあるのか、またどの程度裁量を発揮できるのかを明確にすることで、後々の"被害"を最小限に留めることができます。責任＞裁量の関係になっていないか、またそうなっていれば、具体的に何が必要なのか事前にはっきりさせておきましょう。いくら無茶な命令だったとしても、それを実現するために現実的に解決しなければならない問題があれば、上司も協力してくれるはずです。

４は欠陥だらけの計画が破綻した場合を想定して、事前に「こんな可能性がありますよ」と上司に伝えておくことです。これを行うことによって、仮にプロジェクトが失敗した場合でも、自分はこの可能性に関して言及していたと言い訳をすることができます。ズルい方法ですが、組織の失敗を個人の責任にさせないために、事前に準備しておくことは重要です。


トップのリーダシップが欠如した組織は往々にして、このように理不尽な状況になりがちです。
しばらく様子を見てまったく改善しないようであれば、履歴書を書き始めたほうが賢明かもしれません。

76

本 「僕が２ちゃんねるを捨てた理由」

今更ですが「僕が２ちゃんねるを捨てた理由」という、元２Ch管理人ひろゆき氏の本を読みました。

2009年6月が初版だから、約1年前ですね。

内容の前半は著者が自分の考えについて口述した内容を、ライターが文書にまとめたもので、後半はひろゆき氏と著名人（？）による対談です。

最初の10ページぐらいで、タイトルの問いに対する回答が得られます＾＾
もっともらしいアンケート結果が最初に出てきますが、完全に釣りです。wwww

要するに、2ch管理人として自分がやるべきことがなくなったから、シンガポールの会社に有償で譲りましたということでした。
 
後半はあの電波少年のTプロデューサーらとの対談です。
話の内容とはそれるけど、「十五ヶ国の少女をあつめて、無人島で共同生活させる」 という
電波の例企画は、今考えるとすごい企画だとあらためて感じました。

アメリカでは未だにサバイバーが続いているみたいだから、Lost＋サバイバー＋マルチカントリーなんて企画を本気でやったら、爆発的に売れる事は間違いないですね。。。
 もっとも人種差別の問題やらなんやらがあるから、実現は難しそうですが、、、

もしかして日本の番組を参考にして、既に準備しててもおかしくないです。 これはまったくの想像ですが。


ともかく対談の中で、ひろゆき氏もTさんも海外を強く意識してることがよくわかりました。


サマリですが、正直まとめられません＾＾；
そもそも一つのテーマについて論じている本ではないので、結論的なものは無かったです。（本人もあとがきに書いていました）

全体を通して感じたのは、『ひろゆき氏は日本企業には早すぎる』ということでしょうか、、、
考え方が超合理的で、本人にはそのつもりがなくても、彼に間違えを指摘された人は、自分を否定された気分になることでしょう。日本企業でこれをやったら、一ヶ月と持たない気がします。


私が今までいた会社でも、やはり合理性よりも「和」が重要だという雰囲気がありました。
ひろゆき氏はアメリカにも留学されてるし、経済も勉強しているようなので、そういった経験も影響しているはずです。私自身海外での経験があったからこそ、合理的な考え方をするようになりました。
でも、日本企業において「合理性はトップダウンで推進されるべきで、一兵卒が合理性を口に出すなどおこがましい」という雰囲気があるように思います。


とはいえ条件が揃えば、合理性よりも協調性を重視した方が上手くいく場合もある、と最近考えるようになりました。

とりとめが無くなってしまいましたが、、、

いろいろな意味で、ゆろゆき氏はトップに立つべき人間なんだと思います。
数年前から露出が多くなったのも、将来を考えたマーケティング活動の一環だと勝手に解釈してます。私と同じで出たがりの性格にも見えないですし、、、

60

品質問題により特損5億円

 ニュースクリップです。

ACCESSの10年１月期、純利益41％減　ソフト不具合で対策費計上

　携帯電話用ソフトウエア開発のＡＣＣＥＳＳが15日発表した2010年１月期の連結決算は、純利益が前の期比41％減の４億9300万円だった。為替差損がなくなり経常利益は増えたものの、ソフトに不具合が見つかり対策費用として５億2500万円を特別損失に計上したことが響いた。http://www.nikkei.co.jp/news/tento/20100316ATGD1502515032010.html

株式会社ACCESS　[東証マザーズ]情報・通信業

 IR情報も見てみたのですが、モバイル向けPJがうまくいかなかったようです。

責任を取って社長報酬－50％×3ヶ月、役員が30％×3ヶ月とありました。
やはり資本が入っていると、責任の重さが違いますね。。。

うちの会社もこれぐらい真剣になってくれたら嬉しいです。


実際問題として、品質と出荷スピードを天秤にかけた場合、
どちらを優先するか判断することは非常に難しいです。

当然ビジネスが成り立つことが大前提なので、スピードを無視することは出来ないし、
一方でどこまで品質を犠牲にするかも考える必要があります。

ひとつ提案するとすれば、品質管理チームを作って出荷前の製品の品質を、
ある程度把握できるようにすることが大事です。

バグ管理ツールとテストプロセス管理ツールも利用したほうがよいでしょう。
レポート作成をExcelでやっていると、それ自体にコストがかかりすぎます。

次に「品質を上げるにはコストがかかる」ということを意識して、
リスクベースのテストを実施することが必要です。
闇雲にテストしても意味無いですからね、、、


一度出荷を見送った製品を担当することになったQAは、
相当なプレッシャーが掛かることでしょう。

一番やってはいけないのは、完璧にテストを実施しようとすることです。
やったらQAチームのメンバが何人か倒れます。

必ず、リスクとコストを上層部に説明した上で、経営判断にもとづいてPJを進行するべきです。

35