架空の人物

中山さん、テストプロセスのアセスメントやったんだってよ
JaSST北海道実行委員 with TEF道久保田 耕介
中岫 信©JaSST'17北海道実行委員会

1

あじぇんだ▪ アセスメントって？
▪ なにはともあれアセスメントやってみよう▪ アセスメントやってみたんだってよ©JaSST'17北海道実行委員会

2

アセスメントとは？

©JaSST'17北海道実行委員会

3

アセスメントって？
評価。査定。開発が環境に及ぼす影響の程度や範囲について、事前に予測・評価すること（大辞林 第三版より）「テストプロセスのアセスメント」って？
↓テストプロセスの【評価】↓テストの【やりかたの評価】©JaSST'17北海道実行委員会

4

だれが、なんのためにするの？
▪ 現状の仕事のやりかたを変えたい！という人（テストプロセス改善）▪ 「変えたい」の前に「現状の仕事のやりかた」の良いところ／悪いところを知る必要がある（テストプロセスアセスメント）▪ 現状把握して「評価」しないと、改善するポイントや方法が分からない©JaSST'17北海道実行委員会

5

TPI NEXTを紹介▪ テストプロセスアセスメントのモデルの一つ▪ オランダのSOGETI社により開発▪ 2015年秋に日本語版が発行▪ 現場ノウハウからのボトムアップアプローチ▪ チェックポイントに回答すると、テストプロセスの可視化が行える▪ 可視化した結果をもとにした、改善の優先度がわかる©JaSST'17北海道実行委員会

6

なにはともあれ
アセスメントやってみよう©JaSST'17北海道実行委員会

7

質問回答の注意点▪ TPI NEXTのチェックポイント（質問）から、ほんの一部を抜粋しています▪ 回答は「YES」or「NO」の二択です▪ 「YES」の方は手を上げてください▪ 少しでも該当すると感じたら「YES」でお答えください▪ 時間切れの場合は「NO」としてください©JaSST'17北海道実行委員会

8

Check0

例題

ソフトウェアテストが好きである。

＜解釈＞▪ ここに質問文や用語の解説が表示されます。

©JaSST'17北海道実行委員会

9

では、開始します！！

©JaSST'17北海道実行委員会

10Check１

欠陥管理-コントロールレベル

欠陥ライフサイクルを（再テストを含めて）定義して、適用している。

＜解釈＞▪ 欠陥を発見してからクローズする（決定した対応を実施する）までの流れを決めている。
▪ 実際にそれに従って欠陥を管理している。

©JaSST'17北海道実行委員会

11Check2

欠陥管理-コントロールレベル

各欠陥について、固有のID、関連するテストケースID（あてはまる場合）、欠陥報告者、日付、重要度カテゴリ、説明（欠陥再現手順、期待する結果と実際の結果）、欠陥ステータスを記録している。
＜解釈＞

各欠陥について以下が記録されていること・識別するための一意の番号

・再現手順と期待結果・実際の結果

・(もしあれば)摘出したテストケース

・対応の必要度合い

・欠陥報告者

・現在の状況（修正中、再テスト中 等）©JaSST'17北海道実行委員会

12

Check3

欠陥管理-コントロールレベル

欠陥を処理するために、責任者を決めている。

＜用語＞▪ 責任者：欠陥が修正され、リリースされるまでの管理を行う人©JaSST'17北海道実行委員会

13

Check4

欠陥管理-コントロールレベル

欠陥のアセスメントと解決に関与する人々が、欠陥管理ツールにアクセスできる。

＜解釈＞▪ 欠陥の切り分けや修正、再テストを行う人々が、欠陥情報を参照・編集できること＜用語＞▪ 欠陥のアセスメント：欠陥の評価。影響範囲や優先度付けなど。
▪ 欠陥管理ツール：Redmineなど欠陥を管理するためのシステム©JaSST'17北海道実行委員会

14

Check5

欠陥管理-効率化レベル

欠陥の管理ツールが、欠陥の状態遷移に関する承認フローを順守させる効力を持っている。

＜解釈＞▪ 例えば「欠陥修正後、再テストせずに欠陥をクローズする」といったことができない状態。
▪ 欠陥ステータスの更新権限が適切に設定されている 等©JaSST'17北海道実行委員会

15

Check6

欠陥管理-効率化レベル

欠陥のログを残したり、欠陥の状況を追跡するすべての人々は、同じ欠陥管理ツールを利用しているか、あるいは複数の欠陥管理ツールをシームレスに接続させて利用している。
＜用語＞▪ シームレス：利用者が使い分けを意識しなくても良い状態。
▪ 例えば、一方の欠陥管理ツールで登録された欠陥が、自動的にもう一方の欠陥管理ツールにも登録される 等©JaSST'17北海道実行委員会

16

Check7

欠陥管理-効率化レベル

欠陥管理を広範囲なレポートに役立てている。言い換えると、いろいろな方法でレポートを選択したりソートしたりできる。

＜解釈＞

例：今までの欠陥の内容から傾向を把握し、対策している。
▪ レポートを様々な条件でフィルタリングやソートできる状態。
＜用語＞▪ レポート：欠陥の報告書。Redmineで言うところのチケット。
©JaSST'17北海道実行委員会

17

Check8

欠陥管理-効率化レベル

多くの情報を記録して、傾向を特定している。記録する情報とは、欠陥、サブシステム、優先度、プログラムとそのバージョン、テストベースとそのバージョン、根本原因、すべてのステータス移行と問題解決者などである。
＜解釈＞

各欠陥に対して以下を記録し、傾向を特定していること。
・欠陥を摘出した具体的な機能・モジュール

・その欠陥を作り込んだ原因

・欠陥への対応の優先度

・欠陥処理の履歴と、欠陥を修正した人・仕様書など、テストのインプットとなったもの©JaSST'17北海道実行委員会

18

Check9

テストケース設計-コントロールレベル

テストケースを論理レベルで記録している。

＜解釈＞

テストケースに具体的な操作・値だけでなく、テストの目的(観点)も記載されている状態。

©JaSST'17北海道実行委員会

19

Check10

テストケース設計-コントロールレベル

テストケースには、以下の説明項目を含む。
a)開始時の状況b)変更プロセス＝実施するテストアクションc)予測される結果＜解釈＞

テストケースに以下が記載されていること▪ テストの前提条件（データが登録されていないこと、等）▪ テスト手順▪ 期待値©JaSST'17北海道実行委員会

20

Check11

テストケース設計-コントロールレベル

テストケースにシステムの詳細な振る舞いを記述することで、テストベースのどの箇所がテストの対象であるかが把握できる。

＜解釈＞

テストケースを詳細化することにより、以下が適正に行える▪ 検査対象のどの部分を検査しているか判断できる▪ 仕様変更が入った場合のトレーサビリティが確保できる©JaSST'17北海道実行委員会

21

Check12

テストケース設計-効率化レベル

テストケースは、テスト組織の同僚が見ても理解でき、保守できるものになっている。

＜解釈＞

テストケース全体の構成が構造的に行われている
悪い例：テストケース全体が適切な階層構造になっていない。
他人が見て理解し変更できるような内容になっている
悪い例：主語がない。定量的でない。検査の目的がわからない。
©JaSST'17北海道実行委員会

22

Check13

テストケース設計-効率化レベル

テストケースによって達成できるテストベースのカバレッジレベルが明確である。

＜解釈＞

例：そのテストケースを実施することによって、テスト対象の要件の何％を網羅できるかが明確である©JaSST'17北海道実行委員会

23

Check14

テストケース設計-効率化レベル

テストケース設計に正式なテスト設計技法を用いている。

＜解釈＞

テストケース設計に同値分割や境界値分析など、標準化されたテスト設計技法を使用していること＜用語＞

正式なテスト設計技法：同値分割、境界値分析など、標準化されたテスト設計技法©JaSST'17北海道実行委員会

24

Check15テストケース設計-効率化レベル

テストケースが設計できないような品質特性のテスト作業には、チェックリストを用いている。

＜解釈＞

動的なテストで確認できない品質特性（保守性など）は、チェックリストで確認していること©JaSST'17北海道実行委員会

25

TPI NEXTの全体像と、今回実施した範囲コントロール

この部分

効率化

最適化

1.利害関係者のコミットメント
2.関与の度合い
3.テスト戦略4.テスト組織
5.コミュニケーション
6.報告
7.テストプロセス管理
8.見積もりと計画
9.メトリクス
10.欠陥管理11.テストウェア管理
12.手法の実践
13.テスト担当者のプロ意識
14.テストケース設計
15.テストツール
16.テスト環境©JaSST'17北海道実行委員会

26

いかがでしょうか▪ 結構大変？
▪ 質問自体はわかりやすい？

▪ 自分たちのプロセスの定量評価って、普段あまりやらない？
▪ 問題点や改善点が、なんとなく見える化できました？

©JaSST'17北海道実行委員会

27

アセスメント
やってみたんだってよ©JaSST'17北海道実行委員会‹#›

中山 由信（架空）▪ とあるプロダクトのチームに所属している開発者。
▪ 自チームで開発しながら、品質・改善業務を担う。
▪ テストに関しては、自チームだけではなく他チームの改善にも口をはさんでいる。
▪ プロダクト全体でテストのプロセスがいまいちなので、何とかしないといけないと思っている。
©JaSST'17北海道実行委員会

29

アセスメントをやるきっかけ

漠然となんかテストで困ってる。
→とりあえず、現状把握してみるか。
©JaSST'17北海道実行委員会

30

第1部

中山さん
ー そのアセスメント・・・ ー©JaSST'17北海道実行委員会‹#›

いきなりですが、現状チェック！！

157項目！！

©JaSST'17北海道実行委員会‹#›

チェックシートあるので©JaSST'17北海道実行委員会‹#›

チェックしてみた

なんか形がおもしろいww©JaSST'17北海道実行委員会

34

現状把握した次はによると©JaSST'17北海道実行委員会‹#›

クラスタというのがあるらしい
クラスタとは▪ 1つの改善するステップを構成する複数のキーエリアのチェックポイントをグループ化したモノ。

©JaSST'17北海道実行委員会

36

クラスタというのがあるらしい
クラスタとは▪ 1つの改善するステップを構成する複数のキーエリアのチェックポイントをグループ化したモノ。
チェックポイント
キーエリア©JaSST'17北海道実行委員会

37

クラスタというのがあるらしい
クラスタとは▪ 1つの改善するステップを構成する複数のキーエリアのチェックポイントをグループ化したモノ。

グループ化©JaSST'17北海道実行委員会

38

クラスタというのがあるらしい
クラスタとは▪ 1つの改善するステップを構成する複数のキーエリアのチェックポイントをグループ化したモノ。
▪ TPI NEXTでは「基本クラスタセット」というものが用意されている。

©JaSST'17北海道実行委員会

39

クラスタというのがあるらしい
クラスタとは▪ 1つの改善するステップを構成する複数のキーエリアのチェックポイントをグループ化したモノ。
▪ TPI NEXTでは「基本クラスタセット」というものが用意されている。
▪ 新たにクラスタセットを構築することも可能。

©JaSST'17北海道実行委員会40

基本クラスタセット©JaSST'17北海道実行委員会

41

基本クラスタセットで確認してみた©JaSST'17北海道実行委員会

42

基本クラスタセットで確認してみたAから順に手を付けると良いらしいぞ©JaSST'17北海道実行委員会

43

漠然とゴール設定してみた

ひとまず、全項目をコントロールレベルまで上げるべ！！
©JaSST'17北海道実行委員会

44

クラスタに従ってやることを並べてみた
クラスタ
A

グループ
キーエリア
SR
3.テスト戦略A

TM

7.テストプロセス管理

BSR

3.テスト戦略B

TM

8.見積もりと計画

CTM

8.見積もりと計画

C
C
C
D
D
D
E
E

TM
TM
TP
TM
TP
TP
SR
TP

9.メトリクス
9.メトリクス16.テスト環境
9.メトリクス
12.手法の実践
16.テスト環境
3.テスト戦略
12.手法の実践

チェックポイント2 テスト戦略は、プロダクトリスク分析に基づいている。
テスト計画をテストプロジェクトの開始時に作成している。テストの計画には少なうとも、テストの任務、テストスコープ、1テスト計画、および役割と責任について記載している。
テストレベル、テストタイプ、テストカバレッジ、テストの深さは、（組織で画一的ではなく）リスク分析の結果によって3異なっている。
テスト活動ごとに、活動期間、必要なリソース、活動期間に作る成果物の指標がある。特定すべき活動は、テスト2ケースの定義、実行、テスト計画、管理である。
各テストフェーズやテスト活動間の依存関係を、テスト計画に記載している。テストフェーズとテスト活動に、ある程度3の重複を許容してよい。
1 テストプロセスでは、テストプロジェクトの見積もりや管理のためにメトリクスを定義して、利用している。
2 メトリクスに必要なインプットは統一した形式で記録され、定義されたメトリクスは体系的に保管されている。
1 テスト環境に対する要件を文書化している
3 メトリクスに対するインプット（データ）は、正確であり、かつ確認可能である。
2 テスト手法は、プロジェクトが用いている開発手法に適合している。
2 テスト環境を提供する部署との作業合意を得ている。合意に、タスクや責任を盛り込んでいる。
4 再テストや回帰テストについて、シンプルな戦略を決定している。
3 テストプロジェクトにとって、実装したテスト手法が実用的なものであると認識されている。

E

TP

13.テスト担当者のプロ意識

4 従業員の業務評価では、テスト担当者の特定のテストスキルや一般的なIT能力について定期的に評価している。

E

TP

16.テスト環境

4 テスト環境に対する変更が計画される場合、テスト管理者は随時連絡を受けている。
©JaSST'17北海道実行委員会

45

クラスタに従ってやることを並べてみたけどやることがたくさんあるけど、一気にやるとかえって混乱しないかな？
▪ テスト戦略っておいしいの？
▪ 見積もりで困ってたっけ？
▪ メトリクスって必要なのか？

これで良い方向に進むのか実感が湧かないなぁ？？

©JaSST'17北海道実行委員会

46

陥りがちな罠①合 プ ア 漠 よわ ラ セ 然 くせ ク ス と わて テ メ
かし ィ ンら
ま ス ト
なう や モい。 ガ デまイ ル
まド のに©JaSST'17北海道実行委員会

47

例えば・・・• NGになったプラクティスをすべてOKにしようとする• クラスタAを先に、次にBを・・・と進める©JaSST'17北海道実行委員会

48

プロセスモデルは…
▪ 「計画に沿って進める（管理）」→「実践内容を磨く（エンジニアリング）」→「全体を統合して運営する」→「最適化する」の優先度で作られている。
▪ 「管理（例えば“テスト戦略”・“見積と計画”）」を優先にすると、実務担当者が改善効果を実感しにくくなり、改善への当事者意識が希薄になる傾向がある

To Be Continued©JaSST'17北海道実行委員会

49

第2部

中山さん
ー その思い込み高き選択 ー©JaSST'17北海道実行委員会‹#›

しきりなおして絞 ポ 気 や 全
る イ に め て
こ ン な て Ｏと ト る
Ｋにに を とすす
こるるろのには©JaSST'17北海道実行委員会

51チェックポイントで中山さんが気になるのは…
クラスタ
A

グループ
キーエリア
SR
3.テスト戦略A

TM

7.テストプロセス管理

BSR

3.テスト戦略B

TM

8.見積もりと計画

CTM

8.見積もりと計画

C
C
C
D
D
D
E
E

TM
TM
TP
TM
TP
TP
SR
TP

9.メトリクス
9.メトリクス16.テスト環境
9.メトリクス
12.手法の実践
16.テスト環境
3.テスト戦略
12.手法の実践

チェックポイント2 テスト戦略は、プロダクトリスク分析に基づいている。
テスト計画をテストプロジェクトの開始時に作成している。テストの計画には少なうとも、テストの任務、テストスコープ、
1
テスト計画、および役割と責任について記載している。
テストレベル、テストタイプ、テストカバレッジ、テストの深さは、（組織で画一的ではなく）リスク分析の結果によって3異なっている。
テスト活動ごとに、活動期間、必要なリソース、活動期間に作る成果物の指標がある。特定すべき活動は、テスト
2ケースの定義、実行、テスト計画、管理である。
各テストフェーズやテスト活動間の依存関係を、テスト計画に記載している。テストフェーズとテスト活動に、ある程度3の重複を許容してよい。
1 テストプロセスでは、テストプロジェクトの見積もりや管理のためにメトリクスを定義して、利用している。
2 メトリクスに必要なインプットは統一した形式で記録され、定義されたメトリクスは体系的に保管されている。
1 テスト環境に対する要件を文書化している
3 メトリクスに対するインプット（データ）は、正確であり、かつ確認可能である。
2 テスト手法は、プロジェクトが用いている開発手法に適合している。
2 テスト環境を提供する部署との作業合意を得ている。合意に、タスクや責任を盛り込んでいる。
4 再テストや回帰テストについて、シンプルな戦略を決定している。
3 テストプロジェクトにとって、実装したテスト手法が実用的なものであると認識されている。

ETP

13.テスト担当者のプロ意識

4 従業員の業務評価では、テスト担当者の特定のテストスキルや一般的なIT能力について定期的に評価している。

ETP

16.テスト環境

4 テスト環境に対する変更が計画される場合、テスト管理者は随時連絡を受けている。
©JaSST'17北海道実行委員会

52

この辺が重要な気がする
テスト環境
1.テスト環境に対する要件を文書化している。
→暗黙的だけど、大丈夫か？
2.テスト環境を提供する部署との作業合意を得ている。合意に、タスクや責任を盛り込んでいる。
→作業合意取ってないけど、大丈夫？

4.テスト環境に対する変更が計画される場合、テスト管理者は随時連絡を受けている。
→変更があっても連絡がこないときがあるが、やばくない？

©JaSST'17北海道実行委員会

53

この辺が重要な気がする
テスト環境

良に「今な
1.テスト環境に対する要件を文書化している。

さ着テ後ん
そ手スのと
2.テスト環境を提供する部署との作業合意を得
うしトこなている。合意に、タスクや責任を盛り込んでいる。
だた環とく→作業合意取ってないけど、大丈夫？
な方境を
4.テスト環境に対する変更が計画される場合、テぁが」
考スト管理者は随時連絡を受けている。
え→変更があっても連絡がこないときがあるが、やるばくない？と、→暗黙的だけど、大丈夫か？

©JaSST'17北海道実行委員会

54

これに決めた！！

©JaSST'17北海道実行委員会

55

現場では求めてない• 必要かもしれないが、実担当者レベルでは困ってない（と思っている）→それよりももっとやることがあるだ
ろう！！

©JaSST'17北海道実行委員会

56

陥りがちな罠②

※

※

リーダ・
改善担
当者
など

改 問 特
善 題 定
対 意 の象 識 メを を ン
決 ベ バ
め ー ーて ス （進 にめ）るの。

©JaSST'17北海道実行委員会

57

例えば・・・
普段から特定のメンバーだけがテス
ト環境の状態を把握し、チームとして共有できていないことが気になっていた。
→「テスト環境」を改善対象に！
※チームには大、中、小の沢山の問題が存在するが、それらは各メンバーの立ち位置でバラバラに把握されていることが多い。

©JaSST'17北海道実行委員会

58

現場の実情• 改善に使えるリソースは少ないので、費用・時間対効果が高い問題を対象に選び、改善する必要がある。
• 組織やチームに存在する問題を全体で把握できていない場合、解決すべき問題特定を誤り、改善効果が得られない可能性が高まる。

• また、以外のメンバーの当事者意
To Be識が希薄になる対策が必要。
Continued©JaSST'17北海道実行委員会

59

第3部

中山さん
ー 未来への改善 ー©JaSST'17北海道実行委員会‹#›

もう一度しきりなおして
向 現 思 いけ 場 い って に 込 た
み 目 み んよ を をう捨てて©JaSST'17北海道実行委員会

61

実際の現場の問題意識は…

©JaSST'17北海道実行委員会

現場の声を聴く62

実際の現場の問題意識は…
テストの計画・管理ができていない

グループ分けテスト方針・方策の認識がずれている

テスト実装
見積もりができていない

テストの設計粒度がそろわない©JaSST'17北海道実行委員会

63

実際の現場の問題意識は…
テストの計画・管理ができていない

こんな関係がありそう

テスト方針・方策の認識がずれている

テスト実装
見積もりができていない

管理

テストの設計粒度がそろわない©JaSST'17北海道実行委員会

現場64

実際の現場の問題意識は…
テストの計画・管理ができていない

ここが改善できると他も良くなりそう

テスト方針・方策の認識がずれている

テスト実装
見積もりができていない

管理

テストの設計粒度がそろわない©JaSST'17北海道実行委員会

現場65

チェックポイントにプロットしてみた利害関係者との関係

テスト業務の専門性

テスト管理

1.利害関係者のコミットメント

7.テストプロセス管理

1枚

12.手法の実践

2.関与の度合い8.見積もりと計画

4枚

13.テスト担当者のプロ意識 2枚

9.メトリクス1枚

14.テストケース設計

2枚

15.テストツール

1枚

3.テスト戦略2枚

4.テスト組織10.欠陥管理

5.コミュニケーション

11.テストウェア管理

6枚

7枚

16.テスト環境

6.報告©JaSST'17北海道実行委員会

66

アセスメント結果と問題意識の比較

現場の問題意識とアセスメント結果はずれてなさそう©JaSST'17北海道実行委員会

67

「テスト方針・方策の認識がずれている」から着手すると▪ TPI NEXTのチェックポイント「手法の実践」相当の「テストの設計粒度がそろわない」「テスト実装」といったところの改善が進む。
→改善効果を実感しやすいようで、改善を受け入れられた©JaSST'17北海道実行委員会

68

教訓
TPI NEXTのチェックポイント「手法の実践」は、比較的現場よりのため、現場では改善効果を実感しやすい。
→改善として受け入れられやすい

計画、管理系の改善は、効果が出るまでのリードタイムが長くなり、効果を実感しにくい特徴がある©JaSST'17北海道実行委員会

69中山さんー 改善の気持ちは砕けない ー©JaSST'17北海道実行委員会‹#›まとめると陥りがちな罠①▪ よくわからないまま漠然とアセスメントモデルのプラクティスやガイドに合わせてしまう。
陥りがちな罠②▪ 特定のメンバーの問題意識をベースに改善対象を決めて進める。

©JaSST'17北海道実行委員会

71まとめると▪ アセスメント結果は現場や組織が抱える問題や目標と結びつけることが大事（定量評価と定性評価）▪ クラスタセットは一般的な捉え方として参考にはするが、ガイドに従うことや多くの不適合項目を一律改善することが目的ではないので注意▪ 現場の問題意識を分析した結果やなりたい姿から眺めると適切なターゲットが見つかりやすい©JaSST'17北海道実行委員会

72

完やり楽やいきしす
まくくしし 、ょてう！

現仕状
事のの見やり直かしたをて、©JaSST'17北海道実行委員会

73