Wacate2015summer_report

WACATE2015夏報告会

藤沢耕助

1. はじめに

2. ゆもつよメソッド　ワークショップ

(1)ワークショップの流れ

(2)ワークショップ内容（メイン）

3. おわりに

2

はじめに• 今回の発表は、WACATE2015夏のメインテーマである「ゆもつよメソッド」に主眼を置いたものです。

• 作者のドメイン、理解度により資料には偏りがあります。あらかじめご了承ください。

• できるだけ湯本さんの使った表現をそのまま使っています。

• 他のコンテンツに関しては以下ブログを参照ください。

• http://mhlyc.hatenablog.com

3

http://mhlyc.hatenablog.com

はじめに（WACATE2015夏アジェンダ）

1. ポジションペーパーセッション

2. BPPセッション

3. オリエンテーションとエンジニアのモチベーション

4. 「ゆもつよメソッド」ワークショップ（本発表の対象）

5. 夜の分科会

6. テスト設計コンテスト優勝者セッション

7. 「ゆもつよメソッド」ワークショップ２（本発表の対象）

4

ワークショップの流れ• 「演習1-A」実務経験でのやり方で演習してみる

• 「ゆもつよメソッド解説１」（入力、出力、変換、貯蔵について）

• 「演習1-B」仕様項目の特定（サポート、相互作用除く）

• 「ゆもつよメソッド解説２」（サポート、相互作用について）

• 「演習1-C」仕様項目の特定（サポート、相互作用含む）

• 「演習２」題材を変えて仕様項目の特定

5

「演習1-A」実務経験でのやり方で演習してみる• 「演習1-A」実務経験でのやり方で演習してみる






6

• テストベース配布（ヘッドセット）

• 実務経験でのやり方で、テストパラメータと値、実施する操作とその期待結果を書き出し

時間が足りない！

「演習1-A」実務経験でのやり方で演習してみる

7

なぜ時間が足りないのか？• 普段からそもそも時間を意識してテストケースを作成していない

• 普段からそもそもちゃんとテストベースを読めていない

• テストベースを順序通り詳細に読み進めているため、細かい仕様にばかり目がいってしまい、全体の仕様把握に時間がかかる（湯本さんの指摘）

• まずは全体を大きく捉え、テスト対象を網羅しているかわかりやすく整理するべき

• ゆもつよメソッドの利点

8

「ゆもつよメソッド解説１」（入力、出力、変換、貯蔵について）• 「演習1-A」実務経験でのやり方で演習してみる






9

「ゆもつよメソッド解説１」（入力、出力、変換、貯蔵について）• テストプロセスについて

• ISTQBの定義するテストプロセスについて

• テスト開発プロセスのおさらい

• ゆもつよメソッドについて

• ブラックボックステストにおけるテスト分析の課題

• テストカテゴリをベースにしたテスト分析の方法

• ゆもつよメソッドのメリット10

「ゆもつよメソッド解説１」テストプロセスについて

• テスト実行だけでは、「なぜその行為をするのか？」が不明

• ISTQBでは、テストプロセスを以下の活動に分けて考えるとしている

• 分析する：テストを作れるように、テスト対象を分解する

• 設計する：テスト分析の結果をもとに、目的に沿ったテストを作る

• 実装する：テストを実行できるようにする（手順を決める、テストスクリプトを書くなど、テスト実行にさらに近い作業）

計画テスト終了基準の評価と報告

テスト終了作業設計コントロール分析実装実行

↓テスト開発プロセス

12

「ゆもつよメソッド解説１」テストケースの構造とプロセス

13

テスト分析フライト予約テスト対象フィーチャ

購入金額の計算（料金クラス×人数に税率をかけた金額になること）テスト条件（仕様項目と期待結果）

テスト設計方針

テスト詳細設計

テスト技法を活用

テストパラメータ - クラス - 人数 - 日程

値 - エコノミー - ３人 - 06280900-

アクション 1.フライト予約画面起動 2.必須項目を入力

期待結果 - 15万×3×1.08＝48.6万

- 金額欄に表示

テストケース

「ゆもつよメソッド解説１」テストケースの構造とプロセス

14

テスト分析フライト予約テスト対象フィーチャ

購入金額の計算（料金クラス×人数に税率をかけた金額になること）テスト条件（仕様項目と期待結果）

テスト設計方針

テスト詳細設計

テスト技法を活用

テストパラメータ - クラス - 人数 - 日程

値 - エコノミー - ３人 - 06280900-

アクション 1.フライト予約画面起動 2.必須項目を入力

期待結果 - 15万×3×1.08＝48.6万

- 金額欄に表示

テストケースゆもつよメソッドのターゲット

「ゆもつよメソッド解説１」ブラックボックステストにおけるテスト分析の課題

• ブラックボックステストのテスト設計では、漏れや重複が起こりやすい

16

ホワイトボックステスト

ブラックボックステスト

テスト対象の構造を分析し、網羅テスト対象の仕様を分析し、網羅

詳細化する際に、コードの構造をベースにできる →一貫性を確保しやすい

詳細化する際に、ルールに一貫性がない →経験則に頼ることが多い

• 「大項目」「中項目」「小項目」といった分解、詳細化の問題点

• 個人的には耳が痛いです。

17

大項目中項目小項目１小項目２小項目３テストケース

印刷設定印刷部数 - - 100部印刷した場合

設定プリント設定

「印刷部数が99部を超えました」と表示されること

同じテストケースを実行してしまっている

「ゆもつよメソッド解説１」ブラックボックステストにおけるテスト分析の課題

• ブラックボックステストで行うテスト分析（仕様項目特定）のためのルールを提案

• テストカテゴリを活用する

• 通称：ゆもつよメソッド

• 概要（４つのポイント）

• 論理的機能構造

• テストカテゴリ

• ドキュメントフォーマットと実施順序のルール化

• 仕様項目特定パターン

18

「ゆもつよメソッド解説１」テストカテゴリをベースにしたテスト分析の方法

• 大きく捉えて、テスト対象を網羅しているかわかりやすい

• 細かいことではなく、テストしなければならないことを先に洗い出すことができる

19

「ゆもつよメソッド解説１」ゆもつよメソッドのメリット

よくある問題1. 当たり前すぎる仕様はドキュメントに書かれないことがある → 仕様書を細かく見ているだけだと当たり前なテストが漏れる 2. 仕様書には機能についての説明が散漫しているため、細かく見ていると重複するかといって、多すぎるからと全体を捉えずに省くと、漏れる

テスト条件（仕様項目）の段階でテストが十分か、漏れがないかといった確認が可能になる

• テスト対象の仕様を機能一覧として整理

• 論理的機能構造（次ページ参照）は、フィーチャの中の構造を想定しMECEにテストするための参照モデル

• 論理的機能構造の各要素は必要なテスト条件（仕様項目）を見つけるためのガイドになる

• フィーチャ：「該当のテストレベルから見た機能」と同義

20


21

外部観察できる仕様

機能組合せ

外部

出力調整入力調整

変換

貯蔵

エクスターナル

サポート

相互作用

フィーチャフィーチャフィーチャ

内部に関わる仕様

テスト実行

22


機能組合せ

外部


変換

貯蔵


サポート

相互作用



メインでやること

テスト実行

23


機能組合せ

外部


変換

貯蔵


サポート

相互作用



テスト実行

メインの処理をやりやすくする。（DB格納など）

• テストカテゴリについて

• テスト条件（仕様項目）を見つける際に、一貫性のある解釈をするために、論理的機能構造の各要素ごとに、テスト対象から見てふさわしい名前付けをしたもの

• テストカテゴリは、テスト対象とフォールトの知識から導出される

• 決定したテストカテゴリに対して、合意形成をする

24


• テストカテゴリ

25


論理的構造テストカテゴリ意味付け（想定する欠陥）入力調整画面入力入力チェック、入力画面の制御

ボタン操作画面遷移のルール、処理起動出力調整表示処理結果の表示、出力数の制御

帳票出力印刷内容、印刷フォーマット変換計算料金計算貯蔵検索検索条件の組合せ、検索結果

登録/更新/削除 DB処理相互作用反映 DB処理結果の他機能への反映サポートエラー処理エラー復旧処理

論理的機能構造テスト対象の知識過去に遭遇した欠陥の知識

• ドキュメントフォーマットと実施順序のルール化

26


Step1. テスト対象フィーチャを選択

Step2. テストカテゴリを決めて合意

Step3. 仕様項目と期待結果を特定して整理

Step4. テストパラメータを特定して整理

Step5. テスト条件一覧をチェック

論理的機能構造テスト対象

フィーチャ一覧

テストカテゴリ

テスト条件一覧

テスト分析マトリクス

仕様項目/期待結果

テストパラメータ

テスト分析の実施ステップ

• テスト実行時のデータ入出力パターン

• テストとは、データを入力し、出力したデータを確認する行為である

27


テスト実行のデータの入出力は 9パターン(3×3)に集約できる

両方への出力

内部からの入力

両方からの入力

外部への出力

内部への出力データ出力

データ入出力

外部からの入力

データ入力

28


機能組合せ

外部


変換

貯蔵


サポート

相互作用



テスト実行

テスト実行時のデータ入出力パターンをシミュレーション

仕様項目の特定（サポート、相互作用除く）• 「演習1-A」実務経験でのやり方で演習してみる






29

演習の進め方（演習1-B、演習1-C、演習2共通）• テストすべき仕様項目を特定する（前提：テストカテゴリは決定済み）

• まずは仕様を読み込み、データの入出力をシミュレーションする→論理的機能構造のモデルを活用

• 論理的機能構造の、どこの箱の結果を確認するか？で仕様項目をテストカテゴリに割り振る

• テストカテゴリは特定した仕様項目を分類し、見やすくしている

• 今までの経験から、仕様項目に不足がないか見直す

30

「演習1-B」仕様項目の特定（サポート、相互作用除く）• 感想

• テストカテゴリのどこに割り振るかで混乱する（ヘッドセットの「着信」は、対向機入力？音声出力？）

• 結果として同じテストケースとなる（かぶる）ことはあり得る

• ただし、その場合でもテストパラメータの選び方は異なることがある。（「着信すること」を確かめるのか、「着信音が鳴ること」を確かめるのかでテストパラメータは異なるはず）

31

１日目終了

• 続きは２日目

32

「ゆもつよメソッド解説２」（サポート、相互作用について）• 「演習1-A」実務経験でのやり方で演習してみる






33

「ゆもつよメソッド解説２」テストカテゴリを活用したテスト分析の方法

（解説続き）

34

• テスト条件は、テストの視点から見たテスト対象の仕様項目である

• ブラックボックステストは外部観察によるテスト設計なので、テストベースに含まれるフィーチャから選択していくべき

• 仕様書をそのまま利用するのではなく、フィーチャ単位で整理する

• テストカテゴリとは、テストすべきフィーチャを抜け漏れなく多面的に見るための分類である

• 論理的機能構造は、テストカテゴリを導く時のベースとなるモデル→構造を推測する

35

テストパラメータアクション

テストすべきフィーチャ


欠陥の知識論理的機能構造テストベース

仕様項目

期待結果

事後条件出力値事前条件事前入力

1..*

1..*1..*1

1..*1 1

*

1

1 *1..* 1

テスト分析結果である、テスト条件の構造

0..*

36





仕様項目

期待結果


1..*

1..*1..*1

1..*1 1

*

1

1 *1..* 1


0..*

37





仕様項目

期待結果


1..*

1..*1..*1

1..*1

0..*

1*

1

1 *1..* 1


38





仕様項目

期待結果


1..*

1..*1..*1

1..*1 1

*

1 *1..* 1

テスト条件


10..*

39





仕様項目

期待結果


1..*

1..*1..*1

1..*1 1

*

1 *1..* 1

テスト条件

「XXな場合、◯◯すると□□となること」


10..*

「ゆもつよメソッド解説２」テストカテゴリの作成方法

40

• 入力、出力、変換、貯蔵に該当するテストカテゴリについて

• 機能仕様書から該当するキーワードを洗い出し、リスト（次ページ参照）に入れていく

• そのキーワードを象徴するような名前をつける

• 名前付けしたテストカテゴリの意味をメンバーで共有する

• 入力、出力、変換、貯蔵に該当するテストカテゴリは、テスト対象を理解した結果である

41

入力出力変換貯蔵サポート相互作用

起動/終了パワーボタン

ピープ音終了処理の対向機反映

BlueTooth接続

パスワード入力

対向機機器名表示

ペアリング実施

ペアリング対向機情報

接続状態ペアリング対向機反映

ワイヤレス再生

対向機の音声入力

音楽再生ストリーミング

停止状態再生状態

スイッチリモコンボタン再生開始/

停止停止状態再生状態

ボリュームコントロールピープ音ボリューム音量の保存音量設定変

更可/不可音量設定値の共用

ハンズフリー通話接続着信

音声再生ボイスダイヤル

音声出力先の変更

初期化/リセット設定初期化

機能一覧



42

• サポート、相互作用に該当するテストカテゴリについて

• テスト対象フィーチャのテストによって、内部的に呼び出される別処理の結果確認のこと

• 自処理の操作で完結するテストを「サポート」と呼ぶ

• 他処理との連携操作が必要なテストを「相互作用」と呼ぶ


43

• サポート、相互作用に該当するテストカテゴリについて

• 「連動処理」「割り込み」「リソース共有」「反映（副作用）」に該当するものを仕様からピックアップ

• 自処理実行中に確認できるものを「サポート」、他処理で確認するものを「相互作用」に分類

• そのキーワードを象徴するような名前をつける

• 名前付けしたテストカテゴリの意味をメンバーで共有する

• サポート、相互作用に該当するテストカテゴリは、テスト対象の内部を理解した結果である

44

入力出力変換貯蔵サポート相互作用

起動/終了パワーボタン

ピープ音終了処理の対向機反映

BlueTooth接続

パスワード入力

対向機機器名表示

ペアリング実施

ペアリング対向機情報

接続状態ペアリング対向機反映

ワイヤレス再生

対向機の音声入力

音楽再生ストリーミング

停止状態再生状態

スイッチリモコンボタン再生開始/

停止停止状態再生状態

ボリュームコントロールピープ音ボリューム音量の保存音量設定変

更可/不可音量設定値の共用

ハンズフリー通話接続着信

音声再生ボイスダイヤル

音声出力先の変更

初期化/リセット設定初期化

機能一覧


仕様項目の特定（サポート、相互作用含む）• 「演習1-A」実務経験でのやり方で演習してみる






45

• 感想

• サポート、相互作用に何が当てはまるのか、考え方に慣れるのが難しい

• ボリュームコントロール機能の例では、「音量設定の変更可能/不可能」を「サポート」、「ヘッドセット・対向機での音量設定値の共用」を「相互作用」で確認するとしている

• サポート、相互作用はあくまでメインの処理ではなく、別処理の結果を確認する項目。キーワードは「反映」や「割り込み」、「共有」など

• 特に相互作用は、他の処理を動かさなければ確認できない項目

46

仕様項目の特定（サポート、相互作用含む）

47


機能組合せ

外部


変換

貯蔵


サポート

相互作用



テスト実行

別処理の結果を確認する

「演習２」題材を変えて仕様項目の特定• 「演習1-A」実務経験でのやり方で演習してみる






48

「演習２」題材を変えて仕様項目の特定

• 感想

• 仕様項目の特定はある程度できた（題材がヘッドセット→フライト予約に変わったのもある？）

• やはり、仕様項目をテストカテゴリごとに分類するところで、解釈の差が生まれる（テスト対象のとらえ方の違い？）

49

おわりに• ゆもつよメソッドを完全に修得することは非常に難しいです。

• 資料を読み返しても、理解度の浅い部分がありました。

• しかし、湯本さんの繰り返し強調されたポイント（分析と設計を分けたい理由、モデリングして考える理由、最初に全体をとらえる理由など）は少し理解できた気がします。

• 引き続き、テスト分析・設計に関しては学習を継続していこうと思います。

50

おわりに• 個人的に、ゆもつよメソッドで業務に活用できそうなこと

• 「はじめから仕様書を詳細に読み込むのはやめて、最初は全体像をつかむことを大切にすること」

• 「ブラックボックステストを考えるとき、構造を推定するためにモデルを用いて、入出力のシミュレーションをしながら考えていくこと」

• これらは、ゆもつよメソッドに限らずエンジニアリングとして基礎的かつ重要なことだと考えます。

51

おまけ　湯本さんにtwitterでした質問• 質問１：「テストカテゴリは、論理的機能構造とフォールトの知識から導出されるもの」という考え方は合っていますか？

• A: 論理的機能構造をベースにして、テスト対象とフォールトの知識から導出されるもの、です。テスト対象の知識も必要です

• 質問２：テストカテゴリは同一階層であるとは限らず、階層構造がある場合もあると思うのですが…

• A: テストレベルごとのテストカテゴリがあって良いと思うので、そういう意味では階層構造を持ちます。ただ、より内部に入っていくと内部構造を推定する必要はなくなります

52

Wacate2015summer_report

Software

Transcript of Wacate2015summer_report