Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト技法を使ったテストケースの表現方法/How to express test cases ...
Search
SHIMANE, Yoshikazu
March 22, 2023
Technology
0
1k
テスト技法を使ったテストケースの表現方法/How to express test cases using test techniques
SHIMANE, Yoshikazu
March 22, 2023
Tweet
Share
More Decks by SHIMANE, Yoshikazu
See All by SHIMANE, Yoshikazu
VSTePのテスト観点出しで失敗した事例についての紹介/Failure case of test viewpoint derivation
shimashima35
0
660
組織横断部門におけるバグ数可視化の全社導入の事例/Example_of_company-wide_bug_number_visualization in_cross-organizational_departments
shimashima35
1
350
JaSST Tokyo実行委員のお仕事/Job of JaSST executive committee
shimashima35
0
710
What is “Quality” ?
shimashima35
0
960
品質"実質"無料キャンペーン始めます / Start_quality_real_free_campaign
shimashima35
2
5.4k
明日から始めるSelenideによるブラウザテスト 2018年版/ Browser_test_by_selenide_to_start_from_tomorrow_in_2018
shimashima35
1
830
SelenideよるDSL風E2Eテスト基盤開発の実例 in Osaka /Example_of_E2E_Automation_Test_Architecture_By_Selenide_in_Osaka
shimashima35
0
1.1k
SelenideよるDSL風E2Eテスト基盤開発の実例/Example_of_E2E_Automation_Test_Architecture_By_Selenide
shimashima35
0
1k
明日から始めるSelenideによるブラウザテスト / Browser_test_by_selenide_to_start_from_tomorrow.
shimashima35
0
2.4k
Other Decks in Technology
See All in Technology
統計データで2024年の クラウド・インフラ動向を眺める
ysknsid25
2
840
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
300
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
160
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.2k
非機能品質を作り込むための実践アーキテクチャ
knih
3
950
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
AWS re:Invent 2024 ふりかえり
kongmingstrap
0
130
NW-JAWS #14 re:Invent 2024(予選落ち含)で 発表された推しアップデートについて
nagisa53
0
250
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
430
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
240
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
Featured
See All Featured
Building an army of robots
kneath
302
44k
The Invisible Side of Design
smashingmag
298
50k
GraphQLとの向き合い方2022年版
quramy
44
13k
Bash Introduction
62gerente
608
210k
Statistics for Hackers
jakevdp
796
220k
Faster Mobile Websites
deanohume
305
30k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.4k
Speed Design
sergeychernyshev
25
670
Transcript
テスト技法を使ったテストケースの表 現方法 テスト技法とテストケースを繋ぐ1事例 2023/03/22 Henry QA LT大会 @shimashima35 島根 義和
• リーガルテック企業のQA (兼SET) • 元サーバサイドJavaエンジニア • 2019年 Selenium Conf Tokyo
実行委員 • 「エキスパートが教えるSelenium最前線」を共著 • 2012年からJaSST Tokyo実行委員 自己紹介
テスト管理ツールについての話はしません。基本的にはスプ レッドシートでのテストケースの表現について話をしていきま す。 が、テスト管理ツールを使っても似たような課題に行きあたるこ とがありますので参考にはなります。 おことわり
テスト技法使ってますか? 皆さん、テスト技法を使っていますか? • ペアワイズ • ディシジョンテーブル • 状態遷移 • etc……
上野動物公園の入園料をGIHOZで表現してみる 例:ディシジョンテーブル その1
GIHOZでテストケースを生成してみる。 を、いい感じ、よしできた! 例:ディシジョンテーブル その2
テストケースに書き写すぞ! テストケースのフォーマット
できた! テストケース記述 その1
こんな疑問ありませんか? • 似たような文字が並んで、記述ミス・読み 取りミスが発生しそう。(したことがある) • どこがこのテストで重要なのかわかりにく い。 • ディシジョンテーブルの方がわかりやすい のでは?
ちょっと改良してみよう テストケース記述 その2
こんな疑問ありませんか? • たまたま条件が3つだから「大中小」に当 てはまるけれど、条件が4種類以上だった らどうしよう? • 仕様変更でディシジョンテーブルが変わっ た場合、毎回テストケースを修正して行く のは無駄なのでは? •
ディシジョンテーブルだとロジックが見える が、ケースにしたとたん見えにくくなる。い いのかな?
• 割り当てられたパラメータ・バリューをもとに、手順書を書き 起こすのは無駄なのでは? • 大項目・中項目・小項目が、ディシジョンテーブル毎に全く別 の意味になるがこれでいいのか?関連するテストケースで フィルタする場合に使えない。 ◦ 大項目・中項目・小項目の順番もそろえないと集約でき ない。
• などなど その他にも
単一フォーマットのスプレッドシートです べてを押し込めようとすること 何が原因か?
基本的には以下が主な理由 (のはず) • ケース全体の一覧性の確保 • 実行および結果の管理 この目的を満たしたうえでよりよい記法を考える。 なぜ表にケースを書くのか
こんな感じに書く 実施内容などは参照先のURLをそのまま書いてしまう。 (対象機能、分類はテストケースの整理方法によって変更) 自分なりの結論
• テストのパターン詳細はディシジョンテーブル、N-Wise、状 態遷移のスイッチカバレッジ表 へ任せる。 • テストケース表は上記の表へのリンクを張った上で、表の番 号の実行を書く。 • 実行結果は一覧表に記載する。 自分なりの結論
続き
• 基本的にテストはなんらかのパターン、組み合わせで行わ れる。画面ベースでは考えない。VSTePなどのテスト分析を きちんと行う。 • テスト設計技法を適切に選びきちんと使う。 • テスト対象の操作方法については実行者が理解している。 とはいえ複雑・わかりにくい場合は備考などで補足する。 自分なりの結論
前提
• テスト設計技法を学んだうえできちんと使いこなしましょう。 これが大前提。 • 単一表にすべてを押し込めることには無理がある。なので 無理しないで分けましょう。 おわり