テスト！テスト！テスト！

世のプログラマはGUIテストをどのように実施しているのでしょうか。
私は今までGUIより下層のコード実装が主たる業務だったので(それこそテストデータを流してのリグレッションも朝飯前ちゅう感じの代物だったし)、今回GUIからドライバまで丸々実装ちゅう業務が初めて。色々と頭を悩ませることが多いです。ちゅうのも、GUIちゅうのは組合せが莫大であり、すべてのパターンを網羅するちゅうことは工数から見ても不可能だと思うのです。それこそ、Windowsじゃないにしろ、Wordとかの多機能なアプリケーションとかMSはどのようにテストしているのか知りたい。AdobeはPhotoShopをどのようにテストしているのか知りたい。機能同士が複雑に絡みあうGUIアプリケーションの効率的なテスト方法とは。本当に銀の弾はないのか。

当初、開発を始めた段階で、私はGUIのリグレッションをどうやるか考えてみました。しかし、考えれば考えるほど「無理です。。。」て感じになって、そいや自動化ツールとかあったなって思い出して調べてみたのですが(何をどう自動化するのかさえ知らなかったので)、挫折記事の多いことに愕然としました。夢のツールだと思ったら大間違いだ！とか、逆にコストが嵩んだとか。。マジですか？ちゅか、実体験しないとその答えは見つからないのですが、どうも失敗談の要点を掻い摘むと、GUIが変更になったら作成したテストセットがお釈迦になったとか、テストセットも開発の一つなので慣れるまで時間がかかるとか何とか。いや、それは当たり前だろうと思うのですが、確かに細切れにセットを作成しても、一箇所インタフェースが変更になったら、すべてのセットがお釈迦になるようじゃ意味がないですね。それは、設計そのものが駄目なんじゃ？とか思うのですが、すべて憶測ですので、やはり実体験しかありません。あと、自動化ってリグレッションでしか使う意味がないと思うのですが、じゃあ、GUI(コードじゃなくて)カバレッジを手動でやるとしましょう。とあるAウィンドウを開いて設定、Bウィンドウを開くと設定内容が反映ってところまでをテストケースとしても、この後Bウィンドウを開いたままAウィンドウを閉じると落ちるって現象が発生したら、一体どこからどこまでが機能(カバレッジのエンドポイント)なんだよ！てなる訳で、その切り分けを考えるだけで死にそうになる。ちゅか、パターンをかなり狙って行くか、人海戦術で偶然発見するかしかないじゃない。そんな狙ったパターンなんて分析しても結局漏れはある訳で、100%保証なんてない。そんなパターンに限って、エンドユーザの操作パターンで楽勝に出現してきたりする予感もする(笑)。まぁ、それは分析力と想像力の欠如に起因するのですが。GUIテストの組合わせパターンの膨大さに辟易しています。これを世のプロジェクトが馬鹿正直にやっているとは到底思えません。やはりパターンを絞るしかないのですかね。バグが発生したら「いや、それはレアケースなんで。。。」て言い訳が通じるとは思えません。

そんなこんなで、色々なテスト工学の文献を読んでいるのですが、本当に銀の弾はないのでしょうか。人類の英知の結集しても駄目なんでしょうか。きっとあるはずなんですが。最近、寝るときはいつもこればかり考えています。