システム開発の工程の中でも、テスト段階は具体的に何をするのか、いまいちわからない方も多いのではないでしょうか。この記事では、システム開発においてなぜテストを行うのか、テストの流れとテストの種類、テストの手順、テストを行う際気をつけるポイントについてまとめました。この記事がお役に立ちましたら幸いです。
なぜテストを行うのか
システム開発ではなぜテストを行うのでしょうか。テストの目的を改めて考えました。
直接的な目的と効果
テストを行い、バグを検出するというのが第一の目的です。プログラムのミスを検出することで動作不良などの欠陥を検出し、補修をします。
また、要件を満たしていることを保証する効果があります。プログラムは正常終了するが定められている仕様通りかどうかをテストし、仕様通りでない場合は仕様通りに動作するように補修をします。
間接的な目的と効果
テストを行うことにより、開発プロセスの改善点を見つけることができます。検出された不具合の傾向から開発プロジェクトの進行を見直すことで不具合の数を減らし、次回以降の開発の改善に寄与する内容を見つけ出せます。
また、テスト担当者の仕様理解度を深めることができます。テストを担当する人（テスター）は、そのシステムに詳しくある必要があります。アクシアではテストチームがそのシステムの仕様を最もよく把握していることが多いです。
テスト作業を通じて、システムの仕様やお客様の業務をより深く理解でき、保守・運用や追加開発の際、そのチームで培ったノウハウを活用することができます。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
システム開発でのテストの流れとテストの種類
単体テスト
一般的には、機能単位で機能単体の試験を実施することを指す場合と、プログラム単位で単体で試験を実施することの両方の解釈があります。解釈を区別するために、「プログラム単位で単体で試験を実施すること」を「ユニットテスト」と呼んで、機能単位の単体テストと区別することがあります。
ブラックボックステスト
機能単位で機能単体の試験は、主に画面を実際に操作して、あらかじめ作成したテストの仕様書通りの動きであるかを試験します。このテストのことは、プログラムの中身を見ないでテストをするため「ブラックボックステスト」と呼ばれます。
ブラックボックステストは、非プログラマーでもテストが可能です。ブラックボックステストで単体試験を実施する場合、「機能単位」で実施します。
例えば、「受注管理機能」と「請求管理機能」がある場合、それぞれの機能が出来上がった際にその機能単体のテストを行います。最終的には「受注管理機能」で納品済みになった受注データをもとに請求データが作成され、請求管理機能に連携される仕様であった場合、機能間の連動は単体テストでは意識せず、それぞれの機能単体で仕様を満たしているか、バグがないかを検出することを目的とします。
また、ブラックボックステストはより客観的な視点でテストが可能です。これにより、仕様に定められていないことでも、使い勝手（ユーザービリティー）面で難があり改善が望ましいと考えられる課題を検出することができます。
ホワイトボックステスト（ユニットテスト）
ユニットテストの場合は、プログラムの中身に沿って動作を試験するため「ホワイトボックステスト」と呼ばれます。ユニットテストの実施には、通常ユニットテストを実行するための仕組みが提供され、その仕組みに沿ってプログラムテスト用のコードを作成します。
例外として、ホワイトボックステストの実施が困難な場合は実施しません。例えば、システムの構成が古くホワイトボックステストを実施できる条件が揃っていなかったり、他社から引き継いだシステムがホワイトボックステストを想定した作りになっておらず、極めて非効率だったりといった場合などです。ホワイトボックステストはすべてのプロジェクトに適用できるものではありませんが、新規で開発するものは必須としています。
ブラックボックステストでは、機能単体でテストを行うためフロントエンド（画面）もバックエンド（裏側の処理）も完成していないとテストができません。ホワイトボックステストではプログラムの部品単位でテストを実施できるため、ブラックボックステストに比べて早期にテストを行い、バグを発見することができます。
非プログラマーではホワイトボックステストのテストコードは作成できません。テストコードを作成することで、プログラミング能力の向上、正しい仕様（あるべき姿）を理解したうえで実装を進める習慣がつくなど、プログラマーのスキル向上にも寄与します。
ホワイトボックステストはブラックボックステストと違い、テストは機械がやってくれるためいつでも何度でも再テストが可能です。そのため、リファクタリング（プログラムのソースコードは変えずに内部のソースコードの改善を行うこと）が容易になります。
結合テスト
単体テストを実施し、機能単体の動作が保証されてから結合テストを実施します。
結合テストでは、機能間の連動に着目してテストを行います。例えば「受注管理機能」と「請求管理機能」がある場合で、「受注管理機能」で納品済みになった受注データをもとに請求データが作成され「請求管理機能」にて「未請求」の状態で表示される仕様であった場合、実際にシステムを操作して仕様通りの動作となっているかどうかをテストします。
別々に作成された機能が仕様通り連携して動作するか、不具合が検出された場合どこに原因があったのかを考察し、次回以降のプロジェクトの進行（主にコミュニケーション）の改善をできることがあればフィードバックします。
また、システム内の機能の連携だけではなく、外部システムとの連携があるシステムの場合、外部システムのテスト環境を利用して連携のテストを行います。例えばクレジットカード決済、SNSとの連携、既存の基幹システムとの連携などです。
運用テスト
システムのリリース前に、実際の本番運用を想定して実際の業務に近い流れでシステムを利用してテスト運用を行う試験のことです。ここで検出される不具合、不都合は要件定義や基本設計など、上流工程の取り決めに間違いや想定できていないケースがあることが多いです。
このフェーズで検出される不具合や不都合はシステム会社のみならず、発注側でもよく振り返りを行い、運用・保守や次回以降の開発に活用することが重要です。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
システム開発のテストの手順
ブラックボックステストとホワイトボックステストの手順について解説します。
ブラックボックステスト
機能単体で動作するまでプログラムを作成したら、ブラックボックステストをあらかじめ作成しておいたテスト仕様書（チェックリスト）に基づいて作成します。プログラムの作成フェーズ（実装）と並行して、基本設計作成時にあわせてテスト仕様書を作成し、設計書に沿った仕様で実装されていることがチェックできるテストケースを用意します。
テスト仕様書については、設計者もレビューを行います。このレビューではチーム間での認識のズレを補正する役割もあります。
ホワイトボックステスト
「テストの流れとテストの種類」の項で述べたように、ホワイトボックステストはいつでも何度でも実行できます。この特性を活用して、プログラムの修正のたびにテストを自動的に実施し、もし修正したプログラムに誤りがある場合（退行：以前は動作していたプログラムが動作しなくなること。デグレード、略してデグレとも呼ぶ）、即時に検出される仕組みを導入することが可能になります。
この考え方、仕組みは継続的インテグレーション（CI）と呼ばれ、CIを支援するさまざまなツールがオープンソースで提供されています。
テストの際気をつけるべきポイント
実際にテストを行う際、どのようなことに気をつければよいのでしょうか。
ソースコード修正時の影響範囲の確認
ブラックボックステストではテストが自動化されないため、ソースコードを修正したら、実施済みのテストケースを再度実施する必要があります。修正のたびに全テストケースを実行していると必要な工数が飛躍的に増大するため、修正による影響範囲を最小にとどめる修正を目指す必要があります。
どのようなテストツールやテストを支援する仕組みがある場合でも、プログラマーの素養として、影響範囲を確認してからソースコードの改修を始める習慣は重要です。この事前確認が迅速かつ正確に実施できるプログラマーは、優秀なプログラマーといえます。
テストケースを作成してからプログラムの実装をする（テストファースト）
作成するプログラムがどのような動作をするのが正解なのかが曖昧なまま実装を進めると、多くの場合は仕様通りには仕上がりません。「テストファースト」という考え方は、プログラム本体を実装する前に先にテストプログラムを作成します。この段階で仕様がわからない箇所があれば確認します。
テストファーストではどう動くべきなのかを詰めてから本体を作成するため、そのあとの本体の実装は答えにあわせてプログラムを書くこととなります。プログラミング能力がある方であればこの作業は難しいことではありません。
また、一度書いたコードがいまいちの場合（保守性が悪い、性能が悪いなど）、プログラムの動作を変えずに改善作業を行うリファクタリングを思い切って実施することが可能です。もし間違えてもテストコードが不具合を教えてくれます。
逆にテストコードがなくブラックボックステストしか実施できない場合、リファクタリング後に人と手を介して再テストが必要になり、工数がかかってしまいます。従って、思い切って改修ができず、改修を見送らざるをえないケースも発生します。
テストコードがなく、ブラックボックステストしか実施できない場合でもテストファーストの考え方を採用することは重要です。用意されているテスト仕様書に目を通しておくことで、正しい実装が把握できるようになります。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
システム開発におけるテストとは？まとめ
テストの主な目的は、バグを検出して改善し、要件を満たしていることを保証することです。また、テストを行うことにより、開発プロセスの改善点を見つけることができたり、テスト担当者の仕様理解度を深めることができたりと、今後のシステム開発のノウハウに活用できる効果が期待できます。システム開発におけるテストは、品質を担保するために重要な工程といえるでしょう。
この記事によって、システム開発成功のお手伝いができましたら幸いです。最後までお読みいただき、ありがとうございました。
