私が過去にやらかした
ことを中心に、結合テストにおける「やってはいけないこと」をまとめてみました。
なるべく、専門書や資格試験ではお目にかかれない具体的な事項を挙げたつもりです。
本稿でいう「結合テスト」とは、単体モジュール同士を繋げて期待通りの動作を確認する作業（＝単体テストの次のフェーズ）のことです。
会社によっては「統合テスト」と呼びます。
本稿の内容は執筆者個人の経験に基づく完全に個人的な意見であり、所属企業における立場、戦略、意見を代表するものではありません。
仕様書のアンチパターン
事前に準備しておくべきデータがわからない
例えば、テストを進めている途中で仕様に突然「現在庫が無い、かつ、翌日以降に入荷予定がある商品を選択する」という条件が登場し、該当するデータがないとテストケースを最初からやり直しになるハメになるとか…
- 隅々までくまなく読まないと準備すべきデータが読み取れないようなテスト仕様書は、テスト実施において手戻りや停滞を発生させます。
- 準備すべきデータをテスト実施者が事前に把握できるよう、一覧表などにまとめておいて欲しいものです。
条件の作り出し方がわからない
例えば、「システムエラーの場合」とかザックリした書き方では、テスト実施者には、具体的にはどのような手順で作り出すべきなのか分かりません。
事前処理の手順も詳細かつ具体的に記述するべきです。
期待結果が明確になっていない
例えば、「エラーメッセージが表示されること」とかザックリした書き方では、テスト実施者には、表示されたメッセージが期待結果なのか否か判断できません。
「メッセージID：xxxxxx」とか、「メッセージ文言：〜」など、具体的に記述するべきです。
テンプレートの項目を埋めて満足してしまう
前述したような"不親切な仕様書"を生み出してしまう背景として、コレがあることが多いです。
個人的な経験上、デシジョンテーブル（※）形式のテンプレートを良く見ます。
しかしデシジョンテーブルは、一つの枠内に書ける文字数に制約があり、表現力が不足しがちな形式です。
テストデータの要件、事前条件の作り方、実施手順、結果確認方法などについて書ききれない点は、表の欄外に補足を書いたり、別紙を作成すると良いです。
（※参考リンク）ソフトウェアテスト・テスト技法に関する情報サイト - デシジョンテーブルの解説
テストケースの粒度が大き過ぎる
例えば、「1つのテストケースを消化するために3日かかり、その中の手順を一つでも間違ったら最初からやり直し」というようなテスト仕様書は、粒度が大き過ぎてリスキーです。
テスト実施の分担しやすさの面からも、程よい粒度にできないか、仕様作成者は気を配るべきです。
仕様書のレビューをしない
結合テストフェーズの頃になると、スケジュール的に厳しくなり、レビューの時間を捻出するのが大変な場合もありますが…
質の低いテスト仕様書に基づいてテストを実施しようとすると、実施担当者が迷って生産性が落ちたり、誤解やミスによって手戻りが発生したりします。
結局さらに進捗が悪くなるので、レビューは徹底した方が良いです。
仕様書作成者が実施担当者に事前説明（読み合わせ）をしない
仕様書作成者に時間的余裕がないと、つい「テスト仕様書はココにあるのでよろしく！何かあったら聞いてね」と実施担当者に"丸投げ"しがちですが、これはよろしくないです。
テストの目的（意図）、前準備〜実施までの全体手順、留意点等々、仕様作成者が実施担当者に口頭で説明した方が、結果としてテストの進捗も質も良くなります。
確かに、読むだけで分かる仕様書を書くことが第一ですが…
- 他者に説明することで、不足している部分が見えることがあります。
- 人間がやることなので、質問しやすい雰囲気を作ることも大事です。
また、仕様書作成者と実施担当者の間には情報量の差がある場合が多く、それを埋めるアクションを怠ると齟齬につながります。
齟齬が生まれないようにする責任は、実施担当者ではなく、仕様書作成者の側にあると考えます。
管理のアンチパターン
テストの観点が整理されていない
どのテストフェーズで何のテストをするのか？テストフェーズ全体の計画を立案すべきです。
例えば、排他制御は結合テストで実施するのか、もっと後のテストフェーズで実施するのかなど。
全体テスト計画を踏まえて、結合テストではどの観点をテストするのかをブレークダウンし、明確にすべきです。
そして観点は一覧表にするべきです。例えば、
- 業務フローに即したシナリオテスト
- サイクルテスト（日中の業務を回して、夜間バッチを流すなど）
- 権限系のテスト（管理者の権限と担当者の権限で操作可能範囲が異なるなど）
- 排他制御のテスト
- 環境周りのテスト（クロスブラウザなど）
- ハードウェア/ネットワーク障害系のテスト
このような感じで表にまとめることで、
- 観点に漏れがないか、重複していないかチェックできます。
- テスト仕様書作成の分担にも使えます。
- 優先度がわかりやすくなり、スケジュール立案にも使えます。
※テスト観点項目はあくまで一例です。
いきなり大きな粒度で繋げようとする
スケジュールが逼迫してくると、あれもこれも繋げて一気にテストしたくなりますが、これは「ビッグバンテスト」と言い、避けるべきテスト戦略です。
何故ならば、問題が発生した時に、どのモジュールに原因があるのか切り分けが難しくなるためです。
大抵の場合、
問題対応に手間取る → テストが消化できない → 進捗がさらに悪化する
というような負のスパイラルに陥ります。
"小さく始めてだんだん大きくする"、"急がば回れ"、が、結合テストの鉄則です。
コミュニケーションをおろそかにする
- テスト管理者は、テストチームに、テストの計画・目的・戦略・ゴールを伝達するべきです。
- テストフェーズに入る前にキックオフミーティングを行うと良いです。
- モチベーションはテストの質に影響すると思います。
- ココをきちんと共有しないと、テスト実施者は消化件数のノルマだけを気にするようになります。
- 検出した障害内容や、その対応ステータスは、定期的なミーティングで共有すべきです。
- 重要な障害を検出した人がヒーローになるぐらいの雰囲気が作れると、テストは成功したも同然です。
課題・障害管理フローが明確になっていない
- ツールとして何を使うのか？どのようなフォーマットとするのか？
- 対応する/しないを誰が判断するのか？
- 対応内容のレビューを誰が実施するのか？
- コードレビュー
- 設計書への反映
- 類似調査や横展開
- リグレッションテストなどのデグレード防止策
- クローズするのは誰なのか？
テスト結果（エビデンス）の残し方が明確になっていない
まず、そもそもエビデンスが必須なのかどうか、何のために必要なのか？
管理者は、慣習や惰性を排して是々非々でジャッジし、チーム内で意識合わせをすべきと考えます。
そして、エビデンスが必要なのであれば、「何を」だけではなく、「どのように」まで方針を決めないと、実施担当者としては悩んでしまいます。
方針次第で生産性は大きく変わりますし、個々の担当者が悩んでいる時間は一番無駄です。
フェーズ開始前に細かいことまでキッチリ決めておくべきです。
参考リンク
（引用）テスト仕様書の作り方大公開：(第1回)テスト設計の手順とセオリー
- 誰がやっても迷わずに同じことができるように
- 誰がやっても同じ結果が得られるように
- 結果がOKなのかバグがあるのか誰でも同じ基準で判断できるように
- 何に対してどんなテストをして、それがどんな結果だったのか（どこにバグがあったのか）後からわかるように
つまり『第三者が再現できるように』『第三者が客観的に判断できるように』ということなのです。