コドモンのQAの今までとこれから / Codmon's QA Journey

by コドモン開発チーム

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テストを自学で勉強した経験あり ● アジャイル開発との関わり ○ スクラムは経験したことがあるが、 XPについては書籍を読んだことがある程度

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 XPの概要 Wikipedia よりエクストリーム・プログラミング、XP（英: extreme programming）は、ソフトウェア品質を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。 XPをより知りたい方は、こちらの本をご一読ください

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

14 特にお話をするプラクティスチーム全体受入テスト小さなリリース計画ゲーム継続的インテグレーションメタファー持続可能なペース共同所有テスト駆動開発シンプルな設計ペアリングリファクタリングビジネスプラクティスチームプラクティステクニカルプラクティス

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 受け入れテスト

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

最後に

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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