品質保証部門「モモテツ」のコンセプト
コンセプト
ユーザーが安心して製品を買ったり、使ったりできることを意識したテスト設計は普段から取り組んでいますが、販売部門や開発部門など内部のステークホルダーがテストの進め方や内容について、安心してもらえるような取り組みは出来ていませんでした。そのため、この機会を利用して、「ステークホルダー全員を安心させるテスト設計」がしたいと考え、各ステークホルダーの分析や安心させるための施策をテスト設計に盛り込みながら、活動を進めました。特に内部ステークホルダーを意識した施策を重点的に取り組みました。

位置づけ
普段の業務では、製品開発時の一部分のテストを担当していますが、今回は「品質」を広い視点で捉えてみたいと考え、製品開発の品質保証に早い段階から携わるカラオケシステム開発会社の品質保証部門という立ち位置にしました。設計・開発/テストプ
ロセス全体の品質を計測・分析し、必要に応じて是正を促すことを盛り込んだテスト設計をしました。

方針
通信カラオケシステムに対し 検証と妥当性確認（Verification and Validation）の視点でテストを設計・実施し、以下の全てを確認することを目的としています。
・機能要件が満たされていること。
・ソフトウェア品質目標が満たされていること。
・外部ステークホルダー各々に対するユーザビリティが考慮されていること。
モモテツ

1「モモテツ」の役割

2

ⅠⅡⅢⅣ

Ⅰ 品質目標の設定および達成のための活動推進

Ⅴ

市場ニーズの高い製品を開発するために、品質目標を設定し、達成するための活動をプロジェクト全体を巻き込んで推進する。

目標の確認手段や確認担当を決める

目標を設定する

品質保証チームが担当
システムテストチームが担当

Ⅱ 全体テスト計画の策定
テスト網羅を確保（漏れや 意図しない重複を回避）するために、全体テスト計画（＝テスト戦略。実施するテストレベルと 各テストレベルでのテスト内容）を高位レベルで策定する。

Ⅴ システムテストの実施
品質の最終確認のために、自らシステムテストを実施する。

全体テスト計画に沿ったテストを設計し、実施する・品質状況に応じてテストアーキテクチャを選択できるよう、4パターン準備しておく。
・品質目標がクリアできているか確認を行う。

品質保証部

リスクベースの探索的テストを実施する
ODC分析結果から 狙うべき「テスト対象」「テスト条件」を特定し、テストを実行する。

テスト全体で確認すべき
テスト観点

単体テスト

割確
り認
振担
り当のテスト全体で確認すべき
品質目標

結合テスト
システムテスト

Ⅲ 開発プロセス全体の品質測定および是正勧告
品質をより上流で作りこむために、テストだけでなく開発プロセス全体の品質を測定し、必要に応じて是正勧告を行う。

Ⅳ

品質測定の対象は 開発プロセス全体

品質に応じたテスト内容の変更

要件
定義

プロジェクトの制約（コスト、スケジュール、スコープ）の中で品質を可能な限り高めるために、テスト設計時に「品質状況に応じてテスト内容を変更できる仕組み」を構築し、テスト実行時に制御する。
ODC分析結果読み取れる情報
テストの網羅度

品質状況に応じてシステムテストの内容を分岐
テスト優良・バグ収束型
テスト優良・バグ非収束型

バグの収束具合

テスト不良・バグ収束型
テスト不良・バグ非収束型

モモテツ

事前に4パターンのテス
ト内容を設計しておく

基本
設計

詳細
設計

実装

単体
テスト

結合テスト

システム
テスト

実装工程の例
プロダクトメトリクス

プロセスメトリクス

FP規模

工数の予実比率(実績工数、見積工数)

SLOC
コメント率ネストの深さ（最大）サイクロマティック複雑度

レビュー指摘率(レビュー工数、指摘数)

例●特定の担当者のソースコードが複雑だ→ 担当者の教育を勧告●レビュー工数が著しく少ない→ レビュー実施を勧告●レビュー指摘率が低い→ レビュー体制や運営を確認し、是正勧告

テスト設計の流れ（主なプロセス）…システムテストチーム担当のプロセス…品質保証チーム担当のプロセス

テス
ト計
画テス
ト
要
求分
析テス
ト
アー
キ設
計

詳
細テ
設ス
計ト
モモテツ

ステークホルダーの特定と分析

ステークホルダーの安心感を満たすための施策の検討

品質保証計画書の作成

3

システムテスト計
画書の作成

品保方針の共有

マネジメントリスクの分析

機能要件の導出

P.4で説明新規テスト観点（従来との差分）の導出

新機種対応版
テスト観点の導出

ステークホルダーを安心させるためのテスト要求を漏れなく導出する

テスト要求一覧の作成

P.5で説明ステークホルダー分
析の深掘り

テストフレームの導出

因子一覧の導出

テストタイプへの分類

各テストタイプの実施有無の明確化
各テストタイプの工数配分の設定
各テストタイプの実施順序の設定

探索的テスト以外
テストフレームの構成要素に対するカバレッジ基準の設定

品質保証やステークホル
ダーの安心のために必要な施策を盛り込んだ計画を策定する

探索的テストのみ
探索的テストの実施方針の設計

テストアーキテク
チャの検討

テスト俯瞰図の作成

テスト要求を確認し易いように整理し、効率的・効果的に確認するための実施順序や工数配分を決定する
P.6で説明テストケースを具体的且つ機械的に導出できるよ
うにする
P.7-8で説明

テスト計画4

品質目標や潜在リスクを考慮し、品質保証計画を策定

ソフトウェア
品質保証
計画書

策定した計画を、各テストレベル担当チームと共有
各担当チームに品質保証計画に準拠したテスト計画を策定させることで…

ポイント

テスト全体での網羅性を確保
ポイント

共通手法による品質分析が可能

共有・準拠
品質保証部
システムテストチーム
システムテスト

ポイント

ポイント

ポイント

PMBOKの知識エリアを切り口とすることで、リスクの抽出漏れを防止

品質保証部としての役割（P.2参照）を果たすための施策を反映

ステークホルダーに安心を与える施策を反映

Ⅰ
ポイント

対応が必要なリスクは、対応策を反映
モモテツ

ⅤⅣ

ⅡⅢ

システムテスト
計画書

製品開発部
結合テストチーム
結合テスト

設計/開発
単体テスト

結合テスト
計画書

単体テスト
計画書

テスト要求分析
新機種対応版のテスト観点を導出
従来機種テスト時に用いたテスト観点

ステークホルダーの安心感に繋がるテスト観点

マージ

5
ポイント

ステークホルダーに安心を与えるテスト設計（コンセプト）に対応
ポイント

機種差分（新規要件）から導出したテスト観点

機種のバージョンアップに対応

従来機種との差分

テスト要求一覧を作成
新機種対応版テスト観点からテスト要求一覧を作成

テスト要求一覧

横軸： テスト対象

ポイント

新機種対応版テスト観点

モモテツ

縦軸
：振る
舞
い

「●●のテスト対象で●●の振る舞いを確認するには、どんなテスト条件が必要か」を全ての組み合わせに対して検討ポイント確認する必要がない「テスト対象×（かける）振る舞い」
については、空欄では無く「×(バツ)」を入力することで、「テスト対象×振る舞い」の組み合わせに対する検討漏れを防止

テストアーキテクチャ設計
テストフレームと因子水準一覧を導出

テストフレームをテストタイプに分類

ポイント

テスト観点（因子）の使われ方を定義することで、テスト詳細設計担当者によって異なるテストケースが導出されることを防止（一意性を確保）

テストタイプ

テストフレームの一例

条件は何？

対象は？

6

振る舞いは？

テスト要求一覧
因子水準一覧

ポイント「振る舞い」が同じテストフレーム
はテストの目的が同じと考え、「振る舞い」を基準にグルーピングし粒度を粗くした・“引き”で見られるようにすることで全体像の把握が容易になった・テストの実施順序や工数の配分、進捗管理の単位として使用可能になった因子（各テスト観点）の水準を列挙

テスト俯瞰図を作成

テストアーキテクチャを検討
ポイント

テストアーキテクチャ表

テスト俯瞰図品質状況に応じてシステムテストの内容を分岐できるよう4パターンのアーキテクチャを検討
テスト優良
バグ収束型

テスト優良
バグ非収束型

テスト不良
バグ収束型

テスト不良
バグ非収束型ポイント

モモテツ

テストタイプの実施有無や実施順序、工数配分を設定

・テストアーキテクチャの内容を図示することで一目で把握できるようになり、認識合わせをし易くなった。
・実施内容や順序に加え、工数も併記し、各テストタイプのボリューム感も把握できるようにした。

テスト詳細設計

7

テスト詳細設計書

テストアーキテクチャ設計で導出したテストフレームおよび因子水準一覧を使用し、機械的に入力

テスト
フレーム一覧

しかし、全水準を確認するのは現実的ではない

選定基準により、テストする水準を絞り込み

因子水準
一覧

ポイント

選定基準により、テストケースの爆発を防ぎ、効果のあるテストケースの実施を実現

因子水準の入力
モモテツ

テスト対象選定基準の設定

テスト詳細設計（探索的テスト）
方針の策定■ 探索的テストの工数ボリュームを、アーキテクチャ設計で定めたパターンに応じて決定
目的：品質状況に応じた探索的テストの使い分け■ リスクベース且つピンポイント性の高いテストを実行
目的：市場バグのすり抜けを低減■ 30分から2時間程度の細かなセッションに分割して、テスト実行
目的：テスト進捗の管理/効率的な進行■ 重点項目は複数回、同様のテストを実施する
目的：発生頻度が少ないバグの流出防止■ 各自が行ったテストの内容は一覧化し、確認できるようにする

8

ポイント

・セッションを決めることで、１つの機能/観点のテストの冗長化を防ぎ、メリハリのあるテストを実施
・セッションによる、テスト進捗の管理が可能になる
ポイント

・同様のテストを複数回行うことで、発生頻度の低いバグなどの流出リスクを低減
・探索的テストは確認内容に個人差が生じやすいテストであるため、複数名で確認することにより信頼度を向上
ポイント

・他メンバーのテスト内容を共有することで、新たな探索視点を発想
・探索的テストの成果物として、履歴を残す

目的：テスト履歴の管理、テスト内容を共有による探索箇所の発想拡大■ テスト担当者の専任化はせずに、複数メンバーで分担して、テストする。
また、重点項目はテストスキルを考慮した上で、担当者を選定する
目的：個人差による探索視点の発想拡大、バグ検出効率の最大化を狙う

フローの策定ポイント

ODC分析によって、狙うべき「テスト対象」「テスト条件」をピンポイントで特定可能

モモテツ

探索的テスト期間中は、①～⑥を日々繰り返し実施する