北のテストマン フロアシート＜テスト方針＞

テスト設計全体像

・ユーザー体験のテストを重視した設計とする・テストの保守性を考慮した設計とする

テスト詳細設計を含むテスト設計の全体像を以下に示す。

テスト要求分析

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

ＡＳＴＥＲ通信カラオケ
ソフトウェア要件定義書/用語集/補足資料

テス トタイプ

１．テスト優先度検討

機能テスト

ユーザビリティテスト

性能テスト

互換性テスト

１．要件取り纏め

1-3.要求機能の明確化

1-1.要求事項精査

1-4.要求機能の組合せ明確化

利用頻度5

多くの機能は毎日利用される。

リス ク影響度
合計期待される機能が動作しないことは、5 クレームやリコール、評判の低下による競合へのユーザ流出を招く。

ユーザはシステムを毎日利用し、使い5やすさはその都度期待される。
多くの機能は、操作による素早いレ4スポンスを期待されている。
旧機材や利用環境など、互換性が要4求される場面は多い。

セキュリティテスト

1

攻撃者に攻撃された時に関係する。

信頼性テスト2

障害発生時に関係する。

保守性テスト2

障害発生時に関係する。

10

テストにより取り除かれるべき使い難4 さは、ユーザに不満を抱かせ、競合へのユーザ流出を招く。

9

ユーザ操作のレスポンスが、期待より4 も大きく遅れる場合、ユーザに不満を抱かせ、競合へのユーザ流出を招く。

8

旧機材が利用できなかったり、想定した利用環境に対応していない場合は、オーナーに不満を抱かせる。競合への乗り換え要因となりえる。
データの不正利用や不正操作による業務妨害の発生は、サプライヤや5オーナへの損害、信用の失墜につながる。
故障しやすく、回復手段に難があった
りすると、オーナーに不満を抱かせ2る。競合への乗り換え要因としては小さい。
故障解析がし難いと、故障対応の満足度が下がり、オーナーに不満を抱1かせる。競合への乗り換え要因としては小さい。
376

43[テストタイプ優先度表]

２．テストアーキテクチャ設計

1-6.確認事項
反映[イベントフロー][ステークホルダー
要求洗い出し]1-2.要求事項として取り纏め
機能/非機能機能

1-5.各イベント時の状態遷移明確化[ユースケース図][アーキテクチャ設計図]

1-6. 要件定義書
内容確認

1-7.要求事項
追加/更新

確認[状態遷移図]確認事項
反映

テスト詳細設計[イベントフロー][状態遷移図]１．因子水準決定[要求事項一覧]

1-1.因子の定義[要件定義書内容確認事項][要求事項一覧]

テストベース情報

２．テスト観点の抽出

2-1.テスト観点抽出[因子水準一覧]

2-2.テスト観点図の作成
ボトムアップアプローチ[アーキテクチャ図]

相互補完

・テストケースのグループ化
テスト条件

・テスト実施優先順位付け[観点抽出表]・テストの目的・確認事項

トップダウンアプローチ
２．テストケース作成[観点抽出表][テスト観点図]

２－１.テストケース作成[テストケース]

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

1テスト要求分析
１．要件取り纏め
1-1.要求事項精査

1-2.要求事項として取り纏め

ステークホルダーごとの要求を分析し、テスト観点として抽出すべき要求を明らかにする●「要件定義書」から、機能要求事項を全て抽出(1)カラオケ利用の流れを整理し、ステークホルダーとの関連を特定する●「要求機能番号」を併記しトレーサビリティを確保●「ステークホルダー要求」からも抽出

この段階では未完成！テスト要求分析工程の中で何度も見直す● 「従業員」は関連イベント全てが要件定義書

ステークホルダー要求オーナーにも含まれているため「オーナー」に含める● 「サプライヤー」はステークホルダーから除外。※サプライヤー側
でテストを実施

要求事項一覧

●従って、考慮するステークホルダー
は、「ユーザー」と「オーナー」(2)ブレーンストーミングでステークホルダーの要求を洗い出す●ここでは要求仕様書だけでは読み取れない非機能要求をつかむ

1-3.要求機能の明確化要求する機能を明確化するために、ユーザー視点・オーナー視点でユースケース図を作成

ステークホルダー要求

ユースケース（ユーザー）

緑の網掛

コアな要求

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

肌色の網掛

優先順位する要求

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

網掛け無しその他

観点に必要か判断要ユースケース（オーナー）

2
Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

テスト要求分析
１．要件取り纏め
1-4.要求機能の組合せ明確化

1-5.各イベント時の状態遷移明確化｜機能間の繋がりを明確にするため、イベントフローを作成｜各機能のイベント動作時の状態を明確にするため、状態遷移図を作成●要件とユースケースがインプット●インプットはイベントフロー、イベントに関連する状態の遷移を表す●カラオケシステムを利用するシナリオに沿って機能間●機能テストのシステム状態確認のインプット情報として活用するのつながりを表す●サービス提供などによる機能追加が行われた場合、どのシナリオが関連するのか一目で理解できるようになり、システム全体の保守性が向上する。

状態遷移図
イベントフロー●利用者の活動(操作）を俯瞰できることになったので、あるべき活動がわかり、要件定義書の内容不備・不足が明確になる。
イベントフロー
Input凡例）

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

3

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

2.テスト観点の抽出
2-1.テスト観点抽出｜イベントフローに関するテスト要素と品質特性から、テスト目的を抽出●どのような観点で、何を対象にテストし、どんな確認をするのかを一覧化●テスト要素は汎用的な言葉を用いイベントフロー間で共通
テスト要素とテスト観点の組み合わせが同じ＝類似したテスト

要件定義書内容確認事項

テスト観点抽出表

2-2.テスト観点図の作成｜品質特性の観点からテストすべき観点と、その対象を検討●何をテストすべきか、何処をテストすべきか、対象外のテストは何かを整理

1-7.要求事項追加/更新｜イベントフロー作成時に、要求として追加すべき事項が見つかった場合は、要求事項一覧に要求を追加する● 「 」は今回のテストスコープ内、「 」はスコープ外と判断テスト観点図●ここで要求の追加を繰り返すことで抜け・漏れを防ぐことに繋がる
要求事項一覧

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

3

テストアーキテクチャー設計
1-1. 要件定義書内容確認

1-2.テストアーキテクチャ設計図作成｜テストタイプ毎に、利用頻度とリスク影響度により優先度を検討する●テスト優先度は、テストアーキテクチャ設計でテスト実施順検討の参考値となる（１）テスト観点のうち要求仕様の不明点を発注者に確認しテスト観点の要否を判断
仕様確認要のグループ

テスト観点図要件定義書内容確認事項
テスト優先度

テストタイプ
機能テスト

ユーザビリティテスト

性能テスト

互換性テスト

環境テスト

セキュリティテスト

信頼性テスト

保守性テスト

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

抽出利用頻度確認

10
回答

98

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

判断

判断●機能不足がないことを確認【盛り込む】

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

643

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

6

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

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

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY

6

テスト詳細設計１-1.因子水準決定

１-2.テストケース作成｜テストの因子を洗い出し、因子水準一覧を作成｜これまでの成果物から、テストケースを作成●水準対象はカラオケシステム利用者（ユーザー）の特徴に関する因子●要求分析～アーキテクチャ設計～詳細設計（因子水準決定）までの因子水準一覧

成果物がインプットとなる●イベントフロー単位にテストケースを作成●改修時にどのテストケースを 実施すればよいか判断しやすい構成にする
テストケース●それぞれの因子を組み合わせたものがテスト実施パターンとなる因子水準組み合わせ

項番
１
２
３
４
５
６

章タイトル
テストルート、状態遷移
テスト条件
テスト観点
テスト手順
代替テスト手順
補足資料

インプットとなる成果物
イベントフロー、状態遷移
イベントフロー
観点抽出表
イベントフロー、状態遷移、観点抽出表
イベントフロー、状態遷移
イベントフロー、状態遷移

Copyright © NTT COMWARE CORPORATION 2016
NTT COMWARE CORPORATION CONFIDENTIAL PROPRIETARY8