JaSST’18 TOKYO A8クロージングパネル簡易まとめ

アジャイル・自動化時代のテストの現場のリアル

自己紹介

• コンテキストを合わせるためにサービスのデプロイ/リリース頻度を伝え合う
• 荻野さん1日数十回のデプロイ（テスト環境含む）
• • リリースは1週間に数回
• 天野さん月1リリース（kintone）
• • 1日数回のデプロイ
• 山口さんプロダクトによって差がある
• • 多いところは1日数十回のデプロイ
  • 2週間～1か月のリリース、デプロイもある
  • テスト自動化はいま進めているところ
  • デプロイ、リリースの自動化も進んでいる
• 松尾さんモバイルオートメーションに比重を置いている
• • 検索・レシピ投稿でチーム分割している
  • 1チームが6,7人のエンジニアとディレクター
  • ビルドパイプライン→Github
  • PR→CIが回る本体マージデプロイコマンドでデプロイデプロイ権限はエンジニアが全員持つ
  • 国内事業は1日に30デプロイ
  • 国外対象は1日に20デプロイともにWebのはなし
  • モバイルは審査があるのでもっと遅い1週間～1か月で定期リリースしている
• John Micco26名のインフラチームのマネージャ
• • 全体では30000人のエンジニア
  • インフラとしてAndroid/Chromeはサポートしていない
  • リリースは全社で見て1日2万ほど
  • 本番リリースされるのはそのうち5パーセントほど
  • 1日1リリースのチームもあれば、1月に1リリースというチームもある頻度はチームに任せている

• 天野さんkintoneは1700件のセレニウムテスト（25分くらい）
• • 勘に頼って不安定なところを直している状況なので、そのリグレッションテストアルゴリズムは是非ほしい
• 山口さん開発はチームに委ねられている
• • アルゴリズムはアリだと思うが、それで付いた優先順位がチームとの感覚とあっているか確認する必要がある。
• 松尾さん膨大なテストケースがある状況ではそのようなアルゴリズムがほしい

テストケースの一部しか実行しないことでバグを見落とすのでは？そのあたりはどう対処している？

• John全テストを実行しないリスクはあるが、否応なくその状況に追い込まれているそれは全テストを実行する膨大なコンピュータリソース、コストが発生するようになっため

将来的にAIがテストケース設計することをGoogleは想定している？

• JohnGoogleの規模ではテスト件数が多すぎて人間が介在できなくなっている。
• • 機械学習はある程度間違いは起こすかもしれないが、あとで見逃した欠陥を機械学習にフィードバックして精度を高めている

テストの価値を組織でどのように定義しているか？

• 松尾さん自分たちのコードが他のチームのコードを壊さない、という価値は認識統一できている
• • CIのGreen、Redは計測している
  • カバレッジはチームに依存している特定のチームはカバレッジを指標にしているが、あまり気にしていないチームもある
  • マニュアルテスト（ユーザビリティ）テストはデザイナー含めてチームで行っている
  • サービスを市場に出してよいかチェックするという認識はエンジニアで統一されている
  • WebチームCIは稼働時間を20分に抑えることを目標にしているチームがある
  • • コミットからリリースまで20分が最短ライン
    • 特別な確認がない限りは10分程度でリリースすることもある
• 天野さんエンジニアが自動化をやっている
• • QAは自動化しきれない箇所を担保している
• Johnコミットからリリースまで20分は世界最速Googleでもそこまでではない

継続的リリースのためにはプロセスを改善していかなければならないが、その取り組みはどうしているか？

• 天野さんスクラム導入前は3か月ウォーターフォールの繰り返しを行っていた
• • スクラム開始して、スプリント1で開発してスプリント2で試験するという手法に変化全部で6スプリントある
  • スプリント6は改善スプリントであり、新規開発はしない
  • 不具合修正と同じくらい、改善に工数をあてることができるようになっている
  • スプリント2回分の成果物をひと月のリリースに収めている
  • kintoneチームは一年で不具合報告数が70％減った

YouTubeテスト自動化の事例を聞かせてください

• John2014年から3年間でテスト自動化を行った
• • Googleがすべてのテストを自動化しようと決めたのが2006年
  • その年にYouTubeを買収した
  • 自動化のコア技術はGoogleと同じものを使用している
  • テスト自動化の文化が根付いたのは、コードレビューとテストコードを必ず一緒にするようにしてから
  • 変更は1段階ごとに行っていた
  • コードレビューはテストを付随させるようにして、すべてのコードレビューにテストがつくようになった次に一部の領域のテストを自動化し、それが会社全体に広がっていった
  • 2011年時点でほとんどマニュアルテストは残っていなかった

テストコードとコードレビューのセットのような活動はボトムアップ？トップダウン？

• Johnトップダウンでコードレビューが義務付けられたコードレビュー導入を機にテストコードをセットにするようにした

JaSSTを振り返って

• Johnエンジニアはテスト自動化を良いことだと思っている
• • しかし経営層に説明するのが難しいと考えている
  • 米国はを大中企業のソフトウェア企業がほぼテスト自動化を済ませており、それをどう改善するかという段階に達しているので、日本とのギャップに驚いた
  • なので、経営層に自動化を勧めるような資料は用意してこなかった
  • 自動化のメリットリリース頻度の向上、バグ発見時間の短縮、リリース間の一貫性保持
  • これだけでは説得材料にはならないのでもうちょっと考えてくる
  • Googleでは開発チームごとにSETI(Software Engineer, Tools and Infrastructure)がいる
  • QAチームから開発チームに人を派遣するという方法が良いのではないかそれだけでも文化は変わる
  • 最も変わらなければならないのは開発側でQAともっと連携したほうが良い
  • 上層部にテスト自動化を売り込むためには何らかの価値を語らなければならないそれはエンジニアの生産性向上であるが、それを訴えるのが一番難しい

テストの組織をなくしたヤフーはその問題をどう考えているか？

• 山口さんロールとしてはQAは存在しない
• • 数年前にリリース速度を早めるため、ゲーティングとしてのQAは不要と判断した
  • 開発チーム内にリリース判断基準を委譲したチーム内で責任を持ってテストするようになった
  • 職責としてのテストは存在しないが、行為としてのテストはもちろん行っている

不安定なテストの自動化をソフトウェアエンジニアリングでどう解決しているか？

• 松尾さんAndroidアプリのテスト実装されていたテストに統一性はなかった通信したり描画したりするテストもあれば、モックを使った最小のテストもあった
• • • Flakyなテストは様々な依存関係をもっていたそのような自動化コードは本来不要のはず
    • • どこでどのタイミングでどれくらいテストするのかをきちんを決めて、エンジニア含めコードを書き換えながら説得した
  • テストピラミッドをベースにテストサイズを設定時間かかっても良いが依存性を制限したテスト
  • • 依存性を少なく、時間もかからないような小さいスコープのテストこのようにして不安定さを排除していった
  • 日本のcookpadアプリは様々な機能が入っている特定のリポジトリに変更が入るとCI上で全てテストしなければならなかったがマイクロサービス化で責務をアプリごとに分割し、責任範囲を明確にした20分かかっていたテストは、本来のアプリの責務に落とし込むと5～10分程度だった、ということもあった
  • ではその次にサービス間でどのように品質を保証するか？という話になるそこに今取り組んでいる
• 山口さんGoogleのように、SETIにあたるような部門が頑張っている
• • 並列化のツール群は内政していて、それをテストの方にも適応しているE2Eテスト用モバイルテストフレームワークにそれらを適応し、開発者側から離している
• Johnテストが不合格になった場合、テストがFlakyである情報と一緒にテスト結果が開発側に通達されるべき
• • コミット前からFlakyであったわけだから、コミット者の責任ではない、無駄な開発側の調査時間を減らすために、Flakyであるということを伝えなければならない
  • テストそのものが失敗であったことと、インフラの失敗を切り分けなければならない

インフラ側のエラーとテスト失敗の切り分け方法は？

• Johnインフラ側の要因でテストが失敗したのであれば、それがログに残るようになっている

まとめ

• Johnテスト自動化は強く支持している
• • この領域のエバンジェリストとして、社内のテスト自動化に困っている人がいたら是非手助けしたいCEOへの説得等
• 松尾さん世界各国の人にサービスを届けるためには試行回数を増やすしかないそのために自動化でデプロイ回数を増やし、責務を小さくして人の負担を減らしていきたい
• 山口さんヤフーは国内では相対的に良く見えているかもしれないが、どうすればよいかを考えた結果のQAのゲーティング廃止だったりするので、プロダクトの価値をユーザーに届けるにはどうすればよいのか？何が問題でどう対処すべきか？を真摯に考えていくべきだと思う。
• • 今のヤフーがベストだとは思わない。前進あるのみ。
• 天野さんスクラムを始めたきっかけは、ユーザーに早く価値を届けるためそのためにはアジャイルでテストを効率化したかった

• ---

所感

今出来ることからコツコツと積み上げていくしかない。言い訳は無用。自分は開発者であるが、プロダクトの品質を上げていくために何ができるか、真摯に向き合わねばと改めて感じた熱いセッションだった。