はじめに

こちらはゆるWeb勉強会@札幌 Advent Calendar 2022 16日目の記事です。
最近悩む機会が多い「テスト設計」について書いてみます。

記事を書くきっかけ

2022年の仕事を振り返ると、テストに苦労した一年でした。

私のプロジェクトは新規開発よりも既存機能を改修することの方が圧倒的に多いのですが、改修で過去のテスト設計を活用しようとすると、よくこんなケースに遭遇します。

今回はこういった内容を、実際に現場でも困っていることなので、テスト設計アンチパターンの事例紹介としてまとめます。

※主に単体テストをイメージして書いています（それ以外のテスト工程でも共通する部分があると思います）

私のプロジェクトでは、テストコードの有無に関わらず、最初にマトリクス形式のテスト仕様書を作成します。
※歴史的背景から、テストコードは一部にしか導入できていません

本来であれば仕様書とテストコードは同期が取れているべきなのですが、いつのまにか内容にズレが発生していることが多々ありました。

そうすると改修部分のテスト設計に集中したいのに、まず「現行仕様を担保できるテスト設計&テストコードに修正する」という余計な作業が発生してしまいます。

これが非常にしんどい作業。何が正解か調べないと分からない。
そもそも見積にそんな作業工数は見込んでいないので、時間を理由に諦めてしまうことも多く、傷口がどんどん広がっていく状況でした。

まずは仕様書とテストコードを少しずつでも合わせていきながら、改修したときは必ず同じタイミングで本流へマージすることを徹底することから始めてみようと思います。
※ごく当たり前の話ですが、できていないのが事実！

手作業で実施するテストの場合、実施条件や操作手順が具体的に書かれていないと、前回と同じテストの再現が難しくなります。

プロジェクトには人の入れ替えが付き物であること、運用していくなかで何度も同じ機能をテストする可能性があることを踏まえると、再現性を意識したテスト設計はとても大事です。例えばAPIのURL、ジョブの実行コマンドなどはコピペしてそのまま使えるぐらい明確に書いておくのがベターです。

テスト設計するときは「何も知らない自分がこの仕様書を渡されて、迷いなくテストが実施できるか？」ということを一つ基準にして考えてみると良いのかもしれません。

先ほどと近い話ですが、どういうインプット（データや操作）に対して、どういうアウトプットが期待されるのかも具体的に記述する必要があります。

例えば「XXマスタの項目値」「入力データのうち設計書の条件に合うもの」のような表現では、テストの状況や実施担当者によって正しいかどうかの判断が変わってきてしまいます。

テストは、誰が見ても客観的に同じ判断ができる状態が理想です。

テストに使うデータは、テスト用のデータだけで完結させるのが望ましいです。条件に合うデータがたまたまあったからという理由で、既存データを流用してしまうと、次にテストをしたタイミングで状態が変わっている可能性があるためです。

これが私のプロジェクトでは徹底できておらず、毎回テストのためのデータ作成や修正に時間がかかっています。

理想を言えば、リリース環境（DEVやSTG）のデータを汚染しないように、テスト用の環境が別にあると良いのですが、共存せざるを得ないケースも少なくありません。その場合は通常のマスタとテスト用マスタでコード体系を分けるなど、データがぶつからないように工夫して登録するのが良さそうです。

いくつかのテスト設計アンチパターンを記載してきましたが、すべてに共通するのは「再現性」や「客観性」といったキーワードです。

誰でも同じようにテストを実施できて、同じように結果が判断できて、テストの再実施も簡単！という状態にしておかないと、システムやプロジェクトの継続的な運用は厳しいものになってきます。（厳しさを実感しています...）

こうしたアンチパターンから得た知見は体系立てて整理するとともに、プロジェクト全体で共有して、みんなでテスト設計のあるべき姿について理解を深めていきたいなぁと思いました。

しかし、テストって本当に難しい。