Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

テスト仕様書の基礎知識 Web開発におけるテスト関連ドキュメントの作成・運用術

  2007/07/30 16:09

皆さんは「テスト仕様書」という言葉から何を連想されますか? 筆者の周囲に訊いてみたところ、「大量の印刷物」「メンテナンスが大変」「結局使われない」「報われない」などなど、総じてネガティブな回答が返ってきました。本当にそうなのでしょうか? それでよいのでしょうか? 本稿ではそれらについて改めて考えてみたいと思います。そして、テストとは何かを踏まえた、上手な「テスト仕様書」の作成・運用のためのコツを紹介していきます。

 (開発の現場 Vol.003より転載)

本稿内容の前提:プロジェクトの特徴

 本稿では、内容をよりわかりやすくお伝えするために、筆者が勤める会社で担当するプロジェクトを例に説明していきます。特徴をまとめると以下のようになります。

  • 言語にはJavaを使用:技術基盤を統一することによって、コンポーネント化を容易にし、再利用性・メンテナンス性を高め、得意分野に特化したスキル向上を図る。
  • J2EEを基盤としたコンポーネントベース開発:サーバー側はJ2EEのアプリケーションサーバーを前提とした標準技術を活用し、コンポーネント化によって柔軟なMVCアーキテクチャを実現する。
  • オブジェクト指向で設計:システム機能を論理的に分割し、各コンポーネントやクラスに責務を割り当てることで、メンテナンスやシステム構築の効率化を図る。
  • Web系のユーザーインターフェイス:ユーザーインターフェイスは、Webが8割。残りの2割はSwingやFlashなどのリッチクライアントを使用。ここ数年は特にWebの開発が増えている。

 以降で説明するテスト手法やドキュメント体系、ドキュメントサンプルに関しては、上記を前提としてお話ししていきます。

編集部注

 本稿は「開発の現場 Vol.003」からの転載記事です。記事の内容は2006年1月執筆時点の情報に基づいております。

テストとは?

 まず、テストとは何かについて考えてみます。

 簡単にまとめると、テストとは「構築したシステムを実際に動かしてみることによってその特性を検証すること」です。

 システムを実際に動かすためには、テストの計画、稼働環境の準備、テストケースの設計、テストデータの作成、ドライバ/スタブの実装、などといった準備が必要になります。またテスト中、そして完了後には、テスト結果を分析し、適切な担当者に報告するという段取りも欠かせません。

テストの目的

 では、テストは何のために実施するのでしょうか? その答えは、その人の役割や立場によりさまざまです(図1)。テストを行う際には、このような種々の目的を達成することに全力を注ぐ必要があります。

図1 : テストに期待すること
図1 : テストに期待すること

 また、システム開発の受注形態もさまざまです。ただ、筆者の経験では「システム開発を依頼する組織」と「完成したシステムを活用する組織」とが別であるケースが多いようです。

 たとえば、基幹系システムを利用するのは「製造会社の業務担当部門」であっても、そのシステムを開発するプロジェクトの依頼自体は、製造会社の子会社である「情報システム会社」から来るという場合があります。このケースでは、筆者の会社を含めて3つの組織が登場しますが、それぞれの組織がプロジェクトに期待していることを理解して、テストの目的を整理するように心がけています。

テストのフェーズ分割

 前述の目的を実現するために、プロジェクトはどのようにテストを進めていくのでしょうか?

 筆者の会社における、プロジェクトの工程分割の代表的な例をもとに検討していきたいと思います(図2)。以下、それぞれのテスト同士の役割や関連についてまとめます。

図2 : プロジェクトの工程分割(例)
図2 : プロジェクトの工程分割(例)
  • 単体テスト

     単体テストは、設計フェーズで定めた仕様に基づいて実装していることを確認するのが目的です。そのため、単体テストは通常、実装者が担当します。単体テストが終わってはじめて「実装を完了した」と言えます。

  • コンポーネントテスト

     このフェーズでは、Javaのコンポーネント単位にテストします。クラスが集まって出来たコンポーネントが、与えられた責務を果たしているかどうかを確認します。コンポーネントテストは、アプリケーション開発チームが担当します。「コンポーネント設計」工程において、コンポーネントの責務が決定していますので、他のコンポーネントとのインターフェイスが正しく機能しているかどうかを確認します。

  • 機能テスト

     このフェーズでは、テストが完了したコンポーネントを結合して、機能面からテストします。機能テストでは、外部設計フェーズで検討した「ユースケース」や「画面仕様」を満たしているかどうか確認します。

  • システムテスト

     機能テストが完了してから、システムを総合的に検証することを「システムテスト」と呼びます。実際の業務に近いテストケースをシステム全体を通して実施します。たとえば、「エンドユーザー管理」「管理者管理」「注文管理」「商品管理」「在庫管理」などのサブシステム単位で機能テストを行った後、これらのサブシステムを横断してシナリオに基づいたテストを実施します。

 その他に、非機能要件を検証するパフォーマンステスト、ストレステスト、障害テスト、運用テストなどが含まれます。ただ、プロジェクトの特性によって作業内容やドキュメント体系が大きく異なるため、この誌面においては深くは取り上げません。

Web開発におけるテスト

 では、Web開発についてさらに掘り下げて、テストの特徴を考えていきましょう。

Web開発が実現するビジネスとは

 はじめに、Web開発が実現するビジネスとはどんなものかをいま一度、振り返ってみます。

  1. ビジネスに直結

     ネットビジネスを取り巻く環境は日々進歩しています。「斬新なアイデアを持った企業や組織が、そのアイデアを一刻も早く形にしてビジネスを開始する」Web開発には、そんな役割が求められています。つまり「開発したシステムが即、ビジネスに直結する」と言えるでしょう。

  2. 短納期・低予算

     Web開発では、そのシステムをなるべく早く市場に投入することが求められ、短納期となります。また、ビジネスの立ち上がり時期にはその効果が100%確実とは言い切れないため、限られた予算に基づく開発となり低予算のケースが多いでしょう。

  3. 小さく始めて大きく育てる

     上記のように、低予算で小さく始めることが多い一方、幸いにしてそのビジネスが成功したときにはユーザーの増大に伴ったシステムの拡張があり得ます。また、当初の想定よりもターゲットを広げるために、システムが提供する機能を追加します。したがって、「小さく始めて大きく育てる」かたちを取るケースが多くなります。

 以上の3つを念頭に、Web開発は進められます。

 ところで最近、筆者が携わったプロジェクトで、「将来的には、“PC端末向けのシステム”と“携帯端末向けのシステム”の両方を構築したい。ただし、当初の開発対象は“PC端末向け”に絞って早めに市場に投入したい」という案件がありました。

 そこで、将来変わる可能性があるのはどこか、変わらないところはどこか、を見極め、それに対応できるアーキテクチャを構築しました。

 つまり、最初は小さくても、将来の可能性を閉ざさない、ということが重要です。その結果が、当該システムを最終的に大きく育てることにつながります。

Web開発のテストで心がける点

 次に、Web開発のテストで心がける点について見てみましょう。

  1. フォーカスを絞る

     低予算・低納期の開発で十分に良い品質の成果物を得るためには、時間や費用・開発者といった資源を効率よく配置する必要があります。ときには、たとえば表1のように機能ごとに優先順位をつけて戦略を立てます。テストにおいてもその戦略に従って人数や規模を調整します。

  2. 効率的な進め方

     基本どおり、定石どおりに一から十まで順番にテストしていけばマネジャーは管理しやすく、品質を確保することも難しくはないでしょう。しかし、Web開発でそれを実現するための費用や時間を確保することは困難です。そこで筆者の会社では、その難点を乗り越える手法として、クラスの役割に応じた適切な観点でテストを実施しています。

  3. 大きく育てるために

     特にWeb開発のシステムでは、一度にすべての機能を開発するのではなく、少しずつ機能を追加していきます。以前の機能がデグレードすることなく、そのまま動作していることを常に保障しながら進めていくため、同じテストを何度も繰り返し行うケースが多くなります。したがって、テストを自動化し、人手を介さずにテストできるように工夫することが有効です。

 以上のような観点に留意して、テストを進めることが大切です。

表1 機能ごとの優先順位づけ
表1 機能ごとの優先順位づけ

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 中村 秀剛(ナカムラ ヒデノリ)

    社会人として最初に配属されたプロジェクトでオブジェクト指向による開発を経験し、その魅力と奥深さに感銘を受けた。その後、言語はJava、システムはWeb系へと移るなか、プロジェクトマネジメントに深く関わるようになる。現在は組織横断的にプロジェクトをサポートするなかで計画立案やリスクマネージメントの重要...

  • マーク・マッギー(マーク・マッギー)

    米国籍の道産子。業界経験が長く、主に日本国内で多くの開発現場にさまざまなロールで参画している。現職ではシステム開発プロジェクトの組織横断的な監視/支援を担当している。ソフトウェア開発について社内のベストプラクティスを収集し、社内の情報共有とプロセス改善を支援している。

バックナンバー

連載:開発の現場スペシャル
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5