結合テストと総合テスト
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
機能をモレなくテストするテンプレート
単体テスト仕様書兼報告書の使い方 図2は「DUNGEON」のテンプレートの「単体テスト仕様書兼報告書」です。単体テスト仕様書兼報告書のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/3/14031.zip）からダウンロードできます（14031.zip/42.7 KB）。 当テンプレートの工夫点を挙げてみます。 1点目は前節で述べた詳細設計書との連携部分です。詳細設計書と別ファイルであるということは、同一ファイルの場合に比べて、作成時の工数増、テスト項目の漏れが発生するリスク増というデメリットがあります。 しかし、詳細設計書から転記しやすいフォーマットにすることでそのデメリットを解消しているのです。構成として、詳細設計書の章立てごとにシートを分けています。なぜならチェックする内容ごとにシートのフォーマットが異なるからです。極力リ
結合テスト仕様書兼報告書のテンプレート
結合テストの範囲 テストフェーズの続きとして、今回は「結合テスト」に焦点を当てます。一口に結合テストといっても、SIerによっては実施範囲が異なると思いますので、まずは本連載で想定している範囲を明確にしておきたいと思います。 この実施範囲の差は何を「結合」するかという単位の違いによるものです。最小単位のプログラムを複数結合してテストするのか、それとも画面間の結合なのか、または業務手順の結合なのかということです。もちろんこの違いは、開発手法やシステム構成、開発言語、プロジェクト管理手法など、さまざまな要因によって決まるものですし、また、その単位でしかテストしないわけではなく、どこに重きを置くかの差でもありますので、一概にどれが正解とは言い切れません。 今回紹介する「DUNGEON」テンプレートは、ウォーターフォールでの業務システム構築が守備範囲です。したがって本連載で説明する結合テストは、業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
