やらなイカ？

たぶん、iOS/Androidアプリの開発・テスト関係。

Unity++ 〜ショートセッション勉強会 presented by Unity部〜 #unity_pp に行ってきました

Unity

7/20（土）に開催された『Unity++ 〜ショートセッション勉強会 presented by Unity部〜』に行ってきました。

meetup.unity3d.jp

主催は日本Androidの会Unity部さん*1、会場はGINZA SIXのユニティ・テクノロジーズ・ジャパンさん。 スライドや動画は後日ユニティ・ジャパンさんのUnity Learning Materialsで配信されると思いますので、ごく簡単に。

Democratized Unity Package Manager

speakerdeck.com

  • Unity 2019.1からUnity Package Manager Scoped Registryが使えるようになった
  • Unity Package Managerは2017.2から導入
  • パッケージには4種類ある
    • 公式/verified
    • 公式/preview
    • 公式/built-in
    • 非公式 ← これを扱いやすくなった！ 民主化！
  • Package Name: reverse domain記法
  • Version: semver形式、previewもここで表現
  • Unity Version: 最低ver*2
  • Dependencies: 依存パッケージ
  • Registory: npm仕様
  • Scoped registory
    • package nameのスコープごとにRegistryを切り替えられる((uplinksで上位のレジストリを書くことでカスケードにもできるが、Scopedでのほうが様々な構成に対応できる)) -VerdaccioというOSSで簡単に立てられる
  • Package Manager UIには表示できないのでPackages/manifest.json直書きする
    • Removeはできる
  • Packageを作る
    • Assets/直下にpackage.jsonを置く
    • README.mdとかもAssets/直下に置く
    • asmdef必須
    • Documentation~直下に置くとメタファイルがつくられないのでべんり
    • Test Assembryがコンパイルされないバグ
  • 公開する
    • 認証を通す
    • ROOT/.npmrmにレジストリURLなどを書いておくと便利
    • $ npm publish
  • 詳しくはUNIBOOK 11（C96 4日目 南リ45a）で！
  • upm-packages.dev を立てた*3
  • Command line interface for Unity Package Manager を作った

補足

よーし、パパ Cinemachineを2Dプロジェクトに適応して遊んじゃうぞー

speakerdeck.com

  • プレイヤーにカメラを追従させる処理 → 親子にするなどで実現はできる
  • いい感じにしたい → Cinemachine
  • Unity 2017から、Package Managerでインストール可能
  • 遅延移動、プレイヤーの動きを先読み
  • 特定の範囲から外を見せたくない
    • コライダを設定できる
  • 複数カメラの切り替え、ブレンド
  • 複数ターゲットを収める（拡大縮小して収める）: Target Group
  • カメラシェイク: Impuls Listener
  • ドキュメント充実してる＋テラシュールブログも参考
  • [非公式] Unite Tokyo 2019 Eve2 LT Fes - connpassが8/2募集開始なのでよろしく

アクションゲームにおけるポーズ系演出の難しさと解決法

Preview機能のプレビュー 公式Localizationパッケージの今

Unity開発者が知っておきたい.NETのこと

speakerdeck.com

  • Scripting Backend
    • .NET 4.xが使える
  • Compatibility
    • .NET 4.x: dll大きい。動かないAPIもある
    • .NET Standard 2.0: dll小さい
  • .NET実装: ランタイム＋クラスライブラリ
  • .NET Standard: 仕様・規格

Unity サウンドTips 2019

www.slideshare.net

  • 基礎的なことは 【Unite Tokyo 2018】Audio機能の基礎と実装テクニック 参照
  • Unityはサウンドエフェクトがややムズ
  • Audio Mixer とっつきにくいけど優秀
  • VR特有
    • 指向性：位置情報、直接音：パンニング、初期反射、
    • 360度から聞こえる音：ambisonics
  • VRサウンドSDK多すぎ問題：Oculus Audio SDKがほぼ正解
  • 罠: OculusSpatializerUnityコンポーネント
    • 単位がフィート
  • 処理はそれなりに重い。無理に使わなくてもパンニング＋距離減衰だけでいいことも
  • CRI ADX2
    • 法人向け有償版、個人開発者向けLE
  • Audio DSP Graph
    • previewですらない。Megacityデモからコード抜いて調べた
    • 2-3年先では

書籍が8/27に発売されます

Unityサウンド エキスパート養成講座

Unityサウンド エキスパート養成講座

UniTask入門

speakerdeck.com

  • コルーチンの置き換え、戻り値を返せる
  • C#のTaskより軽い
  • UniRxよりはわかりやすい
  • C# 7以降
  • 生成
    • asyncの戻り
      • async UniTaskVoid: async voidの代わりに使える
    • UniTaskCompletionSource
    • (UniRxの）Observableから変換する
      • 必ず完了するObservableであること
      • ToObservableするとメインスレッドで動く
  • UniTask.Run, UniTask.Delayとか
  • UniTask.WhenAll: 型が違っても待てる
  • WhenAny: どれかひとつ終わったら抜ける
  • Awaiter
    • GetAwaiter()が生えてればawaitできる。拡張メソッドでもok
    • UniTaskはいろいろ提供している
  • UniTask.ToCoroutineでコルーチンに変換できる
  • SceneManager.LoadSceneAsync()とかを待てる
  • progressも取れる
  • OnCollisionEnterとかも
  • コルーチンの上位互換として使える
  • UniTask Tracker
  • UniTaskとキャンセル
    • CancellationToken
      • GetCancellationOnDestroy() べんり
    • OperationCanceledException: 投げるとUniTaskは「キャンセル状態」になる
      • エラーログには出ない
      • 外部からキャンセル要求があったとき
      • 下流で投げたら上までスルーして伝えること
      • 悪用しないこと
  • 標準Taskは必要がなければ使わないでok
  • Observable: イベント処理、結果が複数になるなら使う

カシスちゃんのグッズ発売中

所感

Unityはできることが多く、普段触らない分野の知識はなかなか入ってこないので、Gotanda.unity、Roppongi.unityのようなLT、また今回のようなショートセッション形式で色々聞ける勉強会というのはとてもありがたいです。

似たようなインプットとしては、Unity Pro Tipsのメールマガジンもいいですね。ちょうど先日Cinemachineの記事を読んで興味を持っていたところでした。

いつもながら、企画・運営、そして登壇者のみなさんには感謝。

*1:当時、雨後の筍のようにたくさんあった「部」の数少ない生き残り。テスト部とか酒部とかVR部とかありました

*2:休憩のとき聞きましたが、rangeでは指定できないそうです

*3:ちょうど個人的に、ローカルにVerdaccio立ててもUnity Cloud Buildから使えないしなーと考えていたところだったので、使わせてもらおうかと

GitKraken v6.0リリースとIndividual料金プランの新設

Git GitKraken

マスコットキャラクターがたいへんかわいいと評判のGitクライアント"GitKraken"のバージョン6.0がリリースされました！

youtu.be

とりあえず触ってみたい！ という方は、ぜひ下のリンクからサインアップして試してみてください。

www.gitkraken.com

主な変更点

爆速

起動やリポジトリを開くスピードがとても早くなりました。

起動時のたいへんかわいいアニメーションはいつまで見ていても飽きないのですが、それでも素早く作業に取り掛かれるほうが良いですね。

タブ

画面上部にタブが付き、複数のリポジトリを開いた状態で保持できるようになりました。

従来通りプルダウンでの切り替え操作もできますが、タブのほうが便利。

マージコンフリクト警告

PRをつくるときにマージ先とのコンフリクトを検出したら警告してくれるようになりました。

Individualプランの新設

これまで、Freeプランと$49/yのProプランの二択でしたが、$29/yのIndividualプランが新設されました！

Individualプランでは、従来Proでのみ可能だった以下の機能を使えます。

なお、複数プロファイル切り替え、GitHub Enterpriseの利用などは、これまで通りProプランが必要です。

免責事項

私はGitKraken Ambassadorであり、GitKraken開発元のAxosoft社の従業員ではありません。

I am a GitKraken Ambassador, not a paid employee of GitKraken by Axosoft.

GitKraken Ambassadorになりました

Git GitKraken

マスコットキャラクターがたいへんかわいいと評判のGitクライアント"GitKraken"のアンバサダーになりました！

今後、当ブログでGitKrakenの（かわいいだけじゃない）機能紹介などを行なっていくとともに、近い内に都内でmeetupなどを開催できればと画策しています。

f:id:nowsprinting:20190426005455p:plain

※以下、当初の原稿が「たいへんかわいい」で埋め尽くされてしまっていたため、大幅にリライトしたものでお送りします。

GitKrakenとは

GitKrakenは、Axosoft社が開発・提供しているGitクライアントです。オープンソースプロジェクトでの利用など、商用でなければ基本機能は無料で使用できます。 またGitクライアントだけでなく、Glo Boardsというカンバン機能も備えています。

とりあえず触ってみたい、という方は、ぜひ下のリンクからサインアップして試してみてください。

www.gitkraken.com

Nintendo Switchがもらえたりもらえなかったりするようです。なにより、meetupを開催するときに送ってもらえるノベルティが豪華になりますので、ぜひこのリンクをご利用ください。

GitKraken Pro

GitKraken Freeでも、その美しいGUIは使用できますし、そもそも他に無料のGitクライアントはいくつもあります。しかし、個人的にGitKrakenをおすすめする最大の*1ポイントは、$4.08/moのProプラン以上で使用できる"Merge conflict editor"です。

Merge conflict editorについては、次の動画の1分20秒あたりから見ると*2その便利さがわかっていただけるのではないでしょうか。

youtu.be

またProでは、個人のGitHub.comのアカウントと、会社で使っているGitHub Enterpriseアカウント、もしくはGitLabやBitbucketなどのアカウントを切り替えて使いたい方のための"Multiple profiles"機能も使うことができます。

なお、GitHubにおける複数アカウント利用は利用規約違反では、という話（全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG）ですのでご注意ください。

GitKraken Proは有料プランですが、7日間のトライアルがあります。ぜひ一度お試しください。

Glo Boards

いわゆるカンバンです。GitHub Projectsなどより高機能で、カレンダー・ビューなどもあります。 こちらも、オープンソースプロジェクトでの利用など、商用開発でなければ基本機能は無料で使用できます。

下はバージョン5における新機能紹介動画ですが、Glo Boardsがどのようなものかわかりやすいはず。

youtu.be

こんな方におすすめ

初心者から上級者まで！ と言いたいところなのですが、初心者しかも日本人には英語の壁があるのも確かです。 しかし、先々、複雑な操作をするようになる頃にはCLIに行き着きますし、GUIは慣れるものです。 どうせ使うならキレイなGUIを使いたいという方、ぜひGitKrakenを使ってみてください。

GitおよびGitHub自体に慣れていないという方には、まずはこちらの書籍をおすすめします。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

また、マージ、リベース、それに伴うコンフリクトの解消がとても強力なクライアントですので、多数のブランチが並列していたり、個々のブランチの寿命が長かったりというつらみの深いプロジェクトに携わっている方は、ぜひぜひGitKraken Proのフリートライアルを試していただきたいです。

まあそもそも、そんなプロジェクト（以下略

免責事項

私はGitKraken Ambassadorであり、GitKraken開発元のAxosoft社の従業員ではありません。

I am a GitKraken Ambassador, not a paid employee of GitKraken by Axosoft.

*1:これは「たいへんかわいい」を差し置いて、最大です。次点で「アイコンがたいへんかわいい」「スプラッシュ画面のアニメーションがたいへんかわいい」などと続きます

*2:埋め込みだと再生開始指定が効かないみたいなので

定職につきました

Testing

いわゆる転職エントリです。 長らくフリーランス開発者としてやってきましたが、4月から株式会社ディー・エヌ・エー（以下DeNA）のSWETグループ所属となりました。

副業可・裁量労働でもありますので、自分の会社も副業として細々と存続します。その副業の関係でここ2ヶ月はアルバイト扱いで仕事していたのですが、とても仕事しやすい環境です。

フリーランスから会社員という変化、開発者からテスト系というロールの変化を同時に決めたわけで、そのあたり少し書き残しておきます。

DeNA

お誘いを受けたときの最初の印象は「『電エース*1』みたいな名前の会社だ」というくらいで*2、正直なところ会社員というものが選択肢として考えられていなかった状態でした。

が、なにせ過去に会社員だった記憶は20年前のメーカー系だったわけで、時間をもらって考えるに並の案件よりよほど自由もあるし*3、DeNAであれば色々な領域の技術を扱えるのでは、というあたりに惹かれた感じです。

とは言え、ろくに転職活動などしてこなかったので広く他社と比較したりということもせず（できず）、ネガティブな要因に背中を押されたところもあります*4。

SWET

GoogleなどでいうSET (Software Engineer in Test)、MicrosoftでいうSDET (Software Development Engineer In Test)にあたり、狭義には開発チームのテスト自動化を支援したり、CI/CDなどのインフラを整えたり、というロールです。

自分のコミュニティ活動、著書もまさにこのあたりの領域なので、チョットデキルと言えるところ。

しかし、先日のJaSST'19 TokyoでのYahoo! JAPAN山口さんの話のように、開発チームが自力でテストを書けるようになれば不要になるはずのロールであり、現にGoogleではインフラ色の濃いSETI (Software Engineer, Tools & Infrastructure)に名称も変わり、MicrosoftのSDETはなくなっているそうです。

ソースはこのあたり。

この点は最初の面談でまず聞いたところでなのですが、DeNAでは狭義のSETのロールだけでなく、形式手法や機械学習との連携などR&D的な活動も進めているという話であったり*5、AI for Testingとかゲームとかのテスト技術を個人で追うことに限界を感じていたところもあったので、もう片手間でなくこちらに舵を切ってしまおうか、と決断したのです。

フリーランスについて

フリーランスという働き方については、勧めもしないし止めもしないです。20年前と今とは違うし、どちらが良いとも悪いとも言えないです。DeNAの居心地は今のところとても良い*6ですが、まだ2ヶ月なのでいつ手のひらを返すかわかりませんし。

個人的には、本業で開発、コミュニティ活動でテスト自動化と活動を分けた挙げ句、本業側でろくなポートフォリオを残せていないというバカなことをやってきたわけで、後進には反面教師以外の何も残せないのは申し訳ないです。

最後に参考までに、会社が副業可であっても年金事務所の手続きとかめんどくさくて、日本社会がまだまだなんだなという感想。なにせ絶賛手続き途中なので落ち着いたらエントリ書くかも知れません。 あと雇用保険が7年で失効するとか。

参考資料

テストから見えてくる グーグルのソフトウェア開発

テストから見えてくる グーグルのソフトウェア開発

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

バカ映画一直線!: 河崎実監督のすばらしき世界

バカ映画一直線!: 河崎実監督のすばらしき世界

電エースBOX 河崎実監督作品 [DVD]

電エースBOX 河崎実監督作品 [DVD]

電エースQuiz - 河崎実監督と特撮映画の世界

電エースQuiz - 河崎実監督と特撮映画の世界

  • HUB Systems, Inc.
  • エンターテインメント
  • ¥600

*1:平成元年、バンダイのビデオマガジン『電影帝国』内の1コーナーとしてはじまった特撮作品のシリーズで、30年続いている河崎実監督のライフワーク。気持ちが良くなると変身するヒーロー、電エースの活躍が描かれている。近年はクラウドファンディングで出資者を出演させるという商法が展開されている

*2:実は数年前DeNAセミナールームで登壇したときネタに使ったのですが、盛大に滑りました

*3:フリーだとなかなか案件から抜けられないこともあり、逆にDeNAでは社内での異動がしやすい制度が整っていたりします

*4:最近フリーランスが流行りっぽいけど余り良い案件流れてないとか、35歳定年説については諸説ありますが個人的には内部品質の低いコードの読み書きはつらくなってきたとか、営業めんどくさくなってきたとか

*5:日付は前後しますが https://speakerdeck.com/orgachem/story-of-a-swet-engineer

*6:ぬるいわけではないです。みんな頭良くてついていくだけでも大変

Unity 2018のUnity Test Runner

Unity Testing

ようやく重い腰を上げて手元のUnity 2017.4プロジェクトを2018.3に移行したので*1、何番煎じかわからないけどテスト(Unit tests)まわりについてまとめ。

Test Runnerウィンドウ

2017ではメニューのWindow直下にあった"Test Runner"ですが、Window > General > Test Runnerに移動されました。

Edit mode Tests

2017.4までは、EditModeで実行するテストコードはAssets/**/Editor/**/下にあればよかったのですが、2018では条件が増えています。

例えばAssets/Xxx/Editor/のようなフォルダ階層でXxx下にAssembly Definition（以下asmdef）ファイルを置いてしまうと、Editorまで同じアセンブリに含まれてしまいます。

Xxx/Editor下にEdit mode Testsがある場合はXxx/Editor直下にもうひとつadmdefファイルを作り*2、"Test Assemblies"と"Editor"の2つのチェックボックスをonにする必要があります。

f:id:nowsprinting:20190402003537p:plain

なお、Edit modeでは[UnityTest]属性をつけたテストはEditorApplication.updateコールバックループで実行されるという点は2017も2018も同様です。

Play mode Tests

2017ではPlay modeでテストを実行するには”Enable playmode tests”をクリックしてから再起動する手順が必要でしたが、2018では不要になっています。

代わりに、テストコードは任意のフォルダ下に置き、そこにadmdefファイルを作り、"Test Assemblies"チェックボックスをonにする必要があります。

f:id:nowsprinting:20190402003606p:plain

なお、Play modeでは[UnityTest]属性をつけたテストはコルーチンで実行されるという点は2017も2018も同様です。

Enable playmode tests for all assemblies

もし、Play modeのテストコードを容易に移動できない、asmdefによってアセンブリを分けることが困難といった場合、Test Runnerウィンドウ右上のハンバーガーメニューから"Enable playmode tests for all assemblies"をクリックして有効にすることで、Unity 2017のようにモードを切り替えてPlay mode Testsを実行することができるようです（未確認）。

f:id:nowsprinting:20190402003321p:plain

ただし、このままではビルドに追加のアセンブリが含まれるため、プロジェクトのサイズとビルド時間が長くなってしまいますので、ビルドを行なうときにはDisableに戻すべきです。

アセンブリの依存関係

Assembly Definitionファイル（以下asmdef）はUnity 2017.3から導入された機能で、アセンブリを小分けすることでプロジェクトのビルド時間を節約する効果があります。

Unity 2018からはテストコードは専用のアセンブリ（"Test Assemblies"チェックボックスをonにしたもの）に属する必要が生じたため、テストコードのasmdefからSUT（system under test: テスト対象）ほか使用しているasmdefを参照する旨を"Assembly Definition References"に設定する必要があります。

下図はSUTである"SUTClient"と、"UniRx"に依存している例です。

f:id:nowsprinting:20190402021134p:plain

Internalの扱い

C#では、Internalアクセス修飾子をつけたclass/methodは同一アセンブリ内からのみ参照できます。Unity 2018でテストコードが別アセンブリになったことによって、そのままではInternalなclass/methodのテストを書くことができません*3。

これに対し、参照される側（SUT）の中に以下のコードを書くことで、指定したアセンブリに対してInternalなclass/methodを公開することができます。

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("Assembly-CSharp-Editor")]
[assembly: InternalsVisibleTo("SampleTestsAssembly")]

""の中には、公開するアセンブリ（この文脈上はテストコードのアセンブリ）名を書きます。"Assembly-CSharp-Editor"はUnityエディタです。

なお、このコードはアセンブリ内のどのファイルに書いても良いようなのですが、過去の経緯から"AssemblyInfo.cs"というファイルに書くことが多い？ ようです。

おまけのTips

*1:2017.4から2018.3に上げたので、差分は2018.1か2か3のどこで入ったものかまでは確認していません

*2:右クリック > Create > Assembly Definition

*3:Unity 2017以前でも、Edit modeのテストコードはAssembly-CSharp-Editorというアセンブリに入るため、Internalなclass/methodのテストはそのままテストできませんでした

JaSST'19 Tokyo 聴講メモ（主にAI x Testing関係） #JaSST19Tokyo #JaSST

Testing AI

ほぼ毎年恒例、JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyoに行ってきました。今年はAI x Testing（AI for TestingとTesting AI）の話多め。

以下、聴講したセッションのメモ。

AI-Driven Testing: A New Era of Test Automation

Ultimate SoftwareのTariq King氏による基調講演。

  • Automationとは、独立してできること。テスト実行を自動化しても確認がマニュアルでは当の自動化ではない。AIで完全な自動化を目指す
  • AIST(AI for software testing)は以下を含む分野と定義
    • AI driven testing
    • testing AI systems
    • self-testing systems
  • コミュニティが必要なので作った -> AI for Software Testing Association
  • 今日はAI driven testingにフォーカス
  • testingに使う
    • input:d -> program(function) -> output:f(d)
    • f(d)は受け入れ可能か？
    • 機械学習のモデルも似ている
    • domain:dx -> program -> range:OK(d1),OK(d2),,,
  • 機能を追加するとcomplexityは増えていく
    • coverageも上げるけど追いつかない -> カバレジギャップ
    • 解決したい
  • AI driven testing: a new era of test automation
  • 『不思議の国のアリス』を解析して再生成する試み
    • AI driven test generation
    • abstract testの記述言語を作った
      • if "first name"が出てきたら
      • when 空有白を入れてsubmit
      • then エラーが出る
    • トレーニングデータ不要
  • 限界はある。次に何をするのかわかってない。信頼できるか？
  • self testingし続けないといけない。リアルタイムで

Q&A

AIによるテスト結果を信用できるのか

  • いくつか取り組みがある
  • それでも100%納得されないかもしれないが、それでも今よりまし。マニュアルでもバグはある。100%でない
  • 100%でなくても、数値化・定量化できるのは利点
  • ミッションクリティカルなところには適用できないかも。人間の支援として使うとか。それでも、なにもしないより、AIを使うほうがはるかにいいはず

large volume output

  • "Pterodactyl"というプロダクトに最初に取り組んだ
  • ダッシュボード、複数の問題を集約したりできる

usability testingはできるのか

  • 事例さえあれば。このボタンがわかりにくい、このデザインは見づらい、みたいな事例を学習させることで可能
  • applitools.comでVisual Testingをやっている

Agentにやってはいけない動作を指定できる？　より探索的にすることはできる？

  • ふたつのゴールを同時に達成するのは難しい
  • なにもないと、すべてのリンクを見つけてクリクしてしまうので、スコープを制限する機能はある
  • アクションを制限することもできる。コンフィグレーションを作る必要はある
  • スコーピングする機能は必須

仕様とか検証内容をどう教える（定義する）のか

  • ソフトウエアが予想どおりの動きをするかの予想。ドメインナレッジ。人間の脳の中にある
  • システムに、ある特定の分野のドメイン知識を入れる必要がある。専門家がトレーニングする
  • まだ時間がかかるが、構築する必要がある
  • amazonとかgooogle mapから「これ正しい？」という質問が来る。これはトレーニングに使われている

学習モデルは汎用的？

  • まだ教育ツールの段階。これにトレーニングしてテストに使う。まだ汎用的ではない
  • App Storeのアプリでトレーニングしている人はいる（test.aiのこと？）
  • 汎用的なものは目指したいが、モバイルとデスクトップはまた違う

UIのテストのみ？

  • input/outputがあればできる

将来像について。汎用化は全体なのか、ドメインごとに特化したのを組み合わせるほうか

  • model driven engineeringをやってきた。結果、general solutionでは問題は解けない
  • トレーニングは（そのドメインの）コミュニティでやらなければならない

self healingなどいつごろ実用化されそうか

  • いつ？というのは、コミュニティ次第

テストの未来、品質の未来　～自動化はテスター撲滅の夢を見るか？～

speakerdeck.com

各社でテスト自動化に取り組んでいる方々によるパネル。まず体制とロールについて。

  • 山口さん＠Yahoo!
    • Devのチームで品質も見る。QAというロールもプロセスも存在しない
    • 支援の横断的チームはある
  • 大園さん＠LINE福岡
    • 横断的チーム：テスト自動化、SET、QAがある（わかれている）
  • 木住野さん＠LIFULL
    • 横断的チーム：SET, QA
    • SET（QAから分離）：リリース前E2E自動テストと、依頼があれば自動化支援
  • 根本さん＠メルカリ
    • SET -> Automation&QAグループ(AQA)
    • 各プロジェクトにQAが入っている
    • 横断的チーム：AQA, iOS Dev, Frontend Dev, Backend Dev
  • 松尾さん＠今回はクックパッドの話ベース
    • 各プロジェクトにQAが入っている
    • 横断的チーム：モバイル基盤グループ(QIT)

アンケート結果について

  • テスト自動化への期待と結果
    • 素早いフィードバックが期待も結果も多い
    • コスト削減は期待にはあるけど結果にはない
  • テスト自動化の課題と対策
    • フレーキー
    • 不安定なテストを書くのは後回し、価値の出るところから優先
  • 自動化チームがいない、立ち上げが難しい、人がいない
    • Yahoo!の規模（Devが3,000人）になると、Devがみんなテストできるようにならないといけない
  • なにを対象とするか、どのテストを自動化するか、準備や計画ができていない
  • 手動テストを自動化しようとしてしまう
  • テスターがスクリプト書けない
  • 自動化チームがマネジメント層やテスター他の関係者から十分なサポートを得られない

自動化はテスター撲滅の夢を見るか

  • 自動化チームは必要か
    • 必要：技術のキャッチアップとか手がまわらないので必要
    • 不要：開発チームがやるのが適切なはず
  • QAは必要か
    • サービスによる：Webだと手厚くQAするより、手早くfix&releaseするほうがいい。組み込みとかだとQAは必要
  • テスターは必要か
    • 不要 → 部分的に置き換わる
    • 仕事内容が変わる：多様化

Agile, DevOpsがあたりまえの時代に求められる人材とは

  • プログラマが出せない価値を出せる人（山口さん）
  • 誰もやっていないことに果敢にチャレンジする人（大園さん）
  • 技術スキルを持ち、継続的な改善を推進する人（木住野さん）
  • 越境する人（根本さん）
  • 学びを続けられる人（松尾さん）

まとめ

  • テスターの仕事は自動化によっておきかわるか
  • すくなくとも、"置き換わらない"は0%

Q&A

未来への投資と目の前の仕事とのバランスについて

  • 会社が挑戦していい風潮だった（大園さん）

所感

  • 個人的にもYahoo!さんの体制が理想だと思っているので、大手の話だからで終わらせず、そこを目指していくべきだと思う
  • 自動化チームは必要かのところ等、自動化チームのロールが曖昧なところがあった気がする*1ので、ややはっきりしない点はあった

他のブログ記事

nihonbuson.hatenadiary.jp

AI-based static analysis for clean code

Gammaの紹介

www.mygamma.io

  • ルールベースのstatic analysisは役に立つが、限界もある
  • コミットログを学習してレコメンドするエンジン
  • すばやくフィードバック
  • サジェストはIDEプラグインを提供（今はEclipseのみ？）
  • 学習モデルはインクリメンタルに更新可能
  • 学習モデルは3段階
  • オープンソースリポジトリでの利用なら無料で使える

AIプロダクトに対する品質保証の基本的考え方

スライド(pdf): http://qa4ai.jp/QA4AI.JaSST-Tokyo.20190327.pdf

  • 機械学習を使用したシステム
  • QA4AIコンソーシアム
  • 5つの軸
    • Data Integrity
    • Model Robustness
    • System Quality
    • Process Agility
    • Customer Expectation: 良くも悪くも、顧客の期待
      • 合理的説明・原因・責任を求めるような客。悪い意味で期待値が高いということ
      • 期待値コントロール：低く保ちたい
    • バランス
      • レーダーチャートは5軸でもいいし、Customer Expectationを除いた4軸でもいい
      • 数値化は任意なので感覚的なものになる？
  • プロセス
  • テスト
    • ニューロンカバレジという試みもある
    • メタモルフィックテスティング：今のところ名前がついてる有効なテスト方法はこれだけ？
    • GANでエラーを探す：GANをQA側で組まなければならない
  • 品質の保証とはなにか、をもう一度考え直す必要がある

Q&A

Process Agilityがあったが、なぜアジリティなのか

  • 不確実性に対処するためにサイクルをまわす
  • 機械学習は、規則性があるかすらわからないので
  • Process Qualityでなく、あえてAgility

説明可能性

  • 間違えたら、なぜ間違ったのか。狼とシベリアンハスキーを見分けるモデルで、実は背景の雪を見て判断していた話
  • 全部説明する必要はないけど、ドメインによっては（銀行のローン審査とか）は、理由が説明されなければならない

System Quality

  • AIの寄与度を抑えられているか、という項目はなぜ？
  • 不確実性は持っているので、それを抑えられているか、という話
  • 守るべきものは、仕様書に書かれる

確率的なので、外れたものを人間が即異常値と判断していいのか。学習途中では許容できたりしないか？

  • メモできておらず

ルールベースと機械学習の比率は、ドメインによって違う？　議論はされている？

  • それはネクストステップ。今はまだコンソーシアムとしてはやってない
  • 個人的には、そもそもルールベースでは解決できないことをやってるものもある。自動運転とか。なので、都合よくルールベースというわけにはいかないと思う（石川先生）
  • かならずしも同じものを実現するとは限らない
  • 例外、制約、セーフティネットはルールベースになっていきそう

ゲームのテスト：三銃士モデルを適応してみた！ -Next Generation 次世代の挑戦-

三銃士モデル

  • 世界観、コンテキスト、実装。中心にユーザ感情
  • テスト観点を構造化する。マインドマップ
  • 観点の中に「環境」がある。機種とかOSバージョンとかはここ
  • ジャンルによっても異なる
  • 単一観点から入って複合に進む

ゲーム業界の○○テスト！？＠KLabさん

  • ISO-29119-10 Games Testing（2019/4執筆完了予定？）
  • そもそも、ゲームのテストタイプにはなにがあるのか、研究会で考えてみた話

三銃士モデルを現場適用してみた＠アカツキさん

  • フリーデバッグ（探索的テストみたいなもの。各社で定義は違う）
  • 前倒して実施するようにした。リリース延期とかになるので
  • バグ摘出できるのはベテラン。人数を増やしても無駄だった
    • そもそも、テスト手順があいまい、組み合わせ条件が甘いなどが問題
    • マインドマップで整理してテスト項目にフィードバックすることで事前摘出できるように

UX／マイクロサービスアーキテクチャー時代の自動テスト戦略

  • テストピラミッドのIntegration Tests以下をフロントエンドとバックエンドに分ける話
  • ファクトベースで振り返り
  • 品質はチームで守る意識が芽生えた
    • テスト設計、実装、レビューまでやることで意識が芽生える
    • 自分たちでテストレベルやテスト密度・手法について考えるようになった
  • APIテストは、要件定義からテストチームが入っていた

所感

  • そもそもE2Eテストでないならフロントとバックを分けてテストしているものだと思うので、主張はよくわからなかった
  • 振り返り、開発チームがテストを書き、品質に関する意識が上がったという話はとてもよかった

人工知能は何ができて何ができないのか

はこだて未来大学の松原先生による招待講演。

  • AIに明確な定義はない（そもそも"知能"が定義できてない。知能を定義することが目標？）
  • 個人的には鉄腕アトムを作りたい
  • ヒューリスティック。いいかげんなIT。アルゴリズムで100%うまくいくようになった分野はAIから"卒業"するので、AIはあいまいな状態が続く
  • AIは今、3回めのブーム
  • 将棋・囲碁も40年前は絶対無理と言われていた
  • エキスパートシステム
    • スコアはそこそこ出たけど、ときどきとんでもない間違いをする
    • ナレッジを持っている人の、無意識・暗黙知は反映できない
  • 創造性はコンピュータにも持てる。将棋、機械学習
    • 学習データのマネだけでない新手を指した
  • プロの寄付から学習→教師を超える→AI同士で対局して強化学習→強くなったけど、ブラックボックスで人間は理解できない。解説できない
  • 俳句。生成できるけど、良し悪しを選んだりできない。まだ評価できない
    • 将棋などのゲームは評価基準が明確で、その点はやりやすい
  • 100m競争で機械にまけても悔しくない。体力で負けることは経験がある（動物にも負けてる）。でも将棋で負けると悔しい
  • AIの社会実装の試みの例
    • 公共交通を持続可能にしたい
    • リアルタイム乗り合いサービスを提供。SAVS(smart access vehicle service)と呼んでいる
    • 技術の中心はエージェントシステム
  • 18-19世紀、肉体労働が機械に置き換わっていった。ラッダイト運動
  • 21世紀、ネオ・ラッダイト
    • 一部の頭脳労働（とみなされていた仕事）にすでに影響が出ている
  • 人間とAIのこれから
    • 人間とAIで役割を分担する
    • 人間＋人工知能として賢くなっていく（人間の概念が拡張されていく）
    • 賢くなったAIを人間が受け入れるにはある程度の「とき」が必要と思われる -AIもテストしてもらえる時代になった、という感想

所感

  • "一部の頭脳労働（とみなされていた仕事）"という表現が好き。AI以前にITで減らせるはずの仕事はあったので
  • "AIに明確な定義はない"ということなので、キズナアイちゃん親分も間違いなくAI

キズナアイ 1st写真集 AI

キズナアイ 1st写真集 AI

人工知能の未来 ～その未来をどうテストし、どうテストに活用するのか～

ヒューリスティックを前提とすると、品質は？ 品質とはどう定義するのか

  • 正解率の話なら、正解率でいい。正解のラインが決まっているのなら
  • 正解がなにかがわからない分野にAIが使われているし、その評価が難しい。点数をつける基準をつけたり、人の感性でチェックする

システムの一部にAI

  • AIは、作ってみるまで価値はわからない。前例がないと特に。データに規則性がちゃんとあるのか、それを特徴点として取り出せるかわからないので
  • 文化が違う、試行錯誤、研究に近い開発

AIをAIでテストするとき、指針がほしいのでは。くれって言われない？ > Tariq

  • オフラインでのバリデーションでは十分ではなくなるかも
  • トレーニングによってその環境に適応していくことがある
  • 基準を設けることはできるが、変化が起き続けるので本番環境でモニタリングし続け、評価し続ける必要があるのでは
    • 推論するだけでない
  • 未解決である。エンジニアリングの手法を再検討する必要がある。古いやり方はできないと理解する
  • AI, ML,それぞれの手法の違いを明確に理解する
  • cross validation
  • AI, MLをまず明確に理解するのが第一歩

本番環境でモニタリングするという話はある？

  • 公式には聞かないけど、各所でやりはじめてはいるはず。結果が出てからでないと公式に言わないので

学習過程、explainable

  • 規則性を学ぶ、言語化できないルールを見つける
  • 狼とシベリアンハスキーの雪背景の話。なぜその判断をしたかがわかるか → explainability（説明可能性）
    • 本当に必要か？ なくてもいいのでは？
    • 天気予報、天気図が出てるけど、あれ出ないと納得しない？ 本当に見てる？
  • 将棋の解説者、説明する相手（弱い相手）にわかるように説明する。自分の思考ではなく相手に向けて再構成している
    • 抽象化がいい説明なのかどうか
    • 説明とはなにか、わかった気にさせること？
  • 相手によって説明のしかたは変える。人間はAIの思考は理解できていない。複雑なので＋その分野の知識がない。→たとえ説明してもらても理解できない
  • 機械に対して期待が高すぎる。人間でも適当なことを言う（うまくいくんじゃない？等）が、AIにその答えはゆるされない？
  • 説明しなくてはならないシステムをどう作るのか。必要なら作らないと。いらないなら作らなくていい
  • 科学でなく哲学の話
  • 人間には思い込み、概念がある
  • データの網羅性が少ない問題にはexplainableのアプローチは有効なのでは？
    • 自動運転で、雪の日、霧の日、とかをあらかじめリストアップする必要があるという話になってしまう。でもそれは大変。社会的な話
    • 必要になってからデータ追加・再学習できる体制を作るほうがいいアプローチなのでは
  • Mutation testingなど、既存のテストソリューションがAIのテストに応用できるものもあるのでは？
  • 人間のように、環境の変化にすばやく適応できるマシンを作るほうを目指したい

過学習

  • 防ぐことはできてないけど、知識として持てるようになったので気をつけられるようにはなった
  • 過学習では精度が上がったように見えてしまうので、テストのやり方を考える必要がある

データの話。品質保証の範疇？

  • データ（セット）の情報、バージョン管理などはこれから整えていく必要がありそう
  • proverance、それは確かに誰々が描いたものとか、ワインの出処や経路を保証する
  • データを自動収集しはじめる、差別用語を覚えてしまうとか。信用できないソースに対して検査するノウハウ・手法も確立すべき
  • セキュリティも問題。攻撃される

Q&A

エコシステムは作れないのか。QAがブリーディングする？

  • QAはブリーディングする役割にわまらないと、テストとか評価とかの役割ではいらなくなりそう。ダメ出しするだけの人はいらない
  • サイクルはいる。クオリティを一番に考えてる人に与えるべき役割は、プロジェクトの進行に対してガイダンスを示してくれる人
  • 顧客のニーズを満たせているかが重要
  • テクノロジーを恐れる人、仕事を奪われることを恐れる人がいる。でも、やり方が改善されるだけである。Uber, Cell Phoneとか

データ*2を共有できる？

  • ナレッジは共有すべきだが、データの共有は気をつけるべき。セキュリティや、データにバイアスがかかるという問題があるので、簡単にはできない
  • ツールを作っていく。セキュリティなどの問題を解決するツール
  • 訓練データは資産なので、オープンにしにくい
  • モデル盗難: AIの動きを外から見て、似たモデルを作ってしまう手法。これに対し、透かしを入れられないかという動きもある

テストデータの数

  • 同値クラスの概念がないので絞れない
  • モデルに着目してテストしていかなければならない

*1:スクリプトを書く人であったり、支援する人であったり。SETのロールも各社で違っていたりするので仕方ないのですが

*2:明確に言われなかったが、学習データの話であり、学習済みモデルの話ではなさそう。モデルの話も出てきたので少し曖昧？

第1回AI4SEセミナーに行ってきました #AI4SE

Testing AI

昨年の12/14に開催された第1回AI4SEセミナーの聴講メモを下書きのまま放置してしまっていたので、今更ながら。

ai4se.connpass.com

TOC:

AIによるテスト・デバッグ技術 イントロ＆チュートリアル

www.slideshare.net

  • AI4SEで扱うのは広義の「AI」
  • 自動でなにかすごいことをしてくれる楽しい技術・進んだ技術を
  • 機械学習工学やAI工学は、SE4ML、SE4AI
  • AI4SEといえば、リポジトリマイニング(MSR: Software Repository Mining)
    • ここ10年
  • 今回はSearch based SE/Testing/etc..
    • これもこの10年くらい
    • Facebookのあれ
    • Optimization based Falsification
  • データでなく論理ベースも？
    • Concolic testing
    • 静的解析
    • 例: www.rise4fun.com/
  • 進化計算：最適化の一手法
  • 強化学習
  • サーチベースドテスティング
    • 進化計算でテストケース、テストスイートを生成する
    • 自動運転車で、衝突させるようなケースを作る
    • 評価：カバレジ、テスト数、とか
    • 2018年のJava Unit Testing Competition
      • カバレジ、ミューテーションスコア（人工バグの摘出数）、テストケース数で評価
    • FacebookのSapienz
      • 指標：カバレジ、テスト長、検出バグ数
      • バグ修正も連携(SapFix)
      • 多目的最適化を使っているので、複数のテストスイートのパレートフロントが生成される
      • 意味がありそうなイベント列、リバースエンジニアリングで得た文字列
  • 自動修正
    • プログラムいろいろいじってみて、テストが全部通ったら「修正（案）」
    • テストスイートがしっかりしていることが当然の条件
    • 人の頭の「暗黙の期待」だと無理
    • 例：ミューテーションベース。">"を">="に修正して、テストが落ちるかを評価
    • 自然に近いバグの入れかた
  • 反例探索 (Falsification)
    • モデル検査

バグ自動修正ツールって本当に使えるの？ ～自動デバッグ技術の現状と課題～

www.slideshare.net

  • 2003年：7兆円
  • 2013年：34兆円
  • 開発者は時間の50%をバグの局所化と修正に費やしている、というデータ
    • バグのfixまで：平均6ヶ月
  • 局所化
  • パッチ生成
    • 変更タイプ1：ステートメントレベル
      • 代表的なツール：GenProg, RSRepair
      • 探索範囲が広いため、探索方法に工夫が必要。遺伝的あるごとか
    • 変更タイプ2：テンプレートベース（最新はこちらが主流）
      • Prophet, PAR
      • 探索範囲は狭いが、テンプレート依存
      • テスト成功でも、正しいパッチとは限らない。誤ったパッチ（テスト漏れ）
  • 現在はレベル2（単純バグ自動修正）。3以上は直せない（複雑バグ、高度バグ、完全自動修正）
  • 課題
    • 小規模バグのみ修正可能
    • テスト実行が長いと、パッチ探索の時間がすごくかかる
    • 修正品質がテスト品質に大きく依存
  • SapFix by Facebook
    • 今わかっている範囲（詳細は非公表）
    • revert, template, 単純な変更を網羅的に試す
    • 特別なことはやっていないが、
      • 割り切りがいい。revert優先
      • 修正は実行時エラーに絞っている
  • 富士通
    • ELIXIR: AIを活用したバグ自動修正ツール
    • MLで過去の修正履歴から見つける
    • 開発者による修正は1h、ELIXIRは5min
  • バグ自動修正readyか？ チェックリスト == テストコードの品質が重要
    • 1.自動テストがある
    • 2.自動テストのカバレジに基準がある（xx%以上
    • 3.単体と結合両方で自動化している
    • 4.CIしてる
    • 5.実行時間が規模に対して十分に短い
    • 6.バグが発生したときに再現テストコードを書く文化がある
    • 7.ミューテーションテストでテスト品質を確認している
  • 開発スタイルが変わる。CIで検出した単純バグはBotになおしてもらう
  • オープンソースではkGenProgが日本語で開発されている

github.com

Q&A

テスト十分性の基準は？

  • 理想はミューテーションまで。現実的なところは、カバレジか。

Facebookは実行時エラーのみに絞っている件、ほかは、テストケースがfailしたものも拾おうとしている

  • テストカバレジが必要なのはコスト的ネック、適用が難しい
  • その点も、SapFixの優位点

自動（運転）車システムのためのAI的自動テスト生成

www.slideshare.net

  • サーチベースド
    • 入力：歩行者配置、道路の構造、信号変化たいみんぐ、ほかの車の動きなど
    • 出力；安全性、快適性、法令遵守など（単項目ではない）
  • 最終的には人が見る。悪いケースにアタリをつける、絞り込む
  • 局所最適問題：あら捜し意識が強いと、やや悪い状況を探して、もっと悪い状況を見逃す
  • モンテカルロツリーサーチ、バンディット問題
  • AIシステムのテストへの応用

深層強化学習による制御系の検証の試み

  • 制御系が「おかしな振る舞い」をする入力を強化学習を使って自動生成した
  • 強化学習を使わない手法に比べて、効率的に探索できる（だいたいの場合
  • まだ実用化には程遠い（と思う
  • 強化学習のコツ
    • 入出力は正規化して小さい値にする。0-1とかがいい
  • 成功率の表、アルゴリズムの略称-次のアクションまでの間隔（1sec, 5sec, 10sec
    • 緑はDQN, 赤は既存手法

LT

LTはメモ取れておらず、公開されているスライドのみ貼ります

強化学習による制御システムの自動反例生成

speakerdeck.com

Generate and Validate Program Repair - 学術から産業へ持ち出してみて

www.slideshare.net

所感

バグ自動修正をしてくれるSapFixが話題になりましたが、その現実感とか、適用する前提条件が十分な自動テストというあたりを聞けてとてもよかったです。

テストカバレジは指標にとどめて100%を目指さなくていい、とずっと思っており公言もしていましたが、自動修正を見据えるとそうも言えなくなりそうです。また、ミューテーションテスト等、テスト自体の品質を上げる技法も注目度が上がっていきそう。

まだ実用レベルでないことは認識しつつ、いつか来そうではあるので早めに準備はしておきたい。