JaSST '18 Hokkaido

不完全な業務フロー図から網羅的にテスト設計するための状態遷移図の活用事例
2018年11月30日
株式会社ＮＴＴデータ 町田欣史
© 2018 NTT DATA Corporation

発表の流れ1. 業務フロー図を用いたテスト設計の問題と対策
2. 状態遷移図を用いたテスト設計の問題と対策
3. 適用事例
4. まとめ© 2018 NTT DATA Corporation

2

1. 業務フロー図を用いたテスト設計の問題と対策© 2018 NTT DATA Corporation3

1.1 業務フロー図とは業務システム開発では業務フロー図を作成することが多い
業務における作業の流れ（業務フロー）とシステム化する作業（機能）を明確にする
UMLのアクティビティ図で書いた例
担当者

管理者

業務で実施する作業/機能作成
登録
確認
承認依頼

修正

確認
却下

削除
承認

© 2018 NTT DATA Corporation

4

1.2 業務フロー図の位置づけ
業務フロー図に基づき、設計やテストが行われる業務フローを確認する
テストケースの作成

発注者と受注者で合意形成
業務フロー図テストケース

システムテスト要件定義
外部設計

業務を詳細化
単体テスト

内部設計

コーディング© 2018 NTT DATA Corporation

5

結合テスト

1.3 業務フロー図の問題
要件定義工程で業務フローが網羅的に書かれないことが多い
業務フロー図に書かれる業務フローの種類
基本フロー

利用者が業務の目的を達成するときのごく典型的なフロー

代替フロー

基本フローとは別の手段で業務を完了させるフロー

例外フロ―

成功を妨げる条件下でのフローや特定の条件下でのフロー

特に代替フロー・例外フローの一部が書かれないことがある

不完全な業務フロー図© 2018 NTT DATA Corporation

6

1.4 業務フローが網羅的に書かれない理由
業務フロー図が不完全になる理由はいくつか考えられる① 要件が固まっていない② ステークホルダーが理解できない• 要件定義工程ですべての業務フローを抽出するのが難しい。

• システム開発の知識に乏しい人は厳密すぎる業務フロー図を見ても理解できない。

④ 「網羅」の基準が高すぎる③ 業務が複雑すぎる• システム化対象の業務が複雑すぎると、業務フロー図も必然的に複雑になるため、省略せざるを得ない。

• 要件定義工程で書くべき以上のことを求めている。

これは最後の「まとめ」で触れる© 2018 NTT DATA Corporation

7

1.5 不完全な業務フロー図を基にしたテストの問題
不完全な業務フロー図では十分なテスト設計ができない
不完全な業務フロー図

不完全なテストケース

業務フロー図テストケース

システムテスト

要件定義

結合テスト

外部設計
単体テスト

内部設計

本発表における課題：
この状況でどうやって網羅的にテスト設計をするか
コーディング© 2018 NTT DATA Corporation

8

1.6 対策案（１） 完全な業務フロー図を書く
本来あるべき対策だが、複雑な業務には適用しづらい２つの問題をクリアする必要がある。
① 要件が固まっていない→ 要件が固まってから業務フロー図を詳細する② ステークホルダーが理解できない→ 発注者向けと開発・テスト担当者向けで異なる業務フロー図を書く

対策案 要件定義工程の後に、テストのために業務フロー図を完全化する

不採用
さらにもう１つの問題がネックになる。
③ 業務が複雑すぎる→ 業務フロー図が複雑で、テスト設計が困難である© 2018 NTT DATA Corporation

9

1.6 対策案（２） 不完全な業務フロー図のままでなんとかする状態遷移図を利用することで状態遷移テスト技法を使える
業務フロー図に書かれていない情報を補う必要がある

この情報が書かれるドキュメントはないか？
業務フロー図は、ある作業を行っている状態とその遷移を表現しているため、状態遷移図の一種と考えることができます竹内正治、“業務システム分析のためのUMLモデリング演習 第7回 情報の流れと状態、”
日経ITプロフェッショナル、10月号、130-135、2005

対策案 業務フロー図に記述されない例外/代替シナリオを表現するため、状態遷移図を利用する© 2018 NTT DATA Corporation

採用10

2. 状態遷移図を用いたテスト設計の問題と対策© 2018 NTT DATA Corporation

11

2.1 状態遷移図とはシステムの状態に着目して、システムの振る舞いをモデル化する
対象とするシステムの状態の遷移に沿って、遷移を起こすイベントや遷移条件が記述される。
状態遷移を引き起こす作業などのトリガ
イベント

イベント発生時に遷移するための条件
状態イベント[条件]状態イベント

イベント[条件]
状態イベント/アクション遷移と同時に実行される動作© 2018 NTT DATA Corporation

122.2 業務フローと状態遷移図の関係
状態遷移図でも業務フローの代替/例外フローを表現できる
業務フロー図
担当者

状態遷移図
管理者
作成

作成

未登録

業務フロー図の作業/機能と状態遷移図のイベントが対応

登録

登録
修正中

確認

登録済み
削除

承認依頼
承認依頼

修正

登録
修正

確認

確認

承認待ち

却下

削除

確認

却下
承認

承認

承認済み

業務フロー図の作業/機能の結果と状態遷移図の状態が対応© 2018 NTT DATA Corporation

13

削除済み

2.3 状態遷移図の問題点
業務システム開発では、状態遷移図を作成しないことがある
状態遷移図を作成しない理由①業務全体の流れが分かりにくいので、発注者との合意形成が難しいシステムの挙動について開発者間で認識を合わせるためには必要では？

②業務システムでは「状態」を意識することが少ない• 画面遷移図は書くが、システムの状態はあまり気にしない③業務システムの「状態」は、設計が進まないと考慮するのが難しい（状態の例） ・ データの状態・ 画面の状態© 2018 NTT DATA Corporation

14

2.4 対策案
テストのために状態遷移図を後から作成する
状態遷移図がない場合に、どうするか
案１

業務フロー図を完全にする
不採用
業務が複雑だと・・・という問題に逆戻りする

案２

不採用
状態遷移図以外に使えるものを探す
何かあるかもしれないが、現時点で妙案がない

案３

状態遷移図を後から作る工数の増加が許容できれば実現できる© 2018 NTT DATA Corporation

15採用

2.5 状態遷移図の作成
要件定義工程後に作成したドキュメントから状態遷移図を作成する
状態遷移図の作成に必要なドキュメント• 業務フロー図• 業務を詳細化した設計書
要件定義後に作成したドキュメントを利用
状態遷移図の作成に必要な記述内容

要素
状態イベント

必要な記述内容• 機能実行後の結果

要素（例）データベースの更新結果• 業務フロー図上の機能/作業• 機能において状態を変えるトリガ（例）画面上で発生するイベント
画面遷移が発生するイベント
バッチ処理を起動するイベント© 2018 NTT DATA Corporation

16

条件アクション必要な記述内容• 機能において状態が変わる条件（例）入力チェック条件
画面状態を決める条件
画面遷移条件• 状態が変わるときに行う
作業3. 適用事例© 2018 NTT DATA Corporation17

3.1 適用事例の概要⚫ 金融系の大規模システム開発プロジェクト⚫ 状態遷移図を作成していない
テスト設計者が状態遷移図を作成⚫ 業務フロー図の記述が粗い
適用した業務フロー図の例 … 基本フローしか書かれていない

登録
承認依頼
承認

© 2018 NTT DATA Corporation18

3.2 状態遷移図の作成に使用したドキュメント
ドキュメント
抽出する
要素

状態業
務フロー
図

処
理
設
計書

機能実行後の結果✔

✔

業務フロー図上の機能/作業✔

ドキュメントに記述される内容

画面
定
義書

画面
遷
移図

イベント
条件

機能において状態を変えるトリガ

✔

✔

✔

機能において状態が変わる条件

✔

✔

✔

アクション 状態が変わるときに行う作業© 2018 NTT DATA Corporation

19✔

3.3 適用手順 (1)基本フローに対応する状態遷移の作成
業務フローの基本シナリオに対応する状態遷移を作成する

登録
登録

登録済み
承認依頼

承認依頼

承認待ち
承認

業務フロー図業務フロー図の「機能」を状態遷移図の「イベント」として抽出

承認
承認済み

状態遷移図
© 2018 NTT DATA Corporation

20

業務フロー図の「機能」が実行された後の状態を状態遷移図の「状態」として抽出

3.3 適用手順 (2)状態遷移する条件の抽出
ある状態に遷移するための詳細な条件を抽出する

登録
登録

承認依頼から承認に進むための条件を抽出

承認依頼

登録済み

承認依頼[案件種別：その他以外]
承認待ち

承認

業務フロー図

画面定義書

画面遷移図

承認

承認依頼画面

承認依頼画面→承認画面

承認済み

入力チェック
条件

遷移条件

状態遷移図
© 2018 NTT DATA Corporation

承認待ち状態に遷移する条件を追記

21

承認依頼
[案件種別：その他かつ 案件詳細：あり]「案件種別」「案件詳細」を設定するための記述を次に探す

3.3 適用手順 (3)代替/例外フローに相当する状態遷移の追加
代替/例外フローに相当する状態遷移を設計書から導出する案件種別により遷移を分岐「案件種別」「案件詳細」を設定する情報を追加

登録

登録

登録済み

承認依頼[案件種別：その他以外]
他以外]

承認依頼
承認

業務フロー図

処理設計書

処理設計書

登録

詳細情報登録案件種別を登録する

詳細情報を登録する

承認待ち

22

詳細情報
登録済み

承認依頼

承認
承認済み

状態遷移図
© 2018 NTT DATA Corporation

詳細情報登録[案件種別：その他]

詳細情報に関する状態を追加

3.4 適用結果
代替/例外フローを状態遷移図で表し、テストケースを抽出できた
紹介した業務フローについて• 業務フロー図上では1本のフローで表現されていたが、データの種別により追加機能を実行する必要がある代替フローを補完できた。
その他の業務フローについて• 「取消」に関する業務フローが「取消通知受領」機能から始まっている、すなわち「取消」ができる／できない条件が記載されていなかったが、本手法を適用することで、それらが明確になった。
状態A• 入れ子の状態をもつ複雑な業務フローに対して、状態遷移図を作成することで、代替/例外フローを補完できた。

状態A1

状態A2
状態A3

入れ子の状態© 2018 NTT DATA Corporation23

4. まとめ© 2018 NTT DATA Corporation24

4.1 得られた効果
網羅的なテスト設計だけでなく、品質改善やスキル向上も実現した
テスト設計の網羅性向上
状態遷移図を作成することで、代替/例外フローに相当する状態遷移を抽出した。それを基に状態遷移テスト技法を適用することで、業務フロー図からのテスト設計では漏れていたテストケースを追加できた。
設計書の品質改善 ※副次的効果
業務フローの詳細な条件を確認することで、設計の不統一を発見できた。
テスト設計者の業務知識向上 ※副次的効果
業務フロー図だけでなく、様々な種類の設計書を読み込む過程で、業務知識の拡大につながった。

© 2018 NTT DATA Corporation25

4.2 今後の課題(1)
業務システム開発における状態遷移図について改めて考えるべき作成するドキュメントについて• 状態遷移図が有効なら初めから作っておけばよいのでは？
• 状態遷移図を作成する意義や作成方法を見直し、開発者に理解させる必要がある。
• 状態遷移図が（元の）業務フロー図を包含しているなら、状態遷移図だけでよいのでは？
• 発注者が理解できるかどうかが大きな課題だが、業務システムの開発者も理解できない人が多いと思われる。
• 完全な業務フローを書くのと、どちらがよいのか？
もしくは、両者を適切に使い分けるべきなのか？
• どの方法が最も効率的か、効果的かを検証してみたい。
© 2018 NTT DATA Corporation26

4.2 今後の課題(2)モデルの抽象度を適切に決める必要がある
業務フローに対するテストで確認すべきことについて• 要件定義よりも後に作成された成果物から状態遷移図を作成し、テストケースを作成している。
すなわち、本来は別のテストレベルで確認すべき内容をテストしているのでは？
• テストを無駄に増やしすぎている可能性がある。
このテストレベルで求められる詳細度を再考する必要がある。
• 業務フローは本当に不完全だったのか？
要件定義で求められる詳細度を超えていたのでは？
• 業務フロー図に書くべき代替/例外フローの詳細度を再考する必要がある。と同時に、開発プロセス全体で、どの工程（レベル）で何を定義すべきかを決める必要がある。

© 2018 NTT DATA Corporation27

© 2018 NTT DATA Corporation

まとめと今後の課題■提案手法の特徴のまとめ【利用シナリオ】
業務システムの受託開発プロジェクトのテストにおける、業務フロー図に記述されていない代替/例外シナリオの補完【メリット】
業務フロー図と各業務を詳細化した設計書から、状態遷移図に相当する設計情報を抽出し、代替/例外シナリオを補完できる【制約】
提案手法の適用が過剰となる業務フロー図が存在する■今後の課題適用案件を拡大しての適用効果の検証・適用条件の具体化• 適用効果の定量的な測定• 適用条件の具体化（適用が過剰となる業務フローの特徴づけ）【課題】
業務フロー図をテストベースとしたテストとしては粒度が細か過ぎる分岐も抽出してしまう。状態遷移図が必要となるほど複雑な状態遷移をする業務は限られている[8]© 2018 NTT DATA Corporation29