駆け出しテストエンジニアと組み合わせテスト技法
組み合わせテストというワードがあります。
テスト対象における因子(パラメータ)と水準(パラメータが持つ値)を抽出し、それを網羅的に実行していくアプローチです。
例) エアコンの設定における因子・水準
| 因子 | 水準1 | 水準2 | 水準3 |
| 動作モード | 冷房 | 暖房 | 除湿 |
| 風量 | 自動 | 強い | 弱い |
| 設定温度 | 適温(自動) | 30℃(最大値) | 18℃(最小値) |
このように抽出した因子・水準を組み合わせた動作を行いテストを進めていくわけですが、上記の簡単な例でも全ての組み合わせのパターン数は27になるので、実際のプロジェクトに適用した場合のボリュームは未経験の方でも想像がつくかと思います。
このテストボリュームを効率的に減らす技法として謳われるのが、組み合わせテスト技法というもので、「直交表」や「ペアワイズ法(All-pair)」を用います。
ネットでの解説や書籍も出ているので詳細な説明は割愛しますが、n因子間網羅という考え方で、因子同士の水準のペアを網羅することで、全ての組み合わせを行わずに高い検出率で不具合を見つけることが出来る、というものです。
例) 2因子間網羅による組み合わせパターン
全パターン数27→10に削減
| TC ID | 動作モード | 風量 | 設定温度 |
| 1 | 除湿 | 強い | 30℃ |
| 2 | 除湿 | 自動 | 18℃ |
| 3 | 除湿 | 自動 | 適温 |
| 4 | 除湿 | 弱い | 30℃ |
| 5 | 暖房 | 強い | 18℃ |
| 6 | 暖房 | 自動 | 30℃ |
| 7 | 暖房 | 弱い | 適温 |
| 8 | 冷房 | 強い | 適温 |
| 9 | 冷房 | 自動 | 30℃ |
| 10 | 冷房 | 弱い | 18℃ |
これを駆け出しエンジニア時代に目の当たりにした私は、
「こうやってテストを効率化しているのか、テストエンジニア凄い」
などと思っていたわけです、しかし...！という話が今回のコラムです。
そんな簡単な話ではなかった組み合わせテスト
これで設定項目が多いテスト対象のボリュームも減らせる、やれ安心だ...なんて、そんなにテストの世界は甘くありませんでした。
まず、安直に(深く考えずに)因子・水準を抽出し組み合わせテストを技法と合わせて提案するとこう言われました。
「なぜ全てのパラメータを組み合わせるのか？」
「通常のシステムテストとの違いは何？」
「それぞれの組み合わせに意味はあるのか？」
「組み合わせテストによってどれくらい不具合が出るのか？」
「テストしていない組み合わせで不具合が出たらどうするのか？」
自信ありげに提案した上司も回答に困り、
「これはタグチメソッドで使われている技法でして・・・」などと読んだことも理解もできないタグチメソッドの資料を漁る始末。
結果的には、システムテストのメインはこの組み合わせテストでやりましょう、と合意に至ったのですが、想定した不具合検出数には届かず、その不具合も組み合わせ技法を使用しなくても(単機能テストで)検出できたものばかり、と散々な目に遭ったわけなのでした。
こうした経験からしばらくは組み合わせテストと技法には疎遠になった私ですが、今はHAYST法(テスト分析/組み合わせテストのアプローチ)を愛用しています。つまり、なぜ当時はダメだったかがわかってきた、ということです。
組み合わせテストに失敗した理由
駆け出しのテストエンジニアがテスト効率化に夢を見た組み合わせテストになぜ失敗したのか。
考えられる理由は幾つもありました。
①有則と無則を理解していない
影響のある組み合わせ＝有則、と、影響がないと考えられる組み合わせ＝無則、を分析し、組み合わせパターンに考慮すべきだったということです。
基本的には、2因子間網羅のような組み合わせテストは無則のパターンに適用し、有則の組み合わせは重点的に(より網羅的に)実施するのが良いかと思います。
②組み合わせテストをメインにしない
基本的には無則の『影響がないと考えられていたけどそうではなかった不具合』を見つける組み合わせテストをメインに据えたのは、綿密さに欠けるアプローチだったのではないかと思います。
③テスト自動化を検討していなかった
パラメータの組み合わせによるテストというのは、手動で行うと非常に精神的にも体力的にも浪費します。
延々似たパターンのテストに疲れ、
「この組み合わせは以前にもやったような...」というデジャブに捉われたり、
「この組み合わせはもう不具合出ないよ」と経験から勝手に簡略化しようとするテスターも出てきます。
こうしたテストこそ自動化を検討すべきです。
組み合わせテストはやり方次第
ソフトウェアテストを勉強すると境界値分析／同値クラスの次くらいに出てくる有名なアプローチであるに関わらず、組み合わせテスト技法は実践ではあまり用いられていないように思います。
それは駆け出しテストエンジニア時代の私のような失敗経験を皆がしていたり、先輩社員から聞いたからなのかはわかりませんが、全てはやり方次第、目的に合えばやるべきだと私は思います。
私自身はいくつものプロジェクトでHAYST法のアプローチを愛用していますが、因子・水準の抽出とテスト分析を経て、小規模で組み合わせて用いることが多いです。
無則の組み合わせにはそれほど期待を掛けず、不具合が出ればラッキー、出なければその機能間の品質を担保できたとポジティブに捉える、そのような感覚で良いかと思います。
今回はソフトウェアテストの技法の話でした。
コラムも10回を超えるのにソフトウェアテストの技術の話題がないことを私も気にしていたので、過去の失敗談を振り返りつつ書いてみました。