読者です 読者をやめる 読者になる 読者になる

#ICST2017 に参加してきました!

ICST2017

すごく今更感がありますが、ソフトウェアテストの世界最高峰の国際カンファレンスであるICST2017に参加してきました!

ICST2017の公式ページ(日本語版)

ICST 2017 | ICST2017のページへようこそ!

私が参加したセッションを紹介し、簡単な感想を書きます。

1日目

基調講演「The State of Continuous Integration Testing at Google. 」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

Non-Semantics-Preserving Transformations For Higher-Coverage Test Generation Using Symbolic Execution

  • 実践的なプログラムコードに対してどのように単純化し、最適なテストケースを作成すれば良いかということを考えた研究でした。

Uncertainty-Driven Black-Box Test Data Generation

  • あるプロダクトコードに対してテストケースをランダムに選択するのではなく、機械学習を用いてもっと効果的なテストを選択できないかという研究でした。

Automated Test Generation and Mutation Testing for Alloy

  • テストケースを生成する際に、カバレッジを気にしながらテストケース生成する方法があるが、それ以外にミューテーションで破壊されるようなテストケースを生成し、そのテストケースの有効性を確認した研究でした。

NIVAnalyzer: a Tool for Automatically Detecting and Verifying Next-Intent Vulnerabilities in Android Apps

  • セキュリティ的に脆弱性のあるプログラムコードを検知する仕組みを作成し、既に公開されているAndroidアプリについて脆弱性が無いか確認した研究でした。

Efficient Safety Proofs for Industry-Scale Code using Abstractions and Bounded Model Checking

  • この発表はあまり理解出来なかったです…。

System Testing of Timing Requirements based on Use Cases and Timed Automata

  • タイミングが関わる機能のテストについて、状態遷移に工夫をすることで、より有効的なテストケースを生成するという研究でした。

A Comparative Study of Manual and Automated Testing for Industrial Control Software

  • 同じ製品に対し、自動テスト生成と手動テスト生成を行って、カバレッジやミューテーションがどのように違ったのか比較した研究でした。

How Do Assertions Impact Coverage-based Test-Suite Reduction?

  • 一般的にはテストカバレッジを気にしてテストケースの削減を行っているが、Assertionを気にしてテストケース削減を行ってみた研究でした。

Automata Language Equivalence vs. Simulations for Model-based Mutant Equivalence: An Empirical Evaluation

  • ミューテーション、ランダム、ユースケースからのそれぞれのテストケース作成に対して、強度なミューテーションが発生した場合に検出が出来るのかという研究でした。

2日目

基調講演「Testing and Validation Requirements for Automated Driving Technology.」

  • 自動運転についてトヨタの方が発表しました。
  • トヨタがどのような考えを持って研究しているのか、どのような最新の研究が行われているのか発表していました。

Perphecy: Performance Regression Test Selection Made Simple but Effective

  • パフォーマンステストの回帰テスト方法について提案した研究でした。

A Selection Method for Black Box Regression Testing with a Statistically Defined Quality Level

  • 過去の故障確率に基づいたテストケースの選択方法を提案した研究でした。

Private API Access and Functional Mocking in Automated Unit Test Generation

  • プライベートメソッドに対しての単体テストを上手く行う方法を提案した研究でした。

Using Semantic Similarity in Crawling-based Web Application Testing

  • 自動テストで用いられるDOM要素をベクトル化して、機械学習でどのような値が入るのか自動的に判別するという方法を提案した研究でした。

Barista: A Technique for Recording, Encoding, and Running Platform Independent Android Tests

  • Androidテストを行うツール Baristaの紹介とその効果の検証についての発表でした。

ATOM: Automatic Maintenance of GUI Test Scripts for Evolving Mobile Applications

  • Versionがどんどん更新されていくようなツールに対してのGUIテストのアプローチの提案をしていた研究でした。
  • 状態遷移図を描けば、振る舞いが大きく変わらない状態ならば対応できるはずだ、みたいなことを言ってた。

Transferring State-of-the-art Immutability Analyses: Experimentation Toolbox and Accuracy Benchmark

  • 正直、よく覚えてない…

Accelerating Test Automation through a Domain Specific Language

  • GebやSelenideといったSeleniumラッパー系のツールATAPの紹介
  • eclipse上でサジェストが出るのが特徴
  • 休憩中、発表者に色々と質問した。

Taming Coverage Criteria Heterogeneity with LTest

  • 一つ前の発表の内容ばかり考えててあまり覚えておらず…。

3日目

基調講演「Model-Based Testing and Model Inference: Better Together!」

  • モデルベーステストのお話
  • テスト設計も自動化出来るという夢のあるお話だったが、イマイチ自分の言葉には咀嚼できず…。

Are there any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects

  • Pythonで書かれたコードのテストがISTQBで定義されている単体テストになっているか調べた。
  • 調べ方は、テストコードが1つのimportだけを読み込んでいるかどうかで判断した。
  • 疑問点が一つあったから発表者に質問した。

パネルディスカッション「Bleeding-Edge Testing Challenges that the Software Industry Faces - an Invitation to Researchers to Address these Challenges」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

パネルディスカッション「Quality and testing in Software Engineering curriculum」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

全体的な感想

色々と社内、国内だけでは知り得なかったことが感じ取れて本当に良かったです。

おまけ

  • 朝食(毎日バイキング形式で提供されてた)

f:id:nihonbuson:20170412004012p:plain

  • 1日目の夕食(立食形式)

f:id:nihonbuson:20170412004025p:plain

f:id:nihonbuson:20170412004033p:plain

これらも参加費にコミコミでした。

#ICST2017 基調講演「The State of Continuous Integration Testing at Google」聴講レポート

ICST2017

はじめに

  • ICST2017の中で、「The State of Continuous Integration Testing at Google」というタイトルでGoogleのエンジニアであるJohn Miccoさんが基調講演を行いました。

  • ICST2017公式ページ

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

発表スライド

http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf

今日話すこと

  • Googleのテストの状況を話す
  • 開発者が3万人頑張っている

Googleについて

  • 420万のテストケースが継続的に動いている
  • 1億5千万のテストケースが動いている
  • ほぼ全てが自動化されている
  • Googleは自動テストが好き
  • 開発者はテストに時間をかけられません
  • 1万3千行のプロジェクトチームがある
  • 99%がテストに合格している
    • 失敗することはたまにある

テスト文化について

  • 自動化テストを促進する文化がある
  • 10年の文化がある
  • コードビューがある
  • テストの経験についても話し合う
  • Googleの新入社員に対してテストの仕方を教える
  • SETIでテストについて教えている
  • コードビューでモニターしている
  • チームに取り込まれているプラクティスを行う
  • 他にも色々行われている
  • 420万のテストは開発者が行っている

回帰テスト

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
  • 例えばfoo.hを選んだ場合は赤部分のところをテストする(スライド5ページ)
  • 選択が適切にできればスケジュール化しなくても良くなる
  • クレームから状況を解析して行う
  • 1秒間に変更を2つ行うとBackendが追いついていかなくなる

Presubmit testing

  • 粒度の細かい従属性について見ていく
  • 同じプールを使って
  • Presubmit testを上手く使ってコミットを行う
  • コードビューツールがテスト結果を検知して却下したりする
  • 開発者の判断ミスによって壊れないようにする

Postsubmit testing

  • リグレッションテストが上手く行っても、それでOKではない
  • テストの優先順位は付けない
    • 時間がかかるし
  • なるべく並列に行う
  • Backendとしてキャパシティがあるか確認する
  • スケジューリングの場合、どこかが空かないとやれないから
  • passしたらflagをたてて変更を書ける
  • 2年間のテスト結果やコンソールログを保存している(DBに入れている)
    • どのようなファイルのエディットをしたかなど

グラフ

  • チャンジリストを表している(スライド10ページ)
  • 横軸が時間、縦軸が個々のテストを表現している
  • グラフの1つ目の縦軸は回帰テストを4つ行うことを表している
  • 今までの変更を見て、マイルストーンを引いて、多くのテストのトリガーを引くことになる
  • キャパシティが溜まった時にテストが行われる
  • 45分間ごとにテストを実行される
  • 1日1回45分ぐらいで行われる
  • 最も直近で影響を受けた変更を探し出す(スライド11ページ)
  • きちんと順番通りになっていない可能性もある(スライド12ページ)
  • これをDBに入れて、どれがGreenなのか探す
  • 失敗した場合、何が原因で失敗だったのかを明らかにする(スライド14ページ)
  • どの変更がBreakしたのか判断する必要がある
  • 回帰試験のセレクションをして、スケジューラが必要になる
  • これを塊にしなければならない
  • キューに入れてバッチに入れる
  • もしある特定のシステムが受けた場合、システムのものなのかユーザーのものなのか明らかにする
  • ツールが失敗した場合は再実行を行う
  • 開発者のサブミッションと合格・不合格の判断をなるべく速くする
  • マイクロスケジューリング
  • 原因がどこにあるのか
  • ケースのリストアップをしていく
  • ギャップを埋めていく
  • 開発者が破壊する恐れがある
  • 限られたリソースで済むようにする
  • 破壊実験をしていく

Flaky(スライド21ページ)

  • あてにならないテストのこと。
  • コード以外のものには従属していない
  • テストのアイソレート化、切り分けが必要
  • 全体の16%はFlakyである
  • プロダクトのリリースをブロックすることが多い
    • 全てのパスしなければいけない
  • 16%はいつかFlakyになる
    • 全体で1万近くのテストがあるので1000近くある
  • 何か問題があるとFlakyだから、となってしまう
  • 2%〜16%はFlakyテストを再送されることになる
  • このFlakによって赤信号になってしまう
  • マイクロスケジューラだとパスするかなと思うかもしれないが、緑にするためには、Flakyもクリアする必要になる
  • プロダクションコストに関してはフレーキになる
  • どのくらいのコストがFlakyにかけてしまうのか

  • 何が原因なのか

  • テスト実行の1.5%がFlakyの継続率になる

    • これをFixさせないといけない
      • Fixさせるのは時間がかかる
  • Flakynessを緩和しないといけない

システム

  • Flaky testを認識する
  • failedになると、Flakyになるか確認する
  • 10回それを走らせてFlakyであると判断する
  • スタックトレースもDBに保存する
  • Flakynessレベルに変更になる。(1%のFlaky率から5%のFlaky率に変更など)
  • 自動テストをして、Flaky状態も管理する
    • 例えば、50%のFlakyになるGmailは上手くいかないだろう、とか

OSS

  • Bazelなどのように、OSS化して公開しているものもある(Bazel.io)

学会のリサーチについて

  • OSSプロジェクトのものに対して仮説をたてる
    • 実用性には欠ける
  • Sponser resercherの方々や学生に協力を頂いて、データセットのペーパーを出している
  • Googleコードベースも仮説をたてている
  • 1つのテストがFailになった時に何が原因なのか調査している
  • 1億5000万のテストの結果をOpenにしている
  • 業界と学会のコラボレーションで解決ができるはず
  • API frameworkも作成している
  • かなりのビジネスチャンスがある
  • インターンシップもある
  • journal clubに参加すると、月刊誌をお送りする

質問

3rdPartyについて

  • 異なる言語の自動化をどのように行っているのか
  • また、テストコードと開発コードを同じ言語ですべきか
  • 他の言語で書くこともできるが、枠組みとしては同じ言語で行う
  • 慣れ親しんでいる言語で行う

コンカレンシー問題

  • Flakyテストだとコンカレンシー問題があると思う
  • Flakyの診断をする。もう一度実行するなどを行う
  • ある程度のレベルのFlakynessはあるがそこまで心配していない
  • パーフェクトな状態ではない

マニュアルテストとの兼ね合いについて

  • マニュアルテストとのリンクにしているのか
  • マニュアルでメンテを行っている
  • 必要でないdependencyは削除しているが、基本的にはマニュアルで行う
  • 過度に依存している問題はあるが許容する必要がある

包括的なテストについて

  • 包括的なテストであるが、どのような形でどのタイプを行うと選択しているのか。
  • ある制約がある
    • どのくらいの規模で…
      • 15分
      • 4Coreで
  • E2EテストはFrameworkの中で行う
  • 大きなインテグレーションテストを行う時、45分の中でテストをしていく。
  • システムテストだけではなく必ずUnit testとシステムテストの両方が必要である

Flag optionについて

  • Flagの組み合わせの問題に直面にしなかったのか。
  • 全ての組み合わせをテストするのは不可能ですよね?
  • Flagの組み合わせに対しては相当きつい制約をしている。
    • 例えば、キャッシングに制約をかけるようにしている。
  • 例外にすることはできるがほとんどしていない。
  • Optが失敗してDebugが成功することもあるが…。

  • 400万のこーどがあると言っていたが…。

  • プロダクションテストはあるが、その他のテストはしない。
  • 新しいVersionとして全てうまくいくか
  • プロダクションサーバイメージに対して行う
  • sandboxテストとプロダクションテストは違うということか?
  • そうです
  • これはABテストか?
  • そういうことです

420万のテストケースについて

  • 420万のテストケースは増えていっているのでしょうか?
  • テストプールは常に増えていっている
  • テストケースの最適化は行っているのか?
  • 自動化の分析は行っていない。
  • ただしテスト品質の解析をしている。
  • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない
  • Backendが有限になると思うと、テストの質に意識するようになった。
  • テストについても何らかの責任をもたせることは大切

  • UTestで開発者が作ったもの。自動的なケース。自動化で良い点。どこでどこで使われているのか

  • テストを書くことが企業理念になっている
  • テストリソースを消費してしまう
  • 探求にも時間がかかってしまう

感想

  • テストケースをbreakした時の判断の仕方が良いなと感じた。
  • 「Flaky」という言葉を使って、テストの種別をするというやり方は参考になった。

「ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて」パネルディスカッション聴講レポート #ICST2017

ICST2017

はじめに

  • ICST2017の中で、「Quality and testing in Software Engineering curriculum」(ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて)というタイトルで、各国の大学教授・准教授が登壇して、パネルディスカッションを行いました。

  • ちなみに、聴講者も意見を出していたのですが、意見を出していた殆どが、前回の記事で書いたGoogleAppleのエンジニアだったと記憶しています。

nihonbuson.hatenadiary.jp

  • ICST2017公式ページ

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

このパネルディスカッションのコンセプトについて(司会のShlomo Markより)

  • 最近4年間でソフトウェアのエンジニアリングをやっている
  • ここでは、ホワイトペーパーを出している。
  • Test、クオリティについて産学連携には沢山の問題がある。
  • それに関しても、私もできるだけ研究に移したいと思う。
  • それでは、パネリストの方には自己紹介をしてもらいたいと思う。

自己紹介

  • パネリストには、何を課題として考えているのか伝えてもらう。

Ina Schieferdeker

  • 品質エンジニアリング、解析についてもどういう教育が大学で行われていくのか考える必要がある。

Jens Krinke

  • 当初、ソフトウェアエンジニアリングのプログラミングに関しても、問題解決ベースだった
  • 学生は最初からアプリケーションを作っていた。
  • 学生はハッキングなども技術をやったりもしている。
  • しかし本当の意味を理解していない。
  • 普通のところからソフトウェア・エンジニアリングを話すことになる。
  • テストもそうです。
  • 5年間を考えてみると、業界が変化していくので追いつかなければならない。
  • コンセプトを考えて、テストの要素をなぞらえていかなければならない

Tanja Vos

  • プログラミングをしているのに対し、テストコードを書かなければならない。
  • それは難しい。
  • テストに関しては教えを請いたくないと言われる。
  • 教えるときには、何がステートメントなどを教えて、テストの方をやらなければならない。
  • しかしテストを後から教えることになっても意味がない

森崎修司

  • 私はソフトウェア工学を教えている。
  • 大学と大学院の両方で教えている。
  • 論文のリクエストやコメントもやっている。
  • その他、博士号過程などで教えている。
  • このディスカッションを行っている中で色々と産業界に提起したい。

討論

Shlomo Mark

  • 各国でどのようなことを行っているか。
  • 例えば私の場合、学生はマシーンランニングがやりたいと言ってきたりする。
  • そのときには最初から品質やテストを教える。
    • 問題に直面するから。
  • そしてUnitテストに入っていく

Ina Schieferdeker

  • 動機づけは、ソフトウェアの作っていることの安全を考えなければならないから。
    • 最近の研究ではエアバッグについて。
    • 他にも医療機器とか。
  • そういったところから見ると、テクニックだけではなく、例えば専門家になったときの責任も教えている。

Shlomo Mark

  • 学生になぜテストを教えるのかが難しい

Ina Schieferdeker

  • 皆さんの仰るところは私も思う。
  • 私は何にそれを適用するのかを教える
  • 研究側ではプロトタイプを使う。
  • ソフトウェアの重要性がある。
  • システム側の品質も必要になる
  • 20年関わっているが、「なぜこれをやらなくてはいけないのか」と学生に問う。
  • どの部分をやっているのかを明らかにさせる。
  • 本当の意味での品質レベルを製品に落とし込まないといけない。

聴講者

  • シリコンバレーの場合、どのような理由でできないかをはっきりさせる。
  • テストに関してバックグラウンドがある人しか雇わなければ良い
  • なので学士以上のところが必要

Jens Krinke

  • このような比較ですが、例えばマシーンラーニングだけしたいと言ってくる学生がいる。
  • そういう学生に対してはソフトウェアテストや品質は学ぶ必要がない。
  • ただし、エンジニアではない人がやるとなると一貫性が無くなる。コンセプトがなくなってしまう。
  • パッケージに関しても、最初に品質を学ばなければならない。

Tanja Vos

  • 教育の最初にクオリティを学ばせないといけない
  • 例えば、
    • プログラムを見ていく。
    • 学生に関してはプログラムで検証していく。
    • デバッグをしていくときに対してUnitテストをさせたりして埋め込む必要がある

聴講者

  • テスト志向というのは非常に大切。
  • どれぐらい文化を変えるのに、テストを分かっていない人を変えるのがすごい大変です。というか不可能です。
  • テストを学んでいない人にテストの話をすると、その瞬間に水を失った魚みたいな顔になる。
  • 結果的に、そういう人を雇用できなくなる

Ina Schieferdeker

  • それから教授がいかに説得させるか。
  • 論文などをICSTに参加している方に向けて書いていますが、学生の教育のタスクとしても書いている。

聴講者

  • 機械学習をやっていてもコードを書いている以上、それを健康的な状態に保つためにはテストが必要。

聴講者

  • 5年間Masterでコンピュータ・サイエンスをしている。
  • 1年目からテストケースを与えてテストコードを書いている、実際に開発者テストを書いている。
  • よりテストパターンとしてできるものをやっていく。
  • 上手くいっているところもあるが、Functionalテストになると、どういう風にやっているのか分からない。
  • ツールも入れて、そこの部分も学生に紹介しようと思っているが、それは出来ていない。
  • テストの話をすると、コードがテスト無しで正しく動いているかどうかという方向性にいってしまう。
  • 文化として試行錯誤するという考え方にできていない。
  • ダメならば別のコードをやればよいとなってしまう

聴講者

  • テストを書くことのクールさに学生が気付いていない。
  • 大学に入る前にテストを書いているという人がいない。
  • なので、カリキュラムの中でも厳しくする必要がある。
  • 例えば、コンテストをするとか、インタフェースを設けるとか。

聴講者

  • これは学生の問題ではない
  • ツールやチャンスはある。
  • この命題に関しては好きな人もいるはず

Jens Krinke

  • 学生がこれが好きではないという話については、学生的にはやることには問題ない。
  • こちら側がカリキュラムを変えている。
  • 多分、1,2年あたりで起こると思うが、4年生の方のカリキュラムを変えている。
  • 同じモジュールを異なったコードにしたり。
  • ソフトウェアエンジニアリングをどのように改善していくのかも大学でやっている

聴講者

  • 学生への教え方が変わっていっていくことに驚いている。
  • 一緒にやっていこうというアイディアですね。

聴講者

  • 最も賢い1年生に対して「テストをやっていないとパスできないよ」と伝えてほしい。
    • それがたとえ宝石のようなプロジェクトをやろうとしていても。
  • Googleのインタビューはテストを書かない人と無理です。受け入れられません。
  • 我々はテストを扱える人を求めている。
  • マーケットも求めているし、アカデミックもそうでしょうか?

森崎修司

  • 優先順位について。何がいちばん大切なのか。
  • 同意です。
  • グループワークをやっていて、何人かの学生はそれを学んでシェアする必要があると思っているようです。
  • プログラミングの講義をやっていると、何人かの人は本人で学んでいく人もいる。
  • テストは教えられるべきものなのか。
  • QA活動は気付いたり、生徒自体が発見していくことが大切ではないのか?

聴講者

  • quality testingについてはどう考えているか?

Ina Schieferdeker

  • 大抵は比較をしている。
  • テスターが沢山いるので、大学で学んでいる人もいるので、ソフトウェアエンジニアリングが厳格に勤勉に学んでいかなければならないものである。
  • ソフトウェアエンジニアリングは完璧なものではない。
  • 他のものも鑑みた上で、何をプログラム化すべきなのか。
  • ソフトウェアエンジニアリング以外のものも含めて、より厳密に扱っていく。
  • 例えば、パブリックセクターとプライベートセクターの両方で構築すべきだと思う。

Jens Krinke

  • いや、そうは思わない。
  • クオリティは他の人がやってくれるからと言われてしまう。
  • これは何年も前のやり方で上手くいかない
  • ソフトウェアエンジニアリングの経験を積んだ人が扱う。
  • 大学では品質を教えることができないのだと思う。
  • セルフエンジニアリングのトレーニングはできると思うが、大規模なことをやっていないので品質のトレーニングは無理です。

Tanja Vos

  • 別の講義で教えるということはダメだと思う。
  • 最初からテストについて教えるべき

聴講者

  • 私は少しだけ同意する。
  • そもそも教育時間が短い。
  • きちんとしたエンジニアを育てる、ある程度の教育、プリ教育として、クオリティエンジニアに関しては1つ1つ教えるだけでなく、他のことも教えることになる。
  • 他の専門性も含めて学ばなせなければならない。
  • 博士号でその道のスペシャリストを育成できればと考えている

聴講者

  • どなたか共創の話があった。
  • ベストスキルというようなコミュニケーションが必要だと思う。

聴講者

  • 私は2つのトラックに分ける必要ではないと思う。
  • エンジニアである場合、もちろんソフトを書いてテストを書かねければならない。

Shlomo Mark

  • テストを教えるとして品質は教える必要があるのか。

聴講者

  • 産業界では別にしている。
  • ただ、別々にしていると上手くいかない。
  • テストも書くのが仕事ですよと。責任を持ちなさいと言っている。

聴講者

聴講者

  • 同じ人がやっている。
  • どういうレベルであっても、自分で作ったのならば自分でテストをしなさいと。
  • なので、システムテストレベルについてはツールを提供したりしている。

Ina Schieferdeker

聴講者

Jens Krinke

Ina Schieferdeker

  • そんなことはないです。
  • テストマネージャはプロダクトマネージャよりも給料が高いです。責任が重いからです。ただし、学生は実感できませんが。

聴講者

  • 学術界の把握ができて嬉しく思った。
  • ただ、その中で大学を通じて色々な課題がありますが。
  • 大学の中で教授で産業界の経歴がある人は?何%ぐらいがそうなのでしょう?
  • 会場を見る限り半分くらいでしょうか。
  • 私は学生だが、このようなコンセプトについてそのようなクラスを受けたいと思うが、実例を学びたちと思ったとき、ソフトウェアのトピックが無くては学べないと思うが。

聴講者

  • ITに10年いますが、テスト駆動形のプロセスです。
  • このようなことを扱えて、学んだことが扱えてよかった。
  • テストでも色々な階層があるが、フォーカスしているのはどのようなテストタイプですか?ストレステストなどがあるが。

聴講者

  • Microsoftの場合はそれぞれ分かれている。
  • プロセスに関しても。
  • Microsoftの場合、お互いに役割がある。
  • ただ、Murat Ozturkさんに同意するわけでない。
  • 違いがあります。
  • Writerがいて、スケールがあります。
  • 少し大きい場合はテストオートメータの友人を入れる。
  • マシーンラーニングとかもそう。

Shlomo Mark

  • 時間が来てしまいました。最後にどうぞ。

聴講者

  • どのようにテストプロセスを作っているかについては、どちらの方法でも良い。
  • 開発プロセスに注入していくか、うまくいっているのか、カバレッジはきちんとしているか。
  • どこかに穴があってはまずい
  • トータルカバレッジを考える
  • プロセスの問題というよりもアプローチの問題。
  • 私のチームもそう
  • インフラでも楽しむことが重要。
  • 使っているコードはテストを作るときにも使っている。
  • テストの世界でも分かるようにする。

Shlomo Mark

  • 何を教えれば良いのかはペーパーも出てきています。

感想

  • 「テストを大学で学ばせる」ということ自体、日本の大学ではなかなか出来ていないことなので、世界とのギャップを感じた。
  • とはいえ、世界的にも教育について悩んでいるのかなとも感じた。
  • さらに「プログラミング」「テスト」を講義として分ける、テストの講義を後から実施すること自体も否定的な意見が多かったのが印象的でした。

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

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

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

ICST2017のプログラムの日本語訳を書いてみる(本会議2日目) #ICST2017

ICST2017

1つ前の記事*1に引き続き、ICST2017の本会議2日目のプログラムを訳してみました。

英語ムズカシイネ。

9:30~10:30

基調講演

自動運転技術の試験と妥当性要件

11:00~12:30

I02: Industry #2

①進化するソフトウェアシステムを検証するための情報ニーズ

自動車産業における自動モデルベースソフトウェアテストケースのカバレッジ最大化に関する制御実験

自然言語処理に基づくテストケースの優先順位付けに関する産業研究

R10: Automated and Run-time Testing

①リスト上の線形尺度の効率的なインクリメンタルランタイムチェック

②行動の実行の比較:テストはフィールド動作の代表ですか?

③複数の派遣言語での自動ランダムテスト

R04: Regression Testing

①パフォーマンス回帰テストの選択は、簡単で効果的

②統計的に定義された品質レベルのブラックボックス回帰テストの選択法

③自動化されたユニットテストの生成におけるプライベートAPIアクセスと機能モッキング

11:00~17:30 *2

Testing contest #1

コンテストの概要説明

TESTONA(組み合わせテストツール)のバージョンを変化させたときに出てくる失敗をできるだけ見つけてみてください。

14:00~15:30

A01: Special Session - Aerospace IV&V: Why and how we use software testing to trust products #1

NASA IV&Vにおけるソフトウェアテストの利用について

②ヨーロッパの宇宙機関がフライトソフトウェア開発について、ISVV*3をどのように利用しているか

JAXAがIV&Vについてのソフトウェアテストをどのように使用するのか、そしてその必要性について

R05: Web and Mobile Applications

①クロール(巡回)ベースのWebアプリケーションテストにおける類似性について

②プラットフォームに依存しないAndroidテストの記録、エンコーディング、および実行のテクニック

③進化するモバイルアプリケーションのためのGUIテストスクリプトの自動メンテナンス

S02: New Theories and Tools (short papers)

①構造的テスト目的の一般的かつ効果的な仕様

②モデル検査と静的解析を掛け合わせた方法

③統計的オラクル*4に対する確率的シミュレーションをテストするためのツールキット

クラウドでコスト効率の良いテストについて

16:00~17:30

A02: Special Session - Aerospace IV&V: Why and how we use software testing to trust products #2

①ソフトウェアIV&Vにおける統合された*5形式的解析

②航空宇宙IV&Vドメインとテスト技術によるソフトウェアテストのニーズについて(パネルディスカッション形式)

T02: Code Analysis and White Box Testing

①最先端の不変性分析の移転:実験ツールボックスと精度

ドメイン特化言語を通じてテストの自動化を加速させる

③テストカバレッジ基準の異種性の評価

R06: Parallel Systems and Concurrency

①マルチスレッドプログラムの定義参照データフローの自動テスト

②不変である可能性が高いものを用いたマルチスレッドプログラムのエラー伝搬解析

③Contractsを使用した並列プログラムの検証

*1:1日目はこちら nihonbuson.hatenadiary.jp

*2:それぞれの時間帯で移動ができる構成なのかもしれませんが、一応一括りのセッションという形で示しました。

*3:IV&Vという書き方はよく見るけど、ISVVという書き方は初めて見た

*4:ここで書いている"Statistical Oracles"のOraclesはテストオラクルのオラクルと同じ意味合いで使われている?

*5:IV&Vなのに統合?よく分かってない

ICST2017のプログラムの日本語訳を書いてみる(本会議1日目) #ICST2017

ICST2017

来週、IEEEが主催するソフトウェアテストに関する世界最高峰の国際カンファレンスである『ICST』が日本で初めて(アメリカとヨーロッパ以外で初めて)開催されます!

ただ、国際カンファレンスだけあって公式ページが英語です…。

ICST 2017 | Schedule

ということで、本会議1日目の発表タイトルを日本語に訳してみました。

分かるところについては、簡単な参考資料も載せています。

変な訳になっていれば、ご指摘ください!

9:30~10:30

基調講演

Googleによる、テスト自動化とCI

11:00~12:30

I01: Industry #1

①自動運転のセキュリティについて

②言語対応の自動サポートについて

R08: Model-Based Testing I

①記号実行を使用した高カバレッジ生成

②不確実性に基づくブラックボックステストデータの生成

Alloyの自動テスト生成とミューテーションテスト*1

R01: Fault Localization and Injection

SQLにおける局所的な障害について

②単一故障の普及と局所制限障害への影響について

Linux向けのカーネルレベルでの故障注入のフレームワークについて

D01: Introduction of the Tools to be Demonstrated

D02及びD03で行うデモの紹介

14:00~15:30

R02: Debugging, Composite Faults and Complexity Analysis

①デルタデバッグ*2を利用した同時データ構造の最小ストレステスト

②複合的な欠陥について

③文脈の保存履歴を用いた複雑度解析

T01: Model Checking and DSL-based Testing

Androidアプリの脆弱性を自動的に検出して確認するためのツール

②抽象化と有界モデル検査*3を使用した産業規模コードの効率的な安全性証明

③モデル検査ツールの一種「NuSMV」*4フレームワークであるNuSeenについて

R09: Model-Based Testing II

①学習オートマトンを用いたIoTのモデルベーステスト

ApacheのZookeeperにおけるモデルベースのAPIテスト

ユースケースと時間オートマトンを用いたタイミング要件に関するシステムテスト

14:00~17:30

D02-03: Live Demonstrations

①デスクトップアプリに対してのパフォーマンス測定フレームワーク

②インタフェースの契約論に基づくAPIテスト

ドメイン固有言語(DSL)を用いた自動テストの効率化

④Webサイトについてのエンタープライズレベルのテストツール

⑤JCUnitの紹介*5

⑥Load-time Weaving*6を用いたAndroidのRuntime検証

⑦ミューテーションテスト*7のデモ

16:00~17:30

R03: Security Testing

①公開鍵証明書(X.509)のためのテストについて

API間のトレーサビリティの回復とセキュリティ脆弱性について

Linuxコンテナ用のMining Sandboxes

S01: New Methods and Empirical Results (short papers)

①工業用制御ソフトウェアの手動テストと自動テストの比較に関する研究

アサーションカバレッジベースのテストスイートの削減にどのように影響しているか

オートマトンの言語等価性とモデルベースの等価性のシミュレーション

④Mutation Testingの評価と改善

J01: Special Session - Demands and Efforts in Software Engineering and IV&V among Japanese government and a company

①信頼できるIT社会の実現に向けて

②信頼できるシステム開発の体系的アプローチ

③ベリサーブ社のテストプロセス、テスト分析、テスト設計に関する活動

*1:Alloyは言語ではないか」とのことです。ご指摘いただきありがとうございました!

*2:(参考)デルタデバッグ

mag.osdn.jp

*3:(参考)有界モデル検査とか状態爆発問題の話とか

http://logic.cs.tsukuba.ac.jp/~kam/lecture/sysverif2011/hand4.pdf

*4:(参考)NuSMVの話とか

blog.devshinchi.jp

*5:(参考)JCUnitについて

uehaj.hatenablog.com

*6:(参考)Load-time Weaving

紹介スライドの直リンク

*7:(参考)ミューテーションテストを行った発表事例(SQiP2015より。たまたまこの発表を聞いてた)

https://www.juse.jp/sqip/symposium/archive/2015/day2/files/happyou_B4-3.pdf

「GitLab Meetup Tokyo #1」に参加してきました! #gitlabjp

3月2日、GitLab Meetup Tokyo #1に参加してきました。

gitlab-jp.connpass.com

全体的な感想

  • GitLab CIが当たり前のように出てくるなー

  • GitLab.com事件があったからか、バックアップがHOTな話題だなー

  • 結構改善されてるんだなー

という感じ。

各発表内容の紹介

当日中に記事を書いたので、そのリンクを貼っておきます。

GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開

nihonbuson.hatenadiary.jp

  • GitLabがどれだけ活発なコミュニティなのかということがすごい理解できました!

GitLabの実践的な運用

nihonbuson.hatenadiary.jp

  • 生半可な気持ちでMySQLにしない方が良いということが分かりました。
  • バックアップ大切!

GitLabコミュニティへのコントリビュート

nihonbuson.hatenadiary.jp

  • GitLabに限らず、コミュニティへの貢献方法が学べました!

ここがすごいよGitLab CI

nihonbuson.hatenadiary.jp

  • Twitter上と変わらぬ @sue445 さん節炸裂の発表でした。
  • yamlでスッキリ書けるのって本当に良い!
    • 私もその虜になった一人

GitLab LT

nihonbuson.hatenadiary.jp

  • 4名の方々のLTがありました
  • チームでの運用・大規模な場合の運用など、様々な立場の人の発表でバラエティに富んでいました!

第2回開催決定

  • 第1回の開催中に第2回の募集が開始されました!

gitlab-jp.connpass.com

  • もう一般参加枠は埋まってしまったみたいなので、是非、発表者とかスポンサーでの参加を!