#ソフトウェアテスト #書籍

著者 : 髙橋寿一

本書は上流テストについて

テスト担当者が実施するシステムテストの説明は省く

感想

結構主観的な記述が多かったり、適当な記述もあったり、日本語がおかしかったりもするが、大筋いいことが書いてある

大体知っていることではあったけど、一部知らない情報などもあったりして自分としても学ぶことはあった

テストピラミッドの概念をわかっていなかったり、自動の単体テストをしっかり書くべきだということを経験的にわかってない人にとっては、ページ数が少ない中に重要な情報が詰まっていて、一読の価値はありそう

日本では上流品質という言葉が使われるが、アメリカでは使われない

あえていうならシフトレフト (Shift Left) : 品質向上の活動を設計・コーディングのフェーズに持っていく

本書の目的

Shift Left すること

楽をすること

あらゆるフェーズの検査を最後のテストフェーズで行おうとするとカオスになる

上流品質担保のための提案

要求仕様の明確化

クラスや関数の構造をシンプルに保つ

単体・結合テストの実行

レビューの実施

統合テストやシステムテストで見つかるバグの割合は、多くても 55 %

Beizer のバグ検出の表 (『ソフトウェアテスト技法 自動化、品質保証、そしてバグの未然防止のために』 より)

下流でのテストではバグを見逃す可能性が高くなる

バグの発見が遅れるとその分修正コストがかかる

単体テストをやっている現場でも、自動化されてないしテストケースも管理されていないことがある

そのようなところは設計書もろくにない

重厚な設計所は不要だが、クラス図とシーケンス図は書け！！

クラス図はクラスが大きくなるのを防げるし、リファクタリングの効果も見える

単体テストをするために知っておくべきテスト手法

単体テストという言葉には厳密な定義がなく、ISTQB の用語集にもない (昔はあったが削除された)

本書ではコードベースの単体テストという名前を使う

命令網羅 (C0 カバレッジ)

分岐網羅 (C1 カバレッジ)

網羅することが目的にならないように

網羅率はあくまでテストの品質基準のひとつ

テスト駆動開発などを使ってコードベースの単体テストを書いていくべし

網羅率についての基準

80 % 程度は目指すべき (エラーハンドリングなどもあるので、20 % 程度は頑張ってテストしなくても良いことが多い)

Google の基準

低いコードカバレッジは、プロダクトの大きな領域が完全にはテストされていないことを保証する

高いカバレッジだからといって、高い品質を保証するわけではない

変更頻度の高いコードはカバーされるべき

「ボーイスカウトルール」 で少しずつでも上げていこう

C = e - n + 2 (e : ルートの数、n : 分岐点の数) ← McCabe 数

バグが出やすい箇所 : 直近変更された回数の多いファイル

プログラムの構造などではない

なるほど

Hotspot : バグの出やすさを数値化したもの

Score = ∑_(i=0)^n (1 / (1+e-12ti +12))

変数の定義を教えてくれ……

Hotspot の高い箇所は網羅するようにして、あとは全網羅は目指さなくてよい

コードを網羅して単機能のテストをするのは開発者の責務 → 機能単位の単体テストは開発者が確認すべき

機能単位の単体テストの基本

単機能境界値

組み合わせ : そこでバグが出やすいか、という考え方で組み合わせを考える (さもなければテストケース数が爆発する)

機能単位の単体テストで組み合わせのバグ検出をするのは困難

コードベースの単体テストやコードレビューで検出すべき

組み合わせテスト (デシジョンテーブルやAll-pair など) は一番コストがかかる方法なので、できるだけしない方がいい

にも関わらず、日本では組み合わせテストに頼り切っていたりする

なぜなら品質問題が出たときの対応としてそれが楽だから (問題が発覚 → テストで検知できていなかった → 組み合わせをテストケースに追加しよう、という流れ)

ソフトウェア品質を担保するためにリファクタリングは必須

リファクタリングの 2 つの流れ

コードの本質論からリファクタリングを推奨 (Martin Fowler 推奨) ← 本章でのテーマ

XP のプラクティスでのリファクタリング (Kent Beck 推奨) ← 4 章で説明

内部品質を測るメトリクスとして筆者は McCabe 数と WMC (CK メトリクスのひとつ) を利用

MeCabe 20 以下、WMC 20 以下

明確な根拠はない

コードの複雑度を測る指標はいくつかある

McCabe 数 (サイクロマチック複雑度) ← 筆者のおすすめ (有名だし計測ツールを購入できるから)

Chen の最大交差数

Woodward らのノット数

メトリクスの値が大きいファイルは小さく分割する

MVC 分離は重要

テストの界面を GUI に持たないことが重要

コードレビューはテストよりも効率的にバグを発見できる

Beizer のバグ検出 : ウォーターフォール開発におけるデータでは、コードレビューやプロトタイプ作成の方がテストよりも欠陥検出の割合が多い

統合テストについても、ISTQB や ISO での定義は不明確

GUI 部分と GUI から使われる API 部分にアプリケーションを分割し、API 部分をテストする、という形で統合テストをする例

テストの自動化では、メンテナンスコストを最小限に抑えることが重要

キャプチャー・リプレイの自動化は最悪

Dorothy Graham が定義したテスト自動化のレベルでいうと、レベル 1

最良の選択の一つはキーワード駆動テスト

2 つの属性を効率的に使う

アクションワード

データ

例 : 「ログイン」 というアクションと、ユーザー名・パスワードのデータ

探索的テストは単体テストを十分行った組織には非常に役に立つ

筆者の考えでは、下記の条件を満たせばシステムテスト工程は短い探索的テストで良い

コード網羅が概ね 80 % 以上 (網羅基準は分岐網羅)

アーキテクチャが MVC 分離されている

各関数の McCabe 数が 20 以下、クラスメンバー関数の数が 10 以下

全ての要求仕様がレビューされている

Race Condition のバグに対して十分対策がされている

日本ではシステムテストで品質担保をする組織が多いが、単体テストをちゃんとやれ

そうだね、テストピラミッドだね

ソフトウェア開発において、要求仕様・要求分析は超重要

日本では要求仕様について定義なしに大規模プロジェクトを遂行しているような組織が多すぎる

要求仕様については Karl Wiegers の 『ソフトウェア要求 第 3 版』 だけ読めば良い

要件が不明確だと不具合密度が上がっていることは証明されている

「ソフトウェア開発データが語るメッセージ 「設計レビュー・要件定義強化のススメ」」 より

ウォーターフォール開発では、開発とテストを異なる 2 つのステップに分ける

アジャイルの本を読むと、アジャイルの方が品質がよくなったという記述が散見される

が、日本の組織はまだかなりの部分がアジャイルに移行していないように見える

外見だけアジャイルっぽくしているエセアジャイルも多い

品質を軽視するのはエセアジャイル

リリース前に協力会社のテスト担当者にやらせるようなものはエセアジャイルである

アジャイルの組織で重要な品質要素について鷲崎弘宣氏が定義している

「アジャイル品質パターン (Agile Quality, QA2AQ)」 参照

Android アプリのプロジェクトをサンプルに、JaCoCo でテストカバレッジを取ったり CircleCI で CI を回すような例を説明