326
268

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

こんなテスト仕様書は書かないで

Last updated at Posted at 2022-11-17

はじめに

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

その1 操作方法が分からない:sob:

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

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

その2 期待値が曖昧:sob:

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

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

その3 同じ操作を何回もやっている:sob:

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

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

その4 複数のテスト結果が1つの結果欄にまとめられている:sob:

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

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

さいごに

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

326
268
6

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
326
268

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?