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

by koppamijinko

Slide 1

Slide 1 text

Slido # 2223 118 コドモンのQAの今までとこれから -XPによる成長と見えてきた課題- JaSST ‘25 Tokyo 株式会社コドモン　砂川雅裕

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 ● 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜コドモン ● 趣味野球観戦、映画、旅行 ● 好きなテスト技法デシジョンテーブルテスト ● プライベートでは二児の父（男女の双子） ● 名前　砂川　雅裕　（すなかわ　まさひろ） ● SNS　X : koppamijinko 自己紹介

Slide 4

Slide 4 text

4 はじめに ● 私に関して ○ 開発ほぼ未経験でコドモンにジョインしたQAエンジニア (ソフトウェアテストに関する経験や知識はある) ○ コドモンに入る前はE2EテストやAPIテストを自学で勉強した経験あり ● 話すこと ○ QAとしてジョインし約2年間で、XPのプラクティスを実践して成長した点 ○ もっとこうしていく必要があると思い、QAエンジニアたちでやっていこうとしていること

Slide 5

Slide 5 text

コドモンについて

Slide 6

Slide 6 text

6 Mission

Slide 7

Slide 7 text

7 すべての先生に子どもと向き合う時間と心のゆとりをこんなプロダクトを開発していますメインプロダクトは、保育・教育施設向けWebアプリケーション。保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版アプリケーション、外部サービスと連携するAPIなども開発しています。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

コドモンの開発とQAに関して

Slide 10

Slide 10 text

10 コドモンの開発の変遷年代開発手法テスト・QAの様子創業〜2020.5 がむしゃら開発体系的なテストの整備がない 2020.5〜スクラム導入自前の自動テスト → Autifyで大枠のE2Eを整備 2021.5〜 XPをスモールスタートチーム内でのATDD、 TDDが波及 2021.秋ごろ〜 XPを全面展開

Slide 11

Slide 11 text

QAがXPのプラクティスをやってみた

Slide 12

Slide 12 text

12 ● サークルオブライフ by ロン・ジェフリーズ XPのプラクティスチーム全体受入テスト小さなリリース計画ゲーム継続的インテグレーションメタファー持続可能なペース共同所有テスト駆動開発シンプルな設計ペアリングリファクタリングビジネスプラクティスチームプラクティステクニカルプラクティス Robert C.Martin『Clean Agile 基本に立ち戻れ』 P.47

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

14 ペアプロ、テスト駆動開発（以下、TDD）

Slide 15

Slide 15 text

15 ペアプロ、TDD - 作業イメージ - チケットテストコード Red Green Refactoring 開発するユーザーストーリーのチケットをコードとしていくまでをエンジニアとペアを組んで対応した

Slide 16

Slide 16 text

16 ペアプロ、TDD - 1つ目の壁 - このストーリーのこの処理はリポジトリに修正を入れるやで！テストかこ？リポ...ジトリ...📂？とりまテスト書いておいたわ

Slide 17

Slide 17 text

17 ペアプロ、TDD - 1つ目の壁 - このストーリーのこの処理はレポジトリに修正を入れるやで！テストかこ？レポ...ジトリ...📂？とりまテスト書いておいたわ開発者の言っていることが理解できない！

Slide 18

Slide 18 text

18 ペアプロ、TDD - 1つ目の壁 - 　　　　DDDを勉強するといいよ！リポジトリってなんですか？ ⭐自分がわからないことをちゃんと聴いて勉強した ⭐ドメイン駆動設計のように、今の開発者がユビキタス言語としている内容を勉強することで、シンプルな設計を意識するようになった

Slide 19

Slide 19 text

19 ペアプロ、TDD - 2つ目の壁 - このストーリー、テストだけでどんだけ作ればいいんだ！テストだけじゃなくて、プロダクトコードも長くなってきたなぁ... チケットの切り方ミスったなぁ

Slide 20

Slide 20 text

20 ペアプロ、TDD - 2つ目の壁 - このストーリー、テストだけでどんだけ作ればいいんだ！テストだけじゃなくて、プロダクトコードも長くなってきたなぁ... チケットの切り方ミスったなぁチケットのストーリーが大きすぎる

Slide 21

Slide 21 text

21 ペアプロ、TDD - 2つ目の壁 - このストーリー、XXXな体験まで含めるとちょっとポイント超えそうじゃない？一旦テストある部分だけは、実装進めようか。その分の品質をあげてこ ⭐ユーザーストーリーがどうしても大きくなる場合は、チケットの内容を見直して、チケットの内容を分解して、デプロイ → 小さなリリースの体現 ⭐どうしても溢れてしまいそうな仕様や機能が出てきた時は、チームで話しあい → スコープやリリース日を調整して持続可能なペースを維持

Slide 22

Slide 22 text

22 受け入れテスト

Slide 23

Slide 23 text

23 受け入れテスト - 作業イメージ - プロダクトマネージャー (PdM) プロダクトデザイナー (PD) QAエンジニア・開発しているシステムの要求、仕様に最も敏感・そのシステムの最も売りとなる部分を一番熟知している・テストケースを率先して書いてきた経験が少ない支援して、テストケースを作成＝受け入れテスト

Slide 24

Slide 24 text

24 “受け入れテスト”の正体をつかむまで ● 当初の受け入れテストチケットテスト受入条件・ユーザー操作の事後条件でXXXであること・ただし、YYYな時はXXXとならないテスト・ユーザーが操作できる。その後のhoge のデータはXXXとなっている・YYYな時は、400 エラーになり、

Slide 25

Slide 25 text

25 “受け入れテスト”の正体をつかむまで ● しかし、開発終盤... QAが作ったテストケースを行うと、基本的なところでバグが出るなぁ... 👿ストーリー開発時のテストは全部PASSなのに、なぜかバグが出る 👿マイクロサービスのサービスを跨いだ例外フローで致命的なバグが出る etc… ⭐ストーリーやサービスを跨いだシステムの挙動に対して、守るためのテストを準備することが必要

Slide 26

Slide 26 text

26 “受け入れテスト”がどういうものか定義した ● XPにおけるテストの性質の違いを再整理した by QA 　　　 TDD 　　　受け入れテストストーリーを実装するために作るテスト基本的には、エンジニア自身がストーリーを完遂するために、 Checkingとしてのテストが出来上がる PdMやPDが仕様として守りたいものを確認するテストビジネスサイドが仕様として守りたい機能をピックアップして、システム全体の妥当性確認に観点を置いている ⚠ストーリーの受入基準がPASSするためのテスト ↓ 💡ビジネスサイドがシステムが求められている要求や絶対に起こしてはいけない致命的バグが起きないかCheckするためのテスト

Slide 27

Slide 27 text

27 継続的インテグレーション(CI)

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 継続的インテグレーション(CI) - テスト自動化するには？ - テストコードビルドデプロイテストテストリリースリリースまでの一連のワークフローが必要 Github Actions でテスト＋リリースが可能なワークフローを構築 (エンジニアと一緒に)

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

35 副次的に他のプラクティスにも触れることになったチーム全体受入テスト小さなリリース計画ゲーム継続的インテグレーションメタファー持続可能なペース共同所有テスト駆動開発シンプルな設計ペアリングリファクタリングビジネスプラクティスチームプラクティステクニカルプラクティス

Slide 36

Slide 36 text

XPをやってきたことで QAが感じる組織の伸び代

Slide 37

Slide 37 text

37 XPのプラクティスで守れるところは限定的...？ DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ TDDで作ったテスト * CI 受け入れテスト * CI

Slide 38

Slide 38 text

38 XPのプラクティスで守れるところは限定的...？テスト環境が必要この部分のテストがまだまだ DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

Slide 39

Slide 39 text

39 XPのプラクティスで守れるところは限定的...？テスト環境が必要この部分のテストがまだまだチーム全体で守っていく必要がある DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

Slide 40

Slide 40 text

40 XPにおいて、QAの役割は明記されている『エクストリームプログラミング第2版』(第10章 XPチーム全体) ・XPチームのテスターは、システムレベルの自動テストの選択や　記述について開発前に顧客を支援したり、プログラマーに　テスト技法をコーチしたりする

Slide 41

Slide 41 text

41 QAがこれからチームに貢献していきたいこと『エクストリームプログラミング第2版』(第10章 XPチーム全体) ・XPチームのテスターは、システムレベルの自動テストの選択や　記述について開発前に顧客を支援したり、プログラマーに　テスト技法をコーチしたりする　👉今あるテストの質をコーチングによって高めていく

Slide 42

Slide 42 text

42 QAがこれからチームに貢献していきたいこと『エクストリームプログラミング第2版』(第10章 XPチーム全体) ・テスターはそうした「ハッピーパス」を視野に入れながら、　そこから外れたときに何が起きるかを質問するのが得意である・テスターがコミュニケーションを増幅する役割を担っている

Slide 43

Slide 43 text

43 QAがこれからチームに貢献していきたいこと『エクストリームプログラミング第2版』(第10章 XPチーム全体) ・テスターはそうした「ハッピーパス」を視野に入れながら、　そこから外れたときに何が起きるかを質問するのが得意である・テスターがコミュニケーションを増幅する役割を担っている　👉シフトレフトをしてPLANのテストを　👉シフトライトをしてもっとOPERATEやMONITORに力を

Slide 44

Slide 44 text

44 もう一つしていきたいこと

Slide 45

Slide 45 text

45 もう一歩踏み込んで、品質を考えるフェーズがやってきた ※本人の許可をいただいております

Slide 46

Slide 46 text

46 もう一歩踏み込んで、品質を考えるフェーズがやってきた ※本人の許可をいただいておりますコドモン＝子どもを取り巻く環境のインフラとした時に、プロダクト品質だけでなく、サービス品質をみんなで考えていく時がきた ⭐QAは、みんなが品質を考えていくためには何ができるかという側面でも貢献していきたい

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

48 全体のまとめ ● QAがXPのプラクティスに乗っ取った関わり方をすることで、エンジニアにより身近な存在として認知されるようになってきた ● しかし、QAとしてのスペシャリティを発揮した関わり方ではなかったので、今後はもう少しスペシャリティをあげて、開発者と関わる必要が出てきたと感じている ● プロダクトの成長に対して、社会的責任が大きくなってきた。全員でサービスの品質を維持・向上していくために、QAとして何ができるか再考していきたい

Slide 49

Slide 49 text

最後に

Slide 50

Slide 50 text

50 コドモン採用ページコドモンでは一緒に働きたい仲間を募集しています！開発チームX

Slide 51

Slide 51 text

ご清聴ありがとうございました