おはようございます。わてぷです。
タイトルの通り、6月15日（土）、6月16日（日）にWACATEのワークショップに参加してきました！
今回初参加です。
とりあえず勢いで申し込んでしまいましたが、行ってみて良かったです。
かなり充実した２日間になりました。
全部が全部理解できたわけではなく、記録も微妙に取りきれていないところもありますが、当日何をやっていたのかを書いていきたいと思います。
WACATEとは？
公式サイトはこちら。
詳しくはこちらを見ていただければと思いますが、２日間かけてテストに関するワークショップを、年に２回開催しているようですね。
今までいくつか勉強会やもくもく会に参加したことはありましたが、泊まり込みのものは無かったはず。
今回は「納期半端ないって！」ということで、限られた納期の中でテストをしていくにはどうすれば良いのかということを中心にワークしていきました。
当日の流れ（1日目）
開始まで
会場についたら、受付へ。
班分けの用紙と部屋割りの用紙、それと名札をいただきました。
名札は3色あり、
- 黄色は初参加
- 緑は2回目
- 青は3回以上
というようになっているとのこと。
当然、自分は黄色。
名札に名前やらどこから来たのかやら書いて、開始を待ちます。
ポジションペーパーセッション
WACATEに申し込む際に、ポジションペーパーという用紙を提出するのですが、それを班の中で発表するというもの。
私は特段書くことが思いつかなかったのですが、他の方のポジぺはまじで気合が入っている。
1回目の班でそれぞれ発表が終わったら、2回目の班でまたそれぞれ発表。
その人のバックグラウンドがよく分かります。
BPPセッション
前回のポジションペーパー賞を取った方が発表するセッションとのこと。
今回は、開発者から見るテストということでお話をされていました。
以下、気になったところ。
- Unitテストをやらない理由
- 色々あるが、やり方が分からない、やりたくても出来ないが大きな理由なのでは
- テストが書きやすい設計とは？
- 問題が単純か？
- モジュールごとにテストしたい責務がシンプルで明確
- モジュール間の依存性がない
- 問題が単純か？
iOSの部分（swift?)の部分は知識がないのでコードの部分はあまり分からないのですが・・・
あと、前から気になっていたのですが、「リーン・スタートアップ」をまだ読んでいないので、忘れないうちに読んでおこうと思いました。
テストの組み立て方
制約がある中で、要求される品質レベルを保つためにはどのようにテストを組み立てていくべきかというお話でした。
とりあえず、テストレベルとテストタイプの理解が足りていないことが分かった・・・
話を聞いた当初はそれぞれがごちゃごちゃになっていたと思う。
（あとで復習してようやく分かったのはここだけの話）
ただ、テスト対象をテストレベルとテストタイプで分解し、メッシュ状にすることで細かなコントロールができるという視点は持っていなかったので、この視点は持っておきたいと思いました。
さて、次からワークが始まるのですが、結構長くなりそうなので次回に分けたいと思います。
結構ざ〜っと書いているので、あとで書き直すかもです。
コメント