『TPI NEXT 日本語版発刊記念セミナー』に参加してきました
著者：ふじさわゆうき
更新日:2015/12/12
目次
- セミナー概要
- 個人的感想
- TPI NEXTの概要メモ
- TPI NEXTの詳細メモ
- パネルディスカッションメモ
セミナー概要
- テストプロセス改善であるTPI NEXTについて、薮田さん、湯本さんからのプレゼン
- 薮田さん、湯本さん、皆川さんによるパネルディスカッション
という２部構成でした
個人的な感想
- CMMIとTPI NEXTとの比較が多く面白かったです
- CMMIの場合は、改善のプロセスが決まっているのに対して、TPI NEXTは、キーエリアとクラスタという概念を使って、改善のプロセスをその組織の目的に合わせて柔軟に優先順位を決めることができるというのが特徴とのことでした
- また、CMMIの場合は、机上の論理なのに対して、TPI NEXTは、現場から出てきたフレームワークということで実践的であるともいっていました
- 薮田さんがおっしゃっていたで面白かったのが、16キーエリアという適当な数が良いとのことで、理論的に行こうとすると16なんて中途半端な数にならないとのことです
- TPI NEXTは、クラスタセットと16キーエリアのチェック項目に沿って改善の優先順位を決め、やるべきことをやることによって結果的にテストプロセス改善を狙った手法であると個人的には理解しました
- 今回、薮田さん、湯本さん、皆川さんの話をうけて、TPI NEXTがぐっと身近になったと感じています。やはり、本で読んでもわからないことがこういうセミナーにでると一気にわかります
- TPI NEXTの第一歩は、自分自身をチェックすることから始めてみて、そこからキーエリアの意味を理解することが近道ということなので、とりあえず、この手法を使って、自分自身のテストに対する姿勢で、どの部分が弱点でどう改善していくのか計画をたててみたいと思います
TPI NEXTの概要メモ
- TPI NEXTとは
- プロセス評価ではなく、キーエリアで評価することがポイント
- 現場から生まれてきたフレームワークであって、CMMIと比較して実践的である
- テストチームと利害関係者（プロジェクマネージャとか）とのやりとりを重視する。テストチームだけで評価してもうまくいかない
- キーエリアがあって、それを自己評価して、クラスタセットをもとに改善の優先順位をつけて、改善活動を進めるのが大きな流れ
- 改善計画が長期に渡って、システマティクにできるのがメリット
- 「戦略と組織」「テスト管理」「テスト技術」という３つをバランス良く改善しようという考え方
- CMMIと違って、キーエリア+クラスタセットで多角的に現状の組織を評価することができる
- 薮田さんによると、1970年代から、テスト技術は、あまり変わっていない。だから、TPI next は有効な手段ということ
TPI NEXTの詳細メモ
- 湯本さんによると仕事しながらも技術をキャッチアップしようという意識を「プロ意識」と翻訳した
- TPI NEXTのクラスタAは、基本的なことが多いから軽く達成できる。なのでここから始めてみることが大事
- TPI NEXTによる評価は、なれれば１時間位で実行することが可能
- テスト戦略について、TPI NEXTはわかり易く解説しているので参考にするとよい
- 「戦略と組織」「テスト管理」「テスト技術」など細かいことは、TPI NEXTの本を買って読んでくれとのこと
- クラスタ、カスタマイズできるので、具体例は本を読んでくれとのこと
パネルディスカッションメモ
- プロセス改善は楽しい？
- パネラー4人中3人は「楽しくない」と回答（笑）
- 開発と現場の方々に嫌われるから辛い。色々と言われる
- ただし、上司受けは良い
- テストプロセス改善のフレームワークでTPI NEXTが一番？
- CMMI は権力と結びつきが強いが、TPI NEXTは権力との繋がりがないのが良いと、パネラーの意見。TPI NEXTは、現場で鍛えられてきたモデルなので、素敵
- TPI NEXTは、改善のスコープを決めるのが良い。TPI NEXTを皆で輪読して、やってもいいし、リーダーが指摘しても良い。ただ、輪読はしやすいとのこと
- テストプロセスを改善すると利益はあがる？
- 上がると信じてプロセス改善に取り組めばよい。きっと上がるよ（笑）
- 開発プロセスとセットで改善することが大切。気になるのは、開発プロセスの理論は、10～15年単位でパラダイムシフトが発生しているのに、テストプロセスに関しては1970年代と変わっていないこと。だからこそ、TPI NEXTに取り組むことは意味があるといえる
- テストは改善しないとコストがどんどんかかる分野だから、プロセス改善をしないとコストが下がらないし、むしろ上がっていく
- その他
- TPI next は、プロダクト単位なのか、課とかの組織でみるのか、それは自由。弱点をみたい単位で、当てはめてみるのが良い
TPI NEXTについて学ぶ（２）
概要
- TPI NEXTについて、以下の参考文献を要約することで学ぼうという趣旨です。
今回の対象
- 2 テスト作業とTPI NEXTの位置づけ ～ 2.1 テスト作業のスコープと価値 ｐ9-14
感想
- "テスト作業によってビジネス上で想定される損害が軽減できれば、テスト作業のコストはプロダクトリスクに対する保険掛け金とみなすことができる"という考えかたが新鮮だった。
- 経営層が、保険掛け金算定のもとになるプロダクトリスクの見積もりは難しいだろうし、そのリスクに対する掛け金の見積もりも難しいことから、それに対してテストチームから提供できる材料（レポートなど）は何か？は常に考えて仕事に取り組まないといけないなと感じた
要約
- テスト作業の定義は、「品質とそれに関連するリスクの実態を把握して、助言を提供するプロセスのことである
- テスト作業は、
- ビジネスゴールに沿っていなければならない
- Sftware Development Life Cycle(ソフトウェア開発ライフサイクル)の一部である
- 許容できる事案とコストの中で「適切な」欠陥を検出し、満足のいく助言を提供するように構造化された、コントロール可能なプロセスでなければならない
- 将来の課題にに対しても準備を整えておくべきものである。将来の課題とは、例えば新しい技術の出現、情報システムの複雑化、市場投入期間の短縮などである
- その考え方を一言で言ったものがBDTPI(Business Driven TPI)である
- TPI NEXTのモデルであるBDTPIは、組織のビジネス主導要因によってテラーリングすることができるツールである
- テスト作業を、もっとも低コストな品質対策と考えてはいけない
- なぜなら、開発プロセスの後半に位置するため、バグの修正コストは飛躍的に高くなるからである
- 予防が是正（テスト作業）よりも優れた措置であり、かつ予防のほうがコストもかからないことを忘れてはならない
- テスト作業の難しさは、
- 時間やコストに制約があるから全てをテストすることが不可能であること
- 一方で「これで大丈夫だ」と言わなくてはならない点である
- テストチームは、割り当てられた要件や関連するプロダクトリスクをもとに、もっとも重大なエラーをできる限り早い段階で、かつもっとも効率的な方法で見つけなければならない
- テスト作業によってビジネス上で想定される損害が軽減できれば、テスト作業のコストはプロダクトリスクに対する保険掛け金とみなすことができる
- したがって、テスト作業に割り当てられるコストの金額はプロダクトリスクによって変わる。
- そのプロダクトが、組織、あるいは社会、個人の健康や生活にきわめて重要であれば、テストプロセスにそれを反映させなければならない
参考文献
- 実践ソフトウェアテスト考現学,大西建児,2009/08/27
- TPI NEXT? ビジネス主導のテストプロセス改善,薮田和夫、湯本剛、皆川義孝 (著)
デベロッパーの働き方カンファレンスに参加してきました
デベロッパーの働き方カンファレンスに参加してきました
著者：ふじさわゆうき
更新日:2015/10/31
目次
- カンファレンス概要
- 「新たな働き方って、なに？」のメモ
- 「どういう風に働いて、生きていくの」のメモ
- 個人的感想
カンファレンス概要
- イベントページ
下記のような趣旨で開かれたカンファレンスです。
■デベロッパーの働き方がちょっと変わってきているらしい。
時々、ネットでみかけたり、話をきいたりしますが、本当のところ、何がどんな風に変わってきているのだろう？変化があるってことは、そこには何か背景や理由があるはず。そして、その変化によって何が起きるのだろう。
ということが気になってきそうなので、今回はズバリ 「働き方」 をテーマにDevLOVEを開くことにしました。
■デベロッパーの働き方カンファレンスをやろう。
働き方について、ユニークな取り組みをされている方々に集まって頂き、いろいろと聞いてみようという会です。もし、面白いとおもう働き方があれば、自分たちの会社や現場でもやればいいですよね。あるいは、本当に面白いならば、手っ取り早くジョインしたっていい。どっちにしたって、どんな考えで、どんな取り組みをされているのか、聞いてみよう。
個人的には、最近、論理的出社と物理的出社の話があったので、「最近の働き方でリモートワークってどうなんだろうな？」と興味があったので行ってきました。
「新たな働き方って、なに？」のメモ
まずは、一人ひとり自己紹介しながら、会社での取り組みを紹介する感じだった。
サイボウズ 佐藤さん
- サイボウズの開発部長は、部内で5番目にエラい − ＠IT自分戦略研究所
- ベトナムと上海、インドのチェンナイなど多くの開発拠点(オフシュア開発)があり、リモート環境での仕事について語ってくれた
ヌーラボ 橋本さん
- 社員が世界各地で働いていて、リモートで働いている
- approach in our workというテーマ
- 子育て休暇が月に１回有休とは別に休みを取ることができる
- 急に英語が必要になったので、英語学習支援がある。お金の補助
- 年に１回社員総会を開いて、色々な将来のプランなどをシェアしたりする
- ニューヨークから来る社員の方が旬な情報を持ってきてくれる
StartupTechnology 菊本さん
- StartupLabo
- テーマは"基本的に困ったら制度を作ろう"
- 社員は、Slackでやりとり
- 出社は自由で雨の日は、来ない社員もいるらしい
- 最近困ってきたので、チーム化導入
- エンジニアしか社員にしないのでエンジニアが楽しめる環境を作る
ダイヤモンドメディア 武井さん
- ホラクラシー経営というものを実践している
- 海外からも問い合わせがあるらしい
- 上司も部下も肩書も無い会社
- 社長も役員も社員の選挙で選ばれている
- 上司も部下も肩書も無い会社
- 働く時間も働く場所も無い
- 雇う雇われる関係も無くすようにしている
- 採用する前に仕事をするという採用
ホラクラシーとは
Wikipedia によると、ホラクラシーとは従来のようにトップダウンのヒエラルキーによって意思決定がなされるのではなく、組織全体に権限を分散させ意思決定させることで、自走する組織を保つための社会技術または組織のガバナンス・マネジメント方法と定義されているとのこと。
詳しくは、下記、ブログを参照
- 組織の新しいカタチ「Holacracy（ホラクラシー）」 - UXploration
- ホラクラシー型組織で8年経営してみた。 - Kozo Takei's Blog（武井浩三のブログ） | 人間性経営 フロー経営 ホラクラシー型企業のダイヤモンドメディア株式会社
個人的な解釈だと、
- 今までのように「部長 > 課長 > 係長 > 平社員」のように上から下に組織が分割されていき、上から下に情報伝達されるような組織ではなく、
- 「○○チーム、○○チーム」が沢山あって、目標に向かってそれらのチームが有機的に連携する
のが、ホラクラシーらしい
ギルドワークス 市谷さん
- プロダクト開発を自宅で行っている
- 社内も社外もリモートで作業している
- ギルドのリモートメンバーは70人位
- 正しいものを正しくつくるの意思
- 全員がそろうのは週に１日
- 2か月に１回合宿を行う
- small talkという雑談の時間を大事にしている
「どういう風に働いて、生きていくの」のメモ
この時間では、議題にそれぞれのパネラーが答えるという形式で進む感じだった。
Q.リモートワークについてそれぞれの会社の事情とは
ダイヤモンドメディア 武井さん
- 時間と給料が全く関係がないので、誰が、どこで働いているのかわからなくなっている。プライベートと仕事の境界線が曖昧になってくる
- プロダンサーで勝手に全国ツアーしている社員もいる
- 東京で働くほうが、営業も考えると有利。地方で働くことが結構難しい
- クラウドワークスとかと働けば地方でも仕事はできるが、単価は安いので現状だときつい
StartupTechnology 菊本さん
- お客様ありきの仕事だと東京で仕事をせざる得ない
- とはいえ、地元で働きたいという人もいる
- 東京の仕事を地方に持っていこうという試み
- クラウドソーシング
- 全国でそれなりに人がいる。それで食べていける世界がくるんじゃないかなーと期待
ヌーラボ 橋本さん
- 頼まれるエンジニア(ブログで有名だったり、技術で有名だったり)そういうエンジニアにならないと、東京以外の地方で働くことは実際、厳しいじゃないかという意見
- 働く場所と時間をきっちり決めているが、社員全員が破ってくる（笑）
- 言うことをきかない社員達に諦めがあるが、それが重要で、だから当社には自由がある
ギルドワークス 市谷さん
- やることが多すぎてリモートでもオフィスでも変わらない(笑)
Q.リモートワークは、辛いといって結局、社員が会社に来るそういう現状がある。それって他の会社ではどうなんでしょうか？
サイボウズ 佐藤さん
- 24時間、プロダクトが開発される方向を目指していた。全世界で開発者がいれば可能なはずという理念。リモート推進。
- しかし、そんなサイボウズでもリモートワークはできるが、結局、オフィスに来て仕事をしているらしい
StartupTechnology 菊本さん
- リモートワークしていたら仲間と働いている感が無くて寂しいと社員は感じた過去があった
- 結局、オフィスで働いてみたら楽しく仕事ができているということ
Q.ホラクラシー経営のように個人個人に任せると大きなトラブルにならないのか？
ダイヤモンドメディア 武井さん
- 特に無し。仕事の期日という約束は守ってもらう
- 約束が守れない人は結果的に、レベルの低い仕事ばかりになって淘汰されていく
Q.その他
サイボウズ 佐藤さん
- サラリーマンって素晴らしい。ちゃんと決まった給料がもらえるんだから。そう考えれば仕事は楽しくなるんじゃないかという意見
ダイヤモンドメディア 武井さん
- 優秀な人は、文句は言わない。能力が低い人は「会社の理念が無いからなにをやればいいかわからない。etc」など色々と言ってくる傾向があるとの意見
StartupTechnology 菊本さん
- サイヤ人は死にかけると強くなるという理屈で社員を成長させていく文化
- そうすると2-3ヶ月で1人でRubyのプロジェクトを回せるようになる
ヌーラボ 橋本さん
- 働く場所と時間、就業規則をきっちり決めているが、社員全員が破ってくる（笑）
- 言うことをきかない社員達に諦めがあるがそれが重要で、だから当社には自由がある
- 働き方より、エンジニアは、プログラムをいかに上手く書くかなど考えて欲しいという意見
- 働き方を考えるエンジニアってどうなんでしょうか？といっていた
締めの言葉
- OSSのコミッタになると鍛えられていいと思います
- 経営が考えるのはいいけど、開発者は働き方を考えなくていいと思います
- いろんな働き方があるけど、決めるのは皆さん。自分にあった働き方を見つけてください」
- 「マーケット価値を考えて自分のスキルを伸ばしていくことが大事だと思います
個人的感想
- 結局のところ、リモートワークのメリットはオフィスワークに比べて劣るよう思われた。
- 例えば、サイボウズ 佐藤さん、StartupTechnology 菊本さんの話だと、リモートワークを推進しているのに、結局、オフィスに来る社員が多い話からそのように考えるようになった
- しかし、ギルドワークス 市谷さんの言う用に、やることが明確でとにかく仕事をしなくちゃいけないような状況だと、リモートでもオフィスでも変わらないという意見があった。
- 以上考えてみると、リモートワーク、オフィスワークと両極端に考えるのではく、方針決め等コミュニケーションが必要であればオフィスへ行く、やることが明確でとにかく仕事をしなきゃいけないときはリモートで仕事するなど、柔軟に勤務形態を選べるのがベストなんだろうなと思った。例えば、ギルドワークスのように週１回はオフィスに来なきゃいけないが、それ以外は在宅でもOKとするなど。
印象に残った一言
- ヌーラボ 橋本さんの「働き方より、エンジニアは、プログラムをいかに上手く書くかなど考えて欲しい、働き方を考えるエンジニアってどうなんでしょうか？」という意見が一番印象に残った
- 橋本さんの真意としては「エンジニアが働き方を考えるようになったらそれは、経営者の責任」ということらしい
Masanori Hashimoto on Twitter: "働き方をエンジニアが考えちゃうのは管理職があまり良い環境を作れてないせい。僕のせい。 https://t.co/6Bi6pnrwkH"
- 自分としては、チームメンバーが、働き方について考えだしたら負けという心構えで、仕事に取り組んで行こうと心に決める一言となった
TPI NEXTについて学ぶ（１）－TPIとTPI NEXTとは
TPIとは
- Test Process Improvementの略
- テストプロセス改善に特化したモデル
- TPIはオランダのSOGETI社のTim Koomen 氏とMartin Pol 氏によって提案された手法で、このSOGETI社が構築したテストプロセスを構造化したモデル(TMap: Test Management approach for structured testing)という、独自のテストのための方法論に基づいている
- 現場主導のボトムアップ的なアプローチならTPI、経営・管理層が主導するならTMMのトップダウン的なアプローチという使い分けると良い
- テストプロセスを単独で改善するのではなく、ソフトウェアプロセス改善活動の一環として取り組まないと真の改善にはつながらないという考え方に基づいている
TPI Nextとは
- 管理者層の関心が「プロセス主導」から「ビジネス主導」へと移ってきたことをきっかけとしてTPIモデルを改善したもの
- TPIよりも以下の点が強化された
- 10年感に得た実践事例によってモデルそのものを改善した
- 組織の特定のニーズに合わせて段階的な調整できるように改善した
- TMapとの併用を容易にできるようにした
- テストプロセス、テスト組織をどのようにしたら改善できるのか、ヒントや助言を提案できるように改善した
- クラスタという概念を追加して、多岐の用途に使えるようにした
- 短期間で成果を出せるようにキーエリア達成のコツという概念を導入した
参考文献
- 実践ソフトウェアテスト考現学,大西建児,2009/08/27
- TPI NEXTⓇ ビジネス主導のテストプロセス改善,薮田和夫、湯本剛、皆川義孝 (著)
「【入門】Geb+SpockではじめるWebテスト」の記事を更新しました
Geb+Spockの開発環境構築を扱った以下の記事ですが、
各種ライブラリをバージョンアップして更新いたしました。
Geb+Spockの開発環境を最新化したい方は、是非ともご一読ください。
主な変更点は以下の通りです。
- JavaのVersion
- 1.7 ⇒ 1.8
- EclipseのVersion
- Kepler ⇒ Mars
- GebのVersion
- 0.10.0 ⇒ 0.12.2
- GroovyのVersion
- 2.3.7 ⇒ 2.4.3
- SpockのVersion
- 0.7-groovy-2.0 ⇒ 1.0-groovy-2.4
ハマリ所としては、「gmaven-plugin」を「gmavenplus-plugin」に変更しなきゃいけなかったところです。「gmaven-plugin」では、「Java8 + Groovy2.4.3 + Spock1.0-groovy-2.4」という組み合わせで、Maven実行時にエラーが発生してしまい動作させることができなかった。
さらにgoalsを以下のように設定しなくちゃいけなくて、それが難しかった・・・。gmavenplus-pluginの公式サイトを熟読することで解決しましたが、公式サイト以外のさまざまなブログでは、goalsが別の書き方になっていて翻弄されました。やっぱり公式サイトの熟読が良いですね。
<plugin> <groupId>org.codehaus.gmavenplus</groupId> <artifactId>gmavenplus-plugin</artifactId> <version>1.5</version> <executions> <execution> <goals> <goal>addSources</goal> <goal>addTestSources</goal> <goal>generateStubs</goal> <goal>compile</goal> <goal>testGenerateStubs</goal> <goal>testCompile</goal> <goal>removeStubs</goal> <goal>removeTestStubs</goal> </goals> <configuration> <providerSelection>1.8</providerSelection> <sourceEncoding>UTF-8</sourceEncoding> </configuration> </execution> </executions> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>2.4.3</version> </dependency> </dependencies> </plugin>
今後とも、Geb+Spockの開発環境構築にお役に立てれば幸いです。
【入門】Geb+SpockではじめるWebテスト / [Introduction] Let's start Web Browser Automation Testing using Geb, Spock and Groovy
【入門】Geb+SpockではじめるWeb自動テスト / [Introduction] Let's start Web Browser Automation Testing using Geb, Spock and Groovy
著者：ふじさわゆうき
Author: Yuki Fujisawa
更新日:2015/10/25
Updated date:2015/10/25
Mac版はこちら(2016/11/13 作成)
目次 / Table of contents
- Gebとは / What's Geb ?
- Gebのメリット / Why we have to use Geb ?
- 開発環境構築(Groovy Mars) / Development Environment Building (Groovy Mars)
- サンプルプログラム実装(Geb+Spock+Maven) / Sample program implementation (Geb + Spock + Maven)
- クロスブラウザテストの設定と実行 / Setting up and running of the cross-browser test
- テスト失敗時のスクリーンショット出力 / How to output screen-shot of test failure? (2014/11/09 update)
- Mavenコマンドによるテスト実行 / How to run test by Maven command?(2014/11/29 update)
- "GitHub + Jenkins"によるWEBテストの自動化 / Automation of WEB tests by use to the "GitHub + Jenkins"(2014/11/30 update)
- GebとSpockによるWebテストTips集 / Web test Tips collection about Geb and Spock(2015/01/25 update)
1. Gebとは / What's Geb ?
- Groovy言語で書かれたWebテスト自動化フレームワーク / Web test automation framework written in Groovy language
- SeleniumWebDriverで挙がっている問題（例えば、ログインボタンを押すだけでもおおくの記述が必要など）を解決している / Geb solved Selenium Web Driver problems , for example we need only even many description press the login button
2. Gebのメリット / Why we have to use Geb ?
- WebDriverと比較して、より短く、よりわかりやすいテストを記述することができる。Gebの提供するナビゲーターAPI(Navigator API)というjQueryのようなAPIがそれを可能にしている / Compared to WebDriver, shorter, and can be described more meaningful test. Navigator API like jQuery is allow it
- Page Object patternをサポートしているので画面変更に強いテストを作成することができる / Since Page Object supports pattern, it is possible to create a test that we can handle screen change.
- Page Object patternの詳細 ⇒ 【Geb】ページオブジェクトパターンとは? / What is Page Object pattern ? - yfj2’s Automatic Web Test Related Blog
- Mavenで提供されるのでテスト作成の環境構築が簡単にできる / It is possible to easily environment construction of test creation because it is provided by Maven
- GroovyなのでJavaと互換性があり、SeleniumWebDriverの既存資産をそのまま利用することができる / Since using Groovy has Java-compatible, it is possible to directly utilize existing SeleniumWebDriver's assets
- Moduleを使うことで共通部分を部品化することができる / By using the Module, it can be part of a common portion
3. 開発環境構築(Eclipse Mars) / Development Environment Building (Eclipse Mars)
Java JDK 8のインストール / Installation of Java JDK 8
- Download jdk-8u60-windows-x64.exe(2015/10/25 time)
- Install
- C:\Program Files\Java\jdk1.8.0_66
- Environment variable settings
- New Variable
- JAVA_HOME : C:\Program Files\Java\jdk1.8.0_66
- Path
- %JAVA_HOME%
- New Variable
Eclipseのインストール / Installation of Eclipse
- 下記、URLから"Eclipse Mars for Java and DSL Developers Windows 64-bit版"をダウンロード / First You download the "Eclipse Mars for Java and DSL Developers Windows 64-bit version" from URL.
Eclipseのメモリ設定 / Memory setting of Eclipse
- eclipse-dsl-mars\eclipse.ini
- Xms256m -> Xms512m
- Xmx1024m -> Xmx2048m
-startup plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300.v20150602-1417 -product org.eclipse.epp.package.dsl.product --launcher.defaultAction openFile --launcher.XXMaxPermSize 256M -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile --launcher.appendVmargs -vmargs -Dosgi.requiredJavaVersion=1.7 -Xms512m -Xmx2048m
Eclipse起動 / Start Eclipse
- eclipse.exeを実行する / You run eclipse.exe
- eclipse-dsl-mars\eclipse.exe
- Select of workspace
- (ex)C:\gebworkspace
Groovy Pluginのインストール / Installation of Groovy Plugin
- Help > Install New Software... > Add...
- Name: GRECLIPSE-e4.5
- Location: http://dist.springsource.org/snapshot/GRECLIPSE/e4.5
Java JDK 8の設定 / Setting of Java JDK 8
4. サンプルプログラム実装(Geb+Spock+Maven) / Sample program implementation (Geb + Spock + Maven)
GoogleWikipediaTest Projectの新規作成とMavenの設定 / GoogleWikipediaTest Project New Create and setting of Maven
- File > new > other... > Maven > Maven Project
- pom.xmlの編集 / setting of pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>mygroup</groupId> <artifactId>GoogleWikipediaTest</artifactId> <version>0.0.1-SNAPSHOT</version> <name>GoogleWikipediaTest</name> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>2.4.3</version> </dependency> <dependency> <groupId>org.spockframework</groupId> <artifactId>spock-core</artifactId> <version>1.0-groovy-2.4</version> </dependency> <dependency> <groupId>org.gebish</groupId> <artifactId>geb-spock</artifactId> <version>0.12.2</version> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-firefox-driver</artifactId> <version>2.48.2</version> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-support</artifactId> <version>2.48.2</version> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-chrome-driver</artifactId> <version>2.48.2</version> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-ie-driver</artifactId> <version>2.48.2</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18</version> <configuration> <includes> <include>**/*Test.class</include> <include>**/*Spec.class</include> </includes> </configuration> </plugin> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <encoding>UTF-8</encoding> <source>1.8</source> <target>1.8</target> </configuration> </plugin> <plugin> <groupId>org.codehaus.gmavenplus</groupId> <artifactId>gmavenplus-plugin</artifactId> <version>1.5</version> <executions> <execution> <goals> <goal>addSources</goal> <goal>addTestSources</goal> <goal>generateStubs</goal> <goal>compile</goal> <goal>testGenerateStubs</goal> <goal>testCompile</goal> <goal>removeStubs</goal> <goal>removeTestStubs</goal> </goals> <configuration> <providerSelection>1.8</providerSelection> <sourceEncoding>UTF-8</sourceEncoding> </configuration> </execution> </executions> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>2.4.3</version> </dependency> </dependencies> </plugin> </plugins> <pluginManagement> <plugins> <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself. --> <plugin> <groupId>org.eclipse.m2e</groupId> <artifactId>lifecycle-mapping</artifactId> <version>1.0.0</version> <configuration> <lifecycleMappingMetadata> <pluginExecutions> <pluginExecution> <pluginExecutionFilter> <groupId>org.codehaus.gmavenplus</groupId> <artifactId>gmavenplus-plugin</artifactId> <versionRange> [1.5,) </versionRange> <goals> <goal>addSources</goal> <goal>addTestSources</goal> <goal>generateStubs</goal> <goal>compile</goal> <goal>testGenerateStubs</goal> <goal>testCompile</goal> <goal>removeStubs</goal> <goal>removeTestStubs</goal> </goals> </pluginExecutionFilter> <action> <ignore></ignore> </action> </pluginExecution> </pluginExecutions> </lifecycleMappingMetadata> </configuration> </plugin> </plugins> </pluginManagement> </build> </project>
Groovyプロジェクトへの変換 / Convert to Groovy Project
- GoogleWikipediaTest Project > Configure > Convert to Groovy Project
Maven Update Project
- GoogleWikipediaTest Project > Maven > Update Project
Gebスクリプトの作成 / Creating Geb script
- 下記のようなフォルダとファイルを作成します / Create a folder and files, such as the following
- GoogleWikipediaTest/src/main/groovy/GoogleWikipediaMain.groovy
- GoogleWikipediaTest/src/main/groovy/module/GoogleSearchModule.groovy
- GoogleWikipediaTest/src/main/groovy/page/GoogleHomePage.groovy
- GoogleWikipediaTest/src/main/groovy/page/GoogleResultsPage.groovy
- GoogleWikipediaTest/src/main/groovy/page/WikipediaPage.groovy
- GoogleWikipediaTest/src/test/groovy
- Java Build Pathの設定もします / You also set Java Build Path
- GoogleWikipediaTest > Properties > Java Build Path > Add Folder...
- src/main/groovy , src/test/groovy
- GoogleWikipediaTest > Properties > Java Build Path > Add Folder...
- GoogleWikipediaMain.groovy
import geb.Browser import page.GoogleHomePage import page.GoogleResultsPage Browser.drive { to GoogleHomePage search.field.value("wikipedia") waitFor { at GoogleResultsPage } firstResultLink.click() }
- GoogleSearchModule.groovy
package module import geb.Module class GoogleSearchModule extends Module { // a parameterised value set when the module is included def buttonValue // the content DSL static content = { // name the search input control “field”, defining it with the jQuery like navigator field { $("input", name: "q") } } }
- GoogleHomePage.groovy
package page import geb.Page import module.GoogleSearchModule class GoogleHomePage extends Page { // pages can define their location, either absolutely or relative to a base static url = "http://google.com/ncr" // “at checkers” allow verifying that the browser is at the expected page static at = { title == "Google" } static content = { // include the previously defined module search { module GoogleSearchModule, buttonValue: "Google Search" } } }
- GoogleResultsPage.groovy
package page import geb.Page import module.GoogleSearchModule class GoogleResultsPage extends Page { static at = { title.endsWith "Google Search" } static content = { // reuse our previously defined module search { module GoogleSearchModule} // content definitions can compose and build from other definitions results { $("div.g") } result { i -> results[i] } resultLink { i -> result(i).find("a") } firstResultLink { resultLink(0) } } }
- WikipediaPage.groovy
package page import geb.Page class WikipediaPage extends Page { static at = { title == "Wikipedia" } }
Gebの実行 / Execution of Geb
- GoogleWikipediaMain.groovy > Run As > Groovy Script
- 'http://en.wikipedia.org/wiki/Main_Page'が起動すればOK / If you can invoke the 'http://en.wikipedia.org/wiki/Main_Page' , This test is OK .
Spockの実装 / Creating spock script
- 下記のようなフォルダとファイルを作成します / Create a folder and files, such as the following
- GoogleWikipediaTest/src/test/groovy/GoogleWikipediaMainTest.groovy
- GoogleWikipediaMainTest.groovy
import geb.spock.GebSpec import page.GoogleHomePage import page.GoogleResultsPage import page.WikipediaPage class GoogleWikipediaMainTest extends GebSpec { def "first result for wikipedia search should be wikipedia"() { given: to GoogleHomePage expect: at GoogleHomePage when: search.field.value("wikipedia") then: waitFor { at GoogleResultsPage } and: firstResultLink.text() == "Wikipedia" when: firstResultLink.click() then: waitFor { at WikipediaPage } } }
Spockの実行 / Execution of Geb
- GoogleWikipediaMainTest.groovy > Run As > JUnit Test
- テストが成功すればOK / If the test is successful OK
5. クロスブラウザテストの設定と実行 / Cross-browser test setting and running
以下、記事を参考に設定＆実行する
【入門】Geb+SpockではじめるWebテスト～クロスブラウザテスト編～ / Setting up and running of the cross-browser test - yfj2’s Automatic Web Test Related Blog
6. テスト失敗時のスクリーンショット出力 / How to output screen-shot of test failure?
以下、記事を参考に設定＆スクリーンショット出力する
【入門】Geb+SpockではじめるWebテスト～スクリーンショット編～ - yfj2’s Automatic Web Test Related Blog
7. Mavenコマンドによるテスト実行 / How to run test by Maven command?
以下、記事を参考にMavenコマンドでテストを実行する。
Mavenコマンドでテスト実行をできるようにしておくことでJenkinsとの連携が可能となる。
【入門】Geb+SpockではじめるWebテスト～Maven編～ / How to run test by Maven command using Geb+Spock? - yfj2’s Automatic Web Test Related Blog
8. "GitHub + Jenkins"によるWEBテストの自動化 / Automation of WEB tests by use to the "GitHub + Jenkins"
以下、記事を参考に"GitHub + Jenkins"によるWEBテストの自動化を実現する
【入門】Geb+SpockではじめるWebテスト～GitHub + JenkinsによるWEBテスト自動化編～ - yfj2’s Automatic Web Test Related Blog
9. GebとSpockによるWebテストTips集 / Web test Tips collection about Geb and Spock
以下、記事を参考にしつつ、自分でテストコードを作成してみてレベルアップする
GebとSpockによるWebテストTips集 - yfj2’s Automatic Web Test Related Blog
参考文献 / Bibliography
- Gebについて / About Geb
- PageObjectPatternについて / About PageObjectPattern
【入門】JavaFX+Geb+Spockでキーワード駆動テスト作成ツールを作ろう（１）
【入門】JavaFX+Geb+Spockでキーワード駆動テスト作成ツールを作ろう（１）
著者：ふじさわゆうき
更新日：2015/06/14
記事概要
「キーワード駆動テスト」が、自動テストの目指す一つの理想となっています。しかしながら、「キーワード駆動テストってどのように作成すればいいの？」と具体的な実装に落とそうとすると、サンプルになるソースコードがなかなかみつかりません。そこで、当ブログでは、キーワード駆動テスト作成のクライアントとして「JavaFX」、自動化言語として「Geb」、テストフレームワークとして「spock」を使って、「キーワード駆動テスト」作成ツールの完成を目指します
そもそもキーワード駆動テストって何？
本記事では「キーワード駆動スクリプトで記述されたテストケース群」と定義します。
下記、表は、テストスクリプトのレベルを示すもので、
「キーワード駆動スクリプト」は、最上位のスクリプトの記述レベルを用いたテストです。
●テストを自動実行するための5つのスクリプティング技法
| LV | 技法 | 概要 |
| 1 | リニア | キャプチャーリプレイツールで操作を記録することで自動生成されたスクリプトを、ほとんどそのまま使うものです。1つのテストケースが1つのテストスクリプトに対応するため、テストケースの数が10倍になればスクリプトの数も10倍と、「線形に（リニアに）」増加してしまいます |
| 2 | 構造化 | 分岐・反復といった、プログラミングの基本的な構造を使ってスクリプトを表現することで、スクリプトの保守性・可読性を向上させることができます。リニアスクリプトや構造化スクリプティングのアプローチでは、複数のテストケースに共通の操作（たとえばログイン／ログアウト、特定の画面への遷移など）に対応するスクリプトがテストケースごとに現れるため、操作に変更が発生した場合、そのすべてを修正する必要があります |
| 3 | 共有スクリプト | テストケース間で重複して現れるスクリプトを部品として切り出し、それらを複数のテストケースから呼び出すことで、テストスクリプトの保守性や可読性をさらに向上させることができます。また、部品同士を組み合わせた新しいテストケースを組み立てることもできるので、リニアスクリプトが抱えていた「線形」の問題から逃れられることになります |
| 4 | データ駆動 | スクリプトとデータを分離します。これによって、「手順は同じだが、入力する値は異なる」テストケースを、1つのスクリプトと複数のデータのセットで実現することができます |
| 5 | キーワード駆動 | スクリプトの部品化、スクリプトとデータの分離を行った上で、さらにそれらの部品を、自然言語に近い「キーワード」として抽象化します。ドメインエキスパートやテストエンジニアは、それらのキーワードを使うことで、スクリプトの内部構造を意識せずに自動テストケースを記述できるようになります |
●出典:『システムテスト自動化 標準ガイド』の第3章 ～ テストを自動化するスクリプティング技法の最新事情と取り組みの事例 , http://bit.ly/1JN5g2S
キーワード駆動テストツールの概要（案）
今後、変えるかもしれないけど、とりあえず全体像を設計してみました。
次回
次は、JavaFXの開発環境構築について記事を書きたいと思います。
