先日図書館に行ってきたときに目について、気になったのでそのまま借りてきた1冊
最近はテストコードはAIに書いてもらっているものの、きちんと指示をしないとテストになっていないテストコードが生成されるためきちんとテストの基礎を抑えておいて、AIに指示できるようになりましょう！というのが狙いです
まとめ
タイトルの通り、基本的なテストの手法や計測すべき事項、AIテストなどの最近の話題に触れられていて、テストの基本を押さえることが出居ました。
ただ、知識0といいつつ何の説明もなく専門用語がちりばめられていたり、語り口調(○○みたいな・・・)の記載が随所に見られるので、本当に知識ゼロで読み進めるのは少し難しい印象を感じました。
章別、覚えておきたいところ
1章：はじめに
完全無欠のテストを実施することはテストパターンが増えすぎるため不可能！
また、よくテストは新人にやらせる見たな風潮があるが、テストこそ経験豊富なベテランが行うべき(不具合が残ったまま出荷すると大きな損害となるため)
2章：ソフトウェアテストの基本
ブラックボックステスト：入力と出力だけに注目する
ホワイトボックステスト：プログラムの内部構造に注目する
制御パステストの種類
ステートメントカバレッジ：制御文(if文など)を最低1回は実行する
ブランチカバレッジ：制御文の全パターンを実行する
カバレッジは75%以上が推奨
カバレッジでは検出されないバグがあることを覚えておく（外部から受け取るデータの不正など）
3章：エンジニアが最もよく使う手法
テストは「入力」「出力」「データ保存」「計算」の4種類のテストが行えれば良い
境界値テストは境界となる値を使用する
if(a < 5)のようなプログラムをテストするときは4,5といった値を使用する
複雑な入出力テストはディシジョンテーブルを利用する
GUIは状態遷移マトリックスを利用するとよい
ブラックボックステストのまとめ
入力エリアがある：境界値テスト
入力エリアが複数あり、相互に影響している：ディシジョンテーブル
GUI自体の遷移がある：状態遷移テスト
4章：探索的テスト
探索的テストはテスト設計とテスト実行を同時に行うこと
製品を学習しつつテストを設計、実行し結果を報告、そのサイクルで成熟していく という流れを同時並行で行う
要はテスト対象の製品を理解し、仕様の穴（メニューからは操作できないが、同等の機能を実行するショートカットからだと実行できるなど）を見つけるのが大切という理解
探索的テストはクリテリア（テスト成功、テスト失敗とする条件）を決める
探索的テストはユーザービリティに関する検出に特に有効
5章：要求仕様のテスト
要求を書き出すときは「テスト可能な要求」である必要がある
例：多くのファイルを処理したい→多く、ではテストできない
同時に20ファイルまで開けるようにしたい→テスト可能
ユーザーストーリーも作成する
ユーザーストーリーはプロダクトオーナーと開発チームの約束事として機能する
TDDについても、この章で触れられていた(テスト駆動開発)
筆者としてTDDは推していたが日本国内での導入事例が少ないことを嘆いていた
6章：非機能要求のテスト
非機能要求とは
・パフォーマンス
・セキュリティ
・データ容量
などのこと
ファジングツールや静的解析ツールなどを利用してテストを行う
信頼度成長曲線という用語についても触れられていた(時間の経過とともにバグ数も減っていく曲線)
7章：テストの自動化という悪魔
テスト自動化の失敗についての章
要は「自動化すべきところと、しないほうが良いところを見極めましょう」という内容
単体テストレベルは自動化したほうが良い
逆にUIテストなどの場合は自動化しないほうが良い(変化が多いため、テストコードのメンテナンスにコストがかかるため)
8章：ソフトウェアテスト運用の基本
テストプランの書き方：IEEE829というテストプランの書式が用意されており、これに沿って作るのが良いとのこと
(多少のカスタマイズは可能)
テスト計画について、終盤に人員を投入して早く終わらせようとするのは悪手(デスマプロジェクトに見られる)
製品への知識が乏しい人員が増えたところで、教育にコストがかかったり、理解不足のままテストを行うことで品質が低下する可能性がある
テストケースの書き方として、「誰がテストしても同じ状況が再現できる」ように記載する必要がある
例：メモ帳のテストの場合
ダメなパターン：ファイルを保存する
良いパターン：メニューの保存ボタンからファイルを保存し、名称をtest.txtとしてC:\に保存する
9章：ソフトウェア品質管理の基本
品質を目に見えるものにするため、メトリクスを計測する必要がある
計測可能なものとして
・バグ数
・バグ修正にかかった時間
・コードの複雑度(と複雑度に応じたバグ数)
など
メトリクスは品質を図るもので、人に適用してはいけない
例：バグをたくさん見つけた人に報奨金→プログラマとテスターが組んで、わざとバグを仕込む不正が発生した
10章：新しいテスト技術
AIのようなアプリケーションは、従来のようなテスト手法が利用できない
(入力パラメータに対して、出力パラメータが一定ではないため)
その場合メタモルフィックテストといった新しい手法を用いる
メタモルフィックテスト：似たような入力を行い、似たような出力になるのか確認するテスト
例：パンダの画像をAIに入力→AIがパンダと答える→OK
パンダの画像を反転してAIに入力→AIがクマと答える→NG
カオスエンジニアリングについても触れられていた
カオスエンジニアリングはシステムの一部に障害が発生したときに、ほかシステムに影響が出ないか確認するテスト
AWSにはカオスエンジニアリングを実行するためのツールが準備されているとのこと
以上
個人的なまとめでした
今後AIにテストコード作成の指示を出すときは、それぞれの関数の仕様を把握したうえで境界チェックやカバレッジ、特に重要な処理を意識して支持を出したいところです
