事業継続を支える自動テストの考え方

Slide 1

Slide 1 text

事業継続を支える自動テストの考え方 2025/02/07, 8th長崎QDG 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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

会社概要・沿革

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

生成AIによるテストケース・テストシナリオ自動生成 (β)

Slide 11

Slide 11 text

事業とソフトウェア 01.

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

ソフトウェアを使う人とソフトウェアの使われ方 02.

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

● ECサイトは「使われる側」で、エンドユーザーは「使う側」 ● 決済APIは「使われる側」で、 ECサイトのバックエンドは「使う側」 ● decrementItem() 関数は「使われる側」で proceedOrder() 関数は「使う側」「使われる側 = 提供する側」をプロバイダー「使う側」をコンシューマーと呼ぶことにする様々な「使う側」「使われる側」がある

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

ふるまい、契約、自動テスト 03.

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

● ふるまいはプロバイダーとコンシューマーの間で交わされる契約が決める ○ 仕様書などの成果物が残っている場合もあるし、そうでない場合もある ● プロバイダーは API、GUIなどのインターフェースを持つ ○ DBならクエリがインターフェースだし、関数なら呼び出しがインターフェースである ● コンシューマーはインターフェースを通して目的を達成する ● テストはお互いのふるまいの具体例であるざっくりまとめると

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

リファインメントでテスト計画を立てる 💡 SMSでの多要素認証 E2Eテスト: ● ユーザーは電話番号にSMSを送信できる。 ● ユーザーが不正な電話番号を指定すると、エラーが表示される。 ● 多要素認証を有効にしていないユーザーには、SMS認証画面が表示されない。結合テスト : ● Twilioのテスト用番号を使って正常系/異常系のテストをする。探索的テスト : ● 30分 3~5人出来るだけ幅広いモバイルキャリア、OSを準備する ● 目的: モバイルキャリアや端末に依存する問題を見つける。ロールアウト : ● 日本国内の1%のユーザーに対して有効にし、段階的に範囲を広げる。テスト自動化から、開発を支える継続的テストへ - SpeakerDeck

Slide 44

Slide 44 text

● 想定を超えるたくさんのデータ ● 複数タブをまたいだ利用 ● 複数ユーザーでの同時編集 ● スマートフォンからの操作 ● 古すぎるブラウザ・デバイスでの操作 ● 低速な通信環境ただのバグとして直すだけでなく、現実の使われ方として自動テストも書く実際の使われ方からも学ぶ

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

複雑さを征服する 05.

Slide 47

Slide 47 text

リファクタリング (Refactoring): ふるまいを変えずに中身を作り変えること分割統治 (Divide and Conquer) : 複雑なものを小さく分けて一つずつやっつけていくこと複雑さへのアプローチ : リファクタリングと分割統治

Slide 48

Slide 48 text

複雑になってしまったものでも ● まず現状のふるまいに対する自動テストを書き ● ふるまいを変えずに中身を整理・分割して ● 分割したコンポーネントに更にテストを書くこのようにして安全に少しずつ変えていける複雑さへのアプローチ : リファクタリングと分割統治

Slide 49

Slide 49 text

リファクタリングと分割統治 ProcessOrder() - 発送先バリデーション - 在庫引当 - 支払 - 在庫更新 - 注文完了在庫があり、有効な支払い方法があれば、注文が完了する在庫が無い場合、注文できない無効な発送先の場合、注文できない支払方法が無効な場合、注文できない

Slide 50

Slide 50 text

Slide 51

Slide 51 text

StockService OrderService リファクタリングと分割統治 ProcessOrder() 在庫があり、有効な支払い方法があれば、注文が完了する在庫が無い場合、注文できない無効な発送先の場合、注文できない支払方法が無効な場合、注文できない validateAddress() reserveStock() processPayment() useReservedStock() updateOrderStatus() 東京都千代田区千代田1 は有効横浜県神奈川市1 は無効未注文→注文済にできる注文済→注文済にできない在庫が1のとき1つ予約できる在庫が1のとき2つ予約できない予約済みの在庫を減らせる予約していない在庫は減らせない

Slide 52

Slide 52 text

まとめ

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

システムそのものの複雑さや信頼性を自動テストで担保するには限界があるもちろん、銀の弾丸はないどちらもAutifyの同僚が訳しています

Slide 58

Slide 58 text

なに、上司や同僚が品質の大事さを理解してくれない？

Slide 59

Slide 59 text

お、自動テスト興味ありますか？

Slide 60

Slide 60 text

え、自動テスト挫折しちゃったんですか？ AIを用いたノーコードテスト自動化ツール

Slide 61

Slide 61 text

ご清聴ありがとうございました Enjoy Testing! おあとがよろしいようで