1. 本記事について
1-1. 経緯
限られた時間で実施可能な効果的なソフトウェアテストのやり方はないのかと疑問に思っていた矢先、以下の書籍に出会い、即実践可能な考え方、手法を学習できたので備忘録としてまとめます。
尚、本書では「考え方」と「実践方法」という2つの視点で述べられていますが、本記事では主に「考え方」の部分についてまとめたいと思います。実践方法については自身の携わっているプロジェクトにおいて実践してみてからまとめていきたいと思います。
1-2. 書籍
| 知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書 |  |
| ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方 |  |
2. 上流品質について
2-1. 「上流品質」という考え方
まず、「出荷後バグの少ない品質の高いソフトウェアを開発するため」には、「上流品質」という考え方を元に、システム開発の下流工程でバグを潰すのではなく、上流工程でバグを多く潰すことにより、楽にテストを実行しつつ結果的に出荷後のバグも減らしていくことが大切ということになります。
上流工程でバグを多く潰した場合と下流工程に入ってからバグを潰した場合とでは、出荷後の品質に大きな差が出るということが理論的にも証明されているそうです。
高橋寿一氏著「ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方」では、特に以下の2点を大きなポイントとしています。
・シフトレフトすること(品質を向上させる活動を上流工程にシフトさせること)
・楽をすること(やるべきテストに絞って効率的なテストを実施すること)
つまり、「仕事を減らしつつ品質の高いソフトウェアを出荷する」ためのソフトウェアテストの実施がとても大切ということになります。
2-2. 上流品質を担保するためにやるべきこと
2-2-1. 単体テスト
単体テストを上流工程から実施することで、より多くのバグを早い段階で潰すことが可能です。コーディング段階のみならず、設計段階、要件定義段階でも実施した方が良いでしょう。
単体テストには、主に「コードベースの単体テスト」と「単機能の単体テスト」の2つが紹介されています。
2-2-2. リファクタリング
筆者は「リファクタリングなしでは上流品質は担保できない」と述べています。ビッグクラスの分解、デザインパターンの導入、関数の出口の一本化、MVCの分離など、リファクタリングのやり方は様々紹介されていますが、個人的には会社でLaravelを使用していることもあり、「しっかりとMVCアーキテクチャに則った設計、実装ができているかどうか」という視点を特に大切にしたいと思いました。このアーキテクチャをフルに活用した実装ができているかという点を逐一チェックしていきたいと思います。
2-2-3. コードレビュー・ペアプログラミング
コードレビュー
「レビューはテストよりも効果的なバグ発見手法である」と筆者は述べています。実際、コードレビューによるバグ発見率は単体テストよりもバグ発見率が高いというデータも出ているらしく、その有用性が伺えます。
しかし、レビューは人がやるものであり、できればあまり時間を割きたくないもの。そのため、本書では「単体テスト実行→プルリクエスト→レビュー」という仕組みを作ることが良いと述べられています。この仕組みにより、レビュー時点でレビューしなければいけない点は限られてきます。
ペアプログラミング
一人でプログラミングした場合と、ペアプログラミングを実施した場合とで、「プロジェクトの完了時間」、「テストケースの成功数」などに差が出ており、ペアプログラミングの方が優れているというデータが出ているそうです。
ただし、どんなタスクでも一様にペアプロをすれば良いというわけではなく、「開発者のレベル」と「タスクの難易度」に応じてどの手法を取るかを検討する必要があるとも述べられています。自身のプロジェクトのチームメンバーのレベル感を踏まえて検討するのが良さそうです。
| 開発者レベル | タスク難易度 | ペアプロ向きかどうか |
|---|---|---|
| 初級 | 簡単 | YES |
| 初級 | 難しい | YES |
| 中級 | 簡単 | NO |
| 中級 | 難しい | YES |
| 上級 | 簡単 | NO |
| 上級 | 難しい | NO |
2-3. 楽にテストを実施するためにやるべきこと
2-3-1. テストするべき場所を決める
本書ではテストで楽をするために、「バグが多く潜むところだけに絞ってテストをする」ということを強く推奨しています。どうやって絞るかについては主に2つの手法を紹介しています。
| 手法 | 内容 |
|---|---|
| HotSpot値算出 | 直近のファイルの変更回数によって算出される値 |
| 複雑度算出 | ファイルの行数や条件分岐の多さなどによって算出される値 |
これらによって、テストするべき20%のコードを特定して単体テストを実施(2:8パレートの法則を利用)、あとは探索的テストでUIなどのテストを実施して完了！！！
というわけです。
2-3-2. 自動化する
自動化することでテストの時間、その後のメンテナンス時間も大きく削減されるようであれば、自動化をすることも必要であると述べられています。ただし、むやみやたらな自動化は、「最初は自動化って楽しいけど、後からメンテナンスしなくちゃいけなくて苦痛」という状況を生みかねないので注意するべきであるとも述べられています。正しくメリットとデメリットを見極める必要がありそうです。
まとめ
本書では一貫して、「いかに上流工程で単体テストを多く行い、バグを多く潰しておくか」という点が、品質を高め、出荷後のバグによるトラブルを減らすことにつながるということを強調しています。さらに、「とは言ってもテストしている時間がない」というエンジニアのために、「いかに楽をしてテストするか」という点まで実践的に書かれていました。
私は現在、「1ヶ月単位で2つほどの機能をリリースし、そのサイクルを約半年間続けるようなスケジュールの開発プロジェクト」に携わっています。その中でやはり問題となっているのが、「テストする時間がなくて出荷後バグが多く発生する」という点ですので、まさに本書を参考に改善を図っていきたいと思います。
「テストに関する本質的な改善に関する考え方を学習」しつつ、「即実践可能な内容も学習できる」という非常に有意義な書籍でありました。