ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方

高橋寿一

ソフトウェア上流品質を上げまくって、
バグだらけ・死ぬほど働くのをやめませんか？

テスト界の第一人者、高橋寿一氏執筆の
ロングセラー『知識ゼロから学ぶソフトウェアテスト』の続編が登場！
今回のテーマは「開発者テスト」です。

本書では、アプリ・システム開発において、バグを減らすために
開発者が行うべきテスト（開発者テスト）についてわかりやすく解説します。

開発者テストを実施するために知っておくべき概念・手法や、
○単体テスト
○リファクタリング
○アジャイル開発での品質担保
○テストの自動化
などについて、実例を出しながら解説していきます。

品質コンサルタントとして長年培ってきた筆者の経験をもとにした、
現場で必須の手法＋学術的根拠のエッセンスを詰め込んだ一冊です。

̻□章構成
第1章 はじめに
第2章 上流品質向上のためのテスト
第3章 開発者テストの基本の基本
第4章 コードベースの単体テスト
第5章 単体テストの効率化――楽勝単体テスト
第6章 機能単位の単体テスト
第7章 リファクタリング
第8章 コードレビュー
第9章 統合テスト
第10章 システムテストの自動化
第11章 探索的テスト
第12章 まとめ――全体テストのデザイン
第13章 品質と要求仕様とテストのケース
第14章 アジャイル開発 versus ウォーターフォール開発
第15章 開発者テストの実サンプル

※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 言語・プログラミング
• 出版社: 翔泳社
• タイトル: ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方
• タイトルID: 925600
• ページ数: 224ページ
• 電子版発売日: 2021年03月26日
• コンテンツ形式: EPUB
• サイズ(目安): 20MB

[ブクログ · ★★★★★]

北米の大学で著名な教授に師事し、
大手で品質に関わる業務に従事してきた著者。
多くの著名な論文を引用し、
簡潔に要点をまとめている。
品質の問題を探るとき、まずコードを読み込むところが新鮮。

[ブクログ · ★★★★★]

単体テスト>統合テスト>システムテスト
要求仕様の本は「ソフトウェア要求」がベスト
その一つテスト可能については状態→条件&アクション→特定された結果を考慮する
circleciの雰囲気を味わえた。今後利用していきたい。

[ブクログ · ★★★★★]

今までの経験した現場のことしか言えないが、本書のテーマである、Shift Leftして開発作業を楽にするという考え方を実践している開発現場は少ない。アジャイル開発だとドキュメントはいらないかと勘違いしていたけれど、最低限、クラス図とシーケンス図はあるべきとか、MVC分離は必須とか、関数の出口は1つにすべきとか、単体テストをしっかりやるならウォーターフォール開発も否定されるものではないとか、得るものがたくさんあった。レビューは、間違いを指摘するというより、質問によって本人が気づくことに重点が置かれるものという点に納得。Microsoftでは当然のように行われている単体テストを嫌いな日本人が多いという記述にはちょっと驚き。海外と比べて日本の方がちゃんとやっていそうなイメージだったので。Androidアプリの単体テストの方法が丁寧に書かれていて分かりやすい。

[ブクログ · ★★★★☆]

上流からの品質向上(シフトレフト)必要
⇒不具合時の改修工数、テスト工数が下流に行くほどかさむため

C0,C1カバレッジとかも指標ではあるが品質向上目指さないのであれば無駄(指標にならない。ごまかせる)。単体でもブラックボックスとしてIOでみるのも必要。境界値、組み合わせなどのテスト設計技法の活用。

統合テスト(結合テスト)はアーキテクチャ考慮してテスト駆動開発みたいにテストできる状態(AP,MWの分割、粗結合)にしてやれば効果高い。あとはMVC分離とかも必要かも。

上記整ったら、自動化検討。

[ブクログ · ★★★★☆]

ソフトウェア開発において近年ますます重要性を増すも理想に近付くのはいつまで経っても難しいテストを基礎から解説した一冊。数々の企業で様々なソースコードを読んできた著者の経験を基に「上流品質の上げ方」が懇切丁寧に説明されている。コンサルというバックグラウンドゆえか人員追加やタスク増加を暗黙の前提としない方針で書かれているのも地味だけど助かる。文章も平易で割とサクッと読めるが、熟練エンジニアの方は薄い内容だと感じるかもしれない。ただ、サクッと読めるボリュームだからこそ「自分は理解できてるから要らないよ」と過信せずに一度謙虚に読んでみるのが良いと思う。

[ブクログ · ★★★★☆]

内容が薄いのと文章力が低いなと感じました。
テスト理論の本ですね。実践的な内容ではありません。

結局言いたいことは、早い段階で問題を潰せということに限る。
単体テストさえちゃんとやっておけば、システムテストは大きな労力をかける必要がない。

[ブクログ · ★★★★☆]

バグを出さない仕組みについて書かれた本。
15章まであるが、薄い本なのでサクッと読めます。

テスト手法の中でも、単体テスト、組み合わせテスト、境界値テスト、状態遷移テストについて焦点を当てて書かれていて、何となくテスト書いていたのであればすごくためになるんじゃないかと思います。

あと、同じバグでも要求や設計段階で潰すのと、統合テスト時などある程度開発が進んだ状態で潰す場合でコストが違うよーみたいな話もあって面白いです。

ただ、ところどころ日本企業がテストできてないよ！ってディスってるのは微妙だなぁと思いました笑

[ブクログ · ★★★☆☆]

理論の本かな，という印象．
確かに単体テストができていないのは反省．

1. 上流工程での品質確保！
　→確かに要件定義が甘いところがあるか...
2. コードベースの単体テストはソースコードを書く前に書く！
　→理論はわかっていますが，定着しておらず初めてやるとなるとよくわからないんですよね...
3. 関数の出口は1カ所or2カ所
　→1カ所は入力パラメーターチェック，あとは1カ所に集約．なるほどね．
4. レビューはテストよりも効率的なバグ発見手法
　→確かにあまりできてないかも．以前レビューに時間を取り過ぎて進捗悪化があったので...