0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

テストケース作成で気をつけていること

Posted at

私がテストケースを作成する際に気をつけていることを、思いつくままに書きます。
状況や考え方によってブレることもありますが、少しでも参考になれば嬉しいです。

手順がケースをまたがないように書く

「ケースY」の実施にあたり「ケースXのデータを使う」としているケースを見かけることがあります。しかしこのような構成だと、「ケースX」を先に実施する必要が生じ、手間が増えてしまいます。
さらに「ケースX」が別の目的で複雑な内容の場合、「ケースY」の前提がわかりづらくなることもあります。

多少手間でも、「ケースY」で必要なデータは、その手順内で準備するほうがわかりやすく、単体で実施しやすくなります。

手順は毎回書く

「ケースXの手順1〜3と同じ」と書かれる場合もありますが、実施時にいちいち参照し直すのは手間ですし、意図も伝わりにくくなります。

内容が複雑で毎回記載するのが現実的でない場合は、共通の手順を別シートにまとめるなどの対応が良いと思います(Excelであればシートを分けるなど)。

ケースが切り離せる

テストでNGが出た場合、そのケースだけを再実施できる状態が理想です。他のケースと依存していると、再実施が難しくなったり、全体のやり直しが必要になったりします。

再実施がしやすいよう、ケースごとに独立している構成を心がけています。

前提も手順に含める

テストデータの準備や環境構築などの前提条件も、できるだけ手順に記載するようにしています。

手順として明記することで、見落としや実施ミスを減らせると思います。

誰でも実施できる

仕様を知らない人でも実施できるような内容にすることが理想です。

作成者や実施者が仕様に詳しい場合、どうしても内容が簡易的になることがありますが、他のチームに依頼する場面もあると思います。

その際に「つまりどうすればいいの?」となりがちなので、誰が読んでも迷わず、同じ手順を踏めるよう意識しています。

観点をわかりやすくする

手順が長文化していたり、似たような操作が繰り返されるケースも見かけますが、それは1つのケースに複数の確認観点を詰め込んでいる場合が多いです。

観点ごとにケースを分けることで、手順や目的が明確になりやすくなります。

確認事項は1行に1つ

特にExcelなどの表形式で作成されたテストケースでは、1行に複数の確認項目が書かれていることがあります。

こうなると確認漏れが発生しやすくなるため、確認事項は1つにつき1行で記載するようにしています。

1項目ごとにOK/NGを判定できる形にすることで、チェック漏れも防げます。

最後に

文面はChatGPTに添削してもらいました。読みやすくなってたら嬉しいです!

0
0
0

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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?