テスト設計コンテスト２０１７
Ｕ-３０クラス
話題沸騰ポットのテスト設計
チーム ＯＰＴｉＭ

2もくじ
1. 前提条件の説明
2. テスト設計の目的
3. テスト設計のきまりごと
4. テスト分析
5. テスト設計
6. シナリオ作成
7. 優先順位の決定
8. これからやること3

1. 前提条件の説明
 チーム紹介
 開発環境 製品のターゲット

4

チーム紹介
 オプティムのMDM製品をテストしていたがある日突然新製品のポットをテストしてくれと言われて困惑している３人
 まつもとゆきひろ（リーダー）
 レビュー&諸々の責任担当
 ちひろ
 飼い猫のしいねちゃんが世界で一番かわいい みくさん iOS MDMのことならまかせろ（ポット？何ですかそれ）5

認識合わせしやすい開発環境• 自社開発• 社内で開発し、社内でテストする• 設計/実装チームは座席の隣の島で仕事をしている• ハードウェア部分をテストする温度制御テストチームはすぐ後ろの席で仕事をしている• テスト実装チームは社外にいるが、チャットツールでいつでも話ができる

担当範囲 : ソフトウェア部分のテスト

6

子どもがいる環境がターゲット• 家庭、保育園、小学校など• 乳児～小学校就学前の子どもがいても安心して使えるもの• 小学校に上がったばかりの子どもでも使いやすいもの
幼稚園や保育園に新米パパ＆ママに

7

2. テスト設計の目的① 仕様の不備を見つける② 不要な工数を削減する③ テストの方向性を定める

8

2. テスト設計の目的① 仕様の不備を見つける② 不要な工数を削減する③ テストの方向性を定める

9

仕様の不備を見つける「○○したらどうなりますか？」「うーん…やってみないとわからないですねぇ」
そのままテストを進めると…

 欠陥を見逃す
 手戻りが大きくなる• 事前の認識合わせで期待値を明確にする• 曖昧な仕様、ふさわしくない仕様を実装より前に指摘する

10

2. テスト設計の目的① 仕様の不備を見つける② 不要な工数を削減する③ テストの方向性を定める

11

不要な工数を削減する
 メインターゲットが利用しない機能、使えない機能は思い切って削る
 使ってもらえないものを作るのは工数の無駄 それよりも必要な機能に時間をかけて心理的な欠陥を減らすようにする
余裕

迫る納期

欠陥の見落とし確実なテスト12

2. テスト設計の目的① 仕様の不備を見つける② 不要な工数を削減する③ テストの方向性を定める

13

テストの方向性を定める
 メインターゲットは子どもがいる環境

 子どもがいる環境を中心としたシナリオを作成
 乳幼児とその親
 保育士
 小学生
 etc…

14

3. テスト設計のきまりごと① 質疑応答表の記載
 疑問点、仕様の指摘は「質疑応答表」として文書に残し、やりとりする② 観点表との関連付け
 質疑応答表をきっかけに仕様変更が行われた場合を考慮し、観点表と質疑応答表を関連付けておく

15

質疑応答表の記載
質疑応答表（一部抜粋）
ここから仕様変更が発生することが多々あるため、後から理由を追いやすいように記録しておく• 仕様の不明点の質問• 仕様の記載不足、考慮不足点の指摘• 仕様に関する改善要望 などを記載

16

観点表との関連付け
質疑応答表

観点表
起票時に関連付け

質疑応答表の回答によって仕様が変更された場合は観点表の対応する部分を修正する

確認の手間を減らし、修正漏れを防ぐ

17

4. テスト分析① テストベース読み込み
 テストベース（要求仕様書）の読み込みを行う② 観点表の作成
 テストすべき点を観点表にまとめる③ 質疑応答表への記載
 読み込む中で発生した疑問点や仕様への指摘を質疑応答表にまとめる

18

テストベースの読み込み
テストベース

３色ボールペンを使って要求仕様書を読み込む
緑 : 機能仕様として大事な部分
赤 : 観点として特に大事な部分
オレンジ : 疑問点、改善要望

観点表

質疑応答表

19

テストベース

観点表の作成緑 : 機能仕様として大事な部分
赤 : 観点として特に大事な部分
オレンジ : 疑問点、改善要望

観点表

緑・赤でチェックした
テストすべき点について観点表に書き出す
機能番号や質疑応答表の項番を記載し対応を取りやすくする20

質疑応答表への記載
テストベース
緑 : 機能仕様として大事な部分
赤 : 観点として特に大事な部分
オレンジ : 疑問点、改善要望

質疑応答表
オレンジでチェックした疑問点・改善要望を質疑応答表に書き出す（例）タイマ機能については曖昧な仕様と必須でない機能であることから機能の削除を提案

21

5. テスト設計① テストケースの作成
 テスト観点表からテストケースを作成する② 観点の追加
 後から思いついた観点があれば表に書き足してテストケースを作成③ 質疑応答表への記載
 ここでも不明点などが発生したら都度質疑応答表に書きだす22

テストケースの作成
観点表

テスト分析で出した観点

テストケース

具体的な手順は書かず条件や期待値のみ記載する※削除提案中のタイマ機能はテストケースには起こさなかった

23

観点の追加
観点表

テスト分析で出した観点

テストケース

テストケース作成中に思いついた観点は観点表に戻って書き足す

24

質疑応答表への記載
観点表

テスト分析で出した観点

質疑応答表

テストケース作成中に出た疑問点・改善要望を書き出す観点表と対応がとれるようにしておくことを忘れずに！

25

6. シナリオ作成① ユーザ像の抽出
 メインターゲットとなるユーザは誰か？
 ユーザは製品をどのような場面で利用するのか？

② シナリオの作成
 そのユーザの生活の中でポットはどういう役割を担うのか？

26

ユーザ像の抽出
マインドマップでユーザ像を抽出• 家族構成• ポットを使う場所• ポットの用途• 発生しうるイベントやハプニング

27

シナリオの作成
マインドマップでユーザ像を抽出• 家族構成• ポットを使う場所• ポットの用途• 発生しうるイベントやハプニングそれぞれの要素を複数満たす
シナリオを作成

28

7. 優先順位の決定
 テストケースごとに優先順位を決める• Ａ : 最優先項目• Ｂ : 優先度Ａが完了したのちに実施

29

優先順位の判断基準• 欠陥があると危険な項目はＡ• ユーザの目的が果たせなくなる• ユーザの安全性を保障できなくなる• 欠陥があっても危険ではない項目はＢ• 別の手段で目的を果たせる• ユーザに危害が及ばない30

8. これからやること① 質疑応答表の回答を確認
 回答によっては観点、テストケースを修正② テスト実装・実施依頼
 テストケース仕様書をテスト実装チームに提出しテスト実装を依頼

31

質疑応答表の回答を確認
質疑応答表• 基本的には回答タイミングを設計・実装チームに任せる• 仕様への影響度が高いもの、ハードウェア仕様に関わるものは口頭で打ち合わせしながら回答を埋めていく• 回答による仕様変更があれば観点およびテストケースに反映する

32

テスト実装・実施依頼
テストケース
手順例• 一部のテストケースに手順例を記載済み• 手順例を参考にテスト実装および実施をしてもらう

33

まとめ
1. 前提条件の説明
2. テスト設計の目的
3. テスト設計のきまりごと
4. テスト分析
5. テスト設計
6. シナリオ作成
7. 優先順位の決定
8. これからやること