ソフトウエアの品質はユーザーの満足度に直結します。しかし、「バグ」や「欠陥」はどの開発プロセスにも潜むリスク。ではどうすれば、これらの問題を減少させ、高品質なソフトウエアを提供することができるのでしょうか？ 本記事では、開発プロジェクトの成否を決定づけるテスト戦略のルールを解説します。
単体テスト→結合テスト→ユーザーテストが基本の流れ
プロダクトを作り終えたとしても、致命的なバグやエラーがあったり想定通りに動かなかったりと品質に重大な欠陥がある状態では、完成とは言えません。テストは、品質保証のために行う大切な工程です。テスト次第でプロジェクトの成否が決まると言ってもいいでしょう。
テストには複数の段階があります。まず行われるのは、単体テストです。システム開発では基本的に、システム全体を複数のパーツに分け、エンジニアで手分けしてパーツごとに開発を進めます。単体テストでは、「チームAが作ったパーツaはしっかり動くか」「チームBが作ったパーツbは……」というように、個々のパーツが期待通りに動作するかをまず確認します。
単体テストをクリアしたら、次は、結合テストを行います。結合テストでは、パーツをすべて組み合わせて、データがパーツ間で正常に引き継がれるかどうか、画面の連携に不具合はないかなど、システム全体が問題なく動作するかをチェックします。
最後に行うのがユーザーテストで、システムが要件通りのパフォーマンスを本番の使用環境で出せるかどうか、ユーザーが実際にシステムを操作して確かめます。
車の製造過程を例に想像してみてください。エンジン・タイヤ・ボディなどを別々で作ったら、まずはそれぞれテストを行い、品質をチェックします。これが単体テストですね。そのあと、パーツを合体させて一台の車を組み立て、全体の動きをチェックします。もしかしたら鍵の操作がうまく伝わらずエンジンがかからないかもしれませんし、パーツとパーツが接触してカタカタと音がするかもしれません。
このように、パーツ間の連携に問題がないかを見つけるのが、結合テストです。結合テストをパスしたら、次は実際に人間が試乗してみて、アクセルやブレーキが期待通りに動くかどうかを確認します。これが、ユーザーテストです。
組織やプロジェクトによってテストの各フェーズの定義が違ったり、違う名前で呼ばれたり、状況に応じてほかのテストを行ったりすることもありますが、基本的な流れは単体テスト→結合テスト→ユーザーテストであると認識しておけばいいでしょう。
