ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic Practices とは？
既に説明を読んでいる人は飛ばしてください
- 全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
- BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される
BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resources: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【5.3.1 実施管理プロセス属性】以降を参照ください。
能力レベル1-2-3を例えるのであれば、料理なんかが良い例だと思います。
レベル1：レシピ通りに作ってるが、何を調合したのかわからず同じ味を再現できるか不明な状態。
レベル2：レシピに何をどのタイミングで調合するのか記載され、似た味を再現できている状態。
レベル3：レシピがレストランの決まりに組み込まれ展開されており、誰でも同じくできる状態。
即ちの能力レベル1では何となく実施してリリースができている状態に対し、能力レベル2以上ではプロセス（レシピ）が存在して計画・実行・調整がかけられる状態を示します。
Generic Practices の構成
Generic Practicesを能力レベルで分けた表は以下の通りです。
| 能力 レベル |
プロセス属性 | 項 | 説明 |
| L2 | 実施管理プロセス | GP2.1 | プロセスの実施が管理されている程度を示す |
| 作業成果物管理プロセス | GP2.2 | プロセスにより作成される作業成果物が管理されている程度を示す | |
| L3 | プロセス定義プロセス | GP3.1 | 定義されたプロセスが維持されている程度を示す |
| プロセス展開プロセス | GP3.2 | 定義されたプロセスの展開されている程度を示す |
SWE.6の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.6 ソフトウェア適格性確認テスト には合計7つの基本プラクティス（BP1～BP7）が存在します。
SWE.7 (ソフトウェア適格性確認テスト) の目的は、統合ソフトウェアがソフトウェア要件に遵守している証拠を提供するために、テストを確実に実施することである。
BP1
BP1では、回帰テスト戦略を含むソフトウェア適格性確認テスト戦略の策定が求められています。
回帰戦略とは、例えば上位の要件（仕様やソフトウェア設計など）が変更された場合に、ソースコードにも変更が加わりますが、これをどの程度まで再検証が必要か、方法や範囲を定義付けすることです。
ソフトウェア適格性確認テストを実施するために『どのテストをどの程度まで実施するのか』戦略を策定する必要があります。その他にも、テストを実行するうえで必要なリソースの確保であったり、全体の日程感をスケジューリングしたりしなくてはなりません。
なお、スケジュールは上位スケジュール（例えば、プロジェクトスケジュールや顧客開発マイルストンなど）と整合性がある状態でなくてはなりません。
BP2
BP2では、ソフトウェア適格性確認テスト仕様の作成が求められています。
ソフトウェア適格性確認テストでは、ソフトウェア要件に対して正常な振る舞いを行うことができるのか動的検証を行うことが求められています。例えば、要件に基づくテストを実施し、ソフトウェア要件に対して正しく動作することを確認します。その他にも、あえて正常な状態から逸脱した条件で行うテスト（いじわるテスト等）であったり、ROMやRAMの使用量や実行時間を確認するリソーステストが挙げられます。
上記のように、ソフトウェア適格性確認テストではどのような仕様（テストケース）に基づいてテストを実行すべきなのか定義し、ソフトウェアテスト戦略を策定しなくてはなりません。
BP3
BP3では、テストケースの選択が求められています。
BP2で定義したソフトウェア適格性確認テスト仕様（テストケース）に基づき、必要なテストケースを選択する必要があります。
BP4
BP4では、統合ソフトウェアのテストが求められています。
BP3で選択したテストケースの実行が求められています。今までのBPで求められてきた、戦略・計画・スケジュール・リソース・仕様などなどを用いて、実際にソフトウェア結合テストを実施することがBP6で求められています。なお、テストの記録やログを記録することも求められており、検証目的、実施日、担当者を記録する他にも、再現環境を構築するための確認したソフトウェアバージョンやツールのバージョンやライセンス等も記録します。
BP5
BP5では、双方向トレーサビリティの確立が求められています。
双方向トレーサビリティというのは、下位概念と上位概念の両方向から互いをトレーサビリティできることをいいます。例えば、ソフトウェア適格性テスト仕様の情報から、それらがソフトウェア詳細設計書のどこに該当するのかトラックでき、逆にソフトウェア詳細設計書から結合テストをトラッキングできる仕組みです。
BP6
BP6では、一貫性の確保が求められています。
個々のソフトウェア適格性テスト仕様が漏れなく、ソフトウェア詳細設計書に記載された全ての要件に対して実行されるため、ソフトウェア詳細設計書とソフトウェア適格性テスト仕様の一貫性を担保する必要があります。上位概念と下位概念が完全にイコール（=）の関係である（一貫性が取れている）状態にする必要があります。
BP7
BP7では、結果の要約および伝達が求められています。
ソフトウェア適格性テスト結果を要約し、影響を受けるすべての関係者へ伝達する。が関係する全ての要員に伝達される必要があります。レビュー実施日、参加者、検証目的など、一般的な情報の他にも、検証するソフトウェアのバージョンであったり、仕様したツールなどの情報も事細かに記入（保存）しておく必要があります。これは、レビュー後に、同様の環境を再現することに役立てることができます。
ASPICEの解説はコチラ！
＼noteを始めました／
㊙年収情報から品質経験を綴っています
＼他にも色々なブログを書いています／
コメント