JaSST '18 Tokyo 「Advances in Continuous Integration Testing at Google」聴講メモ
内容のまとめ
- Googleではすべてのテストを自動化している(UXに関するテストは例外)
- CIのスケジューリングに対する取り組み&(効果は維持したまま)コストを削減するための取り組み
- 変更の影響を受けない機能はテストしない
- 過去のテスト結果を蓄積する
- テスト結果を「状態」として時系列で記録し、変化がないものはテストしない
- マイルストーンの設置頻度を減らす
- 「Flakyなテスト」への対処
- コード自体の変更が行われていないのに、テスト結果が変化したものを抽出→開発者にフィードバック
上記を支えるための文化
- テストは書いて当たり前
- テストを書きやすい設計を考えるのは当たり前
- 再利用性のないテストだろうが自動テストを書くのは当たり前
感想
- Googleは、良いプラクティスと言われていることをただ愚直に現実世界に持ち込んでいるだけ、という印象を受けた
- 取り組みを評価するための数値化を、真摯に行っているという印象
- ただそれだけのことがどうしてこんなにも難しいと感じるのか
聴講メモ
- 1件あたり35回のテスト
- 分散化してテスト
- マニュアルQAは一切ない
- 非常に高速
- 非常に頻繁にプロダクトをリリース
- テストの99％は合格
- かなりお金をかけている
- テストの文化を根付かせる
- トイレに貼っている ヒント 結構有効
- テスティングブログ
- 新規採用 一日目からテストを書いてもらう
- QAを別部門としていない
- 1チーム8人に1人か2人がテスト担当
- テストのフレームワークを作る
- 新しいシステムテストというものを追加するためにテストを整える
- ST という役割の人間が土台づくりをしている
- 手作りの自動テストが主流
- どうやってテストを選ぶのか 450万のテストをすべてするのか
- 依存性関係を示したグラフ 図 を使って選定している
- 影響を受けるテスト
- バックエンドで同時並行
- 変更リスト IDをつけて2年間保管 パターンなどが見えてくる
- キャパシティがあいたら マイルストーンを区切って その時点までの変更がテスト対象になる
- 結果が出る
- どの変更で緑から赤に変わったのか
- パスからフェイルに移行した変更を見つける
- 回帰テスト
- 少数の変更ですべてに影響してしまう すべてがそれに依存しているから
- 実行しないテスト ほとんどの問題は0.2%の箇所で起きる
- リソースを節約するために、分析をする
- 変更の半分は38のテストに影響する
- 100％で400万のテスト
- このテストが安心か否かをどう見極めるか
- 赤い フレーキー
- 黒い ビルド失敗
- 現在のシステムは非常にコンサバです
- マイルストーンの間の時間がある
- いちマイルストーンは40分くらい
- グリーンライクなサービス
- インコンクルーシブ
- 100％グリーンでなくても確信レベルに近ければリリースする
- 新しいスケジューリングのアルゴリズム
- 不合格を見落とすリスクはある
- 少ないリソースでトランジションを見つける
- テストをやめればよい
- スキップするのが安全であるとはどういう意味か
- パスという状態とフェイルという状態の遷移
- フェイル＞フェイルもスキップして「よい」対象
- パス＞フェイルは「安全でない」
- パス＞スキップ＞フェイルの場合は「チェンジ2かチェンジ3が問題」
- マイルストーンを少なくする
- スマートスケジューラが悪い状態遷移を検知する
- テスト戦略 テストコストを低くしたい
- 遷移を見逃すリスクをおさえる
- 遷移がなければテストは安全
- どれだけの遷移を見逃すのか
- 新しい戦略の評価
- 2年間のデータ
- インターンの方が作成した図
- 3本の線
- 横軸はスキップレート
- 100％スキップしても0にならない
- 90％以上の場合、テストをしなくても遷移は見つからない
- オプティミスティック
- 遷移がわかっているものはスキップする
- 0.2％のみ実行する
- 失敗するのがわかっていてもスキップしない
- 中央の線は無作為
- 直線にならない
- 確率分布によるもの
- フレーキーなテスト
- 同じコードなのに、テストのパス/フェイルが両方出る
- フレークの不合格は、リリースの支障となる
- デベロッパーはフレーキーを無視する
- 1ヶ月分のデータ
- パスからフェイルの遷移の84％がフレーク
- コードの変更が問題ではない
- ブレークが起こっているのは非常に少ない
- ペアプロのエビデンスが出た
- 1人よりも2人のほうがいい
- ジョーがボブよりもフレーキーを起こす可能性が高い
- 言語によってはブレークが起こりやすい C++とJava Goはもっといい
- 是非結果を記録してください
- こんなものがフレーク
- WEBドライバーのテスト
- マルチスレッドのテスト
- 環境の差異
- 継続的に1.5％がフレーク
- デベロッパーにプレッシャーはかけているものの
- ある程度のフレークさは許容しなければならない
- ほとんどのデベロッパーは、うまくいくまでサブミットし続ける
- どれだけ頻繁に失敗するか
- このテスト自身が、最近フレーキーだったかどうかのフラグを持っている
- フレーキーデータベース
- 明日のチュートリアル
データセット
質問
- マニュアルテストは一切やってない
- ハードウェア含めた自動化のアイディアはあるか
- どれだけデジタル化が進んでいるかによる
- 信号機の制御アルゴリズムだけをテストすれば足りるはず
- カバレッジをどの程度達成しているのか
- 測定はしているが、チームの成熟度によって差がある
- テストの設計の話を知りたい
- コードレビュー ほとんどピアによってコントロールされる
- 小さな変更を非常に大事にしている
- フレーキーという言葉の由来
- 語原はミッコさんも知らない どちらかというと見下げたことば
- 一貫性に欠ける人 不安定 などというニュアンスがある
- グリーンをトップダウンで導入したのかボトムアップで導入したのか
- ボトムから、費用対効果のトレードオフをトップに説明した
- お金がかかるというのが課題感だった
- 3名以上 相関関係が見えてきた
- 3人以上になると規模が大きくなるので、3人がすべてのエキスパートになるのは難しい
- 1人よりは2人のほうがいい 他の人の目があるほうがいい 気づき
- 新規サービスのマニュアルテストもないのか
- 自動化できている 自動化できるということは、イレテーションが短いということ
- 多少問題があってもクリティカルな問題にはならないサービスだから
- UXテストも自動化できるのか
- テストの記録には個人名が入っているのか 個人に注目してどこまでやっていいのか
- よい質問です アメリカでは、従業員の情報は取ることができる すべて匿名化されている マシンラーニングのほうでそれは対処してくれる
- 開発者へのフィードバックについて
- 依存関係は精度が高い テストのグラフ ご関心があればベーゼルをご検討ください
- 開発者以外にフレーキー以外にフィードバックすること
- 様々な分析結果
- (不具合を)見逃してリリースしてしまったことはないか
- 何かを見逃すリスクは低い 見逃さないと思っている トレードオフをみている
- 組み込みのCIに興味がある 想定されるリスクなどあるか
- 少し考えさせていただきたい 興味深い分野だと思います
- グリーンにする社内共通基準のようなものがあるか チームごとに違うのか
- チームごとにテストの内用は決めている でも、ある程度チーム間で合意は取れているとは思う
- 再利用性が低いテストを自動化しているのは何故か
- マニュアルテストしているのは翻訳のみ 迅速にリリースするため 36時間以内にライブに出すというルールがある レアなテストでも、テストを書くということにコミットしている 文化的に組み込まれている
- 自動化にはまらないコードはどうしているのか
- もはやそういった問題はない 2006年に文化を変え始めた 2006年以降のコードは96％程度
- どんなベストプラクティスでもコードに組み込んでいく
- カオスエンジニアリングのような新しいテスト手法をやっているか
- インテグレーションは根づいている
- 実験的 ファジング ランダムテスト つかっているが いまは根幹にはなっていない
- 全体としてのテスト計画を誰が考えるのか
- 各プロジェクトチームが、全体的なテストプランを考えている Googleでは、少数のユーザに使ってもらって、フィードバックを得ている 各チーム自律的に動いている チームが個々に決断できる
- テスト変更の適切さをどう担保しているか
- レビューをしている
- テストの変更で失敗することはないか
- コミットする前に動かして確認している
- AIの活用
- AIは使うもの テストの選定 スケジューリング 機会学習のテストは難しい テスターとしてそこは心配している 数学をわかる必要がある もし壊れても気付けないおそれがある 業界全体が直面する問題
- 人数について
- 強い相関関係がある 複数に人が同じファイルを扱うとテストに影響する 3人以上は影響が起きやすい 3人より2人 2名が最適という判断 なぜなのかはまだわからない ルールまでは設けていない
- 特別なレビューはあるのか レビュアーに必要なスキルセット
- リーダビリティ 言語の可読性 コーディングスタイルをよく知っている その言語をよく知っている チームではテックリードの役割 直接同じプロジェクトに関わっていなくても、ピアプレッシャーによってうまくいっている
- トライビュー？というフレームワーク 静的な分析 コードレビューの自動化 使えないボタン すべてに対して修正をかけるより効率的
