【読了】知識ゼロから学ぶソフトウェアテスト（2023年版）
第2版（2013年版）からどの部分がアップデートされてるのか分かりにくい
個人的な理解だと、テストを含むQA活動には方向性の異なる2つのモチベがある
この2つともが「品質の確保」とかいう用語で表現されることが多いので、混乱を招いてる
①バグの検出
②品質の測定（定量化）、品質の保証（アシュアランス）、このレベルの品質はある（このレベルの品質はない）ということを合理的に主張すること
この本は①にフォーカスしていて、②については特に触れられてない印象
①と比べて②は数字遊びっぽくて価値を生んでる気がしないけど
英語でもいろいろ単語あるけど使い分けてるんかな
・verify
・validate
第1章 はじめに
バグをぜんぶ見つけるのは不可能
バグのないソフトウェアは存在しない
バグはプログラム中に偏在する
プログラムのある部分で未検出のバグがある確率は、その部分で既に検出されたバグ数に比例する
どの部分にバグが出やすいのか
どの部分にどのテスト手法を適用すればいいのか
品質のギャップ（要件と実測）は何か
ソースコードを書くよりもテストコードを書くほうが難しい（量も多くなる）
しかし、ソフトウェア業界では、開発コスト全体の4割程度をテストに書ければ充分だという商習慣になっている
そもそもバグとは
Error：期待結果との不一致、テスト実行者の期待結果の方が誤りである可能性もある
Failure：不具合に相当する現象
Fault：不具合の原因・所在・改修対象（コードのミスなど）
Mistake：不具合の原因を生じさせた過失
QA活動の種類とバグ発見率
認識しておくべき大切な事実は、1つのQA活動ではバグ発見率には限度があるということ
だからQA活動を組み合わせて、トータルのバグ発見率を挙げる必要がある
Prototyping： 30-80%
Informal (Casual) Design Review： 25-40%
Formal Design Review： 40-65%
Personal Code Review： 20-60%
Informal (Casual) Code Review： 20-35%
Formal Code Review (Code Inspection)： 45-70%
Regration Test： 15-30%
Unit Test： 15-50%
Function Component Test：20-35%
Integration Test： 25-40%
System Test： 25-55%
Beta Test (< 10site)： 25-40%
Beta Test (1000site <)： 60-75%
テストレベルとテストタイプが混在してて分かりにくいが（1990年当時にはテストがそこまで体系化されてなかったかもだが）、
コスパよさそうなQA活動は以下
・プロトタイピング：おそらくユーザに見てもらえるから？
・ベータテスト：これもユーザが関与するから？
・設計書やコードの公式レビュー：カジュアルだと自己テストになるからだめなのか？
第2章 ソフトウェアテストの基本 ―ホワイトボックステスト―
ウォーターフォール型では、ホワイトボックステスト（論理構造の正しさの検証）は開発者の仕事であり、テスターの仕事はブラックボックステスト（仕様と挙動の一致を検証）のみだった
アジャイル型では、イテレーション内で開発者もテスターも一緒にテストをするため、テスターでもホワイトボックステストのスキルが必要になった
制御パステスト法（カバレッジテスト法）
目安として、一般用ソフトウェアならブランチカバレッジ80%あればOK
使うカバレッジの種類
・ステートメントカバレッジ（命令網羅）：すべての命令文を実行する（命令文がない分岐は実行されない）
・ブランチカバレッジ（分岐網羅）：すべての分岐を実行する
カバレッジテストの注意点
・検出できないバグがある：ループ、割り込み（マルチタスクやマルチスレッド）、仕様が異常な場合、データが異常な場合、
・コストがかかる：カバレッジが100%に近づくほど、必要なテスト費用は等比級数的に増加していく
第3章 エンジニアが最もよく使う手法 ―ブラックボックステスト―
ソフトウェアの仕事
・入力
・計算
・出力
・保存
境界値テスト
昔は「同値分割」という発想があったが、今は不要（境界知能テストだけ考えればOK）
ディシジョンテーブル
入力と出力の関係が複雑な場合に使う
状態遷移テスト
GUIをテストしたい場合
まとめ
ブラックボックステストは最も簡単
楽して60%のバグを見つけ、その他のバグがなぜ発生したか、どう防止すればいいかを考えるのがテスターの役割
第4章 探索的テスト
古典的なテスト
・要件定義書やプログラム設計書のような、プロダクト自体ではないドキュメントをベースにテストケースを作る
・プロダクトがリリースされたら、テストケースに従ってテスト実行する
↓
問題点
・ドキュメントとプロダクトは一致していないのが普通
・深刻なバグは要求から漏れている可能性が高い、よって実装が要求と一致しているか比較してもあまり意味がない
・大量作成されるテストケースのうち、バグ検出に必要なテストケースはごくわずか（なぜならバグは偏在しているから、同じ深度で全体をテストするより、怪しい場所が見つかったらそこを深掘りしていった方がよい）
探索的テスト
・ソフトウェアを学習しながらテストする方法（古典的なテストでは、ドメイン知識をベースにすることはあっても、ソフトウェア構造をベースにすることは少ない）
・学習→設計→実行→報告を繰り返す
・学習では、ソフトウェア構造（論理構造、プログラムの設計思想など）を把握する。
・設計では、まず機能をリストアップし、フォーカスすべき弱そうなエリアをリストアップする。
・テストケースを作成しないことが多い：テストケース文書化に時間をかけすぎると学習や実効の時間が減ってしまう
・同一者が学習設計実行しないといけないので、ソフトウェアの基礎知識がない素人にはできない
↓
問題点
・専門知識が無いと探索できない。例えば、セキュリティ専門家でなければセキュリティ機能に対するテストはできない。機能テストなら、業務（ドメイン知識）に詳しいユーザ部門担当者なら探索できる。
・探索的テストはあくまでもバグを検出できるだけで、ソフトウェア全体の品質を保証できない
第5章 要求仕様のテスト
バグのないソフトウェアが存在しないように、抜け漏れのない要求仕様も存在しない
なので、「要求仕様には抜け漏れや誤りが含まれている」という前提でプロジェクトを進めなければならない
要求仕様を定義するコツ
①ユーザ要求を機能要件に落とし込む：要求を機能に分解する、要求間の依存関係を整理して、要求×機能のマトリクスを作成する（要求カバレッジを網羅する）
②要求に優先順にを付ける
③テスト可能な表現で文書化する：要求×テストケースのマトリクスを作成する
④非機能要求
「機能」とはなんなのか？
ソフトウェア機能
・画面：いちばん想像しやすい
・バッチ
・API：外部連携用
・帳票
ユーザーストーリー（アジャイル用語）は要件と何が違うのか
よくわからん
要件よりハイレベル（抽象的、曖昧）なのがユーザーストーリー
アジャイル開発案件の典型的な問題として、ユーザーストーリーのみ（要件のようなテスト可能性を考慮しない）で開発して、品質の低下（特にリリース間近の致命的バグ検出）が起こっているということらしい
第6章 非要求仕様（≒非機能要求）のテスト
非機能要件のテストが難しいのは、要求情報／設計情報／実装とのトレーサビリティが曖昧なため
非機能については要求すらない（当たり前品質）こともざらである
ソフトウェアで実装できない（インフラレベルで実装される）非機能要件もある
さらに、非機能品質というのは、トレードオフの関係がある
そのため、すべての非機能品質を同時に最高にすることはできない
（どんなにコストを投下しても）
一般的な非機能品質リスト
・正当性
・ユーザビリティ
・効率性
・信頼性
・完全性
・適応性
・正確性
・堅牢性
パフォーマンステスト（性能テスト）
非機能要件のなかでも深刻になるのがパフォーマンス（処理性能）
正しく処理できても、処理可能な件数、処理にかかる所要時間、処理にかかるCPU、連続稼働可能な時間、などに問題があると、使い物にならないことが多い
セキュリティテスト
・機密性：不正アクセスされない
・可用性：いつでもアクセスできる
・完全性：改竄されない
セキュリティテストの方法論は確立の途上にある
テスト担当者とは別種のスキル（セキュリティの専門性）が必要
ファジングテスト：セキュリティテストにおけるランダムなテスト
ペネトレーションテスト
OWASP ZAP：Webアプリの自動テストツール
SonerQube：コード静的解析ツール
信頼度成長曲線、MTBF（平均故障間隔）
正直、信頼度成長曲線よりも、MTBF（平均故障間隔）の方がメトリクスとして適してると思う
信頼性工学の教義ではバグは有限
ソフトウェア工学の教義ではバグは無限
信頼性の構成要素
・成熟性：maturity
・障害許容性：fault tolerance
・回復性：recoverability
MTBF（平均故障間隔）
信頼度成長曲線
テストケース実行数に対して曲線を描いても無意味
https://www.jasst.jp/archives/jasst08e/pdf/A2-1.pdf
横軸は「テスト項目数」にしないと意味ない
横軸を「経過日数」とかにすると、テストの終盤で日ごとの消化項目数が減ってきた際にグラフが寝てきてしまう（この理屈なら、テストをやめればいずれ必ず収束する）
収束を見る場合に、横軸に日付を使った場合、テストをしていないからバグが出ないのか、テストをしてもバグが出ないのかの区別がつかないという問題がある。
https://www.jasst.jp/symposium/jasst13tokyo/pdf/C5-3_paper.pdf
https://no-plan.hatenablog.jp/entry/2018/05/13/143101
第7章 テスト自動化
自動化が成功するケースはごくわずか
以下のような場合、自動化はほぼ失敗する（メンテコストが嵩むため、人海戦術で手動でやったほうが早い）
・GUIが絡むテスト
・数日に1回程度しか実行しないテスト
自動化が有効な稀な例
・負荷テスト：負荷をかけるのにはツールを使ったほうが早い
第8章 テストウェアの運用
テスト費用（リリース前）だけを最小化しても意味がない
最小化すべきは、「テスト費用（リリース前）＋サポート費用（リリーズ後）」である
IEEE829（ソフトウェアテスト文書の標準規格）
第9章 ソフトウェア品質管理
測定できないものは管理できない
MTBF（平均故障間隔）
バグ修正にかかる時間
バグ修正にかかる時間が短くならないということは、それだけ根が深い（設計レベルの）バグだということ
類似のバグが多く潜んでる徴候あり
単位期間あたりのコード行数変分
コード行数が急変した場合、単純に回収規模が大きいということ
なのでモニタリングしておく意味はある
バグ密度（？）
懐疑的
サイクロマチック複雑度
複雑なコードにはバグが生じやすい
アジャイルメトリックス
ウォーターフォール開発と同じレベルで品質を担保しようとした場合、アジャイル開発でかかるテストコストは増加する
アジャイル開発が向いているのは、バグって使えなくなっても、すぐに復旧すればOKなアプリ。
MTTR（平均復旧時間）が短いことが重要
第10章 新しいテスト技術
AIに対するテスト
既存のテスト手法が使えない
メタモルフィックテスト
ニューロンカバレッジ
AIを使ったテスト
発展途上
カオスエンジニアリングテスト
Netflixが考案？
システム構成要素をランダムに止めて、システムがどんな状況に陥るかを確認するテスト
10.2 複雑なシステムのテスト ─テストは無限大─
完
補足
テストレベル
テストフェイズ、テスト工程、とか呼ばれているものとほぼ同義
・単体テスト（UT、コンポーネントテスト）
・結合テスト（IT、ソフトウェア適格性確認テスト）：テスト環境とテストデータを使う
・内部結合テスト
・外部結合テスト
・システムテスト（ST、総合テスト）：本番に近い環境とデータを使う
・受け入れテスト（UAT）
・ユーザ部門受け入れテスト
・運用部門受け入れテスト：IT-BCPまで含める場合もあり
テストタイプ
テスト手法とか呼ばれてるものとほぼ同義
・ブラックボックステスト
・機能要件テスト
・非機能要件テスト
・性能要件テスト：スループットやレスポンスタイムが要件を満たしているかを見る
・連続稼働テスト：連続稼働した場合の挙動（性能変化や異常）を見る
・ストレステスト：CPUやストレージなどが少ない場合の挙動を見る
・ボリュームテスト：大きなサイズのデータを処理した場合の挙動を見る
・障害許容性テスト：全ての障害を発生させて挙動を見る
・ホワイトボックステスト
・変更部分に対するテスト：回帰テスト、など