知識ゼロから学ぶソフトウェアテスト【改訂版】まとめ 後編

ソフトウェアテスト

　高橋寿一さんの「知識ゼロから学ぶソフトウェアテスト【改訂版】」まとめの後編です。
後編では、第四章から最終章の第九章まで、一気に見ていきます。

もしまだ前編を読んでいない方は、折角なのでこちらからぜひ。

kan-getsu.hatenablog.com

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

「知識ゼロから学ぶソフトウェアテスト【改訂版】」目次

  1. はじめに
  2. ソフトウェアテストの基本
  3. エンジニアが最もよく使う手法
  4. 探索的テスト
  5. 機能あらざるもののテスト、最難関のテストに挑む
  6. ソフトウェアテストの運用の基本
  7. ソフトウェアテスト品質管理の基本
  8. テストの自動化という悪魔
  9. それでもテストがうまくいかない人へ

4. 探索的テスト

第二章で「ホワイトボックステスト」を、第三章で「ブラックボックステスト」を紹介しました。 続く第四章では、著者イチ押しの「探索的テスト」を取り上げています。

探索的テスト (Exploratory Testing) とは

探索的テスト
ソフトウェアの理解・テスト設計・テスト実行を同時に行うテスト

定義を見ただけではやはり分かりづらいので、これまでの手法との対比や、具体的なイメージを使って確認していきます。

まず、これまで紹介した「ホワイトボックステスト」「ブラックテストボックステスト」とは、どう違うのでしょうか。
探索的テストでは、上の定義通り、ソフトウェアの「理解」「テスト設計」「テスト実行」を「同時に」行う、とあります。
ここでは、「同時に」という言葉がポイントとなります。

「ホワイトボックステスト」「ブラックボックステスト」では、いずれも、まずは仕様や要件に基づき、詳細なテストケースの作成から開始します。
実装を確認して制御フローテストを組んだり、同値分割・境界値分析やディシジョンテーブルの作成をして、テストケースを作成してからテストに取り組んでいました。
これら、事前に詳細な手順を作成し、順にテストケースを実行していく計画的なテストを、探索的テストと対比して スクリプトテスト と呼びます。
事前に何をどうテストするかを明確に定めることができ、かつその部分のテストの必要性が高い箇所に対しては、かなり有効なテストです。

しかし、スクリプトテストでは、場合によっては非効率なテストの実行となってしまう可能性もあります。
なぜならば、前編で述べた通り、バグは無限に存在し、バグは偏在し、そしてテスト担当者・開発者のリソースは有限 だからです。
開発やテストが進む中で、事前に作成し実行し続けてきたテストケースの一部があまり有効でないことが分かっても、スクリプトテストのパラダイムでは、そのテストケースを繰り返し実行することが通常多いようです。
これとは逆に、製品を触って理解し、テストを実行する中で得た違和感や気づきをテストケースに反映させ、より効率的にクリティカルなバグの発見に繋げるのが、探索的テストの発想と言えます。

「はじめて学ぶソフトウェアのテスト技法」では、スクリプトテストと探索的テストの対比を、ゲーム「20の扉」*1 のプレイ方法に喩えています。
曰く、スクリプトテストでは、事前に 20の質問全てを用意するようなもので、予想外の事態に対応することができない。
一方、探索的テストでは、回答の結果を受けて次の質問を考えられるので、質問をより効果的に考えられる、となります。

探索的テストの注意点

　ここまでいいことずくめのように思える探索的テストですが、説明を読んでいる中である違和感を持たれた方が多いのではないでしょうか。
おそらくその違和感は当たっており、探索的テストは 一定以上に成熟したテスト担当者が行うことが前提 となるテストだとも述べられています。
理想的には、テストの経験のみでなく、テスト対象のソフトウェアなりのドメイン知識もあるとなお良いのでしょう。

また、スクリプトテスト同様、非機能要求のテストにはあまり向かないようです。

以上の様に、融通が利き、かなりの有効性が認められる探索的テストですが、実施には一定以上の熟達が求められます。
私も含め、テスト入門者は、まずはしっかりとした設計のスクリプトテストを実施して経験を積み、それから探索的テストに挑戦していくのがよさそうです。

5. 機能あらざるもののテスト、最難関のテストに挑む ー非機能要求のテストー

　ここまで、テスト担当者によく使われる具体的テスト手法「ホワイトボックステスト」「ブラックボックステスト」「探索的テスト」を紹介してきました。
お気づきの方もいらっしゃると思いますが、この三種のテストに共通する弱点があります。
それは、非機能要求のテストには不向き という点です。

何度か出てきた「非機能要求」という単語ですが、ここで改めて、これが指すものを確認してみます。

非機能要求とは

非機能要求
ソフトウェアが持つべき特性である、品質特性に対する要求

新しく用語を説明しようとしたら、品質特性 という新しい言葉がまた出てきました。
品質特性についても、ここで簡単に紹介しておきます。

品質特性
ISO 9126で定義されている、ソフトウェアが持つべき特性。機能性 (functionality)、信頼性 (reliability)、効率性 (efficiency)、移植性 (portability)、使用性 (usability)、保守性 (maintainability) の 6つの大分類が定義されている

なんだかごちゃごちゃしていますが、筆者も「非機能要求は説明が難しいため、大胆に要約して説明している」といった趣旨のことを述べています。*2
そして、筆者は、 「テストにおいて特に重要な品質特性は、機密性 (security)、信頼性 (reliability)、パフォーマンス (efficiency) である」 と続けています。

これら非機能要件のテストはスクリプトテストほど基本的でもなく、文字数を割いて詳細に説明するのは、このまとめ記事の役割ではないかと思うので、それぞれ簡単に紹介だけしようと思います。

1. 機密性 (Security)

　機密性、いわゆる「セキュリティ」です。
BSI (英国規格協会) という協会が定める BS7799/ISMSという規格では、情報セキュリティ管理システムに対し、「情報資産の機密性、完全性、可用性が保たれること」を要求しています。
それぞれ簡単に説明しておくと、以下の通りです。

  • 機密性 (Confidentiality)：アクセス権限の担保
  • 完全性 (Integrity)：データ及びその処理方法が正確・完全であることの担保
  • 可用性 (Availability)：認可された利用者が必要なときにアクセスできることの担保

プログラム (あるいはもっとハード寄りの部分でも) に不備があると、これらが担保されていない状況が起き得ます。
例えば、見えていけないデータが見えたり、データが消えたり、システムダウンでアクセスできなかったり、という状況は、セキュリティが担保されていない状況です。

さて、このような状況を避けるべく、以上 3種の性質を担保する必要があるのですが、残念ながらセキュリティの分野のテストは本書執筆時点 (2013年 12月時点) では未発達のようで、部分的にランダムテスト (この文脈ではファジングテストと呼ぶらしいです) に頼らざるを得ない部分があるそうです。
積読と化してしまっているのですが、この辺をちゃんと学ぶなら、徳丸浩さんの『体系的に学ぶ安全な Webアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』を読むのが良いのかなと思います。*3

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

2. 信頼性 (Reliability)

　次は信頼性 (Reliability) です。
筆者も簡単に説明するのが難しいと書いているので、私も甘えます。
ただし、説明がないと分かりづらいので、誤解がある可能性を承知で述べると、信頼性は「システムがどれだけ安定して稼働でき、障害が起きた際どれだけ容易に復旧できるか」くらいのことを指すものだと思っています。

信頼性をなんとなくでも理解するには、信頼性の測定に使われている尺度を取り上げてみるとイメージがつきやすくなると思います。
尺度のうちの一つに、平均故障間隔 (Mean Time Between Failure: MTBF) というものがあります。
これは、システムを連続稼働させた際に、平均的にどれだけの時間でバグや障害に遭遇するかを計算したものです。

ただ、MTBFは当然どんなオペレーションをしているかに左右されますので、信頼性を求める際は、

  • 実際の顧客がもっとも使うと思われるオペレーション実行時の MTBF
  • ストレステスト (負荷テスト) 実行時の MTBF

を求めるのが基本のようです。

また、これらの MTBFの他、信頼度成長曲線 を求めることによっても、ソフトウェアの信頼性を予測することができます。
信頼度成長曲線とは、横軸に時間、縦軸に発見されたバグの数をプロットし、それらプロットを近似曲線で結んだものです。
近似曲線を描くことで、将来のバグ発見間隔の予測に利用できます。
計算式もありますが、ここでは説明し切れそうにないので詳しく紹介はしません (多分間違ったことを言いそうでもあるので......)。*4
ただ、一般には信頼度成長曲線は、テスト初期にはバグ発見数が少なく、中盤にかけて増え、後半にあらかたバグの発見が落ち着いてまた曲線がなだらかになる、という S字のようになることが多いようです。

3. パフォーマンス (Performance)

　最後に、パフォーマンスです。
筆者は、パフォーマンステスト時の注意点として、以下の三点を挙げています。

  1. パフォーマンスの定義は明確に
    • 定量的に定義し、複数の条件で測定をしておく
  2. 要求定義通りのテストケースを書かない
    • 要求定義をあえて逸脱し、バグを発見するためのテスト を書く
  3. パフォーマンステストは後回しにしない
    • パフォーマンステストで発見されるバグは最悪のバグ、設計の見直しすら必要になる
    • ある程度プログラムが動くようになったら、定期的に実行するようにする

1「パフォーマンスの定義は明確に」については、「定量的に」という部分は分かりやすいですね。
ちゃんと数値として測定できる基準を設けないと、曖昧で意味のないテストになるのは想像に難くありません。
また、「複数の条件で測定」というのは、明示的に設けられた基準だけでなく、どれだけの余力があるのか、小さい負荷でも処理速度が遅いことはないか、といった確認もしよう、というものです。
パフォーマンスは、負荷と線形的な関係にあるとは限りません。
ある程度の負荷までは緩やかな処理速度低下だったのが、特定の閾値を超えたら急にパフォーマンスが落ちることもあり得ます (論理が合ってるかわかりませんが、経験から、利用メモリ量が閾値を超えると OOMが発生し、一気に処理速度が落ちるなどはあり得ると思います)。
こうした余力や、少量データでの処理速度も測っておくと、出荷後に「想定外にパフォーマンスが悪い」ということが減ると思います。

2「要求定義通りのテストケースを書かない」については、1と重なる部分があります。
他の部分でも共通することですが、テストは「バグが出ないように」テストするのではなく、「発生すると困るバグを出荷前に発見する」ことが目的です。
このため、むしろ「バグを見つけてやる」くらいの気持ちで、バグが出そうな条件のテストケースの作成をしよう、ということのようです。

最後は、3「パフォーマンステストは後回しにしない」です。
筆者は、「パフォーマンステストで発見されるバグは最悪のバグ」 とまで書いています。
私も前職で、顧客環境で Webアプリのバージョンアップ後にパフォーマンスが大きく落ちた際、短期間での原因特定・復旧にかなりの労力を割いた経験があります。*5
確かに、ユーザーとしては、業務で使うなどするシステムのレスポンスが悪いのは、かなりのストレスですし、業務効率も下がります。
温度感が高くなる懸案になり得るので、ちゃんと初めの頃から定期的に計測することで、問題を引き起こす実装が入ったタイミングの特定にも役立ちます。

第5章まとめ

　以上が、非機能要件のテストについて述べた章のまとめです。
ここで取り上げたセキュリティ、信頼性、パフォーマンスはいずれも重要ですが、定義が複雑だったり、測定が難しかったり、バグ発見が困難だったりします。
しかし、テスト担当者としてはいずれ立ち向かわねばならない部分です。
テストというとまず機能要件のテストを想像しがちですが、こうした非機能の部分にも目を向けることを忘れずにいなければならないようです。

6. ソフトウェアテスト運用の基本 ーテスト成功の方程式ー

第6章では、テスト計画の作成・運用について説明しています。

ここでは、IEEE 829のテンプレート*6 が広く使われているので、このテンプレートを使ってテスト計画を作成しよう、と述べています。

正直、この章に関しては、説明を繰り返す事にあまり意味はなく、IEEE 829を読む方が良いと思うので、割愛します。
例えば次のサイトなどで、IEEE 829フォーマットが示されています。

Qbook - ドキュメントテンプレート | IEEE829とは IEEE 829 - Standard for Test Documentation Overview

とは言えどんなものかだけは示しておいた方が良いと思うので、IEEE 829が定めるテストドキュメントの構成を以下に示します。

IEEE 829テスト計画書テンプレートの構成要素

  1. Test plan identifier
    • テスト計画書を一意に区別する管理番号
  2. References
    • 作成したテスト計画書の理解に有用なドキュメントの列挙
  3. Introduction
    • テスト目的・内容の要約など
  4. Test items
    • テストするソフトウェアのバージョン情報や対応ハードなど、テスト対象の詳細
  5. Features to be tested
    • テスト対象となる品質特性・機能のリストアップ
  6. Features not to be tested
    • ソフトウェアの内、外注部分や既存ライブラリ、互換性の扱いなど、テスト対象でない部分のリストアップ
  7. Approach
    • テスト対象の項目のテストを保証する、アプローチの記載
  8. Item pass/fail criteria
    • 各テスト項目の合否判定基準
  9. Suspension criteria and resumption requirements
    • テスト一時停止・再開基準
  10. Test deliverables
    • テストプロセスの成果物として作成されるドキュメントを記載
  11. Testing tasks
    • テスト実行のために必要なタスクを記載
  12. Environmental need
    • テスト実施に必要な環境条件の記載
  13. Responsibilities
    • テスト実行の責任者・グループを記載
  14. Staffing and training needs
    • テスト実行に必要な人員・スキルを記載
  15. Schedule
  16. Risks and contingencies
    • 考えられる高いリスクと、その防止・対応策を記載
  17. Approvals
    • テスト計画承認者について記載

なお、筆者は上記に加え、定量的指標を用いたテスト終了基準を持つ ことを勧めています。
確かに、定量的な終了基準を予め用意することで、無駄にテスト実施が延びることを防げそうですね。

また、テスト計画書はあくまで計画のレビューが目的なので、長大なドキュメントを作成するのは本末転倒です。
「大きなリスクを抱えたまま製品を出荷させない」という本来の目的を意識し、テスト費用 + サポート費用 = 最小値 となるようにテスト計画の策定・計画省の作成を行うべき、とのことでした。

テスト開始は早いほど良い

　上記で、IEEE 829のテンプレートを示し、具体的なテスト計画書の構成要素を紹介しました。
こうした計画書の作成は、正確な情報共有や、テスト実行前のリスク点検・確認につながり、テストの効率化につながります。
しかし、筆者はこうしたテスト計画書の作成だけでなく、もっと早い段階からソフトウェア開発プロセスに参加し、ビルド成果物だけでなく要求仕様や設計などのチェックをテスト担当者も行うことで、よりコストを抑えることが可能と説明しています。
例えば Kit (1995) の著作で、解析時点でバグを発見すると、機能テスト (スクリプトテストの実施などの段階です) 時点での発見よりも 25倍コストを抑えることができることを紹介しています。*7
また、Perry (1995) の著書を引用し、解析・デザインのバグはコードのバグの約 2倍存在するとの報告を紹介して、早期からのテスト実施・参加を推奨しています。*8
もちろん、こうした早い段階でバグを発見するためには、テストのみならず開発系の知識が必要となることが往々にあると考えられます。
前編でアジャイルやテスト駆動開発に触れた際にも述べましたが、テスト担当者もテストドメインの知識でけでなく、幅広い知識が求められるようになっているように感じました。

7. ソフトウェア品質管理の基本 ーソフトウェア品質のメトリクスー

　第7章では、品質を可視化するための、メトリクス (定量的指標) について紹介しています。
テストに限らず、何かしらの結果を客観化するためには、数値で表される指標を用いることが有効です。
では、ソフトウェアテストでは、どんな指標が有効なのか。
これを、筆者が過去勤務していた Microsoftの例などを紹介しつつ、述べているのが本章です。

品質を可視化するためのメトリクスの基準

まず、テストに有用なメトリクスの基準を紹介しています。
以下基準を満たすものが多いようです。

  • 誤差が少なく、感情や恣意に左右されないもの (客観性)
  • 開発するソフトウェアの品質を代表するもの (妥当性・代表性)

当然ではありますが、客観性は大事です。
筆者は悪いメトリクスの例として、「テストケースの数」を挙げています。
なぜこれが悪いかというと、このメトリクスで測られる「品質」を上げるために、闇雲にテスト担当者がテストケースをたくさん作る可能性があるためです。
この基準上は「高品質」になるかもしれませんが、確かにこれでは無意味なテストケースの増加につながり、本質を見失ってしまう余地がありますね。

また、ソフトウェア品質のメトリクスなのですから、「ソフトウェアの品質」を代表するものでなければなりません。
この観点での悪いメトリクス選択の喩えとして、筆者は「プロバスケットボール選手を成績でなく見た目や素行のみで評価するようなもの」と述べています。
そして、ソフトウェア品質を測定するメトリクスは大抵一種類では十分代表できないため、複数のメトリクスを組み合わせることが有効とも述べています。*9

この他にも、前編などで何度か述べた通り、コードの複雑さとバグの数が相関関係にあり、バグが偏在するため、コードの複雑さを測定することも有用と述べています。

Microsoftのメトリクス例

では、筆者が勤務していた Microsoft社では、当時どのようなメトリクスを用いていたのでしょうか。
以下が、筆者が紹介する、当時の MS社で用いていたメトリクス例です。*10

  • バグのメトリクス
  • テストのメトリクス
    • コードカバレッジ
    • テスト担当者以外のバグ発見数
    • テストケースの数、テストの自動化率
  • ソースコードのメトリクス
    • 追加、削除、変更されたコードの行数
    • KLOCs (Kilo Lines Of Codes)：どのくらいソースコードの行数が増加しているか
  • コードの複雑度
    • McCabeのルール*11
  • ソフトウェアの信頼性メトリクス
    • 実際の顧客が最も使うと思われるオペレーション実行時の MTBF
    • 信頼性成長曲線
    • ストレステスト実行時の MTBF
  • ビルドのメトリクス
    • ビルドにかかる時間
    • ビルドで見つかった問題
    • ビルドが失敗した原因
  • スケジュールのメトリクス
    • 当初に立てたスケジュールと実際のズレ

MS社と言えど、意外と特別なことはしていないことが分かります。
こうした例を用いて、基本に忠実に、本質的に意味のある指標を用いて測定することの重要さを、筆者は強調しています。
何度も筆者がメッセージを発信しているように、「何のためのテストか」「何のためのメトリクスか」を意識して、妥当な選択をしたいですね。

8. テストの自動化という悪魔 ーなぜ自動化は失敗するのかー

　第8章では、テストの自動化について触れています。
タイトルからも伝わる通り、筆者は自身の苦い経験から、無計画な自動化に警鐘を鳴らしています。
もちろん自動化の有効性は認めていますが、何でもかんでも自動化を試みるのはかえって非効率である、というのが主張となっています。

自動化コード保守の観点から: 自動化が有効なケースとそうでないケース

自動化は、わかりやすい成果です。
「自動でテストができるようにしました」は、テストが詳しくない人にも分かりやすいインパクトがあります。
実際、私も自動化への期待と憧れがありますし、挑戦したいと思っています。
しかし、テスト対象である成果物は、バージョンアップや修正の度に、実装が変わります。
ものによっては、こうしたタイミングで自動化コードがそのままでは動かなくなり、自動化コードの保守にコストを割くことになってしまいます。
そしてこの保守コストが手動テストのコストを上回るような場合は、当然自動化は悪となってしまうでしょう。

以上を踏まえ、筆者は、テスト自動化に向く内容と向かない内容を、以下のようにいくつか例示しています。

テスト自動化が有効な内容

  • スモークテスト*12
    • 多くの回数繰り返すため
  • パフォーマンステスト (ストレステスト、負荷テスト)
    • 複数ユーザーを実際に集めるより、ツールでシミュレートした方が良いため
  • APIのテスト
    • APIはそれほど変わらないため

テスト自動化が有効でない内容

  • 回帰テスト*13
    • UI変更の影響が大きく、自動テストコードの保守コストがかさみがちのため
  • グラフィックスやサウンドなどメディア関連のテスト
    • 継続的なメンテナンスがほぼ不可能のため (Takahashi & Kakuda, 2003)*14

第8章まとめ

　以上の様に、自動化には向き不向きがあることに注意しなければなりません。
スモークテストの様に基本的でかつ頻繁に繰り返すものは、自動化の恩恵が大きいようです。
また、パフォーマンステストの様に、そもそも手動でやることのコストがかなり大きいものや、APIのように仕様変更の可能性が小さいものも、自動化によって効率化を見込めそうです。
　一方で、意外にも回帰テストは自動化に向かないと、筆者は述べています。
繰り返し実行するテストなので自動化に向いてそうですが、UI等の変更にかなり左右されてしまう事が多いため、規模によっては手動テストの方が良いようです (もちろん GUIアプリケーションについて、という前提はあります)。
メディア関連の部分については、なんとなくですが分かる気がします。
しっかり読んだわけではないのですが、引用している論文では、現存するツールではグラフィカルなアウトプットの比較が困難である、と述べています。
ただ、この論文が出版されたのが 2003年なので、そこから 15年経った現在なら、もっと良い方法論があるのかもしれません。

自動化する前に、自動化コードの作成・保守コストは、自動化によって得られる恩恵に見合うか、をやはり考えなければならないようです。

9. それでもテストがうまくいかない人へ

　最終章である第9章では、「テストが上手くいかない人へのアドバイス」の章となっています。
しかし、主な内容としては、これまで筆者が述べたことを改めて強調するかたちになっていると思いました。
曰く、以下の通りです。

  • テストにかけられる時間・費用などのリソースは有限であり、バグは無限である -> 組み合わせテストなどをやめ、本質的な部分に注力して効率化を図る
  • ソフトウェアの品質は悪い部分が代表する、このため品質が悪い = バグが偏在する部分を叩くのが効率的

有限なリソースでテストを効率的に行うために、形式的にテストを網羅するのでなく、本質的に「どんなリスクが重要か」を考えた上で、本質に注力する。
また、バグは偏在し、ユーザーからするとそうした品質の悪い部分が製品全体の品質を代表するものになるため、バグが集中する場所に注力する方が良い。

このあたりは、全章通して、筆者が陰に陽に主張していた事ではないかと思いました。
テスト計画を考えるようなマネージャーレベルにならないとまだ縁がないことかもしれませんが、やはりテスト分野においても、コストを考えた、そして効率的な計画を考えることが必要である とのことでした。

後編まとめ

　やはり長くなってしまいました......これでもかなり削りました。
前編が、ホワイトボックス・ブラックボックステストなどの基本的な手法と考え方の紹介だったのに対し、後編はよりテスト全体を管理するような、マネジメント的な観点が入っていました。

特に後編では、「有限のリソースと無限のバグという前提条件下での効率的なテスト計画・実施」 「適切なメトリクスを用いることによるテスト進捗の可視化・客観化」 など、いかに現実の状況下で、制約の中で最大限の結果を出すかが繰り返し説かれていたように思います。

知識ゼロから学ぶソフトウェアテスト【改訂版】感想

　これは私自身の問題なのですが、テストの実務経験がない現状では、解説を読んでも、想像の範疇を出切れない部分がありました。
ただし、本書の対象読者にはおそらく私のような実務未経験の入門者も含まれているかと思いますので、一意見として受け止めてもらえると嬉しいです。
また、前編の冒頭にも書きましたが、本記事に誤りがあれば、それはおそらく私の理解が誤っていることに基づきます。
お気づきの方は、今後の学習のためにも、誤った情報を広めないためにも、ご指摘いただけると幸いです。

　本書を読んだ感想ですが、実務経験が豊かで、かつ大学院での研究経験もある筆者が、その経験の中で感じた感情を前面に押し出して書いている本だと感じました。
随所に、開発部門や上司との対立・調整などの中で生まれた感情がにじみ出ていました。
そうした熱量を感じる、具体的な経験談も交えた主張なので、読んでいて納得感がありました。
また、「知識ゼロから学ぶ」と銘打っているように、本書ではあえて詳細で正確な概念・用語説明を省き、初学者のために平易な言葉で、時には大胆に省略して解説していました。
「まずは何となくでいい」といったメッセージが込められているように感じ、その意味では初学者に優しい入門書なのかと思います。

　一方で、「本書を読めば明日からの実務に備えられる」といった性質の本ではないように感じました。
伝わりやすさを重視した結果、概念や用語の説明にはそれほど紙面を割いていないことが一つの要因であり、体系的な説明でなかったり、時には説明無しにちょっとした用語が出てくることなどもありました。
網羅的・正確な知識をキャッチアップしたい人には、本書は向かないのではないか、というのが私の感想です (あくまで私の感想ですので、このスタイルが合う人も当然いるとは思います)。
そうした網羅的なインプットを求める方には、まだ全て読んだわけではありませんが、前編でも紹介した、『初めて学ぶソフトウェアのテスト技法』の方が、目的には適うかと思います。
ただし、こちらは出版が 2004年なので、最近の技法やツールの解説がないことには留意しなければなりません。

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

以上より、本書は、金銭・時間的余裕がある方が一冊目として読むのに良いのではないかと思います。
また、テストを本職としないが、テスト担当者がどんなことを考えてどんなことをやっているか、を知るのにも良い本でないかと思いました。
近い未来に始まる実務に備える、というためには、個人的には『初めて学ぶソフトウェアのテスト技法』が合っていました。

ただ、私自身本記事執筆時点で実務未経験のひよこなので、経験を積んだ上でまた振り返り、本書の再発見や、記事の修正・加筆などを行っていきたいと思います。

前編・後編いずれも長文となってしまいましたが、お付き合いいただいた方、どうもありがとうございました。

*1:出題者が頭に思い浮かべたものを、20の「はい」「いいえ」で回答できる質問で推測するゲーム。アキネーターとか話題になりましたね

*2:ちなみに「知識ゼロから学ぶソフトウェアテスト【改訂版】」ではなぜか保守性が紹介されていません

*3:界隈では「徳丸本」と呼ばれるらしい。2018年 6月に第 2版が出てます

*4:m(t)：時間軸に対する信頼性、a：期待する fault (bug) の総数、b：バグの発見率 としたうえで、m(t) = a(1 - e^{-bt}) によって求められるそうです

*5:その時の原因はインフラベンダーの DBサーバーの設定ミスが直接の原因でした

*6:IEEE (アイ・トリプル・イー) は、Institute of Electrical and Electronics Engineersを表す。アメリカに本部がある学会で、電気通信関連の仕様の標準化等を行う。IEEE 829は、ソフトウェア・システムのテストにおいて作成すべきドキュメントについて定めた規格

*7:Kit, E. (1995). Software Testing in the Real World. Addison-Wesley, NY.

*8:Perry, W. (1995). Effective Methods for Software Testing. John Wiley & Sons, Inc.

*9:私は心理学研究を学生時代やっていたのですが、構成概念の測定に似ている気がしました。例えば、「勤勉さ」という概念に完全に合致する測定指標が存在しないため、これと概念的に近いと考えられる複数の項目の測定結果の組み合わせで近似するような感じです

*10:出典は Tierney, J. (1997). Microsoft Metrics: Low Cost, Practical Metrics for Software Development. Annual Oregon Workshop Software metrics.

*11:McCabeの Cyclomatic数: プログラムの制御の流れを有向グラフで表現し、そのグラフ中のノード・リンク数などに基づいて算出される複雑度。オブジェクト指向には対応していないらしい

*12:ソフトウェアの基本動作確認のようなテスト。諸説あるが、一説には起動時に煙を吐かないか、といったごく基本的な確認の意から転じたらしい

*13:コードの修正・変更に対し、デグレが起きていないか確認するテスト。デグレはデグレードの省略形で、デグレードは、以前のバージョンで正常だった部分に、新しいバージョンで不具合が発生してしまうこと

*14:Takahshi, J & Kakuda, Y. (2003). Effective Automated Testing for Graphical Objects. 情報処理学会論文誌44巻7号, 2003年7月号.