この記事について
「はじめて学ぶソフトウェアのテスト技法(リー・コープランド著)」は JSTQB認定テスト技術者資格 AL テストアナリスト のシラバスで参考文献として取り上げられたり、テストアナリストの過去問題解説でもお勧めの参考文献として挙げられています。

- 作者:リー・コープランド
- 発売日: 2005/11/03
- メディア: 単行本
原書は "A Practitioner's Guide to Software Test Design" です。

A Practitioner’s Guide to Software Test Design (Artech House Computing Library)
- 作者:Copeland, Lee
- 発売日: 2013/12/31
- メディア: ペーパーバック
この記事内で「本書」は日本語版の「はじめて学ぶソフトウェアのテスト技法」を指すものとします。
本書は特に前半のパートで誤記や説明不足な箇所が目立ちます。原書含め、現時点では正誤表を見つけることができませんでした。また、日本語版の出版社(日経BP社)にも問い合わせ*1を行ったことがあるのですが、初刷り当時の担当編集者が既に退職されているということで、確認できないこともありました。
そこで、誤記や説明不足な点に対し、これらを補足する目的で本記事をまとめることにしました。本記事の内容は私個人の見解です。本記事の内容に関して出版社は関知しておらず、問い合わせることはお控えください。
第3章 同値クラステスト
雇用の社内規定のコード
この章で取り上げている雇用の社内規定の例を引用します。
0歳~16歳:雇用しない
16歳~18歳:パートタイムでのみ雇用
18歳~55歳:正社員として雇用
55歳~99歳:雇用しない
この社内規定では 16, 18, 55 歳が複数の区分で現れています。どちらの区分に属することを想定しているのかはその後のべた書きのコードでわかります。
If (applicantAge == 16) hireStatus = "パート"; If (applicantAge == 18) hireStatus = "正社員"; If (applicantAge == 55) hireStatus = "雇用せず";
ですが、続けて示されるコード例では条件式が不適切です。
If (applicantAge >= 0 && applicantAge <= 16) hireStatus = "雇用せず"; If (applicantAge >= 16 && applicantAge <= 18) hireStatus = "パート"; If (applicantAge >= 18 && applicantAge <= 55) hireStatus = "正社員"; If (applicantAge >= 55 && applicantAge <= 99) hireStatus = "雇用せず";
例えば16歳は1つ目のIf文で true となり "雇用せず" となりますが、2つ目のIf文でも true となり "パート" に上書きされます。結果は想定通りですが、見通しの良いコードではありません。
実はこのコードは「第4章 境界値テスト」で欠陥のあるコードとして取り上げられており、そこでの伏線としてあえてこのようにしていると考えられます。
例題2の誤記
有効な値は 1 以上、9999 以下です。有効な入力値の集合としては {1, 22, 333, 4444}、無効な入力値としては {42, 0, 12345, sqe, $#@%} が選べます。
無効な入力値の例の "42" は "-42" の誤記です。
第4章 境界値テスト
境界値分析は2ポイントか3ポイントか
この章では著者の意図をつかみかねる箇所がありました。
まず、境界値分析は境界値に対して2ポイントを選ぶ場合・3ポイントを選ぶ場合があります。詳細は下記の記事を参照ください。
境界値分析で分析する境界「値」について|Tsuyoshi Yumoto|note
本書から技法の解説のキーポイントを引用します。
各境界について、境界上の値、境界のすぐ下の値、境界のすぐ上の値を1点ずつ選んで、テストケースを作る。
これは3ポイント境界値分析の説明となります。
これを踏まえ、図4-1の境界値を確認します。ここでは下記の解説がありました。
収入の境界は、月額1,000ドルと月額83,333ドル(単位は米ドルとします)です。
テストデータの下端の箇所では {999ドル、1,000ドル、1,001ドル} を、上端の箇所では {83,332ドル、83,333ドル、83,334ドル} を、境界テスト用の値として選択します。
これは3ポイント境界値分析です。
次に例題1の解説を確認します。
このフィールドの入力は、1桁から4桁の数字 (0, 1, ... , 8, 9) です。このデータ長属性に関する境界値テストのテストケースは、{0, 1, 4, 5} 桁の数字となります。
とあり、これは桁数に着目した2ポイント境界値分析です。
つまり、特段の断りなく2ポイントと3ポイントの境界値分析の例が混在しています。
さらに混乱を招くのが「人材雇用アプリケーション」の例です。
前章では、人材雇用アプリケーションが個人の年齢によってどう処理を行うかを示すために、以下のルールを定めました。
0歳~16歳:雇用しない
16歳~18歳:パートタイムでのみ雇用
18歳~55歳:正社員として雇用
55歳~99歳:雇用しない
<中略>
私たちが考えている組織の意図しているルールは、おそらく次のようなものでしょう。
0歳~15歳:雇用しない
16歳~17歳:パートタイムでのみ雇用
18歳~54歳:正社員として雇用
55歳~99歳:雇用しない
<中略>
この例の境界、およびその近傍で注意を払うべき値は、{-1, 0, 1}、{15, 16, 17}、{17, 18, 19}、{54, 55, 56}、{98, 99, 100} です。
「注意を払うべき値」は修正後のルールから境界値分析をしても導くことはできません。修正前のルールに対し3ポイント境界値分析を行うことで導くことができます。
ただ、修正前のルールは不適切であり、それを境界値分析することは妥当ではないと考えています。
第5章 デシジョンテーブルテスト
表5-8 の誤記
表5-8の「条件」の上に "8" という記載がありますが、これは「ルール8」の "8" の位置が誤っています。
第7章 状態遷移テスト
すべてのイベントを最低1回起動するテストケース
「図7-11 すべてのイベントを最低1回起動するテストケース」で「入金済 → 顧客によるキャンセル」と「発券済 → 顧客によるキャンセル」のパスを通っていませんが、「キャンセル」というイベントは「成立 → 顧客によるキャンセル」のテストケースで起動したため、同じ「キャンセル」イベントによるパスは通らなくても良い、ということのようです。
第8章 ドメイン分析テスト
1×1ドメイン分析
1×1ドメイン分析の "1×1" が何を意味しているかを本書内で解説されていません。推測になりますが、関連すると思われる記述を引用します。
1 by1 selection criteria、つまり仕様を式に表して、各式に対して境界値をテストするとした選択基準を適用する際にはドメインテストマトリクスを作ればよいと書かれています。
ドメイン分析と言うテスト技法は他のテスト技法と何が違うのか?|Tsuyoshi Yumoto|note
ドメインテストマトリックスの使い方
「変数/条件のタイプ」をどのように設定すべきなのか、湯本さんの記事の例を参考に考えます。
ドメイン分析と言うテスト技法は他のテスト技法と何が違うのか?|Tsuyoshi Yumoto|note
チルド宅配パックの長さ制限として「長さ ≦ 100 cm, ≧ 1 cm」が示されています。これを表8-1には以下の通り当てはめられます。
- X1 : 長さ
- C11 : 長さ ≧ 1 cm
- C12 : 長さ ≦ 100 cm
そして、C11, C12 の各条件に対して on ポイントと off ポイントを割り当てます。
C11 - on | 1 cm |
C11 - off | 0 cm |
C12 - on | 100 cm |
C12 - off | 101 cm |
湯本さんの記事のドメインテストマトリックスは各条件を列に割り当てていますが、表8-1ではこれを行に割り当てています。
以下の条件でドメインテストマトリックスを作成した例を示します。
- 長さ ≦ 100 cm, ≧1 cm
- 幅 ≦ 100 cm, ≧1 cm
- 長さ+幅 ≦ 150 cm
表8-1の誤記
X2の代表値の横線がX2を突き抜けていますが、これは誤記です。
表8-4 の代表値選択ミス?
テストケース1では GPA = 4.0, ACT = 34, GPA/ACT = 3.9/35 が選ばれています。
ここで疑問なのが、テストケース内で矛盾していることです。GPA = 4.0, ACT = 34 なのですから、GPA/ACT = 4.0/34 を選ぶべきと思われます。
仮に GPA/ACT の in ポイントとしてだけ考えれば GPA/ACT = 3.9/35 も適切です。GPA/ACT の制約条件は "10 * GAP + ACT ≧ 71" です。GPA = 3.9, ACT = 35 の計算結果は 74 であり、制約条件を満たす代表値となります。
ただ、テストケース内で異なる GPA, ACT の値を使ってしまってはテストが実施できないため、この代表値の選び方は不適切と思われます。
第9章 ユースケーステスト
第10章 制御フローテスト
図10-5の実行パス
100%複合コンディションカバレッジを達成するためのテストケースとして以下の4つが挙げられていました。
a > 0, c = 1, b = 3, d < 0
a ≦ 0, c = 1, b = 3, d ≧ 0
a > 0, c ≠ 1, b ≠ 3, d < 0
a ≦ 0, c ≠ 1, b ≠ 3, d ≧ 0
これを図解します。
構造化テストの基礎パスの組が必ずしも一意に決まらない?
構造化テストの説明に下記の記載があります。
必ずしも一意でない複数の基礎パスの組が作成可能なことに、気付かれたかもしれません。しかし、どの組から作成したテストケースを実行しても、すべてのステートメントとすべての分岐が実行されるという性質があります。
この『必ずしも一意でない複数の基礎パスの組が作成可能』が何を指しているのか、分かりませんでした。今後判明すれば追記します。
第11章 データフローテスト
動的データフローテスト
本書の解説だけでは手法が理解できず、日本語の記事を探しましたが、セミナー情報以外見つけることができませんでした。
"Dynamic Data Flow Testing" で検索すると複数の論文がヒットしましたが、英語&ボリュームがあるため、今回の調査では断念しました。
改めて再挑戦したいと考えています。