はじめに
- 参加レポです！スライドは見つけ次第、随時更新します。
- 「スライドアップしたよ〜」「あのスライドアップされたよ〜」「この部分、たぶん言ってたことと違うかも」などがあったら教えていただけると幸いです。
イベント概要
- 日時：2019/11/30(土)13:00 〜 18:00
- 場所：株式会社ディー・エヌ・エー 渋谷区渋谷2-21-1 (渋谷ヒカリエ)
- システムテスト自動化カンファレンス2019 Connpass
- イベント申し込み時アンケートの集計結果
- テスト自動化研究会
- なんとYouTube配信もある
聴講できた講演
AIを活用した交通事故削減サービスのテスト自動化（仮） / 鈴木翔太さん(30分)
事前情報
AIを活用したサービス開発が近年増加してくるにあたりそのテスト方法をどうするかが注目されてきています。DeNAがリリースしたAIを活用した交通事故削減サービス「DRIVE CHART」におけるテストの工夫を紹介します。
メモ
-
DRIVE CHARTの説明
- 交通事故削減が喫緊の社会課題
- ヒヤリハットなどのドライバーの行動を改善
- AI、MLのテストは何すればいいのか
- やったこと
- モデル部分以外は普通の開発手法を使う
- モデル性能試験は、大量のデータを自動化
- テスト観点の洗い出し
- カメラの取り付け位置
- シートの角度
- メガネ
- 道路などなど
- テストケース再考
- 通常観測できる事象は豊富にデータある
- エッジケースは意識して集めないとデータそのものがないことが多い
- Rust使っている
- 過剰品質にならないように、関係者間で合意をとるのがだいじ
- アノテーションの品質問題
- 学習データのクレンジングだいじ。ラベルとか。
- テスト環境
- モニタリング
- 発生しうる状況やリスクを洗い出して合意を取る
感想
- 機械学習システムのQAの取り組みを知ることができて面白かった。
- QA4AI の話など。
- 「発生しうる状況やリスクを洗い出して合意を取る」ことが大切というのは、機械学習システム以外のQAでも共通する部分だなと思ったため覚えておく。
EM×QA視点で進めるテスト自動化への取り組み / 斉藤健太さん (15分)
事前情報
ウエディングパークでEM（エンジニアリングマネージャー）とQAチームの責任者をしております。 両役割の視点から、QAで考えるテスト計画や設計をもとに、エンジニアリングでテスト自動化を進めていく取り組みを始めました。 弊社ではテスト自動化が、ほぼ標準化されておらずゼロからの取り組みとなり、そこに向けてどういうアプローチで進めていってるか、どういう全体構成や技術で基盤作りをしようとしているかなど、具体的な事例を交えてお話します！ QAチーム自体も、私が約1年半前に完全内製化で立ち上げたチームですので、これからテスト自動化を進めていこうと思っている皆さんの参考になればと思います！
▼キーワード
CI/CD、自動テスト（unit/api/e2e）、静的解析、コードメトリクス、Webスクレイピング・・・など
メモ
- ウェディングパーク
- EMとQAの役割
- EM
- 複数の開発チームを束ねている
- QA
- 事業横断でサービスを見ている
- QALTで斉藤さんが発表したスライドも参考になる
- EM
- EMとして考えたこと
- 全体のアーキテクチャ部分を考えた
- どう実現すべきかを考えた
- テスト自動化
- これはEM視点でやる範囲
- QAとして考えたこと
- QCDをより良くしていきたい
- 「何を担保すべきか」をメインにフォーカス
- ビジネス的な重要機能に絞る
- テスト観点をベースとしたテストケース作成
- これはQAがやる範囲
- テスト観点をベースとしたテストケース作成
- テスト自動化
- ビジネスリスクを軸に！！
- テスト自動化の導入比率
感想
- EM、QA、そして3児のパパはすごい！
Serverless automation UI testing by using AWS Fargate / 引持力哉さん (15分)
事前情報
弊社LIFULLではサービスの回帰テストを目的として自動システムテストを利用しています。 リリース前に約800ケースの自動システムテストを定期的に行っています。 先日、テスト実行環境をEC2インスタンスからAWS Fargateへ移行しました。 これにより、効率的なテスト実行環境を作り上げることができました。 具体的には以下のものです
- サーバコストの効率化
- 課金発生がテスト実行時のみになったため。
- テスト実行時間の短縮
- 実行環境のスケールアップによる実行時間の短縮
- 実行の並列化による実行時間の短縮
AWS Fargateでのテスト実行環境アーキテクチャと、構築時に得た知見等をお話できたら良いと思っております。
メモ
- #lifull-set
- @rmochioo
- 自動システムテストフレームワーク
- EC2インスタンスからAWS Fargateへ移行
- 旧環境：EC2インスタンス
- imageはECRから、定期実行はおじさんから
- 柔軟なリソース調整ができないのが問題
- E2E、リンクステータス、レポート機能
- 無駄なものも走ってた
- 新環境：AWS Fargate
- EC2インスタンスを気にせずにコンテナ立ち上げができる
- タスク定義を用意しておけば、テスト内容に応じたリソース調整ができる
- 定期実行はECSのタスクスケジューリング機能を使うようにした
- awsvpcネットワークモード
- タスクに対し、自由なVPCとかを紐づけられる
- 注意点もある
- タスク定義上でポート番号を指定してあげましょう
- クラッシュ
- 依存関係
- dockerize
- 構成管理
- Terraform
- Terraform
- 注意点もある
- タスクに対し、自由なVPCとかを紐づけられる
- 旧環境：EC2インスタンス
感想
- 今の自動テストの環境の問題点を技術でいかに解決していくかを探っているSETかっこいい
- 「定期実行はECSのタスクスケジューリング機能を使うようにした」Jenkinsおじさんさようなら
テスト自動化プロジェクトを支える技術と仕組み / 伊藤由貴さん (30分)
事前情報
ベリサーブでは、品質・検証会社として様々な業種や対象のテスト自動化を行っています。 今回は、テスト自動化プロジェクトを成功させるために整備してきた
- ガイドライン
- テスト自動化プロセス
- エンジニアのロールとスキル定義
- 教育体制
などのノウハウ・仕組みについてご紹介します。
これからテスト自動化をはじめようとしている方や、既に一部で取り組んでいるテスト自動化を社内で広めていきたい方に役立てていただけるかと思います。
メモ
- 使っている具体的なツールやライブラリの話ではなく、これから自動化を始める人などが対象
- テスト自動化とテスト実行自動化はイコールではないという前提で話す
- ずっとテスト自動化の仕事している
-
ベリサーブ
- 品質創造企業
- 品質向上に関わる仕事
- 品質創造企業
- お客様のQCD向上に寄与するのが理想だが、むしろコストを増やしてしまったり、プロジェクト自体が燃えてしまいQCDどころではなくなってしまったり。
- 抱えていた問題
- 社内の横の連携不足
- 個別に頑張っている状態
- エンジニアのテスト自動化スキル不足
- 「要員ガチャ」の闇
- マネージャのテスト自動化知見不足
- 自動化特有のハマりポイントとか
- 社内の横の連携不足
- 既存の概念も役立つが、もう少し具体的な仕組み化が必要と考えた
- 抱えていた問題
- 取り組み
- テスト自動化プロジェクトガイドライン策定
- 自動化進めるにあたって必要なことまとめた
- ISTQBのシラバス、社内外の事例
- gTAA、TAA、TAS
- 標準プロセス設定
- 全体像を明確にするもの
- テスト自動化エンジニアのロール・スキル定義
- どんなスキルを持ったエンジニアがいればいいのか。「テスト自動化ができる」とは何か。
- ロールを設定、各ロールのスキルを可視化。5つある。
- どんなスキルを持ったエンジニアがいればいいのか。「テスト自動化ができる」とは何か。
- 社員教育
- 研修の開催
- テスト自動化関連研修を毎週
- Python、Selenium、Git、Jenkins
- 「これらを身につけています」を胸を張って言える状態を目指している
- テスト自動化プロジェクトガイドライン策定
- 成果
- 社内ノウハウの共有促進
- プロジェクトの安定運営
- 文化の浸透
- 非エンジニア職からも要望
- 「ウチのエンジニアは皆テスト自動化を当たり前にできます」を目指していく
- Q&A：
- 各ロールの人数：どのチームにもアーキテクト、プロマネ、プランナーいる状態を目指したい
- まずハッピーパスからやるやらないを決める
感想
- 「ウチのエンジニアは皆テスト自動化を当たり前にできます」を目指していくというのいいなと思った。
会社レベルの「テスト自動化普及」ミッションに立ち向かう話 / 松木直之さん (30分)
事前情報
社内のSEの開発活動において「テスト自動化を普及させる」というミッションを背負って仕事をしています。SI、PKG・サービス開発など幅広く多数の組織があるなかで、会社としてテスト自動化が十分に進んでいることを目指しています。ですが「どんなテストを自動化する話なの？」「どこまですれば普及になるの？」「現場はそんな余裕ないんだよ」など、まったく簡単な話ではありません。私も道半ばですが、そういう活動の状況や施策についてご紹介します。うまくいくこと/いかないこと含め、同じ立場の人のヒントになれば幸いです。
- 共通部門や自動化普及推進担当のような人はぜひ
- 個々のプロジェクトではなく複数組織横断、マスでとらえる活動です
- ミッションの考え方、説明の仕方、何をKPIにするか、など
- 施策例（ツール、教育、ナレッジ、など）
メモ
- テスト戦略の話をする
- 現場のSEが4万人
- デジタルソフトウェア＆ソリューションBGは5人
- 自動化
- 当然となる環境への危機感
- テストにフォーカスできない、テスト軽視への危機感
- 見解聞いてみた
- 人海戦術
- テスト技術についてほぼ知らないのでは
- 何をもって「自動化」なのか
- 何を計測するか
- どう計測するか
- 大切なのは、「効果の計測」
- 普及率は活動の状況表示。効果は活動の価値表示。
- 僕たちの存続が会社にとっての価値
- テストツールを定める、いっそ作る
- 活動スケールを広げすぎない
- 広げすぎると収集つかなくなる
- 「ウチの会社はけっこう自動化している」と言わせたい
感想
- 何を持って「自動テストやってます！！」かについての認識合わせや定義が必要であるということが確かにと思い、勉強になった。
- 他にも、何をもって「普及」なのか、何をもって「〇〇」なのかなど。
- KPIを決めても腹落ちしない予感と戦わないといけないというのが難しいところで、その難しさに立ち向かっていくのもQAの仕事なのかもしれないと思った。
- 定量化することは大切だが、何を目的にした定量化をしようとしているのかを意識しないと迷子になってしまうことを学んだ。それは今後の目標設定などの際に覚えておく。
SeleniumConf 二都物語 / 河原田政典さん (30分)
事前情報
Seleniumの公式国際カンファレンス「SeleniumConf」をご存知ですか？2019年は4月に東京、10月にロンドンでの開催です。
今回は「SeleniumConf 二都物語（にとものがたり）」と題し、SeleniumConf Tokyo運営の裏側や、SeleniumConf Londonで繰り広げられるテスト自動化の最新事情を織り交ぜながら、現地で学んだこと・肌で感じたことをお伝えします。
国際カンファレンスは世界中の優秀なエンジニアと交流できる素晴らしいチャンスであり、かけがえのない経験が得られます。もちろん、最初はちょっとだけ勇気が必要だと思います。
この少し風変わりなセッションを通じて、次に世界に羽ばたこうとする皆さんの背中を押し、そしてSTAC2019に貢献できれば、何より光栄です。講演会場でお会いしましょう！
メモ
- 2019年、初めてのことをしましたか？
- 事業会社に転職
- ファンシーフライデー
- 靴下4000円たっけ！！
- 11万7000円
- 3万2000円
- 青いテスト会社
- 青いFintech
- 青い教育
- クリスマスキャロル
- 二都物語
- SeleniumConf Tokyo運営
- 4月に3日間
- ステップ
- 2017：Selenium Committer Day
- 2018：Selenium User Community
- YouTubeで全部のセッションを配信している
- 内容をMarkさんが紹介してくれた(詳細はスライド参照)
- Ivan Krutov@vania_pooh
- Twitter広報
- 登壇者控え室待機
- 「与えられた状況に対して、いかに効果的な、誰かにとって価値あるアクションができるか」がだいじだなと学んだ
- SeleniumConf London
- YouTubeで全部のセッションを配信している
- 内容をMarkさんが紹介してくれた(詳細はスライド参照)
- ペトラのマシンガントーク
- YouTubeで全部のセッションを配信している
- 次の世代の登壇を待ち望んでいる
- ベテラン勢は成果をわかりやすく紹介している
- わざわざビザ取って会場に来る人たちと会うのは刺激的。大いに視野が広がる。
- 自分VS世界
- 「エンジニアの戦場は、世界だ」
感想
- 海外カンファレンスに参加する意義は、「情報」よりも「情熱」の交流なのかもと思った。
mabl導入記 / 増原賢秀さん (15分)
事前情報
今年4月に開催されたmablハンズオンで発表した https://speakerdeck.com/masalajpn/what-ive-learned-using-mabl の続編。初見の方もいらっしゃると思うので現状のmablの仕様も踏まえたアップデートになる。かも。
トピック
- mabl mailboxやresult api活用してます(予定)
- data-driven testing導入しました(予定)
- ハマったところ。これまで困ってサポートに問い合わせりしたことなど
- 他エンジニアへの展開はじめました
メッセージとしては、去年の板垣さんの発表を踏まえ、実際に日本にユーザーがいるんだよ、ツールを使うっていう選択もあると思いますよ というのが伝わればいいなと考えています。
メモ
- #ソフトウェアテスト
- mabl
- ピ社
- 使われなくなったPuppeteerが残ってた
- mabl用語
- test
- plan
- flow
- 実際の動きを見せてくれた
- liveでブラウザ操作を記録
- パッと見でだいたい何しているかわかる
- liveでブラウザ操作を記録
- これからなところ
- 海外にサーバーある
- mablに向かない画面がある
- メンテする人が増えたらどうなる
- みなさまへ
- サポートは英語
- ブラウザ自動テストのお作法
- 積極的に改善サイクルに関わっていこう
- 検証の時間は十分に取ろう
- トライアル期間に触りまくろう
- 実行結果は早い段階で開発者に知らせよう
- 可能なら、検証や導入は複数人で担当しましょう！
- アップデート内容をまとめて日本語で書こう
- 課題
- 何をテストすべきか決める
- CI連携
- メンテ他の人もできるように
- E2Eの外に出る
感想
- noteの中の人なのか〜！
- 自動化ツールはどんどん進化していっているであろうしまだ私には知らないものはたくさんあるので、こうしてシェアしてもらえるのはとてもありがたい。
- こうした自動化ツールの紹介や事例発表を参考にしつつ、何をどう自動化すべきなのかというもっと根底の基礎も学んでいこうと思う。
- スライド作成はMarp使っているのかな！？
画像認識ベースのUI自動化フレームワークを用いた取り組み / 古屋秀平さん (15分)
事前情報
E2Eテスト領域におけるAirtestを使った検証自動化の取り組みについてお話します。
- 複数台の端末を連携させての自動化事例など
メモ
感想
- Airtest初めて知った
- テックブログやウォンテッドリーなど、普段書きためているものをスライド発表時に「詳しくはこちらを」を言う流れは見る人も話す人も幸せ
聴講できなかった講演
- 途中からは講演会場が2つに分けられ、同時間で2つの講演が行われました。
- そのため残念ながら聴講ができなかった講演もあります。
- 公式サイトから引用した事前情報、および登壇者のスライドを残しておきます。
Beyond automated functional checking for mobile / 松尾和昭さん (30分)
事前情報
モバイルアプリのGUIのからむUIテストは、単純な自動化で"機能的な確認をする"段階はすでに終えました。 それらのテストをCI/CDに組み込むための高速/安定化(Espresso/EarlGrey/XCTestなど)や、（モバイル端末を主体とした）継続的なモニタリングとしての役割も含む性能テストなどがここ数年間の間に広く挑戦されています。 そのような世界を、私の経験を含めて共有したいと思います。特に、"GUIを操作してスクショをとる機能テストを実行する"話は一般化し、その周辺の話までされているということがモバイルアプリの世界でも発生していることを取り上げたいと思っています。
メモ
- こちらは講演会場が別だったため聴講できなかった。
クラウド上のモバイル端末・シミュレータを活用した大規模並列テスト / 国分佑樹さん (30分)
事前情報
AWS Device Farm やコンテナ化した Android Emulator をクラウド上で複数起動し、並列に自動テストを実行するノウハウと経験則をお話します。また、この自動テストではテストシナリオの保守コストを下げるためにシナリオを必要としないテストエージェントを活用しています。この種のテストエージェントによって、クラッシュやメモリリーク、パフォーマンスイシューを自動で見つける方法を解説します。
メモ
- こちらは講演会場が別だったため聴講できなかった。
エンタープライズ領域へのテスト効率化推進 / 坂下聡さん (15分)
事前情報
テスト自動化を推進するにあたり、スプレッドシートを利用したキーワード駆動型の手法を用いて、Seleniumの導入容易性を大幅に向上したり、既存の設計書からテストケースを自動生成する手法を組み合わせて、テストケース生成からテスト実行までの一括自動化を実現してきました。また、PJに応じた有償サービスの提携やテスト自動化の普及活動も合わせて実施してきました。PJ個別に説明をするところから始まり、組織単位での説明や社内のWBTによる周知活動の継続により、社内において半数のSEが認知するまでになりました。この5年間にわたる活動の中で、うまくいったことや苦労したことを紹介します。
メモ
- こちらは講演会場が別だったため聴講できなかった。
AI自動テストツール導入と発生課題 / 横田雅和さん (15分)
事前情報
以前別の勉強会で話した内容（ https://speakerdeck.com/m_yokota/tesutozi-dong-hua-nitiyarensi-ke-ti-toxin-tanasutetupu ）を基に、肉付け等をして話したいと考えています。
メモ
- こちらは講演会場が別だったため聴講できなかった。
Karateによる開発プロセス改善の事例と、Zipkinと連携したマイクロサービスの障害点検知の仕組み / 高橋勲さん (30分)
事前情報
このセッションでは、昨年のシステムテスト自動化カンファレンスでAPIテストフレームワークであるKarateを知った私が、下記のKarate導入・活用についてお話させていただきたいと思います。
- 「一度E2Eテストを諦めたAPI開発チーム」にKarateを導入して本番環境での障害を減らし、継続的な運用を行っている事例
- E2Eテストと分散トレーシングシステムのZipkinを連携させて「マイクロサービスのどの部分で障害が起きたか」を効率的に発見する仕組みを構築・運用した事例
お話する内容は開発プロセスの広範な改善(テストの習慣化、MTTRの削減、障害時対応の迅速化)を含むため、テスト自動化エンジニアだけでなくQAやプロダクト開発チーム、プロダクトマネージャなど幅広い方々のお役に立つ情報をご提供いたします。
メモ
- こちらは講演会場が別だったため聴講できなかった。
公募LT大会
Karate による UI Test Automation 革命 / 鈴木貴典さん
- テスト自動化における課題は、ピラミッドの上の方のテスト
- Karateは幅広いテストに対応できる
Seleniumに疲れたら、TestCafeで一休みしていきませんか / 末村拓也さん
- Autify
- TestCafeのQiita記事
- Selenium Web Driverを使わない
- モバイル実行もできる
- リモートブラウザモード
- Web Driverで起きてた問題を、「俺たちが自分で作ってメンテする」の意気込み
- TestCafeはTestCafeでバグある
- いろいろ選択肢あって楽しいね！
フロントエンドの自動テストって何をすればよいの？（仮） / 桑原聖仁さん
- ゆめみ
- 初期レンダリングした時にラベル入っているか
- テスティングトロフィー
behave+TextFSMによるネットワーク機器テスト自動化への取り組み / 坪田繁さん
- APPRESIA
- tcl
- BDDテストケースと実装を分離
カイゼンと僕とE2Eテスト / 大津和槻さん
- 内部システム知っているのが自分だけ
- バグ多い
- 手動、モンキーテスト
→E2Eテスト導入
- 手動、モンキーテスト
- テストケース作成
- 主要機能のNever、Must、Want
- E2Eテストが全然運用に乗ってなかった
- バッチの挙動はE2Eテストで担保できない - リファクタリングをしてユニットテスト導入
- このままでもユニットテスト出来なくもないよ！
- 大津さん自体がチーム移動
- 僕がいなくてもテストコード書く作業ができるようにしたい - この姿勢いいな〜！（感想
- カイゼンに終わりはない！！
ノンプログラミングでゆくテスト自動化の道@ユーザ系Sier / Tamechop30 さん
- Testablish導入
- ノンプログラミング、変更に強い
- クラサバ系のアプリにもやっていきたい