Upgrade to Pro — share decks privately, control downloads, hide ads and more …

輝く未来を抱きしめて。アジャイル・DevOps時代の品質組織づくり

 輝く未来を抱きしめて。アジャイル・DevOps時代の品質組織づくり

メルカリに品質組織が存在しない状況で、テストやプロセスの自動化を推進するために思いついたのが「Automation & QA チーム(通称:AQA)」でした。
メルカリAQAチームとは何か? 採用や組織づくりのポイントは何か?AQAで目指したいテストやQAの未来は何か?
QAエンジニア経験のない私が考えるアジャイル・DevOps時代の品質組織を解説させていただきます。

IT検証フォーラム2019発表資料
https://itk-forum.com/

輝く未来を抱きしめて。フレフレみんな!フレフレわたし!いっくよー!

Avatar for Dai Fujihara

Dai Fujihara

July 25, 2019
Tweet

More Decks by Dai Fujihara

Other Decks in Technology

Transcript

  1. 輝く未来を抱きしめ 
 アジャイル・ ev ps時代 
 品質組織 くり
 uly 25th

    2019 検証フォーラム2019
 ai daipresents
 utomation & roup

  2. 藤原 大 / ai 
 • メルカリ
 ◦ oftware ngineer

    in est( )
 ◦ エンジニアリングマネージャ( )
 ◦ 過去: 楽天(アジャイルコーチ、 )、 er ( avaエンジニア)
 • 活動
 ◦ 『アジャイル開発 スクラム』寄稿
 ◦ 『リーン開発 現場』翻訳
 • コンサルティング・技術顧問
 ◦ アジャイル開発支援
 ◦ や 組織 立ち上げ支援
 ◦ 自動化導入支援
 witter: daipresents log: https://daipresents.com/

  3. こ セッション 質問疑問 もちろん。アジャイルテストや自動化 、気 るこ を気軽 聞ける場所を目指し いる。 参考:

    gile esting, utomation and 現場 − 参加者募集中! https://bit.ly/2 t7a 
 コミュニティ参加者400名近く

  4. 2017年頃
 • 〜100人以下 開発組織
 • 職能横断型チーム 開発
 • エンジニアチーム く

    チーム あ た
 職能横断型チーム プロダクトマネージャ、i ng、 ndroid ng、 ng い た 必要 メンバーが参加し いる。 エンジ ニア 集まる「チーム」 、一時あ たけ 、当時 か た。

  5. 現在
 • 「チーム」 消 滅。そ かわり横串 チーム 配置
 • 自動化メイン

    チーム が きた
 • テスト設計だけ、実行 だけする人 採用し い(職能横断チーム や いけ い)

  6. 横串チーム( ) 立ち上げ
 • utomationありき いう名称 
 • 全員自動化
 •

    開発プロセス全体 関わる
 QAエンジニアも自動化 挑み、SETもQA 挑む が全員自動化。そ 結果、テストフェーズ以外 部分 も関わ いく必要が くる。 参考:メルカリQA-SETチームが考え いるQAやテスト 未来 し https://tech.mercari.com/entry/2017/08/18/100138 

  7. 今日、お しするこ 
 • ぜ今 時代 あ た品質を
 考える か?


    • うや 
 そ 品質を実現するか?
 • 品質やテスト 未来 ?

  8. 用語をそろえ おきます
 • テスター:テスト実行が主作業 人
 • : 品質保証(名詞)。人 い
 •

    エンジニア:品質保証活動全般 関わる人
 • 自動化エンジニア・ ( oftware ngineer in est)
 ◦ 自動テストやそ 実行環境を中心 エンジニア リング よ 品質課題を解決し いく人

  9. 用語をそろえ おきます
 • リグレッションテスト:
 回帰テスト。ここ バグ発見 いうより
 「修正 他が壊れ い

    いか」をみるテスト 近い
 • 単体テスト:
 小さいプログラムレベル テスト
 • 機能テスト・結合テスト:
 バックエンド(マイクロサービスや 群) 
 連携テスト。ここ シンプル 区別し い
 • 2 テスト:
 ebやアプリだ 画面を通したテスト

  10. わたし 環境 前提条件
 • スマホアプリや ebアプリ 
 ◦ テスト自動化
 ◦

    / 構築
 • 経験ベース 最適解
 (継続的インテグレション: ontinuous ntegration)、 (継続的デリバリ: ontinuous elivery)。世間 ontinuousブーム。

  11. こ セッション 視点
 • 非 エンジニア 視点
 • プロダクト 


    価値があるか いか視点
 • 多く 仮説を含む発表

  12. 参考: gile 2018 レポート:テスト戦略モデル おける「 」 何か? https://tech.mercari.com/entry/2018/08/30/190000
 参考: ontinuous

    esting in ev ps (2016) https://www.linkedin.com/pulse/continuous-testing-devops-dan-ashby/
 • ev ps サイクル 終わらず連続する
 • すべ アクティビ ティ テスト 必要
 • 誰もがテスト かかわ らざるを得 い
 gile 2018

  13. 参考: ソフトウェアテスト 大規模カンファレンス「 」 学んだ3 こ https://tech.mercari.com/entry/2018/11/01/124027 
 2018
 •

    継続的 統合
 • 継続的 デリバリ
 • よ 、継続的 テスト
 (テスティング)が必要
 • 継続的テスティング ?
 ◦ 何回も実行 きる
 ◦ すぐ実行 きる
 ◦ 安定し 実行される

  14. uro 2019
 「 ost-deploy verification in production」 まり本番環境 リリース後 テストする方法。

    
 参考: テスター 「まだ」死 い~テスター 武器 る や 【 uro 2018】 https://codezine.jp/article/detail/11239 p 2 
 参考: ビッグデータ、マイクロサービス おけるテスト 変化 【 uro 2018】 https://codezine.jp/article/detail/11226 
 
 • 自動化ありき セッ ション多め
 • ngから utometor へ キャリア変更事例が 人気
 • まだテスター 死 いらしい

  15. アジャイル・ ev ps時代 到来ま め
 • プロセスが継続的 ループ構 へ
 •

    テスト ロールや
 フェーズ く る
 • 自動化 よ テスト 考え方が変 わ いく

  16. 参考: ercari utomation & roup ntroduction https://speakerdeck.com/daipresents/mercari-automation-and-qa-group-introduction-2 
 テスト 戦略:

    そ 1
 • じめやすく成果が わかりやすいリグ レッション
 • 外 品質から中 品質へ
 作り込ん いく
 • ng向け 
 自動化
 or ng
 or 
 or 

  17. テスト 戦略: そ 2
 • リグレッション 日々 機能テストをマージ し いくプロセスを作

    る
 • 定期的 リファクタリン グし大きく たり小さ く たりを繰り返す
 リグレッション
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト

  18. テスト 戦術(自動化)
 ndroid/i それぞれ100ケース(シナリオ形式)ぐらいを、2名1ヶ月 作りき 運用を開始。自動化 き いケース ブロッカー し

    後回 し。現在 274ケースぐらいま 育 きた。規模 もよるがリグレッションテストケースがある らそれらを自動化 変換する 一気 やれ る技術スタックや環境が整 き いる 思う。 
 作戦名
 一気 やる
 (おすすめ)
 徐々 やる
 (一般的)
 メリット
 • すぐ 効果が出る
 • 低コスト
 デメリット
 • 初期コスト大きい
 • 最後ま あきらめ い気持ちが必要
 • 時間がかかる
 • モチベが続か い

  19. ビルドパイプライン設計
 郡およ 開発環境 バックエンドシステム 
 スマホアプリ
 テストデータ作成基盤 
 (テスト用 郡)


    テスト結果データ基盤 
 ( est ail)
 テスト実行基盤
 ( ppium / ode)
 テストデータ作成
 テストコード 2 実行 よる
 アプリから 呼 出し 
 実行動画保存
 ログ保存
 テスト結果保存
 アプリ自動ビルド
 ( ircle )
 テスト対象作成

  20. ビルド & テストデータ作成
 • ビルド タイミング
 ◦ masterへ マージ
 ◦

    リリースブランチ作成
 • ビルド
 • 成果物 配布(アップロード) 
 ◦ 保存し マニュアル、自動化 利用
 • 専用 データ作成 & テスト 準備
 i icon https://icons8.com/icon/20821/ios-logo 、 ndroid icon made by reepik from www.flaticon.com、 it ogo by ason ong is licensed under the reative ommons ttribution 3.0 nported icense. 、 ircle https://github.com/circleci/media 

  21. テスト実行
 • テスト実行
 ◦ アプリダウンロード
 ◦ テスト実行
 ◦ 並列化 高

    化
 (左図) 並列化 よ テスト 高 化可能
 参考: ocker × ndroid エミュレータ 、自動テスト( ppium)を並列化・爆 する環境を作 たお話 https://tech.mercari.com/entry/2018/12/10/060000

  22. テスト結果データ
 • est ail 連携し リア ルタイム反映(人間より 賢く 正確)
 •

    エビデンス
 ◦ プログラマチェック用 スタックトレースも 添付
 ◦ エンジニア向けテ スト実行動画も添付
 参考: 自動 2 テスト結果をビューティフル レポート ま め est ail連携し みた https://tech.mercari.com/entry/2018/06/07/142949 

  23. 参考:テスト結果分析
 • ケース 紐付いた
 ◦ 不安定さ 排除
 ◦ バグ傾向 発見


    参考: 自動 2 テスト結果をビューティフル レポート ま め est ail連携し みた https://tech.mercari.com/entry/2018/06/07/142949 

  24. 自動化 ま め
 • ここ リグレッションテスト
 から自動化
 • 将来的 日々

    機能テストも
 すぐ 自動化 きる体制を目指す
 • ビルドパイプライン 設計が必要

  25. 自動化ありき 
 品質保証
 自動化いがい これま 登場した課題が解決する らそれ もいい ず。ただし、 が自由自在

    テストする未来 まだ先だ 思う。今 「やろう おもえ それ も きるけ 、欲しいも 程遠い」 ? 

  26. a ’19
 誰もが変化を予想し いる。
 参考: 自動化 テスター撲滅 夢を見るか? a 語られたテスト

    未来、品質 未来 # a https://daipresents.com/2019/automation-dream-of-tester-eradication/
 • テスター 仕事 自 動化 よ 
 「置き換わら い」 答 えた人 
 0人

  27. 例: 自動化ありき テスト計画
 • テスト 範囲(効率化よりも価値重視)
 ◦ データドリブン:ユーザ 利用率が高い機能から網 羅(

    .g. 80% ユーザが同じ動線 らそ シナリオ だけ カバレッジ80% 考える)
 ◦ 価値ドリブン: 機能 価値を金額 置き換え 、高 い機能からカバーし いく
 a 下記セッション 計画 作り方も工夫し がら自動化を進め いる企業が多いこ がわかる。ライフルさん 場合、画面 価値付けをし 優先 順位を ける 、意思決定がロジカル シンプル。データドリブン 計画 くり事例も増え き い 、メルカリだ お客様 利用する端末を調べ 、人 気 端末を優先的 テストし い 、利用端末全網羅を目指し い い。見 かるバグも網羅 関係し い物が多く、それを目指し もコストが高く るだ け メリットが小さい現実があ た。 
 参考: 自動化 テスター撲滅 夢を見るか? a 語られたテスト 未来、品質 未来 # a https://daipresents.com/2019/automation-dream-of-tester-eradication/ 

  28. 例: 自動化ありき テスト設計
 • 自動化 ため シナリオ例
 ◦ シナリオ1: 新規ユーザ

    ユーザ登録 きる
 ◦ シナリオ2: ユーザ登録後 ユーザ ログイン きる
 ◦ シナリオ3: ホーム画面 「こん ち さん」 表示
 ◦ シナリオ4: ログイン後 ホーム画面 商品が並ん いる
 • もう少し詳細を話す ・・・
 ◦ シナリオ3、4 場合、シナリオ1 2 スキップ きる
 ▪ ログイン処理を テスト前処理 し 実行する
 ▪ ログインした状態 ホーム画面を開く
 テスト設計 いうより、機能 い たブラックボックステストを、プログラム う網羅し いくか考える形 る。一度や たこ 内部処理( コール 等) スキップ きるし、特定 環境やデータも自動生成 きる。 

  29. 参考: 手動テスト 自動化 しん い
 • 手動 効率性が考えられた従来 テスト設計 メリット

    が生かせ い
 ◦ 高 実行 きる環境だ 全部やれ よく る
 • シナリオやケースが自動化 向い い い
 ◦ プログラム設計も必要
 • エンジニアがボトルネック りがち
 ◦ 自動化用シナリオ作成やレビューが き い
 海外 も エンジニアから自動化エンジニアや へ キャリアチェンジ 多い。メルカリ も エンジニア出身 が2〜3名いるが、コードが「きちん 」書ける エンジニア 圧倒的 少 い。 ん くコードが書けるレベルだ utomator(自動化エンジニア) し や いけるかもしれ いが、テス ト環境課題 解決やビルドパイプライン構築 スキル不足 り、テスター 同じくスキル 幅が狭く しまう。 

  30. 参考: テスト自動化 アプローチ
 今あるも を自動化し いくよりも、自動化ケースを先 作り上げ 、そこ 保証 き

    い部分を、手動ケース し 追加し くほうが効率がよい。 まり、 日々、更新され いくマニュアルケースを自動化 追いかけるよりも、自動化ファースト 作られたケースを元 、マニュアルケースを考える いう流れ る いうこ 。
 anual
 uto
 anual
 uto

  31. 参考: さよ らテストケース管理
 こん ち テストコード管理
 コード上 上記 よう ステップを記述

    きる 、ここから est ail を通し テストケースを作成 きる。よ it ub上 コードもケースも管理 き る。余談だが、 est ailを長く使 い わか た 、こ ツールをテストケース管理 使う ら、 pread heetや xcelが eb ただけ あまりメリット が い。 を駆使し データを貯めたり作 たりすれ 、分析ツール し 使え より恩恵をうけられる気がする。 参考: jnicklas/turnip: herkin extension for pec - it ub: https://github.com/jnicklas/turnip
 Test Mgmt Tool API
  32. 海外だ crummerfall か呼 れ 揶揄され いる。 
 参考: テストフェーズが く

    る が未来だろう いう話 https://daipresents.com/2018/no-test-phase/ 
 参考: gile esting - esting from ay 1 https://www.slideshare.net/fstephan/agile-testing-testing-from-day-1 
 • 間違えやすいアジャイルそ 1
 • スプリント・イテレーション わけたけ 
 結局 的 プロセス
 アジャイル難しい問題

  33. アジャイル難しい問題
 • 間違えやすいアジャイルそ 2
 • スプリント・イテレーション内だけ 、
 結局 的 プロセス


    参考: テストフェーズが く る が未来だろう いう話 https://daipresents.com/2018/no-test-phase/ 
 参考: gile esting - esting from ay 1 https://www.slideshare.net/fstephan/agile-testing-testing-from-day-1 

  34. アジャイル難しい問題 対し 
 テストがフェーズじゃ く る ら、同時実行 開発 テストを進め いく必要がある。


    上記図だ anban 考え方が近い。
 参考: アジャイル開発 現在・過去・未来~今を知り、源流を訪 、先を見据える~ https://www.slideshare.net/hiranabe/now-past-and-future-of-agile-development-and-xp

  35. リソース VS ピープル問題
 • 品質 相談を聞い みる ・・・
 ◦ テスト工程を導入し

    
 品質を高め いきたい
 ◦ 品質を見える化したい
 ◦ 人員を効率的 使いたい

  36. ソリューション?
 • 方法論化されたテスト手法や工程を導入!
 • やるべきテストがテストフェーズ 
 移動しただけ
 • 品質を可視化し 組織的

    確認!
 • 見える化 目的 ら い
 • 管理体制を構築!
 • えー 、結局人力?
 これだ バグ 見 かるかもしれ い(次ページも参照 こ )。ただし、やるこ が減ら いし、結局マンパワー ん かする形 りがち。だから、こういう提案をもら た場合 、「短期的 人が増える し 、そ 人を うや 減らす り生産性を高めま すか?」 聞い みる いいかも。考え いる企業 ら回答 きる。

  37. あ たが欲しいも ん すか?
 バグ いうもぐらを
 丁寧 時間をかけ 
 手

    叩き続ける
 仕組み くり すか? 仕組み 仕組み 機能するが、こうい たケース 場合、そ 導入だけ 終わる 、永遠 そ 仕組み コストを払い続け けれ ら い。技術 スケールさせるこ きず、結局人手 スケールするしか い。

  38. リソース VS ピープル 対し 
 参考: 【16- -5】 アジャイルリーダーシップ 組織改革

    ~楽天 アジャイル開発 いうリアル~ https://speakerdeck.com/daipresents/16-b-5 
 • 自己組織化された チーム 
 ◦ 自己解決 きる
 ◦ 意思決定 きる
 ◦ 自己管理 きる

  39. 参考: よくある思考停止
 人間 しか き いこ 
 クリエイティブ 仕事をする
 、それ

    何?
 耳障り 良いけ 思考停止し いるかもしれ い。 いうか何も答え い い(参考:『「超 時代」 働き方』 落合陽一)。 

  40. テストフェーズもテスターも エンジニアもボトルネック りえる。 うや 自分自身がボトルネック る を避け いくかが問われ いる。 


    参考: gile 2018 レポート:テスト戦略モデル おける「 」 何か? https://tech.mercari.com/entry/2018/08/30/190000 
 参考: ontinuous esting in ev ps (2016) https://www.linkedin.com/pulse/continuous-testing-devops-dan-ashby/ 
 • 連続するサイクル
 • テストが必要
 • 誰もがテスト 
 かかわる
 
 これを実現する
 スキルが必要
 人材育成問題

  41. 「シフトレフト = 前倒し」 いう日本語訳 いい か悩む ころ。前倒し 限界がある 、それ 別

    活動 る いか? 
 参考: 2018より - ソフトウェアテスト 大規模カンファレンス「 」 学んだ3 こ https://tech.mercari.com/entry/2018/11/01/124027 
 人材育成問題 対し 
 • バグを「見 ける」から「作ら い」へ
 • 「やるこ 前倒し」 いうよ り
 「避けるため 活動」
 • hift eft(シフトレフト)する 場合、 うすれ いいか?

  42. 人材育成問題 対し 
 • 基本的 コンピュータサイエンス知識や
 プログラミングスキル
 • フェーズ 境目を超えた越境的スキル


    • 開発プロセス全般 かかわれるスキル
 ◦ テスト ごく一部 活動
 ◦ 自動化 ん あたりまえ
 プログラミングスキル より一般的 るが、書けるこ よりも、 うい た考え方 書く か い た部分が重要 くる。 
 た え 、 、テスト 開発 境目を越えた越境的 スキルを持 エンジニア も言える。 

  43. 立ち上げ
 • utomationありき いう名称 
 • 全員自動化
 • 開発プロセス全体 関わる


    QAエンジニアも自動化 挑み、SETもQA 挑む が全員自動化。そ 結果、テストフェーズ以外 部分 も関わ いく必要が くる。 参考:メルカリQA-SETチームが考え いるQAやテスト 未来 し https://tech.mercari.com/entry/2017/08/18/100138 

  44. 今
 and 
 or 
 only 
 も も 、SET組織(ここ

    Automation A) QA組織があ た AQAを立ち上げ。テスト 自動化 QA組織 密接 関わるため、わける 「他人事 りが ち」 を防ぎたか た。しかし、残念 がら今 メルカリ A QAが別れ あり、従来型 QA組織 逆戻りし しまいそう。 AQAを作り上げられ か た 無 念だが、誤解を恐れず 書く 、 QAエンジニア マインドセットを変える 相当難しい 学んだ。次も かいやる ら Aだけ チャレンジしたいかも。
  45. テストをする が い さ ん
 「テスト = い」をきちん 実践され おり「

    hift eft」 取り組まれ い 見習う点が も多い。 
 参考: 【 tech#6 】 あり方 https://www.slideshare.net/next_developer/ltech6-lifullqa 
 参考: 自動化 テスター撲滅 夢を見るか? a 語られたテスト 未来、品質 未来 # a https://daipresents.com/2019/automation-dream-of-tester-eradication/ 
 

  46. 自由主義を ら くユーザベースさん
 大企業病を避けるため 、徹底的 課題 取り組ん おり、社員 想像力を最大限 活かすため

    自由主義を実践され いる。こうい た 組織 し 姿勢が、「ピープル リソース問題」 かいけ へ が いく気がする。 
 参考:7 ルール | 株式会社ユーザベース | Z , nc. https://www.uzabase.com/company/seven-rules/ 

  47. 魅力的品質を目指す apan axiさん
 技術顧問 し サポート中。こ セッション テーマをも 、流行り 自動化

    飛 かず、自分たちがやるべきこ 何か?を考え がら 次世代 組織を立ち上げ中。参考: チームが取り組む魅力的品質へ チャレンジ https://blog.japantaxi.co.jp/2019/07/01/4193
 • を最近立ち上げ、 組織 くり中
 • 方針を決める き 「自 動テストを書くより、テ ストし くい環境を ん かする」を先 選んだ

  48. こ セッション ま め
 • フェーズやロール し テスト く、継 続的

    テストへ
 • マニュアル作業 自動化よりも、価値実現 ため 戦略的 自動化へ
 • リソース効率よりも
 シフトレフト きる人材へ