1メンバー：飯沼2

１．チーム紹介 普段はソフトウェア検証に携わっており、要件がテストケースとマッチしていると感じられることでテストする自分がイイと思えるようなテストを目指している。

3

２．概要
 ASTER様の開発部門からテスト設計を依頼された。実施可能なテスト内容の全容が分かるテスト設計書を作成し、開発部門がテストの十分性を確認する。

4

３．方針その１
 本テスト設計の導入により、従来よりも全体のコストを抑え、短い納期で品質が良いものを目指す。
具体的には業務プロセスの見える化を行うことで効率化すること。また分析に無駄のないことである。

5

４．方針その２
 テストを実行するテスター（自分）がイイと思えるものを目指す。
具体的にはソフトウェアの要件とテストケースがマッチしていると感じられるように設計することである。

6

５．テスト設計の特徴その１
 DMM（機能分析表）を取り入れたモデリングへのアプローチ方法とソフトウェア品質やバグを分析する力である。
DMMとは３×３マスを一つのDMMとする整理ツールと分析ツールの２つの役割を持ち、モデリングやアイデア出しなどを助けてくれるものである。

7(5-1)なぜDMMなのか テスト対象をモデル化するためにDFDを使いたいが、階層化するためには抽象化の度合いを揃える技術など、習得するのが難しいという課題があった。
そこでDMM（機能分析表）を用いて先に階層化を行い、DFDを作図するための設計図を作ることにしたのが導入するきっかけだった。

8(5-2)良かった点/悪かった点～DMMとは何なのか～ 良かった点

思わぬ発見があった。

整理だけでなく分析目的にも向いていた。
 悪かった点

事前にExcel上で分割することで解決した。

１つのDMMは８つまでに分割が制限されるため、分割目的では使いにくかった。

9６．テスト設計の特徴その２
 DFD（データフローダイアグラム）から生み出されるテストケースを使っている。

テスト対象をモデル化することで可視化し、システム理解を深め、プロセス（機能）間の関連性の整理と外部（データの発生源/行き先）との入出力の整理を行うことによって、高い精度で抜け漏れのないテストケースを効率よく作成できる。

10７．テスト設計プロセス～DMM活用ポイント～

整理

工夫

分
析

11８．DMM（機能分析表）～Diamond Mandala Matrix～
 DMMは中央のマス目にコンテキスト名を書き、周囲の８つのマス目には整理/分析した対象の名前を書くというものである。

12(8-1)DMMでプロセスを見える化～テストスコープと機能要求の整理～

整理
①
整理
②

13(8-2)最上位のDMM～機能要求の全体を俯瞰する～

中央から見ていくのがコツ。

インパクトの高いテ
スト領
域はオ
レンジ
色に！

14(8-3)どんどん階層化していく～機能要求の整理～

抜け漏れを早期に発見しよう！

15(8-4)テストレベルも見える化へ～作成したDMMを活かした工夫～

工夫16(8-5)こんな使い方もできるDMM
単体テスト～工夫した点～ 外部結合(枠)

システム
テスト
（枠）

テスト
(枠)

内部結合
テスト
（罫線）
すべてナンバー管理！

17(8-6)DMMで秀でたエラー推測～テストに必要な分析力～分析

18(8-7)ストイックなテスターへ！
～分析には気合も～不具合を絶対に見つけたい気持
ちがピンポイン
トでエラーを推測する。

アイデアを無理やり絞り出す！

19

９．テスト効率を考えたDFD～理解し易さ～ テストし易い大きさのDFDを作る。

DMM（機能分析表）なら丁度良い大きさのDFDが自然にできるようになる。

20(9-1)リバースするプロセス～DFDの作り方～
 ①上層からトップダウン式に作る。

関連性を整理し、必要な外部を洗い出す。
 ②下層からボトムアップ式に作り直す。

システム構成図と洗い出した外部とで入出力の整理を行う。

21(9-2)DFDを作図する～データフローダイアグラム～

22(9-3)トップダウン型

粒度の粗い全体図（階層レベル１）を作る。

23(9-4)コンテキストダイアグラム～システム全体の文脈を表す～
抜け漏れ防止に外部と通信カラオケシステムとの文脈を表すデータの流れを書く！

24(9-5)ボトムアップ型

最も粒度の細かい図（最下層）から作る。

25(9-6)データ辞書を作成する～DMMとDFDを読むために～DMMやDFDは見るために、データ辞書はそれを読むために必要になる。

26(9-7)テスト条件の抽出～DFDからの導き～

データの流れをテスト観点に、事前条件、事後条件のデータの流れを確認する。

27(9-8)テストケースの抽出～DFDと原因結果グラフ～要素を抽出する。

抜け漏れの無い組み合わせを作成する。

28(9-9)テスト条件を作成する～テストフレームを作成した後で～テストフレームとは必要なテスト条件の種類の集まり。

テスト条件を作る

29(9-10)DFDとテストベースの関係～テストケースを作成するために～

テスト条件にインプット！

30

１０．DMMのまとめ～方針の回収～ DMM化するプロセスをExcelで見える化できた。

Excelで！

機能要求を一覧化→分析→分解→階層化
DMMへ！
Excel から DMMへ スムーズに移行でき、工程に無駄がなかった。

31

１１．DFDのまとめ～方針の回収～ DFDの作図はDMMを設計図として見える化したことでスムーズに行うことができ、またDFDを作図するにあたってはプロセス（機能）間の関連性の整理と外部（データの発生源/行き先）との入出力の整理の工程を分けることで、作り直しの手間を最小限にできた。また図の精度もシナリオテストまでのテストケースを作成可能なほど高かった。

32

１２．テストコンテナ～テスト観点のグループ～ 同じまとまりとしてテストすべきテスト観点のグループを作る。
まず枠組みを作る。

33(12-1)テストコンテナへの導き～テストアーキテクチャ設計へ繋ぐもの～
枠組み

目的や種類に合わせてテストコンテナをグルーピングする整理34(12-2)テストコンテナの整理～テストのデザインパターンを検討する～テストコンテナを目的別に分割する。

35(12-3)テストコンテナの関連図～重複するテストの行方～

重複するテスト項目がある場合は、やるかやらないかを明確に示す必要がある。

36

１３．テストプロセスの全体図～テストアーキテクチャ設計へ入る前に～テスト担当者やテスト目的を明確にする。

37

１４．テスト詳細設計～機能要求や要件の抜け漏れを防ぐ～

テストケースを作成する

38(14-1)マトリクスの作成～テストケース一覧～

機能要求と必要な要件を網羅するマトリクスを作成する。

39

１５．自分でイイと思えたか～方針の回収～ プロセスを見える化したことによって要件からテストケースまで高いトレーサビリティを保つことができ、作成したテストケースは取り除きたいバグを念頭に要求ともマッチしてイイテストが実行できると思えるものが作れた。

40

１６．まとめ テスト設計コンテストを通じ、テストでは要件や要求の抜け漏れだけでなく、限られた時間で潜在するバグをどうすれば取り除けるかを追及することが必要だと気づいた。

41

以上です。
ご清聴ありがとうございました。