ＳＥノウハウ テスト編: Ver1.5
価格： ￥0
カテゴリ： Kindle版
Overview:
This book is written know-how of the "test" of the Japanese system development .
Test policy , coordination and planning method of large-scale comprehensive test is written .
＜本書の概要＞
システム開発における『テスト』のノウハウを記載した書籍です。
概要として、テスト推進者として、テストにかかわる業務全般について、実施する業務・作業を本書に纏めています。
工程：テスト方針、単体テスト～総合テスト、UAT
（システム単位の規模のテストでも参考になるとは思いますが、）特に、エンタープライズレベルの企業の合併やシステム統合のような大規模なテストについて、参考になるかと思います。
＜本書の特徴＞
・テストにかかわる実際の業務ノウハウであること
・工程、業務、タスク単位を意識し記載していること
⇒実際のテスト推進業務でも使いやすいと思います。
・特に、大規模な総合テストの調整・計画策定方法について特筆していること
・特に、サイクルテストの実施方法について特筆していること
1はじめに
1.1.本書の前提
2システム化方針（テストにかかわる方針）
2.1.テスト方針
2.1.1.ステークホルダー分析・体制の整備
2.1.2.テスト方針の設計
2.1.3.テスト工程の定義
2.1.4.テスト単位の決定
2.1.5.テスト種別の選択
2.1.6.テスト環境（実機）の選択
2.1.7.テストデータの選択
2.1.8.テスト実施にかかわる方針
2.1.9.テスト方針のレビュー
2.1.10.その他
3単体･結合テスト
3.1.準備
3.2.単体・結合テスト実行計画 策定
3.2.1.完了条件の設定
3.2.2.WBSの緻密化
3.2.3.テスト項目の作成
3.2.4.テスト手順の作成
3.3.環境構築
3.4.単体・結合テスト実施
3.4.1.バグ票の起票
3.4.2.原因の特定
3.4.3.不具合の修正
3.4.4.横展開 修正
3.4.5.再テスト
3.5.単体・結合テスト報告
4総合テスト
4.1.準備
4.2.総合テスト計画の準備説明会（計画策定前）
4.3.環境調整
4.3.1.個別システムの実機の調整
4.3.2.関連システム間のＩ／Ｆ調整
4.3.3.基本マスター調整
4.3.4.本番データの調整
4.4.総合テスト実行計画策定
4.4.1.開始条件の設定
4.4.2.完了条件の設定
4.4.3.テスト対象システムの決定
4.4.4.WBSの緻密化
4.4.5.詳細スケジュールの作成
4.4.6.テスト項目の作成
4.4.7.テスト手順の作成
4.4.8.連絡フローの作成
4.5.総合テスト説明会（計画策定後）
4.6.総合テスト実施
4.6.1.運行連絡
4.7.総合テスト進捗報告 兼 完了報告
4.7.1.総合テスト進捗報告
4.7.2.総合テスト完了報告（テスト品質報告）
4.8.総合テスト その他
5UAT
5.1.準備
5.2.環境調整
5.3.UAT実行計画策定
5.3.1.開始条件の設定
5.3.2.完了条件の設定
5.4.UAT実施
5.5.UAT 完了報告
6その他
6.1.テストデータの管理
＜冒頭＞
1.はじめに
「テスト」の全体像として、テストの全体方針を定めるフェーズと、テストを実施するための計画を策定するフェーズ、テストを行う環境を調整・構築するフェーズ、計画の実行を行うフェーズ、また、テスト工程の各フェーズ（単体、結合、総合、UAT）に大別される。それらを補完する作業として、プロジェクトを推進・管理（進捗管理等）する作業、外部に発注する場合は外部委託にかかわる管理作業等がある。
テストで最も留意すべきことは、テストが不完全な場合、システム障害や、業務影響、他社システム影響があるため、網羅的なテストを行うことである。ただし、テスト品質の向上と、コストはトレードオフの関係にあるため、リスクに対する費用バランスを図りつつ、行うテストを取捨選択する必要がある。
十分なテストを実施することにより、一段と高い品質レベルを保障出来ることになり、最終的に、顧客満足の向上や、システム化による本質的な改善のメリットを享受することが出来る。そのためには、テストにかかわるノウハウが重要である。
1.1.本書の前提
本書（テストにかかわるノウハウ）を記載するにあたり、以下のことが行われている前提である。
●個別システムの開発
個別システムの要件定義、設計、開発が行われている前提である。
⇒要件定義については、『ＳＥノウハウ 要件定義編』 参照
⇒設計、開発については、『ＳＥノウハウ 設計・開発編』に記載予定
●全体スケジュール
開発するシステムの全体計画（マスタースケジュール）が作成されている前提である。
⇒詳細は、『ＳＥノウハウ システム化方針・計画編』に記載予定
●システム重要度評価
システム重要度評価を実施している前提である。
⇒詳細は、『ＳＥノウハウ システム重要度評価編』 参照
テスト品質の向上と、コストはトレードオフの関係にあり、テストが足りなければ、障害が発生し、一方、テスト品質を過剰に高めれば、コスト超過になってしまう関係がある。そのため、開発システムの重要度を評価し、重要度に応じテストを実施したり、テスト数を増減させたりする必要がある。
【完全性評価の概要と、テストでの対応概要】
完全性（Integrity）とは、情報が全て揃っていて欠損や不整合がないことである。
システムには、ツール的な曖昧なデータを保有するシステムから、財務諸表等、正確なデータを報告する責務を持ったシステム迄あり、データに求められる正確性（完全性）によりリスクが異なる。
完全性の評価では、システムの扱う情報の完全性（正確性）を測定し、また、取引金額、利用者数等により、影響が大きくなるため、出力結果が不正確なことに伴う影響も加味し、以下の分類を行う。
・最重要：業務継続に影響を与えるほどの完全性を求められるシステム
・重要：高い完全性を求められるシステム
・一般：一般的な完全性を求められるシステム
・その他：上記以外
完全性が重要以上のシステムは、不完全なデータにより、業務継続を脅かすリスクがあり、確りとテストを実施する必要がある。
【可用性評価の概要と、テストでの対応概要】
可用性とは、必要な時に情報資産が使用出来ることである。一般的に、可用性の要求が高いシステムとは、サービスが停止することで、人命や経済損失が発生するようなサービスや、システムの障害による顧客へのサービス提供の停止や、対外決済との連係が停止する等、中断が許されないことである。
可用性の評価では、システムの可用性を測定し、また、サービス停止による影響も加味し、以下の分類を行う。
・最重要：原則停止不可
・重要：半日までなら許容可
・一般：２－４営業日までなら許容可
・その他：上記以外
可用性が重要以上のシステムは、冗長化構成や、可用性にかかわる機能の実装を行い、その構成や機能についてテストを行う必要がある。
⇒構成や機能の詳細は、『ＳＥノウハウ 要件定義編』 参照
【機密性評価の概要と、テストでの対応概要】
機密性とは、アクセスを許可された者のみが情報資産にアクセス出来ることである。
システムには、公開情報のみを保持するシステムから、重要情報（顧客情報等）を持つシステムまである。これらの保有するデータの特性により、情報漏えいした際の影響度は大きく異なる。また、保有する個人情報のデータ件数によっても影響度は異なる。機密性の評価では、システムの扱う情報の質、ならびに、その量を測定し、以下の分類を行う。
・最重要：事業継続に影響を与えるほどの重要情報を保有するシステム
・重要：重要情報を保有するシステム
・一般：一般情報を保有するシステム
・その他：上記以外
機密性が重要以上の場合、セキュリティ機能の実装を行い、その機能についてテストを行う必要がある。
⇒機能の詳細は、『ＳＥノウハウ 要件定義編』 参照
This book is written know-how of the "test" of the Japanese system development .
Test policy , coordination and planning method of large-scale comprehensive test is written .
＜本書の概要＞
システム開発における『テスト』のノウハウを記載した書籍です。
概要として、テスト推進者として、テストにかかわる業務全般について、実施する業務・作業を本書に纏めています。
工程：テスト方針、単体テスト～総合テスト、UAT
（システム単位の規模のテストでも参考になるとは思いますが、）特に、エンタープライズレベルの企業の合併やシステム統合のような大規模なテストについて、参考になるかと思います。
＜本書の特徴＞
・テストにかかわる実際の業務ノウハウであること
・工程、業務、タスク単位を意識し記載していること
⇒実際のテスト推進業務でも使いやすいと思います。
・特に、大規模な総合テストの調整・計画策定方法について特筆していること
・特に、サイクルテストの実施方法について特筆していること
1はじめに
1.1.本書の前提
2システム化方針（テストにかかわる方針）
2.1.テスト方針
2.1.1.ステークホルダー分析・体制の整備
2.1.2.テスト方針の設計
2.1.3.テスト工程の定義
2.1.4.テスト単位の決定
2.1.5.テスト種別の選択
2.1.6.テスト環境（実機）の選択
2.1.7.テストデータの選択
2.1.8.テスト実施にかかわる方針
2.1.9.テスト方針のレビュー
2.1.10.その他
3単体･結合テスト
3.1.準備
3.2.単体・結合テスト実行計画 策定
3.2.1.完了条件の設定
3.2.2.WBSの緻密化
3.2.3.テスト項目の作成
3.2.4.テスト手順の作成
3.3.環境構築
3.4.単体・結合テスト実施
3.4.1.バグ票の起票
3.4.2.原因の特定
3.4.3.不具合の修正
3.4.4.横展開 修正
3.4.5.再テスト
3.5.単体・結合テスト報告
4総合テスト
4.1.準備
4.2.総合テスト計画の準備説明会（計画策定前）
4.3.環境調整
4.3.1.個別システムの実機の調整
4.3.2.関連システム間のＩ／Ｆ調整
4.3.3.基本マスター調整
4.3.4.本番データの調整
4.4.総合テスト実行計画策定
4.4.1.開始条件の設定
4.4.2.完了条件の設定
4.4.3.テスト対象システムの決定
4.4.4.WBSの緻密化
4.4.5.詳細スケジュールの作成
4.4.6.テスト項目の作成
4.4.7.テスト手順の作成
4.4.8.連絡フローの作成
4.5.総合テスト説明会（計画策定後）
4.6.総合テスト実施
4.6.1.運行連絡
4.7.総合テスト進捗報告 兼 完了報告
4.7.1.総合テスト進捗報告
4.7.2.総合テスト完了報告（テスト品質報告）
4.8.総合テスト その他
5UAT
5.1.準備
5.2.環境調整
5.3.UAT実行計画策定
5.3.1.開始条件の設定
5.3.2.完了条件の設定
5.4.UAT実施
5.5.UAT 完了報告
6その他
6.1.テストデータの管理
＜冒頭＞
1.はじめに
「テスト」の全体像として、テストの全体方針を定めるフェーズと、テストを実施するための計画を策定するフェーズ、テストを行う環境を調整・構築するフェーズ、計画の実行を行うフェーズ、また、テスト工程の各フェーズ（単体、結合、総合、UAT）に大別される。それらを補完する作業として、プロジェクトを推進・管理（進捗管理等）する作業、外部に発注する場合は外部委託にかかわる管理作業等がある。
テストで最も留意すべきことは、テストが不完全な場合、システム障害や、業務影響、他社システム影響があるため、網羅的なテストを行うことである。ただし、テスト品質の向上と、コストはトレードオフの関係にあるため、リスクに対する費用バランスを図りつつ、行うテストを取捨選択する必要がある。
十分なテストを実施することにより、一段と高い品質レベルを保障出来ることになり、最終的に、顧客満足の向上や、システム化による本質的な改善のメリットを享受することが出来る。そのためには、テストにかかわるノウハウが重要である。
1.1.本書の前提
本書（テストにかかわるノウハウ）を記載するにあたり、以下のことが行われている前提である。
●個別システムの開発
個別システムの要件定義、設計、開発が行われている前提である。
⇒要件定義については、『ＳＥノウハウ 要件定義編』 参照
⇒設計、開発については、『ＳＥノウハウ 設計・開発編』に記載予定
●全体スケジュール
開発するシステムの全体計画（マスタースケジュール）が作成されている前提である。
⇒詳細は、『ＳＥノウハウ システム化方針・計画編』に記載予定
●システム重要度評価
システム重要度評価を実施している前提である。
⇒詳細は、『ＳＥノウハウ システム重要度評価編』 参照
テスト品質の向上と、コストはトレードオフの関係にあり、テストが足りなければ、障害が発生し、一方、テスト品質を過剰に高めれば、コスト超過になってしまう関係がある。そのため、開発システムの重要度を評価し、重要度に応じテストを実施したり、テスト数を増減させたりする必要がある。
【完全性評価の概要と、テストでの対応概要】
完全性（Integrity）とは、情報が全て揃っていて欠損や不整合がないことである。
システムには、ツール的な曖昧なデータを保有するシステムから、財務諸表等、正確なデータを報告する責務を持ったシステム迄あり、データに求められる正確性（完全性）によりリスクが異なる。
完全性の評価では、システムの扱う情報の完全性（正確性）を測定し、また、取引金額、利用者数等により、影響が大きくなるため、出力結果が不正確なことに伴う影響も加味し、以下の分類を行う。
・最重要：業務継続に影響を与えるほどの完全性を求められるシステム
・重要：高い完全性を求められるシステム
・一般：一般的な完全性を求められるシステム
・その他：上記以外
完全性が重要以上のシステムは、不完全なデータにより、業務継続を脅かすリスクがあり、確りとテストを実施する必要がある。
【可用性評価の概要と、テストでの対応概要】
可用性とは、必要な時に情報資産が使用出来ることである。一般的に、可用性の要求が高いシステムとは、サービスが停止することで、人命や経済損失が発生するようなサービスや、システムの障害による顧客へのサービス提供の停止や、対外決済との連係が停止する等、中断が許されないことである。
可用性の評価では、システムの可用性を測定し、また、サービス停止による影響も加味し、以下の分類を行う。
・最重要：原則停止不可
・重要：半日までなら許容可
・一般：２－４営業日までなら許容可
・その他：上記以外
可用性が重要以上のシステムは、冗長化構成や、可用性にかかわる機能の実装を行い、その構成や機能についてテストを行う必要がある。
⇒構成や機能の詳細は、『ＳＥノウハウ 要件定義編』 参照
【機密性評価の概要と、テストでの対応概要】
機密性とは、アクセスを許可された者のみが情報資産にアクセス出来ることである。
システムには、公開情報のみを保持するシステムから、重要情報（顧客情報等）を持つシステムまである。これらの保有するデータの特性により、情報漏えいした際の影響度は大きく異なる。また、保有する個人情報のデータ件数によっても影響度は異なる。機密性の評価では、システムの扱う情報の質、ならびに、その量を測定し、以下の分類を行う。
・最重要：事業継続に影響を与えるほどの重要情報を保有するシステム
・重要：重要情報を保有するシステム
・一般：一般情報を保有するシステム
・その他：上記以外
機密性が重要以上の場合、セキュリティ機能の実装を行い、その機能についてテストを行う必要がある。
⇒機能の詳細は、『ＳＥノウハウ 要件定義編』 参照