20181102_テスト管理を語る夕べ

Copyright 2018 Kazuhiro SUZUKI
ソフトウェア開発者のための
テスト管理を語る夕べ
第1回: テストケースの構造について
2018年11月2日(金)
鈴木一裕 @kz_suzuki

2
/ 54Copyright 2018 Kazuhiro SUZUKI
⚫ 『システムテスト自動化標準ガイド』監訳・翻訳 @ 翔泳社
⚫ 『1時間で分かるSTA』発表 @ テスト自動化カンファレンス2014
⚫ 『テストを自動化するスクリプティング…』寄稿 @ Codezine
⚫ 『ギアと開発とわたし』発表 @ 第一回AsiyanAutomationAlliance
⚫ 『探索的テストのモデルとFAQ』発表 @ JaSST'16 Tokyo
⚫ ブログ: 『ソフトウェアの品質を学びまくる2.0』
⚫ Twitter: kz_suzuki ※所属組織とは云々
鈴木一裕 (すずきかずひろ)
ソフトウェアのテスト・品質界隈で、
地味にコミュニティ参加しています。
会社に怒られない程度に
情報発信しています。
品質屋さん、組込みソフトウェアの自動化など。

「テスト管理を語る」
と聞いて、
何を思い浮かべましたか？

4
かっこいいマネジャーの
話はでてきません。

5
「テスト」で「管理」するものってなんだろう。
◼ 「4つの経営資源」で考えてみる。
ヒトモノカネ情報
⚫ 工数
⚫ スキル
⚫ コミュニケーション
⚫ ・・・
⚫ テスト環境
⚫ ハードウェア
⚫ ソフトウェア
⚫ ネットワーク
⚫ テストツール
⚫ ハードウェア
⚫ ソフトウェア
⚫ ライセンス
⚫ シミュレータ
⚫ ・・・
⚫ 人月単価！
⚫ インフラ利用料
⚫ Earned Value
⚫ ・・・
⚫ テストに関する
情報
⚫ テストベース
⚫ テストケース
⚫ テスト手順
⚫ テスト実行状況
⚫ インシデント
⚫ ブロッキングバグ
⚫ ・・・
テストマネジャー！って感じのやつ
ただし、情報があるからこそマネジメントができる。
地味なやつ

6
JSTQBで定義されたテストプロセス
(*1) I/JSTQBではこの他、テストの「モニタリングおよびコントロール」
「終了基準の評価とレポート」「テスト終了作業」というプロセスが定義されている。
テスト
実装
テスト
実行
テスト
設計
テスト
分析
テスト
計画
テストの目的を定義し、そのテストの使命や
目的に合致するようテストの仕様を決めること
「何を」テストするかをテスト条件の形式で定義
する活動。テスト条件は、テストベース、テスト
目的(…)を分析することにより、識別可能
何かを「どのように」テストするかを定義する
活動。(…) テスト技法を使用して、 (…) テスト
ケースの識別を行う。
テスト設計を具体的なテストケース、テスト手順、
およびテストデータとして実装する活動である。
テスト対象のコンポーネントやシステムでテスト
を実行し、実行結果を出力するプロセス。
⚫ テスト要求仕様
⚫ テストアーキ
⚫ テスト設計仕様
⚫ テストケース
⚫ テスト手順
⚫ テストデータ
⚫ テストスイート
⚫ 実行結果
⚫ インシデント
⚫ 進捗状況
⚫ テスト計画書
テストウェアの情報
テスト実行の情報
テスト
管理を
語る夕べ
テスト戦略を…
HAYST法を… テスト要求分析を… テスト観点を…
原因結果グラフを…
の、第1回

7
まちがいさがし
◼ 以下のテストケース管理は何が渋いなのか。
⚫ テストケースの網羅性が
◼ 今回は「情報」と「構造」に注目する。
⚫ 「ログイン」が大にも中にも出てくるんだけど、どういう切り口で「分類」
しているんだ・・・？品質特性9126的なのも見えるが・・・。
⚫ #1は2回やったから2回分の記録があるけれど、集計できないぞ・・・。
というかどのバージョンで実行したんだよ・・・。
⚫ 手順の書き方が人によって違う、期待結果もいい加減すぎる・・・。
⚫ ログインのユーザ種別って「会員」と「非会員」で網羅できてるの？
# 大分類中分類小分類手順期待結果実施者実施日結果
1 機能性正確性配送料計算
無料になるケース
配送料を計
算する
仕様どおりであること鈴木 10/8
10/9
NG
OK
2 機能性正確性配送料計算
無料にならないケース
「確認」画面
に遷移し・・・
配送料が正しく計算
されていること。
佐藤 10/8 OK
3 ログイン会員－
4 ログイン非会員－
5 性能ログイン 40ユーザ同時ログイン

今回の
ゴール
テストケース管理の
データ構造について、
議論の土台を作る

書記、よろしくお願いします。

用語の確認
用語に拘泥したくないけれど、
前提を揃えるためにやっておく。

11
用語の確認: テストケース周り (1)
◼ テストケース (test case)
⚫ 『入力値、実行事前条件、期待結果、そして、実行事後条件の
セットで(略)特定の目的又はテスト条件のために開発されたもの』 (*1)
⚫ 手順はテストケースの必須要素ではない。
◼ 粒度での分類
⚫ 具体的テストケース (concrete test case)
- 『入力データと期待結果が具体的なテストケース。高位レベルのテストケース
からの論理演算子は、論理演算子に相当する実際の値に置き換えられる』
- = 低位レベルテストケース (low level test case)
⚫ 抽象的テストケース (abstract test case)
- 『具体的な入力値や予測結果を使わないテストケース。論理演算子は使用す
るが、値のインスタンスは未定義や使用不可であるといった状態にある』
- = 高位レベルテストケース (high level test case)
- = 論理的テストケース (logical test case)
(*1) この節でカッコで囲んでいるものは、JSTQB用語集からの引用。

12
◼ テスト手順仕様 (test procedure specification)
⚫ 『テストの実行のために、一連の手順を定めたドキュメント。
テストスクリプト、又は、手動テストスクリプトとしても知られる』
◼ テスト設計仕様 (test design specification)
⚫ 『テストアイテムのテスト条件（カバレッジアイテム）、詳細なテスト
アプローチ、及び、関連する高位レベルテストケースを記述した
ドキュメント』
⚫ 「テストアイテムのテスト条件」！？
⚫ （具体的）テストケースの源泉となるもの。
◼ テスト仕様書 (test specification)
⚫ 『テスト設計仕様、テストケース仕様、テスト手順仕様からなる
ドキュメント』
⚫ テストウェアの一部と考えてよさそう。
⚫ 今回議論したいのは、この辺のエンティティ。

13
◼ テストスイート (test suite)
⚫ 『テスト対象のコンポーネント又はシステムのためのいくつかのテスト
ケースのセット。一つのテストの実行事後条件は、次のテストの実行
事前条件としてよく利用される』
⚫ ＝テストセット (test set)
⚫ 1つ以上のテストケースを、目的に応じてひとまとまりにしたもの。
◼ テストチャータ (test charter)
⚫ 『テスト目的を明記したもの。テスト実施法のアイデアを含む場合も
ある。探索的テストにて使用する』
⚫ 今回、深入りは避けよう。

14
◼ テストベース (test basis)
⚫ 『コンポーネント要件やシステム要件を推測できる全てのドキュメント。
これらのドキュメントがテストケースのベースとなる』
◼ テストウェア (testware)
⚫ 『テストプロセスを通じて作成される、テストの計画、設計、実行に
不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、
セットアップとクリーンアップの処理手順、ファイル、データベース、環境、
その他、テストで使用する付加的なソフトウェアやユーティリティなど』
◼ ざっくりと、ベースがINで、ウェアがOUTですかね(*1)。
(*1) ただし既存ツールなどもウェアに含まれるので、必ずしもOUTされるわけではない。

15
用語の確認: ややこしいヤツら
◼ テスト対象 (test object)
⚫ 『テストすべきコンポーネント又はシステム』
⚫ 何をテストするのか。
◼ テスト目的 (test objective)
⚫ 『テストを設計、実行する理由や目的』
⚫ 何のためにテストするのか。
◼ テストタイプ、テストレベル、テストフェーズ、・・・
今回の話にはあまり関係ない、忘れよう。
テストケースとテスト条件の違いについて

16
用語の確認: もっとややこしいヤツら
◼ テストアイテム (test item)
⚫ 『テストを実施する個々の要素。通常、一つのテスト対象に対し、
多数のテストアイテムがある』
⚫ テスト条件と区別できないが、あまり聞かない言葉なので忘れよう。
◼ テスト条件 (test condition)
⚫ 『コンポーネントやシステムのアイテムやイベントで、テストケースにより
検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質
特性、構造要素など』(*1)
⚫ テスト対象のうち、検証したい部分・側面というMy解釈。
◼ テスト観点 (test viewpoint)(*2)
⚫ テスト条件に対する狙い所というMy解釈。
⚫ テスト条件と明確な区切りはなく、重なり合うのでは。テスト観点は
何でも包括してしまう印象。
(*1)テストケースの事前条件とは違うので注意。
(*2) I/JSTQBでは定義されていない！

秋山さん、いつですか
そのFB某グループできるの！？

具体的なテストケースで
考えてみる。

19
『ソフトウェアテスト技法ドリル』より例題
◼ プログラムの仕様
「品物が書籍」で、「合計1,500円以上」で、「配送先が離島以外」なら、
配送料を無料とする。
◼ テスト対象: オンラインショッピングシステム
◼ テストアイテム: 配送料計算機能
◼ テスト条件の例
⚫ 送料計算が仕様通りに正しく行われること。
⚫ 送料計算に要する時間が性能要求を満たすこと。
◼ テスト観点の例
⚫ 送料計算は境界値でも大丈夫か。
⚫ 全部が書籍の場合、全部が書籍以外の場合と、混在の場合は？
⚫ このシステムでは、雑誌って「書籍」に入るの？

20
『ソフトウェアテスト技法ドリル』より例題
◼ 抽象的テストケース: 決定表で網羅しよう。
◼ 具体的テストケース
⚫ 事前条件: サイトにログインし、購入可能状態になっていること。
⚫ 入力値と期待結果
- ＃1: 2,000円の書籍を北海道札幌市に配送する場合、送料が0円。
- ＃8: 200円のティッシュを佐渡ヶ島に配送する場合、送料が500円。
⚫ 事後条件: カートに商品が入ったままであること、・・・。
◼ テスト手順
1. 商品一覧で書籍Aを選択し、カートに入れる・・・
1 2 3 4 5 6 7 8
条件1 品物は書籍 Y Y Y Y N N N N
条件2 1,500円以上 Y Y N N Y Y N N
条件3 配送先離島以外 Y N Y N Y N Y N
動作送料無料 Y N N N N N N N

この時点でもういったん
議論を始めたい方？

22
前置きのまとめ
◼ 今回の議論に残したいエンティティ
⚫ テスト仕様
- テスト設計仕様 ← これはおおむね終わっている前提
- テストケース仕様
- テスト手順仕様
⚫ テスト観点
⚫ テストセット（=テストスイート）
⚫ テスト実行結果
◼ 今回議論したいポイント
テストケースの
⚫ 各エンティティにはどのような情報を持たせるといいのか。
⚫ 各エンティティはどのように分割するのがいいのか。
⚫ エンティティ同士はどのように関連付けるといいのか。

本論の準備が整いました。
あと何分あるの？

24
テストケース周りのエセE-R図
① テスト要求分析、テストアーキ設計といったアク
ティビティから、テスト設計仕様が導かれる。
② テスト設計仕様から、テストケースが導かれる。
③ テストケースは複数のバージョンで構成される。
④ テストケースの手順は、複数のキーワードの羅列
で表現される。
⑤ キーワードは、具体的な操作が別に定義される。
⑥ テストケースの入力値や期待結果はパラメタライ
ズされ、データセットとして別に保持する。
⑦ テスト工程で行うテストをまとめてテストセットとす
る。
⑧ テストケースは複数回実行される前提で、それぞ
れに結果を持つ。
⑨ 実行結果に対し、0個以上のインシデントがある。
(*1) 最初は、テストケースの上流は「テスト観点」しており、観点とテストケースは多対多としていたけれど、現時
点では「設計仕様」をおいている。「1つのテストケースが複数の観点を持つことを許容するか」というにしさんの質
問に回答できていない。
テストケース
(バージョン
個別部)
テストケース
(共通部)
いわゆる
テスト
ケース
テスト実行
結果
テスト設計
仕様(*1)
テストセット
キーワード
テスト工程テストケース
操作
テスト開発の
上流成果物
テスト分析・
設計
テスト実装
テスト実行インシデント
データ駆動用
データ
①
②
③ ④ ⑤
⑥
⑦ ⑧ ⑨
⑦
エンティティ
リレーションシップ

26
エンティティが持つ情報の役割
情報にはいろいろ役割がありそうなので、分類してみた。
非MECE。
⚫ 基本情報: そのエンティティが本質的に必要とする情報。
- テストケースでは「期待結果」が基本情報に相当する。
- 「期待結果のないテストケースを見たことがあるのですが・・・」
→「みんなの心の中にある」
⚫ 識別用情報: そのエンティティを識別するために使う情報。
- 「○○ID」というものが多い。
⚫ トレース用情報: 別のエンティティと関連付けるための情報。
- たとえば、あるテストケースの源泉となったテスト設計仕様をトレースする、
といった目的で使う。
⚫ 検索・分析用情報: エンティティの要素を絞り込んだり、特定の
切り口で分析するために使う情報。
- 「最終実行結果がfailとなったテストを全部抽出してテストセットにしよう」
- 「どの機能についてのテストケースが、pass率低いかな」

27
テストケースがもつべき情報
項目内容 A B C D 備考
テストケースID テストケースを一意に識別する識別子ー ◎ ◎ ー ⚫ システム/人間の識別用に必要
テストケース名テストケースを端的に表現する名称ー ○ ーー ⚫ 人間の識別用に必要
事前/事後条
件
テストケース実行前後のシステムの状態 ◎ ーーー ⚫ テストケースの基本要素
⚫ テスト全体に対する「大前提条件」のようなものがあって、
各テストの前提条件は、その大前提からの差分を記載。
入力値/期待
結果
テスト対象への入力値と、その入力がも
たらすと想定される期待値
◎ ーーー ⚫ テストケースの基本要素
テスト設計仕
様ID
そのテストで確認したいテスト設計仕様
のID
ーー ◎ ○ ⚫ 上位の「テスト設計仕様」と関連付ける。
重要度そのテストの重要度ーーー ○ ⚫ 重要かどうかは場合によるので、テストケース自体に紐
づくのはおかしいかもしれない。
対象機能そのテストケースが対象とする機能ーーー ◎ ⚫ 1つに決まらないこともあるのでタグ化。ただタグが増殖す
る可能性あり。
品質特性そのテストケースが確認しようとする観点
の品質特性
ーーー △ ⚫ 1つに決まらないこともあるので、タグ形式で。
⚫ 品質特性はテスト観点に関連づくので、ここで個別に指
定しない。テスト設計仕様IDから引く。
テストバージョ
ン
テストケースIDに対するバージョンー ◎ ーー ⚫ 後述。
対象プロダクト
バージョン
当該テストバージョンが適用可能なプロ
ダクトのバージョン
ーー ◎ ○ ⚫ 後述。
テスト手順テストを実行する操作のステップ ◎ ーーー ⚫ テストの途中で結果を確認する粒度で区切るとよい。
⚫ 後述。
想定実行時間テスト実行にかかると想定される時間ーーー △ ⚫ 環境によって変わることがあるので、難しいかもしれない。
A: 基本 B: 識別用 C: トレース用 D: 検索・分析用
◎: 必須 ○: あるとベター △: お好みでー：関係なし

28
テストケースのツリー化は必須としない。
前のスライドには「大中小分類」は入れていない。
◼ ツリー構造の悪いところ: 1つの箱にしか入れない。
⚫ たとえば「A機能」「B機能」「C機能」と枝分かれさせてしまった場合、
「A機能とB機能を合わせたテスト」はどこに入れるんだ？
⚫ 複数の値を取りうるパラメタを、ツリー構造にすべきでない。
◼ ツリー構造のいいところ: 見やすい。
⚫ たとえばパソコンのファイルが全部Cドラ直下にあったら・・・。
⚫ gmailは、実態は全メールがフラットになっているが、「ラベル」により、
「メールが複数のフォルダに所属できる」ような見え方になっている。
⚫ Evernoteはフォルダ構造とタグ構造を両立させている。最高。
◼ My結論:
⚫ ツリー構造は、「みやすさ」みたいな便宜的なビューと割り切る。
⚫ 各種属性はタグ管理。検索しやすい→テストスイート作りやすいぞ。

⚫ テストケースが持つべき情報は他にどんな
ものがありますか？
⚫ ツリー構造を取るべき理由ってありますか？
議論ポイント#1

テストケースのバージョン
とは何なのか。

31
テストケースを変更する契機がいくつかある。
A) 本質的でない修正
⚫ 誤字、脱字の修正
⚫ テストケースの属性（ex. 重要度）の変更
B) テストの最適化
⚫ テスト設計の見直しによるデータセット追加
⚫ より簡易、本質的な手順への簡略化
C) 別のプロダクトバージョンへの対応
⚫ テスト観点は同一だが、仕様の異なる別プロダクトのために
データセット追加
- たとえば「作成できるレコード数の上限」が変わったとか。

32
なので変更履歴を管理する必要がある。
◼ バージョン管理の必要性
⚫ Bの場合でも、過去に行ったテスト事項の履歴として、変更前の
バージョンの情報を維持する必要がある。
⚫ Cの場合、従来のプロダクトバージョンのために、変更前の
バージョンを、別の最新版として維持する必要がある。
◼ テストケース変更にともなう必要事項
⚫ テストケースのバージョン管理
⚫ テストケースとプロダクトのバージョン関連付け(*1)（Cに対応）
⚫ テスト実行結果とテストケースバージョンの関連付け（Bに対応）
(*1) プロダクトの最新バージョンだけを維持すればいいのなら、変更履歴としてのバージョン管理をすればよい。
P1.0
T1.0.0 T1.0.1
T2.0.0
P2.0
T1.1
B
C

⚫ テストのバージョン管理と、プロダクトバージョ
ンとの関連付けってどのくらいできています？
⚫ プロダクトコードはgit、手動テストケースは
テスト管理ツール、自動スクリプトはやっぱり
git、とかなったら地獄感ないですか？

テスト手順と
キーワード

35
テストケースの「手順」とは何なのか。
◼ テストケースとテスト手順は、JSTQB的には分かれて
いるが、実務的には手順も含めてテストケースと
呼んでいることが多い（気がする）。
◼ テストケースとテスト手順が多対多になることってあまり
ないんじゃないだろうか。なら一緒に考えてもいいや。

36
配送料の例で考えてみよう
◼ テストケース
1. 2,000円の書籍を北海道札幌市に配送する場合、送料が0円。
2. 200円のティッシュを佐渡ヶ島に配送する場合、送料が500円。
◼ テスト手順
⚫ 具体レベル1: 対象商品を選択し、送料を確認する。
⚫ 具体レベル2: 【商品選択】画面で対象商品をカートに入れ、
【確認】画面で送料を確認する。
⚫ 具体レベル3: 【商品選択】画面で対象商品をクリック、個数が「1」で
あることを確認したうえで、「注文」ボタンをクリック。【確認】画面に
遷移したら、・・・・
◼ レベル3まで必要なのは
⚫ このシステムをよく知らない人。
⚫ 自動テストを書く人。
⚫ 操作順自体がテストの観点になっている場合。障害の再現とか。

37
ならばキーワード化しよう
◼ キーワード駆動テスト (keyword-driven testing)
⚫ 『テストスクリプト記述技術の一つ。テストデータと期待結果だけでなく、
テスト対象アプリケーションに関係するキーワードを含んだデータ
ファイルを使う。キーワードは、テストの制御スクリプトが呼び出す
特別な補助スクリプトが解釈する』
⚫ 手順の本質的な部分を「キーワード」とし、そのキーワードでテスト
手順仕様を記述する。具体的な操作内容は別に実装する。
ログインする 1. ブラウザのアドレスバーに
URLを入力し、ログイン画
面にアクセス
2. 【ユーザ名】テキストフィール
ドにユーザ名を入力
3. ・・・
キーワード
商品を選択する
注文を確認する
補助スクリプト
テスト
手順
・・・
キーワード
①

38
キーワード化して何が嬉しい？
◼ テスト手順の再利用性の向上
⚫ 「テストケースは同一だが、具体的な操作が異なる」場合でも、
キーワードで構成されたテスト手順は同一のままにできる。
◼ 操作内容の再利用性の向上
⚫ 1つの手順について、何度も同じ操作を書き下さずに住む。
◼ 自動化への流用の容易化
⚫ 手順の具体的な操作が明確になっていれば、スクリプト化しやすい。
◼ テスト手順の可読性の向上
⚫ 手順の記述が標準化さ、かつ本質的な部分だけが残るため、理解しやすい。
◼ 属人性の向上(!!)
⚫ 具体的な操作を把握している人は、操作の詳細を見る必要がない。
⚫ 操作内容に裁量があり、探索的な脇道が許容される。
◼ 手順と操作の独立化
⚫ 具体的な操作が変わった場合でも、手順に影響がない。
⚫ 実装が明確になる前に、キーワードで仮に手順を決めておける。

テストケースのパラメタライズ

40
テストケースの「パラメタライズ」とは何なのか。
◼ 同じ手順だが、入力値と期待結果が違うテストケース
がある。
◼ テストケースの「変わる部分」だけを変数化して、データ
セットと組み合わせることで、1つの手順を複数のテスト
手順に展開できる。
◼ データ駆動テストってやつ。

41
配送料の例で考えてみよう
◼ テストケース
1. 2,000円の書籍を北海道札幌市に配送する場合、送料が0円。
2. 200円のティッシュを佐渡ヶ島に配送する場合、送料が500円。
↓ パラメタライズ
 ¥{価格}円の¥{商品種別}を¥{配送先}に配送する場合、送料が
¥{送料}円。
① 価格=2,000、商品種別=書籍、配送先=北海道札幌市、送料=0
② 価格=200、商品種別=ティッシュ、配送先=佐渡ヶ島、送料=500
◼ 何が嬉しい？
⚫ テストケースの再利用性の向上
- 「テスト設計仕様は同一だが、入出力の値などが異なる」場合でも、1つのテスト
ケース（のスケルトン）を複数のテストケースに展開することができる。
⚫ テスト設計とテストケースの独立化
- テストケースの源泉となるテスト設計に変更があっても、データセットに修正が入る
だけで、テストケース自体が影響を受けるリスクが減る。

⚫ テストのバージョン管理と、プロダクトバージョ
ンとの関連付けってどのくらいできています？
⚫ プロダクトコードはgit、手動テストケースは
テスト管理ツール、自動スクリプトはやっぱり
git、とかなったら地獄感ないですか？

44
3つのことがわかった。
◼ テストケースにはバージョンがある。
◼ テストケースの入力と期待出力はパラメタライズすると
よい。
◼ テスト手順の具体的な操作はキーワード化するとよい。

45
テストケースのバージョンを分離する
テストケースにバージョンが存在する
＝そのテストケースに共通の部分と、
バージョンごとに異なる部分があるということになる。
テストケース
(共通部)
テストケースID
テストケース名
テスト設計仕様ID
重要度
対象機能
品質特性
テストケース
(バージョン個別部)
テストケースバージョン
事前/事後条件
入力値/期待結果
重要度
テスト手順
対象プロダクトバージョン
想定実行時間
テストケース

46
テストケースから、パラメタと操作を分離する
データ駆動の考え方に基づき、パラメタを分離する。
キーワード駆動の考え方に基づき、具体的な操作を分
離する。
手順
キーワード1(パラメタライズ)
テストケース
テストケース
テストケースバージョン
事前/事後条件
入力値/期待結果
重要度
テスト手順(パラメタライズ)
対象プロダクトバージョン
想定実行時間
キーワード
操作1-1
操作1-2
操作1-3
データシート
パラメタ1
パラメタ2
パラメタ3

どのように関連付け？

48
テストケース周りのエセE-R図 (再掲)
① テスト要求分析、テストアーキ設計といったアク
ティビティから、テスト設計仕様が導かれる。
② テスト設計仕様から、テストケースが導かれる。
③ テストケースは複数のバージョンで構成される。
④ テストケースの手順は、複数のキーワードの羅列
で表現される。
⑤ キーワードは、具体的な操作が別に定義される。
⑥ テストケースの入力値や期待結果はパラメタライ
ズされ、データセットとして別に保持する。
⑦ テスト工程で行うテストをまとめてテストセットとす
る。
⑧ テストケースは複数回実行される前提で、それぞ
れに結果を持つ。
⑨ 実行結果に対し、0個以上のインシデントがある。
(*1) 最初は、テストケースの上流は「テスト観点」しており、観点とテストケースは多対多としていたけれど、現時
点では「設計仕様」をおいている。「1つのテストケースが複数の観点を持つことを許容するか」というにしさんの質
問に回答できていない。
テストケース
(バージョン
個別部)
テストケース
(共通部)
いわゆる
テスト
ケース
テスト実行
結果
テスト設計
仕様(*1)
テストセット
キーワード
テスト工程テストケース
操作
テスト開発の
上流成果物
テスト分析・
設計
テスト実装
テスト実行インシデント
データ駆動用
データ
①
②
③ ④ ⑤
⑥
⑦ ⑧ ⑨
⑦
エンティティ
リレーションシップ

主張を理解していただけましたか？
ここまでやることに意味あります？

以下の方に、ご意見いただきました。
どうもありがとうございます。
@s_banban
@YasuharuNishi
@NoriyukiMizuno
@keiji_uetsuki
@MAQ69
@誰か漏れているかも・・・。

さあ、ディスカッションの時間だ。

52
世の中のテスト管理ツールは？
◼ TestLink
◼ TestRail
◼ Quality Center
◼ Squash TM
⚫ バージョン管理: なし
⚫ データ駆動: あり
⚫ キーワード駆動: なし
◼ Testructure

53
参考資料
◼ I/JSTQBシラバス
◼ Qbook テスト用語集
◼ Togetter
⚫ テストケースとテスト条件の違いについて
⚫ テスト条件とテスト観点
⚫ テスト設計コンテストOPEN東京チュートリアルまとめ

54
ありがとうございました。

20181102_テスト管理を語る夕べ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20181102_テスト管理を語る夕べ

Similar to 20181102_テスト管理を語る夕べ (20)

20181102_テスト管理を語る夕べ