はじめに
- この記事はJaSST'18 Tokyo（ソフトウェアテストシンポジウム）のパネルセッションを書いたものです。
JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo
自己紹介
- バックグラウンドが違い、コンテキストが違うことがある
- そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。
荻野 恒太郎（以下、荻野）
- 楽天
- テスト自動化とDevOpsのマネージャをしている。
- デプロイは毎日数十回実施
- 1週間に数回リリースしている
天野 祐介（以下、天野）
- サイボウズ
- kintoneの開発チームに所属
- エンジニアが10数名、QAなどを含めると30名ぐらいのチーム
- 2015年にチームリーダーになった
- 今はスクラムマスター中心
- 最近、WaterFallからAgile開発に変更していっている
- 今は1イテレーション2週間で行っている
- Deployの回数は1日数回から十数回実施
- 2週間に1回リリースしている
山口 鉄平（以下、山口）
- ヤフー
- 全社横断の支援部門のマネージャ兼プレイヤー
- 実際にプロダクトを持っているわけではない
- 特定のサービスの話ではないが、多いところだと一日数十回のDeploy、2週間や1ヶ月に1回のDeployをしているところもある
- テストの自動化はどんどん薦めている
- Deployやリリースの自動化もどんどん進めている
- セキュリティのテスト（というかライセンス周り）の自動化を進めている。
松尾 和昭（以下、松尾）
- クックパッド
- 海外事業部に所属
- 半年前に異動
- 開発拠点はUK
- リモートで東京で働いている
- 日本人は60名中10名ほど
- モバイルの自動化やワークフロー構築をしている
- OSSのコミッタとして活動している
- 書籍のレビューもしている
- 色々なサービスを分割して、それぞれで活動している
- 1サービス6,7名ほど
- GithubでMergeをAcceptすると、Deployを開発者が伝えればすぐにDeployできる
- Deploy回数は30回/日ほど
- モバイルアプリはAppStoreの審査が必要なので、1週間〜1ヶ月に1回は定期的にリリースしている
John Micco（以下、Micco）
- 26名のエンジニアが所属しているインフラでマネージャしている
- 中核製品Gmail, SearchなどのCIを担当
- 33000エンジニアをサポートしている
- Deployやリリースなどは行っていない
- 15年間はCIに特化している
- この15年間、同じテストの課題に直面し続けている
- リリースの頻度は2万/日
- そのすべてが本番にPushされるわけでない
- 本番にPushされるのは全体の5%
- そのすべてが本番にPushされるわけでない
- チームによって違う
- 1日に1リリースしたり、1ヶ月に1回リリースしたり
- 各チームによってリリース頻度は違う。中央管理はしてない
Micco氏が紹介したGoogleのやり方について
荻野
- 自己紹介を聞いて、随分GAPを感じた人も多いのでは
- どういう風な現場になっているかについてディスカッションをします
- これから自動化を考えてる人も多いと思うので、その人達の参考になれば。
- 例えば、基調講演の話で、200万件のすべてのテストケースが終わらないとリリースできないと思っていたのでは？
- 会場にアンケート
- もしも100％の自動化が終わっている場合、デグレッションテストの研究を使ってみたい（もしくは買ってみたい）人はどれくらいいるか？
- 登壇者の皆さんは、このGoogleのツールもしくはやり方を利用したいか？
天野
- サイボウズではSeleniumを使ったテストをしている。Pushをしてmasterに入ると、Seleniumで1700件のテストを20分程度で実行する。
- Flakyと思われる原因で落ちることがある
- Flakyかどうか勘で調査している
- Flaky効果的に探し出せるならば使ってみたい
山口
- 現在はそこまでのボリューム感がない
- 優先順位はチームごとによって違う
- 紹介されていた方法論を使えれば良いが、開発者、チームの感覚を確認した上で使う
- 「良いから使う」とはならない
松尾
- 簡単にはすべてを実行できないというときに、必要なぶんだけ実行するためには入れたい
- Googleの方法を使うことで、自分のコミットがどれだけ影響があるのか見え、責任を持たせる効果も出るのではと思う。
荻野
- Miccoさんに質問。
- 実際にはバグを見逃している可能性があるのでは？
- 全てのテストを実行しないというのはどういう思想をもとに行っているのか？
Micco
- 確かに全てのテストを実行しないでリリースするのはリスクがある
- ただ、思想としては否応なしにこのような取り組みになった
- コンピュータリソースが大きくなり、莫大なコストがかかってしまった
荻野
- 機械学習で行うといっているが、人間がテスト選択の妥当性を確認しているのか？
- 将来はAIが完全に担うと思うか
Micco
荻野
- AIのテストをどのようにしているかについては、後でまた聞きたいと思う。
テストの「価値の定義と計測」
- 自動テストでは、バグを見つけるという価値以外に、コストや時間の短縮に価値を見出していると思う。
- テストを行った時の価値について聞きたい
- 例えば、開発・QAの生産性など
- また、実際にどのように計測しているか
松尾
- 自動テストはリグレッションの防止の為というのは組織で共通認識になっている
- 製品を壊さないようにするために自動テストがある
- CIでどれだけGreenになっているかは計測している
- カバレッジを計測しているかはチームによる
- カバレッジを目標にしているチームもある
- マニュアルテスト（ユーザビリティテスト）はデザイナーを含めてチームでやっている
- 我々はサービス会社なので、市場に出してよいのか見ている
- 計測結果は逐次共有している
- リリース前にそれによって継続して開発していくかの判断はあまりしていない
- テストについては、カバレッジがあるからこのチームは良いとかいう話はしていない
荻野
- ソースコードがコミットされてからリリースまでの時間は？
松尾
- Webの場合、テストでAll Greenになるのは時間がかかっても20分におさえている部署がある
- はやいときだと10分いかなかったり
荻野
- もっと早いという方？会場に…いませんね
- これを実現するためにテスト自動化が貢献しているのではないか
- 続いて、サイボウズさんの場合はどうか？
天野
- QA部門があり、開発組織と別れてはいる
- 欠陥検出率は計測している
- 遷移を確認して、効率的に検出できたか確認していた
- 自動化しきれない部分をマニュアルで行っている
- 価値の計測はうまく行ってはいない
荻野
- Googleではどのようにテストの価値やQAの価値を行っているか
Micco
- Googleでは完全に自動化されているので、開発者にはコミット前でも後でもすぐにFBできている
- テストが成功に終わっているのは1つの証でもある
- ただ、コミットからリリースまで20分というクックパッドさんの例は世界で最速なのでは
テストプロセスとアジャイルについて
荻野
- 楽天では、DevOpsの研修をしていて、迅速にFBをしていく図を伝えている
- ドキュメントの管理だったり、リスクベースドテストなどの方法もある
- サイボウズさんの例（ウォーターフォールからアジャイルの変化）が面白いと思ったが、簡単に説明してほしい
天野
- 以前は3ヶ月のウォーターフォールだったが、2週間スプリント×6スプリントに変えた
- スプリントを導入した最初の頃は、6スプリント目をKAIZENスプリントとした
- 現在では、3週目のスプリントでの残存不具合がほぼ0になったので、KAIZENの工数も一定になった
- 6スプリントでリリースしていたが、スプリント2回分で1回のリリースになった
- 1年ぐらいかけて少しずつプロセスを変えていった
- 初期はバーンダウンチャートがバーンアップしてしまったり…
- それでも風土のおかげもあって、スクラムを止めようとはならなかった
- スクラムを導入しようとしたのは私の提案がきっかけ
- 結果として、不具合報告数が70%減となった
荻野
- 1年でサイボウズさんのような成果を上げられるのは珍しいのでは？
山口
- 成果との因果関係が分からないので、一概にアジャイルのおかげとは言えない
- アジャイル導入前後の結果を見ると、すごいと思うと同時に、導入前はどうなの？と思った
- ただ、上がったことは良いのでは？
- スクラム以外のおかげもあったりすると思う
- ただ、ここまでになったのは、より上手く作りたいと思った結果なのではないか。
荻野
- GTAC2014でYOUTUBEのテスト自動化に衝撃を受けた
Micco
- タイミングが一致していた。
- 全社的に自動化に舵を切った2006年にYOUTUBEを買収した
- Google全体で文化が根付いた一番の要素は、コードレビュー時にテストコードもコミットするようにしたこと
- こういう変更というのは、インクリメンタルに一段階ずつ行っていった。
- この領域はまずすべて自動化する、から会社全体に広がっていくとなっていった
- こういう変更というのは、インクリメンタルに一段階ずつ行っていった。
荻野
- 2006年からテスト自動化の取り組みを開始したと行っていたが、いつごろに100％になったのか
Micco
- 私が2011年に入社した時には、手動テストはほとんど残っていなかったと思う
- 全てのプロジェクトに関わっているわけではないので何ともいえないが
荻野
Micco
- 色んな出来事が重なった結果
- 政府の規制によってコードレビューが義務付けされた
- この発言について、後日、Micco本人に確認して、別記事にしました。
- 政府の規制によってコードレビューが義務付けされた
- 開発者の振る舞いも変えたかった
- 現在はコードレビューを存分に活用している
- アナライズをしたり
- 自動的にフィードバックしたりレビュアーでフィードバックしたり…
- 私にとって日本に来て喜びだったのは、テスト自動化は良いものだと思っているが、日本では経営者への説得が大変だと分かったということ
- アメリカの大手の企業は自動化はされているうえでどう改善するかの話になっているから
- 自動化を経営幹部に薦めるためのスライドは用意していなかった
- 自動化をすることで得られるメリットは、バグを見つける時間が短くなることなどがある
- これだけでは日本のCEOを説得するには材料が足りない
- 文化が変わるだけの大きな変化になるはず
- 例えば、QAチームから各開発チームに派遣したら良いのでは？
- 私の組織ではQAが独立部門にあるわけではない
- SETIが各開発チームにいる
- QAと開発者はより密に関わる必要がなる
- 例えば、QAチームから各開発チームに派遣したら良いのでは？
- 上層部に自動化を売り込むためには、価値を語れる必要がある。
- エンジニアの生産性向上を伝えられると良いが、なかなか難しい
- 具体的に、これだけの金額を節約できる、生産性がこれぐらい上がるという話は難しい
- コード1行あたり…といったような公式に落とし込むことはできない
- 今回のカンファレンスでも、そういった主張ができるように研究を薦めて、具体的な数値を示せるようにしていきたい
荻野
- このような価値を数字で示せるようにしたい
- ちなみに私は4年前のJaSSTで発表したのでその例を示す。
- 継続的にテストを行っていると、自動化前後のバグの修正完了日数が短くなったという成果が出た
- Googleではテストの組織をなくしたほうが良いと言っていたが、ヤフーさんの例を聞きたい。
- テスト組織をなくしたと聞いているが。
山口
- QAという職責を持っている人は現在いない
- リリース速度を早めるために、ゲーティングとしてのQAの価値がないと判断したから
- リリース権限とともに、チームにテストの責務を持たせるように変えた。
- テストをする人をなくしたわけではない。
- 行為としてのテストは残っている
- チームの中でどうにかするようにしている
荻野
- QAチームを無くすことに対して混乱は起きたか？
山口
- 混乱は特に起きていない
- 開発者が自分が作ったものをテストしないということは無いと思う。
- なのでやることは変わっていない
- 重箱の隅をつつくのはやらなくなったと思うが、ビジネスとしてダメージが大きい時に、次の時に何とかする
- リリース速度を早めたメリットの方が大きかった。
Flakyテスト、保守性など、自動テストの品質特性の課題をソフトウェアエンジニアリングで解決している事例について
荻野
- テスト自動化するしないで変わることについて
- テストエンジニアが自動化しているのではなく、エンジニアが自動化をしていると思う。
- また、自動化でよく出てくるのはメンテナンスの話
- ソフトウェアエンジニアリングとして解決すべき課題は多いはず
- 不安定なテストどのように解決していくか
松尾
- Androidアプリを対象としたテストでは、統一性が無かった
- 外部での通信もしたり
- 描画でのテストだったり
- モックやスタブを利用して、できるだけ最小のテストをしたり
- Flakyなのは色々な依存関係を持っているところに発生していた
- 色々な取り組みをしてきた。
- どのくらいの時間をかけて実行するのかなどをまずは決めた
- 実際のコードを書き換えて提供した
- テストサイズやテストのピラミッドを使った説明をした
- 狭い責任範囲にして高速で回すとか、時間をかけるテストはダメ、とか
- WEBの場合、色々なサービスが入っていた
- MSAの風潮に従って、単体の責務に分割するようになっていた
- 本来の責務だと20分かかるテストは無くて、10分や5分でできるように崩していった
- あとは、サービス間をどのように保証するかを取り組んでいっている
- 依存性のあるものを別のテストに置き換えたり
- 例えば、Facebookログインなら、スタブとかモックとかに置き換えていく
- ただ、それは内部で依存を持っていないと、外部のログインの仕様が変わったとき、壊れてしまうので注意が必要
山口
- SETIにあたるような部門が色々頑張ってくれている
- テストに限った話ではないが、開発環境やDeployなどのツールを開発している
- CI、CDやその並列化を進めている
- モバイルアプリについては、Flakyなものがあるのは事実なので、E2E用の環境に順次投入していって、開発部隊とは切り離すようにしている
Micco
- これはチュートリアルでも紹介したが、責任を明確に分担する必要がある
- 失敗したテストがFlakyであるという情報も伝えるべき
- 例えば、テストはサブミットされる前からFlakyである話なので、開発者の責任ではない、とか
- テストそのものが失敗であったこととインフラが失敗したことを別問題と扱って情報提供するようにしている
- 重要なのは、適切な人に適切な責任を持たせる
- そのためにインフラ側にも働きかける
荻野
- 今の話は痛かった
- 現在、インフラの問題でFlakyになっていることが多いので…
Micco
- メジャーな方法は、インフラそのものの不具合をシステムが認識出るようにする。
- インフラ側の問題だったらリトライを行う
- 例えばSeleniumで上手くいかなかった場合、Failにするが、インフラ側の問題の場合、Failにはしない
荻野
- テストの方でもExeptionをしっかり入れることは重要だということですね。
最後に一言
Micco
- 私はテストの自動化を強く支持しているが、エヴァンジェリストとして困っていることがあれば、是非お手伝いさせてください。
- 一緒に皆さんのCEOに説得させたいと思う
- 皆さんにお会いして、皆さんの会社について知れたことを感謝しています
松尾
- テストの自動化は色々やりたいと思っていると思うが、Deploy回数を増やすのはまずは必要
- リグレッションという一つの中でも自動化は必要
- 1人に責任過多にさせると厳しくなる
- 責務を分割して、テストとか意識しなくても確認できる世界になれば良いと思う
- 色々話をして楽しかったです。
山口
- 2人共コメントがかっこいい。ずるい。
- ヤフーの状態が良いと思っているかもしれないが、それは違うと思う。
- 何をすると良くなるんだっけ？と考えた結果
- ゲーティングをなくしたり
- パイプラインを変えたり
- 何をすると良くなるんだっけ？と考えた結果
- 届けるにあたって何をすれば良いのか考えるのがネクストアクション
- その結果の1つがテストの自動化
- 弊社の場合はこのようになったが、これがベストではない
- 何かやらないと変わっていかない
- 少しでも楽しんで頂けてれば幸いです。
天野
荻野
- 私個人はすごい楽しめた
- ヤフーのように前から自動化していく話とか、サイボウズさんの最近の取り組みとか
- Googleの取り組みとして、100%の自動化からさらにSKIPしたりとか
- クックパッドさんがリードタイムが世界一というのも良かったと思う
感想
- 奇抜なことをやっているのではなく、正攻法を実直に行っていると感じた
「これをやればOK」ではなく、問題は何か、次に何を行えば解決できるのかを常に考えていくことが大切だと感じた
山口さんの以下の想い、すごく伝わりました！
大人な言葉で、いいからやるんだよ、を言ってみました。
— teyamagu (@teyamagu) 2018年3月8日
関連記事
- この記事の中にも随所に出てくる、John Miccoの基調講演やFlakyの話については、別記事にまとめました。そちらもどうぞ。
