はじめに

これまでのテスト実施やテスト仕様書作成の経験を踏まえてこんなテスト仕様書は書いてほしくないという思いを伝えたいと思います！

その１　操作方法が分からない

システムの仕様が分かる人（自分など）向けにしか書かれておらず、詳細な操作方法が書かれていないというケースです。
テスト仕様書は必ずしも自分がやるとは限らないため、システムの仕様を把握していない人でも実施できるようなテストケースを記載すべきです。丁寧に書くと手間なのですが、結局この操作方法はどうやるのかという問い合わせが来る可能性が高くなり説明するのが手間ということにも繋がると思います。

Point
入社したての新卒でも分かるかということを想像しながら丁寧に記載する

その２期待値が曖昧

例として「〜が正しいこと」のように人によって判断がブレてしまうケースです。
人によって判断がブレてしまうと不具合が生じていても正しい期待値としてテストが進められてしまう可能性があります。そうなると、テスト時に発見できていた不具合の発見が遅れてしまい大きな不具合へと繋がるということもあり得ます。

Point
抽象的な表現は避けて具体的な期待値を記載する

その３　同じ操作を何回もやっている

１回の流れでまとめてテストができるのに分けて書かれていたり、不要なデータの作成が多いケースなどです。
一連の流れの中で確認できるものは効率性を考えてまとめて確認をしてしまいたいです。テスト仕様書を作成するということだけを考えるのではなく、後行程となるテスト実施時のことも考えながら記載してあげると良いでしょう。テストに掛かる時間が長くなると何事でもそうだと思うのですが、疲れて集中力が切れてきます。テストは不具合が無いかを確認する品質問題に関わる重要な過程なので、テスト実施者が快適にテストを進めることができるように意識することが大切です。

Point
テスト実施者の気持ちを考える

その４複数のテスト結果が１つの結果欄にまとめられている

例えば、複数ブラウザのテストをするケースなどです。
ブラウザ毎に結果を記載する箇所が分かれていなかったため、自分のエディタで結果を残して全部実施した後にテスト仕様書に結果を記載するというような経験をしたことがあります。テスト仕様書とは別の場所で結果を管理をしてしまうとテストの実施や不具合の発見が漏れてしまう可能性があります。全ての結果を記載できるようにテスト仕様書を書いてあげるとテスト実施者が楽になります。また、不具合の管理もしやすくなるかと思います。

Point
テスト結果には１機能のみの結果を記載できる作りにする

さいごに

個人的にはテスト仕様書の作成は一番辛い作業ですですが、それよりもリリース後に不具合が発生する方がもっと辛いため、テスト時に不具合を発見できるようにテスト仕様書の作成は丁寧に作成することを心掛けています。長いテストケースの作成は心が折れてしまいそうになりますが。。
テスト仕様書の作成は辛いですが、一緒に頑張りましょう

はじめに

その１ 操作方法が分からない

その２ 期待値が曖昧

その３ 同じ操作を何回もやっている

その４ 複数のテスト結果が１つの結果欄にまとめられている

さいごに

その１　操作方法が分からない

その２期待値が曖昧

その３　同じ操作を何回もやっている

その４複数のテスト結果が１つの結果欄にまとめられている