中年エンジニアの開発と生活の日々

中年エンジニアがソフトウェア開発や日々の生活で得た知見の備忘録

限られた工数でテストケースの品質を上げる

最近、検証エンジニアも兼務すること多く、2年くらい前からテスト設計からテストの実行までやるようになりました。 その際に、見極めが難しいのが、テストケースをどこまで掘り下げて書くかと言うことでした。

基本

おおよそのテスト設計の教科書には以下のように書かれています。

  • 誰が読んでも同じ手順を再現できるように作る
  • 誰が実行しても、実行結果を判定できるように作る

最初は教科書通りにテストケースを書こうとしていたのですが、なんと言っても時間がかかるし、プラットフォームやブラウザやOSのバージョンによって手順が変わったりするので、現実的に上記を100%実行するのは不可能に近いし、工数をかけてまでやることではないという結論にいたっています。

テストケースを作成するに当たって重視すること

限られた工数を使って、有効なテストケースを作成しようとする場合、教科書の中から優先度の低いところをそぎ落としていきます。

  1. OS やブラウザなど、業界標準の知識に依存する手順については省略する
  2. 仕様書を見ればわかる手順は省略する

そして、テストの仕様に対するカバー率は100%を目指します。仕様に書かれているが検証されない機能をゼロにするためです。 そんなの当たり前じゃん、と思う方もいるかもしれませんが、仕様書も完璧に書かれているわけではないケースが多いため、希に抜けることがあったりします…

そんなわけで、結論としてはテストケースの項目を作成するときは気合いを入れる。テスト項目の中身を記載する場合、ある程度読み手を限定して手を抜けることろは手を抜くとメリハリをつけています。

テストケースを書く際に気をつけていること

自分がテストケースを書くときに気をつけていることは大体以下のようなことです。

  • 読み手の仕様に対する理解率を想定しておく
  • 手順を詳細にすることに力を注ぐより、カバー率を上げることに注力する
  • なるべくほかのドキュメントに書いてあることは書かない

ドキュメントというモノは誰かに向けて書いているわけで、読み手の理解率を想定しておくことがとても重要です。 国内の同じ拠点で開発している気心の知れたメンバー向けにオフショアベンダー向けに作るようなテスト手順書を作成するのはオーバースペックな上に、読み手にとっても読みにくいモノになるでしょう。