2014/6/21(土),22(日) 「WACATE2014 夏 ~理解、分解、再構築~」に参加しました。

神奈川・三浦海岸で行われた「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味をもつ「Workshop for Accelerating CApable Testing Engineers」、通称WACATEに参加してきました。
http://wacate.jp/2014/summer/gaiyo.html

今回は3回目の参加になります。*1
夏のWACATEはワークが難しいため、昨年はとても大変でしたが、今年も変わらずでした。
ただ、頭をフル回転させる感覚はクセになりますね。とても楽しかったです。


以下、参加レポート。

BPPセッション「外に出てみよう、伝えよう、そして生み出そう」

Input(外に出る)とOoutput(伝える、生み出す)でサイクルを回す話。小さくてもサイクルを回すことで着実に前に進める。ノリと勢いでもいいので、とにかく行動することが大事。
自分にとってはOutputの質が低いのが課題。少量でもいいから、できるだけ情報をOutputする癖をつけたい。

「テスト分析入門 "「ゆもつよメソッド」を例に"」

テストの再利用性を向上させるためにテスト分析手法の一つ「ゆもつよメソッド」を紹介

ゆもつよマトリクス

「何に対して」と「どこに着目するか」で作成するマトリクス。
ゆもつよメソッドでは「何に対して」を「機能」、「どこに着目するか」を「テストタイプ」「テストカテゴリ」と呼ぶ。

「テストケースの再利用演習」

WACATE夏のメインと言えるグループワーク。製品版のテストケースを作るために、ベータ版のテストケースを分析して再利用しよう、というお題。

「ゆもつよメソッド」における「テストタイプ」、「テストカテゴリ」の分解

どうにも適切に分解しきれた感じがしなくて、難しいと感じた。どのチームも分解方法が違っていて面白かった。自チームではソフトウェア品質特性をベースにおいて、必要において小項目を作成していったけど、どのような出し方がより適切かはまだ整理しきれていない。要復習。

WACATE「経験者」としての反省

WACATEは「初参加」の人に積極的に議論に参加してもらうスタイル。だけど、自分は主張を強く出しすぎて、「初参加者」の発言や考える機会を奪ってしまっていたかと思う。ワークで時間のなさに焦っていたからだと思うけど、次からはもっと相手の主張を引き出せるようになりたい。

特別セッション「テスト設計コンテスト'14 優勝チーム講演」

テスト設計コンテスト'14の優勝チーム「TFC KA・RI・YA」メンバーによるテストアーキテクチャについて。

プレゼンが面白すぎ。

内容がとても勉強になったのはもちろんだけど、“見世物”的な面白さがトンデモなかった。
メリハリがあって退屈させない話し方、聴衆の理解に負担を掛けない間の取り方、大きいものから小さいものまで散りばめられた様々なネタなどなど…
「プレゼン資料見ただけでは何を発表したか分からない」って有名だったKA・RI・YAだったけど、その理由は今回の発表で納得。
プレゼン資料欲しいけど、それ以上にプレゼン動画が欲しい。youtubeとかにあったら、毎日見ます。しかし、こんなプレゼンをやるなんて、#かりやこわい

テスト「アーキテクチャ

建築やソフトウェア開発でも使われている「アーキテクチャ」のテスト版。テストアーキテクチャは新しい概念なので、google先生もほとんど知らない。なので、具体例の情報が少なくて、これまで不明だったが、今回の発表で結構スッキリした。
アーキテクチャとは、設計思想、基本構造のこと。
アーキテクチャビューはアーキテクチャを見えるかしたもの。ステークホルダーの関心事*2に合わせたビューを作成する。成果物がステークホルダーの関心事を満たすことを表現するために使用する。ビューは1つですべてを表現する必要はなく、複数あっても良い。

クロージングセッション「レガシーソフトウェア開発から振り返るテストアーキテクチャ設計」

テストに関するよろず話。ただし、内容は広いが深い。
以下、特に興味深かった話。

探索的テストでバグを大量に出す“鼻が利く”人の話

徹底的に記録を取る癖がある。徹底的に追い詰める感覚を持っている(=豊富なバグパターン知識を持っている?)。対象ドメインに対する知識が豊富。

社外にテスト検証を依頼した時の話

依頼したテスト仕様について、大量の質問が来る。なので、テスト仕様について記述力が向上した。また、テスト実施を他社に依頼したことで時間的余裕ができた。それにより、内部に知見がたまりやすくなり、品質の高いテストの生産性が向上した。

テスト先行

バグ修正のソースレビュー時にテスト方針、テスト用入力データもレビューする。バグが新鮮なうちに議論することで、テストの影響範囲や同種のバグパターンについての指摘が得られるようになった。それにより、デグレードが大幅に減少した。

その他

ディナーセッションの抽選会で本を頂きました。前版は持っているのですが、改訂版で結構変わっていると伺っていたので、とても嬉しいです。
f:id:toshimana:20140623233906j:plain

*1:2013夏、2013冬に参加

*2:TFC KA・RI・YAでは関心事の読み方を“かんしんじ”で統一してるらしい