開発会社から「結合テストが完了しました」と報告を受けて、内容が分からないまま「承知しました」と返した。テストの種類を調べてみたら、単体・結合・総合に加えて機能テストやリグレッションテストといった言葉が並んでいて、余計に分からなくなった。そんな状態の方に向けた記事です。
先に整理しておくと、テストの技法まで理解する必要はありません。発注側にとって大事なのは、どの段階で誰が何を確かめているのか、そして自社は何を受け取って確認すればいいのかの2つだけです。この記事では、システム開発のテストの種類を4段階で整理したうえで、発注側が受け取るべき証跡とその見方を説明します。
この記事のポイント
- テストは単体・結合・総合・受入の4段階で進む
- このうち開発会社が担うのは3つで、発注側が主役なのは受入だけ
- 受け取るのはテスト計画書と結果報告書の2つ
- 結果報告書で見るのは消化件数ではなく残っている不具合
目次
システム開発テストの種類と4つの工程
まず全体像です。名前は会社によって少しずつ変わりますが、進み方は共通しています。
単体・結合・総合・受入の4段階
テストは、小さな部品から始めて、だんだん範囲を広げていきます。いきなり全部つないで動かしても、どこが悪いのか分からないためです。
| 段階 | 確かめること | 実施する主体 |
|---|---|---|
| 単体テスト（UT） | ひとつの機能が設計どおりに動くか | 開発会社 |
| 結合テスト（IT） | 機能どうしをつないでも正しく動くか | 開発会社 |
| 総合テスト（ST） | システム全体が仕様書どおりに動くか | 開発会社 |
| 受入テスト（UAT） | その仕様で自社の業務が回るか | 発注側 |
順番に意味があるのは、原因を切り分けやすくするためです。単体で動くことを確かめてからつなぐので、つないだ途端に落ちたなら原因は「つなぎ方」にあると分かります。逆に、いきなり全部つないで動かすと、どの部品が悪いのかを探すところから始まり、時間がかかります。開発会社が段階を飛ばしていないかは、計画書の工程を見れば分かります。
総合テストはシステムテストとも呼ばれます。呼び方が違うだけで、指しているものは同じです。工程の略語がほかにも出てきて混乱する場合はシステム開発の工程と流れに一覧があります。
開発会社が担うのは3つまで
この表でいちばん大事なのは、いちばん右の列です。単体・結合・総合の3つは開発会社が自分たちで実施し、自分たちで合否を判断します。発注側が立ち会うことは基本的にありません。
発注側が主役になるのは受入テストだけです。ここは実際に業務を担当している人が、自分たちのやり方でシステムを動かして「これで業務が回るか」を判断します。進め方はシステム開発のUATとは？発注側が主役の受け入れテストで詳しく扱っています。
この線引きを知らないと、無駄な心配や口出しが生まれます。単体テストの進み方を細かく聞いても、返ってくるのは技術的な説明だけで、判断材料にはなりません。逆に受入テストを開発会社に任せてしまうと、業務が回るかどうかを誰も確かめないまま本番を迎えることになります。関わる場所を間違えないことが、限られた時間の使い方として効きます。
つまり発注側から見ると、テスト期間の大半は「開発会社が中でやっていること」になります。だからこそ、中で何が起きているかを知る手段が必要になります。それが後半で説明する証跡です。
目的別のテストは総合テストの中で行う
検索すると、機能テスト、性能テスト、セキュリティテスト、リグレッションテストといった言葉も出てきます。これらは4段階とは別の分類なので、並べて覚えようとすると混乱します。
整理すると、4段階は「いつやるか」の区分で、こちらは「何の観点で見るか」の区分です。多くは総合テストの中で、観点を変えて実施されます。
- 機能テスト：仕様どおりの結果が返るか
- 性能テスト：処理速度や、大勢が同時に使ったときに耐えられるか
- セキュリティテスト：不正なアクセスや情報漏れの穴がないか
- リグレッションテスト：どこかを直したせいで、別の場所が壊れていないか
もうひとつ知っておくと役に立つのが、テストの深さは段階によって違うという点です。単体テストは開発会社の内部作業に近く、証跡も簡易なメモ程度のことがあります。一方、総合テストは仕様書と突き合わせる正式な工程なので、項目表と結果が残ります。ですから発注側が本気で中身を見るのは、総合テストの記録からで十分です。単体テストの一覧まで出させても、読める人が社内にいなければ意味がありません。
発注側として押さえておきたいのは、これらが実施されるかどうかは案件によって変わるという点です。とくに性能テストとセキュリティテストは、見積もりに含まれていないこともあります。同時に使う人数が多いシステムや、社外に公開するシステムなら、含まれているかを契約前に確認してください。
システム開発テストで発注側が受け取る証跡
ここからが本題です。中を直接見られない以上、発注側は書面で確かめることになります。受け取るものは2つだけです。
受け取るのはテスト計画書と結果報告書
テストが始まる前に出てくるのがテスト計画書、終わったあとに出てくるのが結果報告書です。この2つを納品物として契約に入れておくのが基本になります。
この2つは、黙っていても出てくるとは限りません。とくに小規模な案件では、テスト計画書を作らずに進めることもあります。悪意があるわけではなく、社内の慣習でそうなっているだけのことが多いのですが、後から「テストしたはずだ」「聞いていない」となる原因になります。見積もりの段階で、成果物として何が納品されるのかを一覧で出してもらってください。
計画書で見るのは、どの段階でどんな観点のテストをするのか、そして合格の基準をどう置いているかです。「重大な不具合がゼロであること」といった書き方をされていることが多いのですが、重大とは何を指すのかまで書かれているかを確認してください。ここが曖昧だと、あとで判断が揺れます。
結果報告書のほうは、実施した件数、見つかった不具合の件数、そのうち直したものと残っているものが並びます。ここで発注側が見る場所は、次のとおりです。
テスト環境とデータは誰が用意するか
証跡の話に入る前に、計画書で必ず確認しておきたいことがあります。テストを動かす環境と、そこに流すデータを誰が用意するのかです。
環境そのものは開発会社が用意するのが一般的ですが、テストに使うデータは発注側が出すことになる場合が多いです。とくに総合テストの後半や受入テストでは、実際の業務に近いデータがないと意味のある確認ができません。ここが計画書に書かれていないと、テスト開始の直前になって「データをください」と言われ、そこから社内調整が始まって日程が押します。
実データを使う場合は、個人情報や取引先の情報をどう扱うかも先に決めてください。そのまま渡してよいのか、一部を伏せた形にするのか。伏せる作業が必要なら、それ自体が数日かかる作業になります。誰がいつまでに何を用意するのかを、計画書に書いてもらうのがいちばん確実です。
結果報告書で見るのは件数ではなく残っているもの
報告書を受け取ると、まず「テスト項目1,250件、消化率100%」といった数字が目に入ります。ですが、この数字はあまり意味を持ちません。項目の粒度は開発会社が決めているので、細かく分ければいくらでも増えるからです。
見るべきなのは、残っている不具合とその重要度です。「未修正が12件あり、うち業務が止まるものが2件」という情報のほうが、消化率よりはるかに重要です。残件がゼロと書かれていない場合は、それぞれいつまでに直すのかを確認してください。
逆に、不具合の発見件数がゼロと報告されたら、それは喜ぶ場面ではありません。私の感覚では、一定の規模のシステムでバグが1件も出ないことはまずありません。テストが浅いか、報告に上がっていないかのどちらかを疑ったほうがいいです。件数の多さより、見つけて直した記録が残っていることのほうが健全です。
残っている不具合を見るときは、重要度の区分が案件ごとに決められているかも確認してください。よくあるのは「業務が止まる」「業務は回るが手間が増える」「表示や文言の問題」の3段階です。この区分が最初に決まっていないと、開発会社が軽微だと判断したものを発注側が重大だと考える、という食い違いが起きます。区分と、それぞれ何日以内に直すのかは、テストが始まる前に合意しておくのが安全です。
ここまでの観点をまとめて確認したい場合は、検収・受入テスト確認シートの「残っている不具合」カテゴリが使えます。
もうひとつ、リグレッションテストの記録があるかも見てください。終盤に不具合を直した場合、その修正で別の場所が壊れていないかを確かめ直す必要があります。ここが抜けていると、直したはずのものが本番で再発します。
テスト工程が薄い計画は後半で崩れる
証跡とあわせて、時間の配分も見ておく価値があります。実装に3か月かけるのにテストが2週間しかない、という配分になっている計画は、たいてい後半で苦しくなります。
もし比率の判断に迷うなら、開発会社に直接聞くのがいちばん早いです。「このテスト期間に、不具合が出た場合の修正と再確認は含まれていますか」と質問すれば、含まれているのか別枠なのかが分かります。答えが曖昧なら、その計画は不具合が出ない前提で組まれているということです。
理由は単純で、テストで見つかった不具合を直す時間が計画に入っていないからです。テストは1周して終わりではなく、見つける、直す、確かめ直す、という折り返しが発生します。この折り返しの時間があるかどうかを、計画の段階で聞いてください。
自分の勘だけで「短すぎる」と判断しにくい場合は、公開されているデータを拠り所にできます。IPAはソフトウェア開発分析データ集として、これまでに収集した5,546プロジェクトの定量データを分析して公開しています。技術者の経験と勘に頼るのではなく実際のデータに基づいて管理する、という趣旨のものです。なお、この事業は終了しており今後の発行予定はないと明記されているので、公開時点のデータである点には注意してください。工程ごとの日数の妥当性そのものはシステム開発のWBSとは？発注側が遅れを見抜く読み方でも扱っています。
- Q. 単体テストや結合テストに発注側は立ち会うべきですか？
- 基本的に不要です。この2つは開発会社の内部作業で、確認しても技術的な説明が返ってくるだけです。発注側が時間を使うべきなのは、総合テストの結果報告を読むことと、受入テストを自分たちで動かすことです。
- Q. テストの成果物は契約書にどう書けばいいですか？
- 納品物の一覧に「テスト計画書」「テスト結果報告書」と項目名で明記してもらうのが確実です。段階ごとに分ける必要はありませんが、少なくとも総合テストの分は受け取れる形にしておいてください。
- Q. 性能テストやセキュリティテストは必ず実施されますか？
- 案件によります。見積もりに含まれていないこともあるため、同時に使う人数が多いシステムや社外に公開するシステムでは、契約前に含まれているかを確認してください。あとから追加すると別費用になります。
