Slide 1

Slide 1 text

輝く未来を抱きしめ 
 アジャイル・ ev ps時代 
 品質組織 くり
 uly 25th 2019 検証フォーラム2019
 ai daipresents
 utomation & roup


Slide 2

Slide 2 text

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


Slide 3

Slide 3 text

こ セッション 質問疑問 もちろん。アジャイルテストや自動化 、気 るこ を気軽 聞ける場所を目指し いる。 参考: gile esting, utomation and 現場 − 参加者募集中! https://bit.ly/2 t7a 
 コミュニティ参加者400名近く


Slide 4

Slide 4 text

参考: https://about.mercari.com/ 


Slide 5

Slide 5 text

2017年頃
 ● 〜100人以下 開発組織
 ● 職能横断型チーム 開発
 ● エンジニアチーム く チーム あ た
 職能横断型チーム プロダクトマネージャ、i ng、 ndroid ng、 ng い た 必要 メンバーが参加し いる。 エンジ ニア 集まる「チーム」 、一時あ たけ 、当時 か た。


Slide 6

Slide 6 text

現在
 ● 「チーム」 消 滅。そ かわり横串 チーム 配置
 ● 自動化メイン チーム が きた
 ● テスト設計だけ、実行 だけする人 採用し い(職能横断チーム や いけ い)


Slide 7

Slide 7 text

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


Slide 8

Slide 8 text

アジャイル・ ev ps時代 
 品質組織 くり


Slide 9

Slide 9 text

今日、お しするこ 
 ● ぜ今 時代 あ た品質を
 考える か?
 ● うや 
 そ 品質を実現するか?
 ● 品質やテスト 未来 ?


Slide 10

Slide 10 text

用語をそろえ おきます
 ● テスター:テスト実行が主作業 人
 ● : 品質保証(名詞)。人 い
 ● エンジニア:品質保証活動全般 関わる人
 ● 自動化エンジニア・ ( oftware ngineer in est)
 ○ 自動テストやそ 実行環境を中心 エンジニア リング よ 品質課題を解決し いく人


Slide 11

Slide 11 text

用語をそろえ おきます
 ● リグレッションテスト:
 回帰テスト。ここ バグ発見 いうより
 「修正 他が壊れ い いか」をみるテスト 近い
 ● 単体テスト:
 小さいプログラムレベル テスト
 ● 機能テスト・結合テスト:
 バックエンド(マイクロサービスや 群) 
 連携テスト。ここ シンプル 区別し い
 ● 2 テスト:
 ebやアプリだ 画面を通したテスト


Slide 12

Slide 12 text

わたし 環境 前提条件
 ● スマホアプリや ebアプリ 
 ○ テスト自動化
 ○ / 構築
 ● 経験ベース 最適解
 (継続的インテグレション: ontinuous ntegration)、 (継続的デリバリ: ontinuous elivery)。世間 ontinuousブーム。


Slide 13

Slide 13 text

こ セッション 視点
 ● 非 エンジニア 視点
 ● プロダクト 
 価値があるか いか視点
 ● 多く 仮説を含む発表


Slide 14

Slide 14 text

ぜ今 時代 あ た 品質を考える か?

Slide 15

Slide 15 text

アジャイル・ ev ps
 時代 到来


Slide 16

Slide 16 text

参考: 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


Slide 17

Slide 17 text

参考: ソフトウェアテスト 大規模カンファレンス「 」 学んだ3 こ https://tech.mercari.com/entry/2018/11/01/124027 
 2018
 ● 継続的 統合
 ● 継続的 デリバリ
 ● よ 、継続的 テスト
 (テスティング)が必要
 ● 継続的テスティング ?
 ○ 何回も実行 きる
 ○ すぐ実行 きる
 ○ 安定し 実行される


Slide 18

Slide 18 text

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 へ キャリア変更事例が 人気
 ● まだテスター 死 いらしい


Slide 19

Slide 19 text

アジャイル・ ev ps時代 到来ま め
 ● プロセスが継続的 ループ構 へ
 ● テスト ロールや
 フェーズ く る
 ● 自動化 よ テスト 考え方が変 わ いく


Slide 20

Slide 20 text

うや そ 品質を 実現する か?

Slide 21

Slide 21 text

テスト自動化
 狭い意味だ テスト 自動化。広い意味だ 、コード 修正からテスト 自動実行ま 含んだビルドパイプライン 自動化 る。 
 


Slide 22

Slide 22 text

参考: ercari utomation & roup ntroduction https://speakerdeck.com/daipresents/mercari-automation-and-qa-group-introduction-2 
 テスト 戦略: そ 1
 ● じめやすく成果が わかりやすいリグ レッション
 ● 外 品質から中 品質へ
 作り込ん いく
 ● ng向け 
 自動化
 or ng
 or 
 or 


Slide 23

Slide 23 text

テスト 戦略: そ 2
 ● リグレッション 日々 機能テストをマージ し いくプロセスを作 る
 ● 定期的 リファクタリン グし大きく たり小さ く たりを繰り返す
 リグレッション
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト
 機能
 テスト


Slide 24

Slide 24 text

テスト 戦術(自動化)
 ndroid/i それぞれ100ケース(シナリオ形式)ぐらいを、2名1ヶ月 作りき 運用を開始。自動化 き いケース ブロッカー し 後回 し。現在 274ケースぐらいま 育 きた。規模 もよるがリグレッションテストケースがある らそれらを自動化 変換する 一気 やれ る技術スタックや環境が整 き いる 思う。 
 作戦名
 一気 やる
 (おすすめ)
 徐々 やる
 (一般的)
 メリット
 ● すぐ 効果が出る
 ● 低コスト
 デメリット
 ● 初期コスト大きい
 ● 最後ま あきらめ い気持ちが必要
 ● 時間がかかる
 ● モチベが続か い


Slide 25

Slide 25 text

ビルドパイプライン設計
 郡およ 開発環境 バックエンドシステム 
 スマホアプリ
 テストデータ作成基盤 
 (テスト用 郡)
 テスト結果データ基盤 
 ( est ail)
 テスト実行基盤
 ( ppium / ode)
 テストデータ作成
 テストコード 2 実行 よる
 アプリから 呼 出し 
 実行動画保存
 ログ保存
 テスト結果保存
 アプリ自動ビルド
 ( ircle )
 テスト対象作成


Slide 26

Slide 26 text

ビルド & テストデータ作成
 ● ビルド タイミング
 ○ 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 


Slide 27

Slide 27 text

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


Slide 28

Slide 28 text

テスト結果データ
 ● est ail 連携し リア ルタイム反映(人間より 賢く 正確)
 ● エビデンス
 ○ プログラマチェック用 スタックトレースも 添付
 ○ エンジニア向けテ スト実行動画も添付
 参考: 自動 2 テスト結果をビューティフル レポート ま め est ail連携し みた https://tech.mercari.com/entry/2018/06/07/142949 


Slide 29

Slide 29 text

参考:テスト結果分析
 ● ケース 紐付いた
 ○ 不安定さ 排除
 ○ バグ傾向 発見
 参考: 自動 2 テスト結果をビューティフル レポート ま め est ail連携し みた https://tech.mercari.com/entry/2018/06/07/142949 


Slide 30

Slide 30 text

自動化 ま め
 ● ここ リグレッションテスト
 から自動化
 ● 将来的 日々 機能テストも
 すぐ 自動化 きる体制を目指す
 ● ビルドパイプライン 設計が必要


Slide 31

Slide 31 text

テストや品質 未来

Slide 32

Slide 32 text

自動化ありき 
 品質保証
 自動化いがい これま 登場した課題が解決する らそれ もいい ず。ただし、 が自由自在 テストする未来 まだ先だ 思う。今 「やろう おもえ それ も きるけ 、欲しいも 程遠い」 ? 


Slide 33

Slide 33 text

a ’19
 誰もが変化を予想し いる。
 参考: 自動化 テスター撲滅 夢を見るか? a 語られたテスト 未来、品質 未来 # a https://daipresents.com/2019/automation-dream-of-tester-eradication/
 ● テスター 仕事 自 動化 よ 
 「置き換わら い」 答 えた人 
 0人


Slide 34

Slide 34 text

自動化ありき 品質保証
 ● 自動化ありき テスト計画
 ● 自動化ありき テスト設計
 ● 自動化ありき テスト実行
 ● 自動化ありき テスト・・・・


Slide 35

Slide 35 text

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


Slide 36

Slide 36 text

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


Slide 37

Slide 37 text

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


Slide 38

Slide 38 text

参考: テスト自動化 アプローチ
 今あるも を自動化し いくよりも、自動化ケースを先 作り上げ 、そこ 保証 き い部分を、手動ケース し 追加し くほうが効率がよい。 まり、 日々、更新され いくマニュアルケースを自動化 追いかけるよりも、自動化ファースト 作られたケースを元 、マニュアルケースを考える いう流れ る いうこ 。
 anual
 uto
 anual
 uto


Slide 39

Slide 39 text

参考: さよ らテストケース管理
 こん ち テストコード管理
 コード上 上記 よう ステップを記述 きる 、ここから 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

Slide 40

Slide 40 text

参考: 自動化ありき テスト実行
 ● 機械 
 ○ 疲れ い
 ○ 間違え い
 ○ モチベが下がら い


Slide 41

Slide 41 text

自動化ありき 品質保証ま め
 ● テスト計画から実行ま 
 自動化ありき 再考が必要
 ● テクノロジーを活用する
 新しいスキルが必要
 ● 新しいマインドセットも必要


Slide 42

Slide 42 text

見え いる課題 そ 対策

Slide 43

Slide 43 text

アジャイル
 難しい問題


Slide 44

Slide 44 text

海外だ 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
 ● スプリント・イテレーション わけたけ 
 結局 的 プロセス
 アジャイル難しい問題


Slide 45

Slide 45 text

アジャイル難しい問題
 ● 間違えやすいアジャイルそ 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 


Slide 46

Slide 46 text

アジャイル難しい問題 対し 
 テストがフェーズじゃ く る ら、同時実行 開発 テストを進め いく必要がある。
 上記図だ anban 考え方が近い。
 参考: アジャイル開発 現在・過去・未来~今を知り、源流を訪 、先を見据える~ https://www.slideshare.net/hiranabe/now-past-and-future-of-agile-development-and-xp


Slide 47

Slide 47 text

リソース ピープル
 問題


Slide 48

Slide 48 text

リソース VS ピープル問題
 ● 品質 相談を聞い みる ・・・
 ○ テスト工程を導入し 
 品質を高め いきたい
 ○ 品質を見える化したい
 ○ 人員を効率的 使いたい


Slide 49

Slide 49 text

ソリューション?
 ● 方法論化されたテスト手法や工程を導入!
 ● やるべきテストがテストフェーズ 
 移動しただけ
 ● 品質を可視化し 組織的 確認!
 ● 見える化 目的 ら い
 ● 管理体制を構築!
 ● えー 、結局人力?
 これだ バグ 見 かるかもしれ い(次ページも参照 こ )。ただし、やるこ が減ら いし、結局マンパワー ん かする形 りがち。だから、こういう提案をもら た場合 、「短期的 人が増える し 、そ 人を うや 減らす り生産性を高めま すか?」 聞い みる いいかも。考え いる企業 ら回答 きる。


Slide 50

Slide 50 text

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


Slide 51

Slide 51 text

リソース VS ピープル 対し 
 参考: 【16- -5】 アジャイルリーダーシップ 組織改革 ~楽天 アジャイル開発 いうリアル~ https://speakerdeck.com/daipresents/16-b-5 
 ● 自己組織化された チーム 
 ○ 自己解決 きる
 ○ 意思決定 きる
 ○ 自己管理 きる


Slide 52

Slide 52 text

人材育成問題


Slide 53

Slide 53 text

参考: よくある思考停止
 人間 しか き いこ 
 クリエイティブ 仕事をする
 、それ 何?
 耳障り 良いけ 思考停止し いるかもしれ い。 いうか何も答え い い(参考:『「超 時代」 働き方』 落合陽一)。 


Slide 54

Slide 54 text

参考: 自動化 テスター撲滅 夢を見るか?JaSST 語られたテスト 未来、品質 未来 #JaSST https://daipresents.com/2019/automation-dream-of-tester-eradication/ 人材育成問題 対し 


Slide 55

Slide 55 text

テストフェーズもテスターも エンジニアもボトルネック りえる。 うや 自分自身がボトルネック る を避け いくかが問われ いる。 
 参考: 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/ 
 ● 連続するサイクル
 ● テストが必要
 ● 誰もがテスト 
 かかわる
 
 これを実現する
 スキルが必要
 人材育成問題


Slide 56

Slide 56 text

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


Slide 57

Slide 57 text

人材育成問題 対し 
 ● 基本的 コンピュータサイエンス知識や
 プログラミングスキル
 ● フェーズ 境目を超えた越境的スキル
 ● 開発プロセス全般 かかわれるスキル
 ○ テスト ごく一部 活動
 ○ 自動化 ん あたりまえ
 プログラミングスキル より一般的 るが、書けるこ よりも、 うい た考え方 書く か い た部分が重要 くる。 
 た え 、 、テスト 開発 境目を越えた越境的 スキルを持 エンジニア も言える。 


Slide 58

Slide 58 text

未来 品質組織

Slide 59

Slide 59 text

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


Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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


Slide 62

Slide 62 text

自由主義を ら くユーザベースさん
 大企業病を避けるため 、徹底的 課題 取り組ん おり、社員 想像力を最大限 活かすため 自由主義を実践され いる。こうい た 組織 し 姿勢が、「ピープル リソース問題」 かいけ へ が いく気がする。 
 参考:7 ルール | 株式会社ユーザベース | Z , nc. https://www.uzabase.com/company/seven-rules/ 


Slide 63

Slide 63 text

魅力的品質を目指す apan axiさん
 技術顧問 し サポート中。こ セッション テーマをも 、流行り 自動化 飛 かず、自分たちがやるべきこ 何か?を考え がら 次世代 組織を立ち上げ中。参考: チームが取り組む魅力的品質へ チャレンジ https://blog.japantaxi.co.jp/2019/07/01/4193
 ● を最近立ち上げ、 組織 くり中
 ● 方針を決める き 「自 動テストを書くより、テ ストし くい環境を ん かする」を先 選んだ


Slide 64

Slide 64 text

アジャイル・ ev ps時代 
 品質組織 くり


Slide 65

Slide 65 text

こ セッション ま め
 ● フェーズやロール し テスト く、継 続的 テストへ
 ● マニュアル作業 自動化よりも、価値実現 ため 戦略的 自動化へ
 ● リソース効率よりも
 シフトレフト きる人材へ


Slide 66

Slide 66 text

バグ いうもぐらを
 丁寧 時間をかけ 
 手 叩き続ける
 組織 くり すか?

Slide 67

Slide 67 text

価値を提供し続ける 品質組織 くり すか?