NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'15 Niigata

基調講演
「ソフトウェアテストの作り方」
秋山 浩一 （富士ゼロックス）

秋山氏自身の11年のコンサルティング活動の中で、現場で実施されている特に名前も無い方法についてご講演いただいた。なお、講演資料はSlideShareにて公開いただいている。
（http://www.slideshare.net/KouichiAkiyama/20150424-jasst）

品質とテストについて

まず、導入として品質とテストについて会場に考える機会が与えられた。「高品質なんていらない」「テストは無い方がいい」と言われた時、心に引っかかるものは無いだろうか？この時、心に引っかかったものというのが「思い」の核となり、品質やテストを改善しようとした時の人を動かす力となるとのことである。

品質問題について

次に、テストは品質のための手段でしかないということから、品質問題に着目したお話をいただいた。

品質問題には大きく2つあり、大炎上（リコール）と改善の停滞である。
大炎上は、大きな費用損害を伴うため、避けたいものである。しかしながら、いざ大炎上が発生した際に、逆に設備投資を行なった会社もあるように、日頃暖めていた策を講じるチャンスと捉えることも大事である（炎上駆動改革）。
2つ目は忘れがちなところで、改善の停滞である。炎上などを機に始まった改善活動をいつまで続けるのかというのが問題であり、改善効果が無いのに同じ改善活動を続けることで、予算だけが減り、結果大炎上となってしまうことがある。では、いつまで続けるかをどう判断すればよいのか？
テスト費用と品質ロスコスト（品質問題による賠償金等）の動きを改善プロセスの段階でまとめると、初期は、テストにお金をかけてはいるが、テストのやり方が悪いため、かゆいところに手が届かず、炎上が発生してしまうような状況である。この場合、改善の余地があるので、テスト費用を下げつつ、品質ロスコストも下げる（品質も高める）ことができる。しかしながら、あるとき改善の壁にぶち当たり、テスト費用を下げると、品質が悪化するという状況になる。それなのに改善活動を続けてテスト費用だけ下げ続けてしまうと、改善の壁に沿って、品質が悪化していき、いずれ大炎上となってしまう。
効果の無い改善活動の継続による大炎上に至らないためには、改善状況の見える化を行ない、炎上の気配を捉えることが大事である。改善の壁にぶち当たり、品質が悪化する方向に変わった段階で察知し、新たな施策を入れ、改善の壁（改善限界ライン）を超える取り組みをすべきである。

品質改善のために現場で実施されていること

多くの現場で行なわれているのが、致命的なバグかそうでないバグかで取り扱いを変える方法である。そのために、まずは何が致命的か定義すべきである（財産・時間・命を奪う、ブランドを傷つける等）。
致命的なものについては、そもそも静的解析ツールなどを使いバグを作りこまないようにすることや、アーキテクチャでバグの発生自体を防ぐことを検討する。また、保証するケースを定義することや、テストで網羅することで、バグを見つけるといった方策も考えられる。
致命的でないものは、回避策がある場合や、軽微で業務（の本筋）を妨げないものである。これらは発生しても、早く対応することで問題とならずに許容されることが多い。そのため、早期に対応できるような対策をしておくことが考えられる（ソフトウェアの自動更新等）。
戦略を立てて、どこに注力するかを考えるのが大事で、完璧にするのか素早い修正で対処するのかトータルに考えることが重要である。

テスト現場での改良ポイント

人が作り出す機能には必ず目的（価値）が伴うが、その目的が仕様書に書かれるとは限らない。（実際、秋山氏がコンサルティングで訪れた会社では、ほとんど書かれていなかったそうである。）しかしながら、多くの会社は、ほとんどが機能仕様書に対するテストを作っている。お客様が欲しいものとして仕様書に記述したものを確認しているので、必ずしも悪くはないのだが、妥当性確認の部分でテスト技術者のスキルに依存し、再現性の部分で弱くなりがちである。

改良ポイントとしていくつか挙げられていたが、特に以下の２つが繰り返し述べられた。

「要求を立てる」

目的が不明確のまま仕様からテストを作るのではなく、仕様から要求を復元し、要求から妥当性確認をする。何のためにこの仕様があるのか、テスト技術者は常に立ち返る必要がある。例えば、地下駐車場の監視カメラで可動範囲を45度から70度にしてくれという要望を出された場合、それは要求ではなく仕様であり、70度にした理由が要求である。70度にしたいという大本の理由（入り口を撮影したい、カメラの台数を減らしたい等）がわかって、仕様や機能が妥当であるか判断できる。
目的を理解するためには、ユーザの声をよく聞くことや自らがユーザになってみることが大事である。

「良いもの・悪いものを知る」

まず、競合製品等の良いものを知らないと、自分の製品の弱点などに目が行かない。例えば、かな漢字変換にしても、Microsoft IMEしか知らないと、カタカナ→英語変換や類語の提示、誤り訂正などの機能があることを知らず、妥当であるかを判断できない。
また、悪いものを知ることも大事で、クレーム情報やお客様の声などを常に見ることが大事である。毎日バグ票を見ていると、類似事例の中に小さな変化があり、お客様の変化や市場の変化を察知することができる。（Windows 10が使われ始めた、クラウドのExcelが使われ始めた等）

ワークショップ
「検出したいバグから考える組合せテスト技法」
～デシジョンテーブル、HAYST 法の講義と演習～

午後は、組合せテスト（デシジョンテーブルとHAYST法）に焦点を絞ったワークショップが実施された。初心者が業務適用できるレベルを目的としている。タイトルに「検出したいバグから考える組合せテスト技法」とあるが、何を見つけたいのか考えずに技法から入ってしまう人が見られるため、見つけたいものがまずあり、それに対して技法を適用するということを意識してほしいとのことである。
なお、午後の資料については公開の予定はないそうである。

講義

演習に先立ち実例を交えながら、用語やポイントを解説いただいた。

・本技法で検出したいバグについて

バグには実装のバグと仕様・設計のバグが存在するが、本技法で検出したいバグは後者である。
実装のバグは、いわゆるプログラムミスで、プログラマー本人が見つけるべきものである。これが多く含まれているとテスト技術者のモチベーションを大きく下げてしまうため、テスト技術者に渡す前にまずは何かしら１度でも正常終了することを確認すべきである。（プリンターなら、ある条件で１度はきちんと紙が出ることなど）
仕様・設計のバグは、開発者やテスト技術者ではわからない部分であるため、組合せテスト技法により見つけるべきものである。そのうち仕様バグは開発者やテスト技術者の思い込みや理解不足で起きる。開発者やテスト技術者が仕様の背景や市場条件（市場の環境、特性、実態等）など、要求をきちんと捉えられていなかったり、「良いもの・悪いもの」を知らずに見逃したりすることで発生する。
設計バグはソフトウェアの分解誤りやモジュールの独立性の判断ミスなどによる。自分の作るところというのは全体に対して小さいため、自分の作っているところがどこに影響があるかわからないことが多い。（実際、製品の実装が年100万行作られるのに対して1人当たり500行／月程度しか実装が行なわれていないそうである）

では、バグが発生する場合いくつの要因の組合せで発生しているのか。システムにより異なるが1～3程度の組合せで9割のバグが発生しているという研究結果がある。少ない組合せ数であるが、そもそも因子には関係性が無いのが普通で、組み合わせがあるところを探すほうが大変である。関係が無いはずの組み合わせ問題を見つけることが市場に出回るバグを減らす鍵である。

関係がある因子についてはデシジョンテーブル法でテストを実施するが、関係があるかわからないところはHAYST法でテストする。なお、HAYST法による組合せテストで見つかるバグとしては下記のものがある。

• 仕様として想定できない組合せ
• 母体バグの顕在化
• 多様な環境との組み合わせ
• ノイズ（意地悪条件）下
• エラー系の組合せ

・組合せテスト技法の用語について

技法の説明で使われる用語として以下がある。

• 要因：結果に影響を及ぼす可能性のある条件（状態や入力）
• 因子：要因のうち、テストで取り上げるもの
• 原因：問題との因果関係が明らかになった要因
• 水準：因子の中の同時にとりえない排他的な選択肢

要因は場所や天気などいくらでも出てくるので、要因をもとにテストしてしまうといくらでもテストパターンが挙げられる。そのため、因子としてきちんとテストで取り上げる範囲を決定し、入力バリエーションとしての水準の組合せをテストパターンとして設定する。

技法を適用する対象として、以下を区別したい。

• 有則：組み合わせた時に特別な関係がある規則。仕様書に記載された規則
• 無則：仕様書に記載されていない規則
• 禁則：有則のうち入力が禁止されている規則
• 変則：仕様外の値に対する規則

変則は仕様で決まった入力値が守られなかった場合の規則のことで、安全系に倒れるように機能しなければならない（フェイルセーフ）。例えば、ハードから仕様外の信号が来て、ソフトが変な動きをしたとしても、ソフトウェアの問題とみなされてしまうことがあるので、今後重要になっていく。

・組合せテスト技法によるテストパターンの作成方法について

組合せテスト技法でテストパターンを作成する主な流れは、下記である。

1. 因子を整理する
2. 有則や禁則の因子について、デシジョンテーブル法でテストパターンを作成する
3. 無則の因子について、HAYST法でテストパターンを作成する

まずは、因子を木構造に整理する。因子をカテゴライズやグルーピングし、抜け漏れがないようにまとめる。ここで無則の分類を意味のある単位で区分けするということに注意したい。全く意味のないものを組み合わせるとパターンだけが増えていってしまうため、モードなどに着目し、区分けを行なうと良い。

次に、デシジョンテーブルを用いて、有則（や禁則）のテストパターンの洗い出しを行なう。デシジョンテーブルとは、仕様書に記載されたコンディション（条件の組合せ）を列挙し、それぞれに対して規定された動作（結果）を付与し、表にまとめたものである。詳しくは、「JISハンドブック（ソフトウェア）JIS X 0125-1986 決定表」（http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/preJISX.html）が参考となる。

最後に、HAYST法で無則のテストパターンを作成する。HAYST法は「2因子間の組合せを網羅すれば、機能の組合せが原因の不具合のうち、70～90%の不具合が検出できる」という研究結果に着目し、直交表を活用し、網羅率を向上しつつテスト項目数の爆発を抑える手法である。経験則でテストパターンを作成した場合、網羅率は低下し、約30%になるというデータがある。これをHAYST法でテストパターンを作成したところ、80%超の網羅率を達成したとのことであり、網羅率の高いテストパターン作成が大きく期待できる。
HAYST法で作成する手順としては、まず組合せテストを実施する因子の組合せを決め、それぞれの因子に対して、テストで使用する入力値（水準）を列挙する（FL表：因子・水準表）。このとき、水準は同値分割法により必要最小限となるように心がけ、多くても8程度にする。そして、列挙した水準を直交表に割り付けると、2因子間が網羅されたテストパターンが作成できる。
なお、無則のテストパターンは正常系のテストのため、入力不可能な組合せ（禁則）はあらかじめ回避しておく必要がある。

演習

ワークショップでは、仕様書から因子・水準を見つけ、有則・無則のテストパターンを作成する演習を実施した。下記のサイトを題材としたワークショップで、演習のインプットとして料金計算の計算仕様と各項目の入力値の範囲が配布された。

「日本郵便株式会社 - 手紙（定形・定形外）の料金計算」
http://www.post.japanpost.jp/cgi-simulator/envelope.php

主な作業手順は下記である。

1. 因子を見つける
2. 因子を木構造に整理し、有則（いくつかのグループ）、無則に分ける
3. 有則の因子についてデシジョンテーブルをグループごとに作る
4. 無則の因子について水準を列挙しFL表をつくる
5. FL表に列挙した水準を直交表に割り付け、無則のテストパターンとする

実際にワークショップを体験し、筆者は手順2が特に難しいと感じた。有則と無則がこんがらがってしまい、有則用の水準と無則用の水準が混ざってしまうなど、うまく進めることができなかった。有則（デシジョンテーブル）のテストパターンの作成（手順3）や無則（HAYST法）のテストパターンの作成（手順4, 5）はある程度機械的に作業を進めることができたので、いきなり因子をまとめるのではなく、手順を行ったり来たりしながら、最終的に木構造にまとめ、抜け漏れチェックができれば良いのではないかと感じた。

なお、解答例としては有則系44パターン、無則系25パターンが示された。実際に秋山氏によりそのパターンで題材サイトをテストしたところ、きちんと構築されており、すべてのパターンをパスしたとのことである。

QAタイム
「教えて！秋山さん」

QAタイムおよび講演中でされた質問について、主なものを下記にまとめる。

Ｑ：

水準の上手な間引き方はあるか？

Ａ：

重要なものを残すようにする。ただし、有則の水準は間引くことはできない。
無則の場合は、同値分割や木構造で整理して、多くても８水準にする。

なお、ここでいう重要なものとはユーザにとって重要（よく使う、これがないと仕事にならない機能）であったり、開発にとって重要（実装が難しい、心配がある機能）なものを指す。

Ｑ：

仕様書には１つの有則になるような組合せが書いてあるが、その側の厳密に書かれていない部分は有則か？無則か？

Ａ：

仕様書に書かれてなかったら、それは無則である。

仕様書は大切にしなくてはいけない。
検証（Verification）は仕様に対してやるしかないため、その仕様が書いていないとできない。レビューで徹底的に潰して、テスト技術者なども含めて合意をする必要がある。
妥当性確認（Validation）では、仕様から要求を立てることが大事である。要求がわからないと、妥当かどうか判断できない。仕様をもらったら要求を理解して、この仕様で良いかを理解した上でテストをしなくてはならない。
今日は「検証のために仕様を固める、妥当性確認のために要求を立てる」ということを覚えて帰って欲しい。

Ｑ：

FL表で、ある水準の比率を調整するなどはできるか？
最大値を何度もテストすると時間がかかる場合があるので、うまく減らしたいのだが？

Ａ：

まずは、何を見つけたいかというのを考えて、最大値でテストする必要があるかどうかを考慮するのが先であろう。

Ｑ：

「組合せテストの水準には異常値を入れない」とあるが、「エラー系の組合せ」の場合、異常値を入れずにテストできないのではないか？

Ａ：

エラー系の組合せはエラー系の組合せだけでテストする。
なお、エラー系とはいえ、エラーの時にきちんと回避されるのかというテストをするので、正常系のテストになる。

おわりに

筆者はエンタープライズ系であり、秋山氏のベースとする組み込み系の話はこれまであまり聞く機会がなかった。しかしながら、冒頭の三浦氏のアドバイスにあったように、ソフトウェア系であろうと組み込み系であろうとエッセンスの部分は共通しており、そのまま持ち帰れるものが多くあった。特に講演内やワークショップで繰り返しお話しいただいた「要求を立てる」、「良いもの・悪いものを知る」というものは、筆者は経験的になんとなくやってはいたが、後輩や同僚には教えていなかったものだと気付かされた。ワークショップで学んだ技法とともに後輩にきちんと伝えていきたいと思う。
また、筆者は今回はじめて新潟でのJaSSTに参加したが、新潟でのJaSSTは1つのテーマについて丸1日聞くことでき深い理解を得られるなど、東京でのJaSSTとの違いが感じられた。その他の開催地もそれぞれの地域の特色が出ていると伺ったので、機会を作って、他の開催地も回ってみたいと思う。