テスト作るのって何に時間かかっているんだっけ？

この記事は「書きたかった一人アドベントカレンダー、リキッドルームに」16日目の記事です。

テスト実行はともかくとして、テストを作るときに「（；＾ω＾）うわ…一週間溶けたわ」となることはありませんか？
私は日常茶飯事です。

テスト作りの何に時間がかかるか？思いつくことを羅列していきます。

テスト対象理解

テスト対象について詳しい状況で始まるならともかく、自分のような流れの派遣テスターの場合は大体詳しい状況では始まりません。
まずはテスト対象の振る舞いについて理解を深めるところから始めます。
でも一番理解が深まるのは大体テストを作り出そうとして入り込む段階です。

テストベースの旅2021

プロダクトをテストするからにはそのテストの元となる仕様書などがあります。仕様書がないこともたまにあります。
とはいえ、基準が必要なので、その基準を探しにいきます。
それは人へ聞くことだったり、前回機種の仕様書だったり…大体長い旅になります。あとは仕様書の不明点を解決するのも結構時間かかります。

果てしないテスト分析

ここは分析する観点を沢山持てば持つほど時間がかかります。
内部構造と仕様、両者の抑えたいポイントから確認するのはもちろんとして、他にも色々な見方がありますよね・・
広げた後まとめるのも結構時間がかかります。この階層構造でいいんだっけ？と立ち止まることもしばしば。

意外と時間かかるぞ詳細化

分析終わった→まとめた→具体的に書くぞ
この具体的に書く段階で詳細に書くことそのものに時間がかかります。
パターンができてくるとそうでもないのですが、
頭の中で「ここは明記して見落とさないようにするか、それとも明記しなくてもよいか」を組み立てたり、テストを実施する人を思い浮かべながら詳細化するかを考えている時、つまり詳細度を決めているときそのものに時間がかかっています。

それぞれについて（時間がかかることを）解決する方法を考えてみる

テスト対象理解
解決方法：思いつかない（予備知識を身に着ける？）
ここに時間がかかるのはひとつのプロダクトにずっと携わるわけではない以上、ある意味仕方ないとも言えます。
ここを縮める人っているのでしょうか・・その方が怖いような
（例えばテスト実施でまったくプロダクトの学習期間を入れずに投入とかあったら怖いと自分は思います）
ここを縮めるにはどちらかというと依頼側がカバーする（テスト対象についてのチュートリアルを作る）くらいしか思いつきません。
それも時間がかかるので、覚える側がその時間を使うか依頼側が使うかどちらかでしかないように思えます。

テストベース探し
解決方法：資料整頓
ここはテストベースについて資料が整頓されていれば改善出来る気がします。資料のトレーサビリティがいけてるとか。
なのでプロダクトに恒久的に関わる立場であれば、テストベースになりうる資料（仕様書等）の整頓を常にしていくが解決方法になるのだと思います。
資料を管理する側とテストを作る側が異なっていて、テスト作る側からここを短縮できる手段があるとすれば、テストベースの探し方をパターン化しておくくらいですかね。（ドキュメントがなければコード見たり開発からヒアリングしたりとか）これもあまりいい方法が思いつきません。

果てしないテスト分析
解決方法：スコープ明確化、まとめ方のパターンを持つ
スコープ明確化：どこまで見る、ここは見ない。の線引きを明確にする。
細かく見れば見るほど時間はかかるのは間違いないので、時間と相談した上で見る範囲をプロジェクトをまとめる側と合意する（特に「見ない」範囲）合意してから分析を始める。分析を始めた段階で想定より時間がかかる場合も同様の相談をする。
まとめ方のパターンを持つ：ここは自分が学習していく＆経験していくで一番なんとかなる個所だと思います。いわゆる技法なりモデル化なりが適用出来る箇所。→学習していく、が解決方法（同時に経験を積むことも）

詳細化で時間かかる
解決方法：テスト実行の環境明確化
テスト実行をどのような形で行うか（近くにいる人、遠くにいる人、プロダクトに詳しい人、プロダクトを初めて触る人）で詳細化の粒度を絞る。
検討した上で詳細に書くべき状況になるのなら、それは必要な工数。
詳細に書かなくてもいいよ（＾ω＾）のときは思い切ってシンプルに書く。
詳細化の基準はJSTQB（具体的と論理的…のあたり）なりIVEC（ミドルレベルシラバス：作成レベル）や実務で学んだりするとよい。

まとめ

テスト作りに時間がかかるのをまるっと縮める魔法のような近道はないが、学習したりプロダクトの資料を整頓することが少しずつテスト作りをスムーズにすることに繋がりそうではある。