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
複数条件が関わるお題を用いてテスト設計から自動テストのケース作成まで考えてみたの #jasst...
Search
nihonbuson
December 21, 2021
Technology
1
5.1k
複数条件が関わるお題を用いてテスト設計から自動テストのケース作成まで考えてみたの #jasstnano / Test involving multiple conditions
nihonbuson
December 21, 2021
Tweet
Share
More Decks by nihonbuson
See All by nihonbuson
品質管理の歴史学 / Quality Management History
nihonbuson
2
58
境界値分析
nihonbuson
2
64
振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること #stac2024 / BDD formulation
nihonbuson
5
1.8k
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
1.1k
忠実度という概念と開発手法 / Fidelity
nihonbuson
1
91
WACATE流 勉強会会場の選び方 / WACATE venue
nihonbuson
1
640
継続的テストモデルを実現するためにスリーアミーゴスを用いた10Xでのシフトレフトの事例
nihonbuson
3
1.6k
BDD(Cucumber)コミュニティが無料提供しているコンテンツの紹介と現在起きている危機
nihonbuson
4
4.8k
JSTQB FL 幻のテスト技法「ユースケーステスト」を学ぶ / Use_case_testing
nihonbuson
5
2.7k
Other Decks in Technology
See All in Technology
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
18
5.6k
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
300
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
180
終了の危機にあった15年続くWebサービスを全力で存続させる - phpcon2024
yositosi
27
23k
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
550
5分でわかるDuckDB
chanyou0311
10
3.3k
能動的ドメイン名ライフサイクル管理のすゝめ / Practice on Active Domain Name Lifecycle Management
nttcom
0
250
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
euglena1215
9
3.6k
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
150
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
460
多領域インシデントマネジメントへの挑戦:ハードウェアとソフトウェアの融合が生む課題/Challenge to multidisciplinary incident management: Issues created by the fusion of hardware and software
bitkey
PRO
2
120
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.9k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
How STYLIGHT went responsive
nonsquared
96
5.2k
Embracing the Ebb and Flow
colly
84
4.5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Faster Mobile Websites
deanohume
305
30k
Optimising Largest Contentful Paint
csswizardry
33
3k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
Transcript
複数条件が関わるお題を用いて テスト設計から 自動テストのケース作成まで 考えてみたの ブロッコリー (@nihonbuson)
はじめに:本日のお題 下記の画像は座席順番待ちシステムの入力画面です。 この店では、大人と子供合わせて最大4名まで予約できます。 氏名は10文字まで入力可能であり、入力必須です。 この入力画面を用いて、 順番待ちの登録ができるかどうかのテストを考えてください。
今回の発表の楽しみ方 • 最初に問題を提示するので、 それをお手元で解いた上で参加すると楽しめます • WACATE 2021冬に参加した方は、 「デシジョンテーブルで振る舞いを整理しよう」の セッションを思い出しつつ参加すると楽しめます
自己紹介 • 風間裕也(ブロッコリー) • @nihonbuson • 社外活動 ◦ JaSST Review実行委員長
◦ WACATE実行委員 • 執筆活動 ◦ 『テストコードの注入から始める レガシーコードのリファクタリング』 ◦ 『Agile Testing Condensed』翻訳 ◦ 『Testing in DevOps』翻訳
アジェンダ • 今回のお題発表 • 愚直にデシジョンテーブルを書く • デシジョンテーブルを簡単化する • テストプロセスを踏まえて今回のお題を解く •
別のテスト技法を用いて考える • テスト設計の成果物を元にテスト実装を行う • PICTを用いて解いてみる • 自動テストへの適用を考える
アジェンダ • 今回のお題発表 • 愚直にデシジョンテーブルを書く • デシジョンテーブルを簡単化する • テストプロセスを踏まえて今回のお題を解く •
別のテスト技法を用いて考える • テスト設計の成果物を元にテスト実装を行う • PICTを用いて解いてみる • 自動テストへの適用を考える 時間の許す限り話す 最低ここまで話す
45分以上喋っちゃうかも?
注意点 • 今回の発表は発表者個人のやり方・考えを 述べたものです。 • お題に対して「これが正解」という話ではありません ◦ 「私が考えたやり方がより良い!」という 意見がありましたら、ぜひ教えてください! •
今回の発表を行うにあたり、JSTQB、JISなどを参考に したものの、表記ルールはそれらに沿っていません。
今回のお題
お題 下記の画像は座席順番待ちシステムの入力画面です。 この店では、大人と子供合わせて最大4名まで予約できます。 氏名は10文字まで入力可能であり、入力必須です。 この入力画面を用いて、 順番待ちの登録ができるかどうかのテストを考えてください。
解法の方針
解法の方針 • 順番待ちの登録(予約)ができるかどうかについては、 入力値の条件の組み合わせパターンを考えた方が良さそう • そこで、デシジョンテーブルを使って 組み合わせパターンを洗い出すことにした
因子水準を考える
因子水準を考える
愚直に全組み合わせの デシジョンテーブル を書く
条件と期待値を記述する
全組み合わせを書こうとする ※今回は、同一因子内の 各水準が排他関係 である前提で 適用したい条件は"◯" 適用しない条件は空欄 で表記しています。
全組み合わせを書こうとする (名前)×(大人の人数)×(子供の人数)×(印刷) = 3×5×5×2 =150通り
予約番号の印刷を 任意にする
予約番号の印刷は結果に影響しない(無則) 今回、 テストしたい内容は 「順番待ちの登録」 ができるかどうか なので、 予約番号の印刷は スコープ外として 考える。 →「-」と表記
予約番号の印刷は結果に影響しない(無則) 今回、 テストしたい内容は 「順番待ちの登録」 ができるかどうか なので、 予約番号の印刷は スコープ外として 考える。 →「-」と表記
予約番号を任意にして書いてみる (名前)×(大人の人数)×(子供の人数)×(印刷) = 3×5×5×1 =75通り
予約番号の印刷の因子を外す 予約番号の印刷は 今回の デシジョンテーブル の因子から外した。
名前の因子と人数の因子 を別表にする
それぞれで因子水準を分けて書いてみる 名前と人数の組み合わせで予約できるかを 網羅的に確認する必要が無さそうなので、 それぞれで因子水準表を分けて記述する
別々にデシジョンテーブルを書いてみる (名前)+(大人の人数)×(子供の人数) = 3+5×5 =28通り ※↑は、もはや デシジョンテーブルでは ないですが…
あれ?ちょっと待って! ここで書いた表はそれぞれ単体の条件で エラーメッセージが出るか確認する表です。 両方ともエラーの場合は別の表にした方が良さそうです。 それだと、 人数も名前も適切じゃない時に、 きちんと両方とも エラーメッセージが出るか 確認してないじゃないか!
両方とも無効なテストは別にして考える
両方とも無効なテストは別にして考える
両方とも無効なテストは別にして考える
両方とも無効なテストは別にして考える 別のテスト
同値クラスを整理する
当然のように書いていたけど… 各文字数ごとに 水準を分けても 記述できる。 そうしなかったのは 「1文字〜10文字」を 有効同値クラス として捉えたため。 (同値分割法)
人数の同値クラスを考える 1名〜3名を同値クラスとして捉えた。
デシジョンテーブルを書いてみる (大人の人数)×(子供の人数) = 3×3 =9通り となった。
デシジョンテーブルを書いてみる (大人の人数)×(子供の人数) = 3×3 =9通り となった。 ただし、?が出てきてしまった… 例えば、 ・大人1名、子供1名…◯ ・大人3名、子供2名…×
合計人数という因子を加えてみる 合計人数が予約可否の 判断に関わるので、 合計人数を因子として 加えて表現する。
合計人数の因子も含めたデシジョンテーブル 実施不可能なもの(禁則)の期待値には N/A(Not Applicable、適用不可)と表記する 例)大人の人数が0名、子供の人数が0名で、 合計人数が1〜3名の設定はできない
N/Aの部分(禁則)を省略する N/Aの部分は自明なので、省略して記述する。
デシジョンテーブル見比べると… ?の部分が、 2つのケースに 分かれて 表現された
ここまでの まとめ
ここまでのまとめ • 愚直に全て書き出すと150通り • 予約番号の印刷は予約登録の期待結果に 影響しないため、因子から除外(150→75通り) • 名前の因子と人数の因子を別々に考える (3×5×5=75→3+5×5=28通り) •
人数の同値クラスを考える ◦ 合計人数という因子も含めてみる (28→3+10=13通り)
それぞれの デシジョンテーブル における テスト観点図を考える
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する 参考:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 テスト手順 作成 自動テスト スクリプト作成 デシジョン テーブル作成
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
デシジョン テーブル作成 テスト手順 作成 自動テスト スクリプト作成 テスト 観点図作成
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル作成 テスト手順 作成 自動テスト スクリプト作成
初期のテスト観点
初期のテスト観点 (名前)×(大人の人数)×(子供の人数)×(印刷) = 3×5×5×2 =150通り
無則な観点を削る
無則な観点を削る (名前)×(大人の人数)×(子供の人数)×(印刷) = 3×5×5×1 =75通り
名前と人数で条件を別々にまとめた場合
名前と人数で条件を別々にまとめた場合 (名前)+(大人の人数)×(子供の人数) = 3+5×5 =28通り ※↑は、もはや デシジョンテーブルでは ないですが…
合計人数の条件を含めた場合
人数の同値クラスと合計人数で考える (名前のテスト)+(人数のテスト)= 3+10 =13通り
150通り 75通り
3+25通り 3+10通り
別のテスト技法を 用いて考える
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル作成 テスト手順 作成 自動テスト スクリプト作成
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル作成 テスト手順 作成 自動テスト スクリプト作成 別のテスト 設計技法
ドメイン分析で考える x+y≦4 y≦4 x≦4 x≧0 y≧0 x+y≧1 赤色の部分が、予約できる範囲
ドメイン分析で考える y≦4 x≦4 x≧0 y≧0 ONポイント OFFポイント OFFポイント(テスト不可) x+y≦4 x+y≧1
【注意】ドメイン分析技法は応用です
テスト設計の 成果物を元に テスト実装を行う
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル作成 テスト手順 作成 自動テスト スクリプト作成 別のテスト 設計技法
名前についてのテスト設計成果物
名前についてのテスト実装の例
テスト設計とテスト実装の関係性
テスト設計とテスト実装が1:1とは限らない
テスト設計とテスト実装が1:1とは限らない
実装実施時要検討事項の存在 テスト設計に出てこない条件 =実装実施時要検討事項
実装実施時要検討事項の出所
実装実施時要検討事項を考慮しないと… 出てくるパラメータを 全てテスト条件として、組み合わせを考えよう! →全組み合わせ(今回の場合150通りのテストパターン) が出てきてしまう
各テスト設計のテスト条件との関係性
PICTを用いて ペアワイズテストを 書いてみる
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル テスト手順 作成 自動テスト スクリプト作成 ドメイン分析 技法
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル テスト手順 作成 自動テスト スクリプト作成 ドメイン分析 技法 PICTを用いた ペアワイズテスト法
PICTでテストパターンを書き出す 150通り→25通りになった!
PICTで作成したテストパターンだと… 予約可能パターンのうち、 #1, #15, #16 は予約できず #20は予約できた。 (#1, #15, #16が期待値通り
にならない不具合) 不具合の原因はどこ?
自動テストの 理解容易性にも 影響する
テスト実行するまでの過程 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テストプロセス(JSTQBより)
テスト 観点図作成 デシジョン テーブル テスト手順 作成 自動テスト スクリプト作成 ドメイン分析 技法 PICTを用いた ペアワイズテスト
PICTで作成したテストパターンだと… 予約可能パターンのうち、 #1, #15, #16 は予約できず #20は予約できた。 (#1, #15, #16が期待値通り
にならない不具合) 不具合の原因はどこ?
PICTの場合でテスト実行
そもそも今回のお題でPICTを使うのはNG 詳しくはブログに書いてます。 「全網羅テスト」という言葉について 〜または、ペアワイズ法、直交表、PICT活用時の落とし穴〜 #テストアドカレ https://nihonbuson.hatenadiary.jp/entry/AllCoverageTrap
【注意】ペアワイズテストは応用です ペアワイズ テスト 直交表など
デシジョンテーブルで作成したテストパターン
デシジョンテーブルの場合でテスト実行
おわりに
まとめ • テスト観点で整理すると、 適切な因子水準を考えることができる • 直接組み合わせる必要がないものは、 別々のデシジョンテーブルにすることで、 テストパターンが掛け算ではなく足し算になる • 複数の因子の組み合わせで別の因子が出てくる場合、
ドメイン分析が活用できる • テスト実装の際は、テスト設計の成果物で理解した 必要な情報のみを記載する • 適切なテスト設計は自動テストの理解容易性も高まる
アドベントカレンダーの記事にします! • 今回のお題発表 • 愚直にデシジョンテーブルを書く • デシジョンテーブルを簡単化する • テストプロセスを踏まえて今回のお題を解く •
別のテスト技法を用いて考える • テスト設計の成果物を元にテスト実装を行う • PICTを用いて解いてみる • 自動テストへの適用を考える ソフトウェアテスト Advent Calendar22日目 自動テスト・テスト自動化 Advent Calendar 24日目
ちゃんとした書き方を知りたい人はこちら https://speakerdeck.com/imtnd/analyze-the-behavior-with-decision-table
おしまい