【テスト設計】テスト仕様書を考えるのってこんなに難しかったのか

テスト設計してます！と面談では答えた。経歴上にも確かにテスト仕様書書いたり、テスト計画書書いたり、シナリオ書いたりしてたので、嘘は言ってないつもりだった。

今のプロジェクトで、「テスト仕様書のフォーマットを考えてほしい」という要望にも応えられるつもりだったのだけど、いざフォーマットを作り出すと「？」となることが多くて、「今までテスト設計したつもりになってたけど、実はテスト設計なんてしてなかったんじゃ」と不安になってきた。

テストを設計するというと、自分の場合「どんなテストケースを作ればいいか」を重点に考えるけど総合的に設計するとなると「どんなテストケースを作ればいいか」は枝葉と言ってもいいかもしれない。何が幹になるの？というのはまだわかってない。

そもそもフォーマットを作る、となると

ディレクトリ構成
テスト仕様書の構成（UTの項目、ITの項目、STの項目）
エビデンスの管理方法
ファイルの命名規則

と外側部分で決めておかなくてはいけないことがあることがわかった。なぜこういう部分に意識がいかなかったかといえばそれはだいたい決められていたから、ということに他ならない。

だいたいこういうテスト仕様というかドキュメント管理部分を外注に決めさせるようなSIerはないから。大手なら尚のことだ。

今までは決まった規則に従ってドキュメント（テスト仕様書）を書いていたけど、今回はフォーマット作り、ということなので（作業が合ってるかは別として）考えておかなくていけなかった部分だった。もしかしたら、この辺りのドキュメント管理に関する仕様は決まっているかもしれなくて、余計なことをしてるのかもしれない。

で、ドキュメント管理に関する仕様が（未確認ながらも）完成しているので、実際にUTの仕様書のフォーマットを書いてみたけれど、結局何が「UT」に当たるのか「IT」に該当するのは何？ってなることが多いなと思った。

一旦、どんなことをテストケースに書かなくてはいけないかというのは置いておいて、テストケース（テスト仕様書）のフォーマットを決めておくことを優先作業とした。

f:id:starscream1999:20181216190637p:plain — UT仕様書のサンプルイメージ

テスト仕様書の各項目は以下のように定義した。過不足あるだろうが、ある程度は網羅出来ているのではないか？

・No. 項番

・分類テスト分類

　初期表示なにも操作せずに表示された状態

　操作項目テスターが行う操作

　非操作項目操作系ではないものの確認すべき項目(データ格納等)

　その他

・テスト項目テストする項目

・詳細項目詳細

・対象画面 | フォームであれば該当のフィールド名

・テスト区分正常 | 異常

・テスト内容テストの内容

・再現方法（テストを実行するための方法

・期待結果テストで得られる期待値

・参考資料仕様書などを別紙で確認する必要がある場合は記載（入力規則など）

・エビデンステスト実施後提出するエビデンスの種類。場合によっては具体的に

・テスト結果 OK | NG

・実施日実施した日時

・担当実施した作業者名

・結果コメントテスターからのコメント欄

・エラー発生時は、日付とエラー内容を入力

・追記の場合は上書きではなく、下の行に追加していく。

・備考テスト設計者からのコメント欄

・チケット該当チケットのURL（チケット登録後、テストリーダーが入力）

・Web 　null | 〇　ウェブシステムかどうか

・アプリ null | 〇　ネイティブアプリかどうか

実際にテストケースを書く上で必要な土台作りは出来たので、あとはテストの観点がまとまれば問題ないと思う。IT仕様書もほぼ同じ作りで、上記項目の中から「対象」の項目を削除した。結合テストの観点から考えると、ピンポイントで画面項目名が必要とは考えられなかったからだ。

また、上記のようなテストケースではなく、マトリクスを作って一覧的に確認する方法もあると思う。画面項目の活性非活性制御や状態遷移の確認などに有効な気がするが、画面内の項目が多くなるとものすごく大きなマトリクスになってしまい、時間もかかる。いいか悪いかは別として、そういう手段もある。とにかくドキュメントがあると安心するようなSierなんかの場合、「自分が実際にテストする立場じゃなければ」あれば喜ばれるかも知らん。

しかし、いざテストケースのフォーマットと言われても最初の一歩で困惑するのはいまだにテストエンジニアとして全く経験が足りてないことの証左だな〜と改めて自分の今後に不安を覚える次第であります。