テスト自動化を​進める​上での​マインドセットと​しての​XP(エクストリーム・プログラミング) / xp-mindset-for-test-automation

1. テスト自動化を進める上での マインドセットとしてのXP (エクストリーム・プログラミング) ソフトウェアテスト自動化カンファレンス2025 株式会社コドモン　砂川雅裕
2. 2 CONFIDENTIAL - © 2025 CoDMON Inc. • 　コドモンについて • 　XPとテストに関して • 　XPのチームでテストをしてみて • 　XPチームにおけるQAとして今は何をしている？ • 　最後に AGENDA
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. XPとテストに関して
10. 10 XPの概要 『エクストリーム プログラミング』より 人間性と生産性を調和させ、その調和を共有しようとする試み • 顧客にバリューをもたらすために必要なことだけを実施 • ソフトウェア開発の制約に対応するための方法論 • 価値や原則は、あらゆる規模に適用可能 • あいまいで急速に変化する要件に対応
11. 11 • サークルオブライフ by ロン・ジェフリーズ XPのプラクティス チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス Robert C.Martin『Clean Agile 基本に立ち戻れ』 P.47
12. 12 テストに関わるプラクティスも存在している チーム全体 受入テスト 小さなリリース 計画ゲーム 継続的 インテグレーション メタファー 持続可能な ペース 共同所有 テスト 駆動開発 シンプルな 設計 ペアリング リファクタ リング ビジネスプラクティス チームプラクティス テクニカルプラクティス
13. 13 テストファーストプログラミング 原著におけるテストの役割に関して -1- スコープクリープ プログラムのあるべき姿を先に書いて、コーディングに集中する 結合度と凝集度 テストを書くのが難しい＝設計に問題がある 信頼 動くコードと自動テストでチームメイトから信頼を リズム 何をすべきかが明確になって、効率的な開発のリズムになっていく
14. 14 テスティングはプログラミングと同様に重要 ◦ 欠陥の発生を抑えて、チームの信頼を成長させる ◦ テストは欠陥に直接対処する取り組み 原著におけるテストの役割に関して -2- テスト テストは2つのセットのテストが必要 ◦ プログラマー視点のテスト ◦ 顧客・ユーザー視点のテスト ◦ ペアプロをすることで、異なる視点のテストが増えていく 失敗するテストを作って、次のテストを書いて、どんどんテストを拡充さ せていく これらのテストを自動化しておく必要がある
15. XPのチームでテストをしてみて
16. 16 XPを始める前のテストの作り方 • テストの目的 ◦ リリース前のバグを取り切ることが目的 • テストの方法 ◦ マニュアルテストでやることが前提 ▪ 開発者が自動テストをやっている場合もあった • 当時作っていたテスト ◦ JSTQBのテストプロセスを参考に段階的詳細化したテスト ▪ 特にミッションクリティカルな機能の場合、 網羅的なテストでバグを取り切る
17. 17 テスティングはプログラミングと同様に重要 ◦ 欠陥の発生を抑えて、チームの信頼を成長させる ◦ テストは欠陥に直接対処する取り組み まずは原著で知識を入れた テスト テストは2つのセットのテストが必要 ◦ プログラマー視点のテスト ◦ 顧客・ユーザー視点のテスト ◦ ペアプロをすることで、異なる視点のテストが増えていく 失敗するテストを作って、次のテストを書いて、どんどんテストを拡充さ せていく これらのテストを自動化しておく必要がある
18. 18 テスティングはプログラミングと同様に重要 ◦ 欠陥の発生を抑えて、チームの信頼を成長させる ◦ テストは欠陥に直接対処する取り組み まずは原著で知識を入れた テスト テストは2つのセットのテストが必要 ◦ プログラマー視点のテスト ◦ 顧客・ユーザー視点のテスト ◦ ペアプロをすることで、異なる視点のテストが増えていく 失敗するテストを作って、次のテストを書いて、どんどんテストを拡充さ せていく これらのテストを自動化しておく必要がある
19. 19 XPチームの中でのテストの作り方 • テストの目的 ◦ テストファーストに開発を進めていく ◦ 欠陥の発生を早期に抑えていく • テストの方法 ◦ テストはできる限り自動化しておく • 今作っているテスト ◦ ストーリー完遂のためのテスト(開発者視点の機能テスト) ◦ エピックを多角的に見たテスト(ユーザー視点のテスト) ◦ 非機能テスト(性能・負荷テスト、セキュリティテスト など)
20. 20 具体的にどうXPのチームに入っていったか？ ペアプロ
21. 21 コンポーネントレベルの ユニットテスト作成 実装 テスト実行 リファクタリング 仕様として APIテストやE2Eテスト 作成 スコープ決め コンポーネントや メソッドレベルで 機能を満たすための テストを作成 実装し、作成したテスト を回して、機能の正しさ をチェック。 保守性を上げるためにリ ファクタも実施 タスクやストーリーを 達成した時に 満たすべき仕様を作成 ストーリー完遂のために行っていること リファイメントや デイリーで話し合って、 開発しやすい タスクや ストーリーに分解
22. 22 ペアプロの様子 - テスト作成の様子 - 職員は、 随時請求機能 で請求項目を 設定できる まずは、E2Eテスト (＝仕様)を書きますか ワイヤーをベースに 入力して、請求を作成 できるようにしましょ う E2Eの中で税率を 全部設定しておきたい です 税込金額が正しいか どうかの確認をしたい ので、テスト値も工夫 したいですね
23. 23 ペアプロの様子 - 実装後のテストの様子 - 一応手動でも 見ておきますか 実装終わったんで、 テスト回しますね ワイヤー通りの挙動な んで、PRのレビューレ ディにしちゃいます CI上の他のテストも 通ったんで問題なさそ うですね 職員は、 随時請求機能 で請求項目を 設定できる
24. 24 開発者と一緒にテストをペアで作ってみて • テストファーストで作ることで開発者視点が見えてくる ◦ E2EテストやAPIテストをベースに、開発者が作りたいものが わかる ◦ 不足しているところや懸念点があれば、テストとしてQAも一緒に作っ ておくことができる • タスク完了時の達成感 ◦ 一緒に実装を続け、作ってきたテストを回す ◦ ある程度のドキドキもある中、ローカルやCIのテスト結果が 全てPASSした時の達成感はすごいものを感じる ◦ QAと開発者の中でコラボが生まれ、信頼感が得られる
25. 25 さらに自動テストの効力を上げる要素 • CIパイプラインが整備されている ◦ 作った自動テストが日時、マージ前で実行されて、 変更に対するフィードバックを早く開発者にフィードバック できている • 自動テストへのコミットがQAだけじゃない ◦ 実際に開発者同士で仕様となるテストを作っている ◦ テストに対する保守をQAがやるというわけではなく、開発者と一緒に 進めることができている ◦ XPのプラクティスのうち、共同所有がコードとテストに対して できている状態
26. 26 自動テストがチームに与えている価値 • 「テストがあるから踏み出せる」という言葉が増えてきた ◦ 動く自動テストがあるからカイゼンに対して、勇気を踏み出せる状況 が生まれている ▪ 横断的な機能に対して追加機能を入れる ▪ ライブラリバージョンアップ ▪ 設計を見直して、大規模なリファクタリング ◦ 実際のコメント
27. 27 ここまでのまとめ • ペアプロで、テスト → 実装と進めながら、テストの状況や 実装の方針がわかる状態が作ることができる ◦ テストや実装に不安が残る部分があれば、実装タスク中に 解消しながら進めることもできる • 自動テストが積み上がっていき、パイプラインで回ることで 予期せぬ不具合検出につながる ◦ 変更による思わぬ不具合を見逃さない仕組みがあることで、 開発中のタスクに対して、何が満たされているといいのか ということを深く考えながらタスクを進めることができる • テストがあることで、難易度の高いタスクに対しても勇気を 持って踏み出せる
28. XPチームにおけるQAとして 今は何をしている？
29. 29 ただ、作っているテストはこれだけではない • 今作っているテスト ◦ ストーリー完遂のためのテスト(開発者視点の機能テスト) ◦ エピックを多角的に見たテスト(ユーザー視点のテスト) ◦ 非機能テスト(性能・負荷テスト、セキュリティテスト など) これらのテストも必要で、 どのようにQAとして取り組んでいるか 話をしていきます
30. 30 ペアプロの中で見えてきた課題 職員は、 随時請求機能 で請求項目を 設定できる まずは、E2Eテスト (＝仕様)を書きますか ワイヤーをベースに 入力して、請求を作成 できるようにしましょ う E2Eの中で税率を 全部設定しておきたい です 税込金額が正しいか どうかの確認をしたい ので、テスト値も工夫 したいですね
31. 31 ペアプロの中で見えてきた課題 職員は、 随時請求機能 で請求項目を 設定できる まずは、E2Eテスト (＝仕様)を書きますか ワイヤーをベースに 入力して、請求を作成 できるようにしましょ う E2Eの中で税率を 全部設定しておきたい です 税込金額が正しいか どうかの確認をしたい ので、テスト値も工夫 したいですね ペア”プログラミング”とあるように、 実装の範疇のプロセス品質は守ることが できるが、実装の範囲を超えた時の 品質を守れているか、QAとしてわからなく なってきた
32. 32 ペアプロの範疇の関心ごと 随時請求で 請求をする ペアプロの作業の範疇は、 エピックのうちの1つのス トーリー・タスク ペアプロの作業は開発プロ セスでも設計〜実装作業が 中心
33. 33 QAとして思ったこと 随時請求で 請求をする エピックとして考えた時、 私たちはその機能の挙動を 正しく届けているのか？ 設計や実装以外で品質保証 活動は進めていかなくてい いのか？
34. 34 さらに品質を強化するためにQAが行っていること • ストーリーの集合体(エピック)を多角的に見て、仕様へのフィード バックやテストを通して、品質を上げていく 随時請求で 請求をする 随時請求の内容が 法律的に問題ない ものか 請求を作るのに、 労力をかけすぎな いか 請求後の請求ス テータスで不整合 が起きない 誤った請求を 請求した後の アフターフォロー 請求先のミスは 絶対に起き得ない か そもそもスロー クエリとかない よね？
35. 35 ▼ これらの原則を踏まえて、今QAとして気をつけていること • 自動テストで守れる部分は多いが、漏らしたり、スコープから 外れることもある • だから、自動テストは品質の積み重ねのコアにしながら、 サテライトでその他のテスト活動を使っていくようにした ペアプロや自動テスト以外の品質管理活動も必要 • テスト自動化の8原則 ◦ 自動テストは書いたことしかテストしない ◦ 自動テストで新種のバグが見つかることは稀である • ソフトウェアテスト7原則 ◦ テストは状況次第 ◦ バグゼロの落とし穴
36. 36 自動テストとその他のテストの「コア - サテライト戦略」 自動テスト 仕様レビュー / 受け入れテスト ユーザビリティ テスト 自動テストの 拡充 スクリプト テスト 探索的テス ト 負荷テスト 適宜、テスト活動をアレンジしながら、品質保証をしている
37. 37 ・ストーリー単位での品質 　だけでなく、視野・視　　 座・視点を変えた時の品　 質はどうか考える ・考えた上で、QAが知って　 いる様々な品質保証活動　 をどんどん活用していく ・自動テストを作ることや　 CIが当たり前になってい　 る文化が醸成 ・QAも開発者とペアプロを 　進めながら、リリース時　 点の品質向上に貢献 ・製造しているコード、テ　 ストに対する共同所有が 　進む 全体のまとめ XP QA 色んな知見を活用しながらプロダクト品質を上げていく
38. 38 • 要求や要件を考える段階からの品質の作り込みの実施 ◦ リスク検出の早期化 • 自動テスト作成の自動化 ◦ 要件やストーリーの内容をベースとして、動く仕様としての テストを3人目の実装者のAIも活用しながら、作成していく ◦ 上記を行うために、テスト設計のスキルを開発者にも伝播させていく • ユーザーニーズの素早い察知とプロダクトへの反映を早める ◦ プロダクトの品質向上の意思決定スピードを早めたい これからしていきたいこと
39. 最後に
40. 40 コドモン採用ページ コドモンでは一緒に働きたい仲間を募集しています！ 開発チームX
41. ご清聴ありがとうございました
42. 42 • Kent Beck・Cynthia Andres 共著, 『エクストリーム・プログラミング』, 翔泳社, 2015 • Robert C.Martin 著 『Clean Agile 基本に立ち戻れ』, アスキードワンゴ, 2020 参考文献