事業継続を支える自動テストの考え方（レバレジーズ様勉強会版）

レバレジーズ様社内勉強会で利用した資料です。

Transcript

1. 事業継続を支える 自動テストの考え方 2025/03/25 レバレジーズ様勉強会 Quality Evangelist @ Autify, Inc. 末村 拓也
2. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し 末村 拓也 (Takuya Suemura) Autify, Inc. (2019 -) Quality Evangelist • Ex. QA Manager • Ex. Senior Technical Support Engineer • Ex. Test Automation Engineer OPENLOGI (2017 - 2019) QA Engineer それより前はPHP開発をしていたり 倉庫でフォークリフトに載ったりしていました ソフトウェア品質や自動テストのあるべき姿を 業界の皆さんと一緒に考えるのが仕事です
3. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し テスト自動化実践ガイド (2024) Coming soon…
4. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し
5. 事業とソフトウェア 01.
6. • ソフトウェアは（ハードウェアと比べ） 拡張や変化をさせやすい • そのため、ビジネスの拡大やニーズの変化に 柔軟に対応させやすい と一般には言われている ソフトウェアと事業
7. 使われ方や期待値がだんだん分からなくなってしまう • 社員の退職や異動に伴い、作った当時の仕様や要求が 分からなくなっていまう • 機能追加時に仕様書をアップデートしなかった • 当初からユースケースが増えて、 誰がどう使っているのかが管理しきれない 実際に事業を長く継続すると
8. ソフトウェアもだんだん大きく複雑になってしまう • もともとあったロジックに変更を加え続けたため 中身のルールが複雑になってしまった • 共通関数のパラメーターが多くなりすぎて どこに何を入れるべきなのか分からない • シンプルにしたいが、どこに何が影響するか 分からず手を入れるのが怖い 実際に事業を長く継続すると
9. 長く続いたソフトウェアに起こること エンジニア視点 • コードから目的を読み取れない • 機能がどう動くのが正しいのか 分からない • 保守性を高める取り組みが 後回しにされる • 保守性を高めたら壊れた 事業視点 • 開発がだんだん遅くなる • 開発者に仕様を聞いても返事がない • え、またリファクタリングしてんの？
10. 持続可能な開発はアジャイルの核であり技術者の責務
11. • どのように使われるものかが明確である • 複雑になっても安全に取り扱える 自動テストは、ソフトウェアにこのような性質を与える 実践的な エンジニアの知恵 です なにをすればいいのか
12. ソフトウェアの “使われ方” 02.
13. ソフトウェアは誰かに使われてはじめて意味を成す • APIは他のプログラムからコールされる • GUIは人間に操作される このように他者から操作されたときの外的な挙動を ソフトウェアの ふるまい と呼ぶ ソフトウェアの「使われ方」とは
14. プロバイダーとコンシューマー プロバイダー コンシューマー I/F
15. • 例ベースの自動テストはコンシューマーのスタブとも言える • 主体はプロバイダー なぜ「使われ方」というのか プロバイダー コンシューマー のフリをしたテス トコード I/F
16. 開発中はこっちに着目しがち プロバイダー コンシューマー I/F
17. 「どう使われるはずか」を想定するのがテスト プロバイダー コンシューマー I/F
18. テストはふるまいの具体例 プロバイダー コンシューマー I/F テスト テスト テスト テスト
19. • sum(a, b) 関数に 1, 2 を与えると、関数は 3 を出力する • ログインフォームにメールアドレスとパスワードを入力すると、 サーバーはセッションIDを返し、マイページへリダイレクトする プロバイダーとコンシューマーのやりとりを具体的に記述する テストはふるまいの具体例
20. 様々な “使われ方” 03.
21. ソフトウェアを使う側も何らかのふるまいをしている • ECサイトのエンドユーザーは「ログインする」「商品をカートに入れる」などの ように ふるまう • mail() 関数を呼び出す registerUser() 関数は、メールアドレス、タイトル、本 文を mail() 関数に渡すように ふるまう 「ふるまう」のはソフトウェアだけ？
22. ユースケース = ユーザーのふるまいに注目したもの ログインする カートに 入れる カートを 編集する 購入を確定 支払う 商品検索 発送
23. シーケンス図 = 各コンポーネントのふるまいに注目したもの カートに入れる カート一覧を表示 購入確定 決済リクエスト 決済完了 購入確定表示 発送リクエスト
24. • 仕様書？ • 要件定義書？ 関数などの小さな単位には↑のような成果物がないこともある ここではプロバイダーとコンシューマーがどうふるまうかを（ときに暗黙のうちに）定 義するものを 契約 と呼ぶことにする それぞれのふるまいは誰が決めるの？
25. プロバイダーとコンシューマーのふるまいを決める「契約」 契約 プロバイダー コンシューマー I/F
26. • プロバイダーの ふるまいに依存したコード が自動テスト ◦ プロバイダーのふるまいが変わると テストコードは動かなくなる • 自動テストは多くの場合 コンシューマーのふるまいの具体例 として記述される • プロバイダー実装だけで契約は守れない 自動テスト実装で契約を守り続ける 自動テストは契約を守り続けるための技術
27. • プロバイダーの ふるまいに依存したコード が自動テスト ◦ プロバイダーのふるまいが変わると テストコードは動かなくなる • プロバイダーのふるまいを変えるときには 自動テストも必ず変えなければならない • 自動テストは 常にアップデートされ続ける具体例 自動テストは生きたドキュメント
28. • ユーザージャーニーが契約なら、 テストはUIを介したE2Eテストとなる • API仕様書が契約なら、 テストはAPIを介したE2Eテストになる • ルーティング仕様書が契約なら、 テストはアプリケーションルーターに対する結合テストになる • sum() 関数の仕様が契約なら、 テストは sum() 関数の振る舞いに対する単体テストになる 契約の種類によって実施するテストは異なる
29. 契約の種類によって実施するテストは異なる 契約 プロバイダー コンシューマー テスト ECサイトの ユーザージャーニー アプリケーション エンドユーザー UIを用いた シナリオテスト 連携する倉庫システ ムのユースケース アプリケーション 倉庫管理システム APIを用いた シナリオテスト Web API仕様 Web API 外部システム API機能テスト アプリケーション ルーターの仕様 REST エンドポイント Webクライアント （ブラウザー） 結合テスト mail() 関数の仕様 mail() 関数 他の様々な関数 単体テスト
30. テストコードは契約を具体的に説明できる ログインす る カートに 入れる カートを 編集する 購入を確 定 支払う 商品検索 発送 アプリケーションのコードでユースケースは表現できないが、 テストコードでは表現できる
31. 脱線. コントラクトテスト
32. 契約に対するテスト : コントラクトテスト https://docs.pact.io/
33. 事業と共に成長する自動テスト 04.
34. • 事業の拡大や変化に応じて、ソフトウェアは変化する • 繰り返し変化を繰り返したソフトウェアは複雑になる • 自動テストはソフトウェアの使われ方 ≒ 契約を守るもの 自動テストの性質を上手く使って、 複雑さや変化に対応し続けるのがポイントとなる ここまでのおさらい
35. • 事業（ビジネスルール）の変化があるとき アプリケーションもまた変化する • 変化のたびにテストも変えたり増やしたりする 事業と共にアプリケーションもテストも進歩させる 事業、アプリケーション、テストは必ずセット
36. 良いユーザーストーリーの特徴 INVEST • Independent • Negotiable • Valuable • Estimable • Small • Testable 機能を考えるときに「どうテストするか」も一緒に考える テスト可能なビジネスルール
37. ビジネスルールと具体例の発見 テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck 「ユーザーの権限を管理したい」という新機能に対する要件の洗い出し
38. ビジネスルールの増加と共に E2Eテストシナリオも増えていく • 各ユーザーストーリーの開発チケットに は自動的にE2Eテスト開発のサブタス ク(チケット)が作成される • E2Eテスト作成完了までは原則開発チ ケットを完了できない仕組み Autify社での例 テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck
39. 保守性との付き合い方 05.
40. 再掲: 長く続いたソフトウェアに起こること エンジニア視点 • コードから目的を読み取れない • 機能がどう動くのが正しいのか 分からない • 保守性を高める取り組みが 後回しにされる • 保守性を高めたら壊れた 事業視点 • 開発がだんだん遅くなる • 開発者に仕様を聞いても返事がない • え、またリファクタリングしてんの？ • リファクタリングしたら壊れたの？ • メンテできないから作り直すの？ • いつ新機能できるの？
41. 内部品質と外部品質は関連する 図は https://www.ashisuto.co.jp/pr_blog/article/20200511_test.html より引用
42. 例）コードカバレッジが下がらない仕組みを入れる 内部品質は日々の取り組みで上げていく
43. 再掲
44. 複雑になってしまったアプリケーションを自動テストで守り アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
45. 内部構造を保守しやすくする アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
46. ユースケースの増大に応じて E2Eテストも増やす アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
47. まとめ
48. • 事業を続けているうちにソフトウェアは変化を繰り返す • 変化を繰り返したソフトウェアは複雑で予測しづらくなることがある • 使い方（使われ方）を具体的に示すコードが自動テスト • 事業と共にアプリケーションと自動テストも変化させる • 継続的に・段階的に保守性を上げられる仕組みを作ると良い まとめ
49. 時間があれば : Autifyについて
50. 会社概要・沿革
51. AI-powered Quality Engineering Platform AutifyはAI, 生成AIを活用したプロダクトと 品質保証のプロフェッショナルがテストプロセスのすべてをサポート
52. ノーコードで誰でも簡単 AIが自動でメンテナンス AIを用いたノーコードテスト自動化ツール
53. テスト自動化導入支援・品質保証サービス 自動化カバレッ ジの向上 QAコンサルティ ング 開発・テストのア ジャイル化 自社運用までの 伴走支援 自動テスト 作成・運用代行 QAリソース 確保・工数削減 QAチームの 立ち上げ 自動化導入支 援検証（PoC）
54. 生成AIによるテストケース・テストシナリオ自動生成 (β)
55. Enjoy Testing! ご清聴ありがとうございました