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

アジャイル・DevOps時代の テストと品質保証 (完全版) / Testing and Quality Assurance in Agile and DevOps Era

アジャイル・DevOps時代の テストと品質保証 (完全版) / Testing and Quality Assurance in Agile and DevOps Era

この10年は多くの変化がありました。

ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。

技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。

一方で、テストや品質保証はどのように変わってきたでしょうか?

私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX(デジタルトランスフォーメーション)」の影響か、 開発に速さがより求められるようになってきたように感じています。

そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。

このセッションでは、アジャイル・DevOps時代におけるテストと品質について、

- 現在
- 戦略と戦術
- 組織未来

のお話させていただきます。

そして特に、「テスト・品質保証」について、現状と課題や求められる要件を整理し、未来のあるべき姿を、議論したいと思います。

https://confengine.com/conferences/devopsdays-tokyo-2021/proposal/15151/devops

Dai Fujihara

April 15, 2021
Tweet

More Decks by Dai Fujihara

Other Decks in Programming

Transcript

  1. About Me 『アジャイル開発とスクラム』 https://www.amazon.co.jp/dp/4798129704/ 、『リーン開発の現場』 https://www.amazon.co.jp/dp/427406932X 藤原 大 / Dai

    Fujihara Japan Lead at mabl Inc. CEO at Sekai Co., Ltd. • 現在: 独立してスーパーアジャイルコーチ 開発組織の技術顧問(プロセス、 QA中心) CTOやEMへのコーチング mablの日本顧客向け業務全般担当 • メルカリ: エンジニアリングマネージャ( EM) Software Engineer in Test(SET) テスト自動化、QA組織立ち上げ • 楽天: EM、アジャイルコーチ • 某SIer: Javaエンジニア • 活動: ◦ 『アジャイル開発とスクラム』寄稿 ◦ 『リーン開発の現場』翻訳 ◦ Twitter: @daipresents ◦ https://daipresents.com/service/
  2. 現状をとりまいているもの アジャイル・DevOps時 代に突入 イテレーティブ&インクリメンタ ル すばやいリリースとフィードバッ ク 正しいものを正しく作りたい アジャイル・DevOpsを 支える技術の進化

    CI/CDサービスのコモディティ化 Docker, k8s の急速な広がり クラウド環境の繁栄 求められるアジャイルな テスト 従来からテストフェーズがボト ルネックになりがち アジャイルなテスティングの事 例不足・マニュアル依存 さてどうしよう?
  3. データ:短期間でのデプロイ回数が増加 2020 Testing in DevOps Benchmark Survey, mabl 年ごと Qごと

    月ごと 2週間ごと 週ごと 日ごと 日に何回も 1日ごと、1週間ごと、2週間ごとのリリースが急増
  4. データ:自動テスト vs マニュアルテスト 2020 Testing in DevOps Benchmark Survey, mabl

    機能テスト、システムテストなどはまだマニュアルが主流
  5. 継続的テストするしかない プログラム テスト & 自動化 インフラなどあらゆる開発アクティビティ デザイン スプリントレビュー スプリントプランニング ふりかえり

    スプリント ここでも テスト デ リ バ リ ! 仕様 設計 実装 テスト ここでも テスト ここでも テスト ここでも テスト たまに第三者検証 フェーズ
  6. テスト自動化のタイムライン例 キックオフと ゴール設定。 継続的にテスト作成 (10〜20件)。 不安定なテストの安 定化とリファクタリン グ。 継続的にテスト作成 (20〜〜50)。

    不安定なテストの安定化とリ ファクタリング。 テスト自動化ツールの セットアップ完了。 自動化基本トレーニング。 自動化応用トレーニン グ。 利用手順などの整備。 CI/CD統合。 まずはリリース前テス トやSTGデプロイタイミ ングで実行。 四半期レビュー 30日 60日 90日 成功に向けてテスト作成 の継続とメンテナンス。 APIテストへのカバレッジ 拡大(同時にリグレッショ ンテスト削減) はじめてのリグレッション テスト作成(まずは5〜10 件)。 通知設定。 定期実行の開始 。
  7. 計画は優先順位 『リーン開発の現場』 18.5 ステップ 3:優先順位をつけて並べ替える より • 目的ドリブン ◦ スモーク

    > リグレッション > API・・・と目的で 優先順位をつける ◦ リグレッションは細かく分ける ▪ ハッピーパス ▪ ハッピーパス+例外系 • データドリブン ◦ ユーザがよく行う行動をもとに優先順 位をつける • 価値ドリブン ◦ 機能や画面をお金に換算して優先順 位をつける • などなど テストケース リスク 手動テストの コスト 自動化 コスト 口座の凍結 高 5時間 0.5ポイント 振込の確認 高 3時間 1ポイント 取引履歴 中 3時間 1ポイント 検索結果の並べ替え 中 2時間 8ポイント お金の入金 高 1.5時間 1ポイント セキュリティアラート 高 1時間 13ポイント 新規ユーザー登録 低 0.5時間 3ポイント デザイン変更 低 0.5時間 20-ポイント
  8. テストピラミッドの呪いとの戦い方例 単体(UT) 機能 API ・IT 探索的 受け入れ リグレッショ ン(松) リグレッション

    (竹) リグレッション (梅) パフォーマンス・ セキュリティ 狙い プログラム レベル 機能レベル APIレベル / 統合レベ ル UI/UX、特 定機能集 中型 スプリントレ ビュー 全機能網 羅 全機能正常系 のみ網羅 最低限の機能 正常系のみ網 羅 特定観点のテ スト 種類 自動化 手動(でき れば自動 化) 自動化 手動 手動 自動化 自動化 自動化 自動化 いきなりUT増やすのがしん どければ、狭い範囲のリグ レッション( スモークテスト、 ここではリグレッション梅)か ら自動化をはじめるのが現 実的。 理想には ほど遠いけど・・・ UT API 徐々にUT/APIテストの数を増や してリグレッションの数を減らす。 粒度の細かいテストも増やしてい く。 梅 UTやAPIをコツコツ増やし、松竹梅の順で減らしていく。経 験的に松は作るのがしんどいので、竹梅だけ、もしくはリグ レッション全体の 20〜30%ぐらいの網羅性を目指せば十分 に思う。 UI UT API UT API リグレッション梅 UT API API リグレッション竹 UT リグレッション竹 リグレッション梅 リグレッション松 リグレッション梅 リグレッションもスコープを3 つぐらいに分け、粒度が荒い テストから実装ていくと失敗 しにくい。 メモ: テストピラミッドは上に行くほどスピードが遅く( FBサイクルが長い)、上に行くほどコストが高いが、 mablなどツールの進化でスピードは速くなり、コストは下がってきてい るので、テストピラミッドにしばられすぎず(それが呪い?)に理想を目指せばいいと思う。
  9. 継続的デリバリ 成熟モデルの活用 CD成熟モデル https://speakerdeck.com/daipresents/the-continuous-delivery-maturity-model-in-agile-and-devops 成熟度 テストのプラクティス Level 3 - 最適化:

    プロセス 改善に集中 本番でのロールバックがほとんどない。欠 陥が見つかってもすぐに Fixされる Level 2 - 定量的に管理: プロセ スは測定・管理されている 品質メトリクスとトレンドは追跡できている。 非機能要件も定義・測定できている Level 1 - 一貫性: アプリの開発 ライフサイクル全体に自動化が 適用されている 自動化されたUTとUATがありUATはテス ターが作成している。開発プロセスの一部 分がテストされている。 Level 0 - 繰り返し可能: プロセ スがドキュメント化・一部自動化 されている UTは自動化。ストーリーをもとにした開発 において部分的にテスト自動化できてい る。 Level -1 - 後退: プロセスは繰 り返せず管理もまだまだで後手 後手 開発後のマニュアルテスト。 DEV/STG/PROのように環境分離。 • Level -1 からLevel 3まで整理され ていてわかりやすい(情報はちょっ と古いかも知れないけど) • 自分たちがいまどういうレベルで、 自分たちが目指すゴールがどこ か。その道程はどういったものか がよくわかる • 地図があると改善は進みやすい
  10. テスト自動化設計 小さく、大量に、並列で • 機械は小さいものを大量に並列処理する のが得意 • ケースは5分以内。ステップ数は 25~50 以内 •

    共通部品を作る。2回やるなら部品にす る • 並列実行できるケースを作る(テストの独 立性) 昔 今 時間 並列数
  11. ベストプラクティス例: 部品の共通化 再利用!再利用!再利用! • 2回やることは部品(mablだと Flow)にする • Flowの引数を活用して汎用性を高 める •

    Flowをたくさん作ってつなげる • 部品を磨きつづける はじめは、大きく「処理」 「処理結果の確認」「遷 移」にわけて部品を作る のがおすすめ。
  12. 自動テストケース管理 Excel / Spreadsheet最強説 • 観点レベルで一覧化 ◦ 手動・自動まとめて管理 ◦ マニュアルケースは別Excelに作ってリン

    クする ◦ 自動テストもmablにリンクだけ ◦ 現時点でベストプラクティスだと思う • 機能別、優先度別、観点別でテストにラベリング
  13. Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む https://lean-trenches.com/scaling-agile-at-spotify-ja/ 組織も変わっていく QA iOS (現在から未来?)アジャイル型組織 チームでプロダクトへ Android

    Frontend Backend BI 上にマネージャがのっかれば 従来型のピラミッド型組織に近い どこに向かうチーム? QA iOS Android Frontend Backend BI ←職能横断的チーム。 チームごとの成熟度を 高く育てられる。チーム 間のコミュニケーション 問題をギルドや支部制 度で弱めている 職能ごと縦割り組織型 → 管理効率が高いが、プロ ジェクト制度だとチームの成 熟度が高まらない。サイロ 化、組織間コミュニケーショ ンの課題がなかなか解決し ない
  14. 開発チームに求められるスキルセット アジャイル開発・スクラムの 基礎知識 プロセス全体の品質に関わる QAエ ンジニアはスクラムマスターとの相 性がよい。 基本的なコンピュータ・サイエンス 知識があれば最高。 まずは「PRを読める」だけで十分。

    テスト自動化も含めたテスト 業務 テスト自動化戦略策定、テスト自動 化戦術の決定、テスト自動・・・・特 にCI/CD技術 「開発だけ」「テストだけ」「テスト自 動化だけ」ではもう足りない。 新しいキャリアへのチャンス。 境界を超えられるスキル 我々が欲しい人材はご意見番では なくて専門家。 設計フェーズ、開発フェーズ、テス トフェーズといった境界を超えて、 その先で価値提供できできる人。 継続的改善できる人。
  15. 来たるべき未来? 技術は進化をし続ける AI/MLが常識を変えていく。 • ペルソナを使った探索的テ スト自動化 • 自然言語でテストケース作 成 •

    ユーザ操作を学習してテスト 作成 などなどすでに実用段階 テストの民主化が進む • プロダクトチームに境界 は必要ない • テストやテスト以外もど んどん民主化が進む • 品質が人やフェーズで はなく活動になる スピードへの自動化(技術)投 資が増える • テスト自動化「だけ」、単純作 業をツールで楽する「だけ」 の価値や成果は小さい • 人や時間のコスト削減は品 質を上げる活動として弱い • デリバリスピードへの投資 に いきつく
  16. Thank you very much 月次ウェビナー開催中! 「探索的テスト」「テスト自動化」「次世代QA 組織」といったテーマをもとに「アジャイル ・DevOps時代のテストや品質保証」を目指 すウェブナーです。 今後も、さまざまなトピックや、その道のプロ

    フェッショナルにご登壇いただく予定です。 https://mabl-japan.connpass.com 今すぐできる2週間の無料トライアル! 「セッション見たよ」でさらに2週間(合計1ヶ月!) のトライアルプレゼント デモリクエストも大歓迎! 技術トレンドや実事例をまじえたデモMTGもお気 軽にどうぞ! https://www.mabl.com/japan