テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（前編） JaSST'15 Tokyo

2015年3月24日

ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。

シンポジウムの最後を飾るクロージングパネルでは、基調講演に登壇したマイケル・ボルトン（Michael Bolton）氏、チェンジビジョンの平鍋健児氏、ACCESSの松木晋祐氏、サイバーコネクトツーの八田博和氏が登壇。

モデレータの東洋大学野中誠による「これからの時代、テストエンジニアとデベロッパとの幸せな関係」とはどう変化してきたか、変化していくのか、という問いかけに対し、現在のテストエンジニアとデベロッパーの関係や、よりよい関係とはどういうものなのか、さまざまな議論と提案が行われました。

本記事ではその内容をダイジェストで紹介します。

テストエンジニアとデベロッパとの幸せな関係

左から、東洋大学野中誠氏、マイケル・ボルトン（Michael Bolton）氏、チェンジビジョン平鍋健児氏、ACCESS 松木晋祐氏、サイバーコネクトツー八田博和氏

野中氏（モデレータ）　JaSST 2015 Tokyo、最後のセッションとなるクロージングパネルでは、「テストエンジニアとデベロッパーとの幸せな関係」について議論していきたいと思います。

さて、この幸せな関係とはなんでしょうか？例えば、デベロッパーからはテストエンジニアに対する期待や、テストが開発に貢献する役割といったものがあると思います。

しかしその期待や役割が、例えばアジャイル開発やWモデルが登場し、テスト自動化技術が登場するなどの技術の変化や環境の変化が起きている中で、時間とともに変化しているのではないか。

そういった視点で、まずは過去から現在に至るお話をしていただきたいと思います。

テスターと開発者は敵対関係ではなく

平鍋氏　私は「永和システムマネジメント」という会社で受託開発をしているのと、「チェンジビジョン」という会社でAstahというUMLを描くツールを開発しています。

私は以前から日本のエンジニアにアジャイル開発を紹介するということをずっとしてきていて、アジャイルで日本の開発の現場をもっと元気にしたいと、そう思ってます。

で、私がテストやテスティングとアジャイルとの関係に初めて気がついたのは、2003年のソルトレイクシティのカンファレンスでした。そこではじめてテスターの人がやっているワークショップに参加して、もちろんそこではテスト技法の話もあったのですが、いちばん印象に残ったのはキャンディの話だったんです。

開発者がテスターに質問をしにくる。バグ表のここはどういう意味なんだと。そしてコミュニケーションをしに来た人にはキャンディーをあげることにして、テスターと開発者は敵対関係にあるのではなく、できるだけたくさん話し合える環境を作ることが最初の仕事だったのだと。

そのとき僕はアジャイルの謎がひとつ解けて。アジャイルってドキュメントを書かないのではなく、早い段階からコミュニケーションをする、できるだけ多くの情報を早い段階で共有して問題を解決することで品質を上げていくのだ、ということがアジャイルの特性のひとつだということに気がついたんですね。

どういうことかというと、これはジッパーなんですが、左が開発者の考え、右が品質保証の考えで、最後にテストをどんとやってジッパーを合わせようとしても、理解が長い間分かれていると難しいですよね。

理解の食い違いが長い間続いていると、それを取り戻すのは難しいです。だから、アジャイルではなるべく早い段階でジッパーがかみ合うように、考えを合わせていくのが大切だと。だから早めにレビューとかテストをすると。

開発チームの生産性向上という役割もテストエンジニアに

松木氏　私はモバイルとかWebテクノロジーが大好きで、そんな変化のスピードが速い分野でテストエンジニアとして貢献できないかと思って、テスト自動化のコミュニティなどもやってきました。

まず、これまでのソフトウェアテストは、あくまで品質保証技術の主要なアクティビティの1つで、テスト分析だったりテストデザインであったり、伝統的なプロセスを重視したり、あるいは開発者とのコミュニケーションはバグレポートというドキュメント中心だったりしたと思います。

また、非機能要件、セキュリティや性能や、といった分野のテストにはかなり高いスキルが要求されると。

で、現在とこれからは、QAという枠だけでなく、開発チームの生産性の向上という役割も、今後テストエンジニアが担っていける役割になるのではないかと考えています。大事なのは、QAの分野がしぼんだりするのではなく、テストエンジニアのフィールドが広がっているということです。

ここでキーテクノロジーになりそうなのは、効果的なテストの自動化。静的テストとしてレビューやインスペクション、メトリクス、探索的テストなんかも、すばやくテスト結果を返せる点で重要だと思っています。

それから仮想化については、テストのターンアラウンドタイムを短くするために主要な技術で、テストの実行環境を簡単に増やせる。これもターンアラウンドタイムの短縮に寄与するかなと。

昔はパフォーマンステストやセキュリティテストのためには高価なツールも必要でした。しかし最近はオープン化の波でオープンソースのツールがでてきたので、ツールのアシストも加速しているのかなと思います。

こういった技術の進歩の流れは、デプロイメントのパイプライン、つまりコードが書かれてからお客さまに届くまでの一連のプロセスを、テストエンジニアがデザインすることがそろそろ可能になるのではないかと思います。

ゲームにバグがないかだけでなく面白いかどうかも見る

八田氏　私が所属するサイバーコネクトツーというのはゲームの開発をしている会社です。私は2009年に入社し、現在はQAチームのリーダーをしています。

これまでのお二人の話をゲーム業界から見ると、品質保証で異なる点があって、それはバグがないということと面白いということの両面を求められるということです。この2つをうまく取り混ぜてQAとしてやっていかないといけないのかな、と強く感じています。

開発者とQAチームがどうやっていい関係を築いていくかですが、弊社のQAチームの取り組みとして、ゲームの仕様を決めるミーティングに積極的に参加して、早い段階で仕様を把握すると。こうするとどこでどういうテストが必要かあらかじめ分かるので。

過去のバグを元に実装チェックリストを作ってもいます。これを開発者に提供しています。同じバグの作り込みを未然に防ぐことができ、開発側はバグ修正の手間が省けますし、テスターもバグを見つける手間が省けて、お互いにうまくいってる部分かなと思います。

野中氏（モデレータ）　アジャイル開発やWモデル、テスト自動化といった技術の変化とは関係なく、開発とQAの距離が遠いことが問題で、それを縮めていくことに八田さんが関与してきたという傾向が強いのかなと受け止めたのですが、八田さんはこうした技術や外部環境の変化をどう見ていますか？

八田　ゲーム業界もプレステ1から2になるときに大きな変化があったりとか、10年ごとくらいには技術も変わっていますが、その中でもずっと開発者といかにコミュニケーションをとって不具合をださないか、といったことがメインで、なかなか難しいのですが、技術によって関係が変わってくるというイメージではないですね。

平鍋　QAの人が開発の人と一緒にやるというのは、むしろ（エンタープライズ業界より）ゲーム業界の方が進んでいると思いますね。エンタープライズ系だとウォーターフォールなんかではいちばん最後にテストが入りますからね。

その違いは、もしかしたらビジネス構造の違い、発注の仕方とか、そういったことなのかもしれません。

八田　昔は弊社でもなかなかできてなくて、プロジェクトでデバッグの時期がきたらアルバイトをやとってまとめてデバッグして、終わったら解散とか、そういう方式でしたが、それだとなかなかノウハウがたまらないのです。だから社内のQAを作ろうとなって、ノウハウをためることで開発者から頼りにされるようになった、という感じです。

いまは開発者から「ミーティングがあるから出てくれないか」と誘われるようになりました。

ターンアラウンドタイムを短縮することで貢献する

野中氏（モデレータ）　もう一歩踏み込んで、技術的にこんなやり方をすればもっと開発とテストエンジニアの関係を近づけられるとか、貢献できるというのはありますか？

松木氏　開発にもっと貢献するという意味では、なによりターンアラウンドタイムを短縮することだと思います。

ターンアラウンドタイムとは、コードにバグが埋め込まれてから発見されて報告されるまでの時間です。これが長いほど、開発者はいやがる。コードを書いて、レビューのときに「ここにバグがあるよ」と言われれば「あ、たしかにそうだ。ありがとう」となると思うのですが、コードを書いてから3週間後とかにバグがありますと報告されても、もうそこの部分は書き終わってると思ってしまっているので、指摘されるとしんどいと。

だからターンアラウンドタイムを短くするのは、開発効率を上げる1つの方法だと思います。

じゃあどうすれば短くできるか。

機能テストを1つ1つ全部自動化すると、メンテナンスが大変になってしまします。ユーザーがどう使うか、いちばん大事なところのテストを自動化して、コードがコミットされるたびに自動テストを回して10分ぐらいで結果を開発者に返す。こうするともっと貢献できるんじゃないかなと思います。

≫後編に続きます。後編では、品質について決定権を持つのは本当にQAなのか、などについて。