SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

テンプレートから学ぶ 受注する開発者のためのテスト仕様書

開発工程とテスト
― 単体/統合/受入/システム/回帰テスト

開発者のためのテスト仕様書テンプレート(5)

  • X ポスト
  • このエントリーをはてなブックマークに追加

1.2. システムテスト

 これまでの解説は「図1:開発工程」をもとにしています。受入テストまで済んでいますから、それで開発は終了して良いと思うかもしれません。しかし、なかなかそうはいきません。保守があるからです。

1.2.A. 保守

 例えば、図4のような人事システムの中の勤務管理サブシステムを開発するとしましょう。今回、全面的に書き直すので新規開発という扱いです。プロジェクト計画を立て、予算を獲得し、プロジェクト開始です。新規開発なので、前節で述べた開発工程が当てはまると思うかもしれません。

図4:「人事システム・勤務管理サブシステム」
図4:「人事システム・勤務管理サブシステム」

 人事システムを良く見てみると、実は図5のように、他のサブシステムがたくさんあることが分かります。これらのサブシステムは勤務管理サブシステムと様々なインターフェースを持っています。

図5:「人事システム・勤務管理サブシステムを取り巻く他のサブシステム」
図5:「人事システム・勤務管理サブシステムを取り巻く他のサブシステム」

 勤務管理サブシステムが新規開発の扱いだからと言って、他のサブシステムとのテストをしないで済ませるわけにはいきませんね。

 もちろん、勤務管理サブシステムを開発するにあたって、影響分析を行っています。この場合、給与、労務管理、情報検索という3つのサブシステムで影響が出ると思えるところは織り込み済みです。

 影響分析は、「人」および「機械」の両方で行います。人は有識者とも言われ、そのシステムを良く知っている人です。勤務管理サブシステムと他のサブシステムとのインターフェースを熟知している(ことになっている)人です。

 機械的な分析では、プログラムの中なら変数をもとに影響範囲を辿っていきます。プログラムの外ではデータベースの定義などをもとにして影響分析します。

 残念なことに、どちらの影響分析にしても、100パーセント信頼して良いわけではありません。人も機械も限界があるのです。従って、システムテストを行う必要があるのです。

1.2.B. システムテスト

図6: システム・テスト
図6: システム・テスト

 図6にシステム・テストの模式図を描きました。図の

「仕様」→「開発工程」→「成果物」

は要件仕様から始まる新規開発部分(保守の用語で「完全化保守(perfective maintenance)」という部分)です。四角で囲んだ成果物の周りに青い楕円の部分があります。これは影響分析を行った結果、対応するべき開発部分(保守の用語で「適応保守(adaptive maintenance)」という部分)です。

 システム・テストはそのさらに外側の部分をテストします。

1.2.C. 回帰テスト

 システム・テストを行うのは「サブシステム(勤務管理サブシステム)に手を入れたのだから、いくら影響分析しても漏れがあるだろう。きっとシステム全体(人事システム)の品質が劣化しているに違いない」というところから出発しています。これは慎重かどうかという担当者の気持ちや性格に依るわけではなく、ソフトウェアを開発して本番稼働してみたら本番障害が出たというたくさんの事実から学んでいることなのです。

 この品質の劣化が起こっていないかどうかを確認するテストがシステム・テストなのです。システムが退行(regression、リグレッション)していないかどうかを確認するので、リグレッション・テスト、または、回帰テストとも言います。

2. まとめ

 開発工程とテストの復習をしました。

「要件定義」→「設計」→「実現」→「単体テスト」→「統合テスト」→「受入テスト」

がどういう性質のものなのかを簡潔に学びました。

 現場では保守が一般的であることから、システム・テストをすることと、システムが退行していないかどうかのテストとして回帰テストがあることも学びました。

参考文献

  1. SEのためのソフトウェア・テストの基本』 山村吉信 著、翔泳社、2003年12月
  2. IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
  3. IEEE Std 829-1998 IEEE Standard for Software Test Documentation
  4. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications
  5. IEEE Std 1016-1998 IEEE Recommended Practice for Software Design Descriptions
  6. CodeZine 『テンプレートから学ぶ受注する開発者のためのテスト仕様書(1)』 山村吉信 著、2009年7月
  7. CodeZine 『テンプレートから学ぶ受注する開発者のためのテスト仕様書(2)』 山村吉信 著、2009年8月
  8. CodeZine 『テンプレートから学ぶ受注する開発者のためのテスト仕様書(3)』 山村吉信 著、2009年9月
  9. CodeZine 『テンプレートから学ぶ受注する開発者のためのテスト仕様書(4)』 山村吉信 著、2009年10月

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
テンプレートから学ぶ 受注する開発者のためのテスト仕様書連載記事一覧

もっと読む

この記事の著者

山村 吉信(ヤマムラ ヨシノブ)

同志社大学大学院・電気工学専攻修了(工学修士)。プリンストン大学大学院・計算機科学科修了(MSE)。1978年、日本アイ・ビー・エム(IBM)入社。システムズ・エンジニア(SE)として、性能評価モデルの営業支援に従事。1983年、IBMサイエンス・インスティチュート(現東京基礎研究所)にて研究員とし...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4566 2009/11/16 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング