2017/2/3　勉強会でのLT資料です。

1. テスト分析・設計について、
釈然としないところ
リリカル(@mhlyc)

2. ⾃⼰紹介（空気を読んでやるか決める）
空前絶後のォォォ！超絶怒涛の品質保証部
品質を愛し 品質に愛された男
そう我こそはァァァァ
たとえこの⾝が滅びようとも
品質求めて命を燃やし
燃えた炎は星となり
⾒るもの全てを笑顔に変える
そう、我こそはァァァァ
サンシャイィィィィン池
2

3. ⾃⼰紹介
• サンシャイン池袋の近くで働いて
います。リリカルです
• 某SIerの品質保証部です
• テスト分析、設計について釈然と
しないところを発表します
3

4. この15分のゴール
• 確かにテスト分析と設計っていまいち
よくわからないかも、と思ってもらう
こと
• すでに問題意識がある⽅は聞き流して
くださってOKです
4

5. 事の発端
• テスト分析もテスト設計も、要するに
どんなテストが必要なのか考えるって
ことでしょう？
• 別に分ける意味なくない？
5

6. 事の発端
• テスト分析もテスト設計も、要するに
どんなテストが必要なのか考えるって
ことでしょう？
• 別に分ける意味なくない？
6
本質的には違うから、
分けるべきだ
分析と設計で
やることが違う

7. そもそもの話
• なんで分析とか設計とか必要になるん
でしたっけ？
• 仕様書の語尾を〜すること* って
変えるだけではダメ？何がダメ？
* CPM法：Copy & Paste & Modify法。
仕様書の語尾を書き換えるだけでテストケースとする。
7

8. （私の思う）CPM法の問題点
• 仕様書に書いてあることしかテスト
しないので、仕様書に書いてないけど
⼤事なことがテストから漏れる
8
そんなの仕様書には
書いてないよ！

9. （私の思う）CPM法* の解決⽅法
• 仕様書以外の何かをベースにして、
必要なテストを考える
• 仕様書の内容から連想した観点を
テストケースに追加する
9
+ α
仕様書に書いてない
こともテストしよう！

10. （私の思う）CPM法* の解決⽅法
• 仕様書以外の何かをベースにして、
必要なテストを考える
• 仕様書の内容から連想した項⽬を
テストケースに追加する
10
• この作業は「分析」とも⾔えるし、
「設計」とも⾔える気がする
•そもそも分ける必要性を感じない

11. 閑話休題：TAaD(Test Analysis and Design)
I have “Test”
11
Test

12. 閑話休題：TAaD(Test Analysis and Design)
I have “Analysis”
12
Test Analysis

13. 閑話休題：TAaD(Test Analysis and Design)
Ah
13
Test Analysis

14. 閑話休題：TAaD(Test Analysis and Design)
“Test analysis”
14
Test Analysis

15. 曖昧なものに曖昧なものをくっつけるん
じゃないよ
• 「テスト」も「分析」も曖昧すぎる
• 「テスト要求分析」とか「テスト対象
分析」とすれば多少はわかりやすい
15

16. そもそも分析って何？
・理解できるように分けること
・⼼の働き（引⽤：「いかにして問題をとくか」）
→⼤きな全体のまま理解できることは
少ない。⼩さな単位に分割することで
理解を助ける
→「解析」に近い？意味解析とか。
16

17. 分析の何がわからないのか？
• 分析はアウトプットが曖昧である
• 終わったのか終わってないのか
よくわからない
• 「きちんと分析する」とはなんだ？
やはりよくわからない
17

18. テスト分析をしないと困る例
• 仕様が不明瞭なために、必要なテスト
が漏れる
• ex) 仕様書で明⽰されていない状態を
⾒逃してしまう（状態遷移テスト）
• そもそも仕様書の内容が理解できず、
何をテストしたらいいのかわからない
18

19. オレ流テストプロセス定義
（異論は認める）
• テスト（対象）分析：仕様書の中⾝を
抜き出して整理したりグループ分け
したりして、仕様を読み解くこと
• テスト設計：テストケースの元ネタを
作ること
• テスト実装：テストケースを作成する
こと。単純作業になるので⾃動化推奨
19

20. 先の秋⼭さんの話を踏まえて(p.8)
• テスト分析の出⼒は”識別されたテス
ト条件”と⾔っているけど、ここでテ
スト条件とは何のことを⾔っている？
テスト条件が曖昧でよくわからない。
• テスト設計には⾼位レベルの設計と
低位レベルの設計があるのではないか
20

21. テスト分析：グループに分けたりして
わかりやすくすること
21
仕様
仕様A 仕様B 仕様C 仕様D
分析⼿法

22. テスト設計：テストケースの元ネタを
作ること
22
仕様
テストケースの元ネタ
テスト技法

23. テスト実装：テスト設計で作った元ネタ
からテストケースを作成する
23
テストケースの元ネタ
テスト
ケースA
テスト
ケースB
テスト
ケースC
テスト
ケースD
パラメータ決定

24. テスト設計をしないと困る理由
• 仕様書から直接テストケースを導出
すると、なぜそのテストで⼗分なのか
説明しづらい
（説明責任の⽋如）
• 観点の漏れにも気づきづらい
• テスト設計技法を使うとカバレッジの
説明ができる
24

25. テスト設計でやることは何？
• 必要なテストを洗い出すこと
• 必要なテストに絞り込むこと
25

26. • 必要なテストを洗い出すこと
• 必要なテストに絞り込むこと
テスト設計でやることは何？
26
これ両⽅ともテスト設計なの？
テスト分析も含んでいる気がする…
→やっぱりよくわかんないし分析と
設計セットでいいじゃん！！！

27. 要するにテスト分析と設計の
線引きがよくわかりません
27
テスト分析 テスト設計
どういう線引き？

28. テスト分析とテスト設計のつながりも
モヤモヤします
テスト設計ではテスト分析の成果物を活⽤する
→テスト分析の成果物とは何か？
→テスト分析をしなかった場合のテスト設計は
どうなるのか？
「テスト設計はしているけどテスト分析をして
ない」という状態のイメージがつかない。
やっぱり分析と設計はセットなのでは？
28

29. 釈然としないことのまとめ(1/2)
• テスト分析もテスト設計も、何かしらのニーズ
があって⽣まれた考え⽅のはず
• でもいつのまにか「CPM法とかないわwww」
みたいな⾔葉でごまかされてなぜ必要なのか
本当には理解できてないような気がする
• なぜ分析／設計しないと困るのか？
• テスト分析やテスト設計などと⾔っているが、
本質的にやりたいことは何なのだろうか
29

30. 釈然としないことのまとめ(2/2)
• 分析と設計は何が違うの？
• 「テスト分析はできてないけどテスト設計は
できた」ってどういう状況？
• 分析のアウトプットって何？
• 何ができたら分析は終了なの？きちんと分析
できたってどういうこと？
• 結局のところ何がしたいの？
30

31. 参考⽂献
• 「構造化分析とシステム仕様」トム・デマルコ著
⾼梨智弘 ⿊⽥純⼀郎 監訳, 2012（⽇経BP社）
• 「いかにして問題を解くか」G.ポリア著
柿内賢信 訳, 2011（丸善出版株式会社）
31