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

コドモンのQAの今までとこれから -XPによる成長と見えてきた課題-

コドモンのQAの今までとこれから -XPによる成長と見えてきた課題-

2025/03/28 JaSST'25 Tokyo で発表した資料です

koppamijinko

March 27, 2025
Tweet

More Decks by koppamijinko

Other Decks in Technology

Transcript

  1. 2 CONFIDENTIAL - © 2025 CoDMON Inc. AGENDA • コドモンの開発とQAに関して

    • QAがXPのプラクティスをやってみた • XPをやってきたことでQAが感じる組織の伸び代
  2. 3 • 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023

    第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 • 好きなテスト技法 デシジョンテーブルテスト • プライベートでは二児の父(男女の双子) • 名前 砂川 雅裕  (すなかわ まさひろ) • SNS X : koppamijinko 自己紹介
  3. 4 はじめに • 私に関して ◦ 開発ほぼ未経験でコドモンにジョインしたQAエンジニア (ソフトウェアテストに関する経験や知識はある) ◦ コドモンに入る前はE2EテストやAPIテストを自学で 勉強した経験あり

    • 話すこと ◦ QAとしてジョインし約2年間で、XPのプラクティスを実践して 成長した点 ◦ もっとこうしていく必要があると思い、QAエンジニアたちで やっていこうとしていること
  4. 8

  5. 10 コドモンの開発の変遷 年代 開発手法 テスト・QAの様子 創業〜2020.5 がむしゃら開発 体系的なテストの 整備がない 2020.5〜

    スクラム導入 自前の自動テスト → Autifyで大枠のE2Eを整備 2021.5〜 XPをスモールスタート チーム内でのATDD、 TDDが波及 2021.秋ごろ〜 XPを全面展開
  6. 12 • サークルオブライフ by ロン・ジェフリーズ XPのプラクティス チーム全体 受入テスト 小さなリリース 計画ゲーム

    継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス Robert C.Martin『Clean Agile 基本に立ち戻れ』 P.47
  7. 13 特にお話をするプラクティス チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な

    ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス Robert C.Martin『Clean Agile 基本に立ち戻れ』 P.47
  8. 15 ペアプロ、TDD - 作業イメージ - チケット テスト コード Red Green

    Refactoring 開発するユーザーストーリーの チケットをコードとしていく までをエンジニアとペアを組んで対応した
  9. 21 ペアプロ、TDD - 2つ目の壁 - このストーリー、XXXな体験まで 含めるとちょっとポイント超えそう じゃない? 一旦テストある部分だけは、 実装進めようか。

    その分の品質をあげてこ ⭐ユーザーストーリーがどうしても大きくなる場合は、チケットの内容を 見直して、チケットの内容を分解して、デプロイ → 小さなリリースの体現 ⭐どうしても溢れてしまいそうな仕様や機能が出てきた時は、チームで話しあい → スコープやリリース日を調整して持続可能なペースを維持
  10. 23 受け入れテスト - 作業イメージ - プロダクト マネージャー (PdM) プロダクト デザイナー

    (PD) QAエンジニア ・開発しているシステムの要求、 仕様に最も敏感 ・そのシステムの最も売りとなる 部分を一番熟知している ・テストケースを率先して 書いてきた経験が少ない 支援して、 テストケースを作成 =受け入れテスト
  11. 24 “受け入れテスト”の正体をつかむまで • 当初の受け入れテスト チケット テスト 受入条件 ・ユーザー操作の事 後条件でXXXである こと

    ・ただし、YYYな時 はXXXとならない テスト ・ユーザーが操作で きる。その後のhoge のデータはXXXと なっている ・YYYな時は、400 エラーになり、
  12. 26 “受け入れテスト”がどういうものか定義した • XPにおけるテストの性質の違いを再整理した by QA     TDD     受け入れ

    テスト ストーリーを実装するために作るテスト 基本的には、エンジニア自身がストーリーを完遂するために、 Checkingとしてのテストが出来上がる PdMやPDが仕様として守りたいものを確認するテスト ビジネスサイドが仕様として守りたい機能をピックアップして、 システム全体の妥当性確認に観点を置いている ⚠ストーリーの受入基準がPASSするためのテスト ↓ 💡ビジネスサイドがシステムが求められている要求や絶対に起こしては いけない致命的バグが起きないかCheckするためのテスト
  13. 28 継続的インテグレーション(CI) - 作業イメージ - テスト コード ビルド デプロイ テスト

    テスト ・TDDや受け入れテストで作ったテストをリリースする度に自動テストとして実施する ・自動テストがFAILするとリリースができないようにしている=バグを出さない! リリース
  14. 29 継続的インテグレーション(CI) - テスト自動化するには? - テスト コード ビルド デプロイ テスト

    テスト リリース TDD、ペアプロの中で 作っていくスキルは身についた PdM、PDと一緒に テストを作っている
  15. 30 継続的インテグレーション(CI) - テスト自動化するには? - テスト コード ビルド デプロイ テスト

    テスト リリース TDD、ペアプロの中で 作っていくスキルは身についた PdM、PDと一緒に テストを作っている 「継続的に」「自動で」 テストをする仕組みをちゃんと 理解できていなかった
  16. 31 継続的インテグレーション(CI) - テスト自動化するには? - テスト コード ビルド デプロイ テスト

    テスト リリース テスト環境が 必要 CIと相性のいいツール でテスト環境を構築 (エンジニアと一緒に)
  17. 32 継続的インテグレーション(CI) - テスト自動化するには? - テスト コード ビルド デプロイ テスト

    テスト リリース リリースまでの 一連のワークフローが必要 Github Actions で テスト+リリースが 可能なワークフローを構築 (エンジニアと一緒に)
  18. 33 XPの中で成長した点まとめ • ペアプロ、TDD ◦ エンジニアと一緒にペアで作業することでコードだけでなく、 シンプルな設計まで身についてきた ◦ エンジニアがやりやすいタスクの粒度がわかり、より目線が揃 いやすくなってきた

    • 受け入れテスト ◦ 受け入れテストのあり方を再整理して、ビジネスサイドの視点 を受け入れることができた • CI ◦ テストを回し続ける基盤をエンジニアと一緒に構築した
  19. 34 XPの中で成長した点まとめ • ペアプロ、TDD ◦ エンジニアと一緒にペアで作業することでコードだけでなく、 シンプルな設計まで身につけた ◦ エンジニアがやりやすいタスクの粒度がわかり、より目線が揃 いやすくなってきた

    • 受け入れテスト ◦ 受け入れテストのあり方を再整理して、ビジネスサイドの視点 を受け入れることができた • CI ◦ テストを回し続ける基盤をエンジニアと一緒に構築した チームで開発するために、 柔軟に動くことができるスキルが 全体的に身につけることができたと実感
  20. 35 副次的に他のプラクティスにも触れることになった チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な

    ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス