2021年12月21日にJaSST nano vol.7で発表した資料になります。

1. なぜ ペアワイズテスト を
使いこなせないのか
JaSST nano vol.7
2021.12.21

2. 2
【主な活動】
• JaSST Kansai 実行委員長 (‘21~22)
• 派生開発推進協議会(AFFORDD) 関西部会、研究会
• WARAI (関西ソフトウェアテスト勉強会) 月1回開催
関西のテストエンジニア。キャリア10年を超えてテストの楽しさに気付く。
HOLLY (Touyou Horikawa)
Profile
【コラム】
@IT エンジニアライフ 「Bugs Life ～テストエンジニアは不具合と戦い共に生きる」

3. 3
はじめに
本発表の「なぜペアワイズテストを使いこなせないのか」の主語は「私」です。

4. 4
ペアワイズテストとは

5. 5
ペアワイズテストの定義⑴
関連する用語の説明～JSTQB ソフトウェアテスト標準用語集 より～
組み合わせテスト (combinatorial testing)： 事前に定義されたレベルのカバレッジを達成するために、
適切に組み合わせたテストのサブセットを識別する手段。
• ペアワイズテスト (pairwise testing) ： ブラックボックステスト設計技法の一つ。
入力パラメータの各ペアを、設定可能な個々の組み合わせの全てで実行するためのテストケースを設計する。
• n ワイズテスト (n-wise testing)： ブラックボックステスト設計技法の一つ。
n 個の入力パラメータの任意のセットを、
設定可能な個々の組み合わせの全てで実行するためのテストを設計する。
• 直交表テスト (orthogonal array testing) ：
直交表を使った変数のオールペア組み合わせテストの体系的な方法。
変数を全て組み合わせたときの数を、オールペア組み合わせでテストできるまでに減らす。

6. 6
ペアワイズテストの定義⑵
ペアワイズテストの説明～JSTQB ATA シラバス(抜粋)～
• 可能な値を複数持つ複数の入力パラメーターを組み合わせてソフトウェアをテストしなければならず、
組み合わせ数が、許容される時間内にテスト可能な数よりも多く存在するときに使用する。
• 特定のパラメーター(変数または因子)とそのパラメーターの特定の値の組は、
パラメーター - 値のペアと呼ばれる。
• ペアワイズテストでは、組み合わせの技法を使用して、
[各パラメーター - 値ペア] が 他の 各パラメーターの [パラメーター - 値ペア]
それぞれに対して1回はテストをする。
(任意の 2つの異なるパラメーターのパラメーター - 値ペアの「オールペア」をテストする)

7. 7
組み合わせ技法の種類
◆有則 ：組み合わせた結果、出力に影響を及ぼすもの
◆無則 ：組み合わせた結果、出力に影響を及ぼさない(及ぼしてはいけない)
◆禁則 ：組み合わせることができない制限、制約
◆微則 ：？
それぞれのアプローチとして、
• 有則の組み合わせは範囲が狭いため、デシジョンテーブルやクラシフィケーションツリーを用いて、
論理関係やパラメータの同値を整理しながら進める。
• 無則の組み合わせは範囲が広くパラメータも多くなるため、組み合わせテストが適している
⇒ 範囲を広げ、より早く(絞ったテストケース数で)問題を見つけるため
組み合わせテスト(ペアワイズテスト、直交表テスト)における “組み合わせ”の種類

8. 8
過去の失敗から学ぶ

9. 9
過去事例から⑴
テストチームへの依頼
• スマートフォンのメール機能をテストしてほしい
• 機能自体は完成していて、実際にスマホに入れ込んだ状態で不具合を出したい
テストリーダの提案
• スマートフォン内の機能とメール機能を組み合わせたシステムテストを提案
＜理由＞不具合はシングルモードよりダブルモードの方が検出される(※参考事例)
※参考事例
NASAにおけるデータベースの欠陥329個を分析したところ、
全体の93％がシングルモードまたはダブルモードの設定の組合せで欠陥が発生
• 全ての組み合わせは膨大なリソースに合わないため、ペアワイズテストにより効率的に進める
採用され、テスト設計へ…

10. 10
過去事例から⑵
ペアワイズテストの設計
スマホのデフォルトで搭載されている機能の因子・水準を抽出する
因子 水準1 水準2 水準3
メール機能 送信 返信 転送
電話 発信 着信 通話中
音楽アプリ 起動 再生中 一時停止
時計機能 アラーム鳴動 タイマー鳴動 ストップウォッチ開始
No. メール機能 電話 音楽アプリ 時計機能
1設定変更 着信 起動 ストップウオッチ開始
2設定変更 通話中 一時停止 アラーム鳴動
3設定変更 発信 再生中 タイマー鳴動
4送信 着信 再生中 アラーム鳴動
5送信 通話中 一時停止 ストップウオッチ開始
6送信 通話中 起動 タイマー鳴動
7送信 発信 一時停止 タイマー鳴動
8転送 着信 一時停止 タイマー鳴動
9転送 通話中 起動 アラーム鳴動
10転送 発信 一時停止 ストップウオッチ開始
11転送 発信 再生中 タイマー鳴動
12返信 着信 一時停止 アラーム鳴動
13返信 通話中 起動 タイマー鳴動
14返信 通話中 再生中 ストップウオッチ開始
15返信 発信 起動 アラーム鳴動
PICT MASTERでテストケース生成 (約1000ケース)
いざ、テスト実行…！

11. 11
過去事例から⑶
結果
• テストが進まない
- できないテストケースが多数あった
- すべて手動によるテスト、とにかく設定に時間が掛かる
- 不具合が出ない(後述)ということも重なり、テスターも苛立ち始める
- ついにはテスト条件を守らない人も出てくる 「こんな条件、意味ないよ！」
• 不具合が出ない 約1000ケースで3件！
- 発見した不具合内容も、組み合わせなくても検出できそうな不具合であることが判明
- システムテストでの経験則およそ3~5％の不具合検出の見積もりから考えると大爆死状態
- 顔面蒼白のテストリーダは最終日間際に探索テストに方針を切り替え、10件超の不具合を発見
- 事なきを得たが、ペアワイズテストをメインに据えたテスト方針は低評価で案件終了・・・
• 仕様変更に弱い
- 仕様変更などで因子・水準の追加/削除が発生した際、
もう一度組み合わせる必要があるが、パターンが変わってしまう
どうしてこうなったのか

12. 12
なぜ失敗したのか⑴
• 本事例は、無則の組み合わせテスト
「影響がでないことを確認する」テストは、
「不具合を出したい」目的とズレがあったのではないか
• テストリーダは機能を組み合わせたテストに期待を掛けすぎていた
不具合が出る前提でペアワイズテストを実施すると、
不具合が出なかった際、組み合わせを減らしたことが仇になってしまう
「不具合を出したい」というリクエストに、ペアワイズテストはマッチしていたのか？

13. 13
なぜ失敗したのか⑵
• 現実にあり得る条件であるかの考慮がなかった
• テスト条件の順序はテスター任せ
⇒ アラーム鳴動中に音楽再生して電話着信が来たらメール送信する？？？
組み合わせ方法に問題があったのではないか？①

14. 14
なぜ失敗したのか⑶
• 組み合わせの安直さが問題ではないか？
組み合わせ方法に問題があったのではないか？②
スマートフォン
メール機能
電話
時計機能
音楽アプリ
カメラ
カレンダー
送信 受信 設定
スマートフォン
メール機能
送信
受信
設定
SMTP POP3
通信プロトコル 送信方式
外部
ネットワーク
ML 予約送信
個別
設定 時刻設定
タイムゾーン
通信設定
画面ロック／スリープ
◼ 安直なスマホ内の機能の組み合わせイメージ
◼ スコープを広げる組み合わせテスト
↓ メール機能内の組み合わせ
↓ メール機能とスマホ内の機能の組み合わせ
↓ メール機能と外部ネットワーク

15. 15
なぜ失敗したのか⑷
• ある程度、不具合を想定しておく必要があったのではないか？
組み合わせ方法に問題があったのではないか？③
対象機能と他機能の組み合わせ ⇒ 何が起きる？／何が起きてはいけない
対象機能と環境の組み合わせ ⇒ 何が起きる？／何が起きてはいけない
対象機能とデータの組み合わせ ⇒ 何が起きる？／何が起きてはいけない

16. 16
まとめ
• 例えテスト自動化が進んだとしても、総当たり戦のテストは時間が掛かるし、不具合検出の効率も悪い
• 品質を速く上げるため、ペアワイズテストと今後もうまく付き合うことが必要になるのではないか
• メリットの弊害
- テストケースを単純に減らせる技法、とか思っている
- 良い不具合がどんどん効率よく検出できそう！ とか思っている
• 楽してテスト設計しようとしている
• テスト技法への固執 ⇒ 技法を使うことが目的／技法を使わなければいけない
• 期待外れな結果から、次プロジェクトで使用しなくなる
• 結論、勉強不足！ 使いこなすも失敗するも自分次第！
邪念と理解不足がペアワイズテストを失敗させる
ペアワイズテストは必要か