テスト分析・設計について、釈然としないところ

リリカル(@mhlyc)

⾃⼰紹介（空気を読んでやるか決める）

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

2

⾃⼰紹介

• サンシャイン池袋の近くで働いています。リリカルです

• 某SIerの品質保証部です • テスト分析、設計について釈然と

しないところを発表します

3

この15分のゴール

• 確かにテスト分析と設計っていまいちよくわからないかも、と思ってもらうこと

• すでに問題意識がある⽅は聞き流してくださってOKです

4

事の発端

• テスト分析もテスト設計も、要するにどんなテストが必要なのか考えるってことでしょう？

• 別に分ける意味なくない？

5

事の発端

• テスト分析もテスト設計も、要するにどんなテストが必要なのか考えるってことでしょう？

• 別に分ける意味なくない？

6

本質的には違うから、 分けるべきだ

分析と設計で やることが違う

そもそもの話

• なんで分析とか設計とか必要になるんでしたっけ？

• 仕様書の語尾を〜すること* って 変えるだけではダメ？何がダメ？

* CPM法：Copy & Paste & Modify法。  仕様書の語尾を書き換えるだけでテストケースとする。

7

（私の思う）CPM法の問題点

• 仕様書に書いてあることしかテストしないので、仕様書に書いてないけど⼤事なことがテストから漏れる

8

そんなの仕様書には 書いてないよ！

（私の思う）CPM法* の解決⽅法

• 仕様書以外の何かをベースにして、必要なテストを考える

• 仕様書の内容から連想した観点をテストケースに追加する

9

+ α仕様書に書いてない

こともテストしよう！

（私の思う）CPM法* の解決⽅法

• 仕様書以外の何かをベースにして、必要なテストを考える

• 仕様書の内容から連想した項⽬をテストケースに追加する

10

•この作業は「分析」とも⾔えるし、「設計」とも⾔える気がする

•そもそも分ける必要性を感じない

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

I have “Test”11

Test

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

I have “Analysis”12

Test Analysis

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

Ah13

Test Analysis

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

“Test analysis”14

Test Analysis

曖昧なものに曖昧なものをくっつけるんじゃないよ

• 「テスト」も「分析」も曖昧すぎる • 「テスト要求分析」とか「テスト対象

分析」とすれば多少はわかりやすい

15

そもそも分析って何？

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

16

分析の何がわからないのか？

• 分析はアウトプットが曖昧である • 終わったのか終わってないのか

よくわからない • 「きちんと分析する」とはなんだ？

やはりよくわからない

17

テスト分析をしないと困る例

• 仕様が不明瞭なために、必要なテストが漏れる

• ex) 仕様書で明⽰されていない状態を⾒逃してしまう（状態遷移テスト）

• そもそも仕様書の内容が理解できず、何をテストしたらいいのかわからない

18

オレ流テストプロセス定義 （異論は認める）• テスト（対象）分析：仕様書の中⾝を

抜き出して整理したりグループ分け したりして、仕様を読み解くこと

• テスト設計：テストケースの元ネタを作ること

• テスト実装：テストケースを作成すること。単純作業になるので⾃動化推奨

19

先の秋⼭さんの話を踏まえて(p.8)

• テスト分析の出⼒は”識別されたテスト条件”と⾔っているけど、ここでテスト条件とは何のことを⾔っている？テスト条件が曖昧でよくわからない。

• テスト設計には⾼位レベルの設計と低位レベルの設計があるのではないか

20

テスト分析：グループに分けたりして わかりやすくすること

21

仕様

仕様A 仕様B 仕様C 仕様D

分析⼿法

テスト設計：テストケースの元ネタを 作ること

22

仕様

テストケースの元ネタ

テスト技法

テスト実装：テスト設計で作った元ネタからテストケースを作成する

23

テストケースの元ネタ

テスト ケースA

テスト ケースB

テスト ケースC

テスト ケースD

パラメータ決定

テスト設計をしないと困る理由

• 仕様書から直接テストケースを導出すると、なぜそのテストで⼗分なのか説明しづらい （説明責任の⽋如）

• 観点の漏れにも気づきづらい • テスト設計技法を使うとカバレッジの

説明ができる24

テスト設計でやることは何？

• 必要なテストを洗い出すこと • 必要なテストに絞り込むこと

25

• 必要なテストを洗い出すこと • 必要なテストに絞り込むこと

テスト設計でやることは何？

26

これ両⽅ともテスト設計なの？ テスト分析も含んでいる気がする… →やっぱりよくわかんないし分析と  設計セットでいいじゃん！！！

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

27

テスト分析     テスト設計

どういう線引き？

テスト分析とテスト設計のつながりも モヤモヤします

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

28

釈然としないことのまとめ(1/2)

• テスト分析もテスト設計も、何かしらのニーズがあって⽣まれた考え⽅のはず

• でもいつのまにか「CPM法とかないわwww」みたいな⾔葉でごまかされてなぜ必要なのか本当には理解できてないような気がする

• なぜ分析／設計しないと困るのか？ • テスト分析やテスト設計などと⾔っているが、

本質的にやりたいことは何なのだろうか

29

釈然としないことのまとめ(2/2)

• 分析と設計は何が違うの？ • 「テスト分析はできてないけどテスト設計は

できた」ってどういう状況？ • 分析のアウトプットって何？ • 何ができたら分析は終了なの？きちんと分析

できたってどういうこと？ • 結局のところ何がしたいの？

30

参考⽂献

• 「構造化分析とシステム仕様」トム・デマルコ著 ⾼梨智弘 ⿊⽥純⼀郎 監訳, 2012（⽇経BP社）

• 「いかにして問題を解くか」G.ポリア著 柿内賢信 訳, 2011（丸善出版株式会社）

31