JaSST’14 Tokyo

魁!! 智美塾「テストアーキテクチャ設計の質について議論しよう」
智美塾塾長＋塾生一同智美塾設立経緯とその後

壱・智美塾とは、JaSST’09 Tokyoのクロージングパネルで提示されたテストライフサイクルを進化させつつ、塾長の厳しい指導のもと、塾生たちが自らの“テスト開発方法論”を目指し活動する梁山泊である。
テスト
要求分析

テスト
アーキ
テクチャ
設計

テスト
詳細設計

テスト
実装

テスト
実施

・JaSST’10 Tokyo以降、テストアーキテク
チャ設計を中心にその考え方の一部と、考え出す過程の議論を披露してきた。
1

智美塾設立経緯とその後

弐・JaSST’13 Tokyoからの1年、智美塾ではテストアーキテクチャ設計の「良さ」とは何か、テストの品質特性について議論を重ねてきた。
・JaSST’14 Tokyoでは、この議論をもとに、具体的な例を用いたテストアーキテクチャ設
計のリファクタリングの過程および、考え方を紹介する。
・本日の議論を通してテストアーキテクチャ
設計の大切さ、テスト「設計力」について少しでも感じていただければ幸いである。
2

本日の要旨と目的
壱．テストプロセス、テストアーキテクチャについての振り返り
議論の導入として、テストアーキテクチャ設計についての議論を披露し、この後行うテストアー
キテクチャ設計リファクタリングのベースとする。

弐．テストアーキテクチャ設計リファクタリ
ング
テストケース設計の具体例を紹介し、そのリファクタリングを通してその中に潜むテストアー
キテクチャ設計の品質について議論し、自身のテストの取り組みの向上の一助とする。
3

壱．
テストプロセス、
テストアーキテクチャについての振り返りテストの目的

JSTQB

シラバスより• 欠陥を摘出する。

– システムが稼動する前に欠陥を摘出して修正する• 対象ソフトウェアの品質レベルが十分であることを確認する。

– 契約や法律上の適格要件や各業界の標準に合致していることを証明する• 意志決定のための情報を示す。
• 欠陥の作りこみを防ぐ。

エンジニアリングの観点と品質保証の観点がある。
「何をどうテストして何を得るか」ということを明らかにしないと何をしているのかわからなくなる
5

従来型テスト設計• ソフトウェア仕様書からの書き写し→機能のテストが中心となりがち
正常ケースはともかく、異常ケースは？
何を確認し、何が確認できているかわからない• テストが十分行えているかどうかの自信が持てない• テスト全体を把握し、過不足を見つけ出すために
テスト全体の設計＝テストアーキテクチャ設計が必要
6

テストアーキテクチャ設計では• テスト観点を列挙し分析する– テスト観点：テストの関心ごとを列挙したもの
テスト目的とテスト対象を網羅する• その上で、テスト全体像を設計する– テスト全体を俯瞰できる– 網羅性を確保できる(抜け漏れ防止)– 複数のテスト間での無駄を排除できる– テストレベルでの分担がしやすくなる

7

テストプロセス
前回までの智美塾のおさらいソフトウェアテスト開発プロセスの基本的考え方• ソフトウェア開発プロセスと
ソフトウェアテスト開発プロセスを対応させると•ソフト要求分析•ソフトアーキテクチャ設計•ソフト詳細設計•ソフト実装•テスト要求分析•テストアーキテクチャ設計•テスト詳細設計•テスト実装• 各プロセスの成果物を対応させると•ソフト要求仕様(要求モデル)•ソフトアーキテクチャモデル•ソフトモジュール設計•プログラム•テスト要求仕様(要求モデル)•テストアーキテクチャモデル•テストケース•テストスクリプト

9

テスト開発ライフサイクル／
ソフトウェアテスト開発プロセスのイメージ
テストする

テスト設計（or テスト計画 or テスト実施準備）

テスト実施

テスト
アーキテクチャ テスト
詳細設計
設計

テスト
実施

テスト
要求分析
テスト要求の獲得と整理・
テスト要求
モデリング

テストアーキテクチャ
モデルの検討

テスト
実装

具体的な
テスト技法のテスト手順・
適用によるテストケースの テストスクリプトの記述
列挙

テストの実施・
記録・報告

10

テスト要求分析
ＩＮＰＵＴ

ＯＵＴＰＵＴ

ソフト／システムへの要求• 要求仕様書• システム仕様書• ソフトアーキテクチャ設計書
テストプロジェクトへの要求
• コスト
• 納期
• 要員(数、スキルや経験)• (顧客から適用を要求された)テスト手段、テスト技法、
シミュレータ、テスト環境など

テスト要求分析•テスト要求定義書•テスト要求モデル•テスト観点群11

テストアーキテクチャ設計
ＩＮＰＵＴ

テスト要求定義書• テスト要求モデル• テスト観点群

ＯＵＴＰＵＴ

テスト
アーキテクチャ設計

管理的側面•テスト計画書•テストアーキテクチャ設計書
技術的側面

12

テストアーキテクチャ設計• テスト要求分析で得た結果を再構築
負荷テスト

コンポーネントテスト

テストフレーム
テスト目的
負荷

テストフレーム
テスト対象
ネットワーク

テスト目的
機能

テストフレーム
テスト目的
負荷

テストフレーム
テスト対象
CPU

テスト目的
性能

xxテスト

xxテスト

テストフレーム

テストフレーム

目的

目的

対象

テストフレーム

テスト対象
コンポーネント

対象

テストフレーム

テスト対象
コンポーネント

ｘｘテスト

ｘｘテスト

テストフレーム

テストフレーム

目的

目的

対象

ｘｘテスト
テストフレーム

目的

対象

目的

対象

対象

目的

・・・

対象

13

テストアーキテクチャ設計をする目的• テスト全体を俯瞰できるようになる（テスト設計者）– テストのバランスが良くなる– テストの大きな抜け漏れを防ぐことができる• コミュニケーションが円滑になる（テストチーム・グループ）– テスト設計のレビューで使うことで、テスト設計の理解が促進される– テスト設計・実装・実施の作業分担や協働作業がしやすい
14

テスト詳細設計
ＩＮＰＵＴ

ソフト／システムへの要求• 要求仕様書• システム仕様書• ソフトアーキテクチャ設計書• ソフトウェア詳細設計書
テストアーキテクチャ設計からのアウトプット• テストアーキテクチャ設計書

ＯＵＴＰＵＴ

テスト詳細設計•テスト詳細設計書×n（例：テストケース、
テスト項目 etc.）

テスト詳細設計モデル

15

テスト実装
ＩＮＰＵＴ

ソフト／システムへの要求• 要求仕様書• システム仕様書• ソフトアーキテクチャ設計書• ソフトウェア詳細設計書• 各種設定、各種マニュアル類、各種運用設定書
テスト詳細設計からのアウトプット• テスト詳細設計書

ＯＵＴＰＵＴ

テスト実装

テスト実施手順書•テストスクリプト/手順•テストデータ•テストオラクル(期待値)•事前条件/事後条件

16

弐．
テストアーキテクチャ設計
リファクタリングある日のお話• テスト担当(実行)者とコンサルの会話• テスト管理(レビュー)者とコンサルの会話

18

テスト担当者の話•

１

テストを教えている人って、現場知らないですよね。
– どうしてそう思うの？

•

だって、新しくテストケースを作る話しかしないじゃないですか。
現場はね。既にあるテストケースを加工して作っているんですよ。
その話をするコンサルって少ないでしょ。
– まぁ、セミナーとかでは、そういう話は少ないかもね。

•

そうそう、この前あった話を聞いてくださいよ。
– あっ、はい。

•

既存システムの改修なので、既にあるテストケースを使うんだけど、このテストケースが曲者で。
使えるテストケースと使わないテストケースを区別しなきゃならないんだけど、これができないんですよ。
たとえば、こんなの。
19

駄目なテストケース例：新規入会画面テストケース
手順

期待結果

新規入会画面を開く
メールアドレス、パスワード入力欄がある
新規入会画面で、メールアドレス：aaa@bbb.com、パスワー
確認画面に遷移する
ド:1234を入力し、OKボタンを押す
新規入会画面で、メールアドレス：
1234567890123456789012@bbb.com、パスワード：
確認画面に遷移する
123456789012345を入力し、OKボタンを押す
12345678901234567890123@bbb.coまでしか入力
新規入会画面で、メールアドレス：
12345678901234567890123@bbb.comを入力するできない
123456789012345までしか入力できない
新規入会画面で、パスワード：1234567890123456を入力する
新規入会画面で、メールアドレス：aaa@bbb.com、パスワード：123
エラーメッセージが表示されるを入力し、OKボタンを押す
新規入会画面で、メールアドレス：aaa@bbb.ccc、パスワード：1234
エラーメッセージが表示されるを入力し、OKボタンを押す
新規入会画面で、メールアドレス：aaa@bbb.com、パスワード：!!!!
確認画面に遷移するを入力し、OKボタンを押す
新規入会画面で、メールアドレス：aaa@bbb.com、パスワード：
エラーメッセージが表示される<<>>を入力し、OKボタンを押す
新規入会画面で、メールアドレス：あああ@bbb.com、パスワード：
エラーメッセージが表示される「あいうえ」を入力し、OKボタンを押す
新規入会画面で、登録済のメールアドレス、パスワードを入力し、エラーメッセージが表示される
OKボタンを押す
新規入会画面で、メールアドレス：aaa@bbb.com、パスワー
メールアドレス：aaa@bbb.com、パスワード:****がド:1234を入力し、OKボタンを押す
表示される
メールアドレス：
新規入会画面で、メールアドレス：
1234567890123456789012@bbb.com、パスワー
1234567890123456789012@bbb.com、パスワード：
123456789012345を入力し、OKボタンを押す
ド：***************が表示される

テスト担当者の話

２– これのどこが問題だと思うの？

•

そんなこと言ってるから現場知らないって言われるんですよ。
– そんなことを言わずに、どこに問題があると思うの？

•「このIDでログインして、このボタンを押して、これを確認して」
こういうふうに書いてあるテストケースは、やっかいなの。
手順が書いてあるから、テストはできるんです。
でも、何を目的としたテストケースなのか分からないので、テストケースが削れないの。分かります？！
– じゃあ、全部テストするしかないか。

•

馬鹿じゃないの。 全部テストするわけ無いでしょう！
テスト手順をバラしていくの。何のためにテストしているのか
分からないから、そうするしかないの。
– バラしていくって、具体的には？

21

テスト担当者の話

３•

そこよ。そこ。そんなやり方、誰からも教わっていないから、勝手にバラしていくんですけど、やる度に違うやり方になっちゃう。

•

バラし方が確立していないっていうか。だから良いやり方を教えて欲しいのに、セミナーで話す人いないんですよ。

• ねぇ。私の不満、分かります？
•

あとね、テストケースは、手順の中の入力値がガチガチに決まってるんだけど根拠が書いてない。改修案件としてどこまで変更していいか分かんないのよ。そのまま使うしか無いんだけど。

•

ちょっとお。聞いてます？

22

テスト管理者の話•

１

話を聞いてもらっても良いですか？
ちょっとばかり愚痴になってしまうかもしれないのですが。
– はい。

•

状況からご説明しますと、あるシステム開発で協力会社が作成したテストケースがあまりにも悪くて、十分なテストがなされないまま納品されまして。

•

一社だけならまだしも、ほぼ同時にそんな事態が頻発したものです
から経営の方が問題視しまして、協力会社が作成したテストケースを全部レビューすることになりました。
– それは大変ですね。

•

はい。レビューアーとして何人かアサインされたのですが、その中に私もいまして。
– どうでしたか？

•

こんなテストケースがありました。
23

駄目なテストケース例：機能組合せテスト
テレビ視
聴

手動録画

予約録画

テレビ視
聴

ダビング

HDDビデ
オ再生

BDビデオ 動画取り
再生
込み

○

手動録画

○

予約録画

○

○
○

写真取り
込み

スライド
ショー

設定

○

○
○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

HDDビデ
オ再生

○

○

DVDビデ
オ再生

○

○

○

BDビデオ
再生

○

○

○

動画取り
込み

○

○

動画再生

○

○

写真取り
込み

○

○

スライド
ショー

○

○

○

○

○

○

○

動画再生

○

ダビング

設定

DVDビデ
オ再生

○

○

○

○

○
○

○

○

○

○

○

○

○

テスト管理者の話

２•

機能×機能のマトリクスが書いてあり、交差したところに○が書いてあります。

•

書いた方は分かるのでしょうけど、私には分かりません。

•

機能組合せテストなのかとも思いましたが、単機能のテストケースは、ひとつもありません。

•

縦軸が先行、横軸が後続のテスト実施の順序を表現しているかとも思ったのですが、順序的にあり得ないものに○が付いています。
そもそも期待結果が書かれていませんから、ＯＫ／ＮＧの判断もで
きません。

•

このようなマトリクスは、テストケースでは無いと判断して突き返
そうかと思ったのですが、もう少し先まで見てみようと思いまして。

•

あっ、こんな話でいいですか。
– どうぞ。他のテストケースもご覧になったのですね。

25

テスト管理者の話•

３

あの、何て言いましょうか。おそらくテストケースを作成した方が異なるのだと思いますが、次のテストケースもひどいといいますか、
見た瞬間にファイルを閉じてしまいました。
– どんなテストケースだったんですか？

•

今から見れば、それほど悪くは無いのかもしれませんが、マトリクスとのギャップがあまりにも大きくて。

•

一つのテストケースの中に、「～の場合、～の場合、～の場合、～の場合」と条件が列挙されているテストケースでして。次のテスト
ケースは、この条件の一部だけを変更した文章になっています。

•

そんなのが何十行もありまして、もう見ていられなくなりました。
どこかの条件に抜けがあっても、テストケースの一覧だけを見ても指摘は難しいと思うのです。

•

皆さんはどうされているのでしょうか。
26

本日のお題テストベース• NPO法人SESSAME書

話題沸騰ポット要求仕様(GOMA-1015) 要求仕様書 第7版
http://www.sessame.jp/– いわゆる電気ポット(沸騰、保温、給湯機能あり)– コンセント、蓋、沸騰ボタン、保温設定ボタン、解除ボタン、給湯ボタン、タイマボタン、水位メータを備える– 温度設定は3つのモード：高温、節約、ミルク– イベントは7つ：沸騰要求、温度制御停止、沸騰処理完了、エラー検知、給湯要求、給湯要求解除、沸点
到達28あるテスト仕様が提示された29

テストケースへの指摘１

テスト担当者の指摘

30

テストケースから出てくる不明点、疑問点

テスト目的？
何のためにテストをするのかが、
よくわからない・・・

そもそも連続動作できない・・・
値が持つ意味はなんだろう・・・？

見たいのは連続動作だけじゃないよね？
これらの値以外に必要な値はないのかな？
考慮されていない同値クラスやテスト条件があるような・・・？

気になることが多すぎてテストが進みません・・・＞＜

31

テストケースへの指摘２

テスト管理者（レビューア）の指摘

32

テストケースから出てくる不明点、疑問点
60時間は動作確認にここでいう連続動作ってなんだろう？
連続で色々な操作/動作をさせること？
長時間動作のこと？

テスト目的は長いし、長時間動作には短いなあ。

テストケース(実際に行われるテスト）

連続動作
何が目的だろう？
水なしだと保温行
為は止まるはず。

満水で60時間90℃のまま±3度で保温
98℃は確認しな
いのかな？

水なしで60時間保温：

これらも環境テストでは？

±3度の温度制御を確認したい？

電源130Vで60時間

70Vは確認しないのかな？

低気圧下(高山)で60時間沸騰から90℃以下で保温
塩水、満水で60時間90℃のまま±3度で保温

環境テスト
200Vは確認しないのかな？

ミルクは確認しないのかな？

塩水を満水？

電源130V、70Vで動作…
高山(低気圧下)での使用…
理解性が低い高気圧下は確認しないのかな？

同じようなテストが散らばっているなあ。

十分性、網羅性が低い
俯瞰性が低い33

それぞれの指摘のまとめ•

テスト担当者の指摘
–
–
–
–
–
–

•

連続動作→テスト目的？ 何のためにテストをするのかが、よくわからない・・・
水なしで60時間保温→そもそも連続動作できない・・・
電源130Vで60時間→値が持つ意味はなんだろう？
塩水、満水で60時間90℃のまま±3度で保温→見たいのは連続動作じゃないよね？
環境テスト：電源130V、70Vで動作。。。→これらの値以外に必要な値はないのかな？
全体→考慮されていない同値クラスやテスト条件があるような・・・？

テスト管理者の指摘– 連続動作→ここでいう連続動作ってなんだろう？
– 満水で60時間90℃のまま±3度で保温 →60時間は動作確認には長いし、長時間動作には短いなあ。±3度の温度制御を確認したい？
– 水なしで60時間保温 →何が目的だろう？水なしだと保温行為は止まるはず– 電源130Vで60時間 →70Vは確認しないのかな？
– 低気圧化(高山)で60時間沸騰から90℃以下で保温–→これらも環境テストでは？98℃は確認しないのかな？
– 塩水、満水で60時間90℃のまま±3度で保温 →ミルクは確認しないのかな？塩水を満水？
– 環境テスト：電源130V、70Vで動作、、、 →200Vは確認しないのかな？
– 高山(低気圧下)での使用、、、 →高気圧下は確認しないのかな？
– 全体 →同じようなテストが散らばっているなあ。

34もう少し考えてみる気になるコメント• 130Vなどの数値の根拠が書かれていないのは、上流の成果物に根拠が書いてあるのではないか。
根拠まで書くと煩雑になるため、意図して書いていないのではないか。
• 上流文書に書かれていれば、テスト文書に根拠が書かれ
ていなくてもよいというのは、新規で作るならOK。
しかし、保守や派生開発のときに困るのではないか。
• テスト仕様書にどういう情報を載せて、どう解釈させればいいか、をはっきりさせないといけない。
• 要するにテスト文書は、手順書や指示書の類いだから、大きな目的は不要かもしれない。（反論あり）
36

では、
どうするとよくなりますか？

指摘１のケース

テスト担当者のお話

38テストケースから出てくる不明点、疑問点

テスト目的？
何のためにテストをするのかが、
よくわからない・・・

そもそも連続動作できない・・・
値が持つ意味はなんだろう・・・？

見たいのは連続動作だけじゃないよね？
これらの値以外に必要な値はないのかな？
考慮されていない同値クラスやテスト条件があるような・・・？

気になることが多すぎてテストが進みません・・・＞＜

39

リファクタリングの手順
テストケースが持つ目的を明確にする

値が持つ意味を明確にする

・・・つまりこういうテストがしたいんでしょ？
「連続動作」と「環境テスト」に込められた意図を明確にしてテストタイプを整理する

条件に考慮漏れが無いかを考える

足りない値を補う

テストケースを作成する
40

テストケースをリバースする
このテストケースで何を確認したいのだろうか？
を明確にする
値が持つ意味を明確にする※下記の認識で合っているかどうか確認する必要あり

きっとテスト目的が異なるよね…

記載されていたケース

そのテストケースで確認したいこと(想定)

電源１３０Vで６０時間(保温)ギリギリ稼働可能な高電圧の状態で長時間稼働しても保温を続けられることを確認したい

電源１３０V、７０Vで動作…

起こりうる高電圧、低電圧の環境で、各機能が正しく動作するかを確認したい

低気圧下(高山)で６０時間沸騰から
９０℃以下で保温想定される低気圧で長時間沸騰し続けた場合でも壊れないことを確認したい（※この場合は一定時間で沸騰を止められる
仕組みが必要だと思うが・・・）

高山(低気圧下)での使用…

沸点が100℃にならない環境で使っても各機能が正しく動作するかを確認したい（※現状の仕様では沸騰が止まらない気がするが・・・）

41

テストタイプを再考する
ざっくりまとめるとこうなるのではないかと・・・
合目的性を考慮しているつもり。

連続動作と環境を組み合わせて考えたいよね…

一般的な環境サポート内で一般的ではない環境

サポート外の環境

短時間の
操作・稼働

機能が働くことを確認する→機能テスト(状態遷移テストで放置による遷移を考慮しているか要確認)

環境による影響に耐えられるかどうかを確認
する→環境対応テスト

エラー処理が行われるかどうかを確認する
どのように壊れるか？
を確認する→破壊テスト

長時間
連続稼働

連続稼働し続けるかど
うかを確認する→連続稼働テスト(単一イベント/
複合イベント)

環境による影響＋連続稼働に耐えられるかど
うかを確認する→環境対応＋連続稼働テスト

×（テストできない）

42

整理し直す→足りないところを補う
他に思いついた値を出してみよう条件を整理しなおす•さらに補足→この配置で認識が合っているかを確認する•この後、各値についてテスト可能か、テストする必要があるかを考慮する
環境として考慮する条件

通常の値(一般的な環境)

通常とは異なるがエラーにならない範囲の値(サポート内で一般的ではない環境)

起こりうる異常値(サポート外の環境)水位

満水
各水位レベル

ギリギリ水なしの手前→蒸発すると水なし
ギリギリ満水の手前→水が動くと満水位センサーにひっかかる

水なし
満水超え

電圧

100V

130V
70V

200V以上水質

水
クエン酸ポット洗浄
液

塩水
ミルク
お茶
味噌汁
発泡性のポット洗浄液

沸点が130℃を超える
液体
沸点が100℃に満たな
い液体
液体じゃないもの温度

沸騰(100℃)
各モードの温度(98℃ 90℃ 60℃)

気圧が低いところの沸点
気圧が高いところの沸点
氷(0℃以下)気圧

通常の範囲内の気圧

気圧の低い高山地域
気圧の高い地域

周波数

50Hz
60Hz

左記以外で起こりうる周波数

設置状態

水平

傾いた状態

Shizuka Ban
2014/3/26

43

整理し直す→足りないところを補う
条件を整理しなおす•稼働時間以外に操作も考慮•60時間の指定をいったん外してテスト可能な時間を検討しなおす
連続動作

短時間の操作・動作

長時間の連続稼働値
および連続させる操作・動作

稼働時間

単一の操作時間
沸騰やタイマーなど、役割を果たす時間

連続テスト可能な時間保証する連続稼働時間保証する総稼働時間

操作

保温
沸騰
蓋の開け閉め給湯
モード変更
タイマー設定タイマー稼働単一動作で放置
単一操作の繰り返し
複合操作・動作の繰り返し

ポットを連続で利用するときって、
いろんなことをするよね…

44

テストケースを作成し直す
連続稼働テスト•通常行われる操作や稼働を長時間連続的に行えることを確認する
稼働時間の定義(テスト可能な時間を設定)

放置しておくものについては、６０時間とする
複合操作・動作の場合は、4日間(96時間)とする

稼働条件
単一操作・動作

稼働時間
60時間

操作・動作の内容
沸騰から保温状態で放置

給湯し続ける複合操作・動作

下記操作をランダムに繰り返す（状態遷移を網羅させるよ
うにシナリオを作成する）
夜間は保温で放置
保温
沸騰
蓋の開け閉め給湯
モード変更
タイマー設定タイマー稼働保温モードを変更して保温

満水からお湯がなくなるまで
あわせて４日間(96時間)

あわせて４日間(96時間)

保温モード
98℃
90℃
60℃
任意

その他の条件
保温中に水が無くならないよう、満水にしてから始める(上に同じ)(上に同じ)

シナリオ内で 夜間は水が無くならないよう満水
設定変更する にしてから放置する

交互にする

保温中に水が無くならないよう、満水にしてから始める

45

テストケースを作成し直す
環境対応＋連続稼働テスト•サポート内ではあるが何らかの影響を受けそうな環境下で、連続稼働に耐えられることを確認する※連続稼働することでポットに何らかの負荷がかかりそうな環境を選ぶ
稼働時間の定義(テスト可能な時間を設定)

環境
電圧

水質

130V

発泡性ポット洗浄液
塩水
ミルク
お茶

気圧と沸点 沸点が95℃の気圧

放置しておくものについては、６０時間とする
加熱が続く条件については夜間放置できないので8時間とする
複合操作・動作の場合は、4日間(96時間)とする

操作・動作の内容
稼働時間
沸騰から保温状態で放置 60時間

保温モード
98℃

その他の条
件
保温中に水
が無くなら
ないよう、
満水にして
から始める

満水からお湯がなくなるまで 98℃給湯し続ける
下記操作をランダムに繰 あわせて４日間(96時間)
シナリオ内で設定変更する
夜間は水がり返す（状態遷移になる
無くならな
べく偏りのないようにシ
いよう満水
にしてから
ナリオを作成する）
夜間は保温で放置
放置する
保温・沸騰
蓋の開け閉め給湯
モード変更
タイマー設定・稼働
沸騰から保温状態で放置 60時間
98℃
沸騰から保温状態で放置 60時間
98℃
60℃
沸騰から保温状態で放置 60時間(利用しそうなミルクモードで保温)
沸騰から保温状態で放置 60時間
98℃
98℃
沸騰から保温状態で放置 8時間(加熱行為を続けてしまう)46

思考過程のポイント• テストケースの目的、数値の意味などを想定する。
• 目的によって確認したいことが異なる。

– 「連続」と「環境」は組み合わせて考えた方がよいのでは– 「値」の持つ意味を考える。
• 通常、ぎりぎりセーフ、異常値で考え、補完する– 「条件」の持つ意味についても考える。

• 検討した結果に基づきテストケースを作成し直す。
• テストタイプは自分で作るもの。

– 組織の標準を適用するわけではない。
47

指摘２のケース

テスト管理者（レビューア）のお話

48テストケースから出てくる不明点、疑問点
60時間は動作確認にここでいう連続動作ってなんだろう？
連続で色々な操作/動作をさせること？
長時間動作のこと？

テスト目的は長いし、長時間動作には短いなあ。

テストケース(実際に行われるテスト）

連続動作
何が目的だろう？
水なしだと保温行
為は止まるはず。

満水で60時間90℃のまま±3度で保温
98℃は確認しな
いのかな？

水なしで60時間保温：

これらも環境テストでは？

±3度の温度制御を確認したい？

電源130Vで60時間

70Vは確認しないのかな？

低気圧下(高山)で60時間沸騰から90℃以下で保温
塩水、満水で60時間90℃のまま±3度で保温

環境テスト
200Vは確認しないのかな？

ミルクは確認しないのかな？

塩水を満水？

電源130V、70Vで動作…
高山(低気圧下)での使用…
理解性が低い高気圧下は確認しないのかな？

同じようなテストが散らばっているなあ。

十分性、網羅性が低い
俯瞰性が低い

49

テスト目的を整理する• テストケースからパラメータを抽出し、テスト目的を整理する。
テスト目的

テストケース(実際に行われるテスト）
動作時間

連続動作
水量

満水で60時間90℃のまま±3度で保温

温度制御

水なしで60時間保温
エラー

設定温度

：
電源130Vで60時間

水の種類

低気圧下(高山)で60時間沸騰から90℃以下で保温
塩水、満水で60時間90℃のまま±3度で保温
動作

環境テスト
電源130V、70Vで動作…
気圧(沸騰温度)

電圧

高山(低気圧下)での使用…
50

リファクタリングする• 抽出したテスト目的とパラメータからテストタイプを再設定し、足りないテスト条件を追加する。
• さらに、齟齬が出ないようにそれぞれのテストに対して説明を追加する。また、標準条件も定義する。
テストタイプ

テスト条件

説明

環境テスト
(水量)

なし、微量、推奨線以内、満水

水量により、適切に沸騰、保温ができたり、エラーが発生することを確認する。
水量がなくなったらエラーが発生すること。
満水でもこぼれないこと。

・・・

・・・

・・・

51

リファクタリング結果
標準条件

理解性UP
合目的性UP
テストタイプ

行為：沸騰、保温
保温温度：90℃
保温時間：8時間
水の種類：水
水量：推奨線以内
電圧：100V
気候：平地

テスト条件

標準のテスト条件を設定する。
保温時間は60時間ではなく、日中の想定使用時間の8時間
とする。

十分性UP
網羅性UP
説明

俯瞰性UP
理解性UP

環境テスト
(水量)

なし、微量、推奨線以内、満水

水量により、適切に沸騰、保温ができたり、エラーが発生することを確認する。
水量がなくなったらエラーが発生すること。
満水でもこぼれないこと。

環境テスト(水の種類)

水、ミルク、塩水

水、ミルク以外を使用されてしまった時に、温度異常、火災、爆発などが発生しないことを確認する。

環境テスト
(気圧)

平地、低気圧環境、(高気
圧環境)

使用される気候に関わらず、沸騰・保温ができることを確認
する。

環境テスト
(電圧)

100V、130V、200V

様々な電圧 (日本、海外)で使用できることを確認する。
温度異常、火災、爆発などが発生しないことを確認する。

ランニングテスト

15時間、1週間

長時間ランニングさせて、動作することを確認する。
保温時間は夜間の電源消し忘れを想定した15時間と1週間
とする。

連続テスト

単機能/複数の連続操作

ボタンの連続押しなど同じ機能や複数の機能を連続で操作する。
52

リファクタリングの効果• テストタイプの整理、再設定→

理解性、合目的性UP• テスト条件の整理、追加→

十分性、網羅性UP• 各テストにテスト目的、説明を追加
→

理解性UP

• 全体整理
→

俯瞰性UP

53

思考過程のポイント• 最初は、ざっくり見る。あまり細かくは見ない。
• 注目するキーワードを見つけ、意味を考える。
• 足りないテスト条件を追加し、テストタイプを再設定し、並べ直す。
• さらに説明を追加する

54

もう少し考えてみるパネリストの指摘• テスト管理者の例について– テスト条件に値が入っている。
– テストタイプの（）内｛例えば(水の種類)｝がテスト目的になっている。
– ひとつのテストタイプの中に異常系、正常系が混じっている(二つに分かれる)。

56

パネリストの指摘• 用語について– テスト担当者とテスト管理者とで、テストタイプ、
テスト条件の用語が指す内容に違いがある。
– 担当者の定義• テスト条件 ：テストケースに落とすまでの確認したい事• テストタイプ ：同じ目的を持ったものの集まり– 管理者の定義• テストタイプ ：テストの目的を分類したもの• テスト条件 ：水準、因子57

パネリストの指摘• 用語について– 副次的な塊をサブ目的でまとめているケースもある。
– 何でもかんでもテストタイプに押し込める雰囲気がよくない– 確認したい事→テストタイプ– 振る舞い→テストタイプとは呼びたくない58

パネリストの指摘• テスト設計には順方向・逆方向の違いがある。
– 順方向• 条件(入力)を考えて、期待結果を確認する。

– 逆方向• こんなことは起きてほしくない（結果）を先に置いて、そうなるようにテストを設計する。

• 順・逆の組合せが必要だが、多くの人は片方やると満足してしまう。
• 順・逆ごちゃごちゃになってしまいがち59

パネリストの指摘• テストケースをリバースエンジニアリングすることによって、テスト観点のモデルのリファク
タリングをしていることになる60

パネリストの指摘• テスト観点図のスタイル(CIBF)– C：条件・入力– Ｉ：テスト対象(機能、状態、イベント、構成要素、周辺機器、サブシステム、シーケンス図)– Ｂ：振る舞い(性能、セキュリティ、障害対応性)– Ｆ：どんなバグを見つけたいか(バッファオーバフ
ロー)• 副次的な塊をサブ目的でまとめているケースも
ある。
61

まとめ

本日のおさらい• テストケースの意味、ちゃんと考えてましたか？

– 目的を明確にしてテストケースを作りましょう– 「なんとなく」作られたテストケースにも目的が潜んでいます。リファクタリングすることで明確にすることができます– リファクタリングしたものをレビューすることで、さらにどのようなテスト設計をしようとしているのか、再整理できます– テスト対象が同じでも、テストの品質特性によってテス
トレベルやテストタイプは大きく変わるかもしれません
まずは自分のテストケースをリバースするところから始めてみましょう63おまけ：智美塾へのお誘い

64

智美塾訓
1. 塾生はテスト開発方法論を目指し、自ら技術獲得に励む事
2. 塾生は現場を尊び、地に足の着いた技術論を行う事
3. 塾生は品質向上という最終目的を常に意識した活動を行う事

智美塾の目的• 参加者それぞれが“テスト開発方法論”を 構築すべく研鑽を重ねる。
• すなわち、“テスト開発方法論”の上位にあるメタな何かを探り理解することによって、自分なりに“テスト開発方法論”を理解し、より良く作りあげたり選択していくこと ができると思われる。
• 以上について、参加者全員による議論 や共通理解、同意65を重ねて進めていく。 決して一方通行の講釈ではない。

来たれ！智美塾へ
・月一回程度、夜間に開催する(東京地区)。
・参加案内はTEF(テスト技術者交流会ML)
およびASTER Webへ提示
・参加希望者は参加案内に記載される参加要件(智美塾への参加動機、あるいはその回のお題について四百字以上で記述すること、など)をよく読み、応募すること。
・他に参加資格としての要件はない。
腕に覚えのある者なら誰でも応募可能である。
・参加メールを塾長などで審議し、資格ありと認められた猛者のみ参加を許される。
66

ご清聴ありがとうございました

67