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

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

Transcript

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