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