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

by Autify

Slide 1

Slide 1 text

事業継続を支える自動テストの考え方 2025/03/25 レバレジーズ様勉強会 Quality Evangelist @ Autify, Inc. 末村拓也

Slide 2

Slide 2 text

タイトルタイトルタイトルタイトルタイトルタイトルタイトル小見出し小見出し小見出し小見出し末村拓也 (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開発をしていたり倉庫でフォークリフトに載ったりしていましたソフトウェア品質や自動テストのあるべき姿を業界の皆さんと一緒に考えるのが仕事です

Slide 3

Slide 3 text

タイトルタイトルタイトルタイトルタイトルタイトルタイトル小見出し小見出し小見出し小見出しテスト自動化実践ガイド (2024) Coming soon…

Slide 4

Slide 4 text

タイトルタイトルタイトルタイトルタイトルタイトルタイトル小見出し小見出し小見出し小見出し

Slide 5

Slide 5 text

事業とソフトウェア 01.

Slide 6

Slide 6 text

● ソフトウェアは（ハードウェアと比べ）拡張や変化をさせやすい ● そのため、ビジネスの拡大やニーズの変化に柔軟に対応させやすいと一般には言われているソフトウェアと事業

Slide 7

Slide 7 text

使われ方や期待値がだんだん分からなくなってしまう ● 社員の退職や異動に伴い、作った当時の仕様や要求が分からなくなっていまう ● 機能追加時に仕様書をアップデートしなかった ● 当初からユースケースが増えて、誰がどう使っているのかが管理しきれない実際に事業を長く継続すると

Slide 8

Slide 8 text

ソフトウェアもだんだん大きく複雑になってしまう ● もともとあったロジックに変更を加え続けたため中身のルールが複雑になってしまった ● 共通関数のパラメーターが多くなりすぎてどこに何を入れるべきなのか分からない ● シンプルにしたいが、どこに何が影響するか分からず手を入れるのが怖い実際に事業を長く継続すると

Slide 9

Slide 9 text

長く続いたソフトウェアに起こることエンジニア視点 ● コードから目的を読み取れない ● 機能がどう動くのが正しいのか分からない ● 保守性を高める取り組みが後回しにされる ● 保守性を高めたら壊れた事業視点 ● 開発がだんだん遅くなる ● 開発者に仕様を聞いても返事がない ● え、またリファクタリングしてんの？

Slide 10

Slide 10 text

持続可能な開発はアジャイルの核であり技術者の責務

Slide 11

Slide 11 text

● どのように使われるものかが明確である ● 複雑になっても安全に取り扱える自動テストは、ソフトウェアにこのような性質を与える実践的なエンジニアの知恵ですなにをすればいいのか

Slide 12

Slide 12 text

ソフトウェアの “使われ方” 02.

Slide 13

Slide 13 text

ソフトウェアは誰かに使われてはじめて意味を成す ● APIは他のプログラムからコールされる ● GUIは人間に操作されるこのように他者から操作されたときの外的な挙動をソフトウェアのふるまいと呼ぶソフトウェアの「使われ方」とは

Slide 14

Slide 14 text

プロバイダーとコンシューマープロバイダーコンシューマー I/F

Slide 15

Slide 15 text

● 例ベースの自動テストはコンシューマーのスタブとも言える ● 主体はプロバイダーなぜ「使われ方」というのかプロバイダーコンシューマーのフリをしたテストコード I/F

Slide 16

Slide 16 text

開発中はこっちに着目しがちプロバイダーコンシューマー I/F

Slide 17

Slide 17 text

「どう使われるはずか」を想定するのがテストプロバイダーコンシューマー I/F

Slide 18

Slide 18 text

テストはふるまいの具体例プロバイダーコンシューマー I/F テストテストテストテスト

Slide 19

Slide 19 text

● sum(a, b) 関数に 1, 2 を与えると、関数は 3 を出力する ● ログインフォームにメールアドレスとパスワードを入力すると、サーバーはセッションIDを返し、マイページへリダイレクトするプロバイダーとコンシューマーのやりとりを具体的に記述するテストはふるまいの具体例

Slide 20

Slide 20 text

様々な “使われ方” 03.

Slide 21

Slide 21 text

ソフトウェアを使う側も何らかのふるまいをしている ● ECサイトのエンドユーザーは「ログインする」「商品をカートに入れる」などのようにふるまう ● mail() 関数を呼び出す registerUser() 関数は、メールアドレス、タイトル、本文を mail() 関数に渡すようにふるまう「ふるまう」のはソフトウェアだけ？

Slide 22

Slide 22 text

ユースケース = ユーザーのふるまいに注目したものログインするカートに入れるカートを編集する購入を確定支払う商品検索発送

Slide 23

Slide 23 text

シーケンス図 = 各コンポーネントのふるまいに注目したものカートに入れるカート一覧を表示購入確定決済リクエスト決済完了購入確定表示発送リクエスト

Slide 24

Slide 24 text

● 仕様書？ ● 要件定義書？関数などの小さな単位には↑のような成果物がないこともあるここではプロバイダーとコンシューマーがどうふるまうかを（ときに暗黙のうちに）定義するものを契約と呼ぶことにするそれぞれのふるまいは誰が決めるの？

Slide 25

Slide 25 text

プロバイダーとコンシューマーのふるまいを決める「契約」契約プロバイダーコンシューマー I/F

Slide 26

Slide 26 text

● プロバイダーのふるまいに依存したコードが自動テスト ○ プロバイダーのふるまいが変わるとテストコードは動かなくなる ● 自動テストは多くの場合コンシューマーのふるまいの具体例として記述される ● プロバイダー実装だけで契約は守れない自動テスト実装で契約を守り続ける自動テストは契約を守り続けるための技術

Slide 27

Slide 27 text

● プロバイダーのふるまいに依存したコードが自動テスト ○ プロバイダーのふるまいが変わるとテストコードは動かなくなる ● プロバイダーのふるまいを変えるときには自動テストも必ず変えなければならない ● 自動テストは常にアップデートされ続ける具体例自動テストは生きたドキュメント

Slide 28

Slide 28 text

● ユーザージャーニーが契約なら、テストはUIを介したE2Eテストとなる ● API仕様書が契約なら、テストはAPIを介したE2Eテストになる ● ルーティング仕様書が契約なら、テストはアプリケーションルーターに対する結合テストになる ● sum() 関数の仕様が契約なら、テストは sum() 関数の振る舞いに対する単体テストになる契約の種類によって実施するテストは異なる

Slide 29

Slide 29 text

契約の種類によって実施するテストは異なる契約プロバイダーコンシューマーテスト ECサイトのユーザージャーニーアプリケーションエンドユーザー UIを用いたシナリオテスト連携する倉庫システムのユースケースアプリケーション倉庫管理システム APIを用いたシナリオテスト Web API仕様 Web API 外部システム API機能テストアプリケーションルーターの仕様 REST エンドポイント Webクライアント（ブラウザー）結合テスト mail() 関数の仕様 mail() 関数他の様々な関数単体テスト

Slide 30

Slide 30 text

テストコードは契約を具体的に説明できるログインするカートに入れるカートを編集する購入を確定支払う商品検索発送アプリケーションのコードでユースケースは表現できないが、テストコードでは表現できる

Slide 31

Slide 31 text

脱線. コントラクトテスト

Slide 32

Slide 32 text

契約に対するテスト : コントラクトテスト https://docs.pact.io/

Slide 33

Slide 33 text

事業と共に成長する自動テスト 04.

Slide 34

Slide 34 text

● 事業の拡大や変化に応じて、ソフトウェアは変化する ● 繰り返し変化を繰り返したソフトウェアは複雑になる ● 自動テストはソフトウェアの使われ方 ≒ 契約を守るもの自動テストの性質を上手く使って、複雑さや変化に対応し続けるのがポイントとなるここまでのおさらい

Slide 35

Slide 35 text

● 事業（ビジネスルール）の変化があるときアプリケーションもまた変化する ● 変化のたびにテストも変えたり増やしたりする事業と共にアプリケーションもテストも進歩させる事業、アプリケーション、テストは必ずセット

Slide 36

Slide 36 text

良いユーザーストーリーの特徴 INVEST ● Independent ● Negotiable ● Valuable ● Estimable ● Small ● Testable 機能を考えるときに「どうテストするか」も一緒に考えるテスト可能なビジネスルール

Slide 37

Slide 37 text

ビジネスルールと具体例の発見テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck 「ユーザーの権限を管理したい」という新機能に対する要件の洗い出し

Slide 38

Slide 38 text

ビジネスルールの増加と共に E2Eテストシナリオも増えていく ● 各ユーザーストーリーの開発チケットには自動的にE2Eテスト開発のサブタスク(チケット)が作成される ● E2Eテスト作成完了までは原則開発チケットを完了できない仕組み Autify社での例テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck

Slide 39

Slide 39 text

保守性との付き合い方 05.

Slide 40

Slide 40 text

再掲: 長く続いたソフトウェアに起こることエンジニア視点 ● コードから目的を読み取れない ● 機能がどう動くのが正しいのか分からない ● 保守性を高める取り組みが後回しにされる ● 保守性を高めたら壊れた事業視点 ● 開発がだんだん遅くなる ● 開発者に仕様を聞いても返事がない ● え、またリファクタリングしてんの？ ● リファクタリングしたら壊れたの？ ● メンテできないから作り直すの？ ● いつ新機能できるの？

Slide 41

Slide 41 text

内部品質と外部品質は関連する図は https://www.ashisuto.co.jp/pr_blog/article/20200511_test.html より引用

Slide 42

Slide 42 text

例）コードカバレッジが下がらない仕組みを入れる内部品質は日々の取り組みで上げていく

Slide 43

Slide 43 text

再掲

Slide 44

Slide 44 text

複雑になってしまったアプリケーションを自動テストで守りアプリケーションサードパーティーコンポーネントユーザー E2Eテスト UI 公開 API APIテスト

Slide 45

Slide 45 text

内部構造を保守しやすくするアプリケーションサードパーティーコンポーネントユーザー E2Eテスト UI 公開 API APIテスト

Slide 46

Slide 46 text

ユースケースの増大に応じて E2Eテストも増やすアプリケーションサードパーティーコンポーネントユーザー E2Eテスト UI 公開 API APIテスト

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

● 事業を続けているうちにソフトウェアは変化を繰り返す ● 変化を繰り返したソフトウェアは複雑で予測しづらくなることがある ● 使い方（使われ方）を具体的に示すコードが自動テスト ● 事業と共にアプリケーションと自動テストも変化させる ● 継続的に・段階的に保守性を上げられる仕組みを作ると良いまとめ

Slide 49

Slide 49 text

時間があれば : Autifyについて

Slide 50

Slide 50 text

会社概要・沿革

Slide 51

Slide 51 text

AI-powered Quality Engineering Platform AutifyはAI, 生成AIを活用したプロダクトと品質保証のプロフェッショナルがテストプロセスのすべてをサポート

Slide 52

Slide 52 text

ノーコードで誰でも簡単 AIが自動でメンテナンス AIを用いたノーコードテスト自動化ツール

Slide 53

Slide 53 text

テスト自動化導入支援・品質保証サービス自動化カバレッジの向上 QAコンサルティング開発・テストのアジャイル化自社運用までの伴走支援自動テスト作成・運用代行 QAリソース確保・工数削減 QAチームの立ち上げ自動化導入支援検証（PoC）