テスト設計コンテスト2015

Lancez-Vous. C'est gratuit
ou s'inscrire avec votre adresse e-mail
テスト設計コンテスト2015 par Mind Map: テスト設計コンテスト2015

1. テストアーキテクチャ設計 - Phase 2

2. 九州チーム

2.1. チームコンセプト

2.1.1. 勝つ!

2.1.1.1. 仮想テスト会社

2.1.1.2. 審査員はお客さま

2.1.1.3. 儲けるためのテスト

2.1.2. 非ITでもわかりやすい資料

2.2. どこで点を稼ぐか

2.2.1. 書いてあることは書く

2.3. チームスケジュール

2.3.1. 第1フェーズ (書類選考)

2.3.1.1. 2014年10月

2.3.1.1.1. 10/5〜10/11

2.3.1.1.2. 10/12〜10/18

2.3.1.1.3. 10/19〜10/25

2.3.1.1.4. 10/26〜11/1

2.3.1.2. 2014年11月

2.3.1.2.1. 11/2〜11/8

2.3.1.2.2. 11/9〜11/15

2.3.1.2.3. 11/16〜11/22

2.3.1.2.4. 11/23〜11/25

2.3.1.2.5. 11/26

2.3.2. 第2フェーズ (決勝戦)

2.3.2.1. 2015年1月

2.3.2.2. 2015年2月

2.4. 課題管理

2.4.1. 前回のテスト設計コンテストで提出した成果物を見ることは可能か

2.4.2. テストアーキテクチャという概念がぼんやりとしている

2.4.3. 成果物の様式を決める

2.5. レビュー

2.5.1. どのタイミングで実施するか

2.5.2. 誰が実施するか

2.5.2.1. 福田

2.5.2.2. 岡崎

2.5.3. レビュー記録の管理をどのようにするか

2.5.3.1. 木下が検討して決める

2.5.3.1.1. backlog使う?

3. テストとは

3.1. 行動する

3.1.1. 考えなくては行けないこと

3.1.1.1. 行動内容

3.1.1.2. 行動手順

3.1.1.3. 行動対象

3.1.1.4. 品質ゴール・品質懸念点

3.1.1.5. トレードオフすべき制約・特性・行動内容

3.1.1.6. 優先順位・工程終了条件

3.1.1.7. スコープ

3.1.1.8. フィードバック

3.1.1.9. バランス

3.1.1.10. 保守性

3.1.1.11. 後工程作業容易性

3.2. 説明する

3.2.1. 考えなくては行けないこと

3.2.1.1. 完備性・網羅性

3.2.1.2. 追跡性・根拠到達性・多重性

3.2.1.3. 論理的整合性

3.2.1.4. 表現統一性

3.2.1.5. 詳細性

3.2.1.6. MECE性

3.2.1.7. 多面性

3.2.1.8. 優先順位優位性

3.2.1.9. トレードオフ適切性

3.2.1.10. 許容範囲明示性

3.3. 納得させる

3.3.1. 考えなくては行けないこと

3.3.1.1. 根拠理解性

3.3.1.2. 一目瞭然性

3.3.1.3. 俯瞰性

3.3.1.4. ストーリー性

3.3.1.5. 首尾一貫性

3.3.1.6. 直感性

3.3.1.7. 不安払拭性

3.3.1.8. 選択可能性・選択肢明示性

3.3.1.9. 説明多様性

3.3.1.10. 上司説明性

4. テスト設計の品質特性?

4.1. 項目によってどの品質特性か対象が変わってくるのでは?

4.1.1. 各項目ごとに品質特性の可否及び説明ができるようにしたい

5. スケジュール

5.1. 登録締め切り:2014/9/30

5.1.1. 登録済み

5.2. 書類選考成果物提出締め切り:2014/11/26

5.2.1. 未提出

5.3. 決勝戦:2015/2/20 or 2015/2/21

6. 配点 (合計点:120点)

6.1. テストアーキテクチャ設計点:30点 (優先順位:1)

6.1.1. テストアーキテクチャレベルでテスト観点が考慮されているか

6.1.2. テストすべきこと(テスト観点)がすべて盛り込まれているか

6.1.3. テストの全体像が把握しやすいか

6.1.4. テスト対象とテスト目的の関係が分かりやすいか

6.1.5. テストの厚みやバランスが考慮されているか

6.1.6. テストスコープが明示されているか、明示されたスコープは妥当性があるか

6.2. テスト詳細設計・実装点:20点

6.2.1. 特定のテスト観点において、テストケースが十分に記述されているか

6.2.2. 選択したテスト観点が適切か

6.2.3. リスクを考慮した優先順位付けが行われているか

6.3. 工程間一貫性点:10点

6.3.1. テストアーキテクチャとテスト詳細・実装の間のトレーサビリティが取れているか

6.3.2. テストアーキテクチャとテスト詳細・実装のバランスが良いか

6.4. 文書点:10点 (優先順位:1)

6.4.1. 文書の情報量は適切か

6.4.2. 記述内容は論理性を保っているか

6.4.3. 文書の可読性は保っているか

6.4.4. 文書体系が示されているか

6.4.5. 文書の保守性を考慮しているか

6.5. プレゼン点:10点 (優先順位:1)

6.5.1. 分かりやすいか(正確な情報が速やかに伝わるか)

6.5.2. 主張が受け入れられるか(説得できるか)

6.6. 特別点:20点

6.6.1. 独自性は高いか

6.6.2. 新規性は高いか

6.6.3. 発想は豊かか

6.7. 技術点:20点

6.7.1. 高い技術を用いているか

6.7.2. 仕様書の問題を指摘できているか

7. テストエンジニアリングプロセス

7.1. テスト計画・テスト戦略・テスト方針といった技術を乖離するために分割した工程群

7.2. テストケース郡(テストスイート)を開発するという考え方

7.3. ソフトウェア開発プロセスと同様の工程から構成される

7.3.1. どんな工程があるの?

7.3.1.1. 1.テスト要求分析

7.3.1.1.1. テスト対象がどうなっていて、何を実証すれば納得してもらえるかを理解する工程

7.3.1.1.2. どんなことするの?

7.3.1.2. 2.テストアーキテクチャ設計

7.3.1.2.1. 論理的立てや現実化、実証が容易になるように分割・整理するなど全体像を構想する工程

7.3.1.2.2. どんなことするの?

7.3.1.3. 3.テスト詳細設計

7.3.1.3.1. どうやってテストをしていけば実証したことになるのかを示せる論理立てを考案する工程

7.3.1.3.2. どんなことするの?

7.3.1.4. 4.テスト実装

7.3.1.4.1. 実際のテスト環境で実証を進めていくためにテストケースを現実化する工程

7.3.1.4.2. どんなことするの?

7.3.1.5. 5.テスト実施

7.3.1.5.1. 実際にテスト手順を実行して実証を進める工程