第199回： 「ソフトウェアテストしようぜ」15 GIHOZ（2. ペアワイズテスト前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、GIHOZの紹介とウェブアプリのテストで大切と思うことを書きました。
私がウェブアプリのテストで一番大切にしていることは、「UI/UXの評価」です。重箱の隅を突くテストはしません。、、、と本人が思っているだけかもしれませんが。
「重箱の隅を突くテスト」とはなにかについては、テスト対象によって変わると思っています。辞書を引いてみたので引用します。
じゅうばこ【重箱】 の 隅（すみ）を楊枝（ようじ）で=ほじくる［=つつく］
些細な点まで干渉、穿鑿したり、どうでもよいようなつまらない事柄にまで口出しをすることのたとえ。
なにが些細で、なにが些細でないか、、、。「どうでもよいようなつまらない事柄」とどうしてわかるのか？？？
重箱の隅か否かの2択で考えたら、「重箱の隅をつくテストなんてない」という人もいると思いますが、実際のところどうなんでしょうね。
「1から100までの数に対して3で割り切れる数はFizz、5で割り切れる数はBuzz、 3でも5でも割り切れる数はFizzBuzzと表示する。それ以外の数は数字のまま表示する。」は、有名なFizzBuzz問題の仕様です。
（プログラミングの練習問題だけれど、うっかりしていると間違える）
さて、このプログラムに0を入れるテストは重箱の隅をつつくテストでしょうか？
そして、0を入力したときに、FizzBuzzと出たら入力チェックが甘いと報告しますか？
さて、前回の「おわりに」のところで私は、『最初は「境界値分析ツール」かなあ？』と書いたのですが、GIHOZのGUIの順番にあわせて、「ペアワイズテスト」から始めることにします。
≡ リポジトリの公開
すみません。ペアワイズの話に入る前に記事用のリポジトリを公開しようとしたらこんなコンファーマがでました。
リポジトリ名を入れると、ボタンに色がつきます。
赤いボタンを押すと公開されたようです。
コンファーマが出るのはよいとしても、なぜリポジトリ名をユーザーに入力させるのでしょう？
コンファーマのメッセージ内にリポジトリ名が書いてあることからわかるように、GIHOZ側はどのリポジトリに対する操作かわかっているのに。
最初見たときには、「公開範囲を変更、、、」と書いてあるので、公開範囲を入力するのかと思ってしまいました。なお、公開範囲は「公開・非公開」の2種類しかなさそうです。
こういうGUIはよくないと思いました。
≡ 「ペアワイズテスト」について
ペアワイズテストについては、2005年のJaSST大阪（当時はKANSAIではなかった）で、土屋先生とセッションしたことを思い出します。読み直したら、私がここに書くよりも土屋先生の資料を読んでもらえばいいやと思いました。（ので、ペアワイズテストの紹介については書きません。直交表については以前の私のnoteをご覧ください）
ペアワイズテストについては、必要性から話した方が良いと思うので、昔話を書きます。
1990年くらいのときに、コピー機にFAX機能がつきました。「オフィスにコピー機とFAX機があると邪魔だから1台にならないか」との要求にこたえたものです。
どうやって作ったかというと、コピー機の中の空いているスペースにFAX用の電子ボード（通信とか、絵作りとかを行うための電子ボード）を押し込んでつくりました。
さて、FAXは画像を0と1のデジタルに変換して相手に送るものです。一方で、コピーは画像をアナログのまま転写するもの（ライトレンズと言います）でした。
全然違う仕組みで動いていたのですが、外から見たら似ていますし、「FAXで読み取った原稿を通信に送らずに自分にループバックさせたらコピーになるのでは？」と安易に考える人もいらっしゃったようです。
でも、考え過ぎてチャレンジしないよりは良かったかな。
FAXは読み取りが遅くても気にならなかった（普段は数枚ですし、多くても10枚送るくらいでしたので、1枚に1分かかっても問題なかった）のですが、コピーのほうは、１分間に40枚で中速機というくらいでしたし、そもそも、会議参加者に配布するために原稿1枚を複数部にコピーする使い方が普通でしたので性能には敏感でした。
そんなこんなで、細かく見ていくと、コピーとFAXでは、必要な品質特性はかなり違っていました。そこで、先に書いたとおり、コピー機の中の空いているスペースにFAX用の電子ボードを押し込みました。要は、用紙送りと画像転写をする装置（以下IOTと呼ぶ）と原稿読み取り装置（IIT）は共有するけど、あとは勝手にやってねというわけです。
まるで、冷めきった夫婦が同じ家に住んでいる感じでスタートしました。
実際のところFAXを開発していたグループとコピーを開発していたグループは、拠点も離れていたことから交流が少なかったですし。
1台になったコピーFAX機にはそういうわけで、コピー用の電子ボードとFAX用の電子ボードが差し込まれ、それぞれ自分の仕事をこなすという形でした。
さて、このときに、ネックとなるのは、例えば、大量コピー中にFAXが届いたときです。別々のボードで同時に処理するわけですので、CPUは良いとしても、2つのボードが共有するBUS（データの流れ道）やIOTの制御を上手くしないと、コピーとFAXが混ざってしまうからです。
それでも、ボード2枚差しアーキテクチャは共用資源の管理さえ頑張れば、なんとかなります。（簡単ではなかったけれども）
次の波がやってきました。「コピーとFAXが一体になったのなら、プリンターだって統合できるはずだ。それを複合機と呼ぼう」というわけです。このときは、同時に「カラー化」の波もやってきました。1995年くらいのことです。
カラー化はデータ量を一気に32倍にしました。白黒では、1画素1ビットで済んでいたものをCMYKの各色8ビットで、32bit必要になったからです。
ソフトウェア屋からしたら、データ量が増えれば遅くなるのは当たり前なのですが、ハード屋さんからするとそれは受け入れ難いことで、「カラーで同速のIOTを設計したぞー」と明るく言ってきました。
前の会社では、1980年代から、すでにワークステーション用のレーザープリンターを当たり前に使って仕事をしていました（世の中的には、ワープロとドットプリンタ、もしくは、Macとレーザープリンタを直結してつなぐ方法が主流で、ネットワークに直接プリンターをつなぐのは珍しかったように思います）、その流れでコピーとFAXが同居したのだからプリンタの同居も簡単なはずだと考えていた人がいるようなのです。
さて、ここで、プリンター用の電子ボードを増やす？ という話になるかと思いきや、「それはないだろう。1枚で行こう。原価をダウン出来るし」と。これもまた、簡単に考えた人がいるようなのです。
かくして、1枚の電子ボードにコピーとFAXとプリンターのソフトウェアが共存することになりました。このときに大きく２つのシステムアーキテクチャが生まれたのですが、それはまた別のお話なので今回は割愛します。
頭が痛いのは「これまであった機能は無くしてはならない」という掟です。
いま、これを読まれている方のなかには、一度も使ったことがない人もいると思うのですが、【割込】ボタンがコピー機にはあります。
だれかが大量コピーを取っているときに、「ごめん、ちょっと1枚コピーさせて」と割り込んでコピーするためのボタンです。
人間なら意識すらしない割り込み作業です。
人間なら、だれかとおしゃべり中に電話がかかってきたら「ちょっと失礼」っていって電話に出て、終わったら「なにしゃべってたっけ？」ってすぐにおしゃべりを再開できます。
でも、これをシステムで実現するのは、けっこう難しいものです。
「割込ボタンさえなければ、リリースを半年短縮してもいい」って言った開発者がいるくらいです。それが、今度は、プリンターやFAXの動作とも関係してくるわけです。機能もめちゃくちゃ増えていました。
こういうことが、私が経験した複合機だけではなく、例えば携帯電話でも起こりました。携帯電話にカメラが付き、音楽再生機能が付き、GPS地図アプリが付き、、、と。
雪だるまのように機能が次から次へとくっつきました。機能を増やすのは、インターフェースを上手くつくれば、ＯＳ上で複数のアプリケーションが動くようになんとかなります。でも、問題はテストです。
スマホを例にしたら、「写真を撮っているときに着信があったら」、「音楽再生中に電子マネーを使ったら」、、、というように組み合わせて使っても問題がないことをテストしなければなりません。
ただ、組み合わせの数は掛け算（2, 4, 8, 16, 32, 64, 128, 256, 512, 1024,…）のように、指数関数的に増えていきます。俗にいう組合せ爆発です。
そんなときに、掛け算ではなく、足し算でテストケース数が増えていくペアワイズテストが役に立ちます。
≡ ペアワイズテストの使いどころ
昔話に書いたように、何かに対して、後からあとから機能を追加していくようなときに、ペアワイズテストで全体の組合せを広く浅くテストすると良いです。昔につくった機能のことを知らない開発者が新しい機能を接ぎ木するので昔の機能との間に不整合が起こることがあるからです。
また、例えば、生命保険の申込書のように、たくさんの入力項目があり、さらに、特約事項のようなほかの条件と絡んでくるような入力がある場合もペアワイズテストは有効です。
他には、貿易システムのように様々な国の法律の組合せの評価が必要な場合に使えます。
一方で、小さなソフトや良く練られたアーキテクチャ上で他の機能との干渉がほとんどない場合や、ルールベースエンジンなどで自動生成したソフトウェアに対してペアワイズテストをしてもあまり効果はありません。
と、ペアワイズテストの使いどころについて書きましたが、仕事上は「結果」から活動をスタートする方が良いです。
つまり、「ペアワイズテストを導入するぞ」から始めるのではなく「今の自分のテストではどのようなバグを見つけることができていないか」を改善活動の起点とするということです。
具体的には、
1. バグを記録する
2. DDPを導入して各テストレベル（例えばシステムテストなど）の前後でバグを何%見つけたか、欠陥阻止率を明らかにする
3. 欠陥阻止率が85%未満の場合、見逃した欠陥を分析して次回は85%以上になるように対策を打つ
ことをします。
上記の3のときに、因子間の組み合わせが原因となったバグを見つけることが出来たら85%以上になると分かったらペアワイズテストを導入することが有効ですので導入します。（何因子間のバグが出ているかを確認しておくと良いです。3因子間の組合せバグも見つけないと85％に達しないなら直交表を適用するか、ペアワイズテストの強度を3にするなどの対策を打てるからです）
「またその話か」と言われそうですが、以下の引用の通りです。プロセスの評価を入力（何をしたか）で測って改善してはなりません。プロセスの改善はプロセスの結果をよく見て分析して、改善すべき点に手を打ちます。CMMIではCAR活動と呼びます。
◆ 手法やプロセスは手段。運用段階にて目的化することで失敗する
• 新しいやり方で結果を出したいとの思いが、失敗したくないという気持を起こす
• 「せめて新手法のやり方は間違えずに進めたい」と強く思う
• 結果的に、「その新手法で何を実現するか」という目的を見失う
≡ おわりに
今回は、ペアワイズテストの必要性と使いどころについて書きました。
次回は、GOHOZのペアワイズツールを使いながらGIHOZのテストをしたいと思っています。
◀前の記事へ 次の記事へ▶
この記事が気に入ったらサポートをしてみませんか？