忘れていましたが、このブログは私のチラシの裏的な書き殴りの何かでした。
■はじめに
「テスト設計がうまくできないのでテスト設計を学びたい」
「テスト設計ができない」
「テスト設計できるか」
この辺りの言葉って私もよく使うし周りでも（どこ、？）よく聞くのですが
では「テスト設計ができる」とは何なのだろうと。
…つい最近どこかで読んだような気もするし、前もどこかで書いたようにも思えます。
このような文脈で「テスト設計」が話に出る場合、大体の場合は
「テスト設計のプロセス全般」を指していると思います。
おそらく「要求分析」「分析」「設計」「実装」の設計だけできない
という意味で使う人はいないかと。
（いたらすみません）
■テスト設計は何か？について書かれている記事
「つい最近読んだ」を思い出したので貼り付けておきます。（記載内容と話が被るのを防止するため）
テスト設計って結局何なのさ？｜156
この記事を読む限り、156さんの経歴は私に非常に近いです（私も実行者から入っていて第三者検証）
私もよく「実行者が分かりやすいように設計をすること」で考えます。
■テスト実装：細かく書くか、ふんわり書くか
これは、ALTMかALTAかFLの（おいおい）具体的テストケースと抽象的テストケース（こんな名前だったっけ？）の話です。
テスト実行する環境に合わせてテストの粒度を調整する。
例えば、テストを実行する人が開発を行っているところから物理的・組織的に離れている（第三者検証に出す場合など）や
後で組織の人間が入れ替わったときにテストケースを流用（過去の不具合情報を利用する場合など）は
具体的に書くことが必要になります。
逆にテスト実行する人がチーム内にいる場合やすぐフォローできる場合
また、ドメインに詳しい場合は「ざっくり書く」方が良いです。
これは、細かく記載しないことによるテスト作成工数の短縮や、他の場所も広げて確認できるメリットの方が大きくなるからです。
この「細かく具体的に書くかざっくり書くか」は
・JSTQBやIVECの資料で知識を身に着ける
・現場でテストの粒度をどう書いたかで得られる経験（あまりにもテストが進まない、逆にテストを細かく書きすぎて作成に時間かかる、メンテナンス工数がかかる）
これらの複合で徐々に身についていくと思います。
■テスト設計（暗に分析）ができない
ここまでの「テスト設計ができない」の話は、テストを実行可能な状態にするためにどう書くか。
すなわち「実装」の話です。
余談ですが「技法うまく使えない」は「設計」の話だと思います。
話を戻します。
私が「テスト設計できない」と言うときに意味しているのは「分析」の話です。
・テスト対象はどういうことをできることが求められているか
・どういうことが起きてほしくないかを求められているか
・その要求に対してどのような切り口でテストを構築するべきか
・テスト対象をどのような機能単位でグルーピングして考えるか
・どの実装単位でグルーピングして考えるか
私が「テスト設計できない」というときはこの構造化について話しています。
■余談：一般的に「テスト設計ができるようになりたい」は何を指すか
他の方から私が「テスト設計できるようになるには」を話されているときは
上記のように分析に限定せず「分析～設計～実装」を複合して話されていることが多いと思います。
「自動化したい」もしかり「～したい」「～できるようになりたい」の話である間は
その中の細かいプロセスには分割されておらず、それを実現しようという段階になって
初めて細かく考えるのかもしれません。
■どうすれば「テスト設計」ができるようになるか
テスト分析の部分をできるようになるには、自分に関して言えば
「パターンを学ぶ」「思考の障壁を取り除く」この2点です。
分析手法をうまく使うことができず尻込みしてしまうのが一番の障壁になっているように思えるので
その心の障壁を減らしていき、パターンを地道に積み上げるしかないかと。
先日のVSTEPの勉強会しかり、その他過去の記憶（おいおい、、）しかり
地道に分析の手法を学んでいくしかないようにも思えます。
あるパターンを過信して「これで考えればもう全部考えた！大丈夫！」になるのは良くないかもしれませんが
それはパターン思いつくようになった段階の後の話であり、最低限、良く思いつきうるパターン
（例えば品質特性。テストレベルやテストタイプで割ることもパターンの一つですよね）を
さっと思いつくようになるくらいになるところが第一歩の一歩の一歩かなあと…
はあ…
■他人に「テスト設計」を教えるにはどうすれば良いか
「分析」「設計」「実装」に分けてまず考えます。
分析は、テスト対象を機能対象で割り、テストする観点で割り、テストするタイプで割り…
など。テスト計画や戦略も考慮しながら。
（自分ができないので書き方も曖昧になります）
設計は、分析した対象に対してどのような設計技法を使ったら良いか。
組み合わせを使用するべき場面や状態遷移図を使うべき場面、
状態遷移の先で組み合わせを使っても良いなど。
実装は、書き方の粒度とか、環境・前提条件なども書くなど。
より実施しやすい、観測しやすいようにすることの重要性など。
テストを作ることは、自分の中では暗黙知の塊になっている気がします。
先人が整頓した資料をたくさん残してくれているのだから、それにインデックスをつけて最大限活用せねば…
と日々思いつつだらだらと生きています。
