テストの完全自動化だって？JaSST Tokyo 2018 Googleの話を受けて

QA JaSST

JaSST Tokyo 2018の基調講演とクロージングパネルでのJohn Miccoさんの話を聞いて感じたことをまとめています。

完全自動化の文化について

2006年(2007年？)に方針を大転換したそうで、トイレでテストのことを考えるようにしたり、私も度々参考にさせていただいている Google Testing Blog を始めたそうです。

Googleのような超大企業でもそのような大転換が可能なのか、と率直に感心しました。
国内にも大企業があるわけですし、別セッションで柴田さんが組み込み系(という分野かな？あれは)でテスト自動化に取り組んでいたというので、大企業だからできるとかWeb系だからできるとかは関係なさそうです。

Agile開発でも似たような話を聞きますが、NASAや戦闘機開発だってAgileらしいけどなにか？っていうやつです。

「やれば出来る、飛べば飛べる」と某アニメのヒロインも言っていますが、ぐだぐだ言ってないでまずはやれよってことですね。

チーム構成について

1チーム当たり8人～10人で、そのうちSETI(Software Engineer, Tools & Infrastructure)が1人～2人いるそうです。

Googleには、以前SET(Software Engineer in Test)がいたのですが、役割の変化などに伴ってSETIと変更しています。

SETIの活動ついては、Google Testing Blogの SETIの話が載っているこちら や SETの話がのっているこちら がとても参考になるかと思います。

現状について

Googleでは、420万ほどのテストが存在して、1日1億5千万テストケース実行されていて(150million test execution/dayだからあってますよね？)、1テストケースあたり35回実行されているらしいです。

そして、これらがすべて自動テストであり、手動テスト率が驚異の0％！ただし、UX系のテストは手動だそうです。
UIのテストなどは自動化できるが、UXはさすがにまだ人手とのことで、人の感覚などが関係するUXテストがAIによってテスト可能で人の仕事が無くなるといった日はまだ到来していません。

自動テストですが、毎テストごとに420万テストケースを実行しているわけではなく、全テストケースを実行するのは一定の間隔で、普段は修正に対して依存があるテストだけを実行しているそうです。

基調講演とは別のセッションで、20分程度テストに時間がかかっているとおっしゃっていましたね。

一定間隔で実施している全テストをMilestone　Testと呼ぶそうです。

自分が参加しているプロジェクトでは、毎回全テストケース(UT)を実行しているのでそこそこ時間がかかっています。
フレームワーク作りなども関係する部分なので突然明日から変更します！と取り組めそうにありませんが、徐々に改善していきたいところです。

どうやって全テストの実行を減らしていったのか

至極当たり前の話です。

  1. commitとテストの間隔を縮める
  2. テストとcommitの分析を行う
  3. 分析結果をもとにテストの間隔を広げる

最初は、高い頻度で全テストケースの実行を行っていたのに対し、テスト結果とコード修正の関係を分析してだんだんと減らしていく、ただそれだけの話です。

文字にすると簡単そうですが、実行するには分析力を要しますね。

Flakyなテストとの闘い

自動テストにはつきものな不安定なテストにどう立ち向かうか。

無視することはいけないがある程度許容する必要性があるそうです。
Submit(GitでいうCommitやPushのことかな？)し続けるコストとのバランスが大事なようです。

原因分析を行い、インフラなのかプロダクトコードなのかを切り分けて無駄な時間を過ごさないようにしているようです。
クロージングパネルで、テストのExceptionを適切に出すことでインフラ、コードどちらが起因なのかを判断できるようにするなどと仰っていた気がします。

前談のテスト間隔とも関係しますが、commitというかPull Requestのサイズをかなり小さくする必要がありますね。

完全自動化への道のり

Googleでは、このように完全自動化していったという話が直接あったわけではないのですが、ポイントになるところは話していましたね。

新規サービスも最初から自動テストにするようで、はGoogleのサービス形態が人命にかかわるものじゃないし、イテレーションの高速化に寄与することにもなるから、最初から完全自動化なのだそうです。

テストが書きにくいレガシーコードは、改修時にテストできる状態にして、必ずテストコードも書いているということでした。

あと個人的に一番大事なことと感じた点、小さな変更が大事であり、小さい変更であってもテストコードも含めてsubmitさせること。
この程度の変更ならという甘えは危険ですね。

所感

システムテストも自動化したい！と自分のプロジェクトでも話をしていますがなかなか実現できない自動化。

完全自動化を目指すということではなく、より適切な時期にマーケット投入するためにどうするのか。そのために継続的なテストを自動化して手動テストは効果的なところだけに行いたい。

通過点として、アプローチはいくつかあると思います。開発チームによる単体テストと専門的なテストチームによる結合、総合テストの実施という役割分担もその一つです。
しかし、あくまで通過点で最終的にはGoogleのような一体となったチームで頭から終わりまで立ち向かいたいところです。

自分の活動を考え直す講演だったと感じていて、開発、SET、QA(テスト)が一体となったチーム作りのコーチング(コンサルティング？)ができる人財になりたいところ。
Scrum Master、Product Owner、他、自分の役割が何なのかは関係なく、チーム一丸で取り組むために主導できる立場でありたい...