Slide 1
Slide 1 text
テスト技法を使ったテストケースの表
現方法
テスト技法とテストケースを繋ぐ１事例
2023/03/22 Henry QA LT大会
@shimashima35 島根 義和
Slide 2
Slide 2 text
● リーガルテック企業のQA (兼SET)
● 元サーバサイドJavaエンジニア
● 2019年 Selenium Conf Tokyo 実行委員
● 「エキスパートが教えるSelenium最前線」を共著
● 2012年からJaSST Tokyo実行委員
自己紹介
Slide 3
Slide 3 text
テスト管理ツールについての話はしません。基本的にはスプ
レッドシートでのテストケースの表現について話をしていきま
す。
が、テスト管理ツールを使っても似たような課題に行きあたるこ
とがありますので参考にはなります。
おことわり
Slide 4
Slide 4 text
テスト技法使ってますか？
皆さん、テスト技法を使っていますか？
● ペアワイズ
● ディシジョンテーブル
● 状態遷移
● etc……
Slide 5
Slide 5 text
上野動物公園の入園料をGIHOZで表現してみる
例：ディシジョンテーブル その１
Slide 6
Slide 6 text
GIHOZでテストケースを生成してみる。
を、いい感じ、よしできた！
例：ディシジョンテーブル その２
Slide 7
Slide 7 text
テストケースに書き写すぞ！
テストケースのフォーマット
Slide 8
Slide 8 text
できた！
テストケース記述 その1
Slide 9
Slide 9 text
こんな疑問ありませんか？
● 似たような文字が並んで、記述ミス・読み
取りミスが発生しそう。(したことがある)
● どこがこのテストで重要なのかわかりにく
い。
● ディシジョンテーブルの方がわかりやすい
のでは？
Slide 10
Slide 10 text
ちょっと改良してみよう
テストケース記述 その2
Slide 11
Slide 11 text
こんな疑問ありませんか？
● たまたま条件が3つだから「大中小」に当
てはまるけれど、条件が4種類以上だった
らどうしよう？
● 仕様変更でディシジョンテーブルが変わっ
た場合、毎回テストケースを修正して行く
のは無駄なのでは？
● ディシジョンテーブルだとロジックが見える
が、ケースにしたとたん見えにくくなる。い
いのかな？
Slide 12
Slide 12 text
● 割り当てられたパラメータ・バリューをもとに、手順書を書き
起こすのは無駄なのでは？
● 大項目・中項目・小項目が、ディシジョンテーブル毎に全く別
の意味になるがこれでいいのか？関連するテストケースで
フィルタする場合に使えない。
○ 大項目・中項目・小項目の順番もそろえないと集約でき
ない。
● などなど
その他にも
Slide 13
Slide 13 text
単一フォーマットのスプレッドシートです
べてを押し込めようとすること
何が原因か？
Slide 14
Slide 14 text
基本的には以下が主な理由 (のはず)
● ケース全体の一覧性の確保
● 実行および結果の管理
この目的を満たしたうえでよりよい記法を考える。
なぜ表にケースを書くのか
Slide 15
Slide 15 text
こんな感じに書く
実施内容などは参照先のURLをそのまま書いてしまう。
(対象機能、分類はテストケースの整理方法によって変更)
自分なりの結論
Slide 16
Slide 16 text
● テストのパターン詳細はディシジョンテーブル、N-Wise、状
態遷移のスイッチカバレッジ表 へ任せる。
● テストケース表は上記の表へのリンクを張った上で、表の番
号の実行を書く。
● 実行結果は一覧表に記載する。
自分なりの結論 続き
Slide 17
Slide 17 text
● 基本的にテストはなんらかのパターン、組み合わせで行わ
れる。画面ベースでは考えない。VSTePなどのテスト分析を
きちんと行う。
● テスト設計技法を適切に選びきちんと使う。
● テスト対象の操作方法については実行者が理解している。
とはいえ複雑・わかりにくい場合は備考などで補足する。
自分なりの結論 前提
Slide 18
Slide 18 text
● テスト設計技法を学んだうえできちんと使いこなしましょう。
これが大前提。
● 単一表にすべてを押し込めることには無理がある。なので
無理しないで分けましょう。
おわり