テスト要求分析チュートリアル
テスト設計コンテスト実行委員

どうしますか？
「会員登録機能を改修しました。テストお願いします」
最初に何をしますか？ 考えてみてください。

[会員登録画面]
お名前(必須、全半角20文字以内)

郵便番号から住所を検索

住所(全角100文字以内)

電話番号(市外局番から)

登録
2

実は

3

必要なテストは判断できますか？
「会員登録機能を改修しました。テストお願いします」• どんなテストをする？
• どんな順序でテストする？
• どれくらいの厚みでテストする？
⇒すぐに判断できませんよね。

4

お話すること

テスト要求分析の一部
開発プロセスの図は以下より：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

5お話すること• テスト開発プロセス（テストプロセス）のうちテスト要求分析 に焦点を当てます。
• テスト設計の良し悪しはテスト設計成果物のみでは語れません。

• やり方は多種多様。
「なぜテスト要求分析を行うか？」考え、自分たちに合うやり方を考えるヒントにしていただければ幸いです。

6

お話すること今回の範囲

集 める(準備含む)

分 ける(分解、分類)
整 理する(構造化)テスト観点を出す テスト計画に反映
7

チュートリアルのながれ

1. テストの課題
2. テスト要求分析とは
3. テスト要求分析のやり方
4. 過去の応募作の審査で気になった点に対して
8

テスト要求分析にまつわるテストの課題

テスト開発プロセスの図は以下より：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

9そんなに困っていないけど、、、「困っているのはテスト要求分析じゃないよ」…？

なんとなくやれてしまうこともある• 長年のつながりで、なんとなくできてしまう• プロセス上それなりのテスト要求分析は行うようになっている

でも…
「テストアーキテクチャに不整合がたくさん」…？
「テストケースが分かりにくいと言われる」 …？

テスト要求分析で失敗していたのかも10困っている時も、もちろんあるテストをすべきことの合意が取れていたはずが…
「なんでここテストしてないのっ！」…？

テスト抜け漏れを指摘されてしまうこともある• 新しいドメインや経験が浅いときは気づきにくい• 体系的、網羅的に抽出できていない「え、ここもテストするの？… 」「ここってこんな動きするの/機能があるの！？」どこまで何をテストをすべきか不明確• なんでそのテストをすべきなのかわからない
11

テスト要求分析の理解レベル• テスト要求分析の説明はすごく簡単に聞こえる

でも…
• 説明の受け手によって理解レベルの深さがマチマチ

12テスト要求分析の理解レベル• テスト要求分析の説明はすごく簡単に聞こえる

でも…
• 説明の受け手によって理解レベルの深さがマチマチなので…
「テスト要求分析とは何か？」を考えてみよう

13チュートリアルのながれ

1. テストの課題
2. テスト要求分析とは
3. テスト要求分析のやり方
4. 過去の応募作の審査で気になった点に対して
14

用語の定義テスト開発プロセスの図は以下より：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

15

本書での用語の意味

以下より（点線の丸を除く）：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

16本書での用語の定義

テスト観点はテストアーキテクチャやテストケースのインプットになる

以下より(吹き出しを除く)：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

17

テスト要求分析では• 以下を決める• どういった目的でテストするか• どこまで、どんなテストをするか

この解釈に大きな壁が存在する

18

どういった目的でテストするかよく言われること• バグを見つけること• ちゃんと動くことを保証すること

もっと深く考えてみる• なぜそこは厚くテストするのか• なぜその部分を先にテストしないといけないのか• そのテストで何の課題を解決したいのか

19

どこまで、どんなテストをするかよく言われること• テストの範囲を明確にすること• インターフェースのある箇所• 他社製のプログラムを使っている箇所• どんなテストをするか明確にすること• 機能テスト、非機能テスト

もっと深く考えてみる• なぜテスト範囲がそこでいいのか• なぜ非機能テストが必要なのか• ××ごと（例えば「機能ごと」）に分けるだけでいいのか20

テスト要求分析の影響箇所
テスト要求分析
成果物

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

テスト
詳細設
計

テスト
実装

テスト
実施

テスト開発プロセスの図は以下より：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

21

テスト要求分析の役割• テスト要求分析結果は、他のプロセスの根拠や背景になる• テスト要求分析の成果物は他の成果物の内容と矛盾がないようにするべき• 他のプロセスと行き来し、フィードバックを取り込みながら進める
意図的に説明できるようにしておかないと、なかなかできない「なぜそう考えたか？ 」が説明でき、ステークホルダーと合意できる内容であること

チュートリアルのながれ

1. テストの課題
2. テスト要求分析とは
3. テスト要求分析のやり方
4. 過去の応募作の審査で気になった点に対して
23テスト要求分析のプロセス
今回の範囲

集 める(準備含む)

分 ける(分解、分類)
整 理する(構造化)テスト観点を出す テスト計画に反映
24

集める(準備含む)

集分

整• テスト要求の集め先は様々
集め先を特定する• テスト対象やプロジェクトの状況にも依存する• まず、集め先を特定する

集める

25

集め先の特定集分

整• 製品やサービス• テスト対象分析をする• テスト対象の使われ方などテスト対象を理解するための分析をする
• ≒仕様

製品や
サービス

26

集める物

集分

• 製品やサービス• テスト対象分析のインプット• 例• 実際の物• 開発時に作成された文書• 設計書• ユーザーズマニュアル• 想定された使われ方(≒仕様)• 問題が起きやすいところ、考えられるリスク

27

整陥りがちなテスト要求分析

集分

整• テスト対象以外から得られるテスト要求を忘れる• テスト対象分析ができていればテスト設計は行える• 頭の片隅で対象以外の分析も本当は行っている→共有しないと、もったいない• テスト対象分析だけで終わってしまうと…
• テスト対象が改修された経緯がわからず、変更に弱いテスト設計になってしまう かもしれない• テストを厚くする箇所が的確でなくなる かもしれない

28

集め先の特定集分

整製品やサービスの周辺には人(ステークホルダー)がいる

使用者の要求生産者の要求…
開発メンバーの要求

テスト
メンバーの要求「どんなステークホルダーがいるか？ 」を考える
29

集め先の特定集分

整• どんなステークホルダーがいるだろうか？
• 手法• 製品やサービスのライフサイクルから考える• いつ、どこで、どんな人がどんな関わり方をするか？

• ステークホルダー識別• 「ソフトウェア及びシステムに直接関与する一次ステークホルダー」「直接的には関与しない二次ステークホルダー」• 「要求とステークホルダーの関係を明らかにするために，ステークホルダーを影響度と重要度の特性で分析する。」(「」内はソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版),
SQuBOK策定部会 編, オーム社, 2014/11 より)

集める(準備含む)

集

分

整

• 特定された集め先からテスト要求を集める
集め先を特定する集める• 本書では下記の例で考える
••
•
•

31

使用者
生産者
開発メンバー
テストメンバー

集める物

集分

整

• 使用者の要求• 使用者の特定と、期待や実使用感の確認• 製品やサービスを利用する人は思った以上に多い。
• 実ユーザー• 利益を得ている人• メンテナンスする人• 使用者の立場により、期待や実使用感は異なる。

32

集める物

集

• 生産者の要求• この製品にかける思惑• プロダクト戦略• フィーチャー• 品質についてどう考えているか• 開発メンバーの要求• 開発時の制限や組織的な思惑• 開発方針• 体制• 品質目標• 予算• 納期• テストメンバーの要求• テスト時の制限や組織的な思惑
33分

整集めるときの注意点

集分

整• 必要な情報を多面的に集められるようにする• 集めた情報を分けて俯瞰する• 手法例：ロジックツリー• 深掘りの方向• 何を必要と思うか、は考えやすい• なぜそれが必要だと思ったの？

• 状況変化の情報を集め忘れないように• 過去プロジェクトからの変化、プロジェクト内の変化• なぜ開発メンバーが休みがちに？ なぜハードを変更？

• MECE（漏れもだぶりもない）か？
深掘りが不足しているところはないか？
34

集められないとき

集分

整• 想像する• 集められなかったすべての立場について想像する• 想像できても忘れてはいけないこと
できれば、事実を集めたほうが良い
あるいは、事実をインプットに想像する• 想像に頼りすぎると、説明しにくくなる• 想像を、うまく使う• 思考の幅を広げるきっかけにする

35

使用者の要求の想像

集

分

整

• 使用者を分解して想像する• 手法• ステークホルダー識別• ステークホルダーを洗い出し、特徴や使う場面を踏まえて、それぞれの気持ちや反応を考える• より具体的に想像する• 手法• カスタマージャーニーマップ• ペルソナ• ユーザーが体験するであろうことをきちんと情報として収集する• ペルソナに優先度をつける• 製品やサービスのターゲットを確認し、重み付けをする• パレート分析などで、重み付けをする
36

ペルソナに優先度をつける

集分

整• パレート分析• 出現頻度を確認し、どれを対象にすれば効果が大きいか、導き出す• 例：どのグループを対象にすると利用者のうち8割をカバーできる？

グラフは以下(最終更新 2017年4月11日 (火) 07:42 )よりhttps://ja.wikipedia.org/wiki/%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E5%9B%B337

生産者の要求の想像

集

分

整

• 製品の強み弱みを知る• 手法• 3C分析
• 顧客（Customer）、競合（Competitor）、自社（Company）
プラス要因
マイナス要因• SWOT分析• 強み (Strengths)、
弱み (Weaknesses)、機会 (Opportunities)、脅威 (Threats)の4象限を考える。

内部環境

強み弱み…

…

外部
環境

機会脅威

• 生産者がどちらに行きたいかを想像する• 「強みを伸ばす？ 」or38「弱みをなくす？ 」

開発(テスト)メンバーの要求の想像 集• 組織の強み弱みを知る• 手法• SWOT分析• 自組織がどうなっていきたいかを想像する
••
•
•

行動指針
目標
KGI（Key Goal Indicator）
KPI（Key Performance Indicator）

39

分

整

ステークホルダーの要求の想像

集

分

整

• 品質を区分して考える• 品質特性• ISO/IEC 25010などのSQuaREシリーズ• 「当り前品質」「魅力的品質」「一元的品質」…
• 既存の区分けは便利だが、やりたいことととの相性の確認や内容の取捨選択については、検討すべき40

集め先の特定、集める物

集

分

整

誰からも出てこなくても気にする必要があること法律などのルール

「常識」
「一般的」

• ルールは、調べる• 類似製品や経験から考える• 例 NGの理由が読み取れない入力エラーメッセージ41

なぜこんなに集めるの？

集分

整

テスト対象以外の情報を、なぜそんなに集めるの？

• すべてのテストをすることはできない• テストの厚みをコントロールする• 一歩先を見たテストができるように• 変化に強くする42

「集める」の おまけ集分

整• 様々なところから集める
••
•
•

テスト対象
人
テスト対象や人を取り巻くルールや常識…

Q：テストエンジニアが、そこまでやらなきゃならないの？

•A：組織でどこまでやれるか、やるべきか、決める必要あり

×「チュートリアルで聞いたから、必要かわからないが、やる」• 重要なことは、理由や問題を理解して行うこと• なぜその分析が必要なのか• 自分たちのテスト設計を良くする為に必要な点は何か→結局はテスト要求分析と一緒
43

テスト要求分析のプロセス
今回の範囲

集 める(準備含む)

分 ける(分解、分類)
整 理する(構造化)テスト観点を出す テスト計画に反映
44

分け方(分解、分類)

集分整• まず分解する
分解する• 複数の要求の集合になっていないか？
• 文章を図表にしてみる

分類する

45

分け方(分解、分類)

集

分

整

• 次に分類する• トップダウン、ボトムアップ両方から分解する• ボトムアップ• 「要求がどう分類できるか？」• かぶることもある
分類する• 理解できるように識別がされていることが重要

46

分け方(分解、分類)

集

分

整

• 分類の例•テストを厚くする要求、厚くしない要求•バグを見つけたい要求、動きを保証したい要求• テストケースを導くエンジニアリング的テスト要求、テストケースを導かないマネジメント的テスト要求(http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf

47より)

分類の一例集分

整• エンジニアリング的テスト要求：システムの完成像とテスト対象の途中経過• システムの完成像への要求の例• システム要求、ソフトウェア要求、機能要求、非機能要求、理想的な使い方、差別化要因、目的機能• テスト対象の途中経過に関する情報の例• 良さに関する知識• テスト対象のアーキテクチャや詳細設計、実装、自信があるところ• 悪さに関する知識：バグが多そうなところ• 構造上問題が起きそうなところ• 前工程までの検証作業（レビューやテスト）が足りなかったり滞ったところ• 類似製品や母体系製品の過去バグ、顧客クレームから分析した知識• スキルの足りないエンジニアが担当したところ、設計中に不安が感じられたところ• 進捗が滞ったりエンジニアが大きく入れ替わったりしたところ
以下より：

http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf

48

分類の一例集分

整• マネジメント的テスト要求：品質リスクなどに反映させる• 工数、人数、スキル分布、作業場所、オフショアか否か、契約形態など• 機材利用可否（シミュレータや試作機など）、ツール利用可否（ツールの種類とライセンス、保有スキル）など• 目標残存バグ数、信頼度成長曲線など• テストスイートの派生可能性や保守性など

以下より：

http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf

49

テスト対象分析結果を分けるとき

集• まず仕様書の内容を分解する• 1箇所に書かれていても分解した方が分かりやすくなる場合がある• 散らばっていても集約した方が分かりやすくなる場合がある• 複数の章やファイルに散らばっていることもある• 分類する、仕様書の行間を埋める• 手法• 3色ボールペン法• 6W2H50分

整分類する、仕様書の行間を埋める集分

整• 3色ボールペン法• 仕様書に意味の違う色をつけていき、識別する• 赤：とても重要• 青：まあ重要• 緑：疑問やおかしい点• 赤ばかりになりがちなので自分たちで意味付けすることも大事• 拡張した例

テスト設計コンテスト’16 SASADAN Go
http://aster.or.jp/business/contest/contest2016.html
51分類する、仕様書の行間を埋める

集分

整• 6W2H• When,Where,Who,What,Why,Whom,How,How Much
をガイドワードに網羅する

テスト設計コンテスト’13 Shelly
http://aster.or.jp/business/contest/contest2013.html
52

分解と分類集分

整• 分解と分類を行き来しながら、集めた要求を欲しいアウトプットに近づける
分解する

分類する

• アウトプットをイメージし、どんな切り口の情報が必要か考えながら行う• テスト設計などのインプットとして欲しい情報は何か？

テスト要求分析のプロセス
今回の範囲

集 める(準備含む)

分 ける(分解、分類)
整 理する(構造化)テスト観点を出す テスト計画に反映
54

整理する(構造化)集分

整• 要求の全体像が見通せるようにする• 要求同士がどう分類されたかが明確か見直す• 要求同士の関係性を明確にする• 親子、相反、順序• トップダウン、ボトムアップ両面から繰り返しおこなっていく

整理する• 表記は何でもよい• 図• マインドマップ• 表• USDM(Universal Specification
Describing Manner)• 「派生開発の変更を含む要求仕様の表現方法」(http://swquality.jp/temp/nagasakiqdg15_usdm.pdf

55より

整理のポイント集分

整• 全体を俯瞰できることが大切• 図と表などを組み合わせてもよい⇒整理されたテスト要求をみて、自分たちとステークホルダーで納得できるか確認する
56

テスト要求分析プロセス

集分整• テスト要求分析プロセスは反復されたり、再度戻って実施される集 める(準備含む)
分 ける(分解、分類)
整 理する(構造化)57

テスト要求分析プロセスのポイント① テストアーキテクチャ、テストケースなどの成果物が、テスト要求分析結果をもとに作成される② 後に繋げやすくなるように、テスト要求分析に取り組む• 繋がっていることがステークホルダーに説明しやすくなるように取り組む②①58

持ち帰っていただきたいこと
なぜテスト要求分析を行うか？というと…

• テスト要求分析の結果はテストアーキテクチャ設計やテスト詳細設計の品質を左右する• 低品質のテスト要求分析結果は、テストアーキテクチャやテストケースの品質低下を招く
また、気をつける必要があることは…

• テスト要求分析結果についてなぜそう考えたか？説明でき、ステークホルダーと合意できるようにする• テスト要求を多面的に集め、根拠をもって分け、整理しないと理解されやすく一貫したテストは非常に困難

チュートリアルのながれ

1. テストの課題
2. テスト要求分析とは
3. テスト要求分析のやり方
4. 過去の応募作の審査で気になった点に対して60

過去の応募作の審査で気になった点に対して• 目的• テスト要求分析と審査の気になった点とのつながりを理解する• テスト要求分析の失敗事例を通して、普段のテス
ト開発/テスト設計コンテストをやり切る• 目標• 審査の気になった点とテスト要求分析の失敗事例および原因を説明できる• 失敗事例を通してテスト要求分析で行う/気にすることを説明できる

失敗事例の紹介• 下記の方の事例と合わせて紹介
失敗なら任せろ！
＆
気にさせてごめんなさい…てすにゃん おーだん氏【テスト設計コンテスト参加歴：4年】
テスト設計コンテスト’15 関西：予選辞退
テスト設計コンテスト’16 関西：審査委員推薦枠
テスト設計コンテスト’17 東海/関西：東海/関西代表チーム
テスト設計コンテスト’18 東海/関西：審査委員推薦枠

失敗事例の紹介• 下記の方の事例と合わせて紹介
失敗なら任せろ！
＆
気にさせてごめんなさい…てすにゃん おーだん氏

テスト要求分析
大失敗時代【テスト設計コンテスト参加歴：4年】
テスト要求分析のテスト設計コンテスト’15 関西：予選辞退
海原に遭難…
テスト設計コンテスト’16 関西：審査委員推薦枠
テスト設計コンテスト’17 東海/関西：東海/関西代表チーム
テスト設計コンテスト’18 東海/関西：審査委員推薦枠

失敗事例の紹介• 下記の方の事例と合わせて紹介
失敗なら任せろ！
＆
気にさせてごめんなさい…てすにゃん おーだん氏【テスト設計コンテスト参加歴：4年】
テスト設計コンテスト’15 関西：予選辞退
テスト設計コンテスト’16 関西：審査委員推薦枠
テスト設計コンテスト’17 東海/関西：東海/関西代表チーム
テスト設計コンテスト’18 東海/関西：審査委員推薦枠※あくまで個人的な経験です…お手柔らかに…

過去の応募作の審査で気になったされた点

No.

内容

1

設計根拠を明示して欲しい
テスト観点を多面的に考慮し、それらの関係と根拠を明示して欲しい
スコープとその根拠を明示して欲しい2

これで本当に俯瞰しやすいのかどうかをきちんと検討して欲しい3

自分たちのテスト開発プロセスの結合度と凝集度に目を向けて欲しい

4

最新のプラクティスを取り入れるのであればきちんと取り入れて欲しい5

まずは、一つ一つきちんと、 自分たちが扱っているものや、行っていることの意味を熟考して、 それらを言語化して論理的に順序立てて説明して欲しい

6

そして、常に全体像を俯瞰して捉えて欲しい7

ただし、言語化や論理を重視するあまり直感を捨ててはならない

8

テスト設計コンテストは、業務での「熟考度」や「俯瞰度」を反映している
テスト設計コンテスト2020 OPENチュートリアルより

過去の応募作の審査で気になったされた点
1.

設計根拠を明示して欲しい
テスト観点を多面的に考慮し、それらの関係と根拠を明示して欲しい
スコープとその根拠を明示して欲しい

テスト要求分析の失敗事例• 状態• どこかの品質モデルをそのまま利用することで、「これで全部です、これをやります」と明示する。

• 原因• 根拠となるテスト要求が不足もしくは曖昧なまま進めた• 根拠が説明できないため、テストアーキクチャ設計でこれも必要か？と迷走する

テスト要求分析で行う/気にすること• 洗い出したテスト要求から根拠が説明できるかを確認す
る• テスト要求が不足もしくは曖昧なまま進めていないかをもう一度確認する• 集め先は他にないか

過去の応募作の審査で気になったされた点
2. これで本当に俯瞰しやすいのかどうかをきちんと検討して欲しい
テスト要求分析の失敗事例• 状態• 一枚絵にテスト要求を詰め込んでしまう• 原因• テストすべきこと、テストの実施順番など議論したいことを絞り切れていない/途中で議論してないテスト要求が紛れ込み整理されていない

テスト要求分析で行う/気にすること• 俯瞰には方向がある• どう俯瞰すればよいか• どのように俯瞰してあることが有効か• 製品の特徴及び自組織のテスト要求を捉えて、俯瞰の方向性を決める

過去の応募作の審査で気になったされた点
3. 自分たちのテスト開発プロセスの結合度と凝集度に目を向けて欲しい
テスト要求分析の失敗事例• 状態• 所属している企業などのプロセスをそのまま利用する• 原因• 自組織の背景や立場が明確なっていない• どのタイミングでどこまで検討すべきか• 客先/第三者テストがいるか など

テスト要求分析で行う/気にすること• 自組織の背景や立場が明確にし、必要な情報、やらなければいけないことを導き出し、テスト開発プロセスに組み込む

過去の応募作の審査で気になったされた点
4. 最新のプラクティスを取り入れるのであればきちんと取り入れて欲しい
テスト要求分析の失敗事例• 状態• 最新のプラクティスの目的を理解せずにやり方だけまねている• 原因• 取り入れる際に、スキル要件や学習期間を考慮していない• 最新のプラクティスが適切かを判断せずに使ってしまう

テスト要求分析で行う/気にすること• テスト要求を明確にする必要がある• 取り入れるプラクティスでどんな問題を解決したいかを考える• 必ずスキルの棚卸をして、学習期間を設ける

過去の応募作の審査で気になったされた点
5. まずは、一つ一つきちんと、 自分たちが扱っているものや、行っていることの意味を熟考して、 それらを言語化して論理的に順序立てて説明して欲しい
テスト要求分析の失敗事例• 状態• テスト要求分析で検討してないことが、後工程の成果物に表れる• 原因• テスト設計者同士で重視するテスト要求が議論されていない

テスト要求分析で行う/気にすること• 行うことの意味は裏に潜んでいる何かしらのテスト要求からきている• なぜそうテストしたいのかを文書化する過去の応募作の審査で気になったされた点
6. そして、常に全体像を俯瞰して捉えて欲しい
テスト要求分析の失敗事例• 状態• テストの全体像にテスト要求が全て詰め込まれた状態になる• 原因• 洗い出したテスト要求すべてに対応しようとする• 洗い出したテスト要求を取捨選択していない

テスト要求分析で行う/気にすること• 洗い出すテスト要求をすべて対応する必要はない• トレードオフ関係の要求もある• ただし、全体像の定義はテスト要求を元に行われ、設計で決定される

過去の応募作の審査で気になったされた点
7. ただし、言語化や論理を重視するあまり直感を捨ててはならない
テスト要求分析の失敗事例• 状態• テスト要求分析で検討しきれないことはすべての成果物から削除する• 原因• 説明できないことはテストしても無駄なことだと考えている

テスト要求分析で行う/気にすること• “直感で判断などを行ったところには、「ここは直感で○○した」と書いておけばよい”とあるように直感でよい• ただし、直観の根拠の検証や理由の追加を忘れないようにする

過去の応募作の審査で気になったされた点
8. テスト設計コンテストは、業務での「熟考度」や「俯瞰度」を反映している
テスト要求分析の失敗事例• 状態• 所属している企業などのプロセスをそのまま利用する• 原因• 時間短縮のために、テスト対象に対して適切かを考えずに安易に利用する• 目的を確認せず、テスト設計・実装作業のみを行っている

テスト要求分析で行う/気にすること• 組織では、テスト要求分析を行わなくても問題ないテスト開発プロセスとなっているかもしれないが、一歩踏み出して「なんで？」と考えてみる• 納得感を持ってプロセスを適用する

最後に• テスト要求分析が一貫性を作り上げる• 各工程の根拠に「テスト要求分析」が隠れている• テスト要求分析と各工程をきちんと結びつけることでテストの一貫性が保たれやすくなる
テスト要求分析
成果物

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

テスト
詳細設
計

テスト
実装

テスト
実施

テスト開発プロセスの図は以下より：
http://www.aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf

最後にテスト要求分析の結果を基に、自分のテストを開発してより良く育てていきましょう！
（失敗もうまく取り入れて…）

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