オブジェクティブグループ

ベンダーから「〇〇テスト完了」と言われたら？テスト段階まとめ

Last updated at 2026-01-22Posted at 2026-01-22

1. はじめに

1-1. この記事の目的

開発プロジェクトで「結合テスト完了しました」「システムテスト開始します」といった報告を受けることは日常的ですが、その実態を正しく理解できているでしょうか。
私は判断に困ることや、質問された際に回答に詰まることが何度かありました💦

よくある悩み：

ベンダーから「結合テスト完了」と報告を受けたが、何を確認すべきか分からない
「システムテスト」と「総合テスト」の違いが曖昧
お客様と一緒にやるテストはどの段階からなのか判断できない

今回は、テストの各段階について体系的に整理し、実務での判断基準をまとめてみました。

1-2. 想定読者

保守業務やベンダー管理を担当している方
受け入れテストの計画・実施経験がある方
テスト仕様書のレビューを行う立場の方
開発経験は浅いが、テスト品質管理を求められている方

1-3. テストの重要性

品質の高いシステムを構築するためには、適切なテスト戦略が不可欠です。
各テスト段階の目的と範囲を正しく理解することで、以下のメリットがあります。

不具合の早期発見・早期修正
テストの重複や漏れの防止
ベンダーとの認識齟齬の解消
適切なリソース配分とスケジュール管理

2. テスト段階の全体像

2-1. テストの流れ（つながりを理解する）

2-2. 各段階のつながり

段階	何をつなぐか	何が変わるか
単体テスト → 結合テスト	個々のモジュールを結合	単独の動作 → 連携の動作
結合テスト → システムテスト	モジュールをシステム全体に統合	部分的な確認 → 全体的な確認
システムテスト → 受け入れテスト	技術検証からユーザー検証へ	仕様通りか → 使えるか

2-3. 対応する開発工程（V字モデルの考え方）

各テスト段階は、開発工程と対応関係があります。

開発工程	対応するテスト段階	何を確認するか
実装	単体テスト	コードが正しく書けているか
詳細設計	結合テスト	設計通りに連携するか
基本設計	システムテスト	設計した機能が実現できているか
要件定義	受け入れテスト	要件を満たしているか

ポイント：開発の早い段階で決めたことは、後のテストで確認します。

3. 各テスト段階の詳細

3-1. 単体テスト（Unit Test）

定義

プログラムの最小単位（関数、メソッド、クラス等）が正しく動作するかを確認するテスト。

目的

個々のコードが仕様通りに動作することを保証
不具合の早期発見
修正時の品質保持（回帰テスト）

実施者

開発者（プログラマー）

確認内容

関数・メソッドの入出力
個別のロジック
データ変換処理
計算処理

テストの観点

正常系：期待される入力に対して正しい出力が得られるか
異常系：不正な入力に対して適切なエラーハンドリングがされるか
境界値：最小値・最大値・境界付近の値で正しく動作するか

成果物

単体テスト仕様書
テスト実行結果レポート
テストコード（自動テストの場合）

具体例（テストケース）

対象機能：会員種別に応じた割引計算

ケースID	入力値（価格）	入力値（会員種別）	期待結果	テスト観点
UT001	1000	プレミアム会員	800（20%割引）	正常系
UT002	1000	一般会員	900（10%割引）	正常系
UT003	1000	非会員	1000（割引なし）	正常系
UT004	0	プレミアム会員	0	境界値（最小値）
UT005	-100	プレミアム会員	エラー発生	異常系（負の値）

3-2. 結合テスト（Integration Test）

定義

複数のモジュール・コンポーネントを組み合わせて、連携部分が正しく動作するかを確認するテスト。

目的

モジュール間のインターフェースの整合性確認
データの受け渡しが正しく行われることの確認
外部システムとの連携確認

実施者

開発者（主担当）
テスト担当者（必要に応じて追加）

確認内容

モジュール間のデータ連携
API呼び出しとレスポンス
データベースとの連携
外部システムとのインターフェース
画面とバックエンドの連携

テストの観点

インターフェース仕様：定義通りにデータが渡されるか
データ整合性：データが正しく保存・取得されるか
エラー伝播：エラーが適切に伝達されるか
トランザクション：複数処理の整合性が保たれるか

成果物

結合テスト仕様書
テストデータ
テスト結果報告書
エビデンス（ログ、DB確認結果、APIレスポンス）

具体例（テストケース）

対象構成：

[フロントエンド] → [バックエンドAPI] → [データベース]

ケースID	テスト内容	確認ポイント
IT001	ユーザー登録API → DB登録確認	APIが200を返し、DBにデータが保存される
IT002	ユーザー一覧API → DB取得確認	DBの全レコードがJSON形式で返される
IT003	重複メール登録 → エラー確認	APIが400を返し、エラーメッセージが適切
IT004	フロント → API → DB 一連の流れ	画面入力からDB保存まで正常に動作
IT005	トランザクション処理	エラー時にロールバックされる

3-3. システムテスト（System Test）

定義

システム全体が要件通りに動くかを確認するテスト。
「ちゃんと作った通りに動くか？」をチェックします。

目的

システム全体の動作確認
要件定義書・基本設計書との整合性確認
業務フロー全体の実現性確認
非機能要件（性能、セキュリティ等）の確認

実施者

テスト担当者（主担当）
- ※開発者が兼任する場合や、専任者を追加する場合がある
発注側（重要機能の確認）

確認内容

業務フロー全体の動作
画面遷移
マスタデータ管理
帳票出力
バッチ処理
性能（レスポンスタイム）
セキュリティ（認証・認可）
運用面（バックアップ、リカバリ）

テストの観点

機能要件：要件定義で定めた機能が実現されているか
業務シナリオ：実業務の流れを想定したテスト
非機能要件：性能、可用性、セキュリティ等
運用性：ログ出力、エラーハンドリング、監視

成果物

システムテスト仕様書
テストシナリオ
テストデータ（マスタ、トランザクション）
テスト結果報告書
エビデンス（スクリーンショット、ログ、帳票サンプル）
性能試験結果（該当する場合）

具体例（業務シナリオ）

業務フロー：ECサイトの注文処理

ステップ	操作内容	期待結果
1	ログイン	会員情報が表示される
2	商品検索	条件に合う商品が一覧表示される
3	商品詳細確認	在庫数、価格が正しく表示される
4	カートに追加	カート内の商品数が更新される
5	注文確認画面へ	合計金額が正しく計算される
6	配送先入力	バリデーションが機能する
7	決済処理	決済API連携が成功する
8	注文完了	注文番号が発行される
9	確認メール送信	注文内容が記載されたメールが届く
10	管理画面確認	注文情報が管理画面に反映される

その他のテストケース例

カテゴリ	テスト内容
機能テスト	上記業務シナリオの実施
性能テスト	100ユーザー同時アクセス時のレスポンスタイム
セキュリティテスト	SQLインジェクション対策の確認
運用テスト	ログ出力内容の妥当性確認

3-4. 受け入れテスト（User Acceptance Test）

定義

ユーザー（発注者、エンドユーザー）の視点で、システムが実際の業務で使用できるかを確認するテスト。

目的

ユーザー要件が満たされているかの最終確認
実業務での運用可能性の検証
システムの受け入れ判断

実施者

発注側担当者（主担当）
エンドユーザー代表
ベンダー（支援・立ち会い）

確認内容

実業務での使用感
操作性・ユーザビリティ
業務要件の充足
帳票の内容・レイアウト
運用手順の妥当性
既存システムからの移行確認

テストの観点

業務適合性：実業務で問題なく使えるか
使いやすさ：ユーザーが迷わず操作できるか
業務効率：業務が効率化されるか
運用性：運用担当者が管理できるか

成果物

受け入れテスト仕様書
実業務に即したテストシナリオ
テスト結果報告書
受け入れ判定書
指摘事項一覧（あれば）

具体例（受け入れテストシナリオ）

業務：勤怠管理システム

シナリオID	業務内容	確認ポイント
UAT001	月初の勤怠締め処理	前月分のデータが正しく締められる
UAT002	有給申請 → 承認	申請から承認までの流れが業務フローに合致
UAT003	残業時間の集計	労働基準法に則った計算がされている
UAT004	給与システムへのデータ連携	既存の給与システムにエラーなく取り込める
UAT005	管理者による勤怠修正	権限を持つ者のみが修正でき、ログが残る

チェックポイント

画面の文言が業務用語として適切か
ボタンの配置が使いやすいか
印刷帳票のレイアウトが実用的か
エラーメッセージが分かりやすいか

4. シナリオテストの位置づけ

4-1. シナリオテストとは

実際の業務フローやユースケースに沿って、一連の操作を通して行うテスト手法です。

4-2. どこで使われるか

シナリオテストは、システムテストと受け入れテストの両方で使われます。

段階	観点	シナリオ作成者	実施者
システムテスト	技術的な観点での業務フロー確認	要件定義書ベース	テスト担当者、開発者
受け入れテスト	ユーザー視点での実業務確認	実業務ベース	ユーザー、発注側

4-3. システムテストでのシナリオテスト例

シナリオ：新規顧客の初回取引

1. 顧客マスタ登録
2. 与信審査申請
3. 与信限度額設定
4. 受注入力
5. 在庫引当
6. 出荷指示
7. 請求書発行

確認観点：各機能が連携して正しく動作するか

4-4. 受け入れテストでのシナリオテスト例

シナリオ：経理担当者の月次処理

1. 前月分のデータ確認
2. 未処理の伝票チェック
3. 決算仕訳の入力
4. 試算表の出力
5. 前年同月との比較
6. 月次報告書の作成

確認観点：実業務で問題なく運用できるか

5. 比較表（まとめ）

5-1. 各テスト段階の比較

項目	単体テスト	結合テスト	システムテスト	受け入れテスト
対応する開発工程	実装	詳細設計	基本設計	要件定義
主な実施者	開発者	開発者	テスト担当者・発注側	発注側・ユーザー
テスト範囲	関数・メソッド	モジュール連携	システム全体	実業務全体
テストの観点	コードの正確性	インターフェース整合性	要件充足	業務適合性
環境	開発環境	開発・検証環境	検証環境	本番相当環境
自動化適性	高い	中程度	中程度	低い

5-2. 成果物の比較

テスト段階	主な成果物
単体テスト	テスト実行結果レポート、テストコード
結合テスト	テスト仕様書、APIテスト結果、ログ
システムテスト	テストシナリオ、スクリーンショット、性能試験結果
受け入れテスト	受け入れ判定書、指摘事項一覧

6. ベンダー受け入れ時のチェックポイント

6-1. テスト仕様書のレビューポイント

6-1-1. テストケースの網羅性

確認項目

要件定義書・基本設計書との対応が取れているか
全ての機能がテストケースに含まれているか
正常系だけでなく、異常系も網羅されているか
境界値テストが含まれているか
非機能要件（性能、セキュリティ等）のテストが含まれているか

確認方法

要件一覧とテスト仕様書を突合せ
↓
各要件に対応するテストケースを確認
↓
カバレッジを算出（例：要件100項目中95項目 = 95%）

6-1-2. テスト条件の妥当性

確認項目

前提条件が明確に記載されているか
実業務を想定したテストデータか
テスト手順が具体的で再現可能か
期待結果が明確に定義されているか

注意すべき記述

曖昧な表現（例：「正常に動作すること」）
前提条件の記載漏れ
非現実的なテストデータ（例：全角100文字の名前）

6-1-3. レビューチェックリスト

項目	確認内容	OK/NG
網羅性	全要件がカバーされているか	□
正常系	基本的な操作フローが含まれているか	□
異常系	エラーケース、例外処理が含まれているか	□
境界値	最小値、最大値、境界値のテストがあるか	□
性能	性能要件のテストが含まれているか	□
セキュリティ	認証、認可、脆弱性のテストがあるか	□
運用	ログ、監視、バックアップのテストがあるか	□

6-2. エビデンスの確認ポイント

6-2-1. エビデンスの種類

必須のエビデンス

スクリーンショット（画面系機能）
ログファイル（バッチ処理、API）
データベース確認結果（データ登録・更新）
帳票出力サンプル（帳票機能）
APIレスポンス（APIテスト）

6-2-2. 確認すべき点

テストケースとエビデンスの対応

各テストケースに対してエビデンスが揃っているか
テストケース番号とエビデンスのファイル名が対応しているか
欠番がないか

日時の整合性

エビデンスの日時がテスト実施日と整合しているか
スクリーンショットのタイムスタンプが連続しているか
古いエビデンスの使い回しがないか

期待結果との一致

スクリーンショットの表示内容が期待結果と一致しているか
エラーメッセージが仕様書通りか
計算結果が正しいか

エビデンスの品質

スクリーンショットが鮮明か（文字が読めるか）
必要な情報が全て写っているか
ログが途中で途切れていないか

6-3. テスト結果報告書の確認

6-3-1. 実施状況の確認

テスト実施率

実施率 = 実施済みテストケース数 / 全テストケース数 × 100%

確認項目

実施率が100%に達しているか
未実施のテストケースがある場合、その理由が明記されているか
スキップしたテストケースの妥当性

実施率が100%でない場合

理由を確認（環境問題、仕様変更、優先度判断等）
未実施のリスクを評価
必要に応じて追加実施を要求

6-3-2. 不具合の状況

不具合の分類

重要度	定義	対応
致命的	システムが動かない、データ破損	即時対応必須
重大	主要機能が使えない	リリース前に対応
軽微	一部機能の不具合、回避策あり	次回リリースで対応可
改善要望	使い勝手の問題	優先度を判断

確認項目

不具合の総数
重要度別の内訳
未解決の不具合の数と内容
修正完了した不具合の再テスト結果

不具合トレンドの確認

発見数の推移をグラフ化して傾向を把握：

Week1: 20件
Week2: 35件（ピーク）
Week3: 15件
Week4: 5件（収束傾向）

収束していない場合は品質に懸念あり。

6-4. よくある抜け漏れ

6-4-1. 非機能要件のテスト

抜けやすい項目

性能テスト（レスポンスタイム、スループット）
負荷テスト（同時アクセス数）
セキュリティテスト（脆弱性診断）
可用性テスト（障害時の挙動）
保守性テスト（ログ出力、監視）

6-4-2. 例外処理のテスト

抜けやすいパターン

ネットワーク切断時の挙動
外部APIがタイムアウトした場合
データベース接続エラー
ディスク容量不足
不正なデータ形式の入力

6-4-3. 操作ログ・監査ログの確認

確認項目

ログイン・ログアウトが記録されるか
データの作成・更新・削除が記録されるか
ログに必要な情報が含まれているか（ユーザーID、操作内容、日時）

セキュリティインシデント時や監査対応で重要になります。

6-4-4. 帳票・出力系のテスト

抜けやすい確認項目

帳票のレイアウト（実際に印刷して確認）
大量データ時の改ページ
印刷プレビュー
PDF出力時の文字化け
Excel出力時のフォーマット

7. テスト計画の立て方（基本）

7-1. テストの実施順序

基本的な流れ

単体テスト → 結合テスト → システムテスト → 受け入れテスト

各段階での品質基準（例）

テスト段階	合格基準（例）
単体テスト	テスト実行成功率80%以上、致命的不具合0件
結合テスト	全テストケース合格、重大不具合0件
システムテスト	要件カバレッジ100%、致命的・重大不具合0件
受け入れテスト	ユーザー承認、運用支障なし

次の段階に進む判断基準

全テストケースの実施完了
致命的・重大な不具合が解決済み
軽微な不具合の対応方針が決定済み
テスト報告書が承認済み

7-2. 外部委託時の考え方

7-2-1. 一般的な分担

開発を外部に委託した場合の分担例：

テスト段階	ベンダー側	発注側
単体テスト	◎ 実施・報告	-
結合テスト	◎ 実施・報告	△ 重要機能の立ち会い
システムテスト	◎ 実施・報告	○ 一部参加・確認
受け入れテスト	△ 支援・立ち会い	◎ 実施・判定

記号の意味

◎：主担当
○：副担当・一部実施
△：支援・立ち会い
-：関与しない

7-2-2. お客様と一緒にやるテストはどこから？

システムの重要度、契約形態、お客様のIT習熟度によって異なります。

パターンA：システムテストから参加

段階	担当
単体テスト	ベンダー単独
結合テスト	ベンダー単独
システムテスト	お客様参加開始
受け入れテスト	お客様主導

適用ケース

システムの重要度が高い
お客様がITに詳しい
早い段階から品質を確認したい

お客様の関わり方

重要機能のテストケース確認
テスト実施の立ち会い
テスト結果の確認

パターンB：受け入れテストのみ参加

段階	担当
単体テスト	ベンダー単独
結合テスト	ベンダー単独
システムテスト	ベンダー単独
受け入れテスト	お客様参加開始

適用ケース

小規模システム
ベンダーとの信頼関係が確立している
お客様のリソースが限られている

お客様の関わり方

ベンダーからのテスト報告書を確認
受け入れテストを実施
最終的な受け入れ判定

パターンC：結合テストの一部から参加

段階	担当
単体テスト	ベンダー単独
結合テスト	重要機能はお客様参加
システムテスト	お客様参加
受け入れテスト	お客様主導

適用ケース

基幹系システム、金融系システム
既存システムとの連携が重要
法規制対応が必要

お客様の関わり方

重要な外部連携のテストに立ち会い
データ移行テストに参加
全体的なテスト品質の監視

7-2-3. 判断基準

お客様がどの段階から参加すべきかの判断基準：

判断要素	システムテストから	受け入れテストのみ
システム重要度	高い（基幹系）	低い（部門系）
お客様のIT習熟度	高い	低い
リソース	十分	限定的
契約形態	準委任・ラボ型	請負
過去のトラブル	あり（慎重に）	なし（信頼）
法規制	厳しい（金融等）	緩い

7-3. リソース配分の考え方

7-3-1. 各テスト段階の工数比率（目安）

テスト段階	工数比率	備考
単体テスト	20-25%	自動化で削減可能
結合テスト	25-30%	APIテストなど
システムテスト	30-35%	最も工数がかかる
受け入れテスト	15-20%	手動中心

※プロジェクトの性質によって変動します

7-3-2. 誰をアサインするか

テスト段階	アサイン
単体テスト	開発者（実装した本人 + レビュー担当）
結合テスト	開発者、テスト担当者（必要に応じて）
システムテスト	テスト担当者（主）、業務担当者、インフラエンジニア ※開発者が兼任する場合も多い
受け入れテスト	発注側業務担当者、エンドユーザー代表、ベンダー（支援）

7-4. スケジュールの考え方

7-4-1. 手戻りを考慮したバッファ

不具合修正の手戻り

テスト実施 → 不具合発見 → 修正 → 再テスト → (再発見 → 修正 → 再テスト)

バッファの目安

単体・結合テスト：テスト期間の20-30%
システムテスト：テスト期間の30-40%
受け入れテスト：テスト期間の20-30%

例：システムテストが10営業日の場合

計画：10日
バッファ：3-4日
合計：13-14日を確保

7-4-2. テストスケジュール例

全体スケジュール（3ヶ月プロジェクトの例）

週	開発	テスト
1-4週	実装	-
5週	実装完了	単体テスト
6-7週	バグ修正	結合テスト
8-9週	バグ修正	システムテスト
10週	バグ修正	受け入れテスト準備
11-12週	-	受け入れテスト
13週	-	リリース準備

8. よくある質問（FAQ）

Q1. 「結合テスト」と「システムテスト」の違いがよく分からない

A. 範囲と観点が異なります

	結合テスト	システムテスト
範囲	モジュール間の連携	システム全体
観点	インターフェースの整合性	要件の充足
実施者	開発者	テスト担当者、発注側
例	API AとAPI Bが正しく連携するか	注文から出荷までの業務フローが実現できるか

具体例：ECサイトの場合

結合テスト

商品検索API + 在庫確認APIの連携
カート追加API + 注文APIの連携
決済API + 外部決済サービスの連携

システムテスト

ログイン → 商品検索 → カート追加 → 注文 → 決済の一連のフロー
管理画面での在庫管理 → 在庫数の反映確認
性能要件（1000ユーザー同時アクセス）の確認

Q2. 「総合テスト」って何？システムテストと違うの？

A. 現場によって定義が異なる曖昧な用語です

パターン1：システムテストと同義（最も多い）

「総合的に」テストする = システムテスト

パターン2：システムテスト + 受け入れテストの総称

ベンダー側のテスト終了後の、総仕上げ的なテスト

パターン3：本番環境でのリハーサル

本番環境での最終確認
「総合運転テスト」とも呼ばれる

推奨：明確な用語を使う

曖昧な「総合テスト」ではなく、以下を使用することを推奨します：

システムテスト
受け入れテスト
本番環境リハーサル
運用テスト

Q3. シナリオテストはいつやるの？

A. システムテストと受け入れテストの両方で実施します

	システムテスト	受け入れテスト
実施者	QA、開発チーム	ユーザー、発注側
シナリオ作成者	要件定義書ベース	実業務ベース
観点	仕様通りか	使いやすいか

Q4. 受け入れテストでベンダーが同席する？しない？

A. 同席する場合としない場合があります

同席するケース

操作方法のサポートが必要
不具合発生時の即座の対応
テスト環境のトラブル対応
システムが複雑で説明が必要

同席しないケース

ユーザーだけで実施できる
操作マニュアルが整備されている
問題があれば後日対応で問題ない

推奨：初日は同席、その後は状況に応じて

初日：ベンダー同席で操作説明
2日目以降：質問があれば連絡

Q5. 回帰テストはいつやるの？

A. 変更があったタイミングで実施します

回帰テストとは
システムの変更（機能追加、修正、改修）によって、既存の機能に悪影響が出ていないかを確認するテスト。

実施タイミング

タイミング	内容
バグ修正後	修正が他機能に影響していないか
機能追加後	新機能が既存機能を壊していないか
リファクタリング後	コード整理が動作に影響していないか
リリース前	最終確認として全体を確認

実施範囲

フル回帰テスト：全テスト再実行（大規模リリース前）
部分回帰テスト：影響範囲のみ（小規模な修正）

Q6. 非機能テスト（性能、セキュリティ）はどの段階？

A. 主にシステムテストで実施します

性能テスト

テスト段階	性能テストの内容
単体テスト	アルゴリズムの効率性
結合テスト	APIのレスポンスタイム
システムテスト	エンドツーエンドのレスポンスタイム、負荷テスト
受け入れテスト	実業務での体感速度

システムテストでの性能テスト例

レスポンスタイム：画面表示3秒以内
スループット：1000件/秒の処理
同時アクセス数：100ユーザー同時アクセス可能

セキュリティテスト

テスト段階	セキュリティテストの内容
単体テスト	入力値のサニタイジング確認
結合テスト	APIの認証・認可確認
システムテスト	脆弱性診断、セキュリティスキャン
受け入れテスト	アクセス権限の妥当性確認

Q7. 自動テストは各段階でどう活用するの？

A. 段階によって自動化の適性が異なります

テスト段階	自動化適性	理由
単体テスト	◎ 非常に高い	繰り返し実行、回帰テスト必須
結合テスト	○ 高い	APIテストは自動化しやすい
システムテスト	△ 中程度	主要シナリオは自動化可能
受け入れテスト	× 低い	使いやすさは人が判断

推奨アプローチ

単体テスト：90%以上自動化
結合テスト：APIは自動化、画面連携は一部自動化
システムテスト：主要シナリオのみ自動化、詳細は手動
受け入れテスト：基本的に手動

9. まとめ

9-1. 各テスト段階の要点

テスト段階	一言でいうと	重要ポイント
単体テスト	コードの正確性確認	自動化推奨、早期発見
結合テスト	モジュール連携確認	インターフェース仕様の整合性
システムテスト	要件充足確認	業務フロー、非機能要件
受け入れテスト	実業務での利用可否	ユーザー視点、運用性

9-2. ベンダー受け入れ時の重要ポイント

テスト仕様書の網羅性確認
- 要件との対応
- 正常系・異常系・境界値
エビデンスの妥当性確認
- テストケースとの対応
- 日時の整合性
テスト報告書の確認
- 実施率100%
- 不具合の状況
抜け漏れの確認
- 非機能要件
- 例外処理
- ログ出力

9-3. テスト計画のポイント

段階的な実施
- 単体 → 結合 → システム → 受け入れ
外部委託時の分担明確化
- お客様参加の開始時期を決める
- 契約書に明記する
バッファの確保
- 手戻りを見込んだスケジュール
- 30-40%のバッファ

9-4. 最後に

テストは「品質を作り込む」ことではなく、「品質を確認する」ことです。

良い品質は、設計とコーディングで作られます。
テストは、その品質を証明し、問題があれば発見するための手段です。

各テスト段階の目的と範囲を正しく理解し、適切なテスト計画を立てることで、高品質なシステムを構築できると考えています。

10. 参考資料

書籍

「ソフトウェアテスト技法」（Glenford J. Myers 著）
- テスト技法の古典的名著
「はじめて学ぶソフトウェアのテスト技法」（Lee Copeland 著）
- 初学者向けの体系的な解説
「実践アジャイルテスト」（Lisa Crispin, Janet Gregory 著）
- アジャイル開発におけるテスト手法
「ソフトウェア品質知識体系ガイド（SQuBOK）」（SQuBOK策定部会編）
- 品質管理の体系的なガイド

オブジェクティブグループでは X の投稿も平日毎日行っています！
IT 関連の小ネタや便利技から、日常のアニメ・ゲーム布教なども幅広く投稿してるので、
ご興味のある方は是非フォロー・いいねをお願いします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up