ALTM過去問題解説
May 22, 2017
JSTQB Technical Committee委員長谷川 聡© Japan Software Testing Qualifications Board

Agenda
試験問題の出題について
K2 TM-4.4.1 欠陥マネジメント
K3 TM-2.7.2 テストマネジメント
K4 TM-2.3.3 テストマネジメント
勉強を進めていくにあたって© Japan Software Testing Qualifications Board2

試験問題の出題について学習の目的（L.O）に従ってシラバスのそれぞれの課題を試験する（FLシラバス

P75）

L.Oには、知識レベルが設定されており、知識レベルに合わせた問題が出題される。ALTMは以下の３つの知識レベルの問題が出題される
K2【理解】シラバスに書かれている内容を理解して説明できる• 例：テストの見積りに影響を与える可能性がある要因を理解し、例を示す。

K3【適用】概念や方法を適用できる• 例：所定のプロジェクトに対して、適用可能なすべての見積り技法を使用して、見積りを作成する。

K4 【分析】状況を分析し、適したものを提案できる• 例：ステークホルダ、状況、およびソフトウェア開発ライフサイクルモデルを含むプロジェクトニーズを分析し、最適なテスト活動を識別する© Japan Software Testing Qualifications Board

3

K2【理解】～理解して説明できる～© Japan Software Testing Qualifications Board

4

K2【理解】 学習の目的
K2の場合、シラバスに書かれている内容を理解して説明出来ることが求められる
TM-4.4.1「テストプロセスとソフトウェア開発プロセスのプロセス能力を評価するために、欠陥レポートの統計情報をどのように使用するかを説明する。」「4.4 欠陥レポート情報によるプロセス能力の評価 」に記載がある、「テスト進捗のモニタリング情報に加えて、欠陥情報は、プロセス改善の取り組みを支援する必要がある。」ことを理解しているかが焦点となる© Japan Software Testing Qualifications Board

5

K2

TM-4.4.1

欠陥マネジメント 過去問題

© Japan Software Testing Qualifications Board

6

K2

TM-4.4.1

正解の解説 1/2

© Japan Software Testing Qualifications Board

7

K2

TM-4.4.1

正解の解説 2/2

正解は© Japan Software Testing Qualifications Boardb8

K3【適用】～概念や方法を適用できる～© Japan Software Testing Qualifications Board

K3

学習の目的

K3の場合、シラバスに書かれている概念や方法を、具体的な例に対して適用できることが求められる

TM-2.7.2「品質コストをベースに、他の定量的および定性的要素を考慮して、テストの価値を見積り、見積った価値をテストステークホルダに伝える。」「2.7 テストのビジネスバリュー」で説明されている品質コストの概念を知っていて、実際に適用して品質コストを算出できることが焦点となる© Japan Software Testing Qualifications Board

10

K3

TM-2.7.2

テストマネジメント© Japan Software Testing Qualifications Board

11

K3

TM-2.7.2

テストマネジメント
プロジェクトの状況

方法の適用

プロジェクトデータ© Japan Software Testing Qualifications Board

12

K3

TM-2.7.2

解説

1/4

品質コストの概要※シラバス(2.7 テストのビジネスバリュー)

1. 予防コスト
2. 評価コスト
3. 内部失敗コスト
4. 外部失敗コスト：欠陥の作りこみを予防するためのコスト：テストやレビューなどの評価するコスト：ソフトウェア提供前の欠陥修正のコスト：ソフトウェア提供後のサポートコスト© Japan Software Testing Qualifications Board

13

K3

TM-2.7.2

解説

2/4

プロジェクトデータの確認•①要求仕様書・システム仕様書・実装コードへのレビュー
内容
レビュー工数(計画・実施を含む)レビューで検出した欠陥の修正工数レビューでの指摘欠陥数

実績
45 時間
25 時間
13 件

•②リリース前までのテスト(コンポーネントテスト～システムテスト)
内容
テスト設計工数
テスト実行工数
テストで検出した欠陥のデバッグ・修正工数
テストで検出した欠陥数

実績
67 時間
154 時間85 時間
15 件•③リリース後内容
欠陥修正工数検出した欠陥数実績
550 時間2 件

評価コスト

内部失敗コスト

外部失敗コスト

テストやレビューのコスト

ソフトウェア提供前の欠陥修正のコスト

ソフトウェア提供後のサポートコスト

コスト：45+67+154＝266時間

コスト：25+85＝110時間

コスト：550時間© Japan Software Testing Qualifications Board

14

K3

TM-2.7.2

解説

3/4

プロジェクトデータの確認•①要求仕様書・システム仕様書・実装コードへのレビュー
内容
レビュー工数(計画・実施を含む)レビューで検出した欠陥の修正工数レビューでの指摘欠陥数

実績
45 時間
25 時間
13 件

•②リリース前までのテスト(コンポーネントテスト～システムテスト)
内容
テスト設計工数
テスト実行工数
テストで検出した欠陥のデバッグ・修正工数
テストで検出した欠陥数

実績
67 時間
154 時間85 時間
15 件•③リリース後内容
欠陥修正工数検出した欠陥数

リリース前(内部)の欠陥あたりのコスト：

実績
550 時間2 件

リリース後(外部)の欠陥あたりのコスト：

リリース前(内部)に検出した欠陥数：28件(13+15)

リリース後(外部)に検出した欠陥数：2件

リリース前(内部)のコスト：376時間(266+110)

リリース後(外部)のコスト：550時間→376時間/28件 ＝13.4時間© Japan Software Testing Qualifications Board→550時間/2件 ＝275時間

15K3

TM-2.7.2

解説

4/4

選択肢の確認
選択肢
評価コスト

内部失敗コスト

外部失敗コスト

(時間)
110
266
110
25(時間)
550
550
550
856

(時間)
266
110
266
45

欠陥あたりのコ 欠陥あたりのコスト(内部)スト(外部)(時間/件)(時間/件)
13.4
275.0
13.4
275.0
275.0
13.4
5.4
50.4

評価コスト

内部失敗コストコスト：67+154+45＝266時間

コスト：85+25＝110時間

リリース前(内部)の欠陥あたりのコスト：

外部失敗コストコスト：550時間

リリース後(外部)の欠陥あたりのコスト：

リリース前(内部)に検出した欠陥数：28件(15＋13)

リリース後(外部)に検出した欠陥数：2件

リリース前(内部)のコスト：376時間(266+110)

リリース後(外部)のコスト：550時間→376時間/28件 ＝13.4時間© Japan Software Testing Qualifications Board→550時間/2件 ＝275時間16K4【分析】～状況を分析し、適したものを提案できる～© Japan Software Testing Qualifications Board

K4

学習の目的

K4の場合、状況を分析し、シラバスに書かれている内容をもとに適したものを提案できることが求められる

TM-2.3.3「プロダクト品質リスクを分析、識別、および評価し、主要なプロジェクトステークホルダの観点に基づいて、リスクとその評価されたリスクレベルの概要を説明する。」「2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ」で解説しているリスクの扱い方を理解して分析結果を導き出すことが焦点となる© Japan Software Testing Qualifications Board

18

K4

TM-2.3.3

テストマネジメント© Japan Software Testing Qualifications Boardの 過去問題

19K4

TM-2.3.3

テストマネジメントの 過去問題

プロジェクトの状況①：統合テスト前

提案内容
プロジェクトの状況②：統合テスト実施後© Japan Software Testing Qualifications Board

20

K4

TM-2.3.3

解説

1/5

解答のポイント

1.リスクベースドテストであること→リスクに合わせて対処の優先度付けをする

2.リスクの再評価を求められていること→統合テストの結果を見て再評価する

3.テスト(プロジェクト)が遅れており、この後のテストレベルも十分に行えない可能性があること→提案の際のINPUTとする© Japan Software Testing Qualifications Board

21

K4

TM-2.3.3

解説

2/5

提案内容についてa. 書籍情報の登録機能は未修正の欠陥があることを制約事項としてリリースすることを検討する。

b. 書籍情報の更新機能は難易度を下げるよう再設計して作り直すことを検討する。
c. 書籍情報の削除機能は今回のリリースから外すことを検討する。
d. 書籍情報の印刷機能が使えなくなったときの代替手段を検討する。
© Japan Software Testing Qualifications Board22

K4

TM-2.3.3

解説

3/5

状況分析のポイント① 統合テスト前
機能名

機能の難易度(複雑さ)

書籍の検索
書籍情報の参照
書籍情報の登録
書籍情報の更新
書籍情報の削除
書籍情報の印刷

低
低
中
高
高
中

機能の特性
コンポーネン
機能の利用頻度トテストの品
質
高
多い
高多い
低
多い
中
少ない
低
少ない
低
多い

機能の代替手段なし
なし
あり
ありありなしリスクが顕在化する可能性：「機能の難易度」と「コンポーネントテストの品質」より
a.

d.

(低い) 登録 ＝ 印刷

＜b.

更新

＜c.

削除 (高い)リスクが顕在化したときの影響度：「機能の利用頻度」と「機能の代替手段」より
c.
b.
a.
d.

(低い) 更新 ＝ 削除＜登録＜印刷 (高い)※a～dは解説のため解答選択肢a～dを表している。
© Japan Software Testing Qualifications Board23K4

TM-2.3.3

解説

4/5

状況分析のポイント② 統合テスト後のリスク再評価
機能名
書籍の検索
書籍情報の参照
書籍情報の登録
書籍情報の更新
書籍情報の削除
書籍情報の印刷

1KLOCあたりのテストケース数
50.0
50.0
50.0
50.0
50.0
50.0

統合テストの結果摘出した欠陥
1KLOCあたりの未修正の欠陥数
数
欠陥数
13.3
0
2
4.0
0
4
20.0
1
2
5.0
0
10
33.3
4
1
3.30

リスクが顕在化する可能性
a.
d.

c.

b.

登録 ＝ 印刷 ＜ 更新 ＜ 削除
a.

d.

b.

c.

d.

a.

b.

c.

d.

b.

a.

c.

統合テスト前 登録 ＝ 印刷 ＜ 更新 ＜統合テスト後 印刷 ＜ 登録 ＜ 更新 ＜または印刷 ＜ 更新 ＜ 登録 ＜© Japan Software Testing Qualifications Board

削除削除削除24

K4

TM-2.3.3

解説

5/5

提案内容の検討a. 書籍情報の登録機能は未修正の欠陥があることを制約事項としてリリースすることを検討する。

→リスクが顕在化する可能性が上がっている。未修正の欠陥は1件である。
代替手段はあるため、リスクが残っていても影響は小さいが、機能の利用頻度が高いため、リスク除去に努める選択肢も捨てきれない。
b.

書籍情報の更新機能は難易度を下げるよう再設計して作り直すことを検討する。

→リスクが顕在化する可能性が下がっているため、対応の優先度は低い。
また、遅れているという状況より、再設計は現実的でない。
c.

書籍情報の削除機能は今回のリリースから外すことを検討する。

→リスクが顕在化する可能性がさらに上がり、未修正の欠陥が4件もある。
代替手段があり、利用頻度も少ないことから、リリースから外すという対応は妥当である。
d.

書籍情報の印刷機能が使えなくなったときの代替手段を検討する。

→代替手段がないため、リスクが顕在化したときの影響度が大きいが、リスクが顕在化する可能性が下がっているため、対応の優先度は低い。
© Japan Software Testing Qualifications Board

25

勉強を進めていくにあたって© Japan Software Testing Qualifications Board

知識レベル毎の学習方法
K2の学習方法
シラバスの記載内容を正しく理解することが必要

K3の学習方法
シラバスに記載されている概念、方法を理解して使えるようにすることが必要

K4の学習方法
シラバスに記載されている概念、方法を理解した上で、シナリオに書かれている状況を分析してベストな判断を選択できるようにすることが必要
テストマネージャについては、以下の参考文献を使って学習することもお勧めする。
体系的ソフトウェアテスト入門（リッククレイグ）– 基本から学ぶテストプロセス管理、ソフトウェアテスト12の必勝プロセス（レックスブラック）–© Japan Software Testing Qualifications Board

27

JSTQBへお問い合わせ
CONTACT INFORMATIONJSTQB（Japan Software Testing Qualifications Board）
E-mail： query@jstqb.jp※1:acceptable mail size is less than 50KB※2: Please understand that our response may take time

ありがとうございました© Japan Software Testing Qualifications Board