5.4K Views
March 16, 22
スライド概要
JaSST nano vol.7 で発表した「なぜペアワイズテストを使いこなせないのか」の資料を公開します。
なぜ ペアワイズテスト を 使いこなせないのか JaSST nano vol.7 2021.12.21
Profile HOLLY (Touyou Horikawa) 関西のテストエンジニア。キャリア10年を超えてテストの楽しさに気付く。 【主な活動】 • JaSST Kansai 実行委員長 (‘21~22) • 派生開発推進協議会(AFFORDD) 関西部会、研究会 • WARAI (関西ソフトウェアテスト勉強会) 月1回開催 【コラム】 @IT エンジニアライフ 「Bugs Life ~テストエンジニアは不具合と戦い共に生きる」 2
はじめに 本発表の「なぜペアワイズテストを使いこなせないのか」の主語は「私」です。 3
ペアワイズテストとは 4
ペアワイズテストの定義⑴ 関連する用語の説明~JSTQB ソフトウェアテスト標準用語集 より~ 組み合わせテスト (combinatorial testing): 事前に定義されたレベルのカバレッジを達成するために、 適切に組み合わせたテストのサブセットを識別する手段。 • ペアワイズテスト (pairwise testing) : ブラックボックステスト設計技法の一つ。 入力パラメータの各ペアを、設定可能な個々の組み合わせの全てで実行するためのテストケースを設計する。 • n ワイズテスト (n-wise testing): ブラックボックステスト設計技法の一つ。 n 個の入力パラメータの任意のセットを、 設定可能な個々の組み合わせの全てで実行するためのテストを設計する。 • 直交表テスト (orthogonal array testing) : 直交表を使った変数のオールペア組み合わせテストの体系的な方法。 変数を全て組み合わせたときの数を、オールペア組み合わせでテストできるまでに減らす。 5
ペアワイズテストの定義⑵ ペアワイズテストの説明~JSTQB ATA シラバス(抜粋)~ • 可能な値を複数持つ複数の入力パラメーターを組み合わせてソフトウェアをテストしなければならず、 組み合わせ数が、許容される時間内にテスト可能な数よりも多く存在するときに使用する。 • 特定のパラメーター(変数または因子)とそのパラメーターの特定の値の組は、 パラメーター - 値のペアと呼ばれる。 • ペアワイズテストでは、組み合わせの技法を使用して、 [各パラメーター - 値ペア] が 他の 各パラメーターの [パラメーター - 値ペア] それぞれに対して1回はテストをする。 (任意の 2つの異なるパラメーターのパラメーター - 値ペアの「オールペア」をテストする) 6
組み合わせ技法の種類 組み合わせテスト(ペアワイズテスト、直交表テスト)における “組み合わせ”の種類 ◆ 有則 ◆ 無則 ◆ 禁則 ◆ 微則 :組み合わせた結果、出力に影響を及ぼすもの :組み合わせた結果、出力に影響を及ぼさない(及ぼしてはいけない) :組み合わせることができない制限、制約 :? それぞれのアプローチとして、 • 有則の組み合わせは範囲が狭いため、デシジョンテーブルやクラシフィケーションツリーを用いて、 論理関係やパラメータの同値を整理しながら進める。 • 無則の組み合わせは範囲が広くパラメータも多くなるため、組み合わせテストが適している ⇒ 範囲を広げ、より早く(絞ったテストケース数で)問題を見つけるため 7
過去の失敗から学ぶ 8
過去事例から⑴ テストチームへの依頼 • スマートフォンのメール機能をテストしてほしい • 機能自体は完成していて、実際にスマホに入れ込んだ状態で不具合を出したい テストリーダの提案 • スマートフォン内の機能とメール機能を組み合わせたシステムテストを提案 <理由>不具合はシングルモードよりダブルモードの方が検出される(※参考事例) ※参考事例 NASAにおけるデータベースの欠陥329個を分析したところ、 全体の93%がシングルモードまたはダブルモードの設定の組合せで欠陥が発生 • 全ての組み合わせは膨大なリソースに合わないため、ペアワイズテストにより効率的に進める 採用され、テスト設計へ… 9
過去事例から⑵ ペアワイズテストの設計 スマホのデフォルトで搭載されている機能の因子・水準を抽出する 因子 水準1 水準2 水準3 メール機能 送信 返信 転送 電話 発信 着信 通話中 音楽アプリ 起動 再生中 一時停止 時計機能 アラーム鳴動 タイマー鳴動 ストップウォッチ開始 PICT MASTERでテストケース生成 (約1000ケース) メール機能 1 設定変更 2 設定変更 3 設定変更 4 送信 5 送信 6 送信 7 送信 8 転送 9 転送 10 転送 11 転送 12 返信 13 返信 14 返信 15 返信 No. 電話 着信 通話中 発信 着信 通話中 通話中 発信 着信 通話中 発信 発信 着信 通話中 通話中 発信 音楽アプリ 起動 一時停止 再生中 再生中 一時停止 起動 一時停止 一時停止 起動 一時停止 再生中 一時停止 起動 再生中 起動 時計機能 ストップウオッチ開始 アラーム鳴動 タイマー鳴動 アラーム鳴動 ストップウオッチ開始 タイマー鳴動 タイマー鳴動 タイマー鳴動 アラーム鳴動 ストップウオッチ開始 タイマー鳴動 アラーム鳴動 タイマー鳴動 ストップウオッチ開始 アラーム鳴動 いざ、テスト実行…! 10
過去事例から⑶ 結果 • テストが進まない - できないテストケースが多数あった すべて手動によるテスト、とにかく設定に時間が掛かる 不具合が出ない(後述)ということも重なり、テスターも苛立ち始める ついにはテスト条件を守らない人も出てくる 「こんな条件、意味ないよ!」 • 不具合が出ない 約1000ケースで3件! - 発見した不具合内容も、組み合わせなくても検出できそうな不具合であることが判明 システムテストでの経験則およそ3~5%の不具合検出の見積もりから考えると大爆死状態 顔面蒼白のテストリーダは最終日間際に探索テストに方針を切り替え、10件超の不具合を発見 事なきを得たが、ペアワイズテストをメインに据えたテスト方針は低評価で案件終了・・・ • 仕様変更に弱い どうしてこうなったのか - 仕様変更などで因子・水準の追加/削除が発生した際、 もう一度組み合わせる必要があるが、パターンが変わってしまう 11
なぜ失敗したのか⑴ 「不具合を出したい」というリクエストに、ペアワイズテストはマッチしていたのか? • 本事例は、無則の組み合わせテスト 「影響がでないことを確認する」テストは、 「不具合を出したい」目的とズレがあったのではないか • テストリーダは機能を組み合わせたテストに期待を掛けすぎていた 不具合が出る前提でペアワイズテストを実施すると、 不具合が出なかった際、組み合わせを減らしたことが仇になってしまう 12
なぜ失敗したのか⑵ 組み合わせ方法に問題があったのではないか?① • テスト条件の順序はテスター任せ ⇒ アラーム鳴動中に音楽再生して電話着信が来たらメール送信する??? • 現実にあり得る条件であるかの考慮がなかった 13
なぜ失敗したのか⑶ 組み合わせ方法に問題があったのではないか?② • 組み合わせの安直さが問題ではないか? ◼ 安直なスマホ内の機能の組み合わせイメージ スマートフォン ◼ スコープを広げる組み合わせテスト ↓ メール機能内の組み合わせ ↓ メール機能とスマホ内の機能の組み合わせ ↓ メール機能と外部ネットワーク スマートフォン メール機能 カメラ 電話 送信 通信プロトコル メール機能 送信 受信 SMTP POP3 送信方式 個別 ML 予約送信 外部 ネットワーク 設定 受信 時計機能 設定 カレンダー 設定 音楽アプリ 時刻設定 タイムゾーン 通信設定 画面ロック/スリープ 14
なぜ失敗したのか⑷ 組み合わせ方法に問題があったのではないか?③ • ある程度、不具合を想定しておく必要があったのではないか? 対象機能と他機能の組み合わせ 対象機能と環境の組み合わせ 対象機能とデータの組み合わせ ⇒ ⇒ 何が起きる?/何が起きてはいけない 何が起きる?/何が起きてはいけない ⇒ 何が起きる?/何が起きてはいけない 15
まとめ 邪念と理解不足がペアワイズテストを失敗させる • メリットの弊害 - テストケースを単純に減らせる技法、とか思っている - 良い不具合がどんどん効率よく検出できそう! とか思っている • 楽してテスト設計しようとしている • テスト技法への固執 ⇒ 技法を使うことが目的/技法を使わなければいけない • 期待外れな結果から、次プロジェクトで使用しなくなる • 結論、勉強不足! 使いこなすも失敗するも自分次第! ペアワイズテストは必要か • 例えテスト自動化が進んだとしても、総当たり戦のテストは時間が掛かるし、不具合検出の効率も悪い • 品質を速く上げるため、ペアワイズテストと今後もうまく付き合うことが必要になるのではないか 16