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/

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

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. こ セッション ま め
 • フェーズやロール し テスト く、継 続的

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