ブログっぽいことを初めて書きますが、来週（2017/02/03）JaSST東京の前ににテスト分析とテスト設計についてのLT大会が開催されます。

ということで、当日話すスライドを作成しました。

他の人がゆもつよメソッドについて解説してくれているものがあったので事前に読み返せるように貼り付けておきます。これらを読んで予習しとかないと！

WCATE2015に参加してくれた藤沢さんのスライド

WACATE2014に朱峰さんがセッションとして発表した時のスライド

2020/5/5追記）みっきーさんが語る夕べの原稿を起こしてくれたnote。すごく良くまとまっているので追記しておきました。

2021/6/5追記）語る夕べでゆもつよメソッド取り上げられたときの記事メモをに書いてくれているQita。これもよくまとまってるし、議事も書かれてて興味深い。

この話、もともとなんで始まったんだろうかというとTwitter上での藤沢さんの疑問から始まった一連のやりとりです。これも事前に読み返しておくといいね！

で、テスト分析とテスト設計を分けたほうがよいかどうかですが、私のスライドにも書きましたが、作業として分けるとメリットがあるだろうということです。ここに暗に隠れている「言いたいこと」は、実際は両者を分けてないことが多いし、そもそも分けて考えるといったことを知らない人も多いということです。エンジニアとして本来できるようになるべきだけど、それを学んだり訓練したりする機会がないんですね。

一言で言うと分析は「理解する」こと、設計は「工夫する」ことですが、実はそれらを分けて考えることが難しいのです。（これに対する反論もありましたが）

だって、いろいろ思いついちゃうから。そこで更に分けて考えることを知らないと、それは更に面倒なのです。なのに現場で単に「分析と設計を分けましょう」とか言いだしたら、きっとそいつは「めんどくさい」やつです。

まぁ、いろいろ思いついちゃうのを止めるわけにはいきませんが、大事なことは、２つは成果物の観点がことなるということです。「理解している」ことは、みんなが共通の理解になることが必要で、自分独自の考えが入っちゃいけないです。一方「工夫する」ことは自分の独自の考えが入るべきです。それは他の人と違って良いのです。ただ、なぜそうかは納得できる理由が必要だということです。（これは過去に先輩に教えてもらいました）

そして、工夫するためは正しい理解が必要です。良い設計には、その前にちゃんとした分析があります。対象を正しく理解するのが難しくなってくるほど、分析が注目されるわけです。

いろいろ思いついちゃってもよいし、同時並行にやってもよいし、両方をいったりきたりしてもよいですが、正しい理解をすることと、自分なりの考えを主張することは分けるべきだっていうのが私から話すことになります。

ついでに言っておくと、実際はテスト設計を明示的にしていないことが多いです。設計するまでもないってこともたくさんあるわけです。私が若い頃いた現場では、テストケースを作るときに仕様理解をする時間とテストケース作成をする時間って感じでタスクを分けていて、設計と呼ぶ作業はありませんでした。それは呼び名が正しくて、実際、自分なんかは、設計と呼べるようなことが必要なときは（いわゆるデシジョンテーブルとか境界値とか考えるのは）、テスト実行時にその場で考えていました。

テスターが実行するときにその場で考えるっていうのも、今では良いことだとはちっとも思っていません。もっと組織としてのテストの能力を上げるには、実行前に設計したほうがよいし、どんな設計をしているかをレビューするとか共有するとかが必要です。けど、いきなりそれをやろうとすると上手く行かない。

なので、現場でテスト分析と設計をちゃんとできるようにするには、段階が必要だと思います。その段階を設計する（テスト設計ではなく改善の設計ですね）のは、また現場の状況の理解と、それをよくしていくためのアイデアをだして実際の作業に落としていくことになります。

そう考えると何事も一緒なんだなーって思ってもらえたらいいな。