API はテストが書きやすいのでバグが出にくいと思っているが、UI を持つアプリはそうもいかない。Selenium や PhantomJS などといったツールもあるが書くのが割りかし大変だしテストが壊れやすいので、これらで画面の遷移パターンを網羅するというのは現実的でない。
自動テストでの担保に限界があるとすると、どうやって手動で検証をするかというのが鍵だと思うので、それについてちょっと考えてみた。
まず、 テスターさんに検証を依頼する という手段が多分かなり一般的なのではないかと思う。
メリットとしては、第三者視点で検証してくれるので開発者自身で気づきにくいバグを見つけてくれたりする。
ただデメリットとして、テスターさんに仕様を伝えるために細かい仕様書を書いたりするコストや、仕様を説明したりするコストが発生するため、開発のスピード感が若干落ちてしまう。（後のメンテナのために仕様書は絶対書けよという意見もあるだろうが、僕はそこはプロダクトの規模で正解はケースバイケースだと思う。）
次に、テスターさんに頼らず 開発者自身で検証する という手段がある。
メリットとしては、コミュニケーションコストが無いので検証のスピードは恐らく一番早い。
デメリットとしては、機能を作った開発者自身だと、「ここは開発中に散々触った機能だから軽い検証で大丈夫っしょー」というメンタリティが 無意識のうちに 多かれ少なかれ発生してしまうものだと思う。それゆえ一般ユーザー視点を失い、第三者であれば絶対やるであろう基本的な検証が甘かったり ... というモラルハザードが生まれる。残念ながらそこがバグの温床になる。
僕としてはどちらの選択肢もデメリットが無視できないのでいろいろ考えた結果、 開発チームの皆で検証する というのが一番いいのではないかと思った。それもリリース直前だけでなく、 1-2 週間に一度定期的に、開発中のプロトタイプを検証も兼ねて皆で触る という手法。
メリットとしては、先の２つの選択肢の良いとこ取りをできるということだ。自分自身の作った機能でなければ第三者視点での検証ができるし、開発チームのメンバーであればプロダクトへの理解は元々あるのでコミュニケーションコストも少なく済む。
さらに、バグを見つける以外にも、機能の良し悪しを実際に触って確かめることができるという副産物もある。 いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 でも書かれているように、作って触ってみるまで機能の良し悪しが分からないことは往々にしてある。
なので次のプロジェクトでは、チームメンバーで定期的にプロトタイプを触る会は絶対に定期的に設けようと思った（過去のプロジェクトでもやってたことあるけど）。まあ、当たり前にやってるところはたくさんあるだろうし、何を今更という話ではあるだろうけど ... 。