昨日はこんな勉強会に参加してきました。
今夜、Webアプリの正しいUIテストの方法が決定されます : ATND
結論から言うと、タイトルの通り、Webアプリの正しいUIテストの方法は決まらなかったんですが、テーマ自体は興味深いテーマだと思いますし、今後も継続的に勉強会が開催される模様なので、とりあえず感想と今後期待することをまとめておきます。
ちなみにこのエントリは僕の感想をだらだら書くためのものであり、セッションの内容を説明するものではありません。どういう話があったのかについてはTogetterにまとめていただいていますので、こちらをご覧いただければと思います。
今夜、Webアプリの正しいUIテストの方法が決定され…ませんでした！ - Togetterまとめ
UIテストとは何か
まず、UIテストとは何なのかという問いに対する回答が昨日会場にいらっしゃった参加者の皆さんでおそらくバラバラだったのではないかと思います。実際パネルディスカッションでもそういった話題があがりましたし、それに対する回答も各パネラーで結構違っていた印象があります。
パネルディスカッションの最後の質問が非常によい指摘だと思ったのですが、つまり「UIテスト」とは
- UI"を"テストする
- UI"を操作して"テストする
のどちらなのかということなのだと思います。
それなりに多くの人が後者をイメージしていて、実際僕もそちらの立場で参加したのですが、前者の立場で参加された方が多くいらっしゃるのだとすると昨日の話はちょっと違っていた気がします。
自動化が前提なのか？
僕がセッションやパネルディスカッションを聞きながら感じたもう一つの違和感はほとんどの方が自動化を前提にお話をされていたことでした。
自動化できなければそれはUIテストではないみたいな空気を感じるけど、どうなんだろ？UIとUXを厳密に区別すればUIは機械的にテストできるはずってことかなー？ #html5biz
— 末並晃 (@a_suenami) 2014, 5月 27が、これについてはイベント概要をちゃんと読めって話でちゃんと明記されていましたね。ごめんなさい。
誰もが一度は考えたことがある、WebアプリのUIテストの自動化。上手く導入できている人もいれば、そうでない人もいるかもしれません。また、導入できたとしても、コストが増えただけで何が良かったのかよくわからないという状況に陥っている人もいるでしょう。
今夜、サイボウズやDeNAなどUIテストの自動化を現場で導入しているエンジニアや、企業向け開発へ適用を進めるエバンジェリストの口から、UIテストは何が嬉しいのか、どうやって扱えば良いのか、「正しいUIテスト」について語って頂きます。
ただ、単に「UIテスト」と呼んだときにそれは必ずしも自動化できるとは限らないんじゃないかと思っていて（もちろん先に述べたUIテストの定義にもよります）、自動化ありきではなく自動テストと人間によるテストの境界を見つけにいくほうがより有意義な議論になるのではないかと思います。
何らかのAPI等でない限り、通常UIの先にいる"ユーザ"は人間であることが多いのであり、それを完全に自動化できると考えるのは若干危険だと思っています。
もちろん議論を重ねた結果、自動化できるという結論に行き着くのだとすればそれはすばらしいことです。がんばってそこに到達しましょう！
僕がUIテストと呼んでるもの
僕が「UIテスト」という言葉から以下のようなことをイメージしました。
一応自分の考えを書いておくとUI”から"テストするのがUIテストかなと思っていて、そういう意味ではイコールE2Eテストかもだし、イコールシステムテストかも。ただ、UIを触る人に理解できる言葉で書かれてることが大事だとは思っている。 #html5biz
— 末並晃 (@a_suenami) 2014, 5月 27僕はまさに「UIを操作してテストする」のが「UIテスト」だと思っていた人です。
そういう意味では「E2Eテスト」や「システムテスト」とほぼ同義語なんですが、テストの記述をそのUIを利用するユーザの言葉でできてるかどうかが肝だと思っていました。
これについてはパネルディスカッションの質疑応答のときにきょんさん（ @kyon_mm ）が言っていたことに概ね同意で、「○○という画面の上のほうにある青いボタン」とか「○○をしたら～というエラーが出た」とか言うわけで、そういう言葉でテストを記述できてるかどうかが「UIテスト」と他のテストの違いだと思っています。
僕が期待していたもの/今後期待すること
「ユーザの言葉でテストを記述する」ことと「自動化する」ことの相性はさほどよくないと思っています。特に先に述べた「上のほうにある青いボタン」や「画面中央に表示されるエラーメッセージ」は高度な画像解析技術でも駆使しなければ自動化は難しいのではないかと思っていて、おそらく大抵のケースにおいてコストに見合わないでしょう。
現実的な落とし所は、そういったユーザによる自由な表現にある程度の制約を設けて「登録ボタン」や「登録失敗エラーメッセージ」といった名前をテスト設計者側がつけ、仕様書やユーザテストやその他のあらゆる場面でできるだけその言葉を使ってもらうことなのではないかと今のところは思っています。
そういったユーザがもつ表現力とテスト側の都合で生じる言葉ができるだけ乖離しないようにテストケースやテストシナリオを設計するためにはどういうプラクティスがあるのか、UIのさらに先にあるユーザのメンタルモデルにより深く踏み込む方法はないのかといったことが知りたいと思っていて、僕個人としてはそういった議論を期待しています。
僕が最終的に目指す先はこのツイートの前者のような世界だったりします。ただ現実的にはまだ難しそうなのでユビキタス言語を構築しようとしている感じですね。
自然言語で書かれた要求を自然言語処理に食わせ、そこから自動テストできるとか理想だけど、例えばExcelで作られたテスト表で人力テストしてもテスターによってテストの品質が変わることを踏まえると、やはり完全な自然言語は困難で、ある程度厳格なユビキタス言語は必要だな。と週末に妄想した。
— 末並晃 (@a_suenami) 2014, 5月 25壮大な理想だとは思いますが、目指し甲斐はあるかと。
