目次
- 目次
- 発表スライド
- 当日のツイートまとめ
- 自己紹介
- 本セッションのコンセプト
- テスト自動化への期待とその結果
- テスト自動化の課題とその対策
- テスト自動化のための理想の体制とロール
- まとめ
- 会場からの質問
- 関連記事
発表スライド
当日のツイートまとめ
自己紹介
今回は自己紹介と働いている組織の形を紹介してもらう
山口鉄平（以下、山口）
- Yahoo! Japan
- システム統括本部 技術支援本部（元）
- 元々は組み込みのソフトウェア開発をしていた
- Yahooは多種多様なサービスが色々な作り方をしている
- Unitテストの導入だけでなく、E2EやAPIも行っていた
- Yahooはプロダクト単位で行っており、その範囲でテストも行っている
- それを我々の間接支援部門が支えている
- QAというプロセスは存在しない
大園博昭（以下、大園）
- LINE Fukuoka
- UI Test Automationチーム
- プロダクト単位で行っている。
- テスト自動化チーム、SETチーム、QAチームが別にあり、それぞれのプロダクトチームに入っている
木住野奈夫人（以下、木住野）
- LIFULL
- 開発志向を持っていたがQAチームへ
- 半年前にQAチームから分離される形でSETチームが誕生
- 4,5名/チーム、週4回のリリース
- リリースパッケージに対するE2Eのテストを実施
- 不安になっている自動テストの相談に対して対応している
根本征（以下、根本）
- メルカリ
- 新卒からWebバックエンド→SETチーム→Automation and Engineeringチーム
- E2EテストやCI/CDを実施
- テストがメインではなく、開発者の生産性向上のための動きをしている
- これまではQAチームと協業して自動化をしていたが、それだけでなくリリースを早めるためのE2Eテストの自動化を直接プロダクトチームに入って行っている
松尾和昭（以下、松尾）
- HeadSpin
- アメリカにある企業
- 今回はクックパッド在籍時代の話を中心に話す
- UnitテストからE2Eテスト、プロセス改善を経験
クックパッドでは国内外の開発に携わっていた
1つのプロダクトに対して、機能ごとにチームができていた
- QA（QITチーム）は横断的に見る形で
- テストの破綻を見越してテストチームを行っているのが特徴的（by 藤原さん）
モデレータ：藤原大（以下、藤原）
- メルカリ
本セッションのコンセプト
自動化を中心に、今後の未来について話す
- 自動化の課題
- どういう組織になっていくのか
ここで言うのはあくまで一例なので、ご自身の自動化推進に参考にしてほしい
テスト自動化への期待とその結果
期待
- 素早いフィードバック
- テストの効率化
- コスト削減
- すばやいデリバリ
- バグの早期発見
- 心の不安
結果
- 素早いフィードバック
- テストの効率化
- すばやいデリバリ
- バグの早期発見
- 心の不安
なぜコスト削減が消えた？
藤原
- 期待と実際の結果を見比べると、コスト削減の期待が消えているのが特徴的に感じた。
- ここについて実際の経験を元に話してもらいたい
大園
- 最初はすべて手動テストをしていた
- QAチームが行っていた
- 品質も担保したいし、コストを削減したいという目的で自動テストを実施した
- 大失敗だった
- 教訓を元に、「まずは品質を担保しよう」ということになった
- あるサービスでは90％は担保している状態になった
- テスト実施のコストは減ったが、自動テストスクリプトの作成コストが増えたので、結局は人的コストがトントン
- 最初はすべて手動テストをしていた
根本
- 2年前にテスト自動化を立ち上げた
- 始めた当時は目に見える効果が大事
- コスト削減は見えやすい
- ただ、メンテナンスコストや、自動スクリプトの作成スキルがあるエンジニアの採用活動コストなどを考えるとトントン
テスト自動化の課題とその対策
- Automation Pattern wiki参照 testautomationpatterns.org
テストが失敗したわけではないが、別の要因（データ作成とか）でテストに失敗してしまう
松尾
山口
- まず、このことがどうして課題かと言うと、安定しないと「テストをやらない」という判断をプロダクトがするようになってしまうから
- そのような場合は、先にインフォメーションを与えて、回避することを先に行う
- もちろん安定させていくことも同時に行っていく
- そこじゃなくても自動テストのメリットを享受できる部分があるはず
自動化チームがいない、または立ち上げが難しい、人材がいない、または少ない
大園
- 立ち上げに難しいというのはあまり感じていない
- むしろ拡大フェーズにおいて、なかなか採用が難しい
- システムを作るに置いてエンジニア力が必要
- エンジニアの採用と同じ感じ
山口
- 3000人いると、SETチームに頼るのは難しい
- 各現場で書けるようになるのが大事
- その人達ができるようになるにしていく
- サービスに伝える、教える人を増やしていくようにする
藤原
- 作れる人のポイントは？
山口
- システムを作ることができる人
- テストをなるべく無駄なく効果的にできるようになる人
- 一夜でできる話ではないので、学び続けられる人
何を自動化の対象とするか？どのテストを自動化するか？のスコープや計画や準備がきちんとできていない
木住野
- 当時、常識が無かった
- テスト対象が明確になっていなかったので、テスト計画を作るようにした。
- テスト対象を絞った
- 手動テストと自動テストのカバーする範囲を明確化した
- その中で、どういったテスト対象にするかは、以下のいずれかを満たすものにした
- ビジネス上絶対に守らないといけないもの
- 明確に定義した（Google Analyticsより）
- ページビュー数
- ページの価値
- 明確に定義した（Google Analyticsより）
- 過去に不具合が起きたもの
- ビジネス上絶対に守らないといけないもの
- 現在は、テストエンジニア3人で長くて4時間、だいたい1時間で完了するようになった
大薗
- 何も考えずにどんどんスクリプトを作った
- プロセスを抜かして、自動化した
- 「すごいでしょ」と一人で思っているようになった
- プロセスを抜かして、自動化した
- 失敗した数はかなり多い。それだけ何をやればよいか学んだ
- 何も考えずにどんどんスクリプトを作った
根本
- テストケースの問題が多かった
- 新しい機能のときに更新されていなかった
- どういう意図でこれを作ったのか誰も分かっていなかった
- テストケースを作り直すことになったので、さらに自動テストも直すようにした
- テストケースの問題が多かった
手動のテストケースをそのまま自動化してしまってテスト効率が悪い
藤原
- 手動テストは手動のためのケースだと思っている
松尾
- アプリのUIのテストだと、いくつものシステムをまたいだ設定があったりする
- 自動テストすると無駄が多く、非常にもったいない
- 自動テストでは裏側の設定をスクリプトで行ったりできるはず
- アプリのUIのテストだと、いくつものシステムをまたいだ設定があったりする
木住野
- いきなり自動テストケースから作り始めたが、困った
- 自動テストを実行して失敗したときに、手動で実行することができない
- いきなり自動テストケースから作り始めたが、困った
テスターが自動化用テストケースをかけない
藤原
- 自動化エンジニアになっての苦労は？
木住野
- プログラミングスキルによる苦労は無かった
- 逆に、テストスキルが元々なかったのですごい苦労した
- 「ブラウザを自動的に動かすことが楽しい！」と自動化ハイになってしまった
- 参考：自動化ハイ kencolle.github.io
大園
- 多分、苦労は無かった
- テストに精通していたわけではない
- ソフトウェアには明るかったので、実装に対しての苦労はあまりない
テスト自動化チームがマネジメント層やテスター、他の関係者から十分なサポートを貰えない
根本
- メルカリでは現在、それぞれの品質や生産性に責任を持っている人とは働きやすい状態になっている
- 一方で、佳境の中でテスト自動化の大切さを伝えるのは難しい
- 砂漠の中で「森は大事ですよ」と言っても、彼らが欲しいのは水なので伝わりづらい
山口
- Yahooの中において、明確に「これをやらなくてはいけない」という仕事の仕方をしていない
- 実際にテストして困っている人のところに行く
- その人が「自動テストいいな」と思えれば、その人のマネージャに伝わっていく
- 個人的には「サポートをもらう」という形をしていない
- 逆にトップダウンで入れたほうが良いときもあるので、その時の効果を示さないといけない
- こっちから仕掛けていくことになる
藤原
- だいたい失敗する時は「カバレッジを正確に求めてくる」という人が現れた時だと思う
テスト自動化のための理想の体制とロール
質問1：自動化チームは必要か？
- 必要
- 大園
- 根本
- 不要
- 山口
- 木住野
- 松尾
「必要」派
- 根本
- メルカリだと、技術の変化を非常に感じる
- マイクロサービス化など
- モノリシックであれば現場が書けるが、ついていってキャッチアップするのは、チームではなくとも人への投資が大切なのでは？
- メルカリだと、技術の変化を非常に感じる
「不要」派
木住野
- 開発が行えるのが理想
- 開発プロセスを理解している人がやれば良い
- 実施できるスキルを持っている、投資できるのが大前提
松尾
- 「自動化チーム」という組織は不要
- あるサービス開発チームにおいて、自動化のロールを持って動く人がいれば良い。
- 自動化チームとして存在している必要がない
- 全社の基盤を作るチームは必要だが…
- 独立したチームが確固たる地位を持つ必要はない
質問2：QAエンジニアは必要か？
- 必要
- 大園
- 根本
- 松尾
- 必要ない
- 木住野
- サービスによる
- 山口
「必要ない」派
- 木住野
- 開発チームやPOが決める
- どうテストに対して納得感を作るのかができれば、QAエンジニアは必要ない
- ただし、そのための教育としてQAエンジニアは必要になってくるかも
「サービスによる」派
- 山口
- YahooのサービスにおいてはQAエンジニアが必要なサービスが特に無い
- 開発チームが改善や品質について見れる状況にある
- 修正してリリースできる範囲にある
- 1回リリースしてからバグが起きたり、人が死ぬようなプロダクトでは必要だと思う
テスターは必要か？
- 部分的に置き換わる
- 山口
- 根本
- 木住野
- 松尾
- 完全に置き換わる
- 大園
「完全に置き換わる」派
- 大園
- テスターが多様化してきている印象がある
- 単にテスト実行するだけでなく、プランナー的に企画段階から入っていったり、UXの部分も入り込んだりしている
- 自動化エンジニアがもてはやされている感がある
- テスターが多様化してきている印象がある
「部分的に置き換わる」派
山口
- 実行作業をするテスターは無くなっていくだろうし、なくしていきたい
- 探索的に見つけてくれる人は残るだろうし、その人の価値は高い
木住野
- 「テスターの仕事＝手動テストを実施する人」と考えていると不要になる
- 技術的にトレンドを追い、開発に取り込んでいく人は価値がある
- リーン開発においては探索的テストをまずテスターにやってもらって、自動化は後追いでやっていくことはありそう
根本
松尾
- 「現地に行って人の生活をする」というようなテスト実施はすぐに置き換わらない
- 人に対してのサービスを作る上では、切れない
- 特定の国で、実際の地域の通信を使ってテストするようなものは自動化に置き換えられる
置き換わる条件について
大園
- 前提条件をいくつかつければ、完全に置き換われると思う
- 開発体制などを見直すなど
- まずは直近のサービスで、そういう環境を作ることをやろうとしている
- 前提条件をいくつかつければ、完全に置き換われると思う
山口
- 何を外の環境にするかによる
- 外にすればするほど現場との距離ができる
- 「なぜ開発の人たちができないのか」という阻害要因を取り除いていくのが役目
木住野
- すぐは達成できるか分からないが、それを目指してやっている
- 誰でもメンテナンスできるように
- どんな環境でもメンテナンスできるように
- すぐは達成できるか分からないが、それを目指してやっている
質問：Agile、DevOpsがあたりまえの時代に求められる人材とは？
- 藤原
- テストフェーズを作ると、その部分がボトルネックになりがちだと思っている
プログラマが出せない価値を出せる人
山口
藤原
- プログラミングスキルはいる？
山口
- 何を作っているのか分からないレベルだと厳しい
- 何が必要なんだっけ？と伝えられる人
誰もやったことないことに果敢にチャレンジする人
- 大園
- 今まで「めんどくさいな」と思っているところを、我々が拾い上げる。
- Developerが開発に集中できるようにする環境を提供できるようにチャレンジできる人が求められている
技術スキルを持ち、継続的な改善を推進する人
- 木住野
- 技術スキルを持って、その中で最適な価値を選択する必要がある
- 最初から正解を選ぶことは難しい
- 低確率で最初に正解が出たとしても、時間の経過で最適解にならなくなることもある
越境する人
- 根本
学びを続けられる人
松尾
- 自分たちが活動しているチームで足りないものは何か
- 自分たちはどういうふうに動けばよいか
- これらを常に考え続けている人は生き残っている人が多い
藤原
- モバイル業界だとツールがどんどん出ているが、そういうのもキャッチアップすべき？
松尾
- 使ってみるのも大事だと思う
- それだけでなく、例えば、機能を見るのは自動化しているが性能評価はモニタリングを手動で行っていたら、そこをどうすれば自動化できるのか？とかを考えている
まとめ
- 自動化はテスター撲滅の夢を見るか？は実はテスターだけの話ではない
テスターの仕事は自動化によってどうなるか？
- 全部ではなく部分的に置き換わる（92％）
- 完全に置き換わる（8％）
- 置き換わらない（0％）
「テスターの仕事は自動化によって置き換わらない」は0%だった。
- テスターはメルカリにはいない
- そこに価値を感じていないから
- テストだけ極めるのは難しいと感じている
- 極端に言うと、給料が上がらない
テストの未来、品質の未来
- 超高速な環境によってテスト実行スピードも超高速になったら？Dockerでできるよ！
- AIやMLの力で自然なシナリオを自動生成できるようになったら？それOSSでできるよ！
- これらを提供できるテストサービスが登場したら？それたくさんあるよ！
- テストピラミッドがひっくりかえり
- 探索テストやテスト設計手法すら必要なくなり
- テスター、QAエンジニア、テストエンジニアが必要なくなり
- 完全自動で全ケース網羅すればよくなる
かもね？
会場からの質問
- 現場への改善と新しい技術を試すバランスが難しいと感じているが、どういうふうに気を付けているor工夫があれば？
回答
- 大園
- 会社の風土として、完全に独立部隊を作ってもらった。コストも度外視で
- 失敗を学びにして変えて欲しい
- QA環境もある程度固まっている状態だった
関連記事
昨年のJaSST Tokyoでのテスト自動化セッション
