WACATE2015冬に参加してきました
こちらの二日間泊りがけのワークショップに参加してきました。
WACATE2015 冬 ～1年の計はWACATEにあり、2016年テスト始め～ 開催概要 - WACATE （ソフトウェアテストワークショップ）
WACATEとは？
詳しくは公式サイトをご覧ください。
WACATEとは - WACATE （ソフトウェアテストワークショップ）
要するに、土日の二日間泊りがけでテストについて勉強しまくり、『楽しかった！』『また行きたい！』とか言うヤバイ人たちが集まるイベントです。ちなみに私もヤバイ人で、今回が４回目の参加になります。いつの間にか、もうすぐ常連レベルです。今回もとても楽しかったなあ。
どんなセッションがあったの？
セッション概要を知りたい方は公式ページをご覧ください。
WACATE2015 冬 プログラム内容 - WACATE （ソフトウェアテストワークショップ）
Togetterまとめはこちら。ブロッコリーさん、いつもまとめありがとうございます。
本記事では、各セッションについて感想を書いています。ページ内リンクを貼ったので、見たいところから見ていただければと思います。
注意：全部読もうとすると、長いです。
気になるところだけ、読んでいただければと思います。
突撃となりのテスト計画 〜こんなときお隣さんはどうしてる？〜
オープニング
WACATE実行委員の並木さんによるオープニングセッション。今回は非常に初参加の方が多かったのが印象的です。常連参加者もいつもよりは少なかったのではと思います。でもその方がWACATEの趣旨としては良いような気もします。自分もいつかはWACATEを卒業するのでしょうが…もうしばらくは勉強させていただくつもりです。
いつもこのオープニングセッションでとてもテンションが高まります。高揚感というか非現実感というか、、やはりいつもと遠く離れた地で開催されているのも意味があるのだと思います。
ポジションペーパーセッション
プレゼンテーションの勘所
印象に残っているのは「一番伝えたいことは何か？」ということです。
ポジションペーパーを使った自己紹介は、このセッションでは3分という時間制限があるのですが、お恥ずかしいことに、自分は「どうやって３分の枠に収めるか」ということしか気にしていませんでした。しかしながら、当然プレゼンテーションで必要なことは「ポイントを絞って伝える」ということです。仮に時間が長かったとしても、ポイントを絞らないプレゼンは的外れなものになってしまうでしょう。そう言った意味ではとても意義深いセッションでした。自己紹介の際も、内容をいくつか絞って話すことができたように思います。
グループの方々
今回は初参加の方が多かったのですが、ベテランかつ初参加の方も多いように思いました。というのも、「若手が普段どんなことを考えているのか知りたい」とのことでした。そういった考えでこのようなワークショップに参加されるのは、若手の立場からしてもとてもありがたいことだと思います。ベテランと若手で「わかりあえない」のではなく、お互いに歩み寄り「わかりあえる」ような関係になれたらと切に思いました。
私の「テスト」、あなたの「テスト」
前回のWACATEでベストポジションペーパー賞（事前提出のポジションペーパーが、参加者投票で一位になった賞）をとった浦山さんのセッションです。
今回はセッションの中でお絵描きをしました。ただ、はじめからお題がわかっていたわけではなく、この手順で絵を描いていくと、最終的にどうなるでしょうか？周りの人と比べてどうでしょうか？という交流に使われました。自分の場合は「あー、お題はこれか」と描いていくうちにわかっていきました。（描く前にされた話の内容も影響したように思います）ちなみに自分が描いたものはこちら。
予想に反して（？）けっこう同じものを描いているな、と思いきや、かなり違うものを描いている人もしました。
例えば「三角形の上に円を描いてください」という指示は、具体的なようであいまいです。三次元的に三角形の中（上）に円を描くのか、それとも三角形の上側の頂点に合わせて二次元的な上に描くのか。どちらも三角形の上に円を描いています。
見方を変えるという意味ではこの演習って同値分割にもつながるのかな、と書いていて思いました。なるほど奥が深い。きっと浦山さんは、この演習を通して「思ったより色々な解釈ができること」「曖昧性をもった指示をすることで起きること」について伝えたかったのではと推察します。
また、ソフトウェアテストについてマインドマップを描いてみるという演習もしました。自分の場合、なぜか偶然カラーペンを持参していたのでカラーでマインドマップを描きました。
しかしお題も「テスト」としていて縛りもほとんどなかったので、周りと見比べると全然違うことを書いていたりして面白かったです。マインドマップには趣味とか考えとか興味・関心が顕著に現れるので、その人の考え・悩みが透けて見えるのも交流の手助けになるように思います。改めてマインドマップは交流に役立つツールだなと感じました。
突撃となりのテスト計画 〜こんなときお隣さんはどうしてる？〜
これも非常に有益なセッションでした。 自分自身、テスト計画がうまく活用できていないなと感じていました。
印象に残ったのは、「テスト計画を途中から見なくなる。使わなくなる」という悩みに対し、「それは活用するに価するテスト計画を作っていないから」という回答。これは刺さりましたね…
じゃあどんなテスト計画をつくればいいのさ？というのに対する答えがこちら。
テスト計画は戦略、段取り、成果物の三位一体と心得よ*1
これはなるほど、と得心しました。テスト計画においては「戦略、段取り、成果物のどれを定義しているか？」というのを明確にしながら進めると良いということです。確かにこれら全部をひっくるめて「テスト計画に問題があるっぽい」と思っていては、なかなかテスト計画の改善にもつながりません。このセッションでは、
- 戦略 ：何を確認する？優先度はどうする？
- 段取り：戦略を実現するために、リソースをどう活用する？具体的な作業は？
- 成果物：バグ管理表、ドキュメントなど
という具合に説明されていたと思います。
セッションでのワークでは、テストにまつわる悩み・課題を共有し、その解決策をグループで考えました。残念ながら解決のための具体的対策まではここで到達することはできませんでしたが、改めて293の鉄則を読み直し、テスト計画を考え直そうと思いました。悩みの解決策は一つとも限らないので、焦らず一つずつ改善していきたいです。
PFDを用いたテスト計画
個人的に今関心が強いPFDが扱われて、私は心の中で歓喜しました。というのも、まだ不勉強でPFDの資料を読んでも使い方がいまいち理解できていなかったのです。
PFDの書き方: ソフトウェアエンジニアのための“硬派”のブログ
福良さんの紹介されていたPFDの書き方は、とてもわかりやすく実践しやすそうなものでした。書き方は次のようなやり方を紹介されていました。
- 必要な成果物を洗い出す。
- その成果物を作るプロセスは何か考え、線でつなぐ
- そのプロセスに入力として必要な成果物は何か考え、線でつなぐ
あとは2〜3を繰り返していきます。
ちょっと汚いですがその時のメモです。
ちょっと試しにどんな感じになるか、システムテストレベルの例をとって考えてみました。
試し書きなので抜けもありそうですが、確かにこうして可視化してみると段取りと成果物の関連が理解しやすくなりますね。あとやってみると感じたのが、これ書くの結構楽しいです。マインドマップに似てるんですかね？「他にどんなプロセスがあるかな？」「成果物はこれだけでいいかな？」と考えるきっかけになってとても良さそうです！
セッションでは以下のようなメリットが紹介されていました。
- 最終成果物までの作業と、必要な成果物を見通せる
- 作業の目的を明らかにする
- 準備不足を防ぐ
- 全体が見えることによる安心感
また、作ったPFDをWBSの元ネタとすることもあるようです。いろいろな活用ができそうですね！
わりとディープ？同値分割↔境界値分析
今回は主に、テストケースを減らすためのテスト技法として同値分割、境界値分析、ドメイン分析が扱われていました。
また、テスト技法というよりも、概念としての同値分割ととらえるとさらに深遠な話になります。リナさんの同値分割についてのまとめは非常に読み応えがありおすすめです。
演習では実際に同値分割、境界値分析、ドメイン分析について問題を出題され、実践してみました。同値分割、境界値分析についてはなるほどそうだよなーという感じだったのですが、ドメイン分析ともなるとそう一筋縄ではいかず。
大きな勘違いポイントがこちら。
ONポイント、OFFポイント、INポイント
JaSST'11 Shikokuでの秋山さんの資料がこちら。
ドメイン分析におけるONポイント、OFFポイント、INポイントについて個人的な理解を述べてみます。
ONポイント：定義域（ドメイン）の境界に隣接する「ドメイン内部」の値
OFFポイント：定義域（ドメイン）の境界に隣接する「ドメイン外部」の値
INポイント：定義域（ドメイン）の「内部」の値
と思う方もいるかもしれませんが、これは嘘です。
本当はこちら。（僕の個人的な定義です）
ONポイント：仕様上、指定されている境界値
OFFポイント：ONポイントから見て、境界を挟んだ向こう側かつ、境界に隣接した値
INポイント：定義域（ドメイン）の「内部」の値
こちらにも定義が紹介されていました。
ONポイントとOFFポイントを正しく理解できるかが鍵となっていて、ONポイントはあくまで「仕様上、指定されている境界値」であることに留意すべきです。境界のどちら側にあるかは、ONポイントを定義する上では考慮しません。具体的な問題を出して考えてみます。
問題
婚活サイト利用者Aさんが、サイトを利用して結婚相手候補者を検索する。以下の条件に合格するものが検索結果に現れることをテストしたい。なお、入力値は整数に制限されるものとする。
- 年齢(X)：20以上、30未満
- 身長(Y)：175以上
- 年収(Z)：600万円以上
この時、Binderのドメイン分析を用いて、ドメイン分析を実施しなさい。
この問題において、各変数のONポイントは以下のようになります。
ONポイント
年齢(X)：0, 20, 30
身長(Y)：0, 175
年収(Z)：0, 600（万）
（ここでは説明を割愛しますが、問題において明示的ではない境界が存在することにも注意が必要です。この場合は0未満、すなわち負の整数は無効同値クラスとなります。また、身長の場合は0ということが有り得ないので0以下が無効同値クラスとなります）
この時のONポイントの定義には、以上や未満といった等号不等号の定義は関連しません。ドメインの内部か外部かはこの段階では意識せず、あくまでONポイントは仕様上、指定されている境界値になります。
そしてOFFポイントを考えるときに初めて、「このONポイントは境界のどちら側にある値か？」ということを考えます。上の例で言うなら、OFFポイントは以下のようになります。
OFFポイント
年齢(X)：-1, 19, 29
身長(Y)：1, 174
年収(Z)：-1, 599（万）
OFFポイントが、ONポイントに最も近い値かつ、境界を挟んで向こう側の値であることが理解できますでしょうか。
というのも、ドメイン分析はあくまで「変数が複数ある場合の境界値分析」なのですから、OFFポイントにはONポイントから見て境界を挟んだ向こう側、かつ境界と隣接している値を選択する必要があるのです。
ドメイン分析は同値分割や境界値分析に比べ意義が理解しづらいように思えるのですが、私が思うドメイン分析の価値は以下のものです。
- 複数の変数を扱うときに、有効な値のテストをする
- 複数の変数を扱うときに、不必要な値のテストを省く
ドメイン分析では一体どんなバグを摘出しようとしているの？と思いますが、グラフで考えるとわかりやすいです。先に挙げた例を出して説明してみます。
三次元をグラフで書くと結構わかりづらいですね…
ドメイン分析は複数の変数を用いた境界値分析ですから、まずは基本的に境界値分析の考え方を実践することになります。ただ、そこで効率よくテストケースを生成していくためにドメイン分析の考え方、ONとOFFとINを使っていきます。ONとOFFを調べるのはまさに、境界を調べるのに必要だからですが、IN値はどう選べばよいのでしょうか？
これはその名の通り、そのドメインに「含まれる」値を選ぶわけです。先の例で言えばこのようになります。
INポイント
年齢(X)：25
身長(Y)：180
年収(Z)：800（万）
要するに、一つの境界を調べている時にもう一つの境界も一緒に調べようとするのがよくない、と言っているわけです。なぜなら、そこでバグが出た時に「どっちの境界にバグがあるのか？」がわからなくなってしまう。結局、分けてテストする羽目になってしまうのです。なので、あくまでXの境界、ONとOFFを入力して調べている時は、他の変数であるYとZは結果に影響しないドメイン内の値を入れて、境界を一つずつ調べていくと良いというわけです。
ドメイン分析の具体的な流れは以下のように説明されました。
- 同値クラス、境界値を見つける
- グラフにしてみる
- ONポイント、OFFポイントを探す
- 組み合わせる（今回の演習ではBinderのマトリクスを用いました）
とてもわかりやすい説明で、自分ではこんなにキレイに整理して説明できないなーと思いました…
ちなみに先の問題の答えはこちら。ちょっと写真見づらいかもしれません。
お時間ありましたらやってみてください。 （身長0の人間とか、年収800万の0歳児とか、考えると恐ろしいですね…!）
TPI NEXTで自分たちのテストを評価しよう
30分と短い時間ですが、TPI NEXTに関するセッション。こちらも気になっていました。 今回のWACATEは非常に俺得でしたね！
しかしさすがにこのセッションはTPI NEXTの概要説明と体験ワーク合わせて30分ですから、扱われたものは非常に一部でした。特にクラスタの考え方なんかはTPI NEXTのとても良い点だと思うので、読んだことのない方はぜひクラスタの紹介をしているページだけでも読んでほしいと思います。
TPI NEXTには初期レベルからコントロールレベル、効率化レベル、最適化レベルと段階が定義されており、徐々に達成難易度も上がっていくのですが
今回周りの方々には効率化レベルや最適化レベルの人が思ったよりたくさんいて、とても驚きました。みんな進んでるんだなあ。確かに某DJプログラマに、「BTSとVCSが連携してないなんて石器時代だ」って言われたしな…
でも実際やってみて思ったのは、「そもそもチェックポイントの読み解きが難しい」という点。読み解きが難しいということは、つまりそれだけ人によってばらつきが出てしまうということで、同じプロジェクトのチームメンバが各々実施したアセスメントの結果なのに、ばらつきが出てしまうことになります。こんなことを少し感じたのですが、これについては後述する分科会でも触れることになります。
ディナーセッション
後夜祭の出欠確認とか宣伝とかしてたらいつの間にか終わってしまった感がとてもあるのですが、最初の方に隣り合った方とテスト自動化の話をちょろっとしました。
なんでも、「テスト自動化において、システムテストレベルとか、ブラックボックスなレベルに縛られてしまうと自動化の幅がなかなか広がらない。うまく自動化をやろうと思ったら、やっぱりコードは読めた方がいいし、そういうホワイトボックス的なレベルから検討できた方がやりやすい」というお話がありました。概念的にはなんとなく同意なんですが、そうは言ってもなかなかコードを読めてテストもやれる人っていっぱいいるわけでもないのですよね。かくいう自分もあんまコード読めません。確かにコードを読めて内部の動きとかわかっていた方が、テスト自動化するにしてもやりやすいだろうなというのは思います。結局、コードを隠蔽された状態で目に見えるところだけ自動化しようと言ってもそれは限界があるのですよね。何が言いたいかというと、そろそろテスト自動化とかコードに近いレベルの勉強もしなきゃあかんなと思いました。
夜の分科会「テストプロセス改善について」
個人的な感想ですが、前回のWACATEで自分がオーナーをやった「テスト観点について」よりは収拾のつく議論になったのではないかと思っています。
ものすごく発散したようで、実際の話題の推移は実にもっともというか、順当な話題の移り変わりであったように思います。ひとまず流れに沿って、議論の内容を書いてみます。
初めに話題提供ということで簡単なスライドを用意しておきました。
この場に来た理由
はじめに、集まった方々の課題にどういったものがあるのかをお聞きしてみました。皆さまが抱えている課題は本当に様々でした。
- 改善の効果がわからない
- テスト実行の管理はできているが、設計や計画がうまくできていない
- 無駄なテストが多いように感じる
- 会社の標準と現場の実態に乖離を感じる。使いたい時に使えるものがあるといい
- プロセスのベースはあるけど、いざテスト実行となるとなかなかうまく進まない
- 新しいことをやるのに強い抵抗、障害がある
- CMMIなど、採用している標準がテストの評価に特化していない
- テストを長くやっているベテランでも、思いつきで作業していたりする
- オフショアをどう進めていくか
- 仕事が人依存になっている。属人化しない仕組みを作りたい
- どのレベルまで成熟したプロセスを求めるかはプロジェクトによって異なってくるが、その度合いをどうコントロールすべきか悩んでいる
- こういった勉強会に担当レベルの人が興味を持ってくれない
などなど。
そこで、「テストプロセス改善をちょっとでもやってみたことがある（アセスメントをしてみたとかでもOK）人がいるか聞いてみました。すると「やったことがある」という方がちらほら。
TPI NEXTのアセスメントは思ったより難しい
TPI NEXTのアセスメントをやってみた、という方にお話を聞いてみると、「思ったよりうまくいかない」「現場に近いとあるが、トップダウン的側面もあると感じた」とのこと。
一つずつ解説しますと、まず「思ったよりうまくいかない」というのは、チェックポイントを読んでのアセスメントはそもそも解釈から難しく、そこで各人による差が生じます。さらに、「どこに力を入れたいと思っている」といった個人の意図が反映されるおそれがあります。例えば、テスト報告に課題を感じている方は「報告」のキーエリアを厳しめに採点するということも考えられるでしょう。なので実際にやる場合は、あくまで第三者にヒアリングされる形をとるとか、主観的な評価にならないよう注意が必要なのではないかとのこと。
また、「トップダウン的側面がある」というのは、あくまでTPI NEXTが「ビジネス主導」であることに起因しています。プロジェクトに対するビジネスニーズというのは特に上長が気にかけていることが多く、そうなるとどうしてもトップダウン的側面が否めないとのこと。なんとなく納得できるような気がします。
と、ここで「そもそもプロセス改善のプロセスってなによ？」という疑問が呈されます。
プロセスってなによ？
僕は初めのスライドで述べたように、アドホックなプロセスと構造化されたプロセスがあることを述べました。そこで、
アドホック：その場限りのテストケース設計
構造化された：設計思想を引き継いだテストケース設計
といった例が挙げられました。（ここでの話はあくまでプロセス改善であり、成果物改善ではないことに留意が必要です）
普段どんなテストをしてる？と聞かれた時、同じチームでも各人でやり方が異なっていることがあります。また、よく一般的に言われるようなことをとりあえずやってみよう、としてもなかなかうまく進みません。それこそ現場の抵抗もあります。チーム内のプロセスの話なのか、それとも全社的なプロセスの話をしているのかでも話は変わってきます。
ここで話をテストプロセス改善に戻します。テストプロセス改善において勘所はどこでしょうか？
テストプロセス改善における勘所
ポイントの一つとして、「まず、一つ変えてやってみる。そこで、『よくなった』と思わせることが大事」という意見がありました。これは抵抗を受けないようにするために非常に大切です。というのも、一度やってみてダメだと「前やってダメだったじゃん！」とより強い抵抗を受けるようになってしまうからです。なので慎重に一つだけ試してみて、確実な成果を上げることが重要になります。簡単なのは自分一人で完結するプロセスで試してみることです。それならば、たとえ失敗したとしても負担を負うのは自分だけになります。
また、「時間がない」と断られる場合は仲間を見つけることが大事です。できるだけ周りを巻き込むこと。上層部を巻き込めればなおよし。結局コスト面を握っているのも上層部であることが多いためです。
チーム内のプロセスと全社的なプロセスの橋渡しをするのも良いのではないかと言われました。例えばプロジェクト計画書のレビューなど何かしらの機会に、双方のプロセスに理解を示してくれる人が参加し、アダプタとして関わると非常に良い効果が得られるようです。
プロセスの標準化について
標準化というと拒絶反応を示されることもありますが、それはプロセスがあらゆるケースに当てはまるかと言われると、そうではないから。というのもあります。しかしそもそも標準化というのは「チームでの良いプロセスを共有しよう」という場があり、そこから展開されていくものです。良いプロセスの共有の場は、決して悪いものではありません。ただ、それを大きいプロジェクトから小さいプロジェクトまで当てはめようとすると無理が生じてきてしまいます。標準化、テーラリングは大変難しいのです。
また、標準化の目的が本来とずれてきて、「認証のための標準化」となってしまうともう不幸です。どんどん現場が締め付けられて、仕事が全然楽にならない重たいプロセスを押し付けられてしまうこともあります…
あくまでプロセス改善の主役は現場であるべきでしょう。
現場主導って言うけど…
ここで反論が出ます。現場現場って言うけど、結局はビジネス、お金のためにやっているのだからビジネス目標は無視できないのではないか。いかにコスト削減とか、見える成果に結びつけていくかを考えなくてはいけない。なるほど確かに、これはこれで正しい気がします。
属人化と標準化
その人単独に結びついたプロセス。その人がやれば上手く行くけど、他の人が真似しても上手くいかない。どうやって標準化したらいいか？という話題です。
ここでは下手に標準化しない方がかえって良いのではないかという意見が出ました。その人のプロセスが形になっているのなら、まずはそれをきちんと伝えるのが良い、と。無理に標準化しようとするとかえってダメプロセスになってしまう危険性もあります。
プロセスとスキルセット
プロセス、プロセスっていうけれど、その前提となるスキルセットってきちんと考えられていますか？という問題提起がありました。確かに、前提となるスキルがなければ良いプロセスであっても活用しきれないことが考えられます。どんな人が求められるか、明確に定義し落とし込んでいくことも同時に必要とされるのではないか、と。
日本式と欧米式
日本式と欧米式では、プロセスに対する考え方、立場が違います。日本式では書いていないことであっても気をきかせたり、考えたりしますが、欧米式では書いていること、きちんと明確に定義されたことだけをやる。ここに違いがあります。
しかし、日本式においてはスキルセットで評価しきれない部分があるのではないでしょうか。例えば、絶対的にポジティブなムードを作り出す人。チームビルディングに必要不可欠な人。これらの人は欧米式では評価に値しないかもしれません。ですが、こういった日本的な文化、コミュニケーションから始めるプロセス改善も有効なのではないでしょうか。
以上、非常に発展し幅広い議論となりました。何か一つでも気づきを持ち帰っていただけていたら幸いです。
深夜の分科会「テストエンジニアのキャリアパス」
深夜の分科会にて、「テストエンジニアのキャリアパスって？テストエンジニアのキャリアにおける成功ってなんだろう？」という話題提起がありました。
なるほどたしかに。テストエンジニアのキャリアパスは、Test.SSFといったフレームはありますが、まだディベロッパーに比べ整備されていないように思えます。 また、この話題提起の裏には「日本ではテストエンジニアが正当な（？）評価を得られていない」という実感もあるようです。
実務に基づく専門知識を活かして大学教授になることが成功？コンサル業にうつってお金を稼ぐのが成功？と成功の定義とは何かから議論をしました。
以下、私の持論です。参考までに。
自分も、テストエンジニアのキャリアパスについて悩んだ時期がありました。まさにこれ発表した時期です。
この時自分は入社２年目なんですが、ああなんて恥ずかしい。けど本当に悩んでいました。
でも今になって思うのは、「目の前のことすらちゃんとやってねぇくせに、未来のことうだうだ語ってんじゃねえよ」ということです。本当に、過去の自分に言いたい。
これは「嫌われる勇気」という本を読んだ影響も大きいのですが、未来を変えたいならばそれは「今ここ」から変えるべきなのであって、それこそ変えようのない過去や未来に執着しても仕方ないです。
先の議論で「日本ではテストエンジニアの地位が認められていない」というものがありましたが、これも、自分が特にやりがちなのですが、対応の不遇さを環境のせいにしてしまいがちです。「自分が評価を得られないのは、日本にいるから、いまの会社にいるからだ。日本や会社の制度、しくみ、文化が悪いんだ」と。免罪符を貼ってしまうわけです。
これは言ってしまえばただの言い訳でしかありません。しかし、海外に出て、会社を変え、文化が変わった時、それでも出世もできないし評価もされなかったとしたら、その時どう感じるでしょうか？
つまり、おそれているわけです。こわいんです。自分の力の無さを突きつけられるのが。だから「海外でテストエンジニアになれば、俺だって評価される」とか「違う会社なら俺は成長できる」って考える。そうしたらラクですよね。自分の力の無さを認めずに済みますから。
極論を言っているように思いますか。でも現実だと思います。正当なやり方で正当な努力をして正当な成果を出している人は、いつだってそれなりの評価を得ます。自分が思うように評価されていないと思うのは、それをしていないからです。やり方が違うか、努力していないか、成果につながっていないか。ただそれだけであって、日本とか会社のせいにしてはいけないと思います。
本当に改善のしようがない職場があること。改善すればするほど苦しくなる職場があること。一方でこれも事実としてあります。 ですが、そこから変わりたいんだったら、少なくともこれまで通りのやり方ではだめです。だめだった。変えたい。だったら、何かを変えないといけないはずです。
こないだ勉強カフェで知り合った方に教えてもらったこの本にも、「今日一日で、人生おわり。それでも今日みたいな過ごし方をするの？」と書かれていました。
未来のことなんて、結局のところ考えたってわかりようがないですよ。ただなんとなく薄ぼんやり見えるような気がしてるだけです。それよりもっと大事なのは、仕事をどうやったらもっとうまく回せるか考える。役立ちそうな本を一冊でも買って、読む。BUMP OF CHICKENの歌詞っぽく言うと、「未来を変えるのはいつだって、ひとつひとつのイマの積み重ねなんだ。」（こんなこと言ってたかわかんないけど。）
ちょっと読んでいて不快に感じられる方もいらっしゃるかもしれませんので、補足しますと
私自身、まだ全然、「いまに集中」できてません。上の文章は自戒的に、自分に向けて書いています。将来のことを考えるのも、もちろん時には必要です。でも、そのために今に集中できなくなってしまうのは、何か違うんじゃないかなと思います。
英語なんてこわくない～英語ドキュメントを読んでみよう
高校とか大学の時はもう少し英語アレルギーはなかったかなと思うのですが、今となってはなかなかハードルの高さを感じてしまいます…
そこで、このセッションで英語に触れられたのはとても良かったです。
このセッションでは、短い時間ながら「いかにして、知識の少ない状態で英語の文章を読み進めるか？」というところに焦点をあてています。なので最初から読める方にとってはすでに知っている内容もあったかもしれません。
英語の文章を読むにあたって重要なポイントは、以下のものです。
- 述語動詞を見つける
- 主語を見つける
- 前置詞を見つけて、後の文章を囲む
全然わからないなーって思っても、まずは最初に出てきた動詞をマーク！次に、最初に出てきた名詞（主語）をマークします。そして、前置詞を見つけたら後の文章を括弧で囲ってしまうわけです。
こんな感じだと思っていますが、間違っていたらすみません…
上の例で言えば、述語動詞と主語さえ押さえてしまえば「Testing everything はfeasibleではない」ってな感じで、なんとなくは読めてしまいます。もちろん辞書を引く必要はありますが。
でもこういった、名詞や動詞、前置詞に着目して読むというやり方は学生時代こそ長文の英語も読むのでこういったテクニックもよく使いますが、社会人になって英語から一度離れてしまうと、せっかく覚えた英文の読み方を忘れてしまいますよね。それで愚直に読もうとして、「わからない。英語は苦手だから読めないんだ」という風になってしまうわけです。でもこういったテクニックを知っているのと知らないのでは、英語に対するハードルの高さが全然違うと思います！短い時間でしたが、とても良いセッションでした。
60分でわかった気になるISO29119
やはり29119はボリュームがとても大きいですね。それこそ本セッションでは、概要レベルの理解はできたものの本質的なレベルまでは到底理解しきれていないなと感じています。まずは英語を克服して原文を読んでいく必要があるのでそこからなわけですが…どうしても英語は避けて通れないなと実感しました。
特に印象に残ったのは「テストポリシー」の話です。テストポリシーとは、その会社、組織にとってテストとは何なのか、です。それこそテスト計画を立てない組織は珍しい（のではないか）と思うのですが、「まずはテストポリシーを決めよう！」ということってあまりないような気がします。しかし、テストポリシーって実はソフトウェアテストにおける根元の部分で、かなり重要なことだと思います。暗黙的に「テストってこういうのを確認する作業だよね」とアンドをとっておけばうまくいくとは思うのですが、これが認識違いとかあったら大変だと思います。テストで全部やろうとしたり、テストでやるべきところを見逃したりします。テストでやるべきことは何かというのは組織やドメイン、プロダクトによっても異なってくるので、テストポリシー的な部分でチームメンバ間の認識があっているかどうかは注意しておく必要があると思いました。
しかし、けっこう規格を読んでいくってハードルが高いと思っているのですが、そうでもないのでしょうか。SQuBOKは読めても規格はなかなか読めない気がするのですが…買おうと思っても結構なお値段ですし。勉強されている方がいましたらコツを聞いてみたいです。
探索的テストはじめの一歩
これは、実際に探索的テストを演習で試すことができたのがとても良かったです。
これまで私は、探索的テストは「スキルのあるベテラン」にしかできないものだと思っていました。ですが、今では「ちょっとやってみるのもアリかもな」と思っています。
というのも、そもそも探索的テスト自体やってみるととても楽しいのですよね。ここか！ちがった！こっちか！アタリだ！というように、楽しみながらテストができます。実際やってみるととても楽しいです。
探索的テストはテストをしながらテスト対象について「学習」し、狙いを定めてテストを進めていきます。なので、「テスト実施しながら設計・分析しなきゃいけないなんて、ベテランじゃなきゃ無理やろ！」と思っていました。
ですが実際にやってみて、セッションでも言われていたことですが「ベテランになるまでは探索的テストはできない」とまで思わなくてもいいのではないか、と思いました。結局、知識や経験が求められるのは探索的テストであれスクリプトテストであれ同様に言えることではあります。なので、「探索的テストでカバーする範囲」を明確にした上で、「スクリプトテストを補完する意味合いで利用する」のであれば、積極的に使っていくのもアリかなと思いました。また、演習でも用いた「チャータ」「ロギング」も重要です。探索的テストであってもしっかりテスト実施の記録を取ること。また、作成したチャータを元に、どのあたりを狙っていくかなどチーム内で事前に方向性を共有しておくこと。これで、探索的テストの進めやすさも変わってくる印象がありました。
質問されない資料にするための4ステップ
今回のWACATEでもっとも難しいセッションだったと思います。
本質を突く「質問」とは何か、考えさせられました。
例えば、演習中に言われたのが「どうして数ある中から、それを選んだの？」というものでした。すると意外と答えられません。結局、「なんとなくこっちだと思ったから」などと答えてしまいました。というのも、知らないうちにロジカルから離れた、エモーショナルな考えに沿って発言していたのです。感情先行で話をすると、そこにはロジックが抜けてしまいがちです。自分ではそんな自覚はなかったので、とても驚きました。
ポイントは、できるだけ本質的な答えを引き出すための質問をすること、それをできるだけシンプルな、少ない質問で構成することだと感じました。
セッション内で紹介された４つの質問がこちらです。
- その文章はその場に居る全員が同じ意味として認識できるだろうか？
- その文章は如何なる場合に於いても成り立つだろうか？
- その文章はある仮定の基に因果関係を構築していないか？
- その文章は他に条件がなくても常に成り立つか？
正直、この４つを聞いた時は「そんなんいちいち考えてられるか！」って思いました。しかし、実際にこの４つの質問を元に文章を補強していくと、確かになかなか曖昧さが減った文章になっていきます。
具体的な例を挙げると、こんな感じです。
とあるWebアプリケーションを想定したとして、「新しいメールアドレスを入力すると、新規登録になる」という仕様があったとします。
これだけ聞くと「なるほど」と思ってしまいがちですが、これには先の４つの質問を元にして様々なツッコミができます。
- 「新しい」で伝わる？「DBに未登録のメールアドレス」ってことだよね？（１）
- ネットワークに接続されているっていう前提だよね？（２、３）
- 他にも、「利用可能ブラウザを使っていること」っていう条件が必要だよね？（４）
という感じで補強していくと、確かにそこそこ一意に受け取られそうな文章に改善されていきます。細かい質問と思われるかもしれませんが、こういった観点で文章をチェックすると効果が出そうだなと思いました。
しかし、本当に質問というのは難しいです。ある程度の抽象度がないと汎用的な質問になりませんし、かといって抽象的すぎても伝わりません。例えば「どうしてこの仕様にしたの？」とかは良い感じの質問かなと思いました。質問というのは単純な一問一答ではなくて、その人に気づきを与えたりとか考えさせたりといった意図でも使われます。「質問の仕方」でビジネス本もたくさん出ていますね。レビューの時にも、「効果的な質問」をすることを意識していきたいと思いました。
ソフトウェアテストの最新動向の学び方
辰巳さんによる、ソフトウエアテストの最新動向の学び方です。 （上記スライドは、その中で紹介されていたソフトウェアテスト年表です）ソフトウェアテストの歴史についても多く語っていただき、とても興味深かったです。デシジョンテーブルのように昔からある技法から、最近の技法まで紹介していただき、結構知らないことも多いなと再認識しました。これからは顧客エクスペリエンスを含めたモダンな品質保証、さらにはグローバルな情報収集が必要になってくるなーということをひしひしと感じたセッションでした。
ちなみに、辰巳さんには最後にSQuBOKにサインをもらっちゃいました！！「次は著者側になれるといいね」と激励の言葉をいただきました！最高です！
クロージング
クロージングでは、ポジションペーパーの授賞式が行われました。
そして、私は今回も見事に一つもかすりませんでした！
私の疑問:
マジでどうやったらBPP（ベストポジションペーパー賞）を取れるの？
誰か教えてほしい。（切実）
過去受賞された方には「狙ったら取れないよ」と言われましたが、
狙ってるもんは仕方ないじゃないですか！
そんなわけで次回こそ、次回こそBPPとります。すでにネタは考え始めているので…（早い）
でも確かに、今回受賞された作品は魂こもってる感ありましたし、ストーリーがあり熱さがありました。次回は改善して持っていきます！！
後夜祭
今回はラッキーなことに実行委員の方と後夜祭でご一緒することができました。夏に何がやりたい？との問いには
「レビューやりたい」
と答えました。
＞これをお読みいただいている実行委員のみなさま
最近の悩みはレビューなので、もしよければご検討いただけると幸いです。テーマがレビューだったら、ウサインボルトも驚愕のスーパースタートダッシュで申し込みます。いえ、もちろんテーマがレビューでなくても多分申し込むと思いますが。いつも運営ありがとうございます。今後とも勉強させていただきます。
その他感想など
今回のWACATEは非常に天気も良く、すがすがしい気持ちでテストについて語りつくせました。後夜祭でドメイン分析のグラフを書いたのは、今回が初めてではないかと推察します。（これ書いたのは僕じゃないですよ！）
また、次回からはついに名札が「常連カラー」（参加５回目）になります。半年後までに自分がどれだけ力をつけられているか。さすがに半年前よりはかなりの力がついた実感がありますが、いかんせんまだドメイン分析を理解できていなかったりと力が不足してるところがあります。着実に一歩ずつ、目の前のことをがんばっていきます。まずは2月の語る会かな… あとはこのWACATEの参加報告。
語る会の詳細はこちら↓
【宣伝】若手エンジニア ソフトウェア技術を語る会2016 - mhlyc -presentation
力がつくというのは不思議なもので、以前は無理だと思っていた「技術書を100冊読む」とか「SQuBOKを通しで全部読む」といったことが不可能ではないことがわかってきます。これはとても面白いことです。いまご活躍されている皆様も、同じ道を通っていったのかなと思っています。
僕が好きなアーティストであるJAM Projectの曲で、こんな歌詞があります。
HERO どんなに強い奴も ちっぽけなガキだったんだ*2
いま強い人を見ると、その人が弱かった時代なんて想像もつかないですよね。でも、実際そうなんだろうなと最近は思います。 自分も頑張ればいくらだってやれると思います。まだ（ギリギリ）24歳だし。
今回もWACATEを通して本当にたくさんのことを学びました。改めて実行委員の方には感謝します。ありがとうございました。
参考にした記事
勝手に参考にさせていただきました。ありがとうございます。
にしわきはるなさんの記事。ご本人は謙遜されていますが、色々な勉強会に積極的に参加したり発表したりされている方です。
各種勉強会でおなじみのブロッコリーさん。夏に引き続き、WACATE2015冬のTogetterまとめを作ってくださいました。また勉強会に行く頻度もとても多く、勉強会に行かない日の方が少ないのではないかと個人的には思っています。色々な勉強会のレポートをあげてくれるのでとても勉強になります。
また、他の人の感想を見るのは面白いですね。印象に残る部分というのは個人個人でとても異なるので、そういう見方もあるのか！と感じます。あとは、資料を見ながらまとめてみて改めて理解できる部分もあります。レポートは誰のためでもなく、自分のために書くべきだなと思いました。
