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

# 参考s料
- 「家づくりで理解する要求明確化の勘どころ～システム構築を成功させる要件定義のポイント～」
- https://www.ipa.go.jp/archive/files/000065172.pdf

- ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01
- https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

Transcript

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

2. テストの全般について話をします
 
 その後ユニットテストの話をします
 What is it?
3. 事業開発でも受託開発でも
 
 基本は一緒
 What is it?
4. 今日はサブスレさん向けなので
 
 事業開発ではなく、受託開発寄りに話す
 What is it?
5. 自分のアプリケーションが
 
 正しく動作している
 What is it?
6. ちゃんと確認できていますか？
 
 何を根拠にしますか？
 What is it?
7. 正しい動作＝意図した動作
 
 
 What is it?
8. 正しい動作＝意図した動作
 
 
 What is it?
9. 正しい動作≠意図した動作
 
 
 What is it?
10. 正しい動作≠意図した動作
 ↓
 バグは意図していないところにある
 What is it?
11. どんなに頑張っても
 
 完璧にすることは難しい
 What is it?
12. 正しく動作している
 
 と言える状態に限りなく近づける
 What is it?
13. 今日はそのために必要な
 
 テスト(検査)の話をします
 What is it?
14. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
15. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
16. 自己紹介
 曽根 壮大（39歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

17. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
18. アプリケーションが
 
 正しく動作している
 正しく動作しているとはなにか
19. 『正しく動作』は
 
 客観的な表現ではない
 正しく動作しているとはなにか
20. • 体調が問題ない
 • 画面が正常に表示されていること
 • クリックして異常がないこと
 客観的な表現では無い例
21. • 体調が問題ない
 • 画面が正常に表示されていること
 • クリックして異常がないこと
 客観的な表現では無い例 体調の良し悪しはその人の主観による 体温が37.5℃未満であること、頭痛が発生していな いこと、など具体的にする必要がある
22. • 体調が問題ない
 • 画面が正常に表示されていること
 • クリックして異常がないこと
 客観的な表現では無い例 正常な状態を知らないといけないが、エラーが表示 するのは正常？ 意図した表示状態を具体的するに必要がある。
23. • 体調が問題ない
 • 画面が正常に表示されていること
 • クリックして異常がないこと
 客観的な表現では無い例 同様に正常な状態を把握していないと異常は判断 することができない。 正常に503を出していることもある。
24. 『正しく動作』を
 
 具体的にする必要がある
 正しく動作しているとはなにか
25. 正しい動作を明記する
 ||
 仕様を明記する
 正しく動作しているとはなにか
26. 1. 要望 
 2. 要求 
 3. 要件 
 4. 仕様
 正しく動作しているとはなにか 上から下にブレイクダウンしていく 場合によっては往復もする 要求と要件は一緒として扱われることも多い
27. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件 → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか
28. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件 → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか ステークホルダー(顧客やPO)が持っている要望の例 - 会員制のECサイトがやりたい（機能） - 高速に表示したい（非機能） - 商品を沢山売りたい（機能・非機能）
29. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件 → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか ステークホルダーと決めること - 会員登録できること（機能） - 商品を注文できること（機能） - 在庫を管理できること（機能 - 素早く表示できること（非機能要件） - 世界中のユーザが利用できること - Webとスマホアプリとして動作すること（機能要件） …etc
30. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件 → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか 要件定義 - 会員登録機能 - 保存したい情報とか - マイページ - 表示したい内容とか - 管理画面 - CSV登録の有無とか - 実行環境 - Chromeだけでいいのかとか - 表示速度の基準値 - 表示して100ms以内に表示するとか …etc
31. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件 → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか 各要件を実装するために必要な仕様の定義 - 会員登録はSSOに対応すること - 会員登録時に生年月日を取得すること - 氏名は姓と名で分けて保存すること - パスワードは20桁以上の半角英数字を使うこと - パスワードとメールアドレスは暗号化して保存すること …etc
32. 要件にするときに、
 
 現実は制約と前提条件がある
 正しく動作しているとはなにか
33. 詳しくはIPA資料を読もう
 
 これは読みやすいのでオススメ
 正しく動作しているとはなにか 「家づくりで理解する要求明確化の勘どころ～システム構築を成功させる要件定義のポイント～」 https://www.ipa.go.jp/archive/files/000065172.pdf
34. 仕様が明確に定義できていますか？
 
 
 正しく動作しているとはなにか
35. 仕様が明確に定義できていますか？
 ↓
 仕様が曖昧だと「正しい動作」はわからない
 正しく動作しているとはなにか
36. 正しく動作とは
 
 
 正しく動作しているとはなにか
37. 正しく動作しているとは
 
 • 要望・要求を満たす要件である
 • 要件を満たした仕様である
 • 仕様通りに動作する
 正しく動作しているとはなにか
38. 正しく動作しているとは
 
 • 要望・要求を満たす
 • 要件を満たした仕様である
 • 仕様通りに動作する
 正しく動作しているとはなにか 要望・要求を満たしていない場合は、ユーザの欲しいものではない 要件漏れは納品時に問題になりがち
39. 正しく動作しているとは
 
 • 要望・要求を満たす
 • 要件を満たした仕様である
 • 仕様通りに動作する
 正しく動作しているとはなにか 要件を満たしていない仕様は所謂 ”仕様バグ” 業務知識が足りなかったりすると発生する 考慮漏れなどもここに該当する
40. 正しく動作しているとは
 
 • 要望・要求を満たす要件である
 • 要件を満たした仕様である
 • 仕様通りに動作する
 正しく動作しているとはなにか 一般的なバグ 仕様や要件が曖昧なときに「仕様通りではない」と言われて、ここに なる場合もある 今日のフォーカスするポイントはここ
41. 明確な仕様に対し、
 
 仕様通りに動作していることを目指す
 正しく動作しているとはなにか
42. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
43. この章でのテストは
 
 テスト(検査)のこと
 テストが守ってくれること、出来ないこと
44. テストと言っても
 
 いろんなテストのがある
 テストが守ってくれること、出来ないこと
45. 詳しく知りたい人は
 
 JSTQBのシラバスがオススメ
 テストが守ってくれること、出来ないこと ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
46. • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。 
 • 故障を引き起こし、欠陥を発見する。 
 • 求められるテスト対象のカバレッジを確保する。 
 • ソフトウェア品質が不十分な場合のリスクレベルを下げる。 
 • 仕様化した要件が満たされているかどうかを検証する。 
 • テスト対象が契約、法律、規制の要件に適合していることを検証する。 
 • ステークホルダーに根拠ある判断をしてもらうための情報を提供する。 
 • テスト対象の品質に対する信頼を積み上げる。 
 • テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。 
 ソフトウェアテストの典型的な目的 引用元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
47. テストとデバッグは
 
 別の活動である
 テストが守ってくれること、出来ないこと 引用元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
48. テストは問題（欠陥）見つける行為
 
 デバッグは問題（欠陥）を取り除く行為
 テストが守ってくれること、出来ないこと
49. • 要件の欠陥
 • 設計の欠陥
 • コードの欠陥
 • 脆弱性
 などに気づける
 テストが守ってくれること、出来ないこと
50. テストは欠陥を見つけることができるが
 
 欠陥をなくすことはできない
 テストが守ってくれること、出来ないこと
51. • テストは欠陥があることは示せるが、欠陥がないことは示せない
 • 全数テストは不可能
 • 早期テストで時間とコストを節約
 • 欠陥の偏在
 • 殺虫剤のパラドックス
 • テストは状況次第
 • 不具合ゼロの落とし穴
 ソフトウェアテストの7原則 引用元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
52. テストにはレベルとタイプがある
 
 
 テストが守ってくれること、出来ないこと
53. 1. コンポーネントテスト(ユニットテスト)
 メソッドや関数などの小さいコンポーネント（ユニット）単位で行うテスト。 
 2. コンポーネント統合テスト(ユニット統合テスト)
 ユニット間のインターフェイスや相互処理を対象にする。モデルの呼び出しやビジネスロジックの機能テ ストなど。
 3. システムテスト
 E2Eテスト使った機能テストなどシステム全体を対象とする。シナリオテストなども含む。 
 4. システム統合テスト
 他のシステム、外部サービスとの連携を対象にする。本番環境に近い環境の方がよりよいテストができ る。
 5. 受け入れテスト
 妥当性の確認などを行い、ビジネスニーズを満たしているか確認する。 
 テストレベル 参照元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
54. テストレベル 一般的に言われるユニットテスト コンポーネント統合テスト コンポーネントテスト
55. 1. 機能テスト
 コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテスト する
 2. 非機能テスト
 コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」 をテストする
 3. ブラックボックステスト
 対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。 
 4. ホワイトボックステスト
 対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステ ムが意図どおりかを確認する。 
 他にも色々ある（シナリオテストとか
 テストタイプ 参照元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
56. テストレベル 一般的に言われるユニットテスト コンポーネント統合テスト コンポーネントテスト 機能テスト 一般的に機能テストを ユニットテストとして実装する 非機能テスト ホワイト ボックステスト ブラック ボックステスト
57. 機能が追加・変更された場合
 
 
 テストが守ってくれること、出来ないこと
58. 機能が追加・変更された場合
 ↓
 確認テストとリグレッションテスト
 テストが守ってくれること、出来ないこと
59. 確認テスト
 ↓
 対象の欠陥を正常に修正したことの確認
 テストが守ってくれること、出来ないこと
60. リグレッションテスト
 ↓
 変更による悪影響の確認
 テストが守ってくれること、出来ないこと
61. テストレベル 一般的に言われるユニットテスト コンポーネント統合テスト コンポーネントテスト 回帰テスト 確認テスト 機能テストを繰り返し実行すれば 回帰（リグレッション）テストになる
62. リグレッションテストでは
 
 欠陥が無いことは証明できない
 テストが守ってくれること、出来ないこと
63. 変更は常に行われ、リリースされる
 
 だからリグレッションテストが必要
 テストが守ってくれること、出来ないこと
64. 変更は常に行われ、リリースされる
 
 だからリグレッションテストが必要
 テストが守ってくれること、出来ないこと 変更によって他の機能が壊れていないか 確認をするために必要
65. リグレッションテストは何度も実行される
 
 だから自動化して、繰り返し実行したい
 テストが守ってくれること、出来ないこと
66. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テストのコツ
 6. まとめ
 あじぇんだ
67. ユニットテストの話
 
 
 コードを書く、テストを書く
68. 1. コンポーネントテスト(ユニットテスト)
 メソッドや関数などの小さいコンポーネント（ユニット）単位で行うテスト。 
 2. コンポーネント統合テスト(ユニット統合テスト)
 ユニット間のインターフェイスや相互処理を対象にする。モデルの呼び出しやビジネスロジックの機能テ ストなど。
 3. システムテスト
 E2Eテスト使った機能テストなどシステム全体を対象とする。シナリオテストなども含む。 
 4. システム統合テスト
 他のシステム、外部サービスとの連携を対象にする。本番環境に近い環境の方がよりよいテストができ る。
 5. 受け入れテスト
 妥当性の確認などを行い、ビジネスニーズを満たしているか確認する。 
 テストレベル 参照元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01 ここの話
69. コードを書くために必要な準備
 
 
 コードを書く、テストを書く
70. コードを書くために必要な準備
 ↓
 要件・仕様を満たす設計が必要
 コードを書く、テストを書く
71. コードを書くために必要な準備
 ↓
 要件・仕様を満たす設計が必要
 コードを書く、テストを書く 多くの場合、要件定義 →基本設計→詳細設計と段階を踏んでいく ドキュメントは必須ではないが、 設計は必ず必要
72. 設計・実装をテスト(検査)する
 
 
 コードを書く、テストを書く
73. 設計・実装をテスト(検査)する
 
 
 コードを書く、テストを書く 実装対象が何をするか（機能を）コンポーネント単位で テストすることを一般的にユニット (単体)テストと呼ぶ
74. ユニットテストを毎回確認する
 ↓
 リグレッションテストになる
 コードを書く、テストを書く
75. ユニットテストをつかって
 
 様々なテストタイプをテスト(検査)する
 コードを書く、テストを書く
76. 1. 機能テスト
 コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテスト する
 2. 非機能テスト
 コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」 をテストする
 3. ブラックボックステスト
 対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。 
 4. ホワイトボックステスト
 対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステ ムが意図どおりかを確認する。 
 他にも色々ある（シナリオテストとか
 テストタイプ（再掲） 参照元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
77. • 機能テスト
 ◦ できること
 ◦ できてはダメなこと
 ◦ できないこと
 • 非機能テスト
 ◦ 場合による
 • ブラックボックス
 ◦ 境界値分析・同値分割法 
 ◦ デシジョンテーブル（入力の全組み合わせ） 
 ◦ 状態遷移
 • ホワイトボックステスト
 ◦ ステートメントテスト（正常系） 
 ◦ ブランチカバレッジ（分岐網羅） 
 ◦ コンディションカバレッジ(複数の分岐を網羅する) 
 ◦ 改良条件判定カバレッジ MC/DC(最終結果が変わるケースの分岐を網羅する) 
 ユニットテストに書くべきこと 参照元：Foundation Level シラバス 日本語版 Version 2023V4.0.J01
78. 必要な機能の仕様が明確なら
 
 
 コードを書く、テストを書く
79. 必要な機能の仕様が明確なら
 ↓
 先にテストコードが書ける（TDD)
 コードを書く、テストを書く
80. テストコードを書くことで
 
 仕様を明確にしていく
 コードを書く、テストを書く
81. テストコードを先に書く
 
 つまりそれは設計をするということ
 コードを書く、テストを書く
82. 機能テストのコードを書くことで
 
 自分が意図した仕様を明記できる
 コードを書く、テストを書く
83. コードを書く、テストを書く
84. コードを書く、テストを書く
85. 少なくとも自分のコードが
 
 何をしたかったかはユニットテストに書く
 コードを書く、テストを書く
86. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
87. テスト(検査)のコツ
 
 
 テスト(検査)のコツ
88. ユニットテストを書いてても
 
 マニュアルテストは必要
 テスト(検査)のコツ ユニットテストはコンポーネントのテストでしかないのでシステムテストは必要 そこも自動化したいなら E2Eテストが必要
89. コードは意図したとおりには動かない
 
 書いたとおりに動く
 テスト(検査)のコツ
90. テスト(検査)のコツ コードの振る舞い 意図した振 る舞い 既知の 問題 意図した振 る舞い 意図した振 る舞い 意図した振 る舞い テスト(検査)が可能な部分 意図していない部分 軽微なバグなど
91. コードは意図したとおりには動かない
 
 書いたとおりに動く
 テスト(検査)のコツ これはテスト(検査)も一緒。 テストコードを盲信しない。
92. 意図のチェックの精度をあげる
 
 
 テスト(検査)のコツ
93. 意図のチェックの精度をあげる
 ↓
 経験ベースのテスト(検査)
 テスト(検査)のコツ
94. • アプリケーションの過去の動作状況
 • 開発者が起こしやすいエラーの種類と、
 そのエラーに起因する欠陥の種類
 • 他の類似アプリケーションで発生した故障の種類
 経験ベースのテスト(検査)
95. 欠陥を直すとき、確認テスト(検査)は
 
 先に再現するテストコードを書く
 テスト(検査)のコツ
96. テストのコツ
97. ユーザビリティのテスト(検査)は
 
 自動化したテストコードでは見えにくい
 テストのコツ
98. ユーザビリティのテスト(検査)は
 
 自動化したテストコードでは見えにくい
 テストのコツ なのでマニュアルテストは必要
99. 自動化した機能テストはローカルで実行
 
 他の自動テストはCIで自動フルテスト
 テストのコツ
100. 自動化した機能テストはローカルで実行
 
 他の自動テストはCIで自動フルテスト
 テストのコツ シフトレフトアプローチ コードが壊れたことは素早くフィードバックを受け取りたい
101. ユニットテストが書きやすい本体のコード
 ||
 責務がシンプルで小さいコード
 テストのコツ
102. ユニットテストが書きやすい本体のコード
 
 責務がシンプルで小さいコード
 テストのコツ シンプルで小さいコードは扱いやすい テスト容易性の高いコードは高凝集・疎結合になりやすい
103. コードの変更でテストコードが壊れたら
 
 直す前に不具合を疑い、意図を確認する
 テストのコツ
104. コードの変更でテストコードが壊れたら
 
 直す前に不具合を疑い、意図を確認する
 テストのコツ 仕様変更なのか、回帰バグなのかちゃんと確認する最後のチャンス
105. 無いよりはあったほうがいいが
 
 使わないテストコードは不要なので捨てる
 テストのコツ
106. 1. 自己紹介
 2. 正しく動作しているとはなにか
 3. テストが守ってくれること、出来ないこと
 4. コードを書く、テストを書く
 5. テスト(検査)のコツ
 6. まとめ
 あじぇんだ
107. 良い仕様が
 
 良い設計を生む
 まとめ
108. 要件・仕様は明確にしましょう
 
 そのためには要望を把握しましょう
 まとめ
109. 仕様を満たすコードを書くために
 
 ユニットテストを書きましょう
 まとめ
110. テストコードを書いてもバグは無くならない
 
 だから自動テスト以外も大事
 まとめ
111. テストコードを書いてもバグは無くならない
 
 だから自動テスト以外も大事
 まとめ オブザーバビリティのような不具合に素早く気付く方法とか
112. ユニットテストは
 
 意図の範囲しかテスト(検査)してくれません
 まとめ
113. ユニットテストは
 
 意図の範囲しかテスト(検査)してくれません
 まとめ 予想できる範囲は人の想像力依存する。 経験を積むためにも実践し、確認テスト (検査)のコードを書く。 そして人のコードやテスト (検査)のコード、ドキュメントを読む。
114. まとめ
115. “大事なのは できる という経験を得ること”
 
 – 宇宙兄弟 145話 
 まとめ
116. まずは眼の前のプロダクトに
 
 ユニットテストを書くところから
 まとめ
117. 明日の自分のために
 
 今日の自分がテスト(検査)をする
 まとめ
118. 昨日の自分に誇れる
 
 今日の自分になろう
 まとめ
119. ご清聴ありがとうございました
 
 
 まとめ