「ソフトウェア業界が直面している最先端のテスト課題」パネルディスカッション聴講レポート #ICST2017

はじめに

  • ICST2017の中で、「Bleeding-Edge Testing Challenges that the Software Industry Faces」(ソフトウェア業界が直面している最先端のテスト課題)というタイトルで、GoogleAppleのエンジニアが登壇して、パネルディスカッションを行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation


セッションのコンセプト(司会のAtif Memonより)

  • 今回のようなセッションに近いこととして「産業界とどのようにやっていくか」という題材をほぼ毎年やっています。
  • 前提として学術界では制約のかかるところからやっていく手法をとってます。
  • しかし毎年「産業界には何も起こらない」という結論になっています。
  • なので今年は少しアプローチを変え、産業界の方々にご登壇して頂き、セッション中に出てくる問題に対して学術界から何かを提供できればと考えております。

登壇者の紹介(司会のAtif Memonより)

  • 話しやすい人を選んでいるつもりです。一人ひとりご紹介します。

John Micco

  • 1日目の基調講演を担当しました
  • GoogleのTACチームにいる
  • テストチームとして自動化を行い、開発者にFeedbackをしている
  • ただし、リサーチもしているし、ペーパーも出している

Murat Ozturk

  • Googleでリサーチをしている
  • パブリッシュもしている。

Adithya Nagarajan

  • Appleに勤めている。
  • リサーチャーの悩んでいることも理解しているはずです。
  • Microsoftなどに転職し、現職はAppleです。
  • Appleのオープン化も進めている。

Bao Nguyen

  • Googleに勤めている。
  • モデルベースをやっている
  • リサーチの結果を使い、業務に活かしている

自己紹介

司会

  • 皆さんはリサーチをサポートしている方々です。
  • まずは5分ずつ話してもらう
  • 特に未解決の部分を話してもらう
  • 登壇者にはこのイベントのFeedbackもくださいと言っている
  • 「ここはリサーチを見ているし聞いている」とか「この部分は産業に関しては必要ない」とか言ってもらいたい。
  • 批判をしていただいても結構です。

Adithya Nagarajan

  • 私の勤めているApple知名度…については聞くまでもないですか。
  • ICSTのような学会イベントには2002年に最後に参加して、そこでは色々なことを学んだ。
  • 15年ぐらいこの業界にいるが、産業界と学術界での色々なGAPを見ていた。
  • 我々は、実は原始的な技術を使ってハイクオリティなサービスを作っている。
    • Fuzzyなツールを使っている。
    • ツールはもっと拡張できるはずだと思っている。
  • 実際にソフトウェア・エンジニアリングを使っている
  • 並列化してアジリティがなければならないと感じている。
  • テスト優位性については変わっていない
  • コラボもできるかもしれないいくつかのエリアがある。
    • データは沢山あります。
      • 仕様データとか。
  • それを使ってテストを改善できるのではないかと思っている。
  • テストスケーリングの問題がある。
    • 優先順位をつけるとか。
  • テストの軽減をしたいと考えている。

Murat Ozturk

  • Adithyaの話を聞いていて、相当似た部分があると感じた
  • Googleに6年以上勤続している
  • ほとんどをテストに関することに費やした
  • マネージャも勉強した。
    • 役割を勉強したいと思った。
    • ロールのカバレッジをしたい
  • ツールとインフラストラクチャもやっている
  • 共通の間違いとして、私たちはテストを書く人だと勘違いされています。
    • 私は最適化をしようとしている。
    • テストケースの効率化などは考えていますが。
  • 問題から始まって、スコープ化して解決しようとしている。
  • Flakyなことをして問題解決をしている
  • 私はあまり良い生徒じゃなかったので、プレゼンテーションの準備が出来ていません。
  • Flakinessは私達のやってきていたことです。
  • どうやったらプロセスの中で緩和できるのか。
  • インフラの中で解決できるのか、これをFlakyテストといっています。
  • どうやって解決するのか。ツールを作って問題を解決したりとか
  • スケールの問題もあります。拡張も重要です。
  • Googleから見た問題に関してお話します。
  • スケールについてはシステムテストレベルだったりテストセットがあります。
  • もっともっと拡張していくと思う。
  • これをうまく最適化できないか考えています。
  • 想像できないぐらい大きいです。
  • ベストなテストケースをなるべく少ない数でできないか考えている。
  • また、その方法を見ていく
  • レイヤーを組み合わせることになると、どのテストをしなければいけないかを見なければいけない。
  • 世の中に非常に多くのアプリケーションが出ている
  • 自動運転車も出ている。
  • この中でももっと調査研究が必要。
  • どういう貢献ができるか、コラボレーションができるか考えている。
  • 皆様に情報を発信し、皆様から情報を得たい。
  • データをどんどん活用してください。
  • 私の方で問題があるので、「誰に聞けば良いですか?」と聞いてくれれば、私が適切な社員を紹介します。

John Micco

  • 解析、仮説については使わなければいけない
  • 問題点は私達が見つけるのとまた違うはず。
  • データセットを見つけてもらえればと思う。
  • 研究もある。
  • もっと大きな産業界のデータセット
  • ただ、問題が少しあります。
  • もっともっとデータを共有するためにオープンにならなければならない。
  • それぞれ独立してリサーチ結果を出している。
  • 同じようなことを同じような問題を抱えていながら別々に発表している。
  • これらを別々にやってはいけないと考えている。
  • 重複してはいけない。
  • 皆さんは接着剤、橋渡しとなるような存在にしてほしい。
  • 機密にするのは意味が分からない。
  • 機密情報でお金を儲けるのではなく、他のところで儲けるべきだ。
  • 全てのデータセットをシェアすべきだと思っている。
  • マニュアルQAはやっていない
  • 2週間1回やっているということを言われたが、本当に必要があればやるべきだと考えている。
  • また他のテクニックについて、Fazzing、自動テストについて。問題はある。
  • 大きなアルゴリズムでバグがあるものはテストしない。
  • リサーチとは違い、適用可能なものからやっていく。
  • 私達ができるものもあった。適さないものもあった。
  • 毎日何百回も起こるので、Flakyの原因を自動的に追求できれば価値があると思う。
  • 似たような問題が他にもあるのだなと驚いた。
  • 現在は99%以上のファームで行われているテストで合格するということです。どれが失敗するか分かる。これはできると思う。
  • 99%を除いた所だけやれば効率良くテストが出来る
  • 回帰テスト・組み合わせテストがある。
  • 例えば、qualityを保証するためにいくつぐらいやれば良いのか
  • 回帰テストを最適化するという話をした。スケジューラの話もした。
  • このようにテストのスケジュールをするにはコンビネーションを考えることが必要です。

Bao Nguyen

  • 私は産業界に移った経歴がある。
  • Scale、スピード、2週間でテストを行う。すぐにテストを行うことがある
  • 同時並行で行うとなると、並行して全部行うことになる。
  • 多ければ良いとなっている。
  • 課題はコミュニケーションの問題がある。
  • Johnさんと同じ。同じ課題に違う方法でやってしまっている。
  • テストもそう。ただし違う意味合いでやっている
  • Googleは仕様を見ていく。
  • 会社によって意味合いが違っていきます。

討論

聴講者

  • スウェーデンの場合、産業界と学会は非常に多くのコラボがある。Ericssonもそう。
  • データがあっても、そのまま使えるわけではない。
  • 例えば関連性が低いものもある
  • このデータは間違っていないのかという確認が必要になっている

Murat Ozturk

  • 確かにそうだと思う
  • 生データはノイズが多くなってしまっている。
  • 研究者のドアを開くという意味で提供したいと思っている。

John Micco

  • 色々なことがデータに入っている。
  • データに有用であるという約束はできませんが、データをサニタイズするだけでも意味がある。
  • とはいえ、リサーチャーによって価値のある物になっていないといけない。

Murat Ozturk

  • 一つ気付いたことがあった。
  • 私はもっと学会に出るべきだと思った。
  • 足がかりはそこからできるのではと感じている

聴講者

  • フライトリサーチをやっている
  • 日常のビジネスと並行することが難しいと感じている。
  • 何かアイディアはありますか?

Adithya Nagarajan

  • モデルベースのテスティングのリサーチャー、学生だった頃、業界はモデルベーステストを使っていなかった。
  • 今やっていることをスケール化していくことができる
  • 業界側ももっと学ぶ必要がある。
  • だんだん起こってくると思う

聴講者

  • リサーチの結果は出ているが、インプリが出来ていない。
  • アイディアはあるが、やり取りをするには時間がかかる。

Murat Ozturk

  • その見方から欠落しているものがある。
  • どう応用し、適用するのか。
  • もしリソースが食うのであれば、インフラも見ていく必要がある。

聴講者

  • リサーチだけでなく業界側も両方必要。
  • How toの部分のチャンス、メソッドをまだ把握できていない。

聴講者

  • 協業していくためにはリサーチのペーパーをソリューションとしてシンプルではないかもしれないが、概念的なものがあれば良い。
    • シンプルなもので適用できるもの
    • 複雑だが適用にローコストなもの。
  • 概念的に素晴らしくても適用が難しいことがある

Bao Nguyen

  • 一つ思うのは、理解し合えていない。
  • ソリューションがシンプルでも進化させていかないと分からない。

Murat Ozturk

  • そのとおりだと思う。
  • 現在だと理論を理解するのにエネルギーを使って、使えるのか考えるのに時間を食う。
  • このソリューションの応用がペーパーでわかると良い

聴講者

  • ソフトウェアエンジニアリングのリーダーをつとめていて、品質などを扱っている。
  • エンジニアは問題を解決するためにできている。
  • 大学、学会と業界にGAPがあるとおっしゃっているが、ソフトウェア・エンジニアリングが科学を用いて解決することをしているはず。
  • デンマークではYahooのクラウドプラットフォームがある。
  • 課題を投げかけてくれれば、これが解決できるかどうかの判断ができるはずだ。

Murat Ozturk

  • 私もそう思う

聴講者

  • 先程の方が仰ったような、シンプルソリューションの話。
  • 通信会社と一緒にやっている。
  • もっともシンプルなものが80%ぐらいしかできない。
  • 洗練することを繰り返すことで皆さんが使えるものになる
  • シンプルソリューションを示すのは産業界としては必要なのかも。
  • もしも必要ならば、こういう可能性があるなという示す

Murat Ozturk

  • そのとおりだと思う。
  • 非常に驚いたが、10年ぐらい学術界に出てなかったが、Industryトラックがあることに驚いた
  • Topicも非常に面白かった。
  • 中間を考えていかなければいけないと感じた。

Bao Nguyen

  • ここで勘違いしてもらいたくないのは、シンプル化はモデルではなくシンボル的なものです。
  • モデルが非常に難しくても、お互いが努力することでもっとわかりやすく出来る。

Murat Ozturk

  • 企業はスケールができる。
  • それがわかった上で、私達が持っているリソースを提供できればと思う。

聴講者

  • おそらく課題を全部が解決したら中小企業になると思う

感想

  • GoogleAppleでも同じようにテストの効率化について悩んでいると知ることができて良かった。
    • ただし、テストケースそのものに興味を持っている点は、テスト設計に興味を持ち、その部分から効率化しようとしている日本のテスト業界とアプローチが異なると感じた。
  • 研究のシンボル化という話はうなずける気がする。
    • 企業の研究についても、結局どうやって他社に適用してもらうかが重要だと思ってる。
  • パネルディスカッションの進め方として、登壇者だけでなく聴講者も参加している形式は良いなと感じた。

テストの教育についてのパネルディスカッションはこちら

nihonbuson.hatenadiary.jp

  • この記事のパネルディスカッションの直後に行われたものです。