今まで関わってきたプロジェクトはだいたい年単位でスケジュールが組まれているのが普通で、その中でもテストフェーズ（統合テスト・システムテスト）は3ヶ月から6ヶ月程度の期間が取られること多かった。現在のSES先企業ではすでに稼働中のWebサービスがあり、そのサービスの機能追加だったり不要な機能を削除したりと日々何かしら動きがある。
過去のプロジェクトと今関わってるプロジェクトの違いはこんな感じである
今まで
- 設計書が豊富に揃っている（画面仕様書やDB設計書など）
- 期間が長い
- テスト仕様書/設計に対するレビューがかっちりしている
現在
- 設計書が揃っていない
- 期間が短い
- テスト仕様書/設計レビューがゆるい
テスト設計をしていてテストケース作成時に特に困るのが「設計書が揃っていない」ことである。揃っていないというか、一応機能仕様書はあるのだけど画面遷移図やステータスの状態遷移図がないので、前提となる状態とその後の期待値がはっきりしないというがある。
ではそんな状態でどのようにパフォーマンスを出せばいいのだろうか？優先的に行いたいものは、「仕様の凍結（フリーズ）」と「完成したシステムに対するスモークテストの実施」の2つだと思う。
仕様の凍結（フリーズ）
システム改修、システム追加などのプロジェクトにおけるキックオフで概要などの説明があり（キックオフ自体がないかも）、その場で色々と質疑応答があると思うけれど、まずは現段階で仕様の凍結を依頼しておきたい。
明らかな仕様の誤り（システム的な矛盾、不要な要素を除く）などは改修対象として良いと思うが（テストの無駄なので）、思いつきで追加されるような機能がないことを前提としてテストの設計をしたいため、仕様の凍結はマストだと思う。ただでさえ設計期間も短いのだから何かあるたびに機能を追加されていたらキリがない。
そういった機能追加要望については、リリース後のアップデートでの対応でまかなう方が良い。まずはリリースしてしまおう。
ただし、機能改修の中でも「機能の削除」は歓迎したいところだ。しかし単に機能削除と言っても他機能と結合状態が強い場合その点を考慮が必要なので、削除される機能は独立した機能が望ましいと思う。
完成したシステムに対するスモークテストの実施
これはテストチームがテスト設計を終えて、いざテスト開始となる前に、「そもそもシステム自体はきちんと動作するか」を確認する作業。システムの頭からお尻までを一回通して動かしてみて、システムの機能がきちんと動いているかどうかをみるためのもの。
スモークテストを実施していないときに（ままある）、テストを開始したもののシステムの根本となる機能が正常に動いていないことが判明し、テストストップとなったことがごくたまに起きていた。テストがストップしている期間、一旦スタートしたテストのために確保した人員リソースの解放も難しく、スケジュールがぐちゃぐちゃになってしまう。
一度テスト開始前にスモークテストさえしておけば、そこで不具合が見つかった場合に「テスト開始期間を後ろ倒しに」という形で対処ができるため、テストが途中でストップになった場合に比べてスケジュール調整が容易になる。
じゃあ、そのスモークテストとやらは「誰がやるのか」という部分がありますが、優先すべきは開発者じゃないでしょうか。他にはPMなどもいると思いますし、場合によってはテスト担当者でもいいと思います。ただ、テスト担当者の場合、テスト実施に工数は確保していると思いますが、テスト前のスモークテストにまで工数は確保していないはずなので、追加の工数が必要になります。
以上の2つがテスト実施に関して優先すべき事項だと思っています。では、テスト設計に関してはどうでしょうか。テスト設計に関しては1つの記事でぺろっと解説となると範囲が非常に広く、深くなってしまうため既存機能のテストに絞ってみたいと思います。
過去のテスト資源を再利用しよう
テスト設計に関していうと、既存機能の確認テストはなるべく設計を行わず、過去のテスト資源を再利用するべき、というのがあります。
ちなみにちょっと話がズレますが、このエントリーを読まれているテスト担当者の方のテストの現場はどのようなテスト設計環境にありますか？Excelベースのドキュメントを使ったテスト設計の環境でしょうか？それとも何かのテストケース管理ツールを運用している環境でしょうか？
私はこれまでExcelベース管理のテスト設計現場も経験ありますし、テスト管理ツールを運用している現場も両方あります。なので、どちらのいい面、悪い面もわかってるつもりですが、比べた時にはやはりテスト管理ツールを運用する方が「楽」と感じます。
いつ、誰が、テスト結果をNGにしたか、OKにしたか、そしてテスト全体がどの程度進んでいるのかという情報がすぐにわかるのがテスト管理ツールです。特に「テスト結果がNGだった場合」にいろいろな情報をテスト結果に記述する必要が出てきますが、その点でExcelシートだと記述スペースにも限界があります。（Excelのセルに書こうと思えば書けるがセルの表示範囲を超えるといちいちセルにカーソルを合わせないと全体が読めない）
テスト管理ツールであれば、そういった情報を一つのテストケースにわかりやすくまとめることが可能なので、後から見た時に見やすい。
また冒頭の話に戻りますが、既存機能を再利用したいとなったときにExcelでシートをコピーして使うというのも案外面倒な部分です。細かくシートが機能単位で整理されていれば良いですが、大体そうはなっておらず「どこからどこまでが再利用対象の機能のテスト？」と判断に迷うこともしばしば。「探すのが大変なので、だったら最初から作り直した方が良い」というふうになってしまうこともあったりします。
テスト管理ツールなら（ただの物置のように管理されているのでなければ）、再利用対象機能だけを抽出して再テストすることが容易です。
Excelベースからテスト管理ツールへの移行しようとすると、最初は「戸惑い、手間、ツールの機能の理解が必要」などの導入障壁があるのでゼロコストとは言いませんが（実際無料で使えるものも多くはない）、導入後が非常に快適なので、まだExcelでやっているのであればツール導入を強くお勧めします。
こんな記事があったので、リンクしておきます
以上、頻繁にリリースされるプロダクトの現場でテストする人の参考になればと思います。
