【読書感想文】ソフトウェア品質を高める開発者テスト【書評】
2021-06-25
Content
はじめに
おはようございます！こんにちは！こんばんは！
のふのふ(@rpf_nob)と申します！！都内のスタートアップでフロントエンドエンジニアとして働いています。
皆さんはソフトウェアエンジニアとして働いていて開発者テストって重要だと認識していると思います。しかし、しっかり勉強したことありますか？私自身あまりしっかりと勉強したことがなかったということもあったので、「ソフトウェア品質を高める開発者テスト」という書籍を手に取り勉強しようと思いました。
そこで今回は「ソフトウェア品質を高める開発者テスト」についての読書感想文・レビューを書いていきます。 この感想文で誰かのお役に立てたら幸いです。
本書の目次
本書の目次は以下のようになっています。
- 第 1 章 はじめに
- 第 2 章 上流品質向上のためのテスト
- 第 3 章 開発者テストの基本の基本
- 第 4 章 コードベースの単体テスト
- 第 5 章 単体テストの効率化――楽勝単体テスト
- 第 6 章 機能単位の単体テスト
- 第 7 章 リファクタリング
- 第 8 章 コードレビュー
- 第 9 章 統合テスト
- 第 10 章 システムテストの自動化
- 第 11 章 探索的テスト
- 第 12 章 まとめ――全体テストのデザイン
- 第 13 章 品質と要求仕様とテストのケース
- 第 14 章 アジャイル開発 versus ウォーターフォール開発
- 第 15 章 開発者テストの実サンプル
重要そうだと思った部分の要約と感想を書いていきたいと思います。
上流品質向上のためのテスト
本書には一貫して上流工程からテストを行い品質向上しましょうということが書かれています。（シフトレフト）これは開発ステージが後ろにいけばいくほどバグの修正コストが倍になっていくし、出荷後のバグも発生しうるという理由で書かれています。
出荷後にバグを顧客に見つけられてしまうリスクを考えると、組織全体で上流工程の内にテストを行い修正コストが少ないうちに品質を向上させておくべきですね。
単体テストについて
基本的には単体テストを正しく行えばほとんどのバグ（80%）は見つけられ、その中で境界値テストと状態遷移テストさえしっかり行えば十分であることが書かれています。
この境界値テストと状態遷移テストさえやっておけば大多数のバグがつぶせると思うし、要求仕様の再確認にもなるのでこの辺りの手法はしっかり理解しておきたいですね。
また、単体テストは以下のようなコードベースでの単体テストで行うことも推奨している。
- プログラムを実行する中で、システム上異常な振る舞いを行わない（ヌルポ、０による除算など）
- 入力値とそれに対応する期待値を出力すること
- 全ての分岐が正しく処理されること
本書では、網羅率については自動車などの人命にかかわるものは 100%の網羅率が望ましいが、それ以外は 80%ほどの網羅率で問題ないと言い切っている。Google では網羅率はほとんどのプロジェクトで 70%を超えているらしい
基本的には 100%であるべきと考えていたので、80%程度で問題ないというのは目から鱗だった。
単体テストをするファイルに関しては、「最近多くバグ修正している」「コードの複雑度が高い（分岐が多い）」などを勘案して決めるとよいと書かれている。
複雑度が高いファイルに関してはまず２つのファイルにぶった切るといいらしいです。コードが行数が多いだけでレビューする気も失せるのでこの手法は効果高いと思う。
リファクタリングについて
本書ではリファクタリングなしに上流品質は担保されないので以下のことを注意してリファクタリングしましょうと書かれています。
- 複雑度を下げるリファクタリング
- 出口を一つにするリファクタリング
- MVC 分離のリファクタリング
- ファイルのコードを短くするリファクタリング
コードが複雑になったり長くなったりする原因は、責務が適切に分けられていないからという理由が大きいので、この辺りは注意して設計する必要がありますね。
コードレビューについて
本書ではレビューとは基本的に他人の書いたものを指摘するのではなく、本人が気づくことに重点を置くものと書かれています。また、レビューはテストよりも効率的なバグ発見手法であるということも書かれています。
コードレビューは大切なので、なるべくコードレビューの前に自動テストで人がレビューするのを最小限で抑える（単体テストでエラー出ているのに人がレビューする意味がない）のが大事であると書かれています。
バグを入れないようにする仕組みではなく、入れてもすぐに発見できる仕組みを入れることが重要ですし、リンターやフォーマッターもしっかり導入してレビューの工数は最小限にしたいですね。
統合テストについて
単体テストだけでは品質の担保はされないので統合テストも必要だが、組織によって考え方が分かれるので時間と予算を鑑み最適解を目指せばよいと書かれています。基本的には単体テスト → 統合テスト → システムテストの順番に見つけるべきバグは減っていくようなアプローチが一般的。
単体テストをやらずに統合テストとシステムテストで終わらせる日本的なパターンもあるそうですが、かなり怖いですよね・・・
システムテストについて
最悪なシステムテストとして「キャプチャー・リプレイの自動化」について書かれている。日本では主流ですが、自動化テストのやり方としてメンテナンス性も悪くかなり愚劣なやり方と言い切っている。そこでメンテナンス性を考えるとキーワード駆動型自動テストを効率的に使うとよいと書かれています。
開発者テストの実サンプル
最後に Java と AndroidStudio を用いたテストの実サンプルが説明されており、単体テストコードの記述、網羅測定、CI/CD などの手法が書かれています。
まとめ
最後に上流品質担保の手法として
- アジャイル開発での要求変更が頻発する中での高速開発
- CI/CD のツールと手法による高速のデリバリ
- HotSpot を利用した効率的な単体テスト
を適宜組み合わせて最適なやり方をすれば、世界最高水準のソフトウェア開発であり、Google と同じ開発手法を使うことになると書かれています。
競合とのスピードに負けないようにこの手法を行うのが日本でもスタンダードにならないと、世界には全く通用しないと本書を読んで切に思いました。
今回は「ソフトウェア品質を高める開発者テスト」についての読書感想文を書いてみました。 この感想文で誰かのお役に立てたら幸いです。今後も読書感想文も書いていきたいと思いますので、何かありましたら Twitter とかでコメントいただけたらと思います！！
最後まで見ていただきありがとうございました！！！！！
この記事が良かったと思ったら SHARE していただけると泣いて喜びます 🤣