何の本？
知識ゼロから学ぶソフトウェアテスト
エンジニアとしての心得やソフトウェアテストにできること、できないこと、など初心者がまず知っておかなければならないことがらにはじまり、必ず実施される各種テスト手法の基礎とポイント、アジャイルなど新しい開発手法に対応したテストの考え方など、テスト技術者にとって不可欠な知識と情報を、親しみやすい記述や例示で判りやすく解説した一冊です。テスト技術者の入門書かつ最適の定番書として、ソフトウェア開発現場のニーズに即した内容を取捨選択のうえ、カラー化して一層読みやすくパワーアップして再登場しました！
ソフトウェアテストに携わる初歩のエンジニア／テスト技術者を育成・要請する立場の方におすすめです。
ソフトウェア品質を高める開発者テスト
テスト界の第一人者、高橋寿一氏執筆の
「開発者テスト」実践における必携書、アジャイル開発に完全対応！
本書では、アプリ・システム開発において、バグを減らすために開発者が行うべきテスト（開発者テスト）についてわかりやすく解説します。
開発者テストを実施するために知っておくべき概念・手法や、
○単体テスト
○リファクタリング
○アジャイル開発での品質担保
○テストの自動化
などについて、実例を出しながら解説していきます。
旧版で言及の少なかったアジャイルテストの方法論にページを割き、
アジャイルの現場でも活躍する内容にパワーアップしました。
品質コンサルタントとして長年培ってきた筆者の経験をもとにした、
現場で必須の手法＋学術的根拠のエッセンスを詰め込んだ一冊です。
ゼロから学ぶソフトウェアテストにおいてはソフトウェアの品質を保証するためのテスト設計の基礎が全般的に記載されており、ソフトウェア品質を高める開発者テストにおいてはソフトウェアの開発者がテストについて知っておくべき内容、単体テストの書き方やシフトレイトの必要性などが主に記載されている。
どちらも200ページほどで、しかも文字が大きく図表も多いためサクッと２時間もあれば読める。その分あっさりしすぎているような印象も受け具体的にどのようにしたらよいのか？と疑問に思う点もあったが、その場合には別の本でさらに知識を深めたり実務経験を積むしかないのかもしれない。
よかったこと
ソフトウェアテストにおける基礎が、筆者のマイクロソフトやSAP、ソニー、品質管理コンサルタントの現場での経験や学術的根拠、データを用いた説明から学ぶことができる。
読書メモ
以下、読書メモ
ソフトウェアにおけるバグ
バグが存在すると、そのソフトウェアに期待される品質を顧客やユーザに届けることができなくなる。バグは重要度が大きく異なるものの、品質を著しく下げ、場合によっては顧客や開発会社に莫大な損害をもたらすことになる。
ソフトウェアにおいてバグは無限とも有限とも言われ（学説によって異なるらしい）、テストによって全てのバグを見つけることはできない。では、どのようなバクをどうやって見つけるべきなのだろうか？
テストすべき項目
この本では
- 境界値テスト
- ディシジョンテーブルテスト
- 状態遷移テスト
これだけで必要なバグは潰せると主張している。もしそれ以上のバグが出るのであれば非機能要求のバグであるので、テストで見つけることは難しいし、重要なバグにはならない、という判断である。
開発者が行うべき上流工程における品質向上
- 開発者はバグのないコードを書き、顧客に仕様を満たした製品を届けるためのコードを書く責任を持つ。が、開発者も人間なのでミスをする。ミスをする前提でそれを発見・是正できる仕組みを作ることが大切。
- テストや設計をきちんと上流工程で行う（シフトレフト）することで大きなバグを開発の初期に見つけ、開発の終盤ではバグがでない・出たとしても小さいものしか出ないようにすることができる。
- 下流工程で、つまり開発の後半で大きなバグが見つかるとどうなるか、もしくは出荷後に見つかるとどうなるか。上流工程でバグを潰すことは開発の効率化、修正コストの低減につながる。
- そのような上流品質の向上のために、「要求仕様・ユーザストーリの明確化」「クラスや関数構造をシンプルに保つ」「単体・結合テストの実行」「レビューの実施」が必要。
単体テスト
- 状態遷移には正しく状態遷移できるための条件、また誤った状態遷移が行われないようにするための条件（もしくはエラー処理や例外処理）がたくさん存在する。正しくこれを文章化しテスト設計者に伝えるか、もしくは自分でテストを行う必要がある。
- 単体テストは分岐網羅（C1カバレッジ）のテストケースを書く。そして関数のin/outをチェックし、関数の責務が達成されることでほとんどのバクを見つけられる。
- Googleテストカバレッジの指標もある
Although there is no “ideal code coverage number,” at Google we offer the general guidelines of 60% as “acceptable”, 75% as “commendable” and 90% as “exemplary.”
https://testing.googleblog.com/2020/08/code-coverage-best-practices.html - ほとんどのバグはソースコードの10~20%から出ると言われており、ファイル行数が長いもの、複雑なもの、変更頻度が高いものが怪しい
- 複雑とはクラスにおけるメソッドの数（10以下が望ましい）もしくは分岐の数から計算されるMcCabe（20以下が望ましい）などによって測定される
- つまり行数の多いファイルはぶった斬るのがよい
コードレビュー
- レビューはテストよりも効果的なバグ発見方法であり、テストでは見つけられない（見つけにくい）Race Condition（競合）のバグを見つけることができる
- 基本的に人が書いたコードのバグを見つけるのは困難。レビューにおいては、どうしてこういうふうになっているのか？を問いかけることで開発者本人が気づきを得て成長することができる。
- コードレビューの前に単体テストを全部通しておくと、恥ずかしい目に遭わなくて済む。
カオスエンジニアリング
- カオスエンジニアリングは非機能テストに近づいている
- エンジニアがさまざまなサービス実行状況を一つのシングルシステムとして見れる
- 本当のリアルワールドインプット（ネットワーク異常など）を入れることで、システムの振る舞いが理解でき、システムの境界で何が起こるかを監視することができる
感想
私はQAエンジニアではないし、開発者としての経験も非常に浅いため最初はあんまり役に立たないのでは、と思っていたが、日々の開発の中で意識しなければならないことが記載されていた。毎日コードを書いている中では仕様を満たすことだけを考えがちになってしまうが、バグのないコードをどのように書くのか、また顧客にどうやって高い品質を届けたらいいのかを意識するきっかけになった。
2冊を読み比べた結果、日々のコーディングのことだけを考えるのであればソフトウェア品質を高める開発者テストの方だけよめば十分であったと思うが、テストのコストやテストの設計全体、テストのメトリックスについては知識ゼロから学ぶソフトウェアテストの方が詳しいので、結果的にはどっちも読んで良かったと思う。かなり重複しているところもあったけれども、、
参考
ソフトウェア品質を高める開発者テストにおいて推薦されていた以下の3冊はそのうち目を通したい。どれも名著なのだろうが、しかし高いな、、