ユニットテストの先へ：テスト技法で要求・仕様を整理するJava開発実践 / Beyond_Unit_Testing_Practical_Java_Development_Techniques_for_Organizing_Requirements_and_Specifications

JJUG CCC 2026 Spring ユニットテストの先へ：テスト技法で要求・仕様を整理するJava開発実践

Transcript

1. ユニットテストの先へ テスト技法で要求・仕様を整理するJava開発実践 2026/05/30 JJUG CCC 2026 Spring @shimashima35
2. 2 自己紹介 @shimashima35 • リーガルテック企業でQA/SET • Javaエンジニア → QA/SET → QA/SET/Javaエンジ ニア • 「エキスパートが教えるSelenium最前線」を共著 • JSTQB-Advanced Level Test Analyst および Test Manager 保有 • 2012年からJaSST Tokyo実行委員 • 2019年 Selenium Conf Tokyo 実行委員 • 2025年からテスト設計コンテスト実行委員
3. 発表にあたっての注意事項 • この発表はshimashima35個人の意見です。所属する組織 団体とは関係ありません。傾向として話が中心で個別具体 的にこれを違う事例はあるかと思いますがご承知ください。 • 発表内容をすべて実務で使ったわけではないのでそこはご 了承さください。 3
4. 皆さんに質問です。挙手をしてください。 1. テスト技法を知っている方 2. テスト技法を使っている方 3. 正常な値・ちょうど境界の値・範囲外の値、それぞれでテス トケースを書いたことがある方 始まる前に質問です 4
5. 思ったほど手が上がらないかな？ でも皆さん、実は意識していなくても使っていることが多いで す。 おや？ 5
6. こんな感じのコードがある場合のテストコードを考える。 /** * 引数のスコアの値が、有効な値(0 ~ 100) であること確認する。 * @param score スコア * @return 有効な値の場合true */ public boolean isValidScore(int score) { // 実装は省略 } 例題 6
7. score の値に着目して、以下のようなパターンを考えるのは結構 あるのでは。 1. 0 (true) 2. 100 (true) 3. -1 (false) 4. 101 (false) ※ テストエンジニアだと、(-1, 0, 100, 101) とすることが多いかも しれない。 回答例 7
8. • なぜこの4つで足りているのか？ • なぜ 0 ~ 100 を全て試さなくていいのか？ ◦ 50 や 60 はいらない？ • なぜ負数は -1 だけでいいのか？ 皆さんに質問です 8
9. 皆さんが普段ユニットテストを書いている際にも実はテスト技法 を気づかないうちに使っています。 そのテスト技法を使うことで4ケースで済むのです。 ここで使った技法は以下の2つです。 • 同値分割 • 境界値分析 テスト技法の力 9
10. 入力値を「同じ扱いをするグループ（同値クラス）」に分ける技 法。グループ内の値はどれを選んでも結果が同じになるため、 代表値1つでテストできる。 • 有効同値クラス：0〜100 • 無効同値クラス：0未満、100超 同値分割 10
11. 同値クラスの境界付近に着目する技法。バグは境界で起きや すいため、境界の値を重点的にテストする。 • 境界値 0 と 100 • その外側 -1 と 101 境界値分析 11
12. • みなさん気が付いていないだけで、テスト技法は日常的に 使っています。 • テスト技法を使うことで、意図を持ってテストケースを選べる ようになります。 ここまでのおさらい 12
13. そもそもなんでテストするんだっけ？ 品質の基礎、品質の経済学 13
14. そもそもなぜテストをするのか？ (品質の話をすると長くなるので端的にいうと) • 利用する人に手間をかけない。 ◦ 最終的な製品のテストならば、最終的なユーザー ◦ JavaのClass/Methodならばその利用者(別のプログラマ) 14
15. • 早い段階で不具合を見つけるほど手戻りが少ない ◦ 古くはBarry Boehmなど。感覚的にもあっているのでは。 • Quality Is Free (Philip B. Crosby) ◦ 品質への投資は、それ以上のリターンがある。そのため “実質無料”。 品質の経済学 15
16. テスト技法の基礎をみんなで学ぼう！ テスト技法の基礎 16
17. テスト条件の定義、テストケースの設計、およびテストデータの 明確化をするための手続き。 (ISTQB Glossary) 実質無制限のテストの中から、意義のあるケースを選択する際 に利用する体系的な手法。 テスト技法とは 17
18. 主要なテスト技法は以下のようなもの。 • 同値分割 • 境界値分析 • ディシジョンテーブル • 状態遷移 • クラシフィケーションツリー • N-Wise など テスト技法とは 続き 18
19. ここはでは技法の使い方について詳細な説明は行いません。 ただ、最初に触れたように実はみなさん知らずに使っていること もあります。 テスト技法の中には要求や仕様を整理することにも使えるもの があります。次で説明していきます。 テスト技法 つづき2 19
20. テスト技法はテストのためだけじゃない テスト技法の要求・仕様整理への活用 20
21. ある架空の仕様の説明 ここからは、ある会員制サイトの会員登録、退会、ログイン周り についての架空の仕様をもとに説明していきます。 21
22. 仕様 3.1 ログイン ユーザーはメールアドレスとパスワードを入力してログインを行う。入力されたパス ワードが正しい場合はログインを許可する。 ログインに失敗した場合、失敗回数をカウントする。3回を超えた場合、アカウントは ロック状態となりログインができなくなる。 3.2 アカウントの認証 新規登録が完了したアカウントは未認証状態となる。登録時に送付される認証メー ルのリンクをクリックすることで有効状態へ移行する。認証メールには有効期限があ り、期限を過ぎた場合はアカウントが削除される。 22
23. 3.3 アカウントの有効期限 アカウントには有効期限が設定されており、有効期限を過ぎた場合はログインができ なくなる。 3.4 退会 ユーザーは退会申請を行うことができる。退会済のアカウントはログインができない。 仕様 続き 23
24. みなさん、仕様理解できました？もちろん、ここでみただけで直 ぐに理解するのは難しいですよね。 先ほどの仕様にはログインについてとユーザーの状態につい て記述されていました。 これをテスト技法を活用して図表で表現してみます。 仕様、理解できたかな？ 24
25. ログイン可否を技法を使い表現してみた。わかるよね？ ログイン仕様 ディシジョンテーブル 25
26. 図で表現するとこんな感じ。 ユーザー状態 状態遷移図 26
27. 表だとこんな感じ。左縦に現在の状態、上横にイベント、交点に 遷移先状態。網羅的に記載できて便利。 「?」の部分が文章の仕様では記載されていないところ。 ユーザー状態 状態遷移表 27
28. 文章で書かれているものよりわかりやすくなったのでは？ わかりやすくなったかな？ 28
29. テスト技法を用いて図表にすることで以下のような効果が得ら れる。 • あいまいさが減り、共通認識ができる。 • レビューがしやすくなる。 • 仕様の漏れに気が付きやすくなる。 • テストに使える。 テスト技法の効果 29
30. ディシジョンテーブル、実はIF文と構造は一緒。プログラマなら ばみんな書けるよ！ ディシジョンテーブルの書き方 30
31. • 「動作」部分に複数の観点を混ぜない。 ◦ ここでは「ログイン可否」だけに絞った。副作用として「アカウントロッ ク」もあるが、それは別に考える。 • 全パターンの組み合わせを行わない。 ◦ あくまでシンプルなロジックで実装した場合を考える。 ◦ とはいえ、慣れない場合は全パターン書いた上で「あり得ない」組み 合わせを消していく方法でも構わない。 上記2つはテストエンジニアでも気を付けること。 ディシジョンテーブルの注意点 31
32. UMLにおけるState Machine Diagramと考え方は基本的に一緒。 1. 状態を抽出する。 2. イベントを抽出する。 3. 状態 x イベント の遷移後の状態を考える。 状態遷移表と状態遷移図は同じものを別の書き方で書いたも の。仕様漏れを探す場合は表のほうがよい。 Web系だと、「状態」が明示されていない点は注意。 状態遷移図 (表)の書き方 32
33. G.M.ワインバーグ/D.C.ゴーズ著「要求仕様の探検学」で、 「Mary had a little lamb.」という文章を、どう読み取れるかためし た。 一番ひどい(?)ものは「メリーは騙されやすい株屋の小男を買収 した」となる。 「have」には「買収する」、「lamb」には「騙されやすい人、特に株 取引において」と辞書にあったのだ。 余談：自然言語の曖昧さについての例 33
34. テスト技法でユニットテストの保守性を上げよう テスト技法のユニットテストへの活用 34
35. ディシジョンテーブルをユニットテストへ適用してみましょう。 ディシジョンテーブルのテストへの適用 35
36. ログインの実装は こんな感じ。これに ユニットテストを書く 時どう考えるか。 ログインをコードで書いてみる 36
37. 先ほどの実装と以下は等価。 ディシジョンテーブルを思い出す 37
38. ParameterizedTestを利用するとそのままかける。 ディシジョンテーブル通りのテストを実装する 38
39. • 省略します。 • ディシジョンテーブルと比較して、ユニットテスト実装時の旨 みが少ない。 • 状態遷移はどちらかというと未定義の仕様を見つけることの 方が重要。 • あと、状態遷移の実装方法が多種多様。DBの状態ベースだ とState Patternで表現しにくいし。 状態遷移のユニットテストへの適用 39
40. ディシジョンテーブルをベースにしてパラメタライズドテストを実 装することで以下の効果が得られます。 • テスト名にルールを書くことで、テスト結果一覧がそのまま 仕様の一覧になる • 「なぜこのテストケースがあるのか」がテーブルを見ればわ かる • 条件が増えたとき、テーブルを更新すれば変更すべき箇所 が明確になる ユニットテストの保守性・可読性 40
41. • こんなに綺麗に仕様から実装ができることは少ない。 • そんな時でも、メソッドの振る舞いをディシジョンテーブルな どで整理するとテストケースの抜け漏れを防ぎ、何をテスト すべきかが明確になる。 まずは仕様の整理 とはいえ…… 41
42. • テスト技法はテストだけでなく、仕様の整理にも使える • 図表にすることで、曖昧さが減り・仕様の漏れに気づき・ チームの共通認識が作れる • テスト技法はテストエンジニアだけのものではない まとめ 42
43. ClaudeにFAQをつくってもらったので幾つか取り上げて回答して いきます。 43 FAQ
44. Q. テスト技法を学ぶための良い参考書は？ A. ソフトウェアテスト技法ドリル【第2版】、ソフトウェアテスト技法 練習帳 をおすすめします。 Q. ディシジョンテーブルや状態遷移表はどのツールで書くのが 良いか？ A. 社内標準のスプレッドシートでも十分。ツールを導入可能なら ば、GIHOZもおすすめ。 44 FAQ
45. Q. チームに導入するのはどこから始めるのが良い？ A. まずは自分が作ろうとしているものを技法を使って表現して みるのがおすすめ。「つまりこういうことですよね？」といって実 物を見せちゃう。 Q.チームメンバーがテスト技法を知らない場合どうする？ A. 技法を知らなくても成果物は大体読めるはず。読めない場合 は読み方を伝えましょう。 45 FAQ
46. Claude に「クソリプ」FAQをつくってもらいました。なお模範解答も Claudeにお願いしました。 46 FAQ
47. Q. 今時AIにテストケース生成させればよくないですか？ A. AIはテストコードを書けます。でも「そのテストで十分か」を 我々が判断できなければなりません。そのためにテスト技法が あるのです。 47 FAQ
48. Q. 仕様書がない現場ではどうするんですか？ A. 仕様書がないからこそ、テスト技法を使って整理する価値が あります。まず自分の担当するクラス一つからで十分です。 48 FAQ
49. Q. スタートアップだと仕様が毎日変わるんですけど A. 仕様が変わるからこそ、現時点の仕様を図表で整理しておく 価値があります。変更があったときにディシジョンテーブルや状 態遷移表を更新すれば、何が変わったのかがチームで共有し やすくなります。 49 FAQ
50. Q. これってTDDで解決しませんか？ A. TDDはテストを先に書くことで設計を進める手法です。そのテ ストを書く前に「何をテストするか」をどう決めるのでしょうか。そ の整理にテスト技法が使えます。 TDDとテスト技法は対立するものではなく、組み合わせるもので す。 50 FAQ
51. Q.テストエンジニアに任せればいいのでは？ A. Class/Methodの振る舞いを一番よく知っているのは実装者で あるあなたです。その仕様を整理する道具として技法を使いま しょう。 51 FAQ
52. Q. 状態遷移のユニットテストはどう書く？ A. 「状態」と「イベント」を実装上どのように表現しているか次第 になる。基本的に遷移元状態にイベントを発火したら遷移後状 態になるか、をテストすることになる。 また状態遷移テストを厳密にいうとNスイッチカバレッジを意識 することになる。が、いわゆるデベロッパーテストではそこまで 考えてなくても基本的には大丈夫。 52 FAQ
53. Q. ディシジョンテーブルの条件が多い場合は？ A. 以下の原因が考えられます。 期待する動作とは関係ない条件が紛れている。 期待する動作が1つに絞りきれていない 複数のディシジョンテーブルに分割できないか検討してみてくだ さい。 53 FAQ