「知識ゼロから学ぶソフトウェアテスト【改訂版】」という書籍を読了しました。
本エントリでは、下記について記載したいと思います。
- 本書の対象読者はどういった方なのか
- 自分が本書を読んで理解した内容
- いちソフトウェアエンジニアとして何が活用できそうか
本書の対象読者はどういった方なのか
本書は米Microsoft, 独SAP, 日本の電機大手で、ソフトウェアテストに従事してきた情報工学博士の著者「高橋寿一」氏が、これまでの経験と様々なエビデンスを元としてソフトウェアテストについてゼロから解説する内容となっています。
メインターゲットとしては テストエンジニア（※1）に向けた内容で、サブターゲットとしては、広義的な意味でのソフトウェアテストについて知見を得たいソフトウェアエンジニアや、効果のあるテストを実施したいという思いがあるテスター業務に関わる方 になるかと思います。
※1. 高品質・高セキュリティを担保するためにテスト計画から改善提案・テストの実施まで請け負うソフトウェアテストに特化・専門したエンジニア
本書を読んで理解した内容
要約すると下記の通りです。
- ソフトウェア開発においてバグは絶対発生すること
- バグを発見するためのテスト手法について（ザックリと）
- スケジュール計画時、バグが発生する前提で考えること
- 品質の見える化でバグの出やすい箇所を判別しやすくなること
ソフトウェア開発においてバグは絶対発生する
前提として著者により下記の主張がされています。
現時点で完全なテスト手法は存在していないので、バグが存在しないソフトウェアは存在しない
テストケースを100万通り用意しても、担保できていないケースが存在してしまうことから絶対にバグが存在しない「完璧」なソフトウェアを用意することは難しく、
完璧を目指すためのテストに多額の費用をかけるよりも、費用対効果を鑑みて「十分」な品質を保ったソフトウェアを目指したほうが良いとのことです。
また、本書の序盤に記載された「先人と著者の言葉」が、本書で解説されているテスト手法やテスト計画を解説するにあたって、とても大事な指針になっていると感じました。
バグを全部見つけるのは無理だと心得ろ！
Cem lanerエラーは見つからないだろうという仮定のもとにテスト計画を立ててはいけない
G,J Mayersプロダラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラー数に祖霊する
G,J Mayersソフトウェアテストで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるのかを知ることである
Juichi Takahashi
バグを発見するためのテスト手法について
テスト手法では下記の4点が紹介されていました。
（テスト手法の詳細を完全に理解しているわけではないため、ザックリとした記載となっています）
- ホワイトボックステスト
- ブラックボックステスト
- 探索的テスト
- 非機能要求に対するテスト
ホワイトボックステスト
- プログラムの論理構造が正しいかどうかをテストする手法であり、人十年にも渡って研究され、品質が改善されることが証明された手法
- 論理構造の正しさのみテストするため、ソフトウェアの仕様が間違っていることから起こるバグは発見できない
- 手法としては「制御パステスト（ステートメントカバレッジ / ブランチカバレッジ）」があり、カバレッジは60-90%あればOK。
- TDD（Test Driven Development）というテストファーストなプログラム開発手法を用いた場合は、必ず最小単位のユニットテストを書くことによりホワイトボックステストの一部を実行することができる
ブラックボックステスト
- プロダラムを一種のブラックボックスに見立てて様々な入力を行うことで、ソースコードを見ずにテストを行う手法でほとんどのソフトウェアにおいて実施されるテスト
- 紹介されていた手法は下記の通り
- 入力処理に対して行う「同値分割法」や「境界値分析法」、「On-Offポイント法」や、それに伴った効率的なテストケースの説明
- 出力処理を確認する観点も持った「ディシジョンテーブル」
- ソフトウェアの状態をモデル化してテストを行う「状態遷移テスト」
- 「アドホックテスト（モンキーテスト）」など
このテストを著者は「もっとも重要で、もっとも時間を費やし、もっとも簡単なテスト」だと主張しており、テストに迷った場合は下記のアプローチを実施することを勧めています。
- まずは「境界値テスト」をやって境界値に関わるバグを潰す
- 入力エリアが2つ以上あるようなダイアログなどがある場合は「ディシジョンテーブルテスト」を行う
- そして状態が遷移するようなソフトウェアの場合は「*状態遷移テスト**」を行う
それでも出る場合は「非機能要求のバグ」か「ブラックボックステストのアプローチが間違っている」、「ホワイトボックステストでしか見つからないバグ」であり、
「十分」な品質を保つという観点ではスルーして、発見されたバグの発生原因や防止策に時間をかけたほうが有意義とのことです。
探索的テスト
- ソフトウェア機能を学習しながらテスト設計とテスト実行を同時に行うというテスト手法
- 「ソフトウェアを理解 -> テストケースを書く -> テストケースを実行する」という一連の流れをふむテストケースベースのテストに対して「ソフトウェアを理解 -> テスト設計 & テスト実行 <-> バグ報告」を並行で行うテスト手法のこと
- テスト担当者が十分なドメイン知識を有したうえで、テストの知識がある場合に抜群の効果を発揮する
- 非機能要求テストには向いていない
非機能要求に対するテスト
- 非機能要求とは複数存在する品質特性（※2）が担保されているかどうかを確かめるためのテスト手法（で、とてもめんどくさいものである）
- ※2: 「ソフトウェアが持つべき特性」で機能的な側面と非機能的な側面の両方の属性を示したもので「機能性、信頼性、効率性、移植性、使用性」などが存在する
- それぞれの非機能要求に対してテストのアプローチが異なっており、とてもたいへん
- どれかの品質を上げた場合にどれかの品質が下がるという依存関係があるため、品質特性のトレードオフを考える必要がある。
- テストにおいて重要だと考えられる品質特性は「機能性」と「信頼性」と「パフォーマンス」であると主張している
- パフォーマンステスト、セキュリティテストなどを実施しよう
スケジュール計画時、バグが発生する前提で考えること
紹介されたテスト手法を「リリースまでにかけることができるコストや、スケジュール」と調整したうえで、取捨選択して実施する必要があります。
- IEEE826をベースとしたテストプランの作成
- テストする機能、しない機能、人員・時間の見積もり、スケジュール、受け入れ基準、etc...
- テストケースの作成
- いつ誰がやっても同じような結果になるように設計すること
品質の見える化でバグの出やすい箇所を判別しやすくなること
- 何を元に品質がよくなったのかの品質指標（メトリックス）を持つことが大事である
- バグメトリックス : バグの数を基準として管理・監視する指標
- バグの増減、バグの重要度、バグの解決に掛かる時間 などの要素で問題の追求をすることができる
- ソースコードメトリックス : ソースコードを基準とした指標
- コードの行数でバグ密度や複雑度を図る
また。メトリックスとは「プロジェクトの健全性および、品質を客観的に知る方法」であり「人の能力や、個人の仕事の結果」として図ってはいけないと強く念押ししている。
- 「あいつは不健全で、ものすごく品質が悪い」や 「あいつはとっても健全で、品質が高い」などと言われて嬉しい人はいない。百害あって一理なし
いちソフトウェアエンジニアとして何が活用できそうか
フロントエンドエンジニアというコードを書く立場から、
本書を読んだ上で直近活用できそうだと思った点は以下の通りです。
- コードを書く際は、どういった内容をテストしたら良いのかについて
- これは、ホワイトボックステストに属するユニットテストでは「制御パステスト」を行えば良さそうだという事がわかった。
- また、TDDで開発すれば必ずユニットテストで制御パステストの一部を書くことになる
- リリース時はどのようなテストをしたらよいか
- これはケースバイケースではあるが、テストプランやテストケースに基づいて適切な手法でのブラックボックステストを実施すると良さそう
- 要件によっては非機能要件テストで「パフォーマンス」や「セキュリティ」のテストも実施する
- 実施するテストプランが適切かどうかについて
- IEEE826をテンプレとしたテストプランの作成や、本書の内容を見比べることで確認する
- 実施するテストケースが適切がどうかについて
- あいまいな表現・記述をしないようにして「いつ、誰がやっても同じ結果が得られる」テストケースかどうか確認する
現時点では、まだ自分の脳の中にインデックスが作成されたくらいの感覚なので、必要に応じて本書を取り出してテスト手法に対する理解を深めて行きたいと思います。