アプリケーションが正しく動作するということ - 自動テスト編 / Automated Testing

Slide 1

Slide 1 text

サブスレッド勉強会アプリケーションが  正しく動作するということ    - 自動テスト編 

Slide 2

Slide 2 text

テストの全般について話をします    その後ユニットテストの話をします  What is it?

Slide 3

Slide 3 text

事業開発でも受託開発でも    基本は一緒  What is it?

Slide 4

Slide 4 text

今日はサブスレさん向けなので    事業開発ではなく、受託開発寄りに話す  What is it?

Slide 5

Slide 5 text

自分のアプリケーションが    正しく動作している  What is it?

Slide 6

Slide 6 text

ちゃんと確認できていますか？    何を根拠にしますか？  What is it?

Slide 7

Slide 7 text

正しい動作＝意図した動作      What is it?

Slide 8

Slide 8 text

正しい動作＝意図した動作      What is it?

Slide 9

Slide 9 text

正しい動作≠意図した動作      What is it?

Slide 10

Slide 10 text

正しい動作≠意図した動作  ↓  バグは意図していないところにある  What is it?

Slide 11

Slide 11 text

どんなに頑張っても    完璧にすることは難しい  What is it?

Slide 12

Slide 12 text

正しく動作している    と言える状態に限りなく近づける  What is it?

Slide 13

Slide 13 text

今日はそのために必要な    テスト(検査)の話をします  What is it?

Slide 14

Slide 14 text

1. 自己紹介  2. 正しく動作しているとはなにか  3. テストが守ってくれること、出来ないこと  4. コードを書く、テストを書く  5. テスト(検査)のコツ  6. まとめ  あじぇんだ

Slide 15

Slide 15 text

Slide 16

Slide 16 text

自己紹介  曽根壮大（39歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO    そ  ● 日本PostgreSQLユーザ会勉強会分科会担当  ● 3人の子供がいます（長女、次女、長男）  ● 技術的にはWeb/LL言語/RDBMSが好きです  ● コミュニティが好きたけ  ね  とも 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

アプリケーションが    正しく動作している  正しく動作しているとはなにか

Slide 19

Slide 19 text

『正しく動作』は    客観的な表現ではない  正しく動作しているとはなにか

Slide 20

Slide 20 text

● 体調が問題ない  ● 画面が正常に表示されていること  ● クリックして異常がないこと  客観的な表現では無い例

Slide 21

Slide 21 text

● 体調が問題ない  ● 画面が正常に表示されていること  ● クリックして異常がないこと  客観的な表現では無い例体調の良し悪しはその人の主観による体温が37.5℃未満であること、頭痛が発生していないこと、など具体的にする必要がある

Slide 22

Slide 22 text

● 体調が問題ない  ● 画面が正常に表示されていること  ● クリックして異常がないこと  客観的な表現では無い例正常な状態を知らないといけないが、エラーが表示するのは正常？意図した表示状態を具体的するに必要がある。

Slide 23

Slide 23 text

● 体調が問題ない  ● 画面が正常に表示されていること  ● クリックして異常がないこと  客観的な表現では無い例同様に正常な状態を把握していないと異常は判断することができない。正常に503を出していることもある。

Slide 24

Slide 24 text

『正しく動作』を    具体的にする必要がある  正しく動作しているとはなにか

Slide 25

Slide 25 text

正しい動作を明記する  ||  仕様を明記する  正しく動作しているとはなにか

Slide 26

Slide 26 text

1. 要望   2. 要求   3. 要件   4. 仕様  正しく動作しているとはなにか上から下にブレイクダウンしていく場合によっては往復もする要求と要件は一緒として扱われることも多い

Slide 27

Slide 27 text

1. 要望 → 欲しいもの  2. 要求 → 欲しいもの達成の条件  3. 要件 → 達成するためのシステム的な条件  4. 仕様 → システム的な条件の実現方法  正しく動作しているとはなにか

Slide 28

Slide 28 text

1. 要望 → 欲しいもの  2. 要求 → 欲しいもの達成の条件  3. 要件 → 達成するためのシステム的な条件  4. 仕様 → システム的な条件の実現方法  正しく動作しているとはなにかステークホルダー(顧客やPO)が持っている要望の例 - 会員制のECサイトがやりたい（機能） - 高速に表示したい（非機能） - 商品を沢山売りたい（機能・非機能）

Slide 29

Slide 29 text

1. 要望 → 欲しいもの  2. 要求 → 欲しいもの達成の条件  3. 要件 → 達成するためのシステム的な条件  4. 仕様 → システム的な条件の実現方法  正しく動作しているとはなにかステークホルダーと決めること - 会員登録できること（機能） - 商品を注文できること（機能） - 在庫を管理できること（機能 - 素早く表示できること（非機能要件） - 世界中のユーザが利用できること - Webとスマホアプリとして動作すること（機能要件） …etc

Slide 30

Slide 30 text

1. 要望 → 欲しいもの  2. 要求 → 欲しいもの達成の条件  3. 要件 → 達成するためのシステム的な条件  4. 仕様 → システム的な条件の実現方法  正しく動作しているとはなにか要件定義 - 会員登録機能 - 保存したい情報とか - マイページ - 表示したい内容とか - 管理画面 - CSV登録の有無とか - 実行環境 - Chromeだけでいいのかとか - 表示速度の基準値 - 表示して100ms以内に表示するとか …etc

Slide 31

Slide 31 text

1. 要望 → 欲しいもの  2. 要求 → 欲しいもの達成の条件  3. 要件 → 達成するためのシステム的な条件  4. 仕様 → システム的な条件の実現方法  正しく動作しているとはなにか各要件を実装するために必要な仕様の定義 - 会員登録はSSOに対応すること - 会員登録時に生年月日を取得すること - 氏名は姓と名で分けて保存すること - パスワードは20桁以上の半角英数字を使うこと - パスワードとメールアドレスは暗号化して保存すること …etc

Slide 32

Slide 32 text

要件にするときに、    現実は制約と前提条件がある  正しく動作しているとはなにか

Slide 33

Slide 33 text

詳しくはIPA資料を読もう    これは読みやすいのでオススメ  正しく動作しているとはなにか「家づくりで理解する要求明確化の勘どころ～システム構築を成功させる要件定義のポイント～」 https://www.ipa.go.jp/archive/files/000065172.pdf

Slide 34

Slide 34 text

仕様が明確に定義できていますか？      正しく動作しているとはなにか

Slide 35

Slide 35 text

仕様が明確に定義できていますか？  ↓  仕様が曖昧だと「正しい動作」はわからない  正しく動作しているとはなにか

Slide 36

Slide 36 text

正しく動作とは      正しく動作しているとはなにか

Slide 37

Slide 37 text

正しく動作しているとは    ● 要望・要求を満たす要件である  ● 要件を満たした仕様である  ● 仕様通りに動作する  正しく動作しているとはなにか

Slide 38

Slide 38 text

正しく動作しているとは    ● 要望・要求を満たす  ● 要件を満たした仕様である  ● 仕様通りに動作する  正しく動作しているとはなにか要望・要求を満たしていない場合は、ユーザの欲しいものではない要件漏れは納品時に問題になりがち

Slide 39

Slide 39 text

正しく動作しているとは    ● 要望・要求を満たす  ● 要件を満たした仕様である  ● 仕様通りに動作する  正しく動作しているとはなにか要件を満たしていない仕様は所謂 ”仕様バグ” 業務知識が足りなかったりすると発生する考慮漏れなどもここに該当する

Slide 40

Slide 40 text

正しく動作しているとは    ● 要望・要求を満たす要件である  ● 要件を満たした仕様である  ● 仕様通りに動作する  正しく動作しているとはなにか一般的なバグ仕様や要件が曖昧なときに「仕様通りではない」と言われて、ここになる場合もある今日のフォーカスするポイントはここ

Slide 41

Slide 41 text

明確な仕様に対し、    仕様通りに動作していることを目指す  正しく動作しているとはなにか

Slide 42

Slide 42 text

Slide 43

Slide 43 text

この章でのテストは    テスト(検査)のこと  テストが守ってくれること、出来ないこと

Slide 44

Slide 44 text

テストと言っても    いろんなテストのがある  テストが守ってくれること、出来ないこと

Slide 45

Slide 45 text

詳しく知りたい人は    JSTQBのシラバスがオススメ  テストが守ってくれること、出来ないこと ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2023V4.0.J01 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

Slide 46

Slide 46 text

● 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。   ● 故障を引き起こし、欠陥を発見する。   ● 求められるテスト対象のカバレッジを確保する。   ● ソフトウェア品質が不十分な場合のリスクレベルを下げる。   ● 仕様化した要件が満たされているかどうかを検証する。   ● テスト対象が契約、法律、規制の要件に適合していることを検証する。   ● ステークホルダーに根拠ある判断をしてもらうための情報を提供する。   ● テスト対象の品質に対する信頼を積み上げる。   ● テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。   ソフトウェアテストの典型的な目的引用元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 47

Slide 47 text

テストとデバッグは    別の活動である  テストが守ってくれること、出来ないこと引用元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 48

Slide 48 text

テストは問題（欠陥）見つける行為    デバッグは問題（欠陥）を取り除く行為  テストが守ってくれること、出来ないこと

Slide 49

Slide 49 text

● 要件の欠陥  ● 設計の欠陥  ● コードの欠陥  ● 脆弱性  などに気づける  テストが守ってくれること、出来ないこと

Slide 50

Slide 50 text

テストは欠陥を見つけることができるが    欠陥をなくすことはできない  テストが守ってくれること、出来ないこと

Slide 51

Slide 51 text

● テストは欠陥があることは示せるが、欠陥がないことは示せない  ● 全数テストは不可能  ● 早期テストで時間とコストを節約  ● 欠陥の偏在  ● 殺虫剤のパラドックス  ● テストは状況次第  ● 不具合ゼロの落とし穴  ソフトウェアテストの7原則引用元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 52

Slide 52 text

テストにはレベルとタイプがある      テストが守ってくれること、出来ないこと

Slide 53

Slide 53 text

1. コンポーネントテスト(ユニットテスト)  メソッドや関数などの小さいコンポーネント（ユニット）単位で行うテスト。   2. コンポーネント統合テスト(ユニット統合テスト)  ユニット間のインターフェイスや相互処理を対象にする。モデルの呼び出しやビジネスロジックの機能テストなど。  3. システムテスト  E2Eテスト使った機能テストなどシステム全体を対象とする。シナリオテストなども含む。   4. システム統合テスト  他のシステム、外部サービスとの連携を対象にする。本番環境に近い環境の方がよりよいテストができる。  5. 受け入れテスト  妥当性の確認などを行い、ビジネスニーズを満たしているか確認する。   テストレベル参照元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 54

Slide 54 text

テストレベル一般的に言われるユニットテストコンポーネント統合テストコンポーネントテスト

Slide 55

Slide 55 text

1. 機能テスト  コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテストする  2. 非機能テスト  コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」をテストする  3. ブラックボックステスト  対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。   4. ホワイトボックステスト  対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステムが意図どおりかを確認する。   他にも色々ある（シナリオテストとか  テストタイプ参照元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 56

Slide 56 text

テストレベル一般的に言われるユニットテストコンポーネント統合テストコンポーネントテスト機能テスト一般的に機能テストをユニットテストとして実装する非機能テストホワイトボックステストブラックボックステスト

Slide 57

Slide 57 text

機能が追加・変更された場合      テストが守ってくれること、出来ないこと

Slide 58

Slide 58 text

機能が追加・変更された場合  ↓  確認テストとリグレッションテスト  テストが守ってくれること、出来ないこと

Slide 59

Slide 59 text

確認テスト  ↓  対象の欠陥を正常に修正したことの確認  テストが守ってくれること、出来ないこと

Slide 60

Slide 60 text

リグレッションテスト  ↓  変更による悪影響の確認  テストが守ってくれること、出来ないこと

Slide 61

Slide 61 text

テストレベル一般的に言われるユニットテストコンポーネント統合テストコンポーネントテスト回帰テスト確認テスト機能テストを繰り返し実行すれば回帰（リグレッション）テストになる

Slide 62

Slide 62 text

リグレッションテストでは    欠陥が無いことは証明できない  テストが守ってくれること、出来ないこと

Slide 63

Slide 63 text

変更は常に行われ、リリースされる    だからリグレッションテストが必要  テストが守ってくれること、出来ないこと

Slide 64

Slide 64 text

変更は常に行われ、リリースされる    だからリグレッションテストが必要  テストが守ってくれること、出来ないこと変更によって他の機能が壊れていないか確認をするために必要

Slide 65

Slide 65 text

リグレッションテストは何度も実行される    だから自動化して、繰り返し実行したい  テストが守ってくれること、出来ないこと

Slide 66

Slide 66 text

1. 自己紹介  2. 正しく動作しているとはなにか  3. テストが守ってくれること、出来ないこと  4. コードを書く、テストを書く  5. テストのコツ  6. まとめ  あじぇんだ

Slide 67

Slide 67 text

ユニットテストの話      コードを書く、テストを書く

Slide 68

Slide 68 text

Slide 69

Slide 69 text

コードを書くために必要な準備      コードを書く、テストを書く

Slide 70

Slide 70 text

コードを書くために必要な準備  ↓  要件・仕様を満たす設計が必要  コードを書く、テストを書く

Slide 71

Slide 71 text

コードを書くために必要な準備  ↓  要件・仕様を満たす設計が必要  コードを書く、テストを書く多くの場合、要件定義 →基本設計→詳細設計と段階を踏んでいくドキュメントは必須ではないが、設計は必ず必要

Slide 72

Slide 72 text

設計・実装をテスト(検査)する      コードを書く、テストを書く

Slide 73

Slide 73 text

設計・実装をテスト(検査)する      コードを書く、テストを書く実装対象が何をするか（機能を）コンポーネント単位でテストすることを一般的にユニット (単体)テストと呼ぶ

Slide 74

Slide 74 text

ユニットテストを毎回確認する  ↓  リグレッションテストになる  コードを書く、テストを書く

Slide 75

Slide 75 text

ユニットテストをつかって    様々なテストタイプをテスト(検査)する  コードを書く、テストを書く

Slide 76

Slide 76 text

1. 機能テスト  コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテストする  2. 非機能テスト  コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」をテストする  3. ブラックボックステスト  対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。   4. ホワイトボックステスト  対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステムが意図どおりかを確認する。   他にも色々ある（シナリオテストとか  テストタイプ（再掲）参照元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 77

Slide 77 text

● 機能テスト  ○ できること  ○ できてはダメなこと  ○ できないこと  ● 非機能テスト  ○ 場合による  ● ブラックボックス  ○ 境界値分析・同値分割法   ○ デシジョンテーブル（入力の全組み合わせ）   ○ 状態遷移  ● ホワイトボックステスト  ○ ステートメントテスト（正常系）   ○ ブランチカバレッジ（分岐網羅）   ○ コンディションカバレッジ(複数の分岐を網羅する)   ○ 改良条件判定カバレッジ MC/DC(最終結果が変わるケースの分岐を網羅する)   ユニットテストに書くべきこと参照元：Foundation Level シラバス日本語版 Version 2023V4.0.J01

Slide 78

Slide 78 text

必要な機能の仕様が明確なら      コードを書く、テストを書く

Slide 79

Slide 79 text

必要な機能の仕様が明確なら  ↓  先にテストコードが書ける（TDD)  コードを書く、テストを書く

Slide 80

Slide 80 text

テストコードを書くことで    仕様を明確にしていく  コードを書く、テストを書く

Slide 81

Slide 81 text

テストコードを先に書く    つまりそれは設計をするということ  コードを書く、テストを書く

Slide 82

Slide 82 text

機能テストのコードを書くことで    自分が意図した仕様を明記できる  コードを書く、テストを書く

Slide 83

Slide 83 text

コードを書く、テストを書く

Slide 84

Slide 84 text

コードを書く、テストを書く

Slide 85

Slide 85 text

少なくとも自分のコードが    何をしたかったかはユニットテストに書く  コードを書く、テストを書く

Slide 86

Slide 86 text

Slide 87

Slide 87 text

テスト(検査)のコツ      テスト(検査)のコツ

Slide 88

Slide 88 text

ユニットテストを書いてても    マニュアルテストは必要  テスト(検査)のコツユニットテストはコンポーネントのテストでしかないのでシステムテストは必要そこも自動化したいなら E2Eテストが必要

Slide 89

Slide 89 text

コードは意図したとおりには動かない    書いたとおりに動く  テスト(検査)のコツ

Slide 90

Slide 90 text

テスト(検査)のコツコードの振る舞い意図した振る舞い既知の問題意図した振る舞い意図した振る舞い意図した振る舞いテスト(検査)が可能な部分意図していない部分軽微なバグなど

Slide 91

Slide 91 text

コードは意図したとおりには動かない    書いたとおりに動く  テスト(検査)のコツこれはテスト(検査)も一緒。テストコードを盲信しない。

Slide 92

Slide 92 text

意図のチェックの精度をあげる      テスト(検査)のコツ

Slide 93

Slide 93 text

意図のチェックの精度をあげる  ↓  経験ベースのテスト(検査)  テスト(検査)のコツ

Slide 94

Slide 94 text

● アプリケーションの過去の動作状況  ● 開発者が起こしやすいエラーの種類と、  そのエラーに起因する欠陥の種類  ● 他の類似アプリケーションで発生した故障の種類  経験ベースのテスト(検査)

Slide 95

Slide 95 text

欠陥を直すとき、確認テスト(検査)は    先に再現するテストコードを書く  テスト(検査)のコツ

Slide 96

Slide 96 text

テストのコツ

Slide 97

Slide 97 text

ユーザビリティのテスト(検査)は    自動化したテストコードでは見えにくい  テストのコツ

Slide 98

Slide 98 text

ユーザビリティのテスト(検査)は    自動化したテストコードでは見えにくい  テストのコツなのでマニュアルテストは必要

Slide 99

Slide 99 text

自動化した機能テストはローカルで実行    他の自動テストはCIで自動フルテスト  テストのコツ

Slide 100

Slide 100 text

自動化した機能テストはローカルで実行    他の自動テストはCIで自動フルテスト  テストのコツシフトレフトアプローチコードが壊れたことは素早くフィードバックを受け取りたい

Slide 101

Slide 101 text

ユニットテストが書きやすい本体のコード  ||  責務がシンプルで小さいコード  テストのコツ

Slide 102

Slide 102 text

ユニットテストが書きやすい本体のコード    責務がシンプルで小さいコード  テストのコツシンプルで小さいコードは扱いやすいテスト容易性の高いコードは高凝集・疎結合になりやすい

Slide 103

Slide 103 text

コードの変更でテストコードが壊れたら    直す前に不具合を疑い、意図を確認する  テストのコツ

Slide 104

Slide 104 text

コードの変更でテストコードが壊れたら    直す前に不具合を疑い、意図を確認する  テストのコツ仕様変更なのか、回帰バグなのかちゃんと確認する最後のチャンス

Slide 105

Slide 105 text

無いよりはあったほうがいいが    使わないテストコードは不要なので捨てる  テストのコツ

Slide 106

Slide 106 text

Slide 107

Slide 107 text

良い仕様が    良い設計を生む  まとめ

Slide 108

Slide 108 text

要件・仕様は明確にしましょう    そのためには要望を把握しましょう  まとめ

Slide 109

Slide 109 text

仕様を満たすコードを書くために    ユニットテストを書きましょう  まとめ

Slide 110

Slide 110 text

テストコードを書いてもバグは無くならない    だから自動テスト以外も大事  まとめ

Slide 111

Slide 111 text

テストコードを書いてもバグは無くならない    だから自動テスト以外も大事  まとめオブザーバビリティのような不具合に素早く気付く方法とか

Slide 112

Slide 112 text

ユニットテストは    意図の範囲しかテスト(検査)してくれません  まとめ

Slide 113

Slide 113 text

ユニットテストは    意図の範囲しかテスト(検査)してくれません  まとめ予想できる範囲は人の想像力依存する。経験を積むためにも実践し、確認テスト (検査)のコードを書く。そして人のコードやテスト (検査)のコード、ドキュメントを読む。

Slide 114

Slide 114 text

まとめ

Slide 115

Slide 115 text

“大事なのはできるという経験を得ること”    – 宇宙兄弟 145話   まとめ

Slide 116

Slide 116 text

まずは眼の前のプロダクトに    ユニットテストを書くところから  まとめ

Slide 117

Slide 117 text

明日の自分のために    今日の自分がテスト(検査)をする  まとめ