TM-5.7.1 (K2)STEP テストプロセス改善モデルの背景、対象範囲、目的をまとめる。

2024年4月12日 08:03

STEP テストプロセス改善モデルの背景

STEP テストプロセス改善モデルは、1990年代に米国のソフトウェアテスト専門家であるデビッド・クレイグ氏によって開発されました。当時、ソフトウェアテストプロセスの改善が求められる一方で、既存のテストプロセス改善モデルでは、特定の順序で改善を進める必要があるという課題がありました。

STEP は、このような課題を解決するために開発されたモデルであり、テストプロセスの改善を特定の順序で行う必要がないことが特徴です。また、要件策定からシステム廃止にわたりテスト活動が継続するライフサイクル活動であるという考え方に基づいています。

STEP テストプロセス改善モデルの対象範囲

STEP は、ソフトウェアのすべてのライフサイクルフェーズを対象としたテストプロセス改善モデルです。具体的には、以下のフェーズを対象としています。

要件定義
設計
実装
テスト
運用
廃棄

また、STEP は、ソフトウェアの大小や複雑さ、開発方法に関係なく適用することができます。

STEP テストプロセス改善モデルの目的

STEP の目的は、ソフトウェアの品質を向上させることです。具体的には、以下の目的を達成することを目指しています。

欠陥を早期に検出して、その影響を最小限に抑える
テストプロセスを効率化し、コストを削減する
テストプロセスを継続的に改善する

STEPの基本的な前提

STEP の基本的な前提は、以下のとおりです。

要件ベーステスト戦略である。
テストをライフサイクル開始時に始める。
テスト要件および利用方法モデルとして使う。
テストウェア設計がソフトウェア設計をリードする。
欠陥を早期に検出するか、またまとめて予防する。
欠陥を体系的に分析する。
テスト担当者および開発者が共同で作業する。

練習問題

あなたは通信ネットワークハードウェアとソフトウェアを製造する国際企業で働いています。ハードウェアとソフトウェアの開発は別の部門で行われており、あなたはネットワークルーターソフトウェア製品ラインのテストマネージャーです。

この製品ラインでは、増分型製品ライフサイクルを使用して密に統合された製品を開発するという長い伝統があります。ハードウェア部門は6ヶ月ごとに新しいバージョンをリリースし、ソフトウェア部門は各新ハードウェアバージョンに対応する新しいソフトウェアバージョンを用意することを目指しています。ソフトウェアは2ヶ月ごとに増分的に開発されます.設計段階では、両部門のスケジュールが同期化されています。

あなたのチームは15人のテスト担当者で構成されており、2年間、多くはそれ以上の在籍期間があります。新しいテストは、経験豊富なテストアナリストによって社内独自のカスタムテストスクリプトとして開発されています。テストのバリエーションや回帰テストセットは、チームの残りのメンバーによって実行されます。

経営陣は、重大な欠陥の発見件数とテスト実行のステータスをリストした月次進捗報告を要求しています。また、すべての部門の人員の効率を測定する取り組みも行われています。さらに、会社レベルでCMMIも導入されています。

しかし、ハードウェア開発スケジュールに追従することができていません。

あなたは、長期的にこれらの問題を解決するために、STEPモデルが有効かもしれないと考えています。以下のSTEPの基本前提のうち、あなたのニーズに最も合っているものはどれですか？

a) 要件ベースのテスト戦略
b) テストウェア設計がソフトウェア設計をリードする
c) テスターと開発者が協力して作業する
d) 欠陥が体系的に分析される

正解：c)

選択肢a (要件ベースのテスト戦略)：製品ラインはすでに要件ベースのアプローチを採用していますが、主な問題はハードウェア開発スケジュールに追従できないことであり、テスト戦略自体ではありません。
選択肢b (テストウェア設計がソフトウェア設計をリードする)：この前提は、直に直面している課題に対処するものではありません。テスト担当者の早期関与は有益かもしれませんが、問題はハードウェアチームとソフトウェアチーム間の同期とコミュニケーションにあります。
選択肢c (テスターと開発者が協力して作業する)：これは、あなたが言及した核心の問題-ハードウェア開発スケジュールに追従できない- に直接対処します。テスト担当者と開発者が協力して互いのプロセスと課題を理解し、問題を早期に発見して解決すれば、最終的にはよりスムーズな製品リリースサイクルにつながります。
選択肢d (欠陥が体系的に分析される)：これはどのテストプロセスでも貴重な実践ですが、ハードウェア開発スケジュールとの整合性を維持するという問題に直接対処するものではありません。