ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方
- 翔泳社 (2021年3月17日発売)
本棚登録 : 92人
感想 : 13件
- Amazon.co.jp ・本 (224ページ)
- / ISBN・EAN: 9784798165035
作品紹介・あらすじ
ソフトウェア上流品質を上げまくって、
バグだらけ・死ぬほど働くのをやめませんか？
テスト界の第一人者、高橋寿一氏執筆の
ロングセラー『知識ゼロから学ぶソフトウェアテスト』の続編が登場！
今回のテーマは「開発者テスト」です。
本書では、アプリ・システム開発において、バグを減らすために
開発者が行うべきテスト（開発者テスト）についてわかりやすく解説します。
開発者テストを実施するために知っておくべき概念・手法や、
○単体テスト
○リファクタリング
○アジャイル開発での品質担保
○テストの自動化
などについて、実例を出しながら解説していきます。
品質コンサルタントとして長年培ってきた筆者の経験をもとにした、
現場で必須の手法＋学術的根拠のエッセンスを詰め込んだ一冊です。
感想・レビュー・書評
-
理論の本かな，という印象．
確かに単体テストができていないのは反省．
1. 上流工程での品質確保！
→確かに要件定義が甘いところがあるか...
2. コードベースの単体テストはソースコードを書く前に書く！
→理論はわかっていますが，定着しておらず初めてやるとなるとよくわからないんですよね...
3. 関数の出口は1カ所or2カ所
→1カ所は入力パラメーターチェック，あとは1カ所に集約．なるほどね．
4. レビューはテストよりも効率的なバグ発見手法
→確かにあまりできてないかも．以前レビューに時間を取り過ぎて進捗悪化があったので...
1
詳細をみるコメント0件をすべて表示 -
今までの経験した現場のことしか言えないが、本書のテーマである、Shift Leftして開発作業を楽にするという考え方を実践している開発現場は少ない。アジャイル開発だとドキュメントはいらないかと勘違いしていたけれど、最低限、クラス図とシーケンス図はあるべきとか、MVC分離は必須とか、関数の出口は1つにすべきとか、単体テストをしっかりやるならウォーターフォール開発も否定されるものではないとか、得るものがたくさんあった。レビューは、間違いを指摘するというより、質問によって本人が気づくことに重点が置かれるものという点に納得。Microsoftでは当然のように行われている単体テストを嫌いな日本人が多いという記述にはちょっと驚き。海外と比べて日本の方がちゃんとやっていそうなイメージだったので。Androidアプリの単体テストの方法が丁寧に書かれていて分かりやすい。
1
-
ソフトウェア開発において近年ますます重要性を増すも理想に近付くのはいつまで経っても難しいテストを基礎から解説した一冊。数々の企業で様々なソースコードを読んできた著者の経験を基に「上流品質の上げ方」が懇切丁寧に説明されている。コンサルというバックグラウンドゆえか人員追加やタスク増加を暗黙の前提としない方針で書かれているのも地味だけど助かる。文章も平易で割とサクッと読めるが、熟練エンジニアの方は薄い内容だと感じるかもしれない。ただ、サクッと読めるボリュームだからこそ「自分は理解できてるから要らないよ」と過信せずに一度謙虚に読んでみるのが良いと思う。
1
-
上流工程でバグを減らそうという考えにもとづいた、ソフトウェアテストについての本。
普段、テストというと、ソフトを開発した後にテストを行い、バグを見つけたら改修するというようにやっているけれど、テストコードを書くことが良いということが書かれてあった。
ようは、テスト駆動開発(TDD)だし、今までそういうやり方があるというのは何度も聞いて知ってるけれども、テストコードの書き方を学ぶのも、テスト用の関数の書き方を考えるのも、テストコードを書くのも工数がかかるのを考えるとどうにもやる気が起きないのだけど、品質があがることを考えるとこういうことも考えたほうがいいのだろうなと思う。
特に、使用がはっきりと決まっておらず、プロトタイプを先に作ってしまおうという開発とはどうにも相性があわないような気がするし、自分が関わるプロジェクトにはそういうのが多いので、使いたいと思わないのだけど、これからはこういう開発手法も考えたほうがいいのだろうな…。
ところで、単体テストという言葉を、間違って使っていたように思う。一つのプログラムにたいしてのテストが単体テストであって、APIなど他のプログラムも含めたテストを連携テストと思ってたのだけど、一般的には、単体テストというのは、コードベースの単体テスト、すなわちホワイトボックステストのことをいうらしい。なので、プログラム単位というよりはむしろ関数単位やファイル(クラス)単位のテストと考えるほうがあってるのかもしれないと思った。勉強不足を実感する。
網羅率というのは、手動かテストコードかに限らず、重要な概念だとは思うのだけど、いまいち何をもって100％というのか分からなかった。コードに書いてあるすべての行をテストしたら100％ということなのか？ それとも、境界値のテストも考慮する必要があるのか？ このあたり、もっと調べたほうがよさそう。
あるファイルが一定期間に直近何回変更されたか、その回数が多いファイルにバグがでやすいというのはなるほどと思った。重点的にそういうファイルのテストやコードレビューは行ったほうがいいのだろうなと思う。
複雑なファイルについては、2つにぶったぎっただけで品質の向上を感じるという話も面白かった。ただ、ぶった切るといっても、同じプライベート変数を様々なメソッドで使ってるクラスファイルだと、難しいだろうなと思う。簡単にいうけど、2つに分けるだけでもコツがいりそう。
ただ、そもそも複雑度というのもいまいちわかりにくいなという印象。ifやswitchが多いと複雑ということでいいのだろうか。このあたりはなんとなくでやったほうがいいのかな。多分、使わない関数とかは消したほうがいいのだろうなと思う(残してるってことよくあるけど)。
「バグを入れないようにする仕組みではなく、入れてもすぐに発見できる仕組みを入れることが重要」というのは、まさにそうだろうなと思った。まあ、言うは易く行うは難しだけど。
なお、全体、特に8章以降は、一つの章のページが短いように思った。コードレビューや要求仕様といったところに一章分割り当てられてはいるのだけど、それがどういうものかについては書いてあるものの、具体的な方法については書かれてないイメージ。特に、要求仕様については、はじめに「本章は最初あまり書くつもりはありませんでした。なぜなら、要求仕様の書き方なんて、プロの開発者である皆さんに対して説明する必要ありませんよね…。」と書かれてあるものの、要求仕様はこうあるべきなところに終始していて、結局どう書けばいいのかよく分からなかった。
最後の15章は開発者テストの実サンプルについて。いろいろ書いてあったけど、単体テストはやっぱり少しハードルが高いらしい。何より、プログラミング言語ごとに使うツールが異なるというのは、ツールの使い方を覚えるコストもやっぱりかかるというわけで、面倒だよなと思った。まあでも、なにか一つの言語で使えるようにはなっていきたい。
ところで本題とは関係ないけど、「maintenance」を「メインテナンス」と書かれてあるのがちょっと気になった。だいたい「メンテナンス」と呼ばないかと思ったのだけど、英語の発音的には「メインテナンス」のほうが近かったりするのだろうか。
1
-
上流からの品質向上(シフトレフト)必要
⇒不具合時の改修工数、テスト工数が下流に行くほどかさむため
C0,C1カバレッジとかも指標ではあるが品質向上目指さないのであれば無駄(指標にならない。ごまかせる)。単体でもブラックボックスとしてIOでみるのも必要。境界値、組み合わせなどのテスト設計技法の活用。
統合テスト(結合テスト)はアーキテクチャ考慮してテスト駆動開発みたいにテストできる状態(AP,MWの分割、粗結合)にしてやれば効果高い。あとはMVC分離とかも必要かも。
上記整ったら、自動化検討。
0
-
【電子ブックへのリンク先】
https://kinoden.kinokuniya.co.jp/muroran-it/bookdetail/p/KP00053375/
学外からのアクセス方法は
https://www.lib.muroran-it.ac.jp/searches/searches_eb.html#kinoden
を参照してください。
0
-
北米の大学で著名な教授に師事し、
大手で品質に関わる業務に従事してきた著者。
多くの著名な論文を引用し、
簡潔に要点をまとめている。
品質の問題を探るとき、まずコードを読み込むところが新鮮。
0
-
単体テスト>統合テスト>システムテスト
要求仕様の本は「ソフトウェア要求」がベスト
その一つテスト可能については状態→条件&アクション→特定された結果を考慮する
circleciの雰囲気を味わえた。今後利用していきたい。
0
著者プロフィール
高橋寿一の作品
