プロダクトオーナーとして開発チームと情報共有する際に注意していること

この記事はProduct Owner Advent Calendar 2015 23日目の記事です。 22日目はjoytomoさんによるPOなき開発現場のプロダクトオーナーシップでした。

(前提)SCRUMにおけるプロダクトオーナーと開発チームの役割について

私は普段、SCRUMで開発をしているチームのプロダクトオーナーをしています。プロダクトオーナーはwhatの担当で、情報収集してプロダクトバックログにアイテムを追加したり、優先順位を最新化したりすることが主たる役割です。開発チームはhowの担当で、プロダクトバックログの内容を実現するより良い方法を考えたり、実際に作ることが役割です。

また、別の言い方で、プロダクトオーナーは投資対効果を最大化することが役目、という説明を受けたことがあります。つまり、有限な開発リソースの中で最も効率の良い(プロダクトを目指す方向に成長させる)whatを選ぶことが重要になります。

そのためにプロダクトオーナーに必要な能力として、1番は決断する力、2番は情報収集する力だとスクラムマスター研修で教わりました。

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

プロダクトオーナーと開発チームの情報差による認識齟齬

最近思うこととして、プロダクトオーナーは情報収集が仕事なので色々な情報を把握できますが、それを全て開発チームに伝えることは難しく、結果、情報の差が出やすいな、ということがあります。

そのため、プロダクトオーナーとしては、情報収集して考えて出した結論でも、開発チーム側からすると結論だけ言われても納得できない、もしくは、プロダクトオーナーが意図した内容と異なる内容で理解してしまう(誤解してしまう)、という状態が生まれやすいのではないか、と考えています。

もちろん、そこがプロダクトオーナーの技量、ちゃんと要点をまとめて伝えることが大事、みたいな話はあると思うのですが、私自身、結構頑張って伝えているつもりでも齟齬が生まれる時があり、どう改善したら良いかなと悩んでいました。

いました、というか今でも悩んではいるのですが、ある程度考えたことがあるので、その内容を以下に書いていきます。

まずはプロダクトバックログ大事

改善の対象として真っ先に考えるのはプロダクトバックログかなと思います。プロダクトバックログにはユーザーストーリーを書くのが大事、とか、INVESTが大事、とか言われます。こういうことが出来ているか再確認する(振り返る)ことがまずは大事なんだろうなと思います。

それ以外で自分で気をつけたこととして、あまり固い文章で書くのを辞めて、出来るだけ思いや感情を書くようにしました。

例えば、

Aという機能を実装する。
KPIは3%程度改善する見込み。

と書かれるより、

Aという機能を実装します。
KPIは3%程度改善する見込みですが、
不安要素もあるので、ちょっと怪しいです。

みたいに書いた方が、温度感が分かりやすいかなと考えています。

コンテキスト共有が大事

プロダクトバックログももちろん大事なんですが、どうしても書き漏れてしまうこととか、この書き方で理解されると思ったのに駄目だった、みたいなことは出てしまいます。というか、ちゃんと読み手が理解できる文章を書いていくのは本当に大変だと思います。

これを改善するのには、普段からコンテキスト共有していることが大事だと考えています。自分が何を考えているとか、どういう情報を得たとか、判断に影響する内容を、判断する前から共有しておくことが大切になります。

例えば

鈴木さんは案1が優れていると考えていて、佐藤さんは案2が優れていると考えているとします。プロダクトオーナーは案1と案2の優先順位を考えなくてはいけなくて、最終的に案2を優先することに決めました。

このとき案1が優れていると考える鈴木さんに説明する方法として

  • 客観的なデータにより優劣を示す
  • 定義した判断軸による評価結果を見せて説明する

などが考えられると思います。ただ、実際には、これでは鈴木さんが納得出来ないケースも結構な数あるのではないかと思います。(データの取得方法が違うとか、評価結果が間違っているとか)

一方で、鈴木さんが案1、佐藤さんが案2を選ぶのは、それぞれ立場が違うので優先するものが異なっているためで、実際プロダクト全体で考えても差はほどんどなく(どちらも大事で)、プロダクトオーナーとしては優劣を決めづらいというようなことも多いと思います。

こういうとき、両者の立場をしっかりを理解した上で判断していることであったり、どちらの案も甲乙つけがたい状態での決断であることなどが理解されている状態にすることも大事だと考えています。(具体的に何を共有するべきかはチーム文化によって変わるとは思いますが)

普段から共有していることが大事

両者の立場を分かった上で判断しているよ、と判断後のタイミングで急に言っても胡散臭いだけな気がします。なので、出来れば、このような情報は判断が必要に必要になる前から人となり・キャラ・価値観みたいな形で、普段から開発チームに把握されていた方が良いと思います。

やり方として分報がお薦め

以前、Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろうという記事が話題になったことで、これを真似て(idobataなので)個人のroomを作り、そこに自分の考えていることをどんどん書き込むようにしました。

これが想像以上に良くて、言語化しにくいのですが、阿吽の呼吸のような何となくわかる状態になります。

もちろん、最終的にはプロダクトバックログアイテムをしっかり作ることが大事なのですが、普段考えていることや大事に思っていることが開発チームと共有できるようになり、意思疎通をスムーズにしたり、書き漏れた際にも分かってもらえているセーフティネットのような役割になってくれたりしています。

また、同時に開発チームにも個人のroomで書き込んでもらっているので、認識齟齬が生まれたことが開発チームの発言からでも察することができます。

あとは、分報に限らず、プロダクトオーナーとして情報をアウトプットしていくことが大事だと思いますので、プロダクトが抱えている課題についてQiita:Teamの記事を書くとか、社長ラジオのプロダクトオーナー版、なども有用かな、などど考えています。(この辺りはまだ未実施です)


Product Owner Advent Calendar 2015 残り2日間はまだ空席となっておりますので、どなたか是非投稿をお願いします!!

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Paolo Perrotta氏のセミナー「アジャイルコーチへの道」に参加しました

アジャイルコーチへの道」 とは

このセミナーです。整理と備忘のために纏めます。

LAND OF COACHING

アジャイルコーチに必要なスキルについての話がありました。

プロダクトマネージャーやスクラムマスターについて学んでいても感じますが、組織とか全体的なところに寄与する役割は、多能工さが求められる感が強いです。そうでないと、回らないとか効率が悪かったりするのかなと。大きく6つのスキルが定義されていましたが、その中で、印象深かったものを以下に記載します。

Conflict Navigator

ConflictにはレベルがあってLv0:Depressionだと、抑圧されていたり、自由に話せる雰囲気がないなど、チームとして問題がある可能性があります。

変に意識統一されてしまっていたり、思考停止してしまっている状態も恐らくこれに該当するのではないかと思います。

そういう場合、アジャイルコーチは、適度にコンフリクトが発生するようにNavigateする必要があるとのことです。本当にそれで良いの?とかなぜそれをやるんだっけ?とか、そういう感じですかね。

逆に、高いレベルに行き過ぎてしまったものは下げることも必要になります。(ただし、Lv5までいくとアジャイルコーチの扱うレベルではなくなるとのこと)

Problem Solver

問題を解決する人、ということですが、大切なのはtake it to the teamで、出来るだけ自分ではなく、チームに解いてもらうことです。

一方で、アジャイルコーチが正しい答えに誘導すること(していると感じること)は、とても不愉快に感じる、という意見もあり、なるほどな、と。

アジャイルコーチとしては、自分の中の仮説は持ちつつも、チームを誘導して答えを出す、という絶妙なバランスが必要なのかなと思いました。チームが出した答えは尊重しつつ、自分の中の仮説と照らし合わせて、矛盾があれば、それはどう考えるか聞く、みたいな感じかなー。

Collaboration Conductor

コラボレーションを誘発する(指揮する)存在という意味です。問題解決に必要な人を集めて、コラボレーションさせる役割。(必要な人が集まったら、勝手に問題が解決していく、ということらしい)

適切な人を見極めるとか、声をかけて呼ぶことが出来るとか、場をセッティングすることが出来る能力って感じかなと思います。

で、一番重要なスキルは?

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターンのLinda RisingさんいわくMind your manners.Be polite.ということらしいです。

礼儀正しく、感じの良い人であることが大事、ということですね。反省します。

Fearless Journey

続いて、Fearless Journey―組織を変革する48の影響戦略カードを使ったアクティビティを行いました。

自分が組織に対して変えたい課題を考え、それを解決する方法論として、Fearless Journeyのカードから選択し、その方法論を使ってどう実現するかを考えました。

同じようなカードを持つ2〜3人でチームになり、ワークを行い、最後にワークで見つけたInsightを共有しました。

自分のチームで見つけたInsight

課題

組織がコンフリクトレベルのLv0:Depressionになりやすいと感じていて、もっとコンフリクトが発生するように、変化を与えたいがうまく変化させられない

Fearless Journeyのカード

  • 種をまく
  • 成功の匂い
  • みんなを巻き込む
  • ステップバイステップ
  • 経営層の支持者

当初の想定

  • 良い機会がある度に種をまいて、変わるきっかけにならないか
  • 現状よりも良くなる成功の匂いを感じてもらって、変わるきっかけにならないか

などなど

考えたこと

  • 例えば、種をまいても変わる人と変わらない人がいる
  • 変わる人は良いけど、変わらない人はどうすれば良いか
  • 自分はなぜ変わって欲しいのか
    • (変わった方が良くなるとして)より良い状態に変化してもらいたい
    • もっと良い状態になると期待している
  • 種をまくことは単に方法論やメリットを見せるだけになっているのでは
  • まだ見せられていない期待を伝えられれば、変わろうという人がいるのでは

Insight

  • 種をまくときは、相手に対する期待が分かるようにすると良い(のでは)

本当に良いかは検証してみないといけないですね・・・・

懇親会

セミナーの後はsushiパーティでした。セミナー参加者の方々が大変豪華だったので、参加者の方とお話するだけでも大変勉強になりました。

アジャイルとかスクラムをやっていると、「掘り下げ」とか「なぜなぜ」みたいな話が多くなりがちな気がしますが、そういう話ってとても性に合っているなと感じます。(懇親会とても楽しかったという意味です)

参考書籍

アジャイルコーチの勉強には以下の本が良いよ、と紹介してもらったので列挙します。

※紹介されていたのは全て日本語の本ではなかったですが、知ってる範囲で日本語版を貼っています

Agile Coaching

Agile Coaching

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Facilitator's Guide to Participatory Decision-Making (Jossey-Bass Business & Management Series)

Facilitator's Guide to Participatory Decision-Making (Jossey-Bass Business & Management Series)

Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

アイデアのちから

アイデアのちから

プロダクトオーナー祭り2015に参加して、プロダクトバックログについての話をしてきました

プロダクトオーナー祭り2015 ~世界を変えるのは俺たちだ!~スピーカーとして参加させて頂きました。楽しかった!!

自分が発表してみての話と、他の方のセッションに参加してみての話を両方書かれて頂きます。

自分が発表した話

発表資料

www.slideshare.net

発表のポイント

以下のような内容が主に伝えたかったことです。

  • バッドノウハウの共有
  • 課題との試行錯誤の様子を伝える
  • 仮に内容が間違っていたとしてもTry大事

失敗の内容もその改善策も、企業やチームによって色々かとは思いますが、(そして自分も、もちろん正解に辿りついているわけではないですが、)同じようなことをしている方々に、何かしらヒントみたいなものになれば良いなという気持ちでした。

発表後に思ったこと

正直、若干後悔するぐらいプレッシャーを感じていたのですが、やった後はやってよかったと思うものですね。理由として、

  • 自分の話にこんなに人が来てくれるのだという感動
  • 「この内容あるある」みたいな共感が得られると嬉しい
  • 「このやり方良いかも」とか言われると、報われた感が半端ない
  • 発表後に色々な人に話しかけてもらえる(懇親会でぼっちにならなかった)
  • 自分のやってることの整理になって、さらに色々考えられるようになる

などがあります。

ちなみに、大きなA会場と、A会場と比較して小さめのB〜D会場で、発表が行われたのですが(私はB会場)、アンケートによると、B〜D会場で行われたセッションの中での投票数 第2位 ということでした。本当に感謝感激でした。田舎の両親に報告します。

他の方のセッションに参加した話

比較的自分は最初の方の発表だったので、発表後は主にワークショップに参加して楽しませて頂きました。その内容についても簡単にですが、触れさせて頂きます。

「プロダクトオーナー/プロダクトオーナーシップ」カイワヤ会(出張版)

カイワヤとは

「会話」+「わや」という造語だそうです。「わや」というのは鎌倉ハムのKウインナーで(私の出身)愛知県ではおなじみの、「駄目になる」みたいな意味の方言です。方言は知っているのに、会の意味がよく分からなかったのですが(笑)、たくさん(≒めちゃくちゃになるぐらい)話す会みたいな意味かなと想像しました。

内容

プロダクトマネジメントマニフェスト

こちらで扱ったのは、プロダクトマネジメントマニフェスト です。

ここに書かれた内容について、他の参加者の方と、「ここが素晴らしい」とか「これは難しいのでは」「自分はここまではできてるけど、これはできてない」みたいなことを、共有&ディスカッションしました。

プロダクトマネージャに必要なのは「覚悟」

  • 基本的に権限はない
  • 製品に対するすべての責任を持っている
  • 最も困難な仕事をしている
  • すべての分野の専門家でなければならない

(そんなの現実的に無理でしょ、という意見もたくさん出つつ)。そんなプロダクトマネージャに必要なのは 覚悟 ではないか、という話をしていました。

別の機会で、実際にプロダクトマネージャをされている方と、 優れたプロダクトマネージャには、いわゆる「人間力」みたいなものが大事ですね というお話をさせて頂いたこととも通じるところがあるな、というのが自分の所感でした。

自分はまだまだ遠い・・・

『メトリクスによる「見える化」のススメ:No 見える化, No 改善』

課題解決のために、課題を「見える化」するためのメトリクスを考えて設定する、という内容のワークショップでした。内容だけでなく、ワークショップの進め方も大変勉強になる会でした。

ワークショップを通じて思ったことをざっくりまとめます。

メトリクスについて

  • 「数値化」できて「問題の状況が分かる」項目の設定って結構難しい
    • 例えば「バグ数」って数値化はできるけど、問題の状況が分かるか。多くなったら良い?少なくなったら良い?
  • 「問題の状況が分かる」ためには、解決したい問題が明確になった方が良さそう
    • 「優先順位が頻繁に変わる」が問題?「優先順位が変わるからスプリントが達成できない」が問題?「関係者が不満を持つ」が問題?
  • 感情とか数値かできなそうなものも、挑戦してみると楽しそう
    • 「朝来たときの気分」とか「夕方帰るときの気分」とか「ありがとうの数」とか
  • 「開発者が喜ぶメトリクスか」「マネージャが喜ぶメトリクスか」の両面を考えるのはとても良い視点
    • 片方だけに都合が良いメトリクスは、何か違っている部分があるのではないか、というヒントになりそう

ワークショップの進め方について

  • チーム名を決めるのは良い
    • 連帯感が高まる。名前付けるの個人的にはとても苦手ですが
  • 途中で一度発表して、他チームからフィードバックをもらえるのが良い
    • 自分たちだけでは気付きにくいことを言ってもらえる
    • チーム内でたくさんの人が発表できて、良い経験になる
  • 複数のチームの進行状況によって、変化できる柔軟なシナリオ
    • 純粋に勉強になりました

反省

最後にちょっとした余談ですが、反省として、 名刺を持っていかなければ駄目 でした。。。

これまでエンジニア界隈の勉強会で名刺交換をした記憶なんてほとんどないのですが、今回は大変多くの方から名刺を頂きまして、普段念のため持っている名刺が一瞬で無くなった私は、ひたすらに頂くだけになってしまいました。。。

関係各位のみなさま、大変失礼致しました m(__)m

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

amazon-ecsでAmazon Product Advertising APIを使ってみました

背景

漫画本を扱うアプリを作りたいな、と考えていて、そのための調査として、AmazonAPIはどんなことが出来るのかな、と調べてみました。

Rubyで使うためのgemを調べたらamazon-ecsというのが見つかったので、とりあえずそれを使いました。

触ったのは主に、商品検索関連です。

事前準備

AmazonAPIが使えるようにユーザ登録しておく必要があります。

このページから行いました。

リファレンス

書き方・使い方

接続するためのキーなどを登録

Amazon::Ecs.configure do |options|
  options[:AWS_access_key_id] = '[your access key]'
  options[:AWS_secret_key] = '[you secret key]'
  options[:associate_tag] = '[your associate tag]'
end

商品を検索する

item_searchというメソッドを使います。 APIリファレンス

検索対象は、何も設定しないとデフォルトはBookになるようです。

res = Amazon::Ecs.item_search(
  '', # Keyword検索の内容を入力します
  :title => '僕だけがいない街', # titleだけで調べたい場合にはこちらを
  :sort => 'titlerank', # 取得された結果(レスポンス)の中でのソート順になるので、注意が必要です
  :tag_sort => 'Name', # 取得される結果をソートします
  :browse_node => '2250738051', # 検索対象をより細かく設定したい場合に使います。この値はKindleストアです
  :country => 'jp'
)

注意事項としては、一度のitem_searchメソッドでレスポンスとして受け取れるのは、最大10個までなので、全ての結果を取得するには、:item_pageのパラメータを使って、複数回問い合わせる必要があるようです。

取得されたデータから値を抽出する

上記のような処理を行うとAmazon::Ecs.Responseクラスが結果として返されます。この中身はXMLになっているようですが、準備されているメソッドで欲しい情報を取得できます。

流れとしては、Amazon::Ecs.ResponseクラスからAmazon::Ecs.Elementクラスを取得して、Amazon::Ecs.Elementクラスのメソッドでタイトルなどの値が抽出できます

res.total_pages # 検索結果が全部で何ページ分あるのか確認できます
res.items.each do |item| # itemsメソッドで、Elementの配列が取得できます
  puts item.get('ASIN')  #Amazonの商品コードを取得
  puts item.get('ItemAttributes/Title') # タイトルを取得
  p item.get_hash # Elementの内容をHashに変えて処理できるようになります
end

商品IDから商品を検索する

item_search以外にもitem_lookupというメソッドがあります。 APIリファレンス

こちらは、商品IDから該当する商品情報を取得するのに便利です

使い方としては、第一引数にASIN(Amazon Standard Identification Number)を渡してあげれば良くて、Responseから先はitem_seachとほぼ同じ流れになります

asins = ['B00UGU4LF4','B010N2825O'] # ASINはカンマ区切りの文字列で最大10個まで渡せます
Amazon::Ecs.item_lookup(asins.join(','),:country => 'jp').items.each do |item|
  puts item.get('ItemAttributes')
end

その他

item_searchitem_lookup:countryというオプションを使っていますが、このオプションはAPIリファレンスには無いものです。

amazon-ecsとして、リクエストを投げるURLを決めるのに使うようなのですが、APIリファレンスに無いために、私はよく書き忘れてしまいます。。。

対策として、最初のconfigureoptions[:country] = 'jp'と書いてしまえば、毎回書く必要は無くなります。(何もしないとデフォルトはusになっているようです)

SeleniumのActionBuilderを使ってみました

実践 Selenium WebDriverを読んで以来、使ってみようと思いつつ使っていなかったActionBuilderを先日使ったので、メモとして残します

リファレンス

Class: Selenium::WebDriver::ActionBuilder

環境

Rubyです

背景

あるページを開いて、そこにあるアンカーリンクを一通り順番に叩いて、リンク切れしていないか

を確認したい、ということがありました。結構リンク数があったので、Selenium使いたいなという感じです。

ちょっと話は逸れますが、リンク切れしていないかの確認でHTTP STATUSの200 OKを確認しようかと思ったのですが、どうやらSeleniumだとHTTP STATUSが取得出来ないようで、HTTP STATUSを確認する良い方法を模索中です。ちなみに、今回は、諸事情あって、かなり力技で、全部の画面キャプチャを撮りましたww。普通であれば、タイトルとかh1とかで値をチェックすれば大丈夫かなと思います。

話を戻しますと、アンカーリンクを一通り叩くというので、find_elementsを使って、aタグをごそっと取ってきて、ループさせようかと思ったのですが、1回叩くとページ遷移してしまうので、ループがうまくいきませんでした(ページ遷移したタイミングで、Elementがいなくなってしまうので)

なので、アンカーは別ウィンドウで開いて確認しようという考えになり、SHIFT押しながらクリックしたいなで、ActionBuilder使おうとなりました

使い方

正直、リファレンスそのまま使えば大丈夫なのですが、流れとしては、以下のようになります(今回の場合)

  • Elementを見つける
element = driver.find_element(:id,'hogehoge')

# ちなみに、「アンカータグ全部拾う」は
elements = driver.find_elements(:tag_name,'a') # => 配列が返ってきます
  • Actionの流れを作って、実行する
driver.action.key_down(:shift).click(element).key_up(:shift).perform

ポイントは、最後のperformですかね。それまでは、ひたすらActionを作っていくイメージで、最後にperformすると作ったActionを実行してくれます。

ちなみに、key_down(:shift)の後にkey_up(:shift)しないと、私の環境ではちょっと変な動きをしていましたので、しておいて方がおそらく良いかと思います。

あと、ページが大きかったりすると、Elementがウィンドウの中に見えていなくて、クリック出来ないということもありました。そういうときには、Actionの中にmove_toメソッドを入れて、そのElementのところに移動してからクリックするなど工夫する必要があります。

補足

過去記事もよろしければ参考にして頂ければ幸いです

genius.hateblo.jp

genius.hateblo.jp

genius.hateblo.jp

Selenium WebDriverの基礎的な使い方

少し前からSeleniumをしばしば触っているのですが、最近社内で初めて使う人向けにQiita:Teamで記事を書いたので、それの転用でブログ記事を書いてしまおうという魂胆になります。

リファレンス

Selenium Design Patterns and Best Practices

Selenium Design Patterns and Best Practices

仕組みのイメージ

あくまでもイメージで、正確ではないかもしれませんが、Browserを動かすものとしてDriverがあって、DriverをProgramで動かすことで、Browser操作が自動化できる、みたいに考えています。

program -> selenium-webdriver -> browser

(私は最初の頃、Driverって言われてもピンと来なかったので、Browserを動かす何かのことをDriverと言うことが分かれば捗る人が少しはいらっしゃるのではないかと思ってます)

HelloWorld的なもの

まず、webdriverを生み出します 参考ドキュメント

driver = Selenium::WebDriver.for :firefox

driverを使ってブラウザを操作をします 参考ドキュメント

# 特定のURLにアクセス
driver.navigate.to 'http://genius.hateblo.jp/'

## driver.navigateでNavigationクラスが取得されます。
## Navigationクラスはブラウザ操作と似た感じのことが出来るみたいで、
## 特定のURLに遷移したり、ブラウザバックしたり、というような操作ができます

# titleを取得する
driver.title

# ページのソースを取得する
driver.page_source

# ブラウザを閉じる
driver.quit

もっと色々な操作を行う

これも正確性には欠けるかもしれませんが、ページ内のボタンを押したり、プルダウンを選んだり、というような操作は、以下のようなイメージだと考えています。

driver.find_element -> Element#action

Driverがいるページから、ボタンだったりプルダウンだったり(=Element)を見つけます。そのためのメソッドfind_elementです。find_elementで見つかったElementに対して、clickなどのElementが持つメソッドを実行して、具体的な操作を行います。

  • find_elementはSearchContextというモジュールで実装されていますので詳しくはこちらを参照してください

  • find_elementで見つかったElementで実施出来る操作はElementのドキュメント を参照してください

ちなみに、Element自身もfind_elementを継承していますので、一回のfind_elementで特定しきれない要素などを複数回find_elementを実行することで特定する、というようなこともできます

実装例

# ボタンをクリック
driver.find_element(:id,'hogehoge').click

# テキストボックスに入力
driver.find_element(:id,'hogehoge').send_keys 'HELLO WORLD'

# テキストボックスを空にする
driver.find_element(:id,'hogehoge').clear

# ラジオボタンを選択する、チェックボックスをクリックする(elementが特定されている場合)
driver.find_element(:id,'hogehoge').click

# ラジオボタンを選択する、チェックボックスをクリックする(値などでクリックするものを選びたい場合)

driver.find_elements(:name,'hogehoge').each do |element|
  element.click if element.attribute('value') == 'fugafuga'
end

## radioやcheckboxの要素がidなどで特定される場合には、
## そのidでfind_elementしてクリックすれば良いだけです。
## そうではなくて、「値で判断してクリックするものを選びたい」場合などは、
## find_elementsメソッドを使い、いったんradioやcheckboxを構成するelementを一通り取得してしまい、
## それらのループの中で期待する値と同じだった場合にクリックする、というようなことをしています。

# セレクトボックスから選択する
Selenium::WebDriver::Support::Select.new(driver.find_element(:id,'hogehoge')).select_by(:value,'list value1')

## リストの選択は、Selectクラスにelementを渡してnewした後、Selectクラスのメソッドを使って選択などの処理を実施します

補足

重複している内容もありますが、過去にもSeleniumについての内容を書いていますので、そちらのリンクも貼っておきます

genius.hateblo.jp genius.hateblo.jp

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

Windows環境でTurnip+Seleniumの受入試験シナリオを動かす

背景

るびまエンドツーエンドテストの自動化は Cucumber から Turnip へという記事からすでに四半世紀が過ぎ去ろうとしていますが、私の手元の環境(Windows7 64bit)ではTurnipがうまく動いていませんでした。

原因はこのissueだったりするのかなと思いつつ、色々と試して、結論としては、私のWin環境では、 Ruby 2.0.0 の32bit版インストーラーを入れれば動く という状態でした。

TurnipのためにRubyのバージョンが固定されるのは大変遺憾であると思いつつも、大元の問題を解決する自信もなく、結局しばらく二の足を踏んでいました。

ちなみに、仮想OSを使ってテストすることも考えたのですが、エンドツーエンド試験として、違うOSでブラウザを動かすのがテストとして正しいのか疑問で、実施していませんでした。

この流れの中で、最近ふと、「仮想OSからWindowsのブラウザを動かせば良いのでは?」と思い付いて、実際やってみました、というのが背景になります。

システムテスト自動化 標準ガイド (CodeZine BOOKS)

システムテスト自動化 標準ガイド (CodeZine BOOKS)

  • 作者: Mark Fewster,Dorothy Graham,テスト自動化研究会,伊藤望,玉川紘子,長谷川孝二,きょん,鈴木一裕,太田健一郎,森龍二,近江久美子,永田敦,吉村好廣,板垣真太郎,浦山さつき,井芹洋輝,松木晋祐,長田学,早川隆治
  • 出版社/メーカー: 翔泳社
  • 発売日: 2014/12/16
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (3件) を見る

Selenium Serverというものがあります

SeleniumにはSelenium Serverというツール(?)があって、クライアント/サーバの関係で、クライアント側からサーバ側のブラウザを動かすことが出来ます。

今回は、クライアント側を仮想OS(CentOS)にして、サーバ側をWindows7にすることで、テストシナリオを仮想OS側で動かし、実際のブラウザ操作はWindows上で行う、という環境を作りました。

環境について

当初の目的を達成するだけであれば、単にWindowsと疎通出来るクライアントがいればそれで良いはずですが、社内の環境として、Vagrant + Dockerという環境がすでにあったので、それを利用して環境構築をしました。

ちなみに私のチームは、普段メインの環境がRubyなわけではなく、私が何とかして何かにRubyをねじ込めないかと日々画策している状態なのですが、Docker イメージとしてRuby環境を配布すれば、個々に環境構築する必要もなく、普段メインで使っている環境(Windowsと仮想OS環境の両方)にも影響しませんので、似たような推進活動をしている人にはお薦めです。

サーバ側

クライアント側

  • CentOS
  • Docker
  • Rubyをインストールしたimageを作成(Docker Hubから取得しても良のではないかと思います)

Windows上に置いたプログラムソースをRubyコンテナから実行するように設定

  • プログラムソースそのものは、Windows上に配置(編集はWinでやりたかったので)
  • Vagrant のファイルsyncとDockerのマウント(-v オプション)を使って、WindowsのプログラムとCentOS側のプログラムを同期
  • bundle installCentOS上のRubyコンテナで実施。インストールしたgemのファイルはWinに保存(ファイルsyncされる状態にしておく)

今回はVagrantやDockerについては、あまり深掘りはしませんが、やっていること自体はドットインストールを見ればすぐ出来るような、そこまでややこしいものではないと思います。

今後のTodoとして、プログラムの実行の度にvagrant sshしてRubyコンテナを実行するのも甚だ面倒ですので、Windows側から簡単にDocker経由でプログラムを実行するための何かは作っておこうと考えています。

サーバ側の設定(Selenium)

Javaが実行出来る状態が必要ですので、入っていない場合にはインストールをして下さい。

Selenium Serverのjarがこちらからダウンロード出来ますので、好きな場所に配置します。ダウンロードした場所でコマンドプロンプトから、java -jar selenium-server-standalone-x.xx.x.jar -role hubと実行すれば任務完了です。

IPアドレス:4444という形でアクセスすることになりますので、念のためクライアント/サーバ間で疎通が出来る状態かを確認しておくと良いかもしれません。

クライアント側の設定(Selenium)

クライアント側は、普通にSeleniumを動かす場合とあまり違いはないです。イメージとしては、Driverのインスタンスを作成するときに、リモートを指定してあげればあとは普通に動く、という印象です。

自分のローカルPCにあるFirefoxを動かす場合の書き方

driver = Selenium::WebDriver.for :firefox

リモートのブラウザを動かす場合には、ここをリモートとして設定すれば良いです

リモートサーバにあるFirefoxを動かす場合の書き方

caps = Selenium::WebDriver::Remote::Capabilities.new(:browser_name => :firefox)
driver = Selenium::WebDriver.for :remote, :url => "http://(サーバのIPアドレス):4444/wd/hub", :desired_capabilities => caps

Selenium::WebDriver::Remote::Capabilitiesというクラスがありますので、そこに諸条件を設定してDriverに渡せば、動いてくれます。

より詳しくはリファレンス:WebDriverリファレンス:Capabilities を参照下さい

こちらの書籍も参照して作りました。(言語はJavaですのでご注意ください)

実践 Selenium WebDriver

実践 Selenium WebDriver

Turnipについて

本当は、Turnipについても書こうかと思っていたのですが、冒頭のるびまの記事以上のものが特に書けなさそうでしたので、割愛します。