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

Transcript

1. Slido # 2223 118 コドモンのQAの今までとこれから -XPによる成長と見えてきた課題- JaSST ‘25 Tokyo 株式会社コドモン　砂川雅裕
2. 2 CONFIDENTIAL - © 2025 CoDMON Inc. AGENDA • コドモンの開発とQAに関して • QAがXPのプラクティスをやってみた • XPをやってきたことでQAが感じる組織の伸び代
3. 3 • 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 • 好きなテスト技法 デシジョンテーブルテスト • プライベートでは二児の父（男女の双子） • 名前　砂川　雅裕 　（すなかわ　まさひろ） • SNS　X : koppamijinko 自己紹介
4. 4 私に関する追加情報(コドモンジョイン前) • 開発経験 ◦ ほぼ未経験でコドモンにジョインしたQAエンジニア (ソフトウェアテストに関する経験や知識はある) • 自動テスト ◦ コドモンに入る前はE2EテストやAPIテストを自学で 勉強した経験あり • アジャイル開発との関わり ◦ スクラムは経験したことがあるが、 XPについては書籍を読んだことがある程度
5. コドモンについて
6. 6 Mission
7. 7 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
9. コドモンの開発とQAに関して
10. 10 コドモンの開発の変遷 年代 開発手法 テスト・QAの様子 創業〜2020.5 がむしゃら開発 体系的なテストの 整備がない 2020.5〜 スクラム導入 自前の自動テスト → Autifyで大枠のE2Eを整備 2021.5〜 XPをスモールスタート チーム内でのATDD、 TDDが波及 2021.秋ごろ〜 XPを全面展開
11. QAがXPのプラクティスを やってみた
12. 12 XPの概要 Wikipedia より エクストリーム・プログラミング、XP（英: extreme programming）は、 ソフトウェア品質 を向上させ、変化する顧 客の要求への対応力を高めることを目的としたソフトウェア開発 プロセスである。アジャイルソフトウェア開発の一つとして、短 い開発サイクルで頻繁に「リリース」することを推奨すること で、生産性を向上させ、新しい顧客の要求を採用するための チェックポイントを導入することを意図している。 XPをより知りたい方は、 こちらの本をご一読ください
13. 13 • サークルオブライフ by ロン・ジェフリーズ XPのプラクティス チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス Robert C.Martin『Clean Agile 基本に立ち戻れ』 P.47
14. 14 特にお話をするプラクティス チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス
15. 15 ペアプロ、テスト駆動開発（以下、TDD）
16. 16 ペアプロ、TDD - 作業イメージ - チケット テスト コード Red Green Refactoring 開発するユーザーストーリーの チケットをコードとしていく までをエンジニアとペアを組んで対応した
17. 17 ペアプロ、TDD - 1つ目の壁 - このストーリーのこの処理は リポジトリに修正を入れるやで！ テストかこ？ リポ...ジトリ...📂？ とりまテスト書いておいたわ
18. 18 ペアプロ、TDD - 1つ目の壁 - このストーリーのこの処理は レポジトリに修正を入れるやで！ テストかこ？ レポ...ジトリ...📂？ とりまテスト書いておいたわ 開発者の 言っていることが 理解できない！
19. 19 ペアプロ、TDD - 1つ目の壁 - 　　　　DDDを勉強するといいよ！ リポジトリってなんですか？ ⭐自分がわからないことをちゃんと聴いて勉強した ⭐ドメイン駆動設計のように、今の開発者がユビキタス言語としている内容を 勉強することで、シンプルな設計を意識するようになった
20. 20 ペアプロ、TDD - 2つ目の壁 - このストーリー、テストだけで どんだけ作ればいいんだ！ テストだけじゃなくて、プロダクト コードも長くなってきたなぁ... チケットの切り方ミスったなぁ
21. 21 ペアプロ、TDD - 2つ目の壁 - このストーリー、テストだけで どんだけ作ればいいんだ！ テストだけじゃなくて、プロダクト コードも長くなってきたなぁ... チケットの切り方ミスったなぁ チケットの ストーリーが 大きすぎる
22. 22 ペアプロ、TDD - 2つ目の壁 - このストーリー、XXXな体験まで 含めるとちょっとポイント超えそう じゃない？ 一旦テストある部分だけは、 実装進めようか。 その分の品質をあげてこ ⭐ユーザーストーリーがどうしても大きくなる場合は、チケットの内容を 見直して、チケットの内容を分解して、デプロイ → 小さなリリースの体現 ⭐どうしても溢れてしまいそうな仕様や機能が出てきた時は、チームで話しあい → スコープやリリース日を調整して持続可能なペースを維持
23. 23 受け入れテスト
24. 24 受け入れテスト - 作業イメージ - プロダクト マネージャー (PdM) プロダクト デザイナー (PD) QAエンジニア ・開発しているシステムの要求、 仕様に最も敏感 ・そのシステムの最も売りとなる 部分を一番熟知している ・テストケースを率先して 書いてきた経験が少ない 支援して、 テストケースを作成 ＝受け入れテスト
25. 25 “受け入れテスト”の正体をつかむまで • 当初の受け入れテスト チケット テスト 受入条件 ・ユーザー操作の事 後条件でXXXである こと ・ただし、YYYな時 はXXXとならない テスト ・ユーザーが操作で きる。その後のhoge のデータはXXXと なっている ・YYYな時は、400 エラーになり、
26. 26 “受け入れテスト”の正体をつかむまで • しかし、開発終盤... QAが作ったテストケースを行う と、基本的なところでバグが 出るなぁ... 👿ストーリー開発時のテストは全部PASSなのに、なぜかバグが出る 👿マイクロサービスのサービスを跨いだ例外フローで致命的なバグが出る etc… ⭐ストーリーやサービスを跨いだシステムの挙動に対して、守るためのテストを 準備することが必要
27. 27 “受け入れテスト”がどういうものか定義した • XPにおけるテストの性質の違いを再整理した by QA 　　　 TDD 　　　 受け入れ テスト ストーリーを実装するために作るテスト 基本的には、エンジニア自身がストーリーを完遂するために、 Checkingとしてのテストが出来上がる PdMやPDが仕様として守りたいものを確認するテスト ビジネスサイドが仕様として守りたい機能をピックアップして、 システム全体の妥当性確認に観点を置いている ⚠ストーリーの受入基準がPASSするためのテスト ↓ 💡ビジネスサイドがシステムが求められている要求や絶対に起こしては いけない致命的バグが起きないかCheckするためのテスト
28. 28 継続的インテグレーション(CI)
29. 29 継続的インテグレーション(CI) - 作業イメージ - テスト コード ビルド デプロイ テスト テスト ・TDDや受け入れテストで作ったテストをリリースする度に自動テストとして実施する ・自動テストがFAILするとリリースができないようにしている＝バグを出さない！ リリース
30. 30 継続的インテグレーション(CI) - テスト自動化するには？ - テスト コード ビルド デプロイ テスト テスト リリース TDD、ペアプロの中で 作っていくスキルは身についた PdM、PDと一緒に テストを作っている
31. 31 継続的インテグレーション(CI) - テスト自動化するには？ - テスト コード ビルド デプロイ テスト テスト リリース TDD、ペアプロの中で 作っていくスキルは身についた PdM、PDと一緒に テストを作っている 「継続的に」「自動で」 テストをする仕組みをちゃんと 理解できていなかった
32. 32 継続的インテグレーション(CI) - テスト自動化するには？ - テスト コード ビルド デプロイ テスト テスト リリース テスト環境が 必要 CIと相性のいいツール でテスト環境を構築 (エンジニアと一緒に)
33. 33 継続的インテグレーション(CI) - テスト自動化するには？ - テスト コード ビルド デプロイ テスト テスト リリース リリースまでの 一連のワークフローが必要 Github Actions で テスト＋リリースが 可能なワークフローを構築 (エンジニアと一緒に)
34. 34 XPの中で成長した点まとめ • ペアプロ、TDD ◦ エンジニアと一緒にペアで作業することでコードだけでなく、 シンプルな設計まで身についてきた ◦ エンジニアがやりやすいタスクの粒度がわかり、より目線が揃 いやすくなってきた • 受け入れテスト ◦ 受け入れテストのあり方を再整理して、ビジネスサイドの視点 を受け入れることができた • CI ◦ テストを回し続ける基盤をエンジニアと一緒に構築した
35. 35 XPの中で成長した点まとめ • ペアプロ、TDD ◦ エンジニアと一緒にペアで作業することでコードだけでなく、 シンプルな設計まで身につけた ◦ エンジニアがやりやすいタスクの粒度がわかり、より目線が揃 いやすくなってきた • 受け入れテスト ◦ 受け入れテストのあり方を再整理して、ビジネスサイドの視点 を受け入れることができた • CI ◦ テストを回し続ける基盤をエンジニアと一緒に構築した チームで開発するために、 柔軟に動くことができるスキルが 全体的に身につけることができたと実感
36. 36 副次的に他のプラクティスにも触れることになった チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス
37. XPをやってきたことで QAが感じる組織の伸び代
38. 38 XPのプラクティスで守れるところは限定的...？ DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ TDDで作った テスト * CI 受け入れ テスト * CI
39. 39 XPのプラクティスで守れるところは限定的...？ テスト環境が 必要 この部分の テストが まだまだ DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
40. 40 XPのプラクティスで守れるところは限定的...？ テスト環境が 必要 この部分の テストが まだまだ チーム全体で守っていく必要がある DAN ASHBY 『Continuous Testing in DevOps…』 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
41. 41 XPにおいて、QAの役割は明記されている① 『エクストリームプログラミング 第2版』(第10章 XPチーム全体) ・XPチームのテスターは、システムレベルの自動テストの選択や 　記述について開発前に顧客を支援したり、プログラマーに 　テスト技法をコーチしたりする
42. 42 QAがこれからチームに貢献していきたいこと① 『エクストリームプログラミング 第2版』(第10章 XPチーム全体) ・XPチームのテスターは、システムレベルの自動テストの選択や 　記述について開発前に顧客を支援したり、プログラマーに 　テスト技法をコーチしたりする 　👉開発中に作るテストの質をコーチングによって高めていく
43. 43 XPにおいて、QAの役割は明記されている② 『エクストリームプログラミング 第2版』(第10章 XPチーム全体) ・テスターはそうした「ハッピーパス」を視野に入れながら、 　そこから外れたときに何が起きるかを質問するのが得意である ・テスターがコミュニケーションを増幅する役割を担っている
44. 44 QAがこれからチームに貢献していきたいこと② 『エクストリームプログラミング 第2版』(第10章 XPチーム全体) ・テスターはそうした「ハッピーパス」を視野に入れながら、 　そこから外れたときに何が起きるかを質問するのが得意である ・テスターがコミュニケーションを増幅する役割を担っている 　👉シフトレフトをしてPLANのテストを 　👉シフトライトをしてもっとOPERATEやMONITORに力を
45. 45 もう一つしていきたいこと
46. 46 もう一歩踏み込んで、品質を考えるフェーズがやってきた ※本人の許可をいただいております
47. 47 もう一歩踏み込んで、品質を考えるフェーズがやってきた ※本人の許可をいただいております コドモン＝子どもを取り巻く環境のインフラ とした時に、プロダクト品質だけでなく、 サービス品質をみんなで考えていく時がきた ⭐QAは、みんなが品質を考えていくためには 何ができるかという側面でも貢献していきたい
48. まとめ
49. 49 全体のまとめ • QAがXPのプラクティスに乗っ取った関わり方をすることで、 エンジニアにより身近な存在として認知されるようになってきた • しかし、QAとしてのスペシャリティを発揮した関わり方ではなかっ たので、今後はもう少しスペシャリティをあげて、開発者と関わる 必要が出てきたと感じている • プロダクトの成長に対して、社会的責任が大きくなってきた。 全員でサービスの品質を維持・向上していくために、QAとして何が できるか再考していきたい
50. 最後に
51. 51 コドモン採用ページ コドモンでは一緒に働きたい仲間を募集しています！ 開発チームX
52. ご清聴ありがとうございました