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

Size: px

Start display at page:

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

まれあとりこし
4 years ago
Views:

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

お話することテスト要求分析の一部開発プロセスの図は以下より : http://aster.or.

2 お話することテスト要求分析の一部開発プロセスの図は以下より : 2

3 お話することテスト開発プロセス ( テストプロセス ) のうちテスト要求分析に焦点を当てますテスト設計の良し悪しはテスト設計成果物のみでは語れませんやり方は多種多様なぜテスト要求分析を行うか? 考え自分たちに合うやり方を考えるヒントにしていただければ幸いです 3

4 お話すること今回の範囲集める ( 準備含む ) 分ける ( 分解分類 ) 整理する ( 構造化 ) 観点を出すテスト計画に反映 4

5 チュートリアルのながれ 1. テストの課題 2. テスト要求分析とは 3. テスト要求分析のやり方 4. 過去の応募作の審査で気になった点に対して 5

テスト要求分析とはテスト開発プロセスの図は以下より : http://aster.or.

6 テスト要求分析とはテスト開発プロセスの図は以下より : 6

7 そんなに困っていないけど困っているのはテスト要求分析じゃないよ? なんとなくやれてしまうこともある長年のつながりでなんとなくできてしまうプロセス上それなりの要求分析は行うようになっているテストアーキテクチャに不整合がたくさん? テストケースが分かりにくいと言われる? テスト要求分析で失敗していたのかも 7

8 テスト要求分析の理解レベルテスト要求分析の説明はすごく簡単に聞こえる受け手によって深さがマチマチ 8

9 チュートリアルのながれ 1. テストの課題 2. テスト要求分析とは 3. テスト要求分析のやり方 4. 過去の応募作の審査で気になった点に対して 9

10 用語の定義テスト開発プロセスの図は以下より : 10

本書での用語の意味以下より ( 点線の丸を除く ): http://aster.or.

11 本書での用語の意味以下より ( 点線の丸を除く ): 11

12 本書での用語の定義テスト観点はテストアーキテクチャやテストケースのインプットになる以下より ( 吹き出しを除く ): 12

13 テスト要求分析では以下を決めるどういった目的でテストするかどこまでどんなテストをするかこの解釈に大きな壁が存在する 13

14 どういった目的でテストするかよく言われることバグを見つけることちゃんと動くことを保証することもっと深く考えてみるなぜそこは厚くテストするのかなぜその部分を先にテストしないといけないのかそのテストで何の課題を解決したいのか 14

15 どこまでどんなテストをするかよく言われることテストの範囲を明確にすることインターフェースのある箇所他社製のプログラムを使っている箇所どんなテストをするか明確にすること機能テスト非機能テストもっと深く考えてみるなぜテスト範囲がそこでいいのかなぜ非機能テストが必要なのかごと ( 例えば機能ごと ) に分けるだけでいいのか 15

16 テスト要求分析の影響箇所テスト要求分析成果物テストアーキテクチャ設計テスト詳細設計テスト実装テスト実施テスト開発プロセスの図は以下より : 16

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

18 チュートリアルのながれ 1. テストの課題 2. テスト要求分析とは 3. テスト要求分析のやり方 4. 過去の応募作の審査で気になった点に対して 18

19 テスト要求分析のプロセス今回の範囲集める ( 準備含む ) 分ける ( 分解分類 ) 整理する ( 構造化 ) 観点を出すテスト計画に反映 19

20 どこから集める? テスト要求の集め先は様々テスト対象やプロジェクトの状況にも依存するまず集め先を特定する 20

21 集め先の特定製品やサービステスト対象分析をするテスト対象の使われ方などテスト対象を理解するための分析をする仕様製品やサービス 21

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

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

24 集め先の特定製品やサービスの周辺には人 ( ステークホルダー ) がいる使用者の要求生産者の要求テストメンバーの要求開発メンバーの要求どんなステークホルダーがいるか? 考える 24

25 集め先の特定どんなステークホルダーがいるだろうか? 手法製品やサービスのライフサイクルから考えるいつどこでどんな人がどんな関わり方をするか? ステークホルダー識別ソフトウェア及びシステムに直接関与する一次ステークホルダー直接的には関与しない二次ステークホルダー要求とステークホルダーの関係を明らかにするために, ステークホルダーを影響度と重要度の特性で分析する ( 内はソフトウェア品質知識体系ガイド -SQuBOK Guide-( 第 2 版 ), SQuBOK 策定部会編, オーム社, 2014/11 より ) 本書では使用者生産者開発メンバーテストメンバーの例で考える

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

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

28 集めるときの注意点必要な情報を多面的に集められるようにする集めた情報を分けて俯瞰するロジックツリー深掘りの方向何を必要と思うかは考えやすいなぜそれが必要だと思ったの? 状況変化の情報を集め忘れないように過去プロジェクトからの変化プロジェクト内の変化なぜ開発メンバーが休みがちに? なぜハードを変更? MECE( 漏れもだぶりもない ) か? 深掘りが不足しているところはないか? 28

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

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

31 パレート分析パレート分析出現頻度を確認しどれを対象にすれば効果が大きいか導き出す例 : どのグループを対象にすると利用者のうち 8 割をカバーできる? グラフは以下 ( 最終更新 2017 年 4 月 11 日 ( 火 ) 07:42 ) より 31

32 生産者の要求の想像製品の強み弱みを知る手法 3C 分析顧客 (Customer) 競合 (Competitor) 自社 (Company) SWOT 分析強み (Strengths) 弱み (Weaknesses) 機会 (Opportunities) 脅威 (Threats) の 4 象限を考える内部環境外部環境プラス要因強み生産者がどちらに行きたいかを想像する強みを伸ばす? 弱みをなくす? 機会マイナス要因弱み脅威 32

33 開発 ( テスト ) メンバーの要求の想像組織の強み弱みを知る手法 SWOT 分析自組織がどうなっていきたいかを想像する行動指針目標 KGI(Key Goal Indicator) KPI(Key Performance Indicator) 33

34 ステークホルダーの要求の想像品質を区分して考える品質特性 ISO/IEC などの SQuaRE シリーズ当り前品質魅力的品質一元的品質既存の区分けは便利だがやりたいことととの相性の確認や内容の取捨選択については検討すべき 34

35 集め先の特定集める物誰からも出てこなくても気する必要があること法律などのルール常識一般的ルールは調べる類似製品や経験から考える例 NG の理由が読み取れない入力エラーメッセージ 35

36 なぜこんなに集めるの? テスト対象以外の情報をなぜそんなに集めるの? すべてのテストをすることはできないテストの厚みをコントロールする一歩先を見たテストができるように変化に強くする 36

37 集めるのおまけ様々なところから集めるテスト対象人テスト対象や人を取り巻くルールや常識 Q: テストエンジニアがそこまでやらなきゃならないの? A: 組織でどこまでやれるかやるべきか決める必要ありチュートリアルで聞いたから必要かわからないがやる重要なことは理由や問題を理解して行うことなぜその分析が必要なのか自分たちのテスト設計を良くする為に必要な点は何か結局はテスト要求分析と一緒 37

38 分け方分解分類まず分解複数の要求の集合になっていないか? 文章を図表にしてみる 38

39 分け方次に分類トップダウンボトムアップ両方からボトムアップ要求がどう分類できるか? かぶることもある理解できる識別がされていることが重要テストを厚くする要求厚くしない要求バグを見つけたい要求動きを保証したい要求テストケースを導くエンジニアリング的テスト要求テストケースを導かないマネジメント的テスト要求 ( より ) 39

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

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

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

43 テスト対象分析結果の識別 3 色ボールペン法仕様書に意味の違う色をつけていき識別する赤 : とても重要青 : まあ重要緑 : 疑問やおかしい点赤ばかりにになりがちなので自分たちで意味付けすることも大事拡張した例テスト設計コンテスト 16 SASADAN Go 43

44 テスト対象分析の識別 6W2H When,Where,Who,What,Why,Whom,How,How Much をガイドワードに網羅するテスト設計コンテスト 13 Shelly 44

45 分解と分類分解と分類を行き来しながら集めた要求を欲しいアウトプットに近づける分解分類アウトプットをイメージしどんな切り口の情報が必要か考えながら行うテスト設計などのインプットとして欲しい情報は何か?

46 整理のやり方要求の全体像が見通せるようにする要求同士がどう分類されたか明確か? 見直す要求同士の関係性を明確にする親子相反順序トップダウンボトムアップ両面から繰り返しおこなっていく表記は何でもよい図マインドマップ表 USDM(Universal Specification Describing Manner) 派生開発の変更を含む要求仕様の表現方法 ( より ) 46

47 整理の重要ポイント全体を俯瞰できることが大切図と表などを組み合わせてもよい 47

48 テスト要求分析のプロセス集める ( 準備含む ) 分ける ( 分解分類 ) 整理する ( 構造化 ) 48

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

50 持ち帰っていただきたいことなぜテスト要求分析を行うか? というとテスト要求分析の結果はテストアーキテクチャ設計やテスト詳細設計の品質を左右する低品質のテスト要求分析結果はテストアーキテクチャやテストケースの品質低下を招くまた気をつける必要があることはテスト要求分析結果についてなぜそう考えたか? 説明できステークホルダーと合意できるようにするテスト要求を多面的に集め根拠をもって分け整理しないと理解されやすく一貫したテストは非常に困難

51 チュートリアルのながれ 1. テストの課題 2. テスト要求分析とは 3. テスト要求分析のやり方 4. 過去の応募作の審査で気になった点に対して 51

ISO9001:2015規格要求事項解説テキスト(サンプル)　株式会社ハピネックス提供資料

ISO9001:2015規格要求事項解説テキスト(サンプル)　株式会社ハピネックス提供資料テキストの構造 1. 適用範囲 2. 引用規格 3. 用語及び定義 4. 規格要求事項要求事項網掛け部分です罫線を引いている部分は Shall 事項 (~ すること ) 部分です解 ISO9001:2015FDIS 規格要求事項 Shall 事項は S001~S126 まで計 126 個あります説網掛け部分の規格要求事項を講師がわかりやすく解説したものです

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

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