2014/9/5

How do you like software test?
正式名称：TEF北海道ソフトウェアテスト勉強会（Testing Engineer’s Forum HOKKAIDO）

テストのスパイス教えます～ちょっとした手間で変わる仕上がり～

2006年ごろ発⾜。
テストをメインにソフトウェアの品質に関わること全般の勉強。
• オンラインで議論– テスト設計技法の勉強したり、要求分析を勉強したり、最近の話題はレビュー• 不定期で勉強会開催

Powered by TEF-Do– ほぼすべて⼿弁当で対応。会費は無料。

• 他地域勉強会連携– 関⻄からゲストが来たり、東海でSIGしたり参加メンバーは10名程度で、常時5〜6名のメンバーが参加。
メンバは常に募集中。
1

http://ameblo.jp/tef-do/tefdoblog@gmail.com

2

こんなことになっていないですか？

こんな感じでテストを作ってませんか？

• 後からバグが出て、テストが漏れていたと後悔したことはありませんか？
• テストケースを書いていて不⾜していないか不安になったことはありませんか？
• コピペでテストを作ってるけど、これでいいのか悩んでいる

1. 機能仕様書を準備
2. テストケース仕様書のテンプレートを準備
3. 機能仕様書から「機能」部分をコピー例）対象機能「ボタンAを押下するとトップ画面が表示される」
4. テストケース仕様書に張り付け、語尾を「〜すること」に変更する。
例）テストケース「ボタンAを押下するとトップ画面が表示されること」

TEF道よりあまり工数を使わずに効果的なテストが実施できる方法をご紹介します3

これを「Copy&Paste&Modify法（CPM法）」と呼ぶ人もいるらしい・・・

4

こんな状況があったとします• 皆さんはソフト開発のチームに所属しています。
• あるソフトの「一部の機能」に対するシステムテストを⾏おうとしています。
• このテストで⾏うテストケースの作成に新人君をアサインしました。

どこかでみたことがあるような…

何かが足りないテストケース

5© 2014 TEF道61

2014/9/5

あるソフト＝テストベース「かんばんりすと」

今回テスト対象機能テスト対象「かんばんりすと」って？
• 小玉 直樹 氏 作のWeb上で使える ToDoリストアプリです。
• タッチ対応ですのでスマートフォンやタブレッド等でもご利用いただけます。

http://kanban-list.herokuapp.com/• TOP画面• サインアップ• ログイン• タスクの一覧表示• タスクの登録• タスクの更新（内容）• タスクの更新（状態）• タスクの削除
7

大項目

中項目

小項目

テスト内容
URLからユーザー登録ボタン
1 TOP画面 ユーザー登録ボタン 押下押下でユーザー登録画面に遷移できる
URLからログインボタン押下で2ログインボタン押下
ログイン画面に遷移できる
3サインアップ Name
⼊⼒
Nameが⼊⼒できるEmailに英数字が⼊⼒でき
4
Email英数字⼊⼒
る

10分

要求仕様書」ご覧ください8

15分

実際のアプリを動かしてみてもOKです！！

10

どうでしたか？
• ほぼ仕様書からのコピペでしたよね？
• ⾜りないテストがありましたよね？
• たとえば、こんな指摘が出ませんでしたか？

グループでレビュー結果を共有してください。
• どんなテストケースが必要か？
• 質の高いテストケースって何だろう？
• このテストケースの作り方において、考えが⾜りていない事はなんだろう？

– 数値項目の境界値のバリエーションが不⾜している– ⼊⼒可能項目が列挙されている機能の、⼊⼒内容が不明– テスト実施不可or実施方法が不明なテストが存在している– 対応ブラウザやセキュリティなどの非機能部分の考慮がされていない– 異常系はテストしなくて良いのか？

11© 2014 TEF道タスクのFilter機能
Book（カテゴリ）の操作
レイアウトの変更
dashboard
ユーザー情報の変更
ログアウト
付加機能詳細ポモドーロタイマー
Done List一覧表示
タスク一覧のEmail送信
背景イメージの変更
自動ロードのON/OFFの切り替え

このテストケースのレビューをしてください。
下記の観点でレビューしてください。
• システムテストとして、テスト内容は十分⾜りているか？不⾜していないか？
• テストケースの品質として問題が無いか？（テスト実施やレビューのしやすさなどを含めて）

結果

9ワーク①b（グループワーク）

対象機能の使用については「資料①••••••••••••

ワーク①a（個人ワーク）

新人君からこんなテストケースがでてきたNo

テスト対象外1222014/9/5

テストケースの比較
新人君のダメな点をもっと明確にするために、ベテランさんのテストの作り方を⾒てみましょう。

理想的なテストってなんだろう？

網羅的で抜けの少ないテストケース

13

14

玄人さんの分析
ユーザ分析してユーザゴールを考える

玄人さんのテストを導く過程
新人君
実装

IT企業の開発関連者

テストケース

代表的なユーザー像• 3０〜４０代• 業務の改善を⽇ごろから考えており、その推進に対してもある程度の影響⼒をもつ。
• 客先やオフショア先で作業を⾏う事が多いので、外出先やスマートフォンで⾃分のタスク管理を⾏う必要性を感じている。

機能仕様

分析

設計

実装

テストケース

ユーザーゴール

ベテラン流

玄人さんの分析
ユーザゴールから保証すべき品質を導く
品質特性（抜粋）• ユーザーゴール

機能正確性

機能適切性
システム／ソフトウェア製品の機能が、定められたタスクや目的を円滑に実施する度合

システム／ソフトウェア製品の機能が、必要な精度で正確な結果を与える度合

システム／ソフト
ウェア製品の機能が、ユーザの目的や定められたタスクに対応している度合

ユーザー要求（満足性）– WEB上でプロジェクトに関するTODOや備忘録を管理することで、作業環境に依存せずにプロジェクトに関する情報を把握できる。

製品やシステムが定められた利用状況下において、決められたニーズを実現する機能を提供する度合
機能完全性

ユーザーゴール

16

玄人さんの分析結果 -1

機能適合性

ゴールの要素分解• ユーザー要求（満⾜性）
重要機能仕様書に記載
代表的ユーザーの されている機能が、ユーザーゴールのプロジェクトに関するTODOなどのタスクを、 利用状況を、全てカ 入力される事が予目的が達成できるいつでもどこでも把握したい。
バーできる機能が 想できる条件に対システムである事。
揃っていること。
して、正確に動作する事。
WEB上でプロジェクトに関するTODOや備忘録 アプリケーションのインストールには社内手を管理することで、作業環境に依存せずにプ 続きが必要なため、特別なプラットフォームやアプリインストールを不要としたいロジェクトに関する情報を把握できる。
思いついたタスクをすぐに登録したいので、起動や操作を迅速に行いたい
社内情報を扱うので、機密情報を漏らさない仕組みが必要© 2014 TEF道

テストの最終目的

WEB上でプロジェクトに関するTODOや備忘録を管理することで、作業環境に依存せずにプロジェクトに関するタスク情報を把握できる。

15

テストの最終目的

想定ユーザー像重要– プロジェクトに関するTODOなどのタスクを、いつでもどこでも把握したい。
– アプリケーションのインストールには⼿続きが必要なため、特別なプラットフォームやアプリインストールを不要としたい– 思いついたタスクをすぐに登録したいので、起動や操作を迅速に⾏いたい– 社内情報を扱うので、機密情報を漏らさない仕組みが必要

ユーザー要求に対して、システム側で考慮する必要がある要素
17

183

2014/9/5

設計
システム要求からテストタイプを導出

玄人さんの分析結果 -2• システム要求（重要箇所抜粋）– アプリケーションのインストールには⼿続きが必要なため、特別なプラットフォームやアプリインストールを不要としたい

テストタイプ（システム要求に対して、「テスト」で確備考認しないといけない汎用的な内容）

システム要求代表的ユーザーの利用状況（複数拠点でのプロジェクト運用）を、全て利用シナリオ確認テストカバーできる機能が揃っていること。

ココを導出する

テストカテゴリ（テストタイプを、対象製品ごとに具体化＆選別したもの）

要求仕様をベースとしたテストを実施し、仕様が不正に実装された個所を検出するテストを実施する。
利用シナリオ確認• OSの種類を問わず、インターネット網と標準的なブラウザがあれば、使用することができるシナリオ（正常）シナリオ（異常～復帰）
操作（マウス）

入力– 社内情報を扱うので、機密情報を漏らさない仕組みが必要• ⾃分のみが情報を閲覧・編集できる• 内容は、⾃分以外に漏れてはいけない

入力内容（入力内容（桁）
入力内容（データ型）

機能仕様書に記載されている機能が、入力される事が予想できる条 機能テスト
件に対して、正確に動作する事。

機能仕様書をベースとした試験を実施し、仕様との相違を検出するテストを行う
処理処理条件
データ格納
画面表示

出力
エラー処理
ユーザーゴール（複数拠点でのプ要求仕様をベースとしたテストを実施し、ロジェクト運用）の目的が達成でき 利用シナリオ確認テスト
仕様が不正に実装された個所を検出するるシステムである事。
テストを実施する。
シナリオ試験（同上）OSの種類を問わず、インターネットOS及びブラウザの種類によらず使用する網と標準的なブラウザがあれば、 外部環境互換性試験（OS／ブラウザ）ことができることを確認するテストを実施使用することができるする。
OS＆ブラウザの組合せ＆ブラウザの組合せ

19

Test
テスト対象機能No.

出力
システムの弱点観 点

非ログイン者の閲覧

インジェクション
SQL
入力

仕様が想定しない入力値（桁・型）の入力仕様が想定しない操作の実
施各情報からのシステムの弱点に着目したテスト

非ログイン状態で情報が引き出せないか確認

文の入力ができない／対SQL
処されている

クロスサイトスクリプ HTML
タグなどの入力ができない／対処されている
ティング入力異常系 （操作 ）イベントと状態の遷移に着目異常系 （入力 ）とブラウザの組み合わせOS
で、一通りの動作確認

操作部分の週特性を、実ユーザーに近いメンバにて評価

エラー判定と、メッセー ジと、エラー後 の動作状態遷移

エラー処理＆ブラウザの組合
OS

想定ユーザーに実際に利用してもらう

せデータ格納の確認

画面表示の正当性に着目

条件による処理分岐など

画面表示

入力型の考慮（バイト数 、文字種

データ格納

処理条件

マウス操作のバリエーション）
入力桁数の考慮（ 、最大値、最大値以上）
0

入力内容（データ型）

操作（マウス）

Test No.
要求 No.

入力内容（桁）シナリオ（正常）利用シナリオ確認 入力
テスト

テストカテゴリ

シナリオ（異常～ 想定外の異常状況からの復帰シナリオ復帰）

機能一覧を整理した
もの

処理

設計
マトリクスにしてテストすべき内容を確認

テスト対象機能
WEBアプリの紹介ページを用意する。

1

TOPページの表示仕様

2015○のついた箇所を詳細化してテストケースに落とす・・・
テストカテゴ
テスト実施項目
リ

ユーザー名、Email、パスワード、パスワード確認
画面表示の入力欄と、サインインボタンを表示する。

入力欄の仕様
ユーザー名のテキストボックスの仕様は以下のと16 おり。
画面表示・ラベル名：Name○

機能に対して、テストすべき内容の決定○

ユーザー名のテキストボックスのラベル名を確認する
ユーザー名のテキストボックスが入力必須であ 入力/未入力
ることを確認する
ユーザー名のテキストボックスの入力桁数を確 境界値
認する

ユーザー名、Email、パスワード、パスワード確認の入力欄と、サインインボタンを表示すること

Nameであること入力必須であること処理条件

・入力桁数：30文字まで

入力内容
（桁）

・入力書式：（制限なし）

半角/全角、英数、ユーザー名のテキスト かな、カナ、記号
入力内容
制限なしであるこボックスの入力書式を確 （@ ! # $ % & ' * + （データ型）と/=?^_`{|}~.そ認するれ以外)○

http://kanbanlistfortohokutest.herokuapp.com/○
TOPページのURLにアクセスすると、以下の9TOPページを表示する。
○
ユーザー登録ボタンをクリックすると、サイン10アップページを表示する。
○
ログインボタンをクリックすると、ログイン11ページを表示する。
○
ページ上部のタイトルは全画面で共通の12 ヘッダーで、クリックするとこの画面を表示する。
○

各コントロールを表示することを確認する

期待値

・必須

○

TOPページのURLは以下とする。
8

入力条件

30文字であること

○2122

○

このような⼿順を踏むとCPM＋αとの違いは？

• テスト分析〜テスト設計のプロセスを踏むことで、「テストすべき内容を明確」にして、関係者と合意を⾏える• 仕様に記載していない事項（記載漏れ、非機能、異常系）のテストを、利用者観点から導出できる• 機能間の組合せや状態遷移などを考慮に⼊れれる• テストの漏れを防ぎやすくなる• レビューがしやすくなる• マトリクスを利用して、CPM+αのテストケースがどんなこと、どんな品質を確認できているかを調べてみましょう• きっとCPM＋αの守備範囲が⾒えてくるはず23

24© 2014 TEF道4

2014/9/5

15
ワーク②a（個人ワーク＆グループワーク） 分

15
ワーク②a（個人ワーク＆グループワーク） 分

CPM＋αの「テストケース仕様書（資料②）」のテストを「テストケース分析シート（資料③）に当てはめてください。
• テストケースの「テスト対象機能」毎に、「どんなテストが実施されているか」を分析します• マトリクスの縦軸は「機能」です。テストケースの「テスト対象機能」と（ほぼ）一致しています。
• 横軸のテストカテゴリをヒントに、テストケースから「テストの目的」を読み取ります• 一致する箇所に○をつけていきます• レビュー指摘で導いたテストケースについては×をつけます

CPM＋αの「テストケース仕様書（資料②）」のテストを「テストケース分析シート（資料③）に当てはめてください。
• テストケースの「テスト対象機能」毎に、「どんなテストが実施されているか」を分析します• マトリクスの縦軸は「機能」です。テストケースの「テスト対象機能」と（ほぼ）一致しています。
• 横軸のテストカテゴリをヒントに、テストケースから「テストの目的」を読み取ります• 一致する箇所に○をつけていきます• レビュー指摘で導いたテストケースについては×をつけます25

26

どうでしたでしょうか？

CPMの特徴• 良いところ

CPM＋αでは・・・・• 機能テスト…それも目に⾒える部分に偏っていませんか？
• 非機能部分やセキュリティの考慮は出来ていないですよね？
• 異常系や環境などの考慮も…
• そもそも、仕様に書いていない内容は一切考慮できていない…

– 早い– 簡単

• 悪いところ

分析、設計を⾏って導いた確認すべき項目とCPM＋αの項目を比較してみてください。
違いがあった場合、その違いはCPMやレビューから導くことはできるでしょうか？グループ内で議論してみましょう。
27（少なくともCPMよりは）理想的なプロセスの特徴

28

ちゃんとテストプロセスをやらないといけないのはわかっているが・・・• 良いところ– 機能仕様だけではなく、利用者観点からの分析が⾏える– 中間成果物を明確にしているので、プロセス単位での内容合意が可能– 全体を俯瞰できるので、レビューが容易– 抜け漏れを防⽌しやすい• 悪いところ– 時間がかかる– ある程度の技術が必要
29© 2014 TEF道– 書いていない事はテストできない– 機能組合せや状態遷移などの、機能間の連携の漏れが生じる– 非機能やセキュリティや異常系が漏れやすい– レビューがしづらい• 理想的には横軸（＝ヒントワード）にあたる部
分を導くプロセスが必要です。
• でも、そこまでできない、何やって良いかわからない、ということがあると思われ、結局CPMにもどる…。
• そんな風にならないための最初の一歩的に、比較的汎用的に使えるヒントワードをご紹介します。

30

52014/9/5• それはあたる

ヒントワード・例（書籍『事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント』より）• 非機能カテゴリ– 排他／同期／容量／メモリ量／タイミング・・・・など• 意地悪漢字– 「再」「特」「略」「誤」・・・など（http://www.jasst.jp/archives/jasst10s/pdf/S3-9.pdf）• エラー推測– 出やすいバグを推測する（メモリリーク／競合／繰り返し／・・・・など色々）

少しでも理想に近づきたい• HAZOPのガイドワード– 化学プロセスにおける危険シナリオ分析⼿法をソフトウェアに応用一歩進んだテストケース• 品質特性の応用（ISO/IEC 25010 http://kikakurui.com/x25/X25010-2013-01.html）• TEF道作成の「ぶっちゃけ品質特性」– 魅⼒性⇒「かっこいい、かわいい」– 環境適応性⇒「いろんなところで使える」

・・・など、ぶっちゃける

31

一例として「それはあたる」の紹介「それはあたるの」例題

⻄暦⇒和暦の変換WEBプログラム

コーナーケースの⼊⼒値を探す方法。
コーナーケースの⼊⼒値を探す方法。

そ（外側）：テスト対象から外や補集合を探す⑤①れ（例示）：怪しい部分の例示を考える②あ（間） ：例示したデータの間を考えるれ（例示）：怪しい部分の例示を考える①③た（対称） ：例示したデータに軸⾜を置いて、は（破壊）：テスト対象が破壊する場合を探す⑥
参考書籍

あ（間）

＜仕様＞
西暦部に「西暦での年」と「月」を入力し、「変換」ボタンを押下すると和暦部に対応した「年号」と「和暦での年」が表示される。

もう⽚方の⾜の降ろし場所を探す：例示したデータの間を考える②④る（類推） ：例示から離れてテスト対象を眺める
た（対称） ：例示したデータに軸⾜を置いて、⑤そ（外側） ：テスト対象から外や補集合を探す
もう⽚方の⾜の降ろし場所を探す③⑥は（破壊）：テスト対象が破壊する場合を探す

る（類推）：例示から離れてテスト対象を眺める④※○付き数字は考える順番を表している
33

ワーク③20分（個人ワーク→グループワーク）• 「それはあたる」を使って、CPMでは導出できにくいテストの視点を考えてみましょう①仕様の「怪しい個所」にチェック（できれば色つきボールペンで）して、怪しい内容をメモしてください。
＜例＞
・「西暦での年」⇒入力範囲は？入力内容のチェックは？
・「月」⇒入力範囲は？入力内容のチェックは？」・「日」は無くて良いのか？（月途中で年号が切り替わる場合は？）・「和暦」⇒元号は、どこまでが対象なのか？明治から？それ以前は？
・「変換ボタン」は、マウスのみ？キーボード対応している？

34

どうでしょうか？
• CPM＋αで導かれなかったテストの視点がでてきませんか？

– 演習① データの⼊⼒に関して（要求３）– 演習② 操作に関して（要求７）– このヒントワードを使うと、主に異常系の視点が（強制的に）得られると思います35© 2014 TEF道

32

36

6

2014/9/5

まとめ（スパイスとは？）• はじめの一歩として、汎用的なヒントワードをつかう一⼿間で、CPM＋αのαが強化されるでしょう↑一味変える「スパイス」を、まずはお試しあれ• ただし、同じことをやりつづけると一⼿間の効果がなくなります。（殺虫剤のパラドックス）• 理想的な方法で導いた横軸のように、テーラーリングして育てることは将来的に必要です。
↑「秘伝のスパイス」を作り上げてください

理想を求めて本ワークで伝えきれていない事

37

38

横軸について縦軸について横軸の｢テストカテゴリ＝ヒントワード｣は、対象製品や組織で変わります。実はこれを大事に育てることが大切です。
【育て方の例】• 担当者のノウハウや暗黙知を盛り込む• プロジェクトの過去のデータの集計結果を盛り込む• 出荷後の不具合などの是正内容をフィードバックして盛り込む• 上記は、いったん抽象化して盛り込む

今回の縦軸は、異なるモデリングのうちの一部にすぎません。本来であれば、縦軸は対象システム分析を⾏い、再構築が必要なのです。
【モデリングの例】• 機能モデル
利用者から⾒たシステムの機能を表すモデル• 静的モデル
問題領域やシステムの静的構造を表すモデル• 動的モデル振る舞いを表すモデル
3940

参照文献
• ソフトウェア・テストPRESS Vol.10– 「今こそ聞きたい テストの上流設計」（湯本 剛氏）How do you like software test?

• 事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント（秋山 浩一氏）

ありがとうございました！
41© 2014 TEF道427