前提として、開発組織の価値提供はquality/costの最大化だと考えている。また、validation/verificationのうちverificationを本記事のスコープとする。
上流で品質を担保したほうが、出荷後の品質は上がる
p. 12
ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人 情報処理推進機構が参照元である。
「プロジェクト計画／再計画や品質マネジメント改善等のシーンにおいて、上流工程での不具合摘出比率の目標を、目安として85%程度に高めて設定することを目指そう。」
https://www.ipa.go.jp/sec/reports/20170331.html
目標（KGI）とすべきであるが、進捗が分からないのでKPIにはできない。
- プロジェクトの後半でバグをつぶすコストは、前半のコストの数倍かかる→効率が悪い=お金がかかる
- プロジェクトの後半でバクをつぶすと、つぶしきれず出荷後のバクになるリスクがある
品質も低いしコストも高いというのは、quality/costの最大化という価値提供から考えると正反対である。
コストを最小限に抑えつつ、市場でのバグを出さないような手法について、本書で説明していきます。
p. 19
ここでコストを上げて品質を上げるという話にいかないところが素晴らしいと思う。
多くの単体テストを行っていない組織では、もちろん設計書も書いていません。（…）クラス図とシーケンス図だけは書いてくださいと言います。
p. 22
やはり図を書くことからはじめるアプローチが良いように思われる。
各テストライフサイクルの中で、適切なテスト手法を組み合わせることは重要です。テストライフサイクル（単体テスト→統合テスト→システムテスト）の各段階で、適切なテスト手法（境界値テスト・組み合わせテスト・状態遷移テスト）を行う必要があります。
p. 24
なるほど。これを各組織で具体的に定義する必要があると思われる。
以下はテストライフサイクルについての説明。
単体テストはコードに対する確からしさを確認するテストなのか、あるいは単機能に対するテストなのかを明確にしたほうがよいでしょう。
p. 34
まずはテストライフサイクルのうちの単体テスト。コードか単機能か。
単体テスト（コードベース）は、以下のことをチェックします。
- プログラムを実行する中で、システム上異常な振る舞いを行わない（null pointer、0による除算など）
- 入力値とそれに対応する期待値を出力すること
- すべての分岐が正しく処理されること（境界値テスト）
p. 35
各テストライフサイクルで何をチェックすべきかは定義される。
世の中には、便利なテスト駆動開発というものがあります。（…）本書では推奨します。
p. 42
各テストライフサイクルでどのようにテストを書くべきかは定義される。
網羅することは品質基準であり、目的は単体レベルの処理機能のバグをなくすことです。
p. 40
なるほど。
コードの網羅率を計測しないと、自分たちの単体テストでコード網羅率を上げる努力が、本当に実のある努力なのかがなかなか確認できません。
p. 47
なるほど。
改善とは、今ある仕事を効率的にし（残業時間を減らし）、かつ品質を上げることです。
p. 58
テストに限る話ではないが、肝に銘じる。
最近（といってもここ10年で）どこからバグが出るかがわかってきました。実はソフトウェア構造ではなく、「あるファイルが一定期間に特に直近何回変更されたか、その回数が多いファイルからバグが出る」とのことです。品質の研究者としては結構ビックリな結果で、個人的には大発見だと思っています。
p. 59
これについては、そうなのかもしれないし正直良くわからない。
機能単位の単体テスト手法の基本は、
- 単機能境界値
- 組み合わせ
テストライフサイクル毎に基本の手法がまとめてあるのが助かる。
読了した上で私の意見をまとめると、
- 開発組織の価値提供はquality/costの最大化
- この価値提供のもとで、quality verificationのstrategyがshift left testing（上流テスト≠システムテスト）であるべきことは理論的に証明されている
- KGIは上流テストでの不具合摘出比率85%
- テストライフサイクル
