Downloaded 31 times
Uploaded byKazuhiro Suzuki
20181102_テスト管理を語る夕べ
「テスト管理を語る夕べ」のイベントでの発表資料です。 https://kataruyube.connpass.com/event/102972/ https://togetter.com/li/1284132
20181102_テスト管理を語る夕べ
- 1. Copyright 2018 KazuhiroSUZUKI ソフトウェア開発者のための テスト管理を語る夕べ 第1回: テストケースの構造について 2018年11月2日(金) 鈴木 一裕 @kz_suzuki
- 2. 2 / 54Copyright 2018Kazuhiro SUZUKI ⚫ 『システムテスト自動化 標準ガイド』監訳・翻訳 @ 翔泳社 ⚫ 『1時間で分かるSTA』発表 @ テスト自動化カンファレンス2014 ⚫ 『テストを自動化するスクリプティング…』寄稿 @ Codezine ⚫ 『ギアと開発とわたし』発表 @ 第一回AsiyanAutomationAlliance ⚫ 『探索的テストのモデルとFAQ』発表 @ JaSST'16 Tokyo ⚫ ブログ: 『ソフトウェアの品質を学びまくる2.0』 ⚫ Twitter: kz_suzuki ※所属組織とは云々 鈴木 一裕 (すずき かずひろ) ソフトウェアのテスト・品質界隈で、 地味にコミュニティ参加しています。 会社に怒られない程度に 情報発信しています。 品質屋さん、組込みソフトウェアの自動化など。
- 3.
- 4. 4 / 54Copyright 2018Kazuhiro SUZUKI かっこいいマネジャーの 話はでてきません。
- 5. 5 / 54Copyright 2018Kazuhiro SUZUKI 「テスト」で「管理」するものってなんだろう。 ◼ 「4つの経営資源」で考えてみる。 ヒト モノ カネ 情報 ⚫ 工数 ⚫ スキル ⚫ コミュニケーション ⚫ ・・・ ⚫ テスト環境 ⚫ ハードウェア ⚫ ソフトウェア ⚫ ネットワーク ⚫ テストツール ⚫ ハードウェア ⚫ ソフトウェア ⚫ ライセンス ⚫ シミュレータ ⚫ ・・・ ⚫ 人月単価！ ⚫ インフラ利用料 ⚫ Earned Value ⚫ ・・・ ⚫ テストに関する 情報 ⚫ テストベース ⚫ テストケース ⚫ テスト手順 ⚫ テスト実行状況 ⚫ インシデント ⚫ ブロッキングバグ ⚫ ・・・ テストマネジャー！って感じのやつ ただし、情報があるからこそマネジメントができる。 地味なやつ
- 6. 6 / 54Copyright 2018Kazuhiro SUZUKI JSTQBで定義されたテストプロセス (*1) I/JSTQBではこの他、テストの「モニタリングおよびコントロール」 「終了基準の評価とレポート」「テスト終了作業」というプロセスが定義されている。 テスト 実装 テスト 実行 テスト 設計 テスト 分析 テスト 計画 テストの目的を定義し、そのテストの使命や 目的に合致するようテストの仕様を決めること 「何を」テストするかをテスト条件の形式で定義 する活動。テスト条件は、テストベース、テスト 目的(…)を分析することにより、識別可能 何かを「どのように」テストするかを定義する 活動。(…) テスト技法を使用して、 (…) テスト ケースの識別を行う。 テスト設計を具体的なテストケース、テスト手順、 およびテストデータとして実装する活動である。 テスト対象のコンポーネントやシステムでテスト を実行し、実行結果を出力するプロセス。 ⚫ テスト要求仕様 ⚫ テストアーキ ⚫ テスト設計仕様 ⚫ テストケース ⚫ テスト手順 ⚫ テストデータ ⚫ テストスイート ⚫ 実行結果 ⚫ インシデント ⚫ 進捗状況 ⚫ テスト計画書 テストウェアの情報 テスト実行の情報 テスト 管理を 語る夕べ テスト戦略を… HAYST法を… テスト要求分析を… テスト観点を… 原因結果グラフを… の、第1回
- 7. 7 / 54Copyright 2018Kazuhiro SUZUKI まちがいさがし ◼ 以下のテストケース管理は何が渋いなのか。 ⚫ テストケースの網羅性が ◼ 今回は「情報」と「構造」に注目する。 ⚫ 「ログイン」が大にも中にも出てくるんだけど、どういう切り口で「分類」 しているんだ・・・？ 品質特性9126的なのも見えるが・・・。 ⚫ #1は2回やったから2回分の記録があるけれど、集計できないぞ・・・。 というかどのバージョンで実行したんだよ・・・。 ⚫ 手順の書き方が人によって違う、期待結果もいい加減すぎる・・・。 ⚫ ログインのユーザ種別って「会員」と「非会員」で網羅できてるの？ # 大分類 中分類 小分類 手順 期待結果 実施者 実施日 結果 1 機能性 正確性 配送料計算 無料になるケース 配送料を計 算する 仕様どおりであること 鈴木 10/8 10/9 NG OK 2 機能性 正確性 配送料計算 無料にならないケース 「確認」画面 に遷移し・・・ 配送料が正しく計算 されていること。 佐藤 10/8 OK 3 ログイン 会員 － 4 ログイン 非会員 － 5 性能 ログイン 40ユーザ同時ログイン
- 8.
- 9.
- 10.
- 11. 11 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: テストケース周り (1) ◼ テストケース (test case) ⚫ 『入力値、実行事前条件、期待結果、そして、実行事後条件の セットで(略)特定の目的又はテスト条件のために開発されたもの』 (*1) ⚫ 手順はテストケースの必須要素ではない。 ◼ 粒度での分類 ⚫ 具体的テストケース (concrete test case) - 『入力データと期待結果が具体的なテストケース。高位レベルのテストケース からの論理演算子は、論理演算子に相当する実際の値に置き換えられる』 - = 低位レベルテストケース (low level test case) ⚫ 抽象的テストケース (abstract test case) - 『具体的な入力値や予測結果を使わないテストケース。論理演算子は使用す るが、値のインスタンスは未定義や使用不可であるといった状態にある』 - = 高位レベルテストケース (high level test case) - = 論理的テストケース (logical test case) (*1) この節でカッコで囲んでいるものは、JSTQB用語集からの引用。
- 12. 12 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: テストケース周り (2) ◼ テスト手順仕様 (test procedure specification) ⚫ 『テストの実行のために、一連の手順を定めたドキュメント。 テストスクリプト、又は、手動テストスクリプトとしても知られる』 ◼ テスト設計仕様 (test design specification) ⚫ 『テストアイテムのテスト条件（カバレッジアイテム）、詳細なテスト アプローチ、及び、関連する高位レベルテストケースを記述した ドキュメント』 ⚫ 「テストアイテムのテスト条件」！？ ⚫ （具体的）テストケースの源泉となるもの。 ◼ テスト仕様書 (test specification) ⚫ 『テスト設計仕様、テストケース仕様、テスト手順仕様からなる ドキュメント』 ⚫ テストウェアの一部と考えてよさそう。 ⚫ 今回議論したいのは、この辺のエンティティ。 (*1) この節でカッコで囲んでいるものは、JSTQB用語集からの引用。
- 13. 13 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: テストケース周り (3) ◼ テストスイート (test suite) ⚫ 『テスト対象のコンポーネント又はシステムのためのいくつかのテスト ケースのセット。一つのテストの実行事後条件は、次のテストの実行 事前条件としてよく利用される』 ⚫ ＝テストセット (test set) ⚫ 1つ以上のテストケースを、目的に応じてひとまとまりにしたもの。 ◼ テストチャータ (test charter) ⚫ 『テスト目的を明記したもの。テスト実施法のアイデアを含む場合も ある。探索的テストにて使用する』 ⚫ 今回、深入りは避けよう。 (*1) この節でカッコで囲んでいるものは、JSTQB用語集からの引用。
- 14. 14 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: テストケース周り (4) ◼ テストベース (test basis) ⚫ 『コンポーネント要件やシステム要件を推測できる全てのドキュメント。 これらのドキュメントがテストケースのベースとなる』 ◼ テストウェア (testware) ⚫ 『テストプロセスを通じて作成される、テストの計画、設計、実行に 不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、 セットアップとクリーンアップの処理手順、ファイル、データベース、環境、 その他、テストで使用する付加的なソフトウェアやユーティリティなど』 ◼ ざっくりと、ベースがINで、ウェアがOUTですかね(*1)。 (*1) ただし既存ツールなどもウェアに含まれるので、必ずしもOUTされるわけではない。
- 15. 15 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: ややこしいヤツら ◼ テスト対象 (test object) ⚫ 『テストすべきコンポーネント又はシステム』 ⚫ 何をテストするのか。 ◼ テスト目的 (test objective) ⚫ 『テストを設計、実行する理由や目的』 ⚫ 何のためにテストするのか。 ◼ テストタイプ、テストレベル、テストフェーズ、・・・ 今回の話にはあまり関係ない、忘れよう。 テストケースとテスト条件の違いについて
- 16. 16 / 54Copyright 2018Kazuhiro SUZUKI 用語の確認: もっとややこしいヤツら ◼ テストアイテム (test item) ⚫ 『テストを実施する個々の要素。通常、一つのテスト対象に対し、 多数のテストアイテムがある』 ⚫ テスト条件と区別できないが、あまり聞かない言葉なので忘れよう。 ◼ テスト条件 (test condition) ⚫ 『コンポーネントやシステムのアイテムやイベントで、 テストケースにより 検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質 特性、構造要素など』(*1) ⚫ テスト対象のうち、検証したい部分・側面というMy解釈。 ◼ テスト観点 (test viewpoint)(*2) ⚫ テスト条件に対する狙い所というMy解釈。 ⚫ テスト条件と明確な区切りはなく、重なり合うのでは。テスト観点は 何でも包括してしまう印象。 (*1)テストケースの事前条件とは違うので注意。 (*2) I/JSTQBでは定義されていない！
- 17.
- 18.
- 19. 19 / 54Copyright 2018Kazuhiro SUZUKI 『ソフトウェアテスト技法ドリル』より例題 ◼ プログラムの仕様 「品物が書籍」で、「合計1,500円以上」で、「配送先が離島以外」なら、 配送料を無料とする。 ◼ テスト対象: オンラインショッピングシステム ◼ テストアイテム: 配送料計算機能 ◼ テスト条件の例 ⚫ 送料計算が仕様通りに正しく行われること。 ⚫ 送料計算に要する時間が性能要求を満たすこと。 ◼ テスト観点の例 ⚫ 送料計算は境界値でも大丈夫か。 ⚫ 全部が書籍の場合、全部が書籍以外の場合と、混在の場合は？ ⚫ このシステムでは、雑誌って「書籍」に入るの？
- 20. 20 / 54Copyright 2018Kazuhiro SUZUKI 『ソフトウェアテスト技法ドリル』より例題 ◼ 抽象的テストケース: 決定表で網羅しよう。 ◼ 具体的テストケース ⚫ 事前条件: サイトにログインし、購入可能状態になっていること。 ⚫ 入力値と期待結果 - ＃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
- 21.
- 22. 22 / 54Copyright 2018Kazuhiro SUZUKI 前置きのまとめ ◼ 今回の議論に残したいエンティティ ⚫ テスト仕様 - テスト設計仕様 ← これはおおむね終わっている前提 - テストケース仕様 - テスト手順仕様 ⚫ テスト観点 ⚫ テストセット（=テストスイート） ⚫ テスト実行結果 ◼ 今回議論したいポイント テストケースの ⚫ 各エンティティにはどのような情報を持たせるといいのか。 ⚫ 各エンティティはどのように分割するのがいいのか。 ⚫ エンティティ同士はどのように関連付けるといいのか。
- 23.
- 24. 24 / 54Copyright 2018Kazuhiro SUZUKI テストケース周りのエセE-R図 ① テスト要求分析、テストアーキ設計といったアク ティビティから、テスト設計仕様が導かれる。 ② テスト設計仕様から、テストケースが導かれる。 ③ テストケースは複数のバージョンで構成される。 ④ テストケースの手順は、複数のキーワードの羅列 で表現される。 ⑤ キーワードは、具体的な操作が別に定義される。 ⑥ テストケースの入力値や期待結果はパラメタライ ズされ、データセットとして別に保持する。 ⑦ テスト工程で行うテストをまとめてテストセットとす る。 ⑧ テストケースは複数回実行される前提で、それぞ れに結果を持つ。 ⑨ 実行結果に対し、0個以上のインシデントがある。 (*1) 最初は、テストケースの上流は「テスト観点」しており、観点とテストケースは多対多としていたけれど、現時 点では「設計仕様」をおいている。「1つのテストケースが複数の観点を持つことを許容するか」というにしさんの質 問に回答できていない。 テストケース (バージョン 個別部) テストケース (共通部) いわゆる テスト ケース テスト実行 結果 テスト設計 仕様(*1) テストセット キーワード テスト工程 テストケース 操作 テスト開発の 上流成果物 テスト分析・ 設計 テスト実装 テスト実行 インシデント データ駆動用 データ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑦ エンティティ リレーションシップ
- 25.
- 26. 26 / 54Copyright 2018Kazuhiro SUZUKI エンティティが持つ情報の役割 情報にはいろいろ役割がありそうなので、分類してみた。 非MECE。 ⚫ 基本情報: そのエンティティが本質的に必要とする情報。 - テストケースでは「期待結果」が基本情報に相当する。 - 「期待結果のないテストケースを見たことがあるのですが・・・」 →「みんなの心の中にある」 ⚫ 識別用情報: そのエンティティを識別するために使う情報。 - 「○○ID」というものが多い。 ⚫ トレース用情報: 別のエンティティと関連付けるための情報。 - たとえば、あるテストケースの源泉となったテスト設計仕様をトレースする、 といった目的で使う。 ⚫ 検索・分析用情報: エンティティの要素を絞り込んだり、特定の 切り口で分析するために使う情報。 - 「最終実行結果がfailとなったテストを全部抽出してテストセットにしよう」 - 「どの機能についてのテストケースが、pass率低いかな」
- 27. 27 / 54Copyright 2018Kazuhiro SUZUKI テストケースがもつべき情報 項目 内容 A B C D 備考 テストケースID テストケースを一意に識別する識別子 ー ◎ ◎ ー ⚫ システム/人間の識別用に必要 テストケース名 テストケースを端的に表現する名称 ー ○ ー ー ⚫ 人間の識別用に必要 事前/事後条 件 テストケース実行前後のシステムの状態 ◎ ー ー ー ⚫ テストケースの基本要素 ⚫ テスト全体に対する「大前提条件」のようなものがあって、 各テストの前提条件は、その大前提からの差分を記載。 入力値/期待 結果 テスト対象への入力値と、その入力がも たらすと想定される期待値 ◎ ー ー ー ⚫ テストケースの基本要素 テスト設計仕 様ID そのテストで確認したいテスト設計仕様 のID ー ー ◎ ○ ⚫ 上位の「テスト設計仕様」と関連付ける。 重要度 そのテストの重要度 ー ー ー ○ ⚫ 重要かどうかは場合によるので、テストケース自体に紐 づくのはおかしいかもしれない。 対象機能 そのテストケースが対象とする機能 ー ー ー ◎ ⚫ 1つに決まらないこともあるのでタグ化。ただタグが増殖す る可能性あり。 品質特性 そのテストケースが確認しようとする観点 の品質特性 ー ー ー △ ⚫ 1つに決まらないこともあるので、タグ形式で。 ⚫ 品質特性はテスト観点に関連づくので、ここで個別に指 定しない。テスト設計仕様IDから引く。 テストバージョ ン テストケースIDに対するバージョン ー ◎ ー ー ⚫ 後述。 対象プロダクト バージョン 当該テストバージョンが適用可能なプロ ダクトのバージョン ー ー ◎ ○ ⚫ 後述。 テスト手順 テストを実行する操作のステップ ◎ ー ー ー ⚫ テストの途中で結果を確認する粒度で区切るとよい。 ⚫ 後述。 想定実行時間 テスト実行にかかると想定される時間 ー ー ー △ ⚫ 環境によって変わることがあるので、難しいかもしれない。 A: 基本 B: 識別用 C: トレース用 D: 検索・分析用 ◎: 必須 ○: あるとベター △: お好みで ー：関係なし
- 28. 28 / 54Copyright 2018Kazuhiro SUZUKI テストケースのツリー化は必須としない。 前のスライドには「大中小分類」は入れていない。 ◼ ツリー構造の悪いところ: 1つの箱にしか入れない。 ⚫ たとえば「A機能」「B機能」「C機能」と枝分かれさせてしまった場合、 「A機能とB機能を合わせたテスト」はどこに入れるんだ？ ⚫ 複数の値を取りうるパラメタを、ツリー構造にすべきでない。 ◼ ツリー構造のいいところ: 見やすい。 ⚫ たとえばパソコンのファイルが全部Cドラ直下にあったら・・・。 ⚫ gmailは、実態は全メールがフラットになっているが、「ラベル」により、 「メールが複数のフォルダに所属できる」ような見え方になっている。 ⚫ Evernoteはフォルダ構造とタグ構造を両立させている。最高。 ◼ My結論: ⚫ ツリー構造は、「みやすさ」みたいな便宜的なビューと割り切る。 ⚫ 各種属性はタグ管理。検索しやすい→テストスイート作りやすいぞ。
- 29.
- 30.
- 31. 31 / 54Copyright 2018Kazuhiro SUZUKI テストケースを変更する契機がいくつかある。 A) 本質的でない修正 ⚫ 誤字、脱字の修正 ⚫ テストケースの属性（ex. 重要度）の変更 B) テストの最適化 ⚫ テスト設計の見直しによるデータセット追加 ⚫ より簡易、本質的な手順への簡略化 C) 別のプロダクトバージョンへの対応 ⚫ テスト観点は同一だが、仕様の異なる別プロダクトのために データセット追加 - たとえば「作成できるレコード数の上限」が変わったとか。
- 32. 32 / 54Copyright 2018Kazuhiro SUZUKI なので変更履歴を管理する必要がある。 ◼ バージョン管理の必要性 ⚫ Bの場合でも、過去に行ったテスト事項の履歴として、変更前の バージョンの情報を維持する必要がある。 ⚫ Cの場合、従来のプロダクトバージョンのために、変更前の バージョンを、別の最新版として維持する必要がある。 ◼ テストケース変更にともなう必要事項 ⚫ テストケースのバージョン管理 ⚫ テストケースとプロダクトのバージョン関連付け(*1)（Cに対応） ⚫ テスト実行結果とテストケースバージョンの関連付け（Bに対応） (*1) プロダクトの最新バージョンだけを維持すればいいのなら、変更履歴としてのバージョン管理をすればよい。 P1.0 T1.0.0 T1.0.1 T2.0.0 P2.0 T1.1 B C
- 33.
- 34.
- 35. 35 / 54Copyright 2018Kazuhiro SUZUKI テストケースの「手順」とは何なのか。 ◼ テストケースとテスト手順は、JSTQB的には分かれて いるが、実務的には手順も含めてテストケースと 呼んでいることが多い（気がする）。 ◼ テストケースとテスト手順が多対多になることってあまり ないんじゃないだろうか。なら一緒に考えてもいいや。
- 36. 36 / 54Copyright 2018Kazuhiro SUZUKI 配送料の例で考えてみよう ◼ テストケース 1. 2,000円の書籍を北海道札幌市に配送する場合、送料が0円。 2. 200円のティッシュを佐渡ヶ島に配送する場合、送料が500円。 ◼ テスト手順 ⚫ 具体レベル1: 対象商品を選択し、送料を確認する。 ⚫ 具体レベル2: 【商品選択】画面で対象商品をカートに入れ、 【確認】画面で送料を確認する。 ⚫ 具体レベル3: 【商品選択】画面で対象商品をクリック、個数が「1」で あることを確認したうえで、「注文」ボタンをクリック。【確認】画面に 遷移したら、・・・・ ◼ レベル3まで必要なのは ⚫ このシステムをよく知らない人。 ⚫ 自動テストを書く人。 ⚫ 操作順自体がテストの観点になっている場合。障害の再現とか。
- 37. 37 / 54Copyright 2018Kazuhiro SUZUKI ならばキーワード化しよう ◼ キーワード駆動テスト (keyword-driven testing) ⚫ 『テストスクリプト記述技術の一つ。テストデータと期待結果だけでなく、 テスト対象アプリケーションに関係するキーワードを含んだデータ ファイルを使う。キーワードは、テストの制御スクリプトが呼び出す 特別な補助スクリプトが解釈する』 ⚫ 手順の本質的な部分を「キーワード」とし、そのキーワードでテスト 手順仕様を記述する。具体的な操作内容は別に実装する。 ログインする 1. ブラウザのアドレスバーに URLを入力し、ログイン画 面にアクセス 2. 【ユーザ名】テキストフィール ドにユーザ名を入力 3. ・・・ キーワード 商品を選択する 注文を確認する 補助スクリプト テスト 手順 ・・・ キーワード ①
- 38. 38 / 54Copyright 2018Kazuhiro SUZUKI キーワード化して何が嬉しい？ ◼ テスト手順の再利用性の向上 ⚫ 「テストケースは同一だが、具体的な操作が異なる」場合でも、 キーワードで構成されたテスト手順は同一のままにできる。 ◼ 操作内容の再利用性の向上 ⚫ 1つの手順について、何度も同じ操作を書き下さずに住む。 ◼ 自動化への流用の容易化 ⚫ 手順の具体的な操作が明確になっていれば、スクリプト化しやすい。 ◼ テスト手順の可読性の向上 ⚫ 手順の記述が標準化さ、かつ本質的な部分だけが残るため、理解しやすい。 ◼ 属人性の向上(!!) ⚫ 具体的な操作を把握している人は、操作の詳細を見る必要がない。 ⚫ 操作内容に裁量があり、探索的な脇道が許容される。 ◼ 手順と操作の独立化 ⚫ 具体的な操作が変わった場合でも、手順に影響がない。 ⚫ 実装が明確になる前に、キーワードで仮に手順を決めておける。
- 39.
- 40. 40 / 54Copyright 2018Kazuhiro SUZUKI テストケースの「パラメタライズ」とは何なのか。 ◼ 同じ手順だが、入力値と期待結果が違うテストケース がある。 ◼ テストケースの「変わる部分」だけを変数化して、データ セットと組み合わせることで、1つの手順を複数のテスト 手順に展開できる。 ◼ データ駆動テストってやつ。
- 41. 41 / 54Copyright 2018Kazuhiro SUZUKI 配送料の例で考えてみよう ◼ テストケース 1. 2,000円の書籍を北海道札幌市に配送する場合、送料が0円。 2. 200円のティッシュを佐渡ヶ島に配送する場合、送料が500円。 ↓ パラメタライズ ¥{価格}円の¥{商品種別}を¥{配送先}に配送する場合、送料が ¥{送料}円。 ① 価格=2,000、商品種別=書籍、配送先=北海道札幌市、送料=0 ② 価格=200、商品種別=ティッシュ、配送先=佐渡ヶ島、送料=500 ◼ 何が嬉しい？ ⚫ テストケースの再利用性の向上 - 「テスト設計仕様は同一だが、入出力の値などが異なる」場合でも、1つのテスト ケース（のスケルトン）を複数のテストケースに展開することができる。 ⚫ テスト設計とテストケースの独立化 - テストケースの源泉となるテスト設計に変更があっても、データセットに修正が入る だけで、テストケース自体が影響を受けるリスクが減る。
- 42.
- 43.
- 44. 44 / 54Copyright 2018Kazuhiro SUZUKI 3つのことがわかった。 ◼ テストケースにはバージョンがある。 ◼ テストケースの入力と期待出力はパラメタライズすると よい。 ◼ テスト手順の具体的な操作はキーワード化するとよい。
- 45. 45 / 54Copyright 2018Kazuhiro SUZUKI テストケースのバージョンを分離する テストケースにバージョンが存在する ＝そのテストケースに共通の部分と、 バージョンごとに異なる部分があるということになる。 テストケース (共通部) テストケースID テストケース名 テスト設計仕様ID 重要度 対象機能 品質特性 テストケース (バージョン個別部) テストケースID テストケースバージョン 事前/事後条件 入力値/期待結果 重要度 テスト手順 対象プロダクトバージョン 想定実行時間 テストケース
- 46. 46 / 54Copyright 2018Kazuhiro SUZUKI テストケースから、パラメタと操作を分離する データ駆動の考え方に基づき、パラメタを分離する。 キーワード駆動の考え方に基づき、具体的な操作を分 離する。 手順 キーワード1(パラメタライズ) キーワード2(パラメタライズ) キーワード3(パラメタライズ) テストケース (バージョン個別部) テストケース (バージョン個別部) テストケースID テストケースバージョン 事前/事後条件 入力値/期待結果 重要度 テスト手順(パラメタライズ) 対象プロダクトバージョン 想定実行時間 キーワード 操作1-1 操作1-2 操作1-3 データシート パラメタ1 パラメタ2 パラメタ3
- 47.
- 48. 48 / 54Copyright 2018Kazuhiro SUZUKI テストケース周りのエセE-R図 (再掲) ① テスト要求分析、テストアーキ設計といったアク ティビティから、テスト設計仕様が導かれる。 ② テスト設計仕様から、テストケースが導かれる。 ③ テストケースは複数のバージョンで構成される。 ④ テストケースの手順は、複数のキーワードの羅列 で表現される。 ⑤ キーワードは、具体的な操作が別に定義される。 ⑥ テストケースの入力値や期待結果はパラメタライ ズされ、データセットとして別に保持する。 ⑦ テスト工程で行うテストをまとめてテストセットとす る。 ⑧ テストケースは複数回実行される前提で、それぞ れに結果を持つ。 ⑨ 実行結果に対し、0個以上のインシデントがある。 (*1) 最初は、テストケースの上流は「テスト観点」しており、観点とテストケースは多対多としていたけれど、現時 点では「設計仕様」をおいている。「1つのテストケースが複数の観点を持つことを許容するか」というにしさんの質 問に回答できていない。 テストケース (バージョン 個別部) テストケース (共通部) いわゆる テスト ケース テスト実行 結果 テスト設計 仕様(*1) テストセット キーワード テスト工程 テストケース 操作 テスト開発の 上流成果物 テスト分析・ 設計 テスト実装 テスト実行 インシデント データ駆動用 データ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑦ エンティティ リレーションシップ
- 49.
- 50.
- 51.
- 52. 52 / 54Copyright 2018Kazuhiro SUZUKI 世の中のテスト管理ツールは？ ◼ TestLink ◼ TestRail ◼ Quality Center ◼ Squash TM ⚫ バージョン管理: なし ⚫ データ駆動: あり ⚫ キーワード駆動: なし ◼ Testructure
- 53. 53 / 54Copyright 2018Kazuhiro SUZUKI 参考資料 ◼ I/JSTQBシラバス ◼ Qbook テスト用語集 ◼ Togetter ⚫ テストケースとテスト条件の違いについて ⚫ テスト条件とテスト観点 ⚫ テスト設計コンテストOPEN東京チュートリアルまとめ
- 54. 54 / 54Copyright 2018Kazuhiro SUZUKI ありがとうございました。