Chapter1 テストのアイデアを生み出す
・関係者と品質に関する全体像を定義しよう
1.それはすべて機能するか、主な機能、主な技術的品質は何か？
2.それはうまく機能するか、主要なパフォーマンス、セキュリティ、スケーラビリティの側面は何か？
3.それは実際に使えるか、主な作業で役立っている
...続きを読むことを示す指標は何か？
4.それは役に立つか、実際の作業で役立っていることを示す指標は何か？
5.それは成功したか、実行する価値があることを示すビジネス指標は何か、財政的制約の範囲内で運営されているか？
・フィーチャーではなく、ケイパビリティ(能力)を探索しよう
・「常にある/決してない」から考えよう
・感情を利用しよう
①スカリーパス(恐怖):このパスをたどると、家は本当に壊され、他のすべてのものはそれとともに破壊されます。ステークホルダーにとって最もりスクの高い領域を洗い出してください。機能や変更について、各ステークホルダーを最も怖がらせるものを考えてください。
②ハッピーパス(素直):素直なケースを説明する主要な具体例であり、ポジティブなテストです。これは、私たちが考え得る振る舞いと機能の特定の領域を通る最も単純なパスです。また、これは最も単純なユーザーの操作であり、(おそらく最初の実行を除いて)毎回成功することが期待されます。
③アングリーパス(怒り):アングリーパスでは、アプリケーションの反応が悪くなったり、エラーが発生したり、うまく再生できず腹を立てたりするようなテストを探します。これらは、検証エラー、不正な入力、論理エラーである可能性があります。
④ディリンクウェントパス(非行):認証、承認、許可、データの機密性など、テストが必要なセキュリティリスクを考慮します。
⑤エンプレシングバス(恥ずかしさ):全体的に大きな恥ずかしさを引き起こすものを考えてください。それらがビジネスの損失のような即時の大惨事ではない場合でも、それらは内部または外部の信頼性に重大な影響を与える可能性があります。これは、かつてテストジャーナルで見たような、「Qality」のような単純なスペルミスかもしれません(テスターの喜ぶ顔を考えてみてください)。
⑥ディソレトバス(寂しさ):これは、アプリケーションまたはコンポーネントに不完全な状態を引き起こします。ゼロ、ヌル、ブランクまたは欠落デー夕、切り捨てられたデータ、および、「寂しい」反応を引き起こす可能性のある不完全な入力やファイル、またはイベントを試してください。
⑦フォゲットフルパス(忘却):メモリとCPUをすべて使い切り、アプリケーションが何も保存できない状態にしてください。それにより、どれほどデータが保存できないかやデータが失われ始めるか、そのデータが保存されたばかりのものかすでに保存されていたものかどうかを確認してください。
⑧インディサイスィブバス(優柔不断):優柔不断なユーザーであり、1つの行動方針に完全に落ち着くことができないことをシミュレートしてください。オンとオフを切り替えたり、ブラウザーの[戻る]ボタンをクリックしたり、データが半分入力されたパンくずリスト間を移動してください。これらの種類のアクションは、システムが最後の状態として記憶しているものにエラーを引き起こす可能性があります。
⑨グリーディーパス(食欲):すべてを選択し、すべてのボックスにチェックマークを付け、すべてのオプションにオプトインし、すべてを注文し、通常、機能を可能な限りすべてロードして、動作を確認してください。
⑩ストレスフルパス(ストレス):現在のシステムの規模を確認し、機能とコンポーネントの限界点を見つけてください。そして、ビジネスボリュームの将来の変化を予測できるようにします。
・実現手段と同様に、ユーザーがメリットを享受できるかどうかも確認しよう
・計測の難しい品質でも定量化に努めよう
・テストのアイデアをACCマトリクスで整理しよう
・横断的関心ごとに対応するリスクをチェックリストとして使おう
・信頼境界を文書化しよう
・普段からログとコンソールの出力を監視しよう
・テストセッションをモブで行おう
・議論のボトルネックにならないよう、ペンを十分に用意しよう
・競合相手の様子を探ろう
Chapter2 適切なチェックの設計
・主要な具体例に焦点を当てよう
・適切に機能する具体例を機能しない具体例と対比させよう
・「どうやって」ではなく、「何を」テストするのか説明しよう
・テストシナリオの期待値には数式ではなく具体的な値を記述しよう
・入力同値クラスだけでなく出力同値クラスも考慮しよう
・入力と出力を明確に分離しよう
・「代わりに何が起こるか」と尋ねよう
・Given-When-Thenの順序を守ろう
・1つのテストでは1つの関心ごとを扱おう
・境界条件が多すぎるときは、モデリングの問題を疑おう
・テストシナリオに登場する表はできるだけ小さくしよう
・3種類の競合する力のバランスを取ろう
・最初にアサーションを書こう
・技術面のチェックとビジネス面のチェックを分けよう
・手動テストを自動化するのはやめよう
Chcpter3 テスト容易性の向上
・同時にデータベースを使う可能性のあるテストはトランザクションでラップしよう
・非同期データはテストのあとにクリーンアップするのではなく、テストの前にセットアップしよう
・CPU時間ではなく論理的なビジネスの時間を導入しよう
・アトミックな外部リソースを提供しよう
・時間経過を待つのではなく、イベントを待とう
・テストからデータ生成処理を分離しよう
・ユーザーインタフェースを通じたやり取りは最小にしよう
・ビジネスの意思決定、ワークフロー、技術的な相互作用にテストを分類しよう
・コストの高いテストは本番環境でのメトリクスを使おう
Chapter4 大規模なテストスイートの管理
・自動テストを開発者の責任としよう
・他のチームと一緒にテストを設計しよう
・テストを作業項目に沿ってグループ化したり構成したりすることは避けよう
・テストは製品コードと一緒にバージョン管理しよう
・自動化パターンの具体例を集めたギャラリーを作ろう
・テストの目的からテストの範囲を切り離そう
・厳格なカバレッジ目標を持たないようにしよう
・テストの有効期間を計測しよう
・テストコードは書くためではなく読むために最適化しよう
・テストには検索しやすい名前を付けよう
・導入部でテストの目的を説明しよう
・主要な具体例のテストと付加的なテストは分離しよう
・定期的に問題を発生させてそれを見つけられるかどうか試そう
Chapter5 日本語版追記アイデア
・すべての自動テストはCI/CDパイプラインからも実行しよう
・リリースしなくとも、テスト環境へのデプロイと、自動テストでの確認を頻繁に行おう
・自動テストの実行結果を継続的に収集・可視化しよう
・自動テストは頻繁に実行し、割れ窓はすぐ塞ごう
・リスクは皆で考えよう 
アジャイル開発の中で、いかに早くフィードバックを得ながらより高い品質を確保していくか。