読者です 読者をやめる 読者になる 読者になる

テスト計画の中でのサブプロセス管理の考え方の紹介

12/8分 担当の、@acha_821 です。

アドカレ初参戦です。

一つの大きなテーマの枠の中で自由に書きたいことをかける。そして、バトン形式。世の中には面白いものがたくさんありますね。

さて、前置きはこのくらいにしますね。早速、バトンを受け取ります!

 

ポイント

プロジェクトゴール達成のための計画を立てるのがプロジェクト計画。

その達成に必要なプロセスを構成するサブプロセス単位も視野に入れて計画すると、選択したプロセスの目的、尺度等についても考えます。

その際に考慮するといいと思うポイントを少しご紹介。

 

ということで・・・スタートっ!

 

 プロジェクト計画とサブプロセス管理

言葉の定義

登場する単語、この記事の中での定義を書いておきます。オレオレな内容なので、他と違っていましたらすみません。

 

プロジェクトゴール

代表的な例として、QCDが挙げられると思います。

今回の記事の中では、テストについて記載したいので、とあるソフトウエアの品質の定量的な目標値をゴールとして想定してみます。

 

 

サブプロセス

プロセスというのは、インプットとアウトプットをつなぐところにある「過程、工程、方法」を意味します。

その定義に基づき、ひとつのプロセスを構成する小さなプロセスの単位をサブプロセス、と定義して話を進めていきます。

CMMIの中では、サブプロセスと言うものもよく出てくるので、馴染みの深い方もいらっしゃると思います。

プロジェクトゴールに「品質」を設定しているので、品質を測る工程・方法がプロセスとなります。

設計工程ですと、設計書が成果物。その設計書の品質を測るプロセスはレビュープロセスと考えることができます。レビューを構成するサブプロセスには、インスペクション、ピアレビュー等が一般的に挙げられています。

 

 サブプロセス管理を行う目的 

 「プロジェクトゴール達成する」ためには、プロセスごとの「やり方」を「今までの成功していたやり方」といかに近似させていくかを管理する、ととらえることもできると思います。(ちょっと発想が飛躍してすみません)

より小さな単位で、「過去の成功経験と同じように」行っていることを監視していくことによって、ゴール達成を阻害する要因を小さなリスクの段階から把握することができます。ここに、サブプロセス管理を行う一番の目的があると思っています。

”従来のうまくいっているやり方”とのズレが少しずつ生じ、発見できないままでいることにより、リスクが大きくなっていきます。

プロセスを小さく管理することで、工程の中で実施するそれぞれのサブプロセスを行う目的が見えてくることがあります。

例えば、ピアレビューのあとにイスペクションを実施すると計画します。ピアレビューとインスペクションでは、それぞれレビュー観点が異なるものとします。そういった、特性の異なる小さなプロセス、これがサブプロセスになります。

異なる特性のものをサブプロセスとして扱うのは、同じ特性・性質のものを管理しても、ズレを生じさせた原因を特定しにくくなるからです。

 

実施するプロセスを選択する

 プロ計では、何を計画していますか?

計画の内容次第で、プロジェクト成否の8割はきまるといわれます。ステークホルダとゴールやスコープ、役割等を共有し、成功への道筋を描く…と言うと言いすぎかしら(^_^;)

プロジェクトを実行するには様々なプロセスがあり、それ毎に計画を立てます。

レビュー計画、構成管理計画、リスク管理計画、作業計画、テスト計画・・・

テスト計画に至っても、「テストは下流だから・・・」ではありません。

プロ計でスコープや役割、成果物等が決まっていればテスト計画もたてられます。

ということで、今回はプロジェクトの初期で立てるテスト計画にフォーカスして書いていきたいと思います。

 

テスト計画におけるサブプロセス

何を計画しますか?

ステークホルダ、スコープ、役割、体制、工程、成果物…プロ計と同じです。

工程(テストレベル)には、単体、結合、システムテスト・・・等があります。

テストレベルごとに、何を検証するのか、何を検証したいのかを計画していきます。

その「検証したいこと」「検証するもの」によって、プロセスも変わってきます。

注:これは、V字モデルでも説明できます。詳細については、以下を参照ください。

V字モデルとは? – ソフトウェアテスト・第三者検証ならウェブレッジ

 

性質・特性の異なるものをサブプロセスとして扱っていきます。

では、テストではどのようなものをサブプロセスと定義すればよいか。

テストレベルごとに検証したい・検証する対象・目的が異なるので、その目的にあった特性・観点を割り振り、尺度を決めて管理を行う

簡単な例でいうと、品質特性モデルが挙げられます。「異なる特性を分類し体系的にまとめられ規格になります。これは、まさに別のサブプロセスとして扱うことができると思います。

ここまで読んでくださっている方はピンときた方もいるかもしれません。

テストにおけるサブプロセスは、管理したい単位(テストコンテナ、テスト観点、テスト条件・・・)の一つの軸になりうるものだと考えています。

サブプロセスにて測定する尺度は、GQMによって落とし込み、メトリクス管理をしましょう(いつか、このGQM・メトリクスについての記事を書きたいと思います)。定量的に管理を行うことで、KKDでは得られない、プロジェクトゴール達成への試みが待っていることでしょう。

 

まとめ

  • 過去の特性が類似した「成功」プロジェクトを層別して、「ゴールを達成するサブプロセス(注★)」を定義・導出しておく
  • ★を指標値なり目標値として持っておくことで、サブプロセス管理を行うことにより、リスクの早期発見ができる
  • 以上の理由から、サブプロセス管理では定性的な管理ではなく定量的な管理がもとめられている
  • プロセスの目的(ゴール)から尺度を落とし込む。(GQM)

 

サブプロセス管理、試してみませんか?