第1回：テストをどう考えていますか？：特集：理論的・計画的なWebアプリケーションのテストの実現（1/2 ページ）

近年のWebアプリケーション開発におけるテストは、クライアント・サーバシステムと比べ、数倍の難しさを持っているといえる。同特集では、Webアプリケーションをいかに効率よく、かつ計画的にテストしていくかを解説していく。第1回となる今回は、テストをどう考えるのかというテーマで話を進めていこう。

[加藤大受，ITmedia]

はじめに

　最近ではアプリケーションの開発というとWebアプリケーションの開発を指すことが多い。細かくいうと、Webアプリケーションは多層アプリケーションでクライアントがブラウザになっている構成といえるが、このWebアプリケーション開発におけるテストを考えた場合、数年前までは一般的だったクライアント・サーバシステムと比べ、テストは数倍の難しさを持っていると筆者は感じている。

　ではなぜWebアプリケーションのテストは難しいのだろうか？　これを説明するにはまず、テストをどう考えるかということから説明する必要がある。「テストなんてアプリケーションができてからテスト仕様書を作って一気に作業してしまえばいいのではないか」と考える方もおられるかもしれない。しかし、筆者の経験からいっても、アプリケーションのテストはもっと理論的かつ計画的であり、難しいものであるといえる。

　また、テストは後ろ向きのイメージであったり、テストはプログラマーやSEに比べ技術レベルが低いテスターが行うイメージのものであったりという考えを持つ方もおられるだろう。しかし、テストエンジニア（テスターではない、テスターとテストエンジニアの違いは別途解説）がカバーする範囲は普通のプログラマーがカバーするよりも広い知識をが要求されることも往々にしてある。

　本稿では、Webアプリケーションをどうやって効率よく、かつ計画的にテストしていくかについて、テストの解説や効率よくテストを実現するためのツールなどを紹介しながら説明していく。第1回となる今回は、テストはどう考えるのかというテーマで話を進めていこう。

いつからテストをはじめるのか

　「テストはどこからはじめると思いますか？」と、開発者に問いかけた場合、返ってくる回答は次の3つに大別できるように思われる。

1. アプリケーションの開発が終了したときから
2. アプリケーションの各モジュールが終了したときから
3. コーディングを行うときから

　1の回答は、すべての実装を終了してから各機能のテストを行っていくということだろう。この場合、開発し終わったアプリケーションに設計上の問題が発覚した場合、大がかりな変更が必要となる可能性がある。また、一般的に最後にまとめてテストを行う場合は、すでに実装部分でほとんどのスケジュールを消費してしまい、本来テストに必要な工数が確保できないというリソースの問題が発生することが多いのも現状である。

　2の回答は、モジュールごとに単機能の検証を行い、その後結合試験を行うという流れでテストを実施されている方であると考えられる。モジュールごとに検証されているため、1の回答のように、最後にすべての機能を検証する場合と異なり、設計の問題が発生したとしても、それが根底の問題ではない限り、各モジュール内の検証および不具合修正で解決されるはずである。また、結合試験によってモジュール間の連携も検証でき、それなりにテストされているというイメージが確立できるのではないだろうか。

　しかし、実際には各モジュールで品質レベルが異なったり、各コンポーネントが検証されているため、結合試験がおろそかにされることも多いのではないだろうか。あるいは各単機能の検証に時間を取られてしまい、アプリケーションが稼働する環境での検証に時間を割けない状況になっていることもあるだろう。

　3の回答は、最近注目されているテスト駆動型開発（TDD)やエクストリーム・プログラミングのテストファーストを実施されている方だと思われる。小規模なプロジェクトの場合、テストファーストで開発していくのもよいが、大規模なプロジェクトでテストファーストを実施すると、仕様書が明確にできあがっていないため（テストコードという仕様書は存在するが）、全体の進ちょくや仕様書の管理ができない問題が発生することがある。もちろん、きちんと詳細設計書まで作成してテストファーストを実施していればこのような問題は発生しないが、テストファーストのコンセプトを「いきなりテストケースのコーディング」と理解している方は、見事に仕様書の整備や将来拡張時の問題に遭遇することだろう。

テストのあるべき姿

　では、テストはいつからはじめるべきか？　筆者はシステムの設計のタイミングからテストを実施するのが理想だと考える。つまり、要件定義から常にテストを意識していくということだ。

　テストは実際にテスト仕様書を作成してテストを実施することだと思いがちだが、設計書レベルのレビューもテストの一部といえる。たとえば、筆者の勤めている会社では、プログラマーとテストエンジニアは別組織となっており、設計のフェーズからテストエンジニアも参加し、テスタビリティ（テストしやすさ）の面やテストにかかる工数の面からアプリケーションの設計に携わる。テストを考慮することでテスト工数の不足やテストしづらい設計になるリスクを軽減するようにしているのだ。もちろんこのレビューに参加するテストエンジニアには上級プログラマに近い開発方法論や各プログラミング言語の特徴などの知識が必要であることは言うまでもない。

　このようなテスタビリティを考慮した方法は、プログラマーだけからなるプロジェクトであっても、テストの面から設計をレビューする担当者を設定することで同じような役割を実現できるといえる。ペアプログラミングをしながらテストについても指摘しながら進めていく方法でも問題ないだろう。

次ページはテストは何回行うべきか、またテストに必要な知識とは？