Tweet
Tweet

Slide 1

Slide 1 text

QA自動化プラットフォーム が実現するDevTestOps Copyright © 1978-2019 Sekai Co., Ltd. All Rights Reserved. https://daipresents.com/service/ Dai FUJIHARA @daipresents

Slide 2

Slide 2 text

2 Dai FUJIHARA アジャイルコーチ 経験 ○ 現在： フリーのアジャイルコーチ /EMとして活動中 ○ メルカリ： エンジニアリングマネージャ（ EM)、Software Engineer in Test（SET) ○ 楽天： EM、アジャイルコーチ ○ 某SIer： Javaエンジニア 活動 ○ 『アジャイル開発とスクラム』寄稿 ○ 『リーン開発の現場』翻訳 ○ 開発コンサルティング・技術顧問 ● アジャイル開発チーム支援 ● SET・QAチーム立ち上げ支援 ● テスト自動化導入支援 ● CTOやEMのコーチング ○ https://daipresents.com/service/

Slide 3

Slide 3 text

1. なぜDevTestOps が必要なのか？ 4

Slide 4

Slide 4 text

現状をとりまいているもの 5 アジャイル ・DevOps 時代に突入 タイムボックスのよるはやいリリースと フィードバック 漸進的（インクリメンタル） 正しいものを正しく作りたい アジャイル ・DevOpsを 支える 技術の進化 CI/CDサービスのコモディティ化 Docker, k8s の急速な広がり クラウド環境の繁栄 求められる アジャイル テスティング 従来からテストフェーズが ボトルネックになりがち アジャイルなテスティングの 事例不足・マニュアル依存

Slide 5

Slide 5 text

6 ● プロセスはリリースで終わらない ● それぞれの活動でテストは必須となり、誰もがテストに参加せざるをえない ● 開発から運用のサイクルを安定・持続可能にするための「テスト」。これを DevTestOpsとここでは呼んでみましょう。

Slide 6

Slide 6 text

2. どうDevTestOps を実現するか？ 7

Slide 7

Slide 7 text

QA自動化プラットフォー ムの登場 8

Slide 8

Slide 8 text

9 プラットフォーム活用のメリット

Slide 9

Slide 9 text

10 プラットフォーム活用のメリット 気にしない 気にしない 気にしない QAツール ・ テストAPI

Slide 10

Slide 10 text

11 テスト自動化サービス比較（独断と偏見） サービス名 特徴 いいね！ Mabl 2016年創業。『Agile Testing』のLisa Crispinが所 属。 ・操作性がいい。 ・メールを挟んだテストができる。 ・開発スピードが早い Autify 2019年創業。日本で勢いのあ るテスティングプラットフォー ム。 ・見た目がわかりやすい。 ・TestRail連携など、ケース管理 ツール連携ができる。 Testim 2014年創業。大企業＆グロー バル企業の利用事例が多い印 象。 ・やれることが一番多い（ように見え る） ● どのサービスも「AIを生かした機能」はまだまだ発展途上な印象。より精度があがると格段に運用が楽になるはずなので超期待

Slide 11

Slide 11 text

規模にあわせて 作戦を選ぶ 品質組織づくり・自動化は組織やプロダクトの規模に依存する 12

Slide 12

Slide 12 text

アクション 責任 メリット デメリット メモ QA部分を外注 （特殊領域の外注） 外部テストベン ダーなど ・お金で解決（短期なら効果的） ・QAエンジニアの育成やキャリア、評価に悩まな くていい（エンジニア部分に集中できる ・お金コストが増える（知識や経験が 残らないので投資にならない） ・人の質が悪い場合、管理コストが逆 にかかる ・各種大手企業によくある形 （楽天、Line、Yahoo、 DeNAなど） 自前でQA・SET組 織を作る 自社QA・SET ・自社エンジニアと密なコミュニケーションがとれ る ・ゴール設定できるためコミットメントさせやすい ・お金コスト増える（投資になるけど） ・職能が増える分、採用・育成・評価と いった運用が増える ・その職能のマネジメントも必要にな る ・メルカリ、Line、ライフル、 freee、カオナビ、メドピア、ト レタ、エムスリーなどなど激増 中 PO・ENG主体の 品質保証体制 自社エンジニア ・POが受け入れテストに責任を持つ ・エンジニア側でテストもカバーするので品質が 作り込まれる ・アジャイルテスティングの実現が可能 ・開発スピードが多少落ちる（ 20％ぐ らい） ・テストの負担が辛くなりがち ・楽天トラベル、クックパッドな ど PO・ENG主体の 品質保証体制 + テ スティングサービス の利用 自社エンジニア ＋ サービスの 活用 ・POが受け入れテストに責任を持つ ・エンジニア側でテストもカバーするので品質の 作り込みが可能に ・自動化テスト基盤の構築がいらない（クロスブラ ウザ・レポーティングなど） ・開発スピードが多少落ちる（ 20％ぐ らい） ・ベンダーロックがかかる（ケースの Exportできないものもある） ・mabl, testim, autify な どを活用した企業が増えてい る 13 アクションプラン例（QA・自動化）

Slide 13

Slide 13 text

3. 何を実現すべきか？ 14

Slide 14

Slide 14 text

“ QAプロセスを導入したい QA組織を作りたい 自動化を進めたい 15

Slide 15

Slide 15 text

“ 属人性の排除、方法論、テスト手法 品質の可視化、アドホックテスト 探索的テスト、管理者 16 なんて言葉が提案資料に並んでいたら要注意。答えもアイデアもないテストベンダーは「一緒に考えていき ましょう」なんてことも言ったり。お金を払ってまでして学ぶ機会を外に提供したいですか？

Slide 16

Slide 16 text

解決できない かもしれません 17 なぜなら、テストフェーズを増やしても品質 は良くならないし、そもそも「テスト ＝ 品質」 「テスト ＝ QA」ではないからです。

Slide 17

Slide 17 text

新しい問題：リードタイムが長くなります リリース 18 要件定義 設計 開発 before テ ス ト after リリー 開発 テスト ○ 開発時間が増えるとより多くのバグが生まれやすくなり、開発に比例してテスト工数も増えます。 ○ テストフェーズはボトルネックになりがちです。しかし、テストベンダーはテストフェーズに人を当てて稼ぐのは得意でも、テストフェーズを短くしたり、なくしてし まうのが苦手（イノベーションのジレンマ）、さらに、自動化スキル不足や関心のなさ（マニュアルテスト以外のテスト理解がない）が原因で改善が進みませ ん。 要件定 義 設計

Slide 18

Slide 18 text

新しい問題：責任が分断されます 19 問題： POやENGの時間がテストに取られている 解決案：テストフェーズを設置 結果： POやENGがテスト（品質）に責任を持たなくなりがち ○ POがリリースするものをチェックしない ○ ENGが作ってテストせずQAにまるなげ 本来は・・・ ○ PO： 受け入れテストを書くべき ○ ENG： UTからE2Eレベルの確認をすべき ○ QA： 特殊な問題以外は発見されないはず プロダクト 開発 テスト

Slide 19

Slide 19 text

誤解を恐れずに書くと、 QAを作ると、エンジニアのテスト作業が QAエンジニアの手に渡るだけ。一方はバ グを作り続け、一方は手動でテストし続ける負のサイクルが生まれる？ 20 「QA」作ったら 品質のおわりのはじまり？ 本当にほしいモノは QA組織ですか？

Slide 20

Slide 20 text

バグというモグラを 時間をかけて じっくり丁寧に 手作業で 叩き続ける仕組みづくり （しかもお金を払って！） あなたが意思決定すべきこと 21 VS 価値を提供し続ける 品質組織・開発組織 づくり

Slide 21

Slide 21 text

4. まとめ 22

Slide 22

Slide 22 text

まとめ 23 ● なぜ？ ■ そういう時代・状況 ● どう？ ■ 実現したいことはなにか？ ● なに？ ■ 作らず使いこなすのもひとつの手

Slide 23

Slide 23 text

“ AIは既存の社会システムと経済システムを完全に破壊し 何十億という人を労働市場から押し出して 大量の「役立たず階級」を創出する可能性があります。 −−『未来を読む』『サピエンス全史』のノア・ハラリ氏の言葉 24

Slide 24

Slide 24 text

“ デジタル経済とは何か。自分の働く領域において、 「規模の経済」を築く方法を見つけなければならない、 ということです。 −−『未来を読む』経済学者ダニエル・コーエン氏の言葉 25

Slide 25

Slide 25 text

26 CREDITS - Special Thank! ○ 『アジャイル開発とスクラム ~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント』（ https://www.amazon.co.jp/dp/4798129704/ ） ○ 『リーン開発の現場 カンバンによる大規模プロジェクトの運営』（ https://www.amazon.co.jp/dp/427406932X/ ） ○ Photo by Franck V. on Unsplash ○ ビルドパイプライン概要 - ベリサーブナビ 2019年12月号 https://www.veriserve.co.jp/asset/approach/veri-navi/ ○ mabl : https://www.mabl.com/ ○ Continuous Testing in DevOps… https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ ○ Willi Heidelbach - Passt 2 https://flic.kr/p/7P6oZm ○ Dustin Gaffke - Spiral Staircase ~ Arc de Triomphe https://flic.kr/p/m5P8xb ○ Presentation template by SlidesCarnival and Photographs by Unsplash アジャイルテスティング・自動化のご相談・お問い合わせは https://daipresents.com/service/ からお気軽にどうぞ。