ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方
ソフトウエアヒンシツヲタカメルカイハツシャテスト カイテイバン アジャイルジダイノジッセンテキコウリツテキデスムーズナテストノヤリカタ
- 著者:
- 高橋 寿一(タカハシ ジュイチ)
- 出版社:
- 翔泳社
- 出版日:
- 2022年06月15日頃
- ISBN:
- 9784798176390
- 在庫:
- 在庫あり
なぜ注目されているか
書籍紹介
技書の森解説
テストは QA チームの仕事で、開発者はコードを書くことに専念すればよい。その分業のまま出荷後のバグに追われている組織に向けて、テストの責務を書いた本人の手に戻す方法を体系立てて示すのが『ソフトウェア品質を高める開発者テスト 改訂版』 (高橋寿一 著、翔泳社、2022 年 6 月刊) です。副題は「アジャイル時代の実践的・効率的でスムーズなテストのやり方」で、版元は「ウォーターフォールでもアジャイルでも、上流品質を上げまくって、よい製品を楽に作ろう!」と掲げ、著者を「テスト界の第一人者」と紹介しています。品質コンサルタントとして長年培ってきた筆者の経験をもとに、現場で必須の手法と学術的根拠のエッセンスを詰め込んだ一冊、というのが版元の位置づけです。
全 15 章の構成、上流品質の考え方から実サンプルまで
構成は全 15 章です。第 1 章と第 2 章で上流品質とは何か、Shift Left がどういう効果をもたらすかを説明し、第 3 章では境界値テストと状態遷移テストという、開発者がこれだけは知っておくべきテスト手法を押さえます。第 4 章から第 6 章が単体テストの本体で、命令網羅 (C0 カバレッジ) と分岐網羅 (C1 カバレッジ)、TDD、コードの複雑度から単体テストをやる箇所を絞る方法、ブラックボックステストとホワイトボックステストを扱います。第 7 章と第 8 章はリファクタリングとコードレビュー、第 9 章から第 11 章は統合テスト、システムテストの自動化、探索的テストと、単体テストの外側へ広がります。第 12 章のまとめを挟み、第 13 章と第 14 章がアジャイル・シフトレフトのメトリックスとアジャイルにおける要求仕様、第 15 章は簡単なアプリを作って単体テストとコード網羅測定を実際にやってみる実サンプルです。翔泳社の案内では付属データの提供はありません。
開発者テストが効く理由、網羅率と複雑度で決める単体テスト
技術背景として押さえたいのは、バグは見つかる工程が下流になるほど修正コストが跳ね上がるという点です。システムテストで見つけたバグは再現、切り分け、修正、再テストの往復を要しますが、コードを書いた直後の単体テストで見つかれば、その場で直せます。これが上流品質、いわゆる シフトレフト が効く理屈で、本書は第 2 章で上流品質と出荷後の品質、残バグのリスクの関係を説明します。もう一つの難所は「どこまで書けば十分か」です。命令網羅と分岐網羅という 網羅率 の指標は、テストが通っていない行や分岐を可視化しますが、全コードに一律で高い網羅率を求めると工数が破綻します。本書はコードの複雑度を使って単体テストをやる箇所を絞る方法を第 5 章で示し、版元の紹介でも「単体テストをやっている時間がありません」という現場の声に答える章と説明されています。複雑すぎて単体テストが書けないコードには第 7 章のリファクタリングで手を入れ、CK メトリックスや MVC 分離といった観点で複雑度を下げる、という順序で章がつながっています。
アジャイルのメトリックスまで、改訂版で厚くなった範囲
版元は改訂版について、旧版で言及の少なかったアジャイルテストの方法論にページを割いたと説明しています。第 13 章では、テストの網羅率そのものの質を測る ミューテーションテスト を考え方、ミュータントの中身、問題点、ミューテーション網羅率という順で解説し、ユーザーストーリと信頼性メトリックス、オペレーションプロファイル、信頼度成長曲線へ進みます。アジャイル・シフトレフトではウォーターフォール時代のメトリックスが適用しにくくなっているという問題意識が版元の枠組み説明にも示されており、品質を定量的に示したいテックリードや品質担当者には、この章が改訂版を選ぶ理由になります。第 9 章では API テストと API バグ密度の考え方、カオスエンジニアリングと品質 / 生産性の関係も扱い、統合テストを重視する実例が紹介されます。
コードを書く開発者のための前提知識と向かない読み方
前提知識としては、何らかの言語でコードを書き、単体テストのフレームワークに触れた経験があれば読み進められます。版元も、テストのプロのような品質概念の知識は要らないが、境界値テストのような基本的な手法は開発者も知るべきだ、という立場を明記しています。一方で、特定のテストフレームワークやツールの操作手順を網羅したリファレンスではありませんし、テスト技術者資格の試験対策書でもありません。テスト技法を網羅的に学びたい人は、テスト専門職向けの体系書と併読する方が目的に合います。また、テストコードの膨大なサンプルを写経して覚えたい人にとっては、本質と判断基準に重心を置いた記述が物足りなく感じられるかもしれません。
出荷後のバグ対応に開発時間を食われている開発者、単体テストを導入したいが工数を確保できないチームのリーダー、アジャイルへ移行して品質の測り方に迷っている品質担当者には、章ごとに持ち帰れる判断基準がある本です。単体テストを「やれと言われる作業」から「自分の開発を楽にする道具」に変えたい人にとって、投じた時間を回収しやすい一冊です。
言及した記事 (5 件)
この本に興味がある方におすすめ
関連する本
関連記事
テスト本ガイド - テスト設計を学べる技術書の選び方
テストの書き方からテスト戦略まで学べる技術書の選び方を紹介。テストピラミッド、TDD の正しい読み方、テストの ROI の考え方を解説します。
「動くコード」と「良いコード」の間にある本
コードが動くようになった後、次に何を学べばよいのか。「動くコード」を「良いコード」に変えるために必要な知識と、それを効率的に学べる本の選び方を解説します。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。