「知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書」を読んでみたメモ

はじめに

環境が変わり開発に関わっていくことになったため、テスト知識０の状態で、
「知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書」を読んでみました。
読みながらのメモを書いた記事になります。

読書メモ

1章

• ソフトウェアで大事なのはどの機能でバグが出やすいか、その部分に対してどのようなテスト手法を適用すれば十分な品質が得られるか知ること
• 全くバグのないソフトウェアは存在しない、完全なテスト手法が存在しないから
• 完璧でなく十分な品質をもつソフトウェアを目指すテスト手法を学ぶ

2章 ホワイトボックステスト

• ホワイトボックステスト
  • プログラムの論理構造が正しいかを解析するテスト
• ウォーターフォールでは開発者がホワイトボックステスト、テスト担当者がブラックボックステストをする流れがあった
  • アジャイルは開発者とテスト担当者の協業で短いイテレーションで回していくいく必要がある（CI/CDなどを利用）
• ホワイトボックステストでは論理構造の正しさのみをテストするため、ソフトウェアの使用が間違っていることから起こるバグは発見できない
• ホワイトボックステストとブラックボックステストの両方とも大事
• 制御パステスト
  • プログラムのふるまいを把握し、どのように制御実行されていくかテストすること
  • ステートメントカバレッジ
    • 条件分岐などで少なくとも一回実行
    • 弱いテスト
  • ブランチカバレッジ
    • 分岐コードに対して両方ともテストする
    • 網羅性は高い
    • カバレッジ基準は80%が理想（著者基準）
• カバレッジ100％でも見つけられないバグはある
  • ループバグ、要求仕様の間違い、データに関するバグなど
• カバレッジテストは予算がかかる
  • ブランチカバレッジがおすすめだけど、Googleはステートメントカバレッジを採用

3章 ブラックボックステスト

• ソフトウェアは4つの仕事しかしてない
  • 入力処理、出力処理、データ保存、計算
• NA＝適用不可
• ブラックボックステスト
  • ソースコードを見ずにテストを行う手法
  • 境界値分析法
    • 入力処理と出力処理に対して行うテスト
    • 境界値にはバグが発生しやすい
      • 設定数値の上限や下限など
    • On-Offポイント法
      • 異なる処理が行われる一番近い2地点でテストする
  • ディシジョンテーブル
    • すべての入力の組み合わせを表にし、その入力に対する動作や出力を記載
    • 漏れ減るが膨大なソフトだと実施が大変
  • 状態遷移テスト
    • 状態Aから状態Bに遷移するときに入力がある
    • 状態遷移マトリックスを使用（状態とイベントを書く）
    • 期待していない状態に遷移するバグや遷移しないバグを発見できる
    • テストが複雑化するため通信プロトコル機能があるときにおすすめ
• テストで見つけられるバグは60％くらい

4章 探索的テスト

• 探索的テスト
  • ソフトウェア機能を学習しながら、テスト設計と実行を同時に行う
  • 大まかな流れ
    • どういうソフトウェアであるべきか判定基準を決める
    • 機能のリストアップ
    • 弱いエリアを見つける
    • 各機能のテスト及びバグを記録
    • 継続的なテストの実行
  • スキルある人が探索的テストを行うとコード網羅率がテストケースベースのテストよりも上がる

5章 要求仕様のテスト

• 要求のエラーは最も修正に費用がかかる
• 要求仕様の４つの重要な要素
  • 漠然たるユーザー要求を要求仕様に落とし込む
    • ユーザー要求と機能要求を分ける
      • ユーザー要求：こんなソフト作って
      • 機能要求：ファイルダウンロードなど
    • 要求が完璧でないことを前提として修正コストを含める
  • 要求に優先順位をつける
    • 必須や重要機能を先につくる
  • テスト可能な要求を書く
    • テストケース作成可能な要求
    • ユーザー要求を詳細レベルや具体化まで分解する必要がある
      • ステート（データ等）→条件又はアクション→特定された結果
      • 目安はUMLの図に落とし込めるくらい
  • 非機能要求
• ユーザーストーリー
  • 顧客と開発チームにとって理解できるもの
  • 短く簡潔で会話の約束事（交渉可能）
  • ユーザーに対して価値のを与えるストーリー
  • 要求仕様とは別

６章 非機能要件について

• 非機能要求には妥協とあきらめが必要
• パフォーマンステスト
  • 想定通りの性能が出るかテストすること
  • テストケースは要求定義を逸脱したものにする必要がある
  • 定期的にパフォーマンステストをする、パフォーマンステスト中に出るバグは深刻
• セキュリティテスト
  • プログラム構造の不備をつき、制御を奪ったり不能にしたりする
  • プログラムデータの不備をつき、データを改ざんする
  • ファジングテスト
    • ツール：OWASP ZAP
• 信頼性とは
  • MTBF：平均故障間隔

7章 自動化について

• 自動化テストは自動化用のコード作成やメンテナンスについても考慮が必要
• Googleの自動化ピラミッド
  • 単体テスト、インテグレーションテスト、UIテスト

8章 ソフトウェアテスト運用の基本

• テスト計画の立て方
  • テストに掛かった費用+サポートにかかる費用＝最小値
  • 致命的なバグなどで回収が発生した場合は上記の限りではない
• テストプランテンプレート
  • IEEE829
• アジャイルでのテスト計画書
  • テスト計画で以下3つを明確にしテストケースを作成する
  • 属性：ソフトウェアがユーザーに対して何を提供するか
    • カーナビなら目的地まで最適に案内するなど
    • 属性を担保するためのテストケースをどう生成するかを計画
  • パーツ：ソフトウェアのどの部分をテストするか
    • テストしない部分を決めることも大事
  • 目的：ユーザーの目的に対して何を提供するか
    • ナビなら交通情報など
• テストケースの書き方
  • いつ誰がやっても同じような結果が得られるように書く
• テスト管理ツールを使うのもよい、アメリカだと良く使ってる

9章 テストのアウトプット

• テストはアウトプットが見えにくい
• 指標の要素
  • 誤差がなく私情に左右されないもの
  • ソフトウェアの品質を代表するもの
• バグの数 バグメトリクス
  • バグの重要度に分け、性質も考慮にいれる
  • モジュールやコンポーネント毎のバグの数
    • 品質の低い箇所を見つけれる可能性がある
• コード行数
  • コード行数からバグ密度を計測する
• アジャイルにおいてのアウトプット
  • 顧客満足度
  • MTTR：平均修復時間
  • For Keysメトリクス
    • デプロイ速度
    • 変更のリードタイム
      • コミットから本番環境稼働までの時間
    • 変更障害率
    • サービス復元時間

10章 AI

• AIに対して行うテストは難しい
  • AIテストはテストできないもののテスト
• AIを使ったテストは今後伸びる
• カオスエンジニアリング
  • 意図的に壊して、壊れにくさを鍛えるテスト
  • Netflixが提唱

総評

本のタイトル通りテスト知識0で読みましたがとても分かりやすかったです。
色々なテスト手法があり今後開発の現場でテストする機会があるときに活かせそうです。
具体的なテスト手法については本書では触りだけのような書き方ではあったため、本書の基礎知識を土台に他の知識もつけて行こうと思います。