テスト計画の立て方

テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。

テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。
この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。

しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。

テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テストプロセスが構成されるようになっていて、両者はハッキリ区別されています。まぁ納得のいく話であります。

テスト種別

したがって、テストを計画するには、テスト種別を設計することから始めると考えやすいでしょう。
私が、タタキとしてよく使うテスト種別は、こんな感じのものです。必要に応じてセキュリティテストのあたりとか足すと良いと思います。

テスト種別	テスト種別	目的	Input
構文チェック	ソース構文チェック	ソースコードを静的解析し、コーディング規約違反、潜在バグを発見する。	コーディング規約
構文チェック	SQL構文チェック	SQLを単体で実行し、文法エラーがないことを確認する。
ユニットテスト	-	クラス,関数単体での挙動をテストする。回帰テスト可能なようにxUnitなどのツールを使って、テストコードを書くのが一般的。	詳細設計書
機能テスト	画面機能テスト	画面設計書で定義した仕様を満たしているかを１画面ごとに確認する。	画面設計書
機能テスト	バッチ機能テスト	バッチ設計書で定義した仕様を満たしているかを１バッチ毎に確認する。	バッチ設計書
フォーマットテスト	レイアウトテスト	帳票やインタフェースファイルが設計通りのレイアウトで出力されることを確認する。	帳票設計書 インタフェース設計書
フォーマットテスト	現新比較テスト	機能を変えないマイグレーション案件の場合、現行システムと同じレイアウトで、画面やバッチが出力されていることを確認する。	現行のシステム
セキュリティテスト	権限テスト	定められた権限の人しかリソースにアクセスできないことをテストする。
セキュリティテスト	CSRFテスト	POST/PUT/DELETE/PATCHメソッドの直呼びで、データが更新されてしまわないことをテストする。	-
セキュリティテスト	XSSテスト	<>"&などのユーザ入力値がそのままHTMLに出力されないことをテストする。
クロスブラウザテスト	PCブラウザ	ブラウザのレンダリングエンジンの違いによるデザイン崩れやJavascriptエンジンの違いによる動作不良を検出する。	動作保証ブラウザ
クロスブラウザテスト	モバイル実機	モバイルの実機において、ベンダーやバージョンの違いによる動作不良を検出する。	動作保証端末
シナリオテスト	-	実際想定されるユーザの操作シナリオに沿って動作検証する。間にバッチ処理などをはさむ場合は、それも含んでシナリオを書く。	ユースケース 画面遷移図
ジョブフローテスト	-	ジョブフローの設定に問題がないか検証する。	ジョブフロー
運用テスト	-	(特に人系を含んだ) 運用が実用に耐えうるものかを検証する。	運用手順書
障害テスト	-	障害発生時の系切り替えやリカバリ/デグラデーションが設計通り動作するかを検証する。	リカバリ設計書
性能テスト	SQL性能テスト	本番相当のデータに対して、SQL単体で実行したときの実行時間を計測し、そもそも性能要件を満たせそうにないものがないかを確認する。実行計画を取得し、意図したインデックスが使われていることを確認する。	性能要件
性能テスト	画面単体性能テスト	1画面に対してターンアラウンドタイムが規定値以下であることを確認する。	性能要件
性能テスト	バッチ単体性能テスト	1バッチ処理に対してターンアラウンドタイムが規定値以下であることを確認する。	性能要件
性能テスト	ロードテスト	運用時に想定されるだけの負荷をシステムにかけ、ターンアラウンドタイムが要求範囲内に収まることを確認する。	性能要件
性能テスト	スループットテスト	システムが同時トランザクションをどれくらいまで捌くことができるかを確認する。	性能要件
性能テスト	ロングランテスト	高負荷状態を長時間かけ続け、メモリリークなどシステムに異常な状態が発生しないことを確認する。	性能要件
移行テスト	-	移行プログラムの動作検証をおこなう。切り戻しの計画があれば、そのシナリオも実施する。	移行計画
業務シナリオテスト	-	他システム連携も含んだ全体の業務フローが設計したとおりに回せるかを検証する。	業務フロー

Markdownの表形式では見にくいので、詳細は↓をご覧ください。
https://docs.google.com/spreadsheets/d/1QUunhOsU3kNGVyFpObFscTLxfeOUMVgrGdfgOnNiq_A/edit?usp=sharing

テスト工程における成果物も、このテスト種別に合わせて決めるようにしましょう。「結合テスト設計書」や「結合テストケース」なる成果物なんてナイのです(総称した概念としては存在するかもしれませんが)。

テスト工程

テスト種別が設計できれば、それを工程へマッピングすることがテスト工程の計画のベースになります。

原則はV字モデルなので、テスト種別のインプットがどの工程で作られたかによって対応するテスト工程に、テスト種別を配置していくのが自然です。

したがって、先程のテスト種別の表で、「インプット成果物」をしっかり決めておくことが重要です。

イテレーティブな開発での考え方

V字モデルの開発をイテレーションごとにやるのがアジャイル開発だ、と言われることがありますが、私も基本的にはこれに賛成です。
したがって、イテレーション内で作るインプット成果物分に対応したテスト種別は、イテレーションの中でやるように計画します。大抵の場合は、画面設計書やバッチ設計書やストーリーのユースケース記述だったりが、インプットになるので、機能テストやシナリオテストまでは、イテレーションの中でやることになります。

新規システムをイテレーティブな開発で作り上げる場合は、ここに漏れている要件定義工程でのインプット成果物に対応するテストと、デグレが入り込んでないかの回帰テストをやる期間として、テストスプリントを全イテレーションの最後に設けるとよいです。

テストの評価

テスト工程には各々品質指標なるものを設定して評価するプロジェクトが多いことでしょう。

• 不具合数 / ソースコード行数
• テストケース数 / ソースコード行数
• 不具合数 / テストケース数

これも、もういちどISO 29119の図を見て欲しいのですが、テスト種別とリレーションシップがあるものです。したがって、テスト種別が異なれば、指標値も変えるのが自然です。

工程でまるっと指標値を決めちゃって、結果、設定したしきい値を越えちゃって、実感としては何も問題ないはずなんだけどなぁ…と思いながらも、言い訳を考える、なんて無駄な作業をしないよう、テスト種別ごとに指標値設定するようにしましょう。

テスト観点

テスト種別に沿って、テストケースを書くわけですが、何もなしに複数の人にテストケースを書いてもらうと、粒度がまちまちだったり、漏れがでたりします。特に、自然言語でまちまちに書かれた画面設計書やバッチ設計書がインプットになる機能テストなどは、人による粒度の差異が出やすいので、テストの観点とケースのあげ方のガイドを作るとよいです。これは、どの現場にいっても見かけるので、システムエンジニア各位、既に工夫されている点かもしれません。

手元に、パッとお見せできるものが無いので、イメージの伝わりやすいものへのリンクを貼っておきます。
http://labs.opentone.co.jp/wp-content/uploads/2010/02/8a7a1b428edc1ed170f8556838542f41.pdf
(元記事が分からなかったので、テスト観点への直リンクです)

いわゆる境界値検証やペアワイズ法などのテスト技法的なものは、このテスト観点に混ぜ込んでおくと、現場に自然に展開できるようになるかと思います。

テスト自動化

※ 自動化のツールの解説はQiita他に溢れているので、ここでは述べません。

ここまで出来れば、あとはテスト種別ごとに、自動化の戦術を決めます。たいていは、メンテナンスも含む自動化するためのコストと、自動化よって削減できるコストとのバランスをみて決めますが、これを見極めるのは非常に難しいものです。
「全てを自動化する/しない」のような極端な計画を立てるのではなく、「部分的に効果のあると思われるところを、手始めに自動化してみます」程度のほんのり自動化戦術でいくのが現実的なところかと思います。

まとめ

とにかくテスト工程とテスト種別とをごっちゃにせず、分けて語るようにしましょう。