テスト設計コンテスト‘１6

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARYはじめにチーム紹介
昨年出場した「TCC」からテスト設計の熱い志を引き継いだ6名のチーム

メンバー紹介リーダー：工藤北のテストマン裕（くどうゆたか）

気になることにはとことん熱中：蛯名桃子（えびなももこ）

環境適応能力◎：米澤英史（よねざわひでひと）

視野の広いムードメーカー：平野一人（ひらのかずと）

見守り主義：原田貴史（はらだたかし）

大胆な梃入れが得意：瀬賀剛（せがつよし）

縁の下の力持ち

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

1

1. テスト方針｜顧客システムの目的や特性からテスト方針を決定●ASTER通信カラオケは、今後もどんどんカラオケのサービスを向上していき、ASTERのユーザーを広げ、かつリピーターを増やしていく●そのためにテスト設計が出来ることを考えるシステムの目的｜

ユーザーに快適でリッチなカラオケ体験を提供する
ユーザー体験のテストを重視した設計とするシステムの特性｜

通信カラオケシステムは今後も繰り返し開発が行われると予想
テストの保守性を考慮した設計とする

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

22. テスト設計の全体プロセス｜テストベースは要件定義レベルのため、システムテストレベルの設計を実施●要求範囲とテスト観点を明確にし、テスト方針に沿ったテストケースを作成する｜テスト要求分析｜テストアーキテクチャー設計｜テスト詳細設計●テストしたい要求を抽出する●テストタイプごとに優先度を決める●テストの因子を洗い出し、因子水準組み合わせパターンを作成する●テストしたい観点を抽出する●テスト観点をグルーピングしてテスト構造を整理●テストしたい観点のモデリングする●テストしたい範囲を導き出す

北のテストマン●テスト方針・優先度からテスト順を決めテスト全体像を表す●テスト要求分析、アーキテクチャ設計の成果物から、テストケースを作成する

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

3３.テスト要求分析(1/11)
全体プロセス

｜テスト要求分析の目的●テストしたい要求の範囲とテスト観点を明確にする
１．要求事項の精査

２．要求事項を取り纏める

３．要求機能の明確化●ﾌﾞﾚｰﾝｽﾄｰﾐﾝｸﾞ

ステークホルダーごとの要求を分析し、テスト観点として抽出すべ
き要求を明確にする「ソフトウェア要件定義書」から、機能要求事項を全て抽出し記載する

ユースケース図を用いシステムに対し何をするのかをステークホルダー視点でモデル化する●分析

４．要求機能の組み合わせを明確化

５．各イベント時の状態遷移を明確化

６．要求定義書の内容確認

要件定義書

イベントフローを作成し機能間の繋がりを明確にする

機能ごとにイベント発生時の状態を明確にする要件が不明確な点や要件が不足していると思われる内容について取りまとめて発注者へ確認する

7．テスト観点抽出

8．テスト観点図作成各分析で明確になった要求から、テストすべき観点を抽出する抽出した観点を精査し観点モデルを作成する｜方法

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

4

３.テスト要求分析(2/11)
３-１要求事項の精査

ステークホルダーごとの要求を分析し、テスト観点として抽出すべき要求を明らかにする(1)カラオケ利用の流れを整理し、ステークホルダーとの関連を特定する● 「従業員」は関連イベント全てがオーナーにも含まれているため「オーナー」に含める● 「サプライヤー」はステークホルダーから除外。※サプライヤー側
でテストを実施
●従って、考慮するステークホルダー
は、「ユーザー」と「オーナー」

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

5

３.テスト要求分析(3/11)
３-2要求事項の精査(2)ブレーンストーミングを行いステークホルダーごとの要求を洗い出す●ここでは要求仕様書だけでは読み取れない非機能要求をつかむ
ステークホルダー要求

北のテストマン

緑の網掛

コアな要求

無いとシステムが成り立たない

肌色の網掛

優先順位する要求

便利だがコアではない
観点に必要か判断要

網掛け無し

その他

観点に必要か判断要
Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

6

３.テスト要求分析(4/11)
３-3要求事項として取り纏め「要件定義書」から、機能要求事項を全て抽出●「ステークホルダー要求」からも抽出●「要求機能番号」を併記しトレーサビリティを確保
要件定義書

この段階では未完成！
テスト要求分析工程の中で何度も見直す

ステークホルダー要求

要求事項一覧

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

7

３.テスト要求分析(5/11)
３-4要求機能の明確化｜要求する機能を明確化するために、ユーザー視点・オーナー視点でユースケース図を作成●ユーザー視点の切り口「予約操作」、「演奏操作」、「コンテンツ利用」
ユースケース

北のテストマン●オーナー視点の切り口「オーナー設定」
ユースケース

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

8

３.テスト要求分析(6/11)

３-5要求機能の組み合わせ明確化｜機能間の繋がりを明確にするため、イベントフローを作成●要件とユースケースがインプット●カラオケシステムを利用するシナリオに沿って機能間のつながりを表す
イベントフロー●サービス提供などによる機能追加が行われた場合、どのシナリオが関連するのか一目で理解できるようになり、システム全体の保守性が向上する。
●利用者の活動(操作）を俯瞰できることになったので、あるべき活動がわかり、要件定義書の内容不備・不足が明確になる。

凡例）

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

9

３.テスト要求分析(7/11)

３-6イベント時の状態遷移明確化｜各機能のイベント動作時の状態を明確にするため、状態遷移図を作成する●インプットはイベントフロー、イベントに関連する状態の遷移を表す●機能テストのシステム状態確認のインプット情報として活用する
状態遷移図

イベントフロー

Input

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

10

３.テスト要求分析(8/11)
３-7要件定義書内容確認｜「要求機能の組み合わせ明確化」の結果でてきた不明点を発注者へ確認する●回答は、北のテストマンによる想定回答●回答結果は、「イベントフロー」、「要求事項一覧」にフィードバック

イベントフロー

要件定義書内容確認事項

要求事項一覧

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY11３.テスト要求分析(9/11)
３-8要求事項追加／更新｜イベントフロー作成時に、要求として追加すべき事項が見つかった場合は、要求事項一覧に要求を追加する。
●ここで要求の追加を繰り返すことで抜け・漏れを防ぐことに繋がる

要求事項一覧

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

12

３.テスト要求分析(10/11)
３-9テスト観点抽出｜テスト要素に対するテスト目的を抽出する●イベントフローより、必要なテスト要素をブレーンストーミングにより抽出●テスト要素を品質特性（※1）でマッピングし、テスト要素に対するテスト観点を明確化●各テスト要素・品質特性（テスト観点）から、テスト目的を定義
テスト観点抽出表※1：（JIS X 25010）
北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

13

３.テスト要求分析(11/11)
３-10テスト観点図作成｜品質特性の観点からテストすべき観点と、その対象を検討●何をテストすべきか、何処をテストすべきか、対象外のテストは何かを整理する●「」は今回のテストスコープ内、「」はスコープ外と判断

テスト観点図北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

14

4.テストアーキテクチャ設計(1/4)
全体プロセス｜テスト観点をコンテナ化し、テスト構造の全体像を俯瞰できるよう整理しテスト順を決める

テスト要求分析成果物

Input

１．テスト優先度検討

２．アーキテクチャ設計

テストタイプ毎に、利用頻度とリスク影響度による、テスト優先度の検討するテスト観点をグルーピングし、テスト構造を整理する。
テスト方針・優先度を踏まえテスト順を決める

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

15

4.テストアーキテクチャ設計(2/4)
4-1テスト優先度検討｜テストタイプ毎に、利用頻度とリスク影響度により優先度を検討する●テスト優先度は、テストアーキテクチャ設計でテスト実施順検討の参考値となる
テスト優先度
テストタイプ
機能テスト

ユーザビリティテスト

性能テスト

互換性テスト

環境テスト

セキュリティテスト

信頼性テスト

保守性テスト北のテストマン

利用頻度

リスク影響度
合計期待される機能が動作しないことは、多くの機能は毎日
55 クレームやリコール、評判の低下によ利用される。
る競合へのユーザ流出を招く。
ユーザはシステムテストにより取り除かれるべき使い難を毎日利用し、使い4 さは、ユーザに不満を抱かせ、競合へ5やすさはその都度のユーザ流出を招く。
期待される。
多くの機能は、操ユーザ操作のレスポンスが、期待より作による素早いレ
44 も大きく遅れる場合、ユーザに不満をスポンスを期待さ抱かせ、競合へのユーザ流出を招く。
れている。
旧機材との互換性
旧機材が利用できない場合は、オー4 が要求される場面
3 ナーに不満を抱かせる。競合への乗は多い。
り換え要因となりえる。
システムの連続運
よくある使い方に支障がある場合は、用・多量同時利用
3 オーナーに不満を抱かせる。競合へ
4は多く行われていの乗り換え要因となりえる。
る。
データの不正利用や不正操作による業務妨害の発生は、サプライヤや攻撃者に攻撃され15オーナへの損害、信用の失墜につなた時に関係する。
がる。
故障しやすく、回復手段に難があった
りすると、オーナーに不満を抱かせ障害発生時に関係22る。競合への乗り換え要因としては小する。
さい。
故障解析がし難いと、故障対応の満障害発生時に関係足度が下がり、オーナーに不満を抱21する。
かせる。競合への乗り換え要因としては小さい。

10987764

3

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

16

4.テストアーキテクチャ設計(3/4)
4-2テストアーキテクチャ設計｜テスト観点図の要素をグルーピングしアーキテクチャ設計図を作成（１）テスト観点のうち要求仕様の不明点を発注者に確認してテスト観点要否を判断する
抽出

テスト観点図から仕様に関わる観点を抽出しグルーピング確認、回答 要求仕様について不明点を発注者に確認し回答を得る
判断

回答結果からテストアーキテクチャ設計図への盛り込み要否を判断する

テスト観点図仕様確認要のグループ

要件定義書内容確認事項
確認

抽出

回答

テストアーキテクチャ設計図

判断

判断【盛り込まない】●機能不足がないことを確認できた●システム利用目的が網羅されていることを確認できた【盛り込む】●重要な操作・時間のかかる操作が間違わずにできる観点は要求仕様である●いたずらや変則操作への対応は要求仕様である

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

17

4.テストアーキテクチャ設計(4/4)
4-2テストアーキテクチャ設計（２）テストアーキテクチャ図を作成する●各テストをテストタイプ毎に分けた後、それらをテスト条件・方法毎にグループ分けする●テストタイプ優先度とテスト方針を参考にしてテスト順を決める●テスト方針「ユーザビリティを重視」⇒テストは早期に実施するように設計
テストアーキテクチャ設計図

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

18

5.テスト詳細設計(1/3)
全体プロセス｜テストの因子水準を決定し、テストケースを作成する

テスト要求分析アーキテクチャ設計

成果物

成果物

Input

１．因子水準の定義

２．テストケース作成

テストの因子を洗い出し、因子水準一覧と因子水準組み合わせパターンを作成する

テスト要求分析、アー
キテクチャ設計の成果
物から、テストケースを作成する

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

19

5.テスト詳細設計(2/3)
5-１因子の定義｜テストの因子を洗い出し、因子水準一覧を作成●水準対象はカラオケシステム利用者（ユーザー）の特徴に関する因子のみ
因子水準一覧

●それぞれの因子を組み合わせたものがテスト実施パターンとなる因子水準組み合わせ

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

20

5.テスト詳細設計(3/3)
5-2テストケース作成｜これまでの成果物から、テストケースを作成●要求分析～アーキテクチャ設計～詳細設計（因子水準決定）までの成果物がインプットとなる●イベントフロー単位にテストケースを作成●問題発生、改修時にどのテストケースをテストケース実施すればよいか判断しやすい構成で保守性を高める
項番

タイトル

インプットとなる成果物

１

テストルート、状態遷移

イベントフロー、状態遷移

２

テスト条件

イベントフロー

３

テスト観点

観点抽出表

４

テスト手順

イベントフロー、状態遷移、観点抽出表

５

代替テスト手順

イベントフロー、状態遷移

６

補足資料

イベントフロー、状態遷移

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

21

さいごに

｜テスト方針の検証
方針１．ユーザ体験テストの重視●仕様外のユーザ要求を拾うことができた●ユーザ体験テストを多くの観点で実施できた●ユーザビリティテストの早期実施・フィードバックできた方針２．テストケースの保守性●機能の変更・追加時の、テストケースの影響範囲が把握しやすくなり、テストケースの更新がしやすくなった
北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY22ご清聴ありがとうございました

北のテストマンCopyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY23