『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) を開催してきた #junitbook


前回まででこちらの書籍でのイベント開催は計5回を数えておりました。書籍の進みとしても終盤を迎えつつあるので、いずれどこかで著者を招いて集大成的なイベントを…というのは朧気ながら考えてはいたものの、これと言って明確なプラン等はまだ立てておりませんでした。

…がしかし!まさかの展開で今回の『特別編』が開催される事が決まり、この日(5/12)朝から夜まで丸一日費やして、ひっじょ〜に濃い〜内容で勉強会を実施出来ました。

特別編開催までの経緯

…まぁ、1つは著者の渡辺さんが5/11にJJUG関連イベントに参加の為東京に来られており、ちょうどこの日(5/12:日)が空いてるのでこんな感じでイベントどうか、というお話があったので、それを快諾したと言うのがまず1点、ありました。

イベントそのものの内容については、渡辺さんの方にも色々と意図があるでしょうからその辺りはご本人のブログなどで詳細を語られる事を期待したいと思います。:-)


また、イベント開催決定を受けて半ば冗談半分でいろふさんにもオファーしてみたところ『行きます!』とのご返事が。あれ?w 別のインスタンスが出てくるのかな…等など推測してみたのですが、いろふさんも渡辺さん同様、この週前後に開催されるJava関連イベントに参加のため東京方面におられるとの事でした。折角来られるというので何かお話を…というオファーにも快諾して頂きました。

著者御本人(渡辺さん)の講演&ハンズオンだけでもお腹一杯なのに、更に『いろふ』さんという要素が追加された事によって当日の期待感が否応も無く高まって参りました。

参加者募集ページの状況を見てもそれは明らか。これまでの開催回(全5回)でもそんなにキャンセル率は多くなく、居ても2〜3人程度。キャンセル待ちも居て2〜3人、という状況でした。それに対して今回は募集定員20名に対して参加募集で登録された人は総勢30名超。

当日の参加キャンセルも体調不良が回復せず止むを得ず…という方を除き、全員参加でした!脅威の参加率ですねw

開催前

当日の内容は『講演+ハンズオン』、更にはテーマ内容に応じた環境を諸々準備した上で臨むという事なので、事前に配布資料&ソースコードが展開されました。諸々含めたアーカイブはこちら。


また私は私で、イベント進行を無事に進めるべく細々とした作業や準備をやっとりました。進行スライド資料とか、座席表の要素集めとか...

前日

前日5/11(土)はこちらの勉強会に参加しておりました。こちらもこちらで非常に内容が濃く、懇親会も引き続き参加したい思いがあったのですが、翌日のこちらのイベントの事もあり断念。

また、このイベントの後に近くのオリジン弁当で『まとまった注文は可能か』という折衝をしていたのですが、予め決まったメニュー・個数は1週間位前からでないと頼めない様でした…。今回はイベントの参加者総数が正直読めない部分があった(当日の状況次第)のと、メニューから何を頼むかの算段がこの時点で全くついてなかったので、『朝早めに一度確認に行って、当日注文可能なものをピックアップ、そこから参加者が好きなメニューを選ぶ』形を取ることに。

当日 早朝

当日の朝は早めに起きてお店に来店。そして注文可能なメニューをオリジン弁当のおばちゃんと折衝(笑)、商品をピックアップして開始直後の注文に備えました。ちなみ利用したお店はこちら。


そして今回も利用した会場は御存知横浜タネマキ!前日は雨降りでこの日も崩れるのかな〜と若干心配しておりましたが、当日はこんな感じで素晴らしい天気に恵まれてました。そこまで暑くもなく、風通しも良くて過ごしやすい一日だったと思います。

[:400]

10:00 - 10:15 開始・会場諸説明等

ほぼ時間通り、10:00にイベントスタート!当日司会進行で利用したスライド資料は以下となります。

なお、開始前で18名集合、10分程遅れて1人到着と言う素晴らしい出席率でありました。(※非常に残念ですが残り1人の方は体調回復せずと言う事で欠席となりました)


冒頭は毎度のように『横浜タネマキなう!』しかし今回はいつもとメンツが違いますw

そしてこのタイミングで弁当発注!予め注文可能なものをオリジン弁当おばちゃんに挙げてもらい、それらの中から好きなものを選び、注文すると言う方式を採りました。程良く注文が散らばる感じに。そしてこの後偶然ですが奇跡が起きたのでした...(その辺は後述)

10:15 - 10:55 自己紹介

…という事でしたので、ある意味『いろふさんに向けた各者自己紹介』的な時間。

-お名前
-どんな事をしているか?
-なにに興味があるか?
-TDDBCに参加した事があるか?
-Javaやテストの経験等
-今日、どんな事を経験したいか?

渡辺さんが用意されていた上記テキストが書かれたスライドを表示させながら、各自順番に自己紹介を進行。見出しに書いてある時間を見ても分かるように、トータル40分(!)を掛けた自己紹介タイムとなりました。もうこの時点で大きな笑いも出ていたりで、場の雰囲気としては十分に温まっている状態でした。参加者の皆さんの人となりや最新トピックが分かってとても良い時間だったのでは、と思います。

また、このタイミングで割と少なくない数、『TDDBCには参加申し込みをしたものの、抽選に漏れて参加出来てない』『TDDBCに参加しようと思ってサイトを見たら既に受付終わっていた(時期を逸した)』という発言が聞かれたのが印象深かったです。都心でのTDDBC人気(及び競争率高騰問題)は中々に悩ましい点ですねぇ…。

11:00 - 11:30 講演『テスト駆動開発を継続する』(『TDDBC Osaka 2013 1月 外伝』発表再演)

ここからはいよいよイベント前半部分:講演。

まず最初に『JUnit実践入門』著者:渡辺さんによる本イベントの趣旨等をご紹介。


そして!本拠地大阪のみならず、日本各地...いや世界中でインスタンスの存在が確認され、誰もその総数、実体、その他諸々の事項に関して真実を知る者は居ないという(しろめ)...iRoF(TwitterID:@irof)さん(リアルインスタンス)が横浜のこの地に登場!自分目の前に座ってたので写真もこんな目の前!w

毎度おなじみのアイコンも相まって行く先々で大人気のいろふさん、今回も首から下げているアイコン付きの名前カードを見て、『あ!』という感じで指を指される事が多いのが切ない、と話しておられました...(´・ω・`)w


今回、いろふさんの参加決定と同時に何か話して欲しいというのはありましたが、渡辺さんのリクエストもありいろふさんにはこちらの再演ネタでご講演頂くことに。資料はこちらです。今年頭に大阪でお話されたものの再演になります。

TDDBC大阪外伝についてはこの辺りをご参照。資料も再演ネタなので詳細メモは省きます。


講演終了後はQ&Aタイム。幾つか挙がっていた中で抜粋して1つこちらでご紹介。

  • [Q].『動いているコードは触らない』というのがあったが、『予測不可能な事が起きるから触らないんだ』という意見もある。また、『テストを書く』と言う事は変更したら失敗するだろう、という予測の元に書いている。…どういうテスト書けば良いんですかね?
    • [A].
      • その辺を保証しようと思ったら、テストエンジニアとしては網羅の話を絡めていく。また自動テストでカバー。
      • 少なくともその範囲を漏らさないようにする必要がある。ソフトウェアの世界で制御可能な部分はあるはず。
      • 予測不可能をどこまでカバーするか、この辺、予算見合いな部分もある。
      • この辺のバグはこの層でカバー出来る…と言った感じで、カバーする方法は何かしらあるはずだ。
      • そして、その辺のモヤモヤを解消するのが今日のハンズオン。


いやぁ、目の前でいろふさんの講演を聞けて良かったです。しかし目の前に居たいろふさんは本当にリアルインスタンスだったのだろうか...(しろめ

11:30 - 12:30 講演『受け入れテストの自動化とユースケース駆動開発 -Pre Cucumber Boot Camp-』


そして本日のメインイベント、渡辺さんの講演です!現時点でスライド資料UPは検討中との事でしたので、写真及び資料として個人的に頂いたものの中から幾つか抜粋して画像として掲載致します。以下メモ。


  • 今回は、どちらかと言うと"開発"の話です。
  • cucumberを使う事でユニットテスト要らないんじゃないか、という話が出る事がある。しかし、自分は状況によっては居るのでは無いか、と思う。
  • Railsの場合は設定のみで動く、コードをあんまり書かない。ユニットテスト的なテストコードを書くとRailsのサクサク感が死んでしまう。
    • 設定されていれば動くけど、ミスってれば動かない。→ロジック=フレームワークのバグ。
    • ならユニットテストやるよりも受け入れテストをやっちゃえばいいんじゃない?Railsとしてもこっちの方が良いのでは。と思った。


  • テスト駆動開発プログラマを救ったか?
    • TDDは我々プログラマを救ったのか?→『YES!』
      • 確かに救った。動作するきれいないコードを手に入れた。
      • シンプルな設計になり、自動化されたテストによって急なリリースや仕様変更に対応出来るようになった。
    • もう何も怖くない…でも現実の開発でも同じ事が言えるの?
    • 顧客が本当に必要だったもの:顧客の要件を満たして居なければ、ただのゴミなのである。
  • TDDは銀の弾丸ではない。目標は顧客の要件を満たすこと。
  • TDDは開発を支援するが、品質は保証しない。
  • TDDはテストリストが起点
    • プログラムが満たすべき仕様をリスト化
      • 最初に全てを抽出出来ない
      • テストリストは随時、追加・修正
    • 具体的な仕様(例)が必要。getListで1件のデータが取得出来る、等。
  • 要件からテストケースを導く
    • 『何を構築するか。』が大切。
    • 外部的振る舞いを設計する(→外部設計)
      • システムが満たすべきテストケース
  • 外部設計とテストリスト
  • TDDは開発手法
    • 良いプログラムは開発できるが、良いシステムになるとは限らない。
    • 良いシステムは顧客の要件を満たすシステムであり、要件を満たすテストリストを作ることが重要。
  • 外部設計の手法
    • 顧客の言葉を使う。
    • 顧客が理解出来るツールを使う。
  • 外部設計とは?
    • システムの外部的振る舞い
      • 利用者視点
      • 要件定義とのトレーサビリティ
      • システム化するスコープ
    • 実装とのトレーサビリティ
      • 内部(システム化方式)に依存しない
    • ※利用者視点で考えたら、自動販売機も『お金を入れてボタンを入れたらジュースが出てくる』以外は何もない。
  • システム境界
    • システムと外部の接点
      • どこからがシステムの機能、データなのか?
    • ユーザーインタフェース(画面)
      • 外部インタフェース
  • この辺りについては、神崎さんの本が参考になる。※外部設計の本。RADRAという開発手法を使ったもの。
  • トレーサビリティ
    • 追跡(トレース)性
    • 成果物同士が論理的につながっているか?
      • 各フェイズでの成果物の整合性も必須。
      • 要件定義 - 外部設計(比較的保てる)
      • 外部設計 - 実装(保ちにくい)

ユースケース駆動開発実践ガイド (OOP Foundations)

ユースケース駆動開発実践ガイド (OOP Foundations)

  • ユースケース
    • システムの機能を表すシナリオ(使用例)
    • 外部的な振る舞いと内部的な振る舞い
      • システムと外部とのやり取りを記述する
    • 要件定義フェイズで抽出され、外部設計フェイズで詳細化する
    • 例:書籍を登録する
      • 必ず箇条書き、1行で1アクション、文末は『〜する』(『〜出来る』は厳禁:やるの、やらないの?)
  • 書籍を登録する(分析を反映)
    • 管理者が復数居る..あれ、管理者は一緒?
      • この分析で判明する。分析をすることによって文章の曖昧さが消えていく。
      • ユースケースシナリオが綺麗に書かれていく。

  • アーキテクチャの適用
    • 言語/フレームワークの選択
      • Rails,Javaee,Django,CakePHP...まぁ、結局はどんなフレームワークや言語を使っていても出来るものは出来る。
      • 分析の時点で必要なクラス・メソッド・テストケースを割り出せ、見積もれる。
      • 確認画面増える→コストが増える事が確認、説明出来る。
      • 理論的に使えば武器にも成る。細かい点は異なるが、骨格は変わらない。
    • ※多くなってくるとレビュー辛い、って言い出す。→削るという方向性も出せる。

  • テスティング
    • 書いて責任を持てないコードを書くな!
  • アジャイルテストの4象限
    • ユニットテスト:技術面でチームを支援。プログラマが楽になる。自動化前提
    • 受け入れテスト:ビジネス面で製品批評(クオリティ)を支援。手動。
    • 機能テストと受け入れテストはコンテキストにもよる?


  • cucumber/selenium
    • cucumberとは?
      • 受け入れテストを自動化するフレームワーク
      • 自然言語でテストシナリオを記述
        • フィーチャーファイル
      • テストシナリオをプログラムに変換し実行
        • ステップ定義

    • seleniumとは?
      • プログラムでブラウザ操作を制御するツール
      • ブラウザのコントロール
      • 表示されている項目の検証
  • cake/seleniumによる受け入れテスト
    • 今回はこちらの範囲をワークショップで実践します。


締めは質疑応答。こちらの講演でも興味深い質問が幾つか挙がっておりました。

  • [Q].シナリオ箇条書きの部分について、『***の場合』という風に書くのはアリなのか?
    • [A].
      • なるべく簡単に書くことが前提。前提条件に書いてしまうという方法がある。この場合、"代替シナリオ"などを用いる。
      • 『***の場合』:これってそもそも別シナリオじゃね?
      • 代替シナリオに書けるもの→バリデーション等が該当。
        • 例:一般ユーザと管理者ユーザの『ユーザ登録』。
          • 主シナリオに『***の場合』とあるのはNG。
          • この場合別シナリオになるだろう。一部同じ部品を使っているかも知れないが。
          • 主シナリオには分岐は無い。
  • [Q].ユースケースは『人が使う』、アーキテクチャは横串。その辺とユースケースのくくりをどのように扱うべきか。
    • [A].
      • 結局このシナリオを作る人は、実装する人しか作れない。アーキを知ってない人がやっても作れない。
      • 1本2本ユースケースを書いたなら、6人チームで1人2人が先行してフレームワークを調べながら
      • プロトタイプでスパイラルを回してく。
  • [Q].(上記の質疑応答を受けて)それらが出来る人のスキルセットはどのようなものがあるか。リードする立場、メンバーの立場それぞれで。
    • [A].
      • メンバー:アーキテクチャを理解出来ているか否か。『登録する』ならSPringのcontrollerの***でXXXする、とかに落とし込めるレベル。
      • リーダー:それらを上から下まで見通せる人でないと厳しい。


ちょうど良い感じでお昼御飯の注文状況も良さげ(20人分出来ました)なタイミングで、午前の部(講演)は一区切り。

渡辺さんは講演途中から、頻繁に以下のフレーズを口走っておりました。相当思うところがあったのでしょう...w

12:30 - 13:30 昼食

お店は近くにあるとは言え、さすがに20人分ともなると結構な量となるため、参加者数人にお願いして分担して弁当を取りに行くことに。

で、ここでちょっとした奇跡が起きました!注文取る際は特に厳密に値段を気にすること無く(大体500円前後のメニューをチョイスはしたが)、また参加者の皆さんも特にその辺気を付けている訳でも無かった(と思う)のですが...

レシートを見てみるとなんと、お会計が10000円ちょうど!これにはオリジン弁当のおばちゃんも笑っておりました。これが証拠写真w

タネマキに戻り、各自チョイスしたお弁当を食しながらしばし休憩。

また、この時間で"ステッカー職人"@sue445さんから、いろふさんステッカーの配布が行われました。今回は何とメタリック仕様!この色味が、まぁ何とも言えない感じでMacBookAirの本体カラーに馴染む...w

そしてこれとは別に、いろふさんステッカー(ノーマル)、ゆとりさんステッカーも併せて配布されておりました。

座席表もこのタイミングで更新・公開。部屋の周りにいる物体は...気にしちゃだめだ。

13:30 - 17:30 ハンズオン

午後は一転、ハンズオン尽くし。

基本的に各参加者に考えてコードを書かせるという流れでは無く、渡辺さんの解説、進行に従ってコードをコピペしながら理解を深めていくという感じ。

資料は計2点、以下のzipファイルとイベント時間内で配布、展開されたもう1つのソースコードファイル等一式。(こちらは一般公開されず、参加者限定)

資料及び進行内容はとても丁寧なものであり、理解もしやすかったですね。こういった諸々環境構築及び設定作業が必要なハンズオン等は、その環境設定諸々で時間一杯となったり躓いたりしがちですが、今回のハンズオンは皆さん着いて行けてたようで満足度も概ね高かったのではないでしょうか。

  • 背景、要点等をまず説明
  • コピペでコードを貼り付け、動作確認
  • ソースコードリファクタリングを適宜行い、テストコードの追加をより効率化させていく

この辺りも、自分含めて参加者の皆さん、着いては行けてたけど若干ヒーコラ言ってたような気がしなくもないw 学ぶべき点は結構てんこ盛りだったからな〜。渡辺さんや他の参加者の方々に詳細なレポート等を是非ともお願いしたいところです。

17:30 - 18:30 自由時間他諸々作業など

この辺りからは、流れ的にはハンズオン本編は終わり、エクストラで用意されている課題を個人の思い思いのペース、選択で進めて行くという時間。勿論、その際の渡辺さんやいろふさんのサポートもあり。

まぁ、先にも書きましたがここまでの講演&ハンズオンまでで相当濃密なペースだったので、休憩的な時間に充てている人も多かったような気が。休憩に充てていたり、ジョジョ読んでる人もちらほらと。


そんな中、自分は休憩を挟みつつこんなことしてました。

KPTをその場で改修→文字起こし

渡辺さんが19時過ぎには会場を後にし、飛行機で札幌に帰らなければならないということでこのタイミングでKPTの文字起こしを決行。参加者の皆さんが付箋書きを追え、各要素を置きにいったそばからそこの付箋をひっぺがし、テキスト(Google Docs)に書き起こすという作業を実施。付箋自体の枚数は50枚程度でしたが、ものの25分程度で全ての文字起こしを完了してました。この作業、わりかしイベント終了後に時間を置いてから…というのも多いような気がしますが、分担作業などしてしまえばそんなに時間掛かるものでもないですし、イベント期間中に文字になっていたほうが何かと便利な気もしますので、時間配分的に調整してお試しになってみてはいかがでしょうか。

  • Keep
    • JUnit読書会の参加
    • 休日に活動した
    • 自分にとって新しい技術を学んだ
    • 慣れない開発環境で何とか着いて行けた
    • Webアプリケーションテストのイメージが明確になった。
    • Gradleで同じ事が出来るか、チャレンジ出来た。
    • 自分が書いたコードは最低限、正常系の自動テストは書く
    • チュートリアルの説明が分り易かった
    • ハンズオンの準備が十分に出来ていて、比較的滞り無く進行出来た
    • 教材が、色んな要素を含んでいて良かった。
    • 洋書のCucumber本よりRSpecBookが良い。尚、翻訳は残念らしい。今度読んで見たい。
    • JavaSeleniumを初めて触る事が出来た。
    • 今日の課題を無事終えることが出来た。
    • モヤモヤしていたCucumber+Seleniumのテストのやり方はハッキリした
    • ハンズオン形式は理解しやすい
    • irof 横浜インスタンス
  • Problem
    • 途中ついて行けない時があった→何とかリカバれた?
    • 何かひとつ挑戦するテーマ(Groovyで、とかGradleで、とか)を作った方が良かった...
    • 最初の環境構築で躓いて、少し時間が掛かってしまった
    • importするクラスを間違えていて、1時間位迷走(ムダ)にした
    • めっちゃ疲れた
    • IDEAの最新版でサポートしている事に気付いたのが終盤だった事
    • 書籍一覧の説明で、追加分のソース内容が追えなくなったので、どこかで参照出来るとありがたい
    • 素のJavaでテスト書くの、おつらい...
    • Eclipse重い
    • SeleniumWebDriverでHomeページを開くまでに時間が掛かった
    • 独力でシナリオ書くのはまだ辛い(Seleniumに慣れていない)
    • Cucumberでのシナリオがまだ書けない。
    • コードを写せないところがあった。(配布テキストに全コードがあると嬉しいです。見落としていたところとか)
    • 付いて行くのに精一杯だった
  • Try
    • IntelliJ! IntelliJ
    • Webテストを楽にするツールを調べる(Groovy, geb...)
    • 会社でSelenium,cucumberをやる
    • CRUD全部を書いたサンプルを見たい
    • 今日やった内容をIntelliJで復習
    • 打倒『Excelでのテスト仕様』。
    • シナリオ(features)の作り方をもっと学ぶ!→関連書籍を読んでみる。
    • 今やっている案件(Java/Seasar2)へ試してみる
    • Gebで同じ事が出来るかやってみる
    • シナリオを書けるようになる
    • 機能追加版をもっとやりたい!
    • 新しいPCを買う
    • Webアプリを作りながらCucumber-junit + Seleniumを試す
    • 事前に時間を作って準備する
    • jenkinsでも動かしてみたいので設定内容一覧を提示して頂けるとありがたいです。
    • 追加のfeatureを自分でも作ってみる
    • gebで同じ事をやってみる
    • スライド最後のJenkinsの設定スクリーンショット下さい。
    • 復習(もう1回、自分でやる)
懇親会のネタ集め(主に"いろふの部屋")

ここまででも十分内容の濃い時間でしたが、せっかく渡辺さん、いろふさん両名が来られている訳だし、懇親会の時間も内容濃いものにしたいな〜といろふさんに何かネタが無いかと訪ねてみたところ、後述する『LTの件』と逆に『いろふさんが聞いてみたいテーマ』で話が膨らんできたので、急遽その方向で催しを行う事に。

また、このタイミングで数名の方には懇親会で飲み食いするものをそれぞれ調達しに行って頂いてました。ご協力ありがとうございました。

18:30 - 19:15 懇親会(ふりかえり)

アルコールと食べ物(ピサ等)が届いたのを受けて、ゆる〜りと懇親会開始。

またこのタイミングで、横浜にちょうど戻っていたenum(TwitterID:@enum)さんが懇親会から合流。のっけからの挨拶で、早速場をロックしておりました...w

懇親会冒頭は普通の立食形式でしたが、渡辺さんが今回のイベントについて、参加者の皆さんからフィードバックをもらうという形で進行。懇親会と言いつつ皆普通に座って本編と変わらずな感じでしたけどね。こちらでも色々濃い〜話が聞けました。

19:15 - 20:25 懇親会(いろふの部屋)

  • 懇親会前の時点でいろふさんにも色々ネタが無いか聞いていたところ、幾つか興味深そうなネタが出て来たので急遽構成を決め『いろふの部屋』を開催する事に。こんなだ! 突貫で作ったのでクオリティが低い低い...w


ちゃんと、当日はこの音楽も流しましたよ。:-)
:w500]

挙げた質問は以下。メモ取れてたところだけ記載。

いろふさんからの質問 その1

  • 同値分割、境界値分割...この流れで後2つ挙げられますか?
  • テストエンジニア、欲しい?→欲しい!
    • でも実際やってくるテストエンジニアの希望像が理想と現実で異なる
    • 理想はこのへんを知っている技術者、でも来るのは茶髪のにーちゃん
      • えなむ氏『一体何人の人を亡き者にしたか分からない…』
    • テストの世界がどんなものがあるか、知っておいて欲しい。
    • 技法・知識は知っておくと便利。

ソフトウェアテスト技法

ソフトウェアテスト技法

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

  • テスト技法はマストなんじゃねぇの?(えなむ氏
    • デシジョンテーブルは書けるようになってほしい。
    • 原因結果グラフ
    • segテスト
    • 直交表だけは、使い方が分からなくとも使えるようになっておいて欲しい。
    • まともに使うようになってくると、HAISTとかも。

いろふさんからの質問 その2

  • 早く帰りたいから
  • 回避テストしたい
  • 働きたくない...仕事なんてなくなれば良いのに。

 

  • コスト。でも自動化やるとコスト上がりません?
    • 単発のものは上がるけど、続くものについては効果が出る…と信じたい。
  • テスト自動化=コスト。
  • "自動化"=繰り返せば繰り返すだけ…という意味合い。
  • 人を責めない。自動化すると人を責める事も無くなる。
  • 再現性があるのが強み。
  • 書いたものしかテストされない。イケてるテストオペレータって超常的な能力を身に着けている。
    • そういうところだけに寄り添う事が危険。
  • テスト技法の1つ:探索的テスト。
    • いろふさん的にはどう説明する?『経験にもとづいて今まで出したバグを画面で再現する』
    • 『匂いを感じ取る?』
    • いじわるテスト。探索的テストが経験を積むことによって…
  • 運が悪く、踏んじゃう人。掘り返し能力の高い人w
  • アクションゲームで壁すり抜けが得意な人とかいるよね〜。
  • こういう作りの時にはこういうバグが出る、という暗黙知暗黙知はもう少しすれば形式知に出来る?

いろふさんからの質問 その3

  • WinRunner:かなり高いツール。今のseleniumみたいなもん。QTPの前身。
  • WIndowsのマウス・キーボードのマクロ。
  • xUnit
  • rSpec
  • Selenium
  • Jmeter
  • Jenkis
  • Sikuri Script
    • ファジング
  • TestLink:使っている人居ますかね?
    • excelベースででもちゃんとテスト項目表とか作れるのであれば使うと幸せになれるかも。
    • あんまワクワクしない
  • スクショがExcelに貼り付けられる。
  • Winshot
  • Seleniumスクリーンショットが取れるらしい。takeScreenshot
    • 画像の差分取る場合は画像のdiff取らなければならない。
    • JUnitと連携して使う場合、落ちた時にスクショ取る等のルールを作ると便利。

いろふさんからの質問 その4

  • 出家するまで
  • 考えるのをやめる
  • 許容出来る不安になるまで『最悪部長に怒られるけどいいか』
  • これでもういいや、の当たり:
    • 作っているプロダクトが何に役立つか
    • 何人がこのプロジェクトでコケると死ぬのかw

 

  • 言い換えよう:どういう状態になったら不安じゃ無く成るか?
    • カバレッジ100%なら不安じゃないのか。
    • 自分の銀行口座に2億あれば不安じゃ無く成るのか。
    • 網羅できないから、不安になる?
  • いつテスト終わるんだ、というポイントがない。
    • これで終わり、というのがない。
    • プロダクトの戦略にもよる。バグ収束曲線、クリティカルバグ発生率とか。
  • 終わりどころを何か持ってないですかねぇ…
    • 上がどんだけお金を払えるか、がリミットなのかな〜。
  • 上司を殴っちゃえば良いんだ、と思えたら不安は無くなる?w
  • タイムアップで諦める、なら正常系だけ動けばいいという基準を持てる?

いろふさんからの質問 その5

  • 『読む』で計3人が挙手、いずれもJUnit4系。ま〜読みにくいよね。

いろふさんからの質問 その6

  • 和田さんはモック派。
  • 都合の良いデータを作る場合は使うよね?
  • 過渡期で使う。DBとかまだねーし。
  • 不安だから作り途中で使う。
  • スパイ:コネクションがどういう形なのか見えない場合があるときに使う。


まぁ基本酒が入った状態での駄話でしたけどねw でも皆さん、色々なところから話が派生したり盛り上がったりでとても楽しい時間でした。

20:25 - 20:30 懇親会(締めLT)

当会最後は、いろふさんによるLTで締め。『TABOK』(自動テスト知識体系)に関する『8つの誤解』というテーマでした。






本編・懇親会含め、第6回特別編は以上で終了!

終わってみればこれまでのシリーズ全6回中、最大人数(20人)、最長時間(10時間超)、最も内容の濃いものとなった第6回。参加者の満足度も相当に高かったのでは無いでしょうか。インプットする内容が多過ぎて参加レポートのまとめ自体も1週間後となってしまうなど、個人的にはありましたが...(^^; )

参加された他の皆様も、書こうと思ってるけどボリューム的に...という方はいらっしゃるかも知れませんw その場合でも大丈夫。部分部分でも、トピック単位でも何か得るもの、思うことがあればブログ等でアウトプットして頂けると主催の私としても、講演された渡辺さん、いろふさんとしても嬉しいと思います。なので参加者の皆さん、是非ブログを!(笑)


札幌から著者の渡辺さん&大阪からいろふさん、そして当日ご参加頂いた皆様、ありがとうございました!

次回お知らせ:

次回第7回は、当初第6回として行う予定だった内容のスライド(順延)となります。CIをメインとした内容、『第14章 コードカバレッジ』『第15章 継続的テスト』を対象とします。現在数名、参加枠に空きがありますので興味のある方は是非ご参加ください。