ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

JSTQB-ALシラバスのお勉強 ─ 8.3~8.9

 ソフトウェア開発におけるプロセス管理のモデルといえば、CMM/I。「CMMI」(Capability Maturity Model Integration:能力成熟度モデル統合)という名前には、プロセスのPの字も出てきませんが、ソフトウェア開発プロセスがどれだけ「成熟」しているかを評価するのに用いられます。

 ただ、このモデルは、ソフトウェアテストには重きをおいていない。そこで、ソフトウェアテストプロセスの評価・改善を行うためのモデルを作ろう!ということで・・・、たくさん作ってしまったようですね。
 この章のそれぞれのモデルも、本来は1つ1つ中身を学ぶべきですが、ひとまず概要だけを押さえていきます。

改善のステップ

 モデルに依らず、テストプロセスを見直し、改善するためのステップを、「IMPROVE」という言葉で表します。

  • I 開始(Initiate)
  • M 測定(Measure)
  • P 優先度設定および計画(Prioritize & Plan)
  • R 定義および再定義(Define & Redifine)
  • O 運用(Operate)
  • V 確認(Validate)
  • E 進化(Evolve)

 「進化」あたり、相当苦しい気がしますが・・・。「確認」の結果、改善プロセスを止めることもありますので、「End」のEかも知れませんね。
 それぞれの内容に、特に触れる必要はないでしょう。読んでそのままです。

プロセス改善タイプ

 モデルは、プロセス参照モデルコンテンツ参照モデルに分けられます。このキーワード(英語)で検索しても、各種検索エンジンでISTQBのシラバスおよび関連書籍しかヒットしません。ISTQBシラバスから訳してみますと、

  • プロセス参照モデル:自組織のプロセスを評価する時に、比較の対象となるモデル。TPIが相当する。
  • コンテンツ参照モデル:自組織のプロセスを評価した後に、プロセスを改善するためのモデル。CTP、STEPが相当する。

 評価する前に使うのか、後に使うか、という違いでしょうか・・・。
 以下、具体的なモデルです。

モデル1:TMM(Testing Maturity Model)

 CMMそのままで、初期(Initial)→定義(Definition)→統合(Integration)→マネジメントおよび測定(Management & Measurement)→最適化(Optimization)というようにレベルアップしていきます。

  • 初期:何も定義されず、デバッグとテストの区別がない状態。
  • 定義:テストのポリシーとゴールが設定され、初歩的なテスト技法が用いられる。
  • 統合:テストが、ソフトウェア・ライフサイクルに組み込まれる。監視とコントロールがなされる。
  • 測定:監視とコントロールが定量化され、効率的な改善が図れる。
  • 最適化:結果に応じてプロセスが随時改善され、最適化されている。
モデル2:TPI(Test Process Improvement)

 テストに関わる、たとえば「テスト戦略」「メトリクス」「テストケース設計」といった20の要素を「キーエリア」として、それぞれのキーエリアに対し、A~Dの4段階でランク付け。この結果を「テスト成熟度」として14段階のレベルにマッピングする、というものです。
 TMMとの大きな違いは以下。

  • TMMが段階表現であるのに対し、TPIは連続表現。
  • TMMがソフトウェア開発全体のプロセス改善と連動するのに対し、TPIはテストプロセスの改善から始めることができる。([コチラ](http://journal.mycom.co.jp/series/sysdev_test/020/index.html)を参照)
モデル3:CTP(Critical Testing Process assesment)

 日本語訳の最初の文がわかりづらいのですが、提唱者であるBlack氏のサイトを読むと、このモデルの前提とは、「テストには複数のプロセスがあるが、あるものは重要で、あるものはそうでもない。なのでその重要なプロセスを見出して改善しよう」ということのようです。

 プロセスの評価には、以下のようなメトリクスが使用されます。

  • 欠陥検出率
  • ROI
  • 要件のカバレッジ、リスクのカバレッジ など

 この他に、定量的には表しづらい、テスト計画の有用性といった要素も評価の対象となります。

モデル4:STEP(Systematic Test and Evaluation Process)

 適用の条件が、ちょっと特殊ですね。「テストがライフサイクルの開始時に始まる」「テストウェアの設計が、ソフトウェアの設計に先立つ」など、テストファーストを意識したモデルです。また、テストが、要件定義からシステムの廃棄まで、ライフサイクル全体に渡っての活動であるということを前提にしています。

 使用されるメトリクスとしては、以下のようなものです。

  • 欠陥密度
  • 欠陥の傾向(重要度や偏在の傾向など)
  • 欠陥の作り込み、検出、除去のフェーズ

 やはり、概要だけでは本質的な違いはわかりませんね。  TPIやCTPなど、書籍も充実しているようですので、いずれ勉強してみます。この他にも、TOM・TIM・SQRといったモデルがあります。