システム開発におけるテストエンジニアの重要性とは

システムやアプリケーションの開発現場で花形といえば、プログラマーやシステムエンジニアでしょう。しかし、その陰であまり目立たないものの、開発の成功に欠かせないのが、「テストエンジニア」の存在です。

設計通りにプログラミングが行われても、多くの場合バグが発生します。もしその不具合に気づかずにリリースしてしまったら、どうなるでしょう。ユーザーからの信用を失うのみならず、クライアントにも多大な損害を与えることになりかねません。それを阻止するのが、テストエンジニアの仕事です。

そこで今回は、テストエンジニアの具体的な役割や重要性についてまとめました。

テストエンジニアの仕事と重要

テストエンジニアとは、システムやアプリ、IT製品などが、クライアントの要望や設計通りに動作するかを確認するエンジニアのことです。

設計が完璧でも、プログラミングの過程でミスがあれば、バグが発生します。設計自体にクライアントの意図に沿わないミスが含まれていることも考えられます。そのまま製品化してしまうと、ユーザーに多大な迷惑がかかるだけでなく、クライアントとともに開発者自身も信用を失墜し、損害賠償を求められる恐れもあります。

Webシステムやアプリは、一旦リリースすると想定外の操作により不具合が生じることもあれば、アクセスが過度に集中してシステムダウンを起こすケースもあります。重大なバグやパフォーマンスの低下は、多数のユーザー離れや数百万、数千万円単位の損失を引き起こしたり、多額の修正費用がかかったりする可能性もあります。そのような事態を回避するためにも、正式なリリース前にテストエンジニアが入念なテストを行う必要があるのです。

想定されるすべてのケースを洗い出し、テストエンジニアが一つひとつテストを実施して設計ミスやバグを見つけ出します。その原因を分析のうえ報告すると、それをもとにプログラマーやシステムエンジニアが修正をおこないます。

プロダクトの作り手は、ミスが生じないように注意を払いますが、それでもやむを得ずミスに気づかないことがあります。そこをテストエンジニアが第三者の立場で確認することで、思いもよらない不具合を発見できることがあるのです。プロダクトの品質を大きく左右するだけでなく、リスク管理という意味からも、システム開発におけるテストエンジニアの重要性は計り知れないといえるでしょう。

テストエンジニアが行うテストとは

システム開発の流れは、大まかにいうと、

『要件定義→外部設計→内部設計→プログラミング→単体テスト→結合テスト→システムテスト→運用テスト→リリース→運用・保守』となります。

このプロセスの内、「単体テスト」「結合テスト」「システムテスト」が、テストエンジニアが担当する主なフェーズとなります。それぞれについて、具体的に説明しましょう。

単体テスト

単体テストは「モジュールテスト」や「ユニットテスト」ともいいます。プログラム全体ではなく、それを構成する小さな単位（モジュール）が正常に機能するかどうかを確認する工程を意味します。

例えば、ユーザーの生年月日から、AとBの2グループに分けて、グループごとに異なる試供品をプレゼントするというサービスを想定しましょう。単体テストでは、ユーザーが生年月日を入力して、確実にAかBへの振り分けができるか、といった基本的な動作を確認します。もし「1800年生まれ」といった現実にはあり得ないデータが入力された場合に、エラー表示できるか、なども単体テストの対象になります。

単体テストは、各モジュールが結合される前に行われるため、早い段階で不具合が発見できるメリットがあります。すべてのプログラムが設計通りに機能しているかを、プログラムの内部から確認する「ホワイトボックステスト」と、ユーザー目線に立って画面表示やユーザーインターフェースなどに不具合が無いか、外部からチェックする「ブラックボックステスト」の主に2通りの方法があります。

結合テスト

単体テストをパスしたモジュールやユニットを結合した際に、意図した通り機能するかを確認するのが、結合テストです。

上記の例で言うと、

ユーザーによって生年月日が入力される→AかBにグループ分けされる→製造工場に試供品の数量をグループ別に指示→宛名や住所がプリントされて自動梱包される→出荷指示を出す

といった一連の流れが滞りなく確実に行われるかをテストする、という具合です。

結合テストの種類には、モジュール間やサブシステム間の結合状態を確認する「内部結合テスト」と、外部システムと結合した際の動作確認をする「外部結合テスト」があります。

結合テストの方法としては、重要度の高い上位モジュールを呼び出してから、下位モジュールを順次呼び出す「トップダウンテスト」。その逆で下位モジュールから一つずつテストして問題なければ上位モジュールに結合してテストを繰り返す「ボトムアップテスト」の2通りに大別でます（他に、上位、下位の別なくモジュールを結合したうえで行う「ビッグバンテスト」という手法もありますが、問題が発覚しても原因の特定が困難なため多用されません）。

システムテスト

単体テスト、結合テストを経て、問題がすべてクリアーされたら、いよいよ本番を想定した環境で最終的なシステムテストを行います。「総合テスト」と呼ぶこともあります。

ソフトウェアだけでなくハードウェアも含めて、実際に使われる環境と同じ条件でテストするので、システム全体を俯瞰したうえで不具合が検出できます。ここで確認された動作レベルがそのまま製品の品質となるので、クライアントの要望通りのシステムが稼働するかを厳しくテストするのが、システムテストのミッションです。

テストエンジニアの業務プロセス

テストエンジニアがどの様なプロセスでテスト業務を遂行していくのか見ていきましょう。

テスト計画

テストに向けた準備の第一歩は、テスト計画書の作成です。テストの目的や範囲、環境や人員（テストエンジニア）のリソース、終了基準、そして全体のスケジュールなどを文書化し、関係者が共有できるようにします。

具体的には、「全体テスト計画書」と「個別テスト計画書」があります。

「全体テスト計画書」は、単体テストや結合テスト、システムテストなど、各テストレベルの定義や方向性、全体のスケジュールについてドキュメントにまとめたものです。

一方、「個別テスト計画書」には、全体テスト計画書で定められた各テストレベルにおける環境や要員、スケジュールを詳しくまとめます。テストといっても、誰がどの様な方針で行うかによって、そのクオリティは千差万別です。中には、時間短縮のためにテストそのものを省略したり、大幅にプロセスを削減したりすることもあります。

せっかくテストを行っても、漏れがあれば後々重大な問題につながりかねません。よって、個別テスト計画書は、各テスト項目の漏れをなくすべく、進捗状況を逐一確認できる書式にしておく必要があります。

テスト設計

テストエンジニアは、テスト設計書をもとに具体的にテストを遂行していきます。よって、テスト設計では、プロジェクトやプロダクト作成の背景、具体的な目的を正確に明記し、プロダクトにどの様な機能があり、それらをどの様な技法を使ってテストするのか、手順も含めて細かく定めます。

この際、参考となるのが、要件定義書です。

要件定義書にはクライアントの要望が記載されているので、これをもとに、どの機能をどの様な切り口（テスト観点）でテストするべきかを逐一定義していきます。この段階で必要のない機能を洗い出すこともできるため、無駄をそぎ落とし、プロダクトの品質を向上させるうえで非常に重要な工程になります。よって、テスト観点の的が外れていないか、漏れがないかを要件定義書作成者に確認し、フィードバックしてもらうという方法をとる場合もあります。

テストエンジニアは、IT機器メーカーやシステム開発業者の社員である場合もあれば、テストのためだけにアサインされるケースもあります。よって、テスト設計書に不明確な点があると、テストエンジニアのタスクが定まらなかったり、テスト業務の質が下がったりします。その意味では、テスト設計書のクオリティが、プロダクトの品質を最終的に決定するといっても過言ではありません。

テスト実施

テスト計画書やテスト設計書の内容にそって、実際にテストを実施します。単体テストの次が結合テスト、それが済めばシステムテストに移ります。この後にも「受け入れテスト」や「運用テスト」がありますが、「受け入れテスト」は、基本的に開発を依頼したクライアントが品質を確かめるために行うものです。もちろんそこで不具合が指摘されれば、開発担当のエンジニアが責任をもって修正する必要があります。

さらに「運用テスト」は、プロダクトをリリースする状況下での最終確認とデモンストレーションの場です。これが済んだら、いつでもリリース可能ということです。