【読書レポート】ソフトウェア品質を高める開発者テスト

## 第1章
### 上流品質
本書の目的は2つ
- Shift Leftすること（Agileで品質を担保すること）
- 楽をすること

ソフトウェアの開発プロセスは、計画・設計→開発・ビルド→テスト→デプロイ・リリースの順に進められる。Shift Leftとは、品質の向上活動を計画・設計段階（というかなるべく前の段階）に持っていく活動のこと。

### アジャイルでの品質
アジャイルテストでは以下の4つの概念の定義が必要
- 開発者の品質フレームワーク
- テスト担当者の品質フレームワーク
- 開発者の具体的な作業指針
- テスト担当者の具体的な作業指針

作業指針では、どのようにメトリクスを達成するかの具体的な基準を定義する。例えば、「コード網羅率を何%達成すべき」「複雑度はいくつ以下」など。

## 第2章
### 上流品質活動

上流品質の担保には？
- 要求仕様・ユーザーストーリーの明確化
- クラスや関数構造をシンプルに保つ
- 単体・結合テストの実行
- レビューの実施

### さぼる・逆らう人のための上流テスト講座

独立行政法人情報処理推進機構が出したグラフでは、出荷後の品質が高いソフトウェアは上流工程でのバグの発見数の割合が高いことを示している。

### 上流品質と残バグのリスク

Putnam曰く、「早期のコードインスペクション、レビュー、繰返し型開発、周期的構築などに重点を置くと欠陥摘出曲線は開発の初期に移動する」

システム開発で避けなければならないのはこの2点
- プロジェクトの後半でバグをつぶすコストは、前半のコストの数倍かかる → 効率が悪い = お金がかかる
- プロジェクトの後半でバグをつぶすと、つぶしきれず出荷後のバグになるリスクがある

またバグの修正は後のフェーズになるほど、より多くの工数がかかるようになる。

## 第3章
### 開発者がこれだけは知っておくべきテスト手法
- 境界値テスト
    - プログラムで境界と呼ばれる場所には常にバグが潜んでいるので、境界値の近くは詳しくテストする必要がある
- 状態遷移テスト
    - 状態をモデル化しテストする手法
- 組み合わせテスト

他にも
- 単体テスト
- 探索的テスト
- 統合テスト
- システムテスト
などもできると良い

## 第4章
### コードベースの単体テスト
コードベースの単体テストを厳密にいえば、**関数の網羅率を計測しロジックの確からしさを確認するホワイトバックステスト**になる。本章では、これをコードベースの単体テストと呼ぶ。

単体テストでは以下をチェックする。
- プログラムを実行する中で、システム上異常な振る舞いを行わない
- 入力値とそれに対応する期待値を出力すること
- すべての分岐が正しく処理されること（境界値テスト）

### 命令網羅（C0カバレッジ）
このテストは「すべての分岐が正しく処理されること」が達成されないため、実はあまり役に立たない
行ごとにテストが通過したかどうかを見る

### 分岐網羅（C1カバレッジ）
分岐ごとにテストが通過したかどうかを見る

### よくある単体テストの間違い
網羅性だけ気を付けていればよいわけではない。いかにも気を付ける
- 関数のin/outをチェックする
- 関数の責務が達成されている（十分分離されている？）

### 知っているようで知らないコードベースの単体テストの書き方
Kent Beck曰く、「プログラミングとテストを両方行う方が、プログラミングだけよりも早くソフトウェア開発を完成できる」

テスト駆動開発のサイクル
- 赤：失敗するテストを書く
- 緑：テストに通るような最小限のコードを書く
- リファクタリング

### 網羅率 - コードベースの単体テストの成否を計測する

Googleの網羅率の内部ガイドラインでは、
- 網羅率 60%：許容範囲
- 網羅率 75%：推奨
- 網羅率 90%：模範的

## 第5章 単体テストの効率化 - 楽勝単体テスト
### どこを単体テストすればよいか？

- 単体テストのやる個所を絞る
    - 直近の変更回数に重みを付け、過去に変更されたファイルはそれほど重みをつけない
    - HotSpotの大きさの計算方法は以下
```math
HotSpot := \sum^n_{i=0} \frac{1}{1 + e - 12ti + 12}
```
- ファイルを2つにぶった切る
    - 直近の変更回数とファイル行数が長いものから単体テストを行う
    - HotSpot値と複雑度の閾値を定め、両方閾値を超えた場合はリファクタリングをする

## 第6章 機能単位の単体テスト
### 開発者がやるべき単機能のテスト

コード網羅をして、単機能のテストをするのは開発者の責務
機能単位のテスト手法の基本は以下。
- 単機能境界値
- 組み合わせ

## 第7章 リファクタリング
リファクタリングの目的は何か？ → リファクタリングなしには上流・アジャイル品質が担保できないから

### やはり複雑です、そのコード！ 書けません、単体テスト

単体テストの流れ
- ファイルの複雑度が高ければまずは2つとか3つにファイルをぶった切る。シンプルなぶった切りだけなら単体テストはいらない
- それでも複雑度が下がらない場合、既存の複雑な関数コードに対して単体テストを書く
- Mockを書く
- 網羅率を測定し、網羅率が75%になるまで、単体テストを追加する
- リファクタリングを行う
- 単体テストを実行し、結果が同じか確認する

リファクタリングで注意する点
- 複雑度を下げる
    - McCabe20以下、WMC（クラス当たりの平均メソッド数）は20以下とする
    - またCKメトリクスの値が高いものは、リファクタリングすべき
- 関数の出口を1つにする
- MVCを分離する
    - テストの界面をGUIに持たない
- ファイルのコードを短くする

## 第8章 コードレビュー
### コードレビューとは
レビューとは、基本的に他人の書いたものを指摘するのではなく、本人が気づくことに重点を置くもの。

レビューはテストよりも効率的なバグ発見手法である（ほんまか？）

なるべくコードレビューの前に機械が検出できるバグは検出しておいて、人は本当に最小限のことしかやらない仕組みにしておく。

### ペアプログラミング
ペアプロ適用のガイドラインでは、開発者のレベルとタスクの難易度でペアプロに向いているかどうかを決める。

- 開発者のレベル: 初級
    - タスク難易度: 簡単 → YES
    - タスク難易度: 難しい → YES
- 中級
    - 簡単 → NO
    - 難しい → YES
- 上級
    - 簡単 → NO
    - 難しい → NO

またペアプロはソースコードの品質を向上させる。

## 第9章 統合テスト
### APIテストとAPIバグ密度の考え方
APIに入力パラメータがある場合は、そのパラメータに対して境界値テストをして、できればそのAPIを様々な形で叩き、状態遷移まで網羅できれば完璧。

コード網羅率を追加しない代わりに、どのくらい境界を網羅したかを計測することをおすすめしている。

### カオスエンジニアリング
カオスエンジニアリングとは、部分的にCPUを止めるなどして動作を確認する手法。

## 第10章 システムテストの自動化
### 最悪のシステムテスト
メンテナンスのコストがかかるから、キャプチャー・リプレイの自動化やめろ

### 妄想な自動化
自動化にもコストがかかる
なんなら人手もかかるかも

## 第11章 探索的テスト
探索的テストとは、スキルのある担当者が責任を持って、テストケースを書かずに、テストの学習とテスト実行を高速に行う手法。

## 第12章 まとめ - テスト全体のデザイン
### 単体テストなしで疲弊する組織
単体テスト中心の開発スタイルでなければ、組織は疲弊する
- 同じようなテストを主導でやるので、テストエンジニアのキャリアパスが見えなくなり、誰も品質のスペシャリストになりたくなくなる
- おなじようなバグを人間が見つけ、同じようなバグを開発者が修正する。バグの混入と、発見のタイミングがずれるので、バグの混入を防ぐ活動がしにくい

## 第13章 アジャイル・シフトレフトのメトリクス
品質のメトリクスとして、以下をおすすめする
- コード網羅率（C0ではなくC1）
- ミューテーションテスト
    - まず単体テストが実装され全て通っていることを確認したうえで、ミューテーションテストツールでミュータント（バグ）を仕込み、期待通りバグが検出されるか確かめる方法
    - 例えば、&& を || に変えるなど（網羅できていれば発見できるバグ）
    - ただし誤検知が多い
- CKメトリクス
- HotSpot
- 信頼度成長曲線
    - 信頼度曲線`m(t)`は以下で定義される
```math
m(t) = a(1-e^{-bt})
```
    - テストを実行した週の数が増えると、新たに発見するバグの数は徐々に減っていく、これで予測を立てる

## 第14章 アジャイルにおける要求仕様
### ユーザーストーリーの利点
アジャイル品質で重要なことは、開発者がイテレーションの中で実装するまっとうなユーザーストーリーを書き、それをテスト担当者がイテレーション期間にチェックすることです。

イテレーションの終わった瞬間にステークホルダーと確認することは、なによりも素晴らしいことです！品質の専門家にとって。ウォーターフォールの要求問題の呪縛から完全に解き放たれます。

## 第15章
ここは単体テストの実践が載っている、省略

## 感想
HotSpotや信頼度曲線のようなメトリクスが具体的な計算方法で示されていたのは良かった。
特に頻繁に変更が入る個所でバグが発生しやすいことから、重点的にHotSpot値が高い個所からリファクタリングをするというのは、とても合理的に感じた。
また、第4章で色んな企業の網羅率の基準を見られて参考になった。