QA・ソフトウェアテスト研修【MIXI 26新卒技術研修】

本スライドは、MIXIの2026年度新卒向け技術研修で使用された資料です。
　
MIXI 2026新卒技術研修
『QA・ソフトウェアテスト研修』
　
───────────────────────────────
※皆様へのお願い※ 資料・動画・リポジトリのご利用について
───────────────────────────────
公開している資料や動画は、是非、勉強会や社内の研修などにご自由にお使いいただければと思いますが、以下のような場でのご利用はご遠慮ください。
- 受講者から参加費や授業料など金銭を集めるような場での利用
（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用

Transcript

1. QAとは & ソフトウェアテスト⼊⾨ 開発本部たんぽぽ室QAGマネージャー 松⾕峰⽣ ©MIXI
2. ⾃⼰紹介 名前 : 松谷峰生 (まつやみねお) 部署 : 開発本部たんぽぽ室QAG モケイ部 に入っています。 興味あったら声をかけてください笑 社外活動 • JaSST(ソフトウェアテストシンポジウム)九州元実行委員長 • ASTER(ソフトウェアテスト技術振興協会)教育事業メンバー • AIプロダクト品質保証ガイドラインVUI領域執筆(だいぶ昔だ…) ©MIXI 2
3. ⾃⼰紹介 • • • ©MIXI マンガ家！ ◦ 新人さんからわかるソフトウェアテスト解説マンガ 「テスターちゃん」 ◦ なにそれ？あなたの知らないテストの言葉 ◦ マンガではじめるMagicPod入門 ペットはフクロモモンガ GWは小説執筆にトライしていました(笑) 3
4. 最初に AI時代に突入しました。 AIによって実現手段は変わる でしょう。 ですが 実現したい事、根本、考え方は変わりません。 みなさんには今日 その部分を学び持って帰って いただきたいです。 ©MIXI 4
5. ⽬次 • • • • • • ©MIXI QA(品質保証)って？ 休憩 (5分) ソフトウェアテスト入門 ◦ テストの重要性 ◦ テストの考え方 ◦ テストレベルという考え方 休憩 (5分) テスト技法 ◦ 同値分割法 ◦ 境界値分析 ◦ デシジョンテーブルテスト ◦ 組み合わせテスト（ペアワイズ法） ◦ 状態遷移テスト おすすめ書籍 5
6. QA(品質保証)って？ ©MIXI
7. この項⽬でのゴール QAとは どういった活動を指しているか イメージできること 自分は作るだけ。後は任せた という状態に ならないこと ©MIXI 7
8. QA(品質保証)って？ QA (Quality Assurance) 品質保証 ©MIXI 8
9. QA(品質保証)って？ QAって テストすることでしょ？ ©MIXI 9
10. QA(品質保証)って？ QA=テスト という認識は少し違います ©MIXI 10
11. 品質ってなんだっけ？ ©MIXI
12. QA(品質保証)って？ 2分くらい みなさんが 好きなゲームやサービスを 思い浮かべてみてください。 どういったところが好きですか？ ©MIXI 12
13. QA(品質保証)って？ おそらく 「バグが見つからないから好き」 ではなかったかと思います。 何かしら「満足すること」 があったのではないでしょうか？ ©MIXI 13
14. 品質の定義の変遷 クロスビー (Philip B. Crosby) 品質とは、 要件に対する適合 である ワインバーグ (Gerald M. Weinberg) 品質は誰かにとっての価値 である 一般の工業プロダクトよりの定 義 ここでの価値は 「人々はその要求が満たされる なら、喜んで対価を払う」を意味 している 割とテスト業界では この定義が好きな人が多い (主観) ©MIXI 出典： ソフトウェア品質知識体系ガイド（ SQuBOK Guide V2） 14
15. 品質の定義の変遷 石川馨 (いしかわかおる) 「製品の品質」は 欧米の考えである「狭 義の質」 である。 一方「広義の質」は 仕事の質、サービス の質、情報の質、工程の質、部門の質、 人の質、システムの質、会社の質など、 これら全てを含めて捉える 。品質管理 は「広義の質」について管理することを 基本姿勢とする ©MIXI 出典： ソフトウェア品質知識体系ガイド（ SQuBOK Guide V2） プロダクトの質を「狭義の質」、 それを取り巻く全体を含めた質 を「広義の質」と定義 15
16. 品質の定義の変遷 保田勝通 (やすだかつゆき) 品質とは、 ユーザーにとっての価値 であ る 近代的な品質管理における品 質の定義。 品質はユーザーの満足度 であ る 出典： ソフトウェア品質保証の考え方と実際， 日科技連出版， 保田勝通著 ©MIXI 16
17. 品質保証って？ 品質保証 保証 = 間違いがない、大丈夫であると認め、責任をもつ こと。 出典：デジタル大辞泉（小学館） ©MIXI 17
18. 品質保証って？ なので品質保証 ちょっと言い換えると… ユーザーが満足できる ことを約束すること 松谷のオレオレ定義 ©MIXI 18
19. 品質保証って？ ユーザーが満足できる ことを約束すること プロダクト品質 ©MIXI その手段として プロダクト (アプリなど )に対して は テストやレビューというアプローチ がある! 19
20. 品質保証って？ そのプロダクトさえ テストでしっかり押さえていたら 満足度の高いものになる？ ©MIXI 20
21. 作り⽅‧やり⽅(プロセス)がイマイチだとイマイチなモノができる 毎回ボロボロのプ ロダクトが出来上が り、 ひたすらテストで打 ち返して 時間もコストも かかったり… 毎回同じバグ あるし! ©MIXI とりまバイブコーディングで リリースしまくってるけど … ユーザーの 要求の対応に とんでもなく 時間やコストが かかったり… 中身がスパゲティで 何が何やら！ 21
22. 品質保証って？ プロセスの質は プロダクトの質や サービスの質として現れる！ ©MIXI 22
23. 品質保証って？ ユーザーが満足できる ことを約束すること 作り方ややり方に対して は プロセスのカイゼン というアプローチ がある! 例えば、リリースごとに KPTで振り返 りを行い改善点を直すなど プロセス品質 (業務品質 ) カイゼン カイゼンを回す ことによって、より良いものを、 より良い状態で出すことができるようになってく る ©MIXI 23
24. 例えば… カイゼンはPJの課題の数だけあるけど、例えば… TDDでテストを 根付かせる 手作業のテストの自 動化 振り返り→ カイゼンのサ イクルを回す ©MIXI 仕様駆動開発 で進めてみる デプロイパイプラインの構築 コーティングルールの整 備 レビューの強化 24
25. 品質保証って？ プロセスが良ければ…！ もう一段上があります ©MIXI 25
26. 品質保証って？ ユーザーが満足できる ことを約束すること 言い換えると … ブランド ©MIXI 26
27. 品質保証って？ ユーザーが満足できる ことを約束すること ⚪⚪社のゲームだから 子どもでも楽しめるは ず！ 言い換えると … xx社のバッグだから 綺麗で丈夫なはず！ ブランド MIXIのものだから 面白いはず！ ©MIXI zz社の車だから 安全なはず！ 27
28. 品質保証って？ ユーザーが満足できる ことを約束すること 会社に対して は みんなで同じ方向を向けるようにポリ シーを策定したり、 品質文化を根付かせ るアプローチ がある 企業品質 会社として一定の品質のものを出せること により「 MIXIのものだから安心だし良いもの だ」という企業ブランドとなる ©MIXI 28
29. QA(品質保証)って？ ブランドは ひとつのプロダクトや1回のリリースで 成り立つものではなく 信頼の積み重ね で成り立つ ©MIXI 29
30. QA(品質保証)って？ 品質保証は 特定の人のがんばりではなく みんなで行っていく活動 (組織的な活動) 品質のことは xxさんに任せた！ 俺たちゃ作るだけ！知らん！ ではない ©MIXI 30
31. QA(品質保証)って？ QAって テストすればいいんでしょ？ テストすることだけが QAではない ©MIXI 31
32. まとめ的なページ ユーザーが満足できる ことを約束すること それを実現するために… プロダクトに対してはテストやレビューというアプローチ 作り方ややり方に対してはプロセスのカイゼンという アプローチ 会社に対しては品質文化を根付かせるアプローチ ©MIXI 出典 : テスターちゃん 2巻 32
33. QA(品質保証)って？ ここまで学んだように 品質保証活動は誰かに任せるのではなく みなさんも含めた 自分たちで意識して進めていく ことがとても大切です ©MIXI 33
34. QA(品質保証)って？ これから皆さんには 品質保証活動の中で 開発業務に一番近い 「ソフトウェアテスト」 についてお伝えします ©MIXI 34
35. 質疑応答 ©MIXI 35
36. 学んだことの整理の時間 5分休憩 & 学んだことを思い返して 整理しましょう。 (当てたりしないのでご安心を) ©MIXI 36
37. ソフトウェアテスト⼊⾨ ©MIXI
38. テストの重要性 ©MIXI
39. この項⽬でのゴール テストの 重要性について 感じて、理解すること ©MIXI 39
40. 不具合による事故例(Therac-25放射線事故) Therac-25は電子線/X線を使って癌を治療する放射線治療機でした。 ある日放射線技師は治療時に電子線の「E」キーの代わりにX線の「X」キーを押してしまいました。 間違いに気づき技師は8秒以内に「↑」キーを押してフィールドに戻り「E」キーを入力しなおしました。 そして照射したところ事故が発生してしまいました。 1回180ラドの線量のはずが、1万6000~2万5000ラドの線量が照射されてしまったのです。 原因 • 機能の問題 ◦ Xキーが入力されると Therac-25内部の磁石の位置が設定されるが、動作完了には 8秒かか る ◦ この間に照射モードが変更されると磁石位置を示すフラグが変わっておらず、モード変更のサ ブモジュールが正しく実行されずに過剰照射が発生する • UIの問題 ◦ 入力を受け付けない状態にあるとき、入力を待たせるような機能がないため入力できたと思っ てしまう ◦ 変更時に変更完了といったメッセージが出ないため、変更したと思ってしまう ◦ エラー時に「誤動作 54」と出たが、それが何を意味するエラーかどこにも書かれていなかった ©MIXI 40
41. 不具合による事故例(アリアン5型ロケット爆発事故) 1996年6月4日、フランス領ギアナの宇宙センターからヨーロッパ最新の無人サテライト発信ロケットが打ち上げられました。しかし、 打ち上げ後約40秒後に爆発してしまいました。 原因 • 固体ブースターの噴射口と主エンジンの噴射口を制御する Inertial Reference Systemに欠陥があり 正確な飛行姿勢が送られなかった。 ◦ 64bitの浮動小数点数を 16bit符号付整数に変換する際に、 32,768を超えてしまいエラーとなっ た。結果、主エンジンの噴射角度が最大になってしまった。 ◦ 変換失敗のエラー処理をしていなかった • HotStanbyの予備系統もあったが同じシステムが載っていたため、同じくエラーになって同時に落ち た 損失は 80億ドル。 ©MIXI 41
42. 動かないソフトウェアが引き起こす問題 経済的な損失 テストが重要な理由！ 時間の浪費 信用の失墜 テストにより、ソフトウェアの品質を 評価し、実際の環境でソフトウェア の問題が発生するリスクを低減 する 障害や死亡事故 ©MIXI 42
43. テストの考え⽅ ©MIXI
44. この項⽬でのゴール テストは 仕様通り動くかの動作チェック だけではないことを 理解していること ©MIXI 44
45. 1分で考えてみよう みなさんが 自分で作ったアプリやツールで (または使ったことがあるアプリやツールで) どんなバグがありましたか？ 思い出してみてください。 ©MIXI 45
46. テストの考え⽅ テストって 仕様通り動くか確認すれば いいんでしょ？ ©MIXI 46
47. テストで⾏うこと3選 仕様通り 実装通り 動作するかの 「チェッキング」 ©MIXI 新しい情報を 発見するための 要求にそったものが 作れているかの 「テスティング」 「妥当性確認」 47
48. 仕様通り/実装通り動作するかの「チェッキング」 答えがあって、それ通りになっているか照らし 合わせる活動 仕様通り 実装通り 動作するかの 「チェッキング」 言葉のまんまチェックする活動。よく世間で言わ れる「テスト」のイメージ。 テストの認識がこの活動範囲が全てだと思うと 「テストなんて簡単」の思考に陥る ©MIXI 48
49. チェッキングは⽤意された道を歩くようなもの この道はちゃんと歩けるな 仕様で決まっている道 岩 岩 仕様で決まっている道 岩 その道に石（バグ）があると 気付くことができる ©MIXI 仕様で決まっている道 仕様で決まっている道 その道の上でなくても、その道の 近くの石なら気づくことができる可 能性 その道から離れている石には気づ くことができない 49
50. その道を歩かないユーザーも多い！ 岩 我々が考えた道 (仕様通りの使い方 )ではないところ を歩いて、石 (バグ)にぶつかって怪我をする人もい る！ 仕様で決まっている道 実際には、我々が想定しない使い方、テストケースでは通らない使い方をして、 我々が気づかなかった大きなバグにぶつかるユーザーもいます。 仕様通り、実装通りかを確認するチェッキングだけではこういった問題が発 生します。 ©MIXI 50
51. テストで⾏うこと3選 新しい情報を 発見するための 「テスティング」 ©MIXI 51
52. 新しい情報を発⾒するための「テスティング」 新しい情報を 発見するための 新しい情報を探す活動 「テスティング」 「どこらへんに限界があるのかな？」「これどう なってるのかな？」など問いを立て確認する活 動 ©MIXI 52
53. テスティングは探検をするイメージ アプリやシステムの道なき道を探検して 「ここがこう動くなら、あそこはこうなっていない とダメなのでは !?」 のような新しい情報を見つける活動 みなさんも自作アプリを作った後に実際に使って みて「動作テスト」をしますよね。 そこで「あ〜こここうなってたほうがいいな」と微 調整したり、全く想定していなかった謎バグを見 つけて直しますよね。 ズバリそれです。 ©MIXI 53
54. テストとは マイヤーズ (Glenford J. Myers) テストとは、 エラーを見つけるつもりでプログラムを実行する 過程である 出典 : ソフトウェア・テストの技法 第2版 ©MIXI 54
55. バグを発⾒するための「テスト」 仕様通り動くかのチェックで バグ見つかるよね？ ©MIXI 55
56. 仕様通りの確認で仕様上のバグは⾒つけられるけど… 仕様に書いていない使い方 探索をしないと見つからない 岩 仕様に書いてある使い方 「仕様通り動くか」のチェッキングで、仕様という「大通り」にある バグは見つかる。 しかし、仕様に書かれていない様々な「小道」がある。 そこは確認 していないためバグが残っている。ユーザーは様々な使い方をす るため、本番でそのバグを踏むことになる。 ©MIXI 56
57. バグの多くは「忘れもの」 ・要件定義漏れ ・偉い人との認識齟齬 要求 要件 ・仕様漏れ ©MIXI ・設計の間違い ・影響箇所の把握漏れ ・PdMとの認識齟齬 仕様 設計 実装 自分が想定した 通り動くかの確 認で大丈夫？ ・実装の間違い ・実装の漏れ 57
58. 作ったシステムを触らない⼈が意外といる 何か実装した後 自分のシステムを触らない人が 意外といます ©MIXI 58
59. 考え⽅ひとつで⾏動が変わる！ ちゃんと動くか チェックしよう バグを見つけて やろう! ©MIXI 「正しい動作」にフォーカスす るため、一般的な操作に終 始しがち 「バグを見つける」にフォーカ スするためイレギュラーな操 作が増える 59
60. 仕様通りのチェックに加え、バグの探索をしよう 仕様通り動くかチェッ クしたけど… 本番でバグが出ないか 不安だァァーッ！！ 仕様通り動くかは チェックしたけどさぁ もうお分かりだろう!! バグを探そうとしていないのである !! 探そうとしていないものが本番で見つかるのは当たり前である!! 仕様通りのチェック + バグの探索の二つが揃って良いテストと なります。 ©MIXI 60
61. どうすればいいの？ これから学ぶ「テスト技法」を使う システムを触る時間をつくる 立ち止まって「忘れもの」はないか考える ©MIXI パターンの漏れに気づくこと ができる 「バグを見つけるつもり」で システムを触ってみる。 「ユーザーになったつもり」 でシステムを触ってみる。 実際に触ると見えてくるこ とも多い。 落ち着いて考えると、意外と 忘れている処理に気づく 61
62. テストで⾏うこと3選 要求にそったものが 作れているかの 「妥当性確認」 ©MIXI 62
63. 妥当性確認ってなに？ ゴージャスな チョコパフェが食べたい！ わかりました。 1週間後にまた来てくだ さい。 最高にゴージャスなチョ コパフェってやつを食べ させてあげますよ。 要求 ユーザー ©MIXI PdM 63
64. 妥当性確認ってなに？ ゴージャスなチョコパフェだな！ 仕様はこれだ！！ 舌触りの良い高級クリームをのせる 砂糖コーティングされたイチゴをのせる 高級チョコレートソースを上からかける 仕様 北海道産のバフンウニでクリームを囲む 仕様を考える PdM ©MIXI 内部はフレーク、イクラ、アイスの3層 64
65. 実装完了！仕様通り実装されているかの「チェッキング」 舌触りの良い高級クリームをのせる 開発版が完成したぞ！ 仕様通り実装されているか確認 しないとな 砂糖コーティングされたイチゴをのせる 高級チョコレートソースを上からかける 北海道産のバフンウニでクリームを囲む 内部はフレーク、イクラ、アイスの3層 ©MIXI 65
66. 仕様通り実装されているかの「チェッキング」 ©MIXI 舌触りの良い高級クリームをのせる 仕様通りのっていることを確認 砂糖コーティングされたイチゴをのせる 砂糖コーティングであることを確認 高級チョコレートソースを上からかける 仕様ではチョコソースだが、実物では醤 油がかかっている 修正しました！ 北海道産のバフンウニでクリームを囲む 仕様ではバフンウニだが、実物ではムラ サキウニであった 修正しました！ 内部はフレーク、イクラ、アイスの3層 仕様通りの順で 3層であることを確認 66
67. バグを発⾒するための「テスティング」 ©MIXI 舌触りの良い高級クリームをのせる Pass 砂糖コーティングされたイチゴをのせる Pass 高級チョコレートソースを上からかける Pass 北海道産のバフンウニでクリームを囲む Pass 内部はフレーク、イクラ、アイスの3層 Pass 仕様通りになっていることの チェックは済んだぞ！ 次はバグを探索しないとな！ 67
68. バグを発⾒するための「テスティング」 探索で重要なバグを見 つけちゃいました！！ よく見つけてくれました！ それはWebで24時間以内に食べてと Popupを 出す対応をします！ これで仕様にないところのバグ探索 の対応も終わった！ バグ票: 35℃環境下に48h放置後、最後 まで食べ進めるとお腹を壊す ©MIXI 68
69. 完成！ ゴージャスチョコパフェ feat. 海の幸 リリースです！ ユーザーの反応が楽しみですね！ ©MIXI 69
70. 結果… マズ… ©MIXI 70
71. 結果… 仕様通り実装されていて 動作に問題がないと確認をしても そもそものニーズを満たしていない、 要求を捉えられていない 場合もある ©MIXI 71
72. 妥当性確認とは 作業成果物がステークホルダーのニーズ に一致するか を、調査によって確認するこ と 出典 : ISTQB Glossary, V4.6.0 ©MIXI 72
73. どうすればいいの？例 例えば… ドッグフーディング ユーザーテスト A/Bテスト DAUなどのデータを追って分析 満足度調査等のアンケート ©MIXI 73
74. もう少し⾝近でできること 仕様や言われたことをただ鵜呑みに するのではなく 気になることがあったときは コミュニケーション をしましょう チョコパフェに海の幸って大丈夫でしたか？ ©MIXI 74
75. 余談 : AIを使えば良いのでは、に対する松⾕の考え 仕様通り 実装通り 動作するかの 「チェッキング」 AIを使ったチェックがしやす い場所。 ただし、機械的に確認しづら いところの制限はある。 ©MIXI 新しい情報を 発見するための 要求にそったものが 作れているかの 「テスティング」 「妥当性確認」 一般的な実装や設計周りの ミスは AIで対応可能。 ただし、一般的ではないドメ イン知識やコンテキスト漏れ はAIが気づけない 自分たちが作りたいものを 作れているかの確認は人間 の仕事！ 75
76. 1分で考えてみよう この章の冒頭で挙げてもらったバグは ・チェッキング ・テスティング ・妥当性確認 どの活動で見つかりそうですか？ ©MIXI 76
77. 質疑応答 ©MIXI 77
78. テストレベルという考え⽅ ©MIXI
79. この項⽬でのゴール テストレベルの概念を理解し、 今後テストを考える際に 意図したテストを どのテストレベルで行ったほうがいいか ある程度判断できる ©MIXI 79
80. テストレベルという考え⽅ テストといっても、コードで実行するテストも あれば、システムを実際に動かすテストも あるよね？ ©MIXI 80
81. テストレベル 系統的にまとめ、マネジメントしていく テスト活動のグループ 出典 : JSTQB Foundation Level Ver4.0.J02 ©MIXI 81
82. テストレベル コンポーネントテスト(ユニットテスト) コンポーネント統合テスト(結合テスト) システムテスト システム統合テスト 受け入れテスト ©MIXI 82
83. テストレベル(コンポーネントテスト) コンポーネントテスト (ユニットテスト ) コンポーネント : 独立してテストできる、システムの最小構成単位 出典 : ISTQB Glossary, V4.6.0 hoge(){ … … … … … } ©MIXI スタブ/ モック コンポーネントを単独でテストすることに 焦点を当てる。（いわゆるユニットテスト） 他のコンポーネントを呼び出すところは スタブなどを利用する。 主にロジックについてテストする。 83
84. テストレベル(コンポーネント統合テスト) コンポーネント統合テスト (結合テスト ) コンポーネント コンポーネント統合テスト（結合テスト）はコン ポーネント同士を連携させてテストを行う。 コンポーネント間のインターフェイス（接点）に フォーカスし、相互処理についてテストする。 コンポーネント ©MIXI 84
85. テストレベル(システムテスト) システムテスト システム ©MIXI コンポーネント コンポーネント コンポーネント コンポーネント システムテストはシステムにフォーカスし、振 る舞いや全体的な能力について テストを行 う。 85
86. テストレベル(システム統合テスト) システム統合テスト テスト対象システ ム ©MIXI コン ポーネ ント コン ポーネ ント コン ポーネ ント コン ポーネ ント 他システム システム統合テストは、テスト対象のシ ステムと他のシステムや外部サービス とのインターフェイスにフォーカス しテス トをする。 （例えば管理システムと連携など） 86
87. テストレベル(受け⼊れテスト) 受け入れテスト システム ©MIXI コン ポーネ ント コン ポーネ ント コン ポーネ ント コン ポーネ ント システムがユーザーのニーズを満たして いるかにフォーカスする。妥当性確認。 87
88. テストレベル ©MIXI コンポーネントテスト(ユニットテスト) 主にロジックのテストが目的 コンポーネント統合テスト(結合テスト) 主にコンポーネント間の相互処理のテ ストが目的 システムテスト 主にシステムを通しての振る舞い、全 体的な能力のテストが目的 システム統合テスト 主にシステム間の相互処理のテストが 目的 受け入れテスト 主にユーザーの要求を満たしているか の確認が目的 88
89. テストレベル テストにそういったわけ方があることはわ かったけど、それって何か役に立つの？ ©MIXI 89
90. テストレベルで考えるテストの最適化 テストの最適化が 考えられるようになる！ ©MIXI 90
91. 例えば… システム 入力データを送 るだけ Backend コンポーネント Front Frontも通したシス テムテスト で全パ ターンをチェックす るのに3日はかかり ます ここですごいパターン分 けのロジックがある 受け取ったデー タを整形して表 示 ©MIXI 91
92. 全てを「システムテスト」で確認でいい？ 例えばこんなテストのアプローチもできそう コンポーネントテスト データ送信のテスト目的 であ れば決められたフォーマットで データが送られているかテスト で良さそう Front コンポーネントテスト Backend ロジックを確認したいとい うテスト目的 であればコン ポーネントテストでよさそう コンポーネント ここですごいパターン分 けのロジックがある 表示を確認するテスト 目的であれば、データ を入れて見て表示確認 で良さそう コンポーネントテスト ©MIXI 92
93. 例えばこんなテストのアプローチもできそう 実際にデータのやり取りが できているか確認するテスト 目的なら全パターンで見なくて もどれかでテストすれば良さそ う Front コンポーネント統合テスト Backend コンポーネント ここですごいパターン分 けのロジックがある ©MIXI 93
94. 例えばこんなテストのアプローチもできそう Backend Front 全体の振る舞いを確認する テスト目的やターンアラウン ドタイムを知る目的 ならシス テム全体を通したテスト コンポーネント ここですごいパターン分 けのロジックがある システム ©MIXI システムを通して「何かバグ がないか」と探索するテスト 目的ならシステム全体を通し たテスト 94
95. テストレベルで考えるテストの最適化 そのテスト目的を達成するためには 本当にそのテストレベルでの テストが最適か 考えることが大切 ©MIXI 95
96. 余談 : AIを使えば良いのでは、に対する松⾕の考え ユニットテスト 結合テスト システムテスト システム統合テスト コードベースでのテストは AIが 強い。 ただし AIが書いたテスト群が 「妥当なテスト」であるかのレ ビュー、判断は必要 実際にシステムを動かすテス トは、AIがどこまで手を伸ば せるかでコストが変わる。 AIでシステムテストすべきか 下のレイヤーで担保すべきか 考えること (例 : Bluetoothでロボットの初 回セットアップと動作確認 ) ©MIXI 受け入れテスト 意図したものが意図した通り に出来上がっているかの受け 入れは人間の仕事 96
97. 質疑応答 ©MIXI 97
98. 学んだことの整理の時間 5分休憩 & 学んだことを思い返して 整理しましょう。 (当てたりしないのでご安心を) ©MIXI 98
99. テスト技法 ©MIXI
100. テスト技法 テスト技法 同値分割法 境界値分析 デシジョンテーブル テスト 組み合わせテスト 状態遷移テスト ユースケーステスト テストはなんでもかんでもテストしまくれば いいというわけではありません。 時間とお金の都合を考えて、 QCDF(Quality, Cost, Deliver,Feature) のバランスが取れたテストを行う 必要が あります。 そこでテスト技法です。 テスト技法は、比較的少ないながらも十 分なテストケースのセットを開発、つまり 効率的なテストを作成 する方法です。 今回の講義内容には入ってません ©MIXI ※ブラックボックステストの技法 100
101. AI時代においてテスト技法を学ぶ理由 AIが書いたテストが 妥当かどうか 判断できるようになるため ©MIXI 101
102. テスト技法 テスト技法については、一部 NPO法人ASTER(ソフトウェアテスト技術振興協会 )の 「ASTERセミナー標準テキスト」を利用しています。 全体を見たい人は以下です。（無料です） https://www.aster.or.jp/business/seminar_text.html ©MIXI 102
103. 同値分割法 テストケースを合理的に 少なくするための技法 ©MIXI
104. 同値分割法 ある特定のパーティションすべての要素がテスト対象によって同等に処理さ れることを想定して、データをパーティションに分割する。各パーティションに 対して1つの値をテストする。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version4.0.J02 （例）１けたの正の整数2個を足し算するプログラム ？ それぞれ「1」から「9」までの整数が入 力できるのであれば、「 1+1」から 「9+9」までの81通りのテストが必要 か？ ©MIXI クリア 計算 「１けたの正の整数」以外の 値も入力できてしまうので は？ 104
105. 同値分割の背景にある考え⽅ 同じ処理がされるはずの パーティション（グループ） 2 1 3 6 7 9 ©MIXI 同じパーティションの他の数字でも 同じ欠陥が見つかるはず 5 4 8 “3”で欠陥が見つかった 同値パーティション (同じ処理がされるであろうグループ）か らデータを一つ選んで問題があった場合、この問題は同じ パーティションの他のデータでも発生するはずだ、というも の 105
106. 同値分割法 • ある特定のパーティションすべての要素がテスト対象によって同等に処理さ れることを想定して、データをパーティションに分割する。 同値パーティション 無効パーティション 有効パーティション 無効パーティション （システムに拒否される値） （システムに受け入れられる値） （システムに拒否される値） 01 ©MIXI 9 10 106
107. 同値分割法 • 各パーティションに対して1つの値をテストする。 無駄なテストをなくし、テスト回数を削減できる。 無効パーティション 有効パーティション 無効パーティション （システムに拒否される値） （システムに受け入れられる値） （システムに拒否される値） 代表値：-5 ©MIXI 01 9 10 代表値：5 代表値：15 107
108. 同値分割法 • パーティションが識別できるのは入力だけではない。 – 出力、構成アイテム、内部値、時間関連の値、インターフェースパラメー ターなど （例） 2個の入力をともに「3」とした場合 3+3=6 表示位置が ずれるかも 1桁のときは「２桁めに０」が表 示されてしまうかも 答え（出力）は6 2個の入力をともに「5」とした場合 5 + 5 = 10 答えが1桁の場合と2桁の場合で 別々のパーティションとするなど。 答え（出力）は10 ©MIXI 108
109. 同値分割法 • パーティションは、連続/離散、順序性あり/なし、有限/無限のいずれでもよ い 離散的なパーティション例 (地域など) 青森県 北海道 京都府 ニュー ヨーク州 ワシントン州 イリノイ州 連続的なパーティション例 (数値など) <0.0℃ ©MIXI 0.0℃ 60.0℃ >60.0℃ 109
110. 同値分割法 • パーティションは、重複してはならず、空でない集合でなければならない 誤った同値分割の例 成人 （18歳以上） 高校生以下 どちらにも属する どちらにも属さない 16歳の社会人 ©MIXI 18歳の高校生 110
111. 境界値分析 バグを⾒つけるように 狙っていく技法 ©MIXI
112. 境界値分析 同値パーティションの境界を確認することに基づいた技法で、パーティションの最小値 および最大値を選んでテストする。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version4.0.J02 無効パーティション 有効パーティション 01 無効パーティションの最大値 有効パーティションの最小値 ©MIXI 無効パーティション 9 10 無効パーティションの最小値 有効パーティションの最大値 112
113. 境界値分析 • 境界に対する記述ミスや解釈ミスに起因する欠陥をピンポイントで狙う。 例）ソースコードでの不等号の実装ミス（「＞」と「＞＝」など） 例）仕様における境界に関する曖昧な記述 システム稼働時間 8:00～20:00 8:00、20:00は稼 システム停止時間 0:00～8:00、20:00～24:00 働？停止？ 例）アリアン5号のようなオーバーフロー • 狙う場所の例 ◦ 入力値の下限-1、下限、上限、上限+1 ◦ 配列の最大長、最大長+1 ◦ 条件式（等式・不等式）で指定された値、およびその前後の値 ©MIXI 113
114. 境界値分析 • 数値の範囲以外にも適用できる。 例）数値属性を持つ非数値変数（A3、B5といった用紙サイズなど） • ループ（ユースケース内のループを含む） • 格納されているデータ構造 例: その変数のメモリ確保の最大。最大値で問 • 物理オブジェクト（メモリを含む） 題がないか、最大値を超えた場合の処理等。 • 時間により判定される活動負荷の耐久性 例: この製品は60時間稼働できる。 60時間確かに稼働できるか、超えた場合は危 険にならないか等耐久性の確認 • 非機能欠陥を発見する。 例）負荷の耐久性 • システムは10,000人の同時ユーザーをサポートする。 ©MIXI 114
115. 境界値分析 (2値BVA) • 2値BVAは、その境界値と、隣接するパーティションの一番近い値を選ぶ方 法 • カバレッジ (%) ◦ 通過した境界値 / 識別したすべての境界値 * 100 無効パーティション 01 有効パーティション 無効パーティション 9 10 この例では、2値BVAの場合、境界値”1”と隣り合ったパーティションの最も近い境界値 ”0”、境界値”9”と隣り合った パーティションの最も近い境界値 ”10”の4つが境界値となる。 カバレッジは、 0と1の2つだけ確認したとき、識別したすべての境界値は 4つのため、以下となる。 2 / 4 * 100 = 50.0 = 50% ©MIXI 115
116. 境界値分析 (3値BVA) • 3値BVAは、その境界値と、両方の隣接値を選ぶ方法 • カバレッジ (%) ◦ 通過した境界値 / 識別したすべての境界値 * 100 無効パーティション 012 有効パーティション 無効パーティション 8 9 10 この例では、3値BVAの場合、境界値”1”と隣り合った値 ”0”と”2”、境界値”9”と隣り合った値 ”8”と”10”の計9つの値を 確認する。 カバレッジは、 0と1の2つだけ確認したとき、識別したすべての境界値は 9つのため、以下となる。 2 / 9 * 100 = 22.22… = 22.2% ©MIXI 116
117. 3値BVAは2値BVAで⾒逃す問題を拾える可能性 例えば、(age >= 20 )と書く所を (age == 20) と書いてし まったとしましょう。 2値BVAの場合(age=19, age=20) 期待結果はage=19の時False, age=20の時はTrueで す。 (age >= 20)でも(age == 20) でも、どちらでも期待結果 通りになりテストはPassします。 3値BVAの場合(age=19, age=20, age=21) (age == 20) としてしまっていた場合、age=21が期待結 果はTrueのはずなのにFalseが返ってくるためテストで 問題を発見できます。 実際にどこまでテストするかはプロダクトに応じて考えま しょう。 ©MIXI 出典 : 【連載】なにそれ？あなたの知らないテストの言葉（第 2回）： ミューテーションテスト(Mutation testing) 117
118. 質疑応答 ©MIXI 118
119. 演習 境界値分析 ©MIXI
120. 演習 : 境界値分析 (時間5分) • 以下のコードのテストを考えましょう。 ◦ short int型（16bit符号付き）の引数aがある。 ◦ モジュール内にはif (a<0) と if (7<a)という 2個の条件文がある。 • 同値パーティションを挙げましょう。 • 各同値パーティションの境界値を挙げましょう。 ©MIXI 120
121. 演習の解答例 境界値分析 ©MIXI
122. 演習の解答例 : 境界値分析 1. 同値パーティションは以下の5個 • -32769以下 • -32768以上、-1以下 • 0以上、7以下 • 8以上、32767以下 • 32768以上 2. 境界値は以下の8個 • -32769、-32768、-1、0、7、8、32767、32768 ©MIXI 122
123. デシジョンテーブルテスト テスト対象を漏れなく テストするための技法 ©MIXI
124. デシジョンテーブルテスト • ロジックを条件と動作に分けて、マトリクスで表現した表を デシジョンテーブル と呼 び、デシジョンテーブルをテスト設計に使用するテスト技法を デシジョンテーブル テストと呼ぶ。 例： 「満30歳以上」「年間 50万円以上購入」「指定地域在住」の会員は「特別会員」になる 条件 動作 ©MIXI ルール 1 2 3 4 5 6 7 8 満30才以上 T T T T F F F F 年間50万円以 上購入 T T F F T T F F 指定地域在住 T F T F T F T F 特別会員 X - - - - - - - 124
125. デシジョンテーブルテスト 考えられる条件の組合せを作るという点において、漏れや抜けがなくなる。 入力条件が複雑に（ANDやORで）絡み合う場合に有効 開発時の仕様整理にも使いやすい 条件の洗い出しが難しい 条件の数が多いとデシジョンテーブルの作成に時間がかかる ©MIXI 125
126. デシジョンテーブルの書き⽅ 例： ある映画館の座席予約システムがあります。 この映画館では水曜日は20%割引です。 また全曜日通して、22時以降は10%割引です。 割引が重なった場合は割引率が高い方が適用されます。 ©MIXI 126
127. デシジョンテーブルの書き⽅ 例： ある映画館の座席予約システムがあります。 この映画館では水曜日は20%割引です。 また全曜日通して、 22時以降は10%割引です。 割引が重なった場合は割引率が高い方が適用されます。 1 2 3 4 水曜日 時間 >= 22時 「～だったら」という 条件の部分！ ©MIXI 条件を抽出して記載する。 例の場合、「曜日 (水曜か否か)」と「時間（22時以上か否か）」が条件であるこ とがわかる。 127
128. デシジョンテーブルの書き⽅ 「どうなる」という 結果の部分！ 例： ある映画館の座席予約システムがあります。 この映画館では水曜日は20%割引です。 また全曜日通して、22時以降は10%割引です。 割引が重なった場合は割引率が高い方が適用されます。 1 2 3 4 水曜日 時間 >= 22時 20%割引 10% 割引 割引なし ©MIXI 動作を記載する。 仕様には明記されていない動作（いずれにも当てはまら ない）もあるので注意！ 128
129. デシジョンテーブルの書き⽅ 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 機械的に YとNを 並べる！ 20%割引 10% 割引 割引なし 条件の全組み合わせを記入する。 成り立つ場合はY(またはT)、成り立たない場合はN(またはF)。 ©MIXI 129
130. デシジョンテーブルの書き⽅ デシジョンテーブルは抜け漏れなくテストするための技法！ 一列ずつアレコレ考えないでYとNは機械的に並べてしまおう。 条件が増えるごとに 1,2,4,8,16…と倍々に増やしていけばいい。 Yを4つ Nを4つ 1 2 3 4 5 6 7 8 条件 〇〇〇 Y Y Y Y N N N N 条件 △△△ Y Y N N Y Y N N 条件 □□□ Y N Y N Y N Y N 動作 xxx Yを2つ 動作 yyy 動作 Nを2つ zzz Yを1つ ©MIXI Nを1つ 130
131. デシジョンテーブルの書き⽅ 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 X X - - 10% 割引 - - X - 割引なし - - - X 条件を見ながら考え て埋める必要がある 条件に対する結果を記入する。 当てはまる項目には「X」、当てはまらない項目には「-」を記載する。 ©MIXI 131
132. テストケースの書き⽅ ©MIXI 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 X X - - 10% 割引 - - X - 割引なし - - - X デシジョンテーブルの 1列 が、それぞれテスト項目 となる。 条件はテストケースの 「入力」に、動作はテスト ケースの「期待結果」とな る。 132
133. デシジョンテーブルの最⼩化 水曜日だった場合 時間は動作に 影響しない 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 X X - - 10% 割引 - - X - 割引なし - - - X 条件部分に出てくる「－」は任意の 意味。 （任意とは、YでもNでも動作は変わら ないということ。） ©MIXI 最小化 同じ動作になる共通条件を持つルールはま とめられる可能性がある。 1 2 3 水曜日 Y N N 時間 >= 22時 - Y N 20%割引 X - - 10% 割引 - X - 割引なし - - X 133
134. デシジョンテーブルの最⼩化 満30歳以上で 年間50万円以 上購入した指定 地域在住の会員 は、特別会員に なる 1 2 3 4 5 6 8 [条件] 満30歳以上 Y Y Y Y N N N N 年間50万円以上購入 Y Y N N Y Y N N 指定地域在住 Y N Y N Y N Y N X - - - - - - - [期待結果] 特別会員 満30歳以上でも 年間50万円購入してなければ 指定地域在住に動作が左右されない 満30歳未満なら 他の条件に動作が 左右されない 1 ※注意事項 条件の処理順が条件欄の記 載順と同一であること。 不明の場合は単純に最小化 できない。 ©MIXI 7 2 3 4 [条件] 満30歳以上 Y Y Y N 年間50万円以上購入 Y Y N － 指定地域在住 Y N － － X - - - 当初3・4 → 最小化後3 当初5・6・7・8→ 最小化後4 [期待結果] 特別会員 134
135. 質疑応答 ©MIXI 135
136. 演習 デシジョンテーブルテスト ©MIXI
137. 演習 : デシジョンテーブル (時間10分) • 「うるう年判定プログラム」の仕様は以下の通りである。 1. 西暦年数が4で割り切れる年は、うるう年である。 2. 西暦年数が4で割り切れる年のうち、100で割り切れる年の場合は、うるう年で はない（平年である）。 3. 2.のケースであっても、400で割り切れる年の場合はうるう年とする。 1. 2. ©MIXI 上記の仕様について、デシジョンテーブルを作成しましょう。 ①で作成したデシジョンテーブルの各規則（ルール）に対して、テスト実行時に用 いる具体的な入力値、期待結果を列挙しましょう。 137
138. 演習の解答例 デシジョンテーブルテスト ©MIXI
139. 演習解答例 : デシジョンテーブル • 全ての組合せを作成したのち、あり得ない組合せを削除する。 1 2 3 4 5 6 7 8 4で割り切れる Y Y Y Y N N N N 100で割り切れる Y Y N N Y Y N N 400で割り切れる Y N Y N Y N Y N うるう年 X - X - 平年 - X - X ありえない組合せを削除する ©MIXI 139
140. 演習解答例 : デシジョンテーブル 1 デシジョンテーブル ©MIXI 1 2 3 4 4で割り切れる Y Y Y N 100で割り切れる Y Y N N 400で割り切れる Y N N N うるう年 X - X - 平年 - X - X 140
141. 演習解答例 : デシジョンテーブル 2 デシジョンテーブルから作成されるテストケース ©MIXI No 入力値 期待結果 説明 1 2000 うるう年 4でも、100でも、400でも割り切れる 2 2100 平年 4でも、100でも割り切れるが、400で割り切れな い 3 2020 うるう年 4で割り切れるが、100と400では割り切れない 4 2019 平年 4でも、100でも、400でも割り切れない 141
142. 演習解答例 : デシジョンテーブル • プログラムにおけるうるう年の判定が以下のような順序で行われていたと する。 N 平年 4で 割り切れる N Y うるう年 100で 割り切れる N Y 400で 割り切れる Y ©MIXI 平年 うるう年 142
143. 演習解答例 : デシジョンテーブル • うるう年は4個の規則（ルール）で判定される。 N 平年 ③ ④ 4で 割り切れる N Y うるう年 ② 100で 割り切れる N Y 400で 割り切れる Y ©MIXI 平年 うるう年 ① 143
144. 組み合わせテスト テストケースを合理的に 少なくするための技法 ©MIXI
145. こんなときどうテストをしますか？ テストの時にそれぞれのパーツをテストして OKだった。しかしリリースしてみると帽子B と体Cの組み合わせの時にパーツに被りがあり表示が崩れの本番障害が発生！ 他も組み合わせてテストして確認しないといけなさそう！ あなたはどのようにテストをしますか？ 頭の装備 体の装備 ネックレス ブラウザ 帽子A 体A ネックレスA Chrome 帽子B 体B ネックレスB safari 帽子C 体C ネックレスC Firefox ネックレスD Edge 帽子D ©MIXI 145
146. こんなときどうテストをしますか？ 頭4通り x 体3通り x ネックレス 4通り x ブラウザ 4通り = 4x3x4x4= 192パターン !! ©MIXI 146
147. こんなときどうテストをしますか？パート2 特定のモードでa⚪ payの時だけ支払いができない本番障害が発生！ どうやら内部の 実装は複雑になっていそうだ。支払い周りをもう一度がっつりテストをしないといけなさそ うだ。 あなたはどのようにテストをしますか？ ©MIXI 支払い手段 支払期間 モード(状態) OS クレジットカード 月額払い モードA Android最低バージョン ド⚪モ払い 年払い モードB Android最新バージョン ソフ⚪バンク簡単決 済 モードC iOS最低バージョン a⚪ pay モードD iOS最新バージョン 147
148. こんなときどうテストをしますか？ 支払い手段 4通り x 支払い期間 2通り x モード4通り x OS4通り = 4 x 2 x 4 x 4= 128パターン !! ©MIXI 148
149. ペアワイズ法を使うと これが組み合わせテスト (ペアワイズ法 )を使うと … ©MIXI 149
150. ペアワイズ法を使うと 192パターンあったテストがなんと 18パターンに !! 頭の装備 体の装備 ネックレス ブラウザ 帽子A 体A ネックレスA Chrome 帽子B 体B ネックレスB safari 帽子C 体C ネックレスC Firefox ネックレスD Edge 帽子D ©MIXI 150
151. ペアワイズ法を使うと 128パターンあったテストがなんと 17パターンに !! 支払い手段 支払期 間 モード(状態) OS クレジットカード 月額払 い モードA Android最低バージョン ド⚪モ払い 年払い モードB Android最新バージョン ソフ⚪バンク簡単決済 モードC iOS最低バージョン a⚪ pay モードD iOS最新バージョン ©MIXI 151
152. 今回は「ペアワイズ法」の話をします 組み合わせテストにはペアワイズ法と直交表がありますが、今回はペアワイズ法 についてお伝えします。 ペアワイズ法 (オールペア法 ) 組み合わせテスト 直交表 ©MIXI 152
153. 疑問 どういう理屈で 組み合わせが 少なくなるの？ ©MIXI 153
154. 組み合わせのバグは、2つの要素までで多くを占める 以下の研究論文では、組み合わせのバグは 2つの要素の組み合わせまでで多くの割 合を占めている ことを明らかにしました。 “software failures in a variety of domains were caused by combinations of relatively few conditions.” "Software Fault Interactions and Implications for Software Testing," R. D. Kuhn et al, IEEE Transactions on Software Engineering, 30(6), 2004 要因数 医療用組み込み機器 ブラウザ Webサーバー データベース 1 66 29 42 68 2 31 3 2 19 19 5 4 1 2 7 2 97% 47 5 2 6 1 ©MIXI 76% 28 70% 25 93% ※論文内では累積 で表記 154
155. 「1因⼦ずつの場合のバグの発⾒率がρならそれに⽐較してほぼρの2乗に期待される」 これは田口玄一博士の著書「ロバスト設計のための機能性評価」より。 なんのこっちゃですが、何が言いたいかというと3因子間でのバグはかなり低確率になり ます。 1000行あたりのバグ発見率 200万行あたりのバグ件数 1因子 4/1000 = 0.4% 0.4×2000000 = 8000件 2因子間 (4/1000)^2 = 0.0016% 0.0016×2000000 = 32件 3因子間 (4/1000)^3 = 0.0000064% 0.0000064×2000000 = 0.128件 ©MIXI 155
156. ペアワイズ法では2つの項⽬が全て組み合わされるようになっている ペアワイズ法(オールペア法)では、全ての組み合わせを行うのではなく、そのうちの 2つの項 目が全て組み合わされるように 作られています。 IHコンロ コンロ二口以上 システムキッチン なし なし なし できれば できれば できれば 必須 必須 必須 全数組み合わせの場合は 3 x 3 x 3 = 27通り ©MIXI 156
157. ペアワイズ法では2つの項⽬が全て組み合わされるようになっている 例 : IHコンロの「なし」とコンロ二口以上、システムキッチンの組み合わせ IHコンロの「なし」と コンロ二口以上の「なし」「できれば」「必須」 の組み合わせができている ©MIXI IHコンロの「なし」と システムキッチンの「なし」「できれば」「必須」の組 み合わせができている 157
158. ペアワイズ法では2つの項⽬が全て組み合わされるようになっている つまりペアワイズ法は、問題が起こる確率が高いであろう「２つの組み合わせ」を網羅 し、確率が低い「 3つ以上の組み合わせ」は捨てる技法 です。 テストは時間もコストも有限です。その制限の中で効果が最大になるように確認しよう という方法 でもあります。 全数組み合わせをすべきか、ペアワイズ法をすべきか、リスクを考えて実施しましょう。 ©MIXI 158
159. ⽤語：各項⽬が「因⼦」、項⽬の各値が「⽔準」 組み合わせテストの話では「因子」「水準」という言葉が絶対に出ます。ややこしいですが覚 えてしまいましょう。 項目にあたる部分が「因子」 パラメーターと呼ぶこともある 値にあたる部分が「水準」 だたの値と呼ぶこともある ©MIXI IHコンロ コンロ二口以上 システムキッチン なし なし なし できれば できれば できれば 必須 必須 必須 159
160. ペアワイズ法にはツールを使います。 ペアワイズ法で効率が良い組み合わせを作るのは非常に難しいです。 というよりツールがないとほぼ無理です。 今回は GIHOZという無料でテスト技法を使うことができるサイトを用いて説明します。 無料のツール : GIHOZ https://gihoz.com ©MIXI 160
161. ペアワイズ法にはツールを使います。 因子を入力 水準を入力 使い方はとてもシンプルです。 「新規作成」→「ペアワイズテスト」でテストを作ることができます。 パラメータと書かれたところに因子(IHコンロ、システムキッチンなど)を入力します。 値のところに水準(なし、できれば、必須)を入力して「テストケースを生成」をクリックすれば完成 です。 ©MIXI 161
162. 実演 できあがったものがこちら https://gihoz.com/users/mineo_matsuya/repositories/kenshu_repo/folders/root_folder ©MIXI 162
163. テストケースでFailed(NG)が出た場合の意味 #6のみFailedに なった場合 仮にテストケース 6だけFailed(NG)になったとしま しょう。このことから以下の組み合わせのいずれ かに問題があることが言えます。 ・IHコンロできれば x コンロできれば ・IHコンロできれば x システムキッチン必須 ・コンロできれば x システムキッチン必須 ・IHコンロできれば x コンロできれば x システム キッチン必須 この組み合わせにフォーカスして再度テストをし て問題領域を狭めていきましょう。 ©MIXI 163
164. 決められた組み合わせがある場合 例えば今までの表に「ガスコンロ」の項目を追加したとします。 そのとき、ガスコンロが「必須」の時は IHコンロは「なし」、 IHコンロが「必須」の時はガスコンロは 「なし」にしたい です。 そのときは「制約」を使いましょう。 (組み合わせテストの用語としては制約や禁則と言われています) ©MIXI 164
165. 3因⼦以上の組み合わせをしたい 2因子間網羅(ペアワイズ法)では不安だという場合もあるかもしれません。そのときは3因子～などと 網羅する因子数を「オプション」の「組み合わせるパラメータ数」から変更することができます。 ©MIXI 165
166. デシジョンテーブルテストと組み合わせテストの違い デシジョンテーブル ペアワイズ法で減らした組み合わせ デシジョンテーブルテストでは、仕様などで決められた「規則のある組み合わせ」のテストを行いま す。「この条件とこの条件ならこういう結果になる」です。 組み合わせテストは特に制限はありません。「組み合わせを合理的に減らす技法」 です。 ©MIXI 166
167. コラム：テスト技法なんて信⽤できない? テストは「どこにあるかわからないバグを効率的に見つけるには」といった統計学のお化けみたいな 存在です。なので業界には大学の教授が多く、研究が進められていたりします。 それら研究で「こうしたら確かに効果があった！」というものが査読されて「確かに再現性あるね」と なって技法としてまとめられていたりします。 先ほどの2因子の組み合わせまででバグがほぼ出てるよ、の研究に対して 「2つの組み合わせしか網羅してないんでしょ。3つは？4つは？なんか不安で不安でしようがない からやっぱり全数テストが正義」 は感覚的であり、全体的な工数から見たリスクの管理ができていないように見えます。 テストは時間も工数も有限ですので、先人が研究のもとに作った技法は大いに利用していきましょ う。 ©MIXI 167
168. 質疑応答 ©MIXI 168
169. 状態遷移テスト テスト対象を漏れなく テストするための技法 ©MIXI
170. 状態遷移テスト 状態遷移テストは、状態遷移図や状態遷移表をもとにして、それらを網羅する 遷移パスをテスト します。 ストップウォッチ 状態遷移図 ©MIXI 170
171. どんなときに使えるの？ • 何かしら変わるもの (コレからアレになったらどうなるんだろう？というテストをし たい時） ◦ 例 ▪ ▪ 同じモノだけど中の状態が変わっていくとき • ログイン状態/非ログイン状態 • エアコン (冷房/暖房/自動モードなど) • (Therac-25の問題ももしかしたら拾えるのかも) 画面遷移などで、データが保持される/クリアされるか... etc • ©MIXI 氏名・住所入力画面→購入確認画面→購入完了画面 171
172. 状態遷移図 ソフトウェアの状態とアクションによって状態が遷移する方法を示した図。 状態に着目して全体を俯瞰できるようになります。 イベント 状態 遷移 ストップウォッチ ©MIXI 172
173. 状態表 状態と入力の関係を示し、有効&無効な可能性のある遷移を明確にした表。 仕様の抜け漏れを発見することができます。 状態 イベント イベント / 状態 計測準備中 計測中 一時停止中 スタートボタン押下 計測中 一時停止中 計測中 リセットボタン押下 N/A N/A 計測準備中 上の状態で 左のイベントがあったときに 遷移する状態 ©MIXI 無効な遷移 (Not Applicable) 状態遷移図には現れない！ 仕様でここの考慮漏れなどがありがち！ 173
174. じゃあ実際にどうやってテストするの？ よく使われるのは「Nスイッチカバレッジ 」です。 0スイッチカバレッジ（リンク網羅） 1回のイベントで遷移する 経路をすべて網羅する 例：計測準備中→計測中 1スイッチカバレッジ 例： 計測準備中→計測中→一時停止中 ©MIXI 前の状態から後状態まで にスイッチが 1つある（状 態を一つ経由する）状態 遷移を網羅する 174
175. 0スイッチカバレッジの場合のテストケース • 計測準備中→計測中 • 計測準備中→計測準備中 (状態表でしかわからない) • 計測中→一時停止中 • 計測中→計測中 (状態表でしかわからない) • 一時停止中→計測中 • 一時停止中→計測準備中 # 遷移前の状態 イベント 期待結果 1 計測準備中 スタートボタン押下 計測中になること 2 計測準備中 リセットボタン押下 計測準備中になること 3 計測中 スタートボタン押下 一時停止中になること 4 計測中 リセットボタン押下 計測中になること 5 一時停止中 スタートボタン押下 計測中になること 6©MIXI 一時停止中 リセットボタン押下 計測準備中になること 175
176. 1スイッチカバレッジの場合のテストケース ©MIXI • 計測準備中→計測中→一時停止中 # 遷移前の状態 イベント 期待結果 • 計測準備中→計測中→計測中 1 計測準備中 スタート→スタート 一時停止中になること • 計測準備中→計測準備中→計測中 2 計測準備中 スタート→リセット 計測中になること • 計測準備中→計測準備中→計測準備中 計測中→一時停止中→計測中 3 計測準備中 リセット→スタート 計測中になること • • 計測中→一時停止中→計測準備中 4 計測準備中 リセット→リセット 計測準備中になること • 計測中→計測中→一時停止中 5 計測中 スタート→スタート 計測中になること • 計測中→計測中→計測中 6 計測中 スタート→リセット 計測準備中になること • 一時停止中→計測中→一時停止中 計測中 リセット→スタート 一時停止中になること • 一時停止中→計測中→計測中 7 一時停止中→計測準備中→計測中 8 計測中 リセット→リセット 計測中になること • • 一時停止中→計測準備中→計測準備中 9 一時停止中 スタート→スタート 一時停止中になること 10 一時停止中 スタート→リセット 計測中になること 11 一時停止中 リセット→スタート 計測中になること 12 一時停止中 リセット→リセット 計測準備中になること 176
177. GIHOZでNスイッチカバレッジのテストを作る GIHOZ https://gihoz.com/ ©MIXI 177
178. 実演 できあがったものがこちら https://gihoz.com/users/mineo_matsuya/repositories/kenshu_repo/folders/root_folder ©MIXI 178
179. Nスイッチカバレッジの選び⽅ まずは0スイッチカバレッジ は行いましょう。 それで怪しいところがあったり、バグがあったときに1スイッチカバレッジを実施するか判断 しましょう。 • 0スイッチカバレッジだと1回の遷移が確認できるが、1スイッチカバレッジのテストでし か発見できないバグもあります ◦ 例： • 一度計測を開始すると、2回目以降計測準備中からスタートボタンで計測 開始できない • 設定画面から前の画面に戻って再度設定に行ったらデータが保存されて いない ©MIXI 179
180. 状態遷移テストのメリット/デメリット • メリット ◦ 期待通りに遷移できない欠陥を見つけられる ◦ 状態遷移図とあわせて状態表を使うことで、テストの漏れ・抜け防止とともに、 仕様や設計の誤りを見つけられる • ©MIXI デメリット ◦ 状態をちゃんと設定できない（曖昧）だと、結局抜け漏れが発生する ◦ 状態や遷移の数が多いと状態遷移図や状態表が複雑になる 180
181. 質疑応答 ©MIXI 181
182. 演習 状態遷移テスト ©MIXI
183. 演習：状態遷移図の作成 (時間があったらやってみて) • 自動販売機 ◦ 100円硬貨のみ受け付ける。 ◦ ジュースは100円と150円の2種類のみである。 （ジュースボタンが2個ある。） ◦ ジュースボタンを押して購入後に残高があれば、おつりとして商品と同時に返却さ れる。 ◦ コイン返却ボタンがある。 ◦ その他の仕様（ジュースの在庫、ジュースの温度、自動販売機内のおつりの有 無、取り出し口の商品詰まり、偽造コインなど）は考慮しない。 • 投入済金額（0円、100円、200円）を状態として状態遷移図と状態表を作成してみてく ださい ©MIXI 183
184. 演習の解答例 状態遷移テスト ©MIXI
185. 演習の解答例：状態遷移テスト ©MIXI 185
186. 演習の解答例：状態遷移テスト 2. 状態表 状態 0円 100円 200円 100円投入 100円 200円 ？？？ コイン返却ボタン押下 N/A 0円 0円 100円ジュースボタン押下 N/A 0円 0円 150円ジュースボタン押下 N/A N/A 0円 イベント ©MIXI 186
187. おすすめ書籍 ©MIXI
188. おすすめ書籍 ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス 2023対応 テストの考え方について、全体的に学ぶことができます。 JSTQB(ISTQB)という国際的なテスト技術者の資 格試験のための本でもあります。 ソフトウェアテスト技法練習帳 ~知識を経験に変える 40問~ 状態遷移テストなどのテスト技法を、例題を使って手を動かしながら学ぶことができます。 テスターちゃん (2巻のほうがテストの考え方がたくさん載っている ) 手前味噌ながら …。ソフトウェアテストの初学者に向けて書いた「マンガでわかる」系の本です。 1巻はテス トエンジニアの業務系 (バグ票の書き方など )について、2巻がテストの考え方が多く載っています。社内に 本が置いてあります。 ©MIXI 188
189. おすすめ書籍 JSTQB シラバス テスト技術者試験用のシラバス群。様々なジャンルのテストについて知ることができる。すべて無料で読め る。内容は少し難しい。 ©MIXI 189
190. みなさん、これから業務で 様々なPJに関わり 様々なプロダクトを作ることになります。 その時に 「ユーザーが満⾜できるものを作れているかな？」 を意識してみてくださいね！ ©MIXI
191. ©MIXI