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

by MIXI ENGINEERS

Slide 1

Slide 1 text

©MIXI QAとは & ソフトウェアテスト⼊⾨ CTO室&Romi事業部兼務松⾕峰⽣

Slide 2

Slide 2 text

©MIXI 2 ⾃⼰紹介名前 : 松谷峰生 (まつやみねお) 部署 : 開発本部 / Romi事業部 (兼務) 基本はずーっとRomiをやっています。モケイ部に入っています。社外活動 ● JaSST九州(ソフトウェアテストシンポジウム)実行委員長 ● ASTER(ソフトウェアテスト技術振興協会)教育事業メンバー ● AIプロダクト品質保証ガイドラインVUI領域執筆(だいぶ昔だ…)

Slide 3

Slide 3 text

©MIXI 3 ⾃⼰紹介 ● マンガ家！ ○ 新人さんからわかるソフトウェアテスト解説マンガ「テスターちゃん」 ○ (新連載！)なにそれ？あなたの知らないテストの言葉 ● ペットはフクロモモンガ ● ゴールデンウィーク中は横シューティングを作ってました。完成させてストアリリースしたいなぁ

Slide 4

Slide 4 text

©MIXI 4 ⽬次 ● QA(品質保証)って？ ● ソフトウェアテスト入門 ○ テストの重要性 ○ テストの考え方 ○ テストレベルという考え方 ● テスト技法 ○ 同値分割法 ○ 境界値分析 ○ デシジョンテーブルテスト ○ 組み合わせテスト（ペアワイズ法） ○ 状態遷移テスト ● おすすめ書籍

Slide 5

Slide 5 text

©MIXI QA(品質保証)って？

Slide 6

Slide 6 text

©MIXI 6 QA(品質保証)って？ QA (Quality Assurance) 品質保証

Slide 7

Slide 7 text

©MIXI 7 QA(品質保証)って？ QAってテストすることでしょ？

Slide 8

Slide 8 text

©MIXI 8 QA(品質保証)って？ QA=テストという認識は少し違います

Slide 9

Slide 9 text

©MIXI 品質ってなんだっけ？

Slide 10

Slide 10 text

©MIXI 10 QA(品質保証)って？みなさんが好きなゲームやサービスをいくつか思い浮かべてみてください。どういったところが好きですか？

Slide 11

Slide 11 text

©MIXI 11 QA(品質保証)って？おそらく「バグが見つからないから好き」ではないと思います。何かしら「満足すること」があるのではないでしょうか？

Slide 12

Slide 12 text

©MIXI 12 品質の定義の変遷クロスビー (Philip B. Crosby) 品質とは、要件に対する適合である一般の工業プロダクトよりの定義ワインバーグ (Gerald M. Weinberg) 品質は誰かにとっての価値であるここでの価値は「人々はその要求が満たされるなら、喜んで対価を払う」を意味している割とテスト業界ではこの定義が好きな人が多い (主観) 出典：ソフトウェア品質知識体系ガイド（ SQuBOK Guide V2）

Slide 13

Slide 13 text

©MIXI 13 品質の定義の変遷石川馨 (いしかわかおる) 「製品の品質」は欧米の考えである「狭義の質」である。一方「広義の質」は仕事の質、サービスの質、情報の質、工程の質、部門の質、人の質、システムの質、会社の質など、これら全てを含めて捉える。品質管理は「広義の質」について管理することを基本姿勢とするプロダクトの質を「狭義の質」、それを取り巻く全体を含めた質を「広義の質」と定義出典：ソフトウェア品質知識体系ガイド（ SQuBOK Guide V2）

Slide 14

Slide 14 text

©MIXI 14 品質の定義の変遷保田勝通 (やすだかつゆき) 品質とは、ユーザーにとっての価値である近代的な品質管理における品質の定義。品質はユーザーの満足度である出典：　ソフトウェア品質保証の考え方と実際，日科技連出版，保田勝通著

Slide 15

Slide 15 text

©MIXI 15 品質保証って？保証 = 間違いがない、大丈夫であると認め、責任をもつこと。品質保証出典：デジタル大辞泉（小学館）

Slide 16

Slide 16 text

©MIXI 16 品質保証って？なので品質保証ちょっと言い換えると… ユーザーが満足できることを約束すること松谷のオレオレ定義

Slide 17

Slide 17 text

©MIXI 17 品質保証って？ユーザーが満足できることを約束することその手段としてプロダクトに対してはテストやレビューというアプローチがある! プロダクト品質

Slide 18

Slide 18 text

©MIXI 18 品質保証って？そのプロダクトさえテストでしっかり押さえていたら満足度の高いものになる？

Slide 19

Slide 19 text

©MIXI 19 品質保証って？チームがイマイチだと… 毎回ボロボロのプロダクトが出来上がり、ひたすらテストで打ち返して時間もコストもかかったり… ユーザーの要求の対応にとんでもなく時間やコストがかかったり… 次のリリースが一生来ない ! 毎回同じバグあるし!

Slide 20

Slide 20 text

©MIXI 20 品質保証って？チームの質はプロダクトの質やサービスの質として現れる！

Slide 21

Slide 21 text

©MIXI 21 品質保証って？ユーザーが満足できることを約束することチームに対してはプロセスのカイゼンというアプローチがある! カイゼンを回すことによって、より良いものを、より良い状態で出すことができるようになってくるカイゼンプロセス品質 (業務品質 )

Slide 22

Slide 22 text

©MIXI 22 例えば… カイゼンはPJの課題の数だけあるけど、例えば… TDDでテストを根付かせるデプロイパイプラインの構築手作業のテストの自動化コーティングルールの整備振り返り→ カイゼンのサイクルを回すレビューの強化

Slide 23

Slide 23 text

©MIXI 23 品質保証って？チームが良ければ…！

Slide 24

Slide 24 text

©MIXI 24 品質保証って？ユーザーが満足できることを約束すること言い換えると … ブランド

Slide 25

Slide 25 text

©MIXI 25 品質保証って？ユーザーが満足できることを約束すること言い換えると … ブランド ⚪⚪社のゲームだから子どもでも楽しめるはず！ xx社のバッグだから綺麗で丈夫なはず！ MIXIのものだから良い意味で驚かされるはず！ zz社の車だから安全なはず！

Slide 26

Slide 26 text

©MIXI 26 品質保証って？ユーザーが満足できることを約束すること会社に対してはみんなで同じ方向を向けるようにポリシーを策定したり、品質文化を根付かせるアプローチがある会社として一定の品質のものを出せることにより「MIXIのものだから安心だし良いものだ」という企業ブランドとなる企業品質

Slide 27

Slide 27 text

©MIXI 27 QA(品質保証)って？品質保証は特定の人のがんばりではなくみんなで行っていく活動 (組織的な活動) 品質のことはxxさんに任せた！俺たちゃ作るだけ！知らん！ではない

Slide 28

Slide 28 text

©MIXI 28 QA(品質保証)って？ブランドはひとつのプロダクトや1回のリリースで成り立つものではなくユーザーの信頼の積み重ねで成り立つ

Slide 29

Slide 29 text

©MIXI 29 QA(品質保証)って？ QAってテストすることでしょ？

Slide 30

Slide 30 text

©MIXI 30 まとめ的なページ出典 : JaSST’19 Tokyo QA入門(秋山浩一) 出典 : テスターちゃん 2巻

Slide 31

Slide 31 text

©MIXI 31 QA(品質保証)って？これから皆さんには品質保証活動の中で開発業務に一番近い「ソフトウェアテスト」についてお伝えします

Slide 32

Slide 32 text

©MIXI 32 QA(品質保証)って？けれど、ここまで学んだように品質保証活動はみんなで意識して進めていく (=ブランドを作っていくこと ) ことがとても大切です

Slide 33

Slide 33 text

©MIXI 33 質疑応答

Slide 34

Slide 34 text

©MIXI 34 学んだことの整理の時間 5分休憩 & 学んだことを思い返して整理しましょう。 (当てたりしないのでご安心を)

Slide 35

Slide 35 text

©MIXI ソフトウェアテスト⼊⾨

Slide 36

Slide 36 text

©MIXI テストの重要性

Slide 37

Slide 37 text

©MIXI 37 不具合による事故例(Therac-25放射線事故) Therac-25は電子線/X線を使って癌を治療する放射線治療機でした。ある日放射線技師は治療時に電子線の「E」キーの代わりにX線の「X」キーを押してしまいました。間違いに気づき技師は8秒以内に「↑」キーを押してフィールドに戻り「E」キーを入力しなおしました。そして照射したところ事故が発生してしまいました。 1回180ラドの線量のはずが、1万6000~2万5000ラドの線量が照射されてしまったのです。原因 ● 機能の問題 ○ Xキーが入力されると Therac-25内部の磁石の位置が設定されるが、動作完了には 8秒かかる ○ この間に照射モードが変更されると磁石位置を示すフラグが変わっておらず、モード変更のサブモジュールが正しく実行されずに過剰照射が発生する ● UIの問題 ○ 入力を受け付けない状態にあるとき、入力を待たせるような機能がないため入力できたと思ってしまう ○ 変更時に変更完了といったメッセージが出ないため、変更したと思ってしまう ○ エラー時に「誤動作54」と出たが、それが何を意味するエラーかどこにも書かれていなかった

Slide 38

Slide 38 text

©MIXI 38 不具合による事故例(アリアン5型ロケット爆発事故) 1996年6月4日、フランス領ギアナの宇宙センターからヨーロッパ最新の無人サテライト発信ロケットが打ち上げられました。しかし、打ち上げ後約40秒後に爆発してしまいました。原因 ● 固体ブースターの噴射口と主エンジンの噴射口を制御する Inertial Reference Systemに欠陥があり正確な飛行姿勢が送られなかった。 ○ 64bitの浮動小数点数を16bit符号付整数に変換する際に、 32,768を超えてしまいエラーとなった。結果、主エンジンの噴射角度が最大になってしまった。 ○ 変換失敗のエラー処理をしていなかった ● HotStanbyの予備系統もあったが同じシステムが載っていたため、同じくエラーになって同時に落ちた損失は80億ドル。

Slide 39

Slide 39 text

©MIXI 39 動かないソフトウェアが引き起こす問題経済的な損失時間の浪費信用の失墜障害や死亡事故テストにより、ソフトウェアの品質を評価し、実際の環境でソフトウェアの問題が発生するリスクを低減するテストが重要な理由！

Slide 40

Slide 40 text

©MIXI テストの考え⽅

Slide 41

Slide 41 text

©MIXI 41 テストの考え⽅テストって仕様通り動くか確認すればいいんでしょ？

Slide 42

Slide 42 text

©MIXI 42 テストで⾏うこと3選仕様通り動作するかの「チェック」バグを発見するための「テスト」要求にそったものが作れているかの「妥当性確認」

Slide 43

Slide 43 text

©MIXI 43 仕様通り動作するかの「チェック」仕様通り動作するかの「チェック」どこで何をすればどうなるか仕様書に書いてあるので確認することが明確基本的には「当たり前」の領域テストの認識がこの範囲だけだと「テストなんて簡単」の思考に陥ってしまう

Slide 44

Slide 44 text

©MIXI 44 仕様書に書かれていることこう動く正常系の仕様こう動かない異常系の仕様 (エラー系など ) 仕様書仕様書に「全てのこと」が書かれているわけじゃないから注意！これらのことを「仕様通り動くか」を確認するけど …

Slide 45

Slide 45 text

©MIXI 45 仕様通り動作するかの「チェック」テストで「仕様書(設計)に書かれていること」は確実におさえましょう！仕様書に全てが書かれていないが、書いてあることをまずは確実にしよう

Slide 46

Slide 46 text

©MIXI 46 テストで⾏うこと3選バグを発見するための「テスト」

Slide 47

Slide 47 text

©MIXI 47 バグを発⾒するための「テスト」仕様通り動くかのチェックでバグ見つかるよね？

Slide 48

Slide 48 text

©MIXI 48 バグを発⾒するための「テスト」「仕様書通りに動くかのチェック」で Therac-25やアリアン5号機のような問題は見つけられるでしょうか？

Slide 49

Slide 49 text

©MIXI 49 仕様通りの確認で仕様上のバグは⾒つけられるけど… 仕様に書いてある使い方仕様に書いていない使い方「仕様通り動くか」のチェックで、仕様という「大通り」にあるバグは見つかる。しかし、仕様に書かれていない様々な「小道」がある。そこは確認していないためバグが残っている。ユーザーは様々な使い方をするため、本番でそのバグを踏むことになる。

Slide 50

Slide 50 text

©MIXI 50 開発のおおざっぱな流れ要求要件仕様設計実装「こういうものが欲しい」から実装までの大まかな流れ

Slide 51

Slide 51 text

©MIXI 51 設計時の思考出典 : 単なる仕様チェックから卒業してテスト技術力を高めていくために (池田暁)

Slide 52

Slide 52 text

©MIXI 52 バグの多くは「忘れもの」要求要件仕様設計実装・要件定義漏れ・偉い人との認識齟齬・仕様漏れ・設計の間違い・影響箇所の把握漏れ・PdMとの認識齟齬・実装の間違い・実装の漏れ自分が想定した通り動くかの確認で大丈夫？

Slide 53

Slide 53 text

©MIXI 53 テストとはマイヤーズ (Glenford J. Myers) テストとは、エラーを見つけるつもりでプログラムを実行する過程である出典 : ソフトウェア・テストの技法第2版「システムを動かす」でも良さそう

Slide 54

Slide 54 text

©MIXI 54 テスト時の思考出典 : 単なる仕様チェックから卒業してテスト技術力を高めていくために (池田暁)

Slide 55

Slide 55 text

©MIXI 55 バグを発⾒するための「テスト」テストは「探索」を含む

Slide 56

Slide 56 text

©MIXI 56 考え⽅ひとつで⾏動が変わる！ちゃんと動くかチェックしよう「正しい動作」にフォーカスするため、一般的な操作に終始しがちバグを見つけてやろう! 「バグを見つける」にフォーカスするためイレギュラーな操作が増える

Slide 57

Slide 57 text

©MIXI 57 作ったシステムを触らない⼈が意外といる何か実装した後自分のシステムを触らない人が意外といます

Slide 58

Slide 58 text

©MIXI 58 仕様通りのチェックに加え、バグの探索をしよう仕様通り動くかチェックしたけど… 本番でバグが出ないか不安だァァーッ！！仕様通り動くかはチェックしたけどさぁもうお分かりだろう!! バグを探そうとしていないのである !! 探そうとしていないものが本番で見つかるのは当たり前である!! 仕様通りのチェック + バグの探索の二つが揃って良いテストとなります。

Slide 59

Slide 59 text

©MIXI 59 どうすればいいの？これから学ぶ「テスト技法」を使うシステムを触る時間をつくる立ち止まって「忘れもの」はないか考えるパターンの漏れに気づくことができる「バグを見つけるつもり」でシステムを触ってみる。「ユーザーになったつもり」でシステムを触ってみる。実際に触ると見えてくることも多い。落ち着いて考えると、意外と忘れている処理に気づく

Slide 60

Slide 60 text

©MIXI 60 探索には経験‧知識が必要バグの探索には確実な手法や手軽な方法は今はなく知識や経験に大きく左右されます

Slide 61

Slide 61 text

©MIXI 61 テストで⾏うこと3選要求にそったものが作れているかの「妥当性確認」

Slide 62

Slide 62 text

©MIXI 62 妥当性確認ってなに？ゴージャスなチョコパフェが食べたい！ユーザーわかりました。 1週間後にまた来てください。最高にゴージャスなチョコパフェってやつをリリースしますよ。 PdM 要求

Slide 63

Slide 63 text

©MIXI 63 妥当性確認ってなに？仕様を考えるPdM ゴージャスなチョコパフェだな！仕様はこれだ！！舌触りの良い高級クリームをのせる砂糖コーティングされたイチゴをのせる高級チョコレートソースを上からかける北海道産のバフンウニでクリームを囲む内部はフレーク、イクラ、アイスの3層仕様

Slide 64

Slide 64 text

©MIXI 64 実装完了！仕様通り実装されているかの「チェック」舌触りの良い高級クリームをのせる砂糖コーティングされたイチゴをのせる高級チョコレートソースを上からかける北海道産のバフンウニでクリームを囲む内部はフレーク、イクラ、アイスの3層開発版が完成したぞ！仕様通り実装されているか確認しないとな

Slide 65

Slide 65 text

©MIXI 65 仕様通り実装されているかの「チェック」舌触りの良い高級クリームをのせる砂糖コーティングされたイチゴをのせる高級チョコレートソースを上からかける北海道産のバフンウニでクリームを囲む内部はフレーク、イクラ、アイスの3層仕様通りのっていることを確認砂糖コーティングであることを確認仕様ではチョコソースだが、実物では醤油がかかっている修正しました！仕様ではバフンウニだが、実物ではムラサキウニであった修正しました！仕様通りの順で3層であることを確認

Slide 66

Slide 66 text

©MIXI 66 バグを発⾒するための「テスト」舌触りの良い高級クリームをのせる砂糖コーティングされたイチゴをのせる高級チョコレートソースを上からかける北海道産のバフンウニでクリームを囲む内部はフレーク、イクラ、アイスの3層仕様通りになっていることのチェックは済んだぞ！次はバグを探索しないとな！ Pass Pass Pass Pass Pass

Slide 67

Slide 67 text

©MIXI 67 バグを発⾒するための「テスト」バグ票: 35℃環境下に48h放置後、最後まで食べ進めるとお腹を壊す探索で重要なバグを見つけちゃいました！！よく見つけてくれました！それはWebで24時間以内に食べてと Popupを出す対応をします！これで仕様にないところのバグ探索の対応も終わった！

Slide 68

Slide 68 text

©MIXI 68 完成！ゴージャスチョコパフェ feat. 海の幸リリースです！　ユーザーの反応が楽しみですね！

Slide 69

Slide 69 text

©MIXI 69 結果… マズ…

Slide 70

Slide 70 text

©MIXI 70 結果… 仕様通り実装されていて動作に問題がないと確認をしてもそもそものニーズを満たしていない場合もある

Slide 71

Slide 71 text

©MIXI 71 妥当性確認とは作業成果物がステークホルダーのニーズに一致するかを、調査によって確認すること出典 : ISTQB Glossary, V4.6.0

Slide 72

Slide 72 text

©MIXI 72 どうすればいいの？例 A/Bテスト DAUなどのデータを追って分析ユーザーテスト満足度調査等のアンケートドッグフーディング例えば…

Slide 73

Slide 73 text

©MIXI 73 もう少し⾝近でできること仕様や言われたことをただ鵜呑みにするのではなく気になることがあったときはコミュニケーションをしましょうチョコパフェに海の幸って大丈夫でしたか？

Slide 74

Slide 74 text

©MIXI 74 テストで⾏うこと3選(再掲) 仕様通り動作するかの「チェック」バグを発見するための「テスト」要求にそったものが作れているかの「妥当性確認」

Slide 75

Slide 75 text

©MIXI 75 質疑応答

Slide 76

Slide 76 text

©MIXI テストレベルという考え⽅

Slide 77

Slide 77 text

©MIXI 77 テストレベルという考え⽅テストといっても、コードで実行するテストもあれば、システムを実際に動かすテストもあるよね？

Slide 78

Slide 78 text

©MIXI 78 テストレベル系統的にまとめ、マネジメントしていくテスト活動のグループ出典 : JSTQB Foundation Level Ver4.0.J02

Slide 79

Slide 79 text

©MIXI 79 テストレベル(コンポーネントテスト) コンポーネントテスト (ユニットテスト ) hoge(){ … … … … … } コンポーネント : 独立してテストできる、システムの最小構成単位スタブ/ モックコンポーネントを単独でテストすることに焦点を当てる。（いわゆるユニットテスト）他のコンポーネントを呼び出すところはスタブなどを利用する。主にロジックについてテストする。出典 : ISTQB Glossary, V4.6.0

Slide 80

Slide 80 text

©MIXI 80 テストレベル(コンポーネント統合テスト) コンポーネント統合テスト (結合テスト ) コンポーネントコンポーネントコンポーネント統合テスト（結合テスト）はコンポーネント同士を連携させてテストを行う。コンポーネント間のインターフェイス（接点）にフォーカスし、相互処理についてテストする。

Slide 81

Slide 81 text

©MIXI 81 テストレベル(システムテスト) システムテストシステムテストはシステムにフォーカスし、振る舞いや全体的な能力についてテストを行う。システムコンポーネントコンポーネントコンポーネントコンポーネント

Slide 82

Slide 82 text

©MIXI 82 テストレベル(システム統合テスト) システム統合テストシステム統合テストは、テスト対象のシステムと他のシステムや外部サービスとのインターフェイスにフォーカスしテストをする。（例えば管理システムと連携など）テスト対象システムコンポーネントコンポーネントコンポーネントコンポーネント他システム

Slide 83

Slide 83 text

©MIXI 83 テストレベル(受け⼊れテスト) 受け入れテストシステムがユーザーのニーズを満たしているかにフォーカスする。妥当性確認。システムコンポーネントコンポーネントコンポーネントコンポーネント

Slide 84

Slide 84 text

©MIXI 84 テストレベルシステムテストシステム統合テストコンポーネント統合テスト(結合テスト) 受け入れテストコンポーネントテスト(ユニットテスト) 主にロジックのテストが目的主にコンポーネント間の相互処理のテストが目的主にシステムを通しての振る舞い、全体的な能力のテストが目的主にシステム間の相互処理のテストが目的主にユーザーの要求を満たしているかの確認が目的

Slide 85

Slide 85 text

©MIXI 85 テストレベルテストにそういったわけ方があることはわかったけど、それって何か役に立つの？

Slide 86

Slide 86 text

©MIXI 86 テストレベルで考えるテストの最適化テストの最適化が考えられるようになる！

Slide 87

Slide 87 text

©MIXI 87 例えば… Front Backend 入力データを送るだけ受け取ったデータを表示するだけコンポーネントここですごいパターン分けのロジックがあるシステムシステムテストで全パターンをチェックするのに3日はかかります

Slide 88

Slide 88 text

©MIXI 88 全てを「システムテスト」で確認でいい？ Front Backend データ送信のテスト目的であれば決められたフォーマットでデータが送られているかテストで良さそう表示を確認するテスト目的であれば、データを入れて見て表示確認で良さそうコンポーネントここですごいパターン分けのロジックがある例えばこんなテストのアプローチもできそうロジックを確認したいというテスト目的であればコンポーネントテストでよさそうコンポーネントテストコンポーネントテストコンポーネントテスト

Slide 89

Slide 89 text

©MIXI 89 例えばこんなテストのアプローチもできそう Front Backend 　実際にデータのやり取りができているか確認するテスト目的なら全パターンで見なくてもどれかでテストすれば良さそうコンポーネントここですごいパターン分けのロジックがあるコンポーネント統合テスト

Slide 90

Slide 90 text

©MIXI 90 例えばこんなテストのアプローチもできそう Front Backend コンポーネントここですごいパターン分けのロジックがあるシステム全体の振る舞いを確認するテスト目的やターンアラウンドタイムを知る目的ならシステム全体を通したテストシステムを通して「何かバグがないか」と探索するテスト目的ならシステム全体を通したテスト

Slide 91

Slide 91 text

©MIXI 91 テストレベルで考えるテストの最適化そのテスト目的を達成するためには本当にそのテストレベルでのテストが最適か考えることが大切

Slide 92

Slide 92 text

©MIXI 92 質疑応答

Slide 93

Slide 93 text

©MIXI 93 学んだことの整理の時間 5分休憩 & 学んだことを思い返して整理しましょう。 (当てたりしないのでご安心を)

Slide 94

Slide 94 text

©MIXI テスト技法

Slide 95

Slide 95 text

©MIXI 95 テスト技法同値分割法境界値分析デシジョンテーブルテスト状態遷移テストユースケーステスト組み合わせテストテスト技法テストはなんでもかんでもテストしまくればいいというわけではありません。時間とお金の都合を考えて、 QCDF(Fは機能やフィーチャー )のバランスが取れた情報を提供する必要があります。そこでテスト技法です。テスト技法は、比較的少ないながらも十分なテストケースのセットを開発、つまり効率的なテストを作成する方法です。 ※ブラックボックステストの技法今回の講義内容には入ってません

Slide 96

Slide 96 text

©MIXI 96 テスト技法テスト技法については、一部 NPO法人ASTER(ソフトウェアテスト技術振興協会 )の「ASTERセミナー標準テキスト」を利用しています。全体を見たい人は以下です。（無料です） https://www.aster.or.jp/business/seminar_text.html

Slide 97

Slide 97 text

©MIXI 同値分割法テストケースを合理的に少なくするための技法

Slide 98

Slide 98 text

©MIXI 98 同値分割法計算クリア（例）１けたの正の整数2個を足し算するプログラム？それぞれ「1」から「9」までの整数が入力できるのであれば、「 1+1」から「9+9」までの81通りのテストが必要か？「１けたの正の整数」以外の値も入力できてしまうのでは？ある特定のパーティションすべての要素がテスト対象によって同等に処理されることを想定して、データをパーティションに分割する。各パーティションに対して1つの値をテストする。出典： ISTQBテスト技術者資格制度　 Foundation Level シラバス日本語版 Version4.0.J02

Slide 99

Slide 99 text

©MIXI 99 同値分割の背景にある考え⽅ 1 同じ処理がされるはずのパーティション（グループ） 2 3 4 5 6 7 8 9 “3”で欠陥が見つかった同じパーティションの他の数字でも同じ欠陥が見つかるはず同値パーティション(同じ処理がされるであろうグループ）からデータを一つ選んで問題があった場合、この問題は同じパーティションの他のデータでも発生するはずだ、というもの

Slide 100

Slide 100 text

©MIXI 100 同値分割法 • ある特定のパーティションすべての要素がテスト対象によって同等に処理されることを想定して、データをパーティションに分割する。同値パーティション 9 有効パーティション（システムに受け入れられる値）無効パーティション（システムに拒否される値）無効パーティション（システムに拒否される値） 1 10 0

Slide 101

Slide 101 text

©MIXI 101 同値分割法 • 各パーティションに対して1つの値をテストする。代表値：5 代表値：15 代表値：-5 無駄なテストをなくし、テスト回数を削減できる。 9 有効パーティション（システムに受け入れられる値）無効パーティション（システムに拒否される値）無効パーティション（システムに拒否される値） 1 10 0

Slide 102

Slide 102 text

©MIXI 102 同値分割法 • パーティションが識別できるのは入力だけではない。 – 出力、構成アイテム、内部値、時間関連の値、インターフェースパラメーターなど（例） 2個の入力をともに「3」とした場合 3 + 3 = 6 答え（出力）は6 答えが1桁の場合と2桁の場合で別々のパーティションとするなど。 2個の入力をともに「5」とした場合 5 + 5 = 10 答え（出力）は10 1桁のときは「２桁めに０」が表示されてしまうかも表示位置がずれるかも

Slide 103

Slide 103 text

©MIXI 103 同値分割法 • パーティションは、連続/離散、順序性あり/なし、有限/無限のいずれでもよい青森県北海道京都府ニューヨーク州ワシントン州イリノイ州離散的なパーティション例 (地域など) 連続的なパーティション例 (数値など) 0.0℃ <0.0℃ 60.0℃ >60.0℃

Slide 104

Slide 104 text

©MIXI 104 同値分割法 • パーティションは、重複してはならず、空でない集合でなければならない高校生以下成人（18歳以上）誤った同値分割の例 18歳の高校生どちらにも属する 16歳の社会人どちらにも属さない

Slide 105

Slide 105 text

©MIXI 105 同値分割法 • 複数のパーティションセットがある場合、各パーティションを少なくとも1回は通るような最も単純なテストケースの設計をイーチチョイスカバレッジという – 網羅ではなく、 1回は各パーティションを通るデータの選び方 18才未満 18≦x<65 65才以上年齢 1年未満 1≦n<5 5≦n<10 10年以上契約年数一般会員上級会員会員種別テストケース1 テストケース2 テストケース3 テストケース4 例 : 「年齢」「契約年数」「会員種別」という項目がある場合

Slide 106

Slide 106 text

©MIXI 境界値分析バグを⾒つけるように狙っていく技法

Slide 107

Slide 107 text

©MIXI 107 境界値分析有効パーティションの最小値無効パーティションの最大値有効パーティションの最大値無効パーティションの最小値同値パーティションの境界を確認することに基づいた技法で、パーティションの最小値および最大値を選んでテストする。 9 有効パーティション無効パーティション無効パーティション 1 10 0 出典： ISTQBテスト技術者資格制度　 Foundation Level シラバス日本語版 Version4.0.J02

Slide 108

Slide 108 text

©MIXI 108 境界値分析 • 境界に対する記述ミスや解釈ミスに起因する欠陥をピンポイントで狙う。例）ソースコードでの不等号の実装ミス（「＞」と「＞＝」など）例）仕様における境界に関する曖昧な記述システム稼働時間　8:00～20:00 システム停止時間　0:00～8:00、20:00～24:00 例）アリアン5号のようなオーバーフロー 8:00、20:00は稼働？停止？ ● 狙う場所の例 ○ 入力値の下限-1、下限、上限、上限+1 ○ 配列の最大長、最大長+1 ○ 条件式（等式・不等式）で指定された値、およびその前後の値

Slide 109

Slide 109 text

©MIXI 109 境界値分析 ● 数値の範囲以外にも適用できる。例）数値属性を持つ非数値変数（A3、B5といった用紙サイズなど） ● ループ（ユースケース内のループを含む） ● 格納されているデータ構造 ● 物理オブジェクト（メモリを含む） ● 時間により判定される活動負荷の耐久性 ● 非機能欠陥を発見する。例）負荷の耐久性 ● システムは10,000人の同時ユーザーをサポートする。例: この製品は60時間稼働できる。 60時間確かに稼働できるか、超えた場合は危険にならないか等耐久性の確認例: その変数のメモリ確保の最大。最大値で問題がないか、最大値を超えた場合の処理等。

Slide 110

Slide 110 text

©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%

Slide 111

Slide 111 text

©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

Slide 112

Slide 112 text

©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が返ってくるためテストで問題を発見できます。実際にどこまでテストするかはプロダクトに応じて考えましょう。

Slide 113

Slide 113 text

©MIXI 113 質疑応答

Slide 114

Slide 114 text

©MIXI 演習境界値分析

Slide 115

Slide 115 text

©MIXI 115 演習 : 境界値分析 (時間5分 : 休憩含む) ● 以下のコードのテストを考えましょう。 ○ short int型（16bit符号付き）の引数aがある。 ○ モジュール内にはif (a<0) と if (7

Slide 116

Slide 116 text

©MIXI 演習の解答例境界値分析

Slide 117

Slide 117 text

©MIXI 117 演習の解答例 : 境界値分析 1. 同値パーティションは以下の5個 • -32769以下 • -32768以上、-1以下 • 0以上、7以下 • 8以上、32767以下 • 32768以上 2. 境界値は以下の8個 • -32769、-32768、-1、0、7、8、32767、32768

Slide 118

Slide 118 text

©MIXI デシジョンテーブルテストテスト対象を漏れなくテストするための技法

Slide 119

Slide 119 text

©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 - - - - - - -

Slide 120

Slide 120 text

©MIXI 120 デシジョンテーブルテスト考えられる条件の組合せを作るという点において、漏れや抜けがなくなる。入力条件が複雑に（ANDやORで）絡み合う場合に有効開発時の仕様整理にも使いやすい条件の洗い出しが難しい条件の数が多いとデシジョンテーブルの作成に時間がかかる

Slide 121

Slide 121 text

©MIXI 121 デシジョンテーブルの書き⽅例：ある映画館の座席予約システムがあります。この映画館では水曜日は20%割引です。また全曜日通して、22時以降は10%割引です。割引が重なった場合は割引率が高い方が適用されます。

Slide 122

Slide 122 text

©MIXI 122 デシジョンテーブルの書き⽅例：ある映画館の座席予約システムがあります。この映画館では水曜日は20%割引です。また全曜日通して、 22時以降は10%割引です。割引が重なった場合は割引率が高い方が適用されます。 1 2 3 4 水曜日時間 >= 22時「～だったら」という条件の部分！条件を抽出して記載する。例の場合、「曜日(水曜か否か)」と「時間（22時以上か否か）」が条件であることがわかる。

Slide 123

Slide 123 text

©MIXI 123 デシジョンテーブルの書き⽅例：ある映画館の座席予約システムがあります。この映画館では水曜日は20%割引です。また全曜日通して、22時以降は10%割引です。割引が重なった場合は割引率が高い方が適用されます。 1 2 3 4 水曜日時間 >= 22時 20%割引 10% 割引割引なし動作を記載する。仕様には明記されていない動作（いずれにも当てはまらない）もあるので注意！「どうなる」という結果の部分！

Slide 124

Slide 124 text

©MIXI 124 デシジョンテーブルの書き⽅ 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 10% 割引割引なし条件の全組み合わせを記入する。成り立つ場合はY(またはT)、成り立たない場合はN(またはF)。機械的に YとNを並べる！

Slide 125

Slide 125 text

©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つ

Slide 126

Slide 126 text

©MIXI 126 デシジョンテーブルの書き⽅ 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 X X - - 10% 割引 - - X - 割引なし - - - X 条件に対する結果を記入する。当てはまる項目には「X」、当てはまらない項目には「-」を記載する。条件を見ながら考えて埋める必要がある

Slide 127

Slide 127 text

©MIXI 127 テストケースの書き⽅ 1 2 3 4 水曜日 Y Y N N 時間 >= 22時 Y N Y N 20%割引 X X - - 10% 割引 - - X - 割引なし - - - X デシジョンテーブルの 1列が、それぞれテスト項目となる。条件はテストケースの「入力」に、動作はテストケースの「期待結果」となる。

Slide 128

Slide 128 text

©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でも動作は変わらないということ。）

Slide 129

Slide 129 text

©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歳未満なら他の条件に動作が左右されない ※注意事項条件の処理順が条件欄の記載順と同一であること。不明の場合は単純に最小化できない。

Slide 130

Slide 130 text

©MIXI 130 質疑応答

Slide 131

Slide 131 text

Slide 132

Slide 132 text

©MIXI 132 演習 : デシジョンテーブル (時間10分 : 休憩含む) • 「うるう年判定プログラム」の仕様は以下の通りである。 1. 西暦年数が4で割り切れる年は、うるう年である。 2. 西暦年数が4で割り切れる年のうち、100で割り切れる年の場合は、うるう年ではない（平年である）。 3. 2.のケースであっても、400で割り切れる年の場合はうるう年とする。 1. 上記の仕様について、デシジョンテーブルを作成しましょう。 2. ①で作成したデシジョンテーブルの各規則（ルール）に対して、テスト実行時に用いる具体的な入力値、期待結果を列挙しましょう。

Slide 133

Slide 133 text

Slide 134

Slide 134 text

©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 • 全ての組合せを作成したのち、あり得ない組合せを削除する。ありえない組合せを削除する

Slide 135

Slide 135 text

©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

Slide 136

Slide 136 text

©MIXI 136 演習解答例 : デシジョンテーブル 2 デシジョンテーブルから作成されるテストケース No 入力値期待結果説明 1 2000 うるう年 4でも、100でも、400でも割り切れる 2 2100 平年 4でも、100でも割り切れるが、400で割り切れない 3 2020 うるう年 4で割り切れるが、100と400では割り切れない 4 2019 平年 4でも、100でも、400でも割り切れない

Slide 137

Slide 137 text

Slide 138

Slide 138 text

Slide 139

Slide 139 text

Slide 140

Slide 140 text

©MIXI 140 こんなときどうテストをしますか？テストの時にそれぞれのパーツをテストして OKだった。しかしリリースしてみると帽子B と体Cの組み合わせの時にパーツに被りがあり表示が崩れの本番障害が発生！他も組み合わせてテストして確認しないといけなさそう！あなたはどのようにテストをしますか？頭の装備体の装備ネックレスブラウザ帽子A 体A ネックレスA Chrome 帽子B 体B ネックレスB safari 帽子C 体C ネックレスC Firefox 帽子D ネックレスD Edge

Slide 141

Slide 141 text

Slide 142

Slide 142 text

©MIXI 142 こんなときどうテストをしますか？パート2 特定のモードでa⚪ payの時だけ支払いができない本番障害が発生！　どうやら内部の実装は複雑になっていそうだ。支払い周りをもう一度がっつりテストをしないといけなさそうだ。あなたはどのようにテストをしますか？支払い手段支払期間モード(状態) OS クレジットカード月額払いモードA Android最低バージョンド⚪モ払い年払いモードB Android最新バージョンソフ⚪バンク簡単決済モードC iOS最低バージョン a⚪ pay モードD iOS最新バージョン

Slide 143

Slide 143 text

Slide 144

Slide 144 text

Slide 145

Slide 145 text

©MIXI 145 ペアワイズ法を使うと 192パターンあったテストがなんと頭の装備体の装備ネックレスブラウザ帽子A 体A ネックレスA Chrome 帽子B 体B ネックレスB safari 帽子C 体C ネックレスC Firefox 帽子D ネックレスD Edge 18パターンに !!

Slide 146

Slide 146 text

©MIXI 146 ペアワイズ法を使うと 128パターンあったテストがなんと支払い手段支払期間モード(状態) OS クレジットカード月額払いモードA Android最低バージョンド⚪モ払い年払いモードB Android最新バージョンソフ⚪バンク簡単決済モードC iOS最低バージョン a⚪ pay モードD iOS最新バージョン 17パターンに !!

Slide 147

Slide 147 text

Slide 148

Slide 148 text

Slide 149

Slide 149 text

©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% ※論文内では累積で表記

Slide 150

Slide 150 text

©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件

Slide 151

Slide 151 text

©MIXI 151 ペアワイズ法では2つの項⽬が全て組み合わされるようになっているペアワイズ法(オールペア法)では、全ての組み合わせを行うのではなく、そのうちの 2つの項目が全て組み合わされるように作られています。 IHコンロコンロ二口以上システムキッチンなしなしなしできればできればできれば必須必須必須全数組み合わせの場合は 3 x 3 x 3 = 27通り

Slide 152

Slide 152 text

©MIXI 152 ペアワイズ法では2つの項⽬が全て組み合わされるようになっている例 : IHコンロの「なし」とコンロ二口以上、システムキッチンの組み合わせ IHコンロの「なし」とコンロ二口以上の「なし」「できれば」「必須」の組み合わせができている IHコンロの「なし」とシステムキッチンの「なし」「できれば」「必須」の組み合わせができている

Slide 153

Slide 153 text

©MIXI 153 ペアワイズ法では2つの項⽬が全て組み合わされるようになっているつまりペアワイズ法は、問題が起こる確率が高いであろう「２つの組み合わせ」を網羅し、確率が低い「 3つ以上の組み合わせ」は捨てる技法です。テストは時間もコストも有限です。その制限の中で効果が最大になるように確認しようという方法でもあります。全数組み合わせをすべきか、ペアワイズ法をすべきか、リスクを考えて実施しましょう。

Slide 154

Slide 154 text

©MIXI 154 ⽤語：各項⽬が「因⼦」、項⽬の各値が「⽔準」組み合わせテストの話では「因子」「水準」という言葉が絶対に出ます。ややこしいですが覚えてしまいましょう。 IHコンロコンロ二口以上システムキッチンなしなしなしできればできればできれば必須必須必須項目にあたる部分が「因子」パラメーターと呼ぶこともある値にあたる部分が「水準」だたの値と呼ぶこともある

Slide 155

Slide 155 text

©MIXI 155 ペアワイズ法にはツールを使います。ペアワイズ法で効率が良い組み合わせを作るのは非常に難しいです。というよりツールがないとほぼ無理です。今回は GIHOZという無料でテスト技法を使うことができるサイトを用いて説明します。無料のツール : GIHOZ https://gihoz.com

Slide 156

Slide 156 text

©MIXI 156 ペアワイズ法にはツールを使います。使い方はとてもシンプルです。「新規作成」→「ペアワイズテスト」でテストを作ることができます。パラメータと書かれたところに因子 (IHコンロ、システムキッチンなど)を入力します。値のところに水準(なし、できれば、必須)を入力して「テストケースを生成」をクリックすれば完成です。因子を入力水準を入力

Slide 157

Slide 157 text

Slide 158

Slide 158 text

©MIXI 158 テストケースでFailed(NG)が出た場合の意味仮にテストケース6だけFailed(NG)になったとしましょう。このことから以下の組み合わせのいずれかに問題があることが言えます。・IHコンロできれば x コンロできれば・IHコンロできれば x システムキッチン必須・コンロできれば x システムキッチン必須・IHコンロできれば x コンロできれば x システムキッチン必須この組み合わせにフォーカスして再度テストをして問題領域を狭めていきましょう。 #6のみFailedになった場合

Slide 159

Slide 159 text

©MIXI 159 決められた組み合わせがある場合例えば今までの表に「ガスコンロ」の項目を追加したとします。そのとき、ガスコンロが「必須」の時は IHコンロは「なし」、 IHコンロが「必須」の時はガスコンロは「なし」にしたいです。そのときは「制約」を使いましょう。 (組み合わせテストの用語としては制約や禁則と言われています )

Slide 160

Slide 160 text

Slide 161

Slide 161 text

©MIXI 161 デシジョンテーブルテストと組み合わせテストの違いデシジョンテーブルテストでは、仕様などで決められた「規則のある組み合わせ」のテストを行います。「この条件とこの条件ならこういう結果になる」です。組み合わせテストは特に制限はありません。「組み合わせを合理的に減らす技法」です。デシジョンテーブルペアワイズ法で減らした組み合わせ

Slide 162

Slide 162 text

©MIXI 162 コラム：テスト技法なんて信⽤できない? テストは「どこにあるかわからないバグを効率的に見つけるには」といった統計学のお化けみたいな存在です。なので業界には大学の教授が多く、研究が進められていたりします。それら研究で「こうしたら確かに効果があった！」というものが査読されて「確かに再現性あるね」となって技法としてまとめられていたりします。先ほどの2因子の組み合わせまででバグがほぼ出てるよ、の研究に対して「2つの組み合わせしか網羅してないんでしょ。 3つは？4つは？なんか不安で不安でしようがないからやっぱり全数テストが正義」は感覚的であり、全体的な工数から見たリスクの管理ができていないように見えます。テストは時間も工数も有限ですので、先人が研究のもとに作った技法は大いに利用していきましょう。

Slide 163

Slide 163 text

©MIXI 163 質疑応答

Slide 164

Slide 164 text

Slide 165

Slide 165 text

Slide 166

Slide 166 text

©MIXI 166 どんなときに使えるの？ ● 何かしら変わるもの (コレからアレになったらどうなるんだろう？というテストをしたい時） ○ 例 ■ 同じモノだけど中の状態が変わっていくとき ● ログイン状態/非ログイン状態 ● エアコン (冷房/暖房/自動モードなど) ● (Therac-25の問題ももしかしたら拾えるのかも) ■ 画面遷移などで、データが保持される/クリアされるか... etc ● 氏名・住所入力画面→購入確認画面→購入完了画面

Slide 167

Slide 167 text

Slide 168

Slide 168 text

©MIXI 168 状態表状態と入力の関係を示し、有効&無効な可能性のある遷移を明確にした表。仕様の抜け漏れを発見することができます。イベント　/　状態計測準備中計測中一時停止中スタートボタン押下計測中一時停止中計測中リセットボタン押下 N/A N/A 計測準備中無効な遷移 (Not Applicable) 状態イベント上の状態で左のイベントがあったときに遷移する状態状態遷移図には現れない！仕様でここの考慮漏れなどがありがち！

Slide 169

Slide 169 text

©MIXI 169 じゃあ実際にどうやってテストするの？よく使われるのは「Nスイッチカバレッジ」です。 0スイッチカバレッジ（リンク網羅） 1スイッチカバレッジ 1回のイベントで遷移する経路をすべて網羅する前の状態から後状態までにスイッチが 1つある（状態を一つ経由する）状態遷移を網羅する例：計測準備中→計測中例：計測準備中→計測中→一時停止中

Slide 170

Slide 170 text

©MIXI 170 0スイッチカバレッジの場合のテストケース # 遷移前の状態イベント期待結果 1 計測準備中スタートボタン押下計測中になること 2 計測準備中リセットボタン押下計測準備中になること 3 計測中スタートボタン押下一時停止中になること 4 計測中リセットボタン押下計測中になること 5 一時停止中スタートボタン押下計測中になること 6 一時停止中リセットボタン押下計測準備中になること ● 計測準備中→計測中 ● 計測準備中→計測準備中 (状態表でしかわからない) ● 計測中→一時停止中 ● 計測中→計測中 (状態表でしかわからない) ● 一時停止中→計測中 ● 一時停止中→計測準備中

Slide 171

Slide 171 text

©MIXI 171 1スイッチカバレッジの場合のテストケース # 遷移前の状態イベント期待結果 1 計測準備中スタート→スタート一時停止中になること 2 計測準備中スタート→リセット計測中になること 3 計測準備中リセット→スタート計測中になること 4 計測準備中リセット→リセット計測準備中になること 5 計測中スタート→スタート計測中になること 6 計測中スタート→リセット計測準備中になること 7 計測中リセット→スタート一時停止中になること 8 計測中リセット→リセット計測中になること 9 一時停止中スタート→スタート一時停止中になること 10 一時停止中スタート→リセット計測中になること 11 一時停止中リセット→スタート計測中になること 12 一時停止中リセット→リセット計測準備中になること • 計測準備中→計測中→一時停止中 • 計測準備中→計測中→計測中 • 計測準備中→計測準備中→計測中 • 計測準備中→計測準備中→計測準備中 • 計測中→一時停止中→計測中 • 計測中→一時停止中→計測準備中 • 計測中→計測中→一時停止中 • 計測中→計測中→計測中 • 一時停止中→計測中→一時停止中 • 一時停止中→計測中→計測中 • 一時停止中→計測準備中→計測中 • 一時停止中→計測準備中→計測準備中

Slide 172

Slide 172 text

Slide 173

Slide 173 text

Slide 174

Slide 174 text

©MIXI 174 Nスイッチカバレッジの選び⽅まずは0スイッチカバレッジは行いましょう。それで怪しいところがあったり、バグがあったときに1スイッチカバレッジを実施するか判断しましょう。 ● 0スイッチカバレッジだと1回の遷移が確認できるが、1スイッチカバレッジのテストでしか発見できないバグもあります ○ 例： • 一度計測を開始すると、2回目以降計測準備中からスタートボタンで計測開始できない • 設定画面から前の画面に戻って再度設定に行ったらデータが保存されていない

Slide 175

Slide 175 text

©MIXI 175 状態遷移テストのメリット/デメリット ● メリット ○ 期待通りに遷移できない欠陥を見つけられる ○ 状態遷移図とあわせて状態表を使うことで、テストの漏れ・抜け防止とともに、仕様や設計の誤りを見つけられる ● デメリット ○ 状態をちゃんと設定できない（曖昧）だと、結局抜け漏れが発生する ○ 状態や遷移の数が多いと状態遷移図や状態表が複雑になる

Slide 176

Slide 176 text

©MIXI 176 質疑応答

Slide 177

Slide 177 text

Slide 178

Slide 178 text

©MIXI 178 演習：状態遷移図の作成 (時間があったらやってみて) ● 自動販売機 ○ 100円硬貨のみ受け付ける。 ○ ジュースは100円と150円の2種類のみである。（ジュースボタンが2個ある。） ○ ジュースボタンを押して購入後に残高があれば、おつりとして商品と同時に返却される。 ○ コイン返却ボタンがある。 ○ その他の仕様（ジュースの在庫、ジュースの温度、自動販売機内のおつりの有無、取り出し口の商品詰まり、偽造コインなど）は考慮しない。 ● 投入済金額（0円、100円、200円）を状態として状態遷移図と状態表を作成してみてください

Slide 179

Slide 179 text

Slide 180

Slide 180 text

Slide 181

Slide 181 text

©MIXI 181 演習の解答例：状態遷移テスト 2. 状態表状態イベント 0円 100円 200円 100円投入 100円 200円？？？コイン返却ボタン押下 N/A 0円 0円 100円ジュースボタン押下 N/A 0円 0円 150円ジュースボタン押下 N/A N/A 0円

Slide 182

Slide 182 text

©MIXI おすすめ書籍

Slide 183

Slide 183 text

©MIXI 183 おすすめ書籍ソフトウェアテスト教科書 JSTQB Foundation 第5版シラバス 2023対応テストの考え方について、全体的に学ぶことができます。 JSTQB(ISTQB)という国際的なテスト技術者の資格試験のための本でもあります。ソフトウェアテスト技法練習帳 ~知識を経験に変える 40問~ 状態遷移テストなどのテスト技法を、例題を使って手を動かしながら学ぶことができます。テスターちゃん (2巻のほうがテストの考え方がたくさん載っている ) 手前味噌ながら…。ソフトウェアテストの初学者に向けて書いた「マンガでわかる」系の本です。 1巻はテストエンジニアの業務系 (バグ票の書き方など )について、2巻がテストの考え方が多く載っています。社内に本が置いてあります。