はじめに
今度、結合テスト手伝ってもらうから～！
プロジェクトで突然、そんな場面に出会うこともチラホラ。
テスト仕様書見ながらひたすら項目こなせばいいだけでしょ？
・・いえいえそんなことありません。
やり方を間違えれば、
- 期間内に終わらない
- 重要な観点を見落として、後の工程 or リリース後に障害発生（→ テスト実行者誰や～?ってなるやつ）
などなど、いろいろと問題になりかねないので、心して臨む必要があります。
自身の経験も踏まえ、漏れなく、ダブりなく、結合テストを進める手順をまとめてみました。
※様々なテストがありますが、今回は結合テストにのみフォーカスしています。
結合テスト実行手順
1. スケジュール、制約事項の確認
まずはスケジュール、制約事項の確認をします。
- 期間、ボリュームはどのくらいか?
- どのような環境、ツールを使うのか?
- 不具合が見つかったらどうするのか?（エスカレーションの方法、頻度など）
などなど。テストを進めるにあたって必要な情報を把握しておきましょう。
2. 実行環境の準備
次に、テスト実行に必要な環境やツールの準備を行います。
テスト実行時に不足のないよう、この段階で一通り整えておきましょう。
3. 設計書、テスト仕様書の確認
続いて、設計書、テスト仕様書に目を通しておきましょう。
ありがちのが、テスト仕様書は見るけれども、設計書は見ないケース。
テスト仕様書の内容がわかりやすく的確であればかまわないのですが、必ずしもそうとは限りません。
例えば、次のようなケース。
機能概要：試験問題を解き終え、終了ボタンを押す。70点以上の場合は「合格」、70点未満の場合は「不合格」と表示される。
そして、結合テスト仕様書が以下のようになっていたとします。
| 画面 | 操作 | 期待値 | 備考 |
|---|---|---|---|
| 結果画面 | 終了ボタンを押下すること | 結果が合格であること | 正答率70%で試験を終了すること |
この場合、確認すべきなのは、画面の表示でしょうか? テーブルの値でしょうか? それとも、両方?
・・正解は、設計書の内容によります。
期待値の内容が、
- 結果画面に合格と表示されていること
- scoreテーブルの合否フラグの値が1（合格）であること
のように詳細に書いてあればいいのですが、上の表のように曖昧な書き方をされている場合は何をもって合格とすればいいのか、ハッキリしません。
独断と偏見で進めると、後々富んだ大事故になりかねないので、設計書も一通り読んで、テスト実行時に具体的に何を確認できればよいのか？把握しておきます。
・・実際に上のような結合テスト仕様書に出くわして不具合を見逃してしまい、後の工程で発覚、手戻りが発生してたいへんなことになりかけたことがあります。
（テスト設計レビューの段階で修正しておいてほしいところではありましたが、、）
何らかの問題が起こったことによる再テストの場合は、不具合チケットなどを確認し、問題とそれに対する対応内容も把握しておきます。
また、この段階で必要に応じて、実装者やテスト設計者に確認をとり、疑問点を払拭しておきましょう。
（不具合や手戻りを最小限にとどめるためにも、この後のプロセスでも、疑問点があれば適宜確認を。）
4. テスト実行順序の決定
例えばWEBサイトの場合、テスト項目はたいてい画面単位で順に並んでいるため、そのまま順番通りやると非効率です。
どの順序でやるとスムーズか考え、必要なデータや条件などでパターンわけしておきましょう。
例えば、次のようなケース。
機能概要：ユーザーIDでログイン → 結果画面に合否を表示 → 詳細画面に得点を表示する。
備考：70点以上の場合は「合格」、70点未満の場合は「不合格」
そして、テスト仕様書が以下のように書かれていたとします。
| No | 画面 | 操作 | 期待値 |
|---|---|---|---|
| 1 | 結果 | 得点が70点以上のユーザーでログイン | ・合格と表示されること |
| 2 | 得点が70点未満のユーザーでログイン | ・不合格と表示されること | |
| 3 | 詳細ボタンを押下 | ・詳細画面に遷移すること | |
| 4 | 詳細 | 得点が70点以上のユーザーで詳細画面に遷移 | ・DBに登録されている得点が表示されること ・得点が70点以上であること |
| 5 | 得点が70点未満のユーザーで詳細画面に遷移 | ・DBに登録されている得点が表示されること ・得点が70点未満であること |
この場合はどうでしょうか?
上から順に進めるよりも、
- 1 → 3 → 4
- 2 → (3) → 5
のように進めたほうがスムーズですよね。
テストのボリュームが多くなればなるほど、パターン分けも複雑になるので、無理しすぎない範囲で（このプロセスに時間を取りすぎるのもよくないので、、）やっておきましょう。
5. テストデータの準備
続けて、4でわけたパターンに対応したデータを準備します。
このパターンの場合はこのデータを使う、と一覧にまとめておくと実行時に楽です。
手順4であげたテストケースの場合、以下のような感じ。
（実行順序も併せて書いています。）
| パターン1 | パターン2 | 備考 | |
|---|---|---|---|
| 合格 | 不合格 | ||
| ユーザーID | 0001 | 0002 | userテーブル |
| 得点 | 70 | 69 | scoreテーブル |
| 実行順序 | No | No | |
| 1 | 2 | ||
| 3 | (3) | ||
| 4 | 5 |
6. テスト実行、報告
いよいよテスト実行です。
手順4, 5で決めた順序とデータを使って進めていきましょう！
不具合が出た場合は、不具合チケットの起票等を行うなどして、都度報告していきます。
（この辺りの対応はプロジェクトによって異なるので、手順1でぬかりなく確認しておきましょう。）
テストを実行し終えたら、実行結果や画面キャプチャなど、成果物の提出も忘れずに！
7. 振り返りの実施
プロジェクト全体で振り返りを行うところもあると思いますが、個人でも振り返りを行い、よかった点、改善点をピックアップして、次回、よりスムーズに進められるようにしておきましょう。
PDCAサイクルをまわしていけば、最強のテスト実行者になれること間違いなし！
終わりに
いかがだったでしょうか?
結合テストはじめ、テスト工程はシステムの品質に重要な役割を担っています。
経験を積みつつ、書籍や勉強会などで学んで、よりスピーディーに、より質の良いテストを実施できるようにしていきたいですね。
参考
日頃のテスト、そして、本記事の執筆に、以下の書籍を参考にさせていただきました。
- この1冊でよくわかるソフトウェアテストの教科書 | SB Creative
- 駄目パターンに学ぶ失敗しないソフトウエアテスト実践ノウハウ | 日経SYSTEMS
前者ではテスト手法メインに必要な知識を一通り、後者ではテスターに必要な考え方を学べます。
いずれも比較的読みやすいので、オススメです！