QA自動化プラットフォームが実現するDevTestOps - What is the DevTestOps and QA automation platform

A760a90c9afd981004343b9861f1e8b4?s=47 Dai FUJIHARA
February 18, 2020

QA自動化プラットフォームが実現するDevTestOps - What is the DevTestOps and QA automation platform

イベント発表資料。

今話題のQA自動化プラットフォームを活用してプロダクトの品質を向上させる事例が増えてきました。このセッションでは、QA自動化プラットフォームによってどう「DevTestOps」を実現していくのかを議論していきます。

https://mabl-japan.connpass.com/event/166229/

A760a90c9afd981004343b9861f1e8b4?s=128

Dai FUJIHARA

February 18, 2020
Tweet

Transcript

  1. QA自動化プラットフォーム が実現するDevTestOps Copyright © 1978-2019 Sekai Co., Ltd. All Rights

    Reserved. https://daipresents.com/service/ Dai FUJIHARA @daipresents
  2. 2 Dai FUJIHARA アジャイルコーチ 経験 ◦ 現在: フリーのアジャイルコーチ /EMとして活動中 ◦

    メルカリ: エンジニアリングマネージャ( EM)、Software Engineer in Test(SET) ◦ 楽天: EM、アジャイルコーチ ◦ 某SIer: Javaエンジニア 活動 ◦ 『アジャイル開発とスクラム』寄稿 ◦ 『リーン開発の現場』翻訳 ◦ 開発コンサルティング・技術顧問 • アジャイル開発チーム支援 • SET・QAチーム立ち上げ支援 • テスト自動化導入支援 • CTOやEMのコーチング ◦ https://daipresents.com/service/
  3. 1. なぜDevTestOps が必要なのか? 4

  4. 現状をとりまいているもの 5 アジャイル ・DevOps 時代に突入 タイムボックスのよるはやいリリースと フィードバック 漸進的(インクリメンタル) 正しいものを正しく作りたい アジャイル

    ・DevOpsを 支える 技術の進化 CI/CDサービスのコモディティ化 Docker, k8s の急速な広がり クラウド環境の繁栄 求められる アジャイル テスティング 従来からテストフェーズが ボトルネックになりがち アジャイルなテスティングの 事例不足・マニュアル依存
  5. 6 • プロセスはリリースで終わらない • それぞれの活動でテストは必須となり、誰もがテストに参加せざるをえない • 開発から運用のサイクルを安定・持続可能にするための「テスト」。これを DevTestOpsとここでは呼んでみましょう。

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

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

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

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

  10. 11 テスト自動化サービス比較(独断と偏見) サービス名 特徴 いいね! Mabl 2016年創業。『Agile Testing』のLisa Crispinが所 属。

    ・操作性がいい。 ・メールを挟んだテストができる。 ・開発スピードが早い Autify 2019年創業。日本で勢いのあ るテスティングプラットフォー ム。 ・見た目がわかりやすい。 ・TestRail連携など、ケース管理 ツール連携ができる。 Testim 2014年創業。大企業&グロー バル企業の利用事例が多い印 象。 ・やれることが一番多い(ように見え る) • どのサービスも「AIを生かした機能」はまだまだ発展途上な印象。より精度があがると格段に運用が楽になるはずなので超期待
  11. 規模にあわせて 作戦を選ぶ 品質組織づくり・自動化は組織やプロダクトの規模に依存する 12

  12. アクション 責任 メリット デメリット メモ 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・自動化)
  13. 3. 何を実現すべきか? 14

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

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

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

  17. 新しい問題:リードタイムが長くなります リリース 18 要件定義 設計 開発 before テ ス ト

    after リリー 開発 テスト ◦ 開発時間が増えるとより多くのバグが生まれやすくなり、開発に比例してテスト工数も増えます。 ◦ テストフェーズはボトルネックになりがちです。しかし、テストベンダーはテストフェーズに人を当てて稼ぐのは得意でも、テストフェーズを短くしたり、なくしてし まうのが苦手(イノベーションのジレンマ)、さらに、自動化スキル不足や関心のなさ(マニュアルテスト以外のテスト理解がない)が原因で改善が進みませ ん。 要件定 義 設計
  18. 新しい問題:責任が分断されます 19 問題: POやENGの時間がテストに取られている 解決案:テストフェーズを設置 結果: POやENGがテスト(品質)に責任を持たなくなりがち ◦ POがリリースするものをチェックしない ◦

    ENGが作ってテストせずQAにまるなげ 本来は・・・ ◦ PO: 受け入れテストを書くべき ◦ ENG: UTからE2Eレベルの確認をすべき ◦ QA: 特殊な問題以外は発見されないはず プロダクト 開発 テスト
  19. 誤解を恐れずに書くと、 QAを作ると、エンジニアのテスト作業が QAエンジニアの手に渡るだけ。一方はバ グを作り続け、一方は手動でテストし続ける負のサイクルが生まれる? 20 「QA」作ったら 品質のおわりのはじまり? 本当にほしいモノは QA組織ですか?

  20. バグというモグラを 時間をかけて じっくり丁寧に 手作業で 叩き続ける仕組みづくり (しかもお金を払って!) あなたが意思決定すべきこと 21 VS 価値を提供し続ける

    品質組織・開発組織 づくり
  21. 4. まとめ 22

  22. まとめ 23 • なぜ? ▪ そういう時代・状況 • どう? ▪ 実現したいことはなにか?

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

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

  25. 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/ からお気軽にどうぞ。