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

8th長崎QDG 2025/02/07

https://nagasaki-it-engineers.connpass.com/event/316177/

Transcript

1. 事業継続を支える 自動テストの考え方 2025/02/07, 8th長崎QDG 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. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し 末村 拓也 (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開発をしていたり 倉庫でフォークリフトに載ったりしていました ソフトウェア品質や自動テストのあるべき姿を 業界の皆さんと一緒に考えるのが仕事です
4. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し テスト自動化実践ガイド (2024) Coming soon…
5. タイトルタイトルタイトルタイトルタ イトルタイトルタイトル 小見出し小見出し小見出し小見出し
6. 会社概要・沿革
7. AI-powered Quality Engineering Platform AutifyはAI, 生成AIを活用したプロダクトと 品質保証のプロフェッショナルがテストプロセスのすべてをサポート
8. ノーコードで誰でも簡単 AIが自動でメンテナンス AIを用いたノーコードテスト自動化ツール
9. テスト自動化導入支援・品質保証サービス 自動化カバレッ ジの向上 QAコンサルティ ング 開発・テストのア ジャイル化 自社運用までの 伴走支援 自動テスト 作成・運用代行 QAリソース 確保・工数削減 QAチームの 立ち上げ 自動化導入支 援検証（PoC）
10. 生成AIによるテストケース・テストシナリオ自動生成 (β)
11. 事業とソフトウェア 01.
12. • ソフトウェアは（ハードウェアと比べ） 拡張や変化をさせやすい • そのため、ビジネスの拡大やニーズの変化に 柔軟に対応させやすい と一般には言われている ソフトウェアと事業
13. 使われ方や期待値がだんだん分からなくなってしまう • 社員の退職や異動に伴い、作った当時の仕様や要求が 分からなくなっていまう • 機能追加時に仕様書をアップデートしなかった • 当初からユースケースが増えて、 誰がどう使っているのかが管理しきれない 実際に事業を長く継続すると
14. ソフトウェアもだんだん大きく複雑になってしまう • もともとあったロジックに変更を加え続けたため 中身のルールが複雑になってしまった • 共通関数のパラメーターが多くなりすぎて どこに何を入れるべきなのか分からない • シンプルにしたいが、どこに何が影響するか 分からず手を入れるのが怖い 実際に事業を長く継続すると
15. • どのように使われるものかが明確である • 複雑になっても安全に取り扱える 自動テストは、ソフトウェアにこのような性質を与える 実践的な エンジニアの知恵 です 逆に、どういうものがあれば良いのか
16. ソフトウェアを使う人と ソフトウェアの使われ方 02.
17. ソフトウェアは誰かに使われてはじめて意味を成す • APIは他のプログラムからコールされる • GUIは人間に操作される このように他者から操作されたときの外的な挙動を ソフトウェアの ふるまい と呼ぶ ソフトウェアの「使われ方」とは
18. ソフトウェアを使う側も何らかのふるまいをしている • ECサイトのエンドユーザーは「ログインする」「商品をカートに入れる」などの ようにふるまう • mail() 関数を呼び出す registerUser() 関数は、メールアドレス、タイトル、本 文を mail() 関数に渡す 「ふるまう」のはソフトウェアだけ？
19. ユースケース = ユーザーのふるまいに注目したもの ログインする カートに 入れる カートを 編集する 購入を確定 支払う 商品検索 発送
20. シーケンス図 = 各コンポーネントのふるまいに注目したもの カートに入れる カート一覧を表示 購入確定 決済リクエスト 決済完了 購入確定表示 発送リクエスト
21. • ECサイトは「使われる側」で、エンドユーザーは「使う側」 • 決済APIは「使われる側」で、 ECサイトのバックエンドは「使う側」 • decrementItem() 関数は「使われる側」で proceedOrder() 関数は「使う側」 「使われる側 = 提供する側」を プロバイダー 「使う側」を コンシューマー と呼ぶことにする 様々な「使う側」「使われる側」がある
22. プロバイダーとコンシューマー プロバイダー コンシューマー I/F
23. 開発中はこっちに着目しがち プロバイダー コンシューマー I/F
24. 「どう使われるはずか」を想定するのがテスト プロバイダー コンシューマー I/F
25. テストはふるまいの具体例 プロバイダー コンシューマー I/F テスト テスト テスト テスト
26. • sum(a, b) 関数に 1, 2 を与えると、関数は 3 を出力する • ログインフォームにメールアドレスとパスワードを入力すると、 サーバーはセッションIDを返し、マイページへリダイレクトする プロバイダーとコンシューマーのやりとりを具体的に記述する テストはふるまいの具体例
27. ふるまい、契約、自動テスト 03.
28. • 仕様書 • 要件定義書 関数などの小さな単位には↑のような成果物がないこともある ここではプロバイダーとコンシューマーがどうふるまうかを定義するものを 「契約」と呼ぶことにする それぞれのふるまいは誰が決めるの？
29. プロバイダーとコンシューマーのふるまいを決める「契約」 契約 プロバイダー コンシューマー I/F
30. • ふるまいはプロバイダーとコンシューマーの間で交わされる 契約が決める ◦ 仕様書などの成果物が残っている場合もあるし、 そうでない場合もある • プロバイダーは API、GUIなどのインターフェース を持つ ◦ DBならクエリがインターフェースだし、 関数なら呼び出しがインターフェースである • コンシューマー はインターフェースを通して目的を達成する • テストはお互いのふるまいの具体例である ざっくりまとめると
31. • プロバイダーの ふるまいに依存したコード が自動テスト ◦ プロバイダーのふるまいが変わると テストコードは動かなくなる • 自動テストは多くの場合 コンシューマーのふるまいの具体例 として記述される • プロバイダー実装だけで契約は守れない 自動テスト実装で契約を守り続ける 自動テストは契約を守り続けるための技術
32. • プロバイダーの ふるまいに依存したコード が自動テスト ◦ プロバイダーのふるまいが変わると テストコードは動かなくなる • プロバイダーのふるまいを変えるときには 自動テストも必ず変えなければならない • 自動テストは 常にアップデートされ続ける具体例 自動テストは生きたドキュメント
33. • ユーザージャーニーが契約なら、 テストはUIを介したE2Eテストとなる • API仕様書が契約なら、 テストはAPIを介したE2Eテストになる • ルーティング仕様書が契約なら、 テストはアプリケーションルーターに対する結合テストになる • sum() 関数の仕様が契約なら、 テストは sum() 関数の振る舞いに対する単体テストになる 契約の種類によって実施するテストは異なる
34. 契約の種類によって実施するテストは異なる 契約 プロバイダー コンシューマー テスト ECサイトの ユーザージャーニー アプリケーション エンドユーザー UIを用いた シナリオテスト 連携する倉庫システ ムのユースケース アプリケーション 倉庫管理システム APIを用いた シナリオテスト Web API仕様 Web API 外部システム API機能テスト アプリケーション ルーターの仕様 REST エンドポイント Webクライアント （ブラウザー） 結合テスト mail() 関数の仕様 mail() 関数 他の様々な関数 単体テスト
35. 脱線. コントラクトテスト
36. • 例ベースの自動テストはコンシューマーのスタブとも言える • 主体はプロバイダー なぜ「使われ方」というのか プロバイダー コンシューマー のフリをしたテス トコード I/F
37. 契約に対するテスト : コントラクトテスト https://docs.pact.io/
38. 事業と共に成長する自動テスト 04.
39. • 事業の拡大や変化に応じて、ソフトウェアは変化する • 繰り返し変化を繰り返したソフトウェアは複雑になる • 自動テストはソフトウェアの使われ方 ≒ 契約を守るもの 自動テストの性質を上手く使って、 複雑さや変化に対応し続けるのがポイントとなる ここまでのおさらい
40. • 事業（ビジネスルール）の変化があるとき アプリケーションもまた変化する • 変化のたびにテストも変えたり増やしたりする 事業と共にアプリケーションもテストも進歩させる 事業、アプリケーション、テストは必ずセット
41. 良いユーザーストーリーの特徴 INVEST • Independent • Negotiable • Valuable • Estimable • Small • Testable 機能を考えるときに「どうテストするか」も一緒に考える テスト可能なビジネスルール
42. ビジネスルールと具体例の発見 テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck 「ユーザーの権限を管理したい」という新機能に対する要件の洗い出し
43. リファインメントでテスト計画を立てる 💡 SMSでの多要素認証 E2Eテスト: • ユーザーは電話番号にSMSを送信できる。 • ユーザーが不正な電話番号を指定すると、エラーが表示される。 • 多要素認証を有効にしていないユーザーには、SMS認証画面が表示されない。 結合テスト : • Twilioのテスト用番号を使って正常系/異常系のテストをする。 探索的テスト : • 30分 3~5人 出来るだけ幅広いモバイルキャリア、OSを準備する • 目的: モバイルキャリアや端末に依存する問題を見つける。 ロールアウト : • 日本国内の1%のユーザーに対して有効にし、段階的に範囲を広げる。 テスト自動化から、 開発を支える継続的テストへ - SpeakerDeck
44. • 想定を超えるたくさんのデータ • 複数タブをまたいだ利用 • 複数ユーザーでの同時編集 • スマートフォンからの操作 • 古すぎるブラウザ・デバイスでの操作 • 低速な通信環境 ただのバグとして直すだけでなく、 現実の使われ方 として自動テストも書く 実際の使われ方からも学ぶ
45. ビジネスルールの増加と共に E2Eテストシナリオも増えていく • 各ユーザーストーリーの開発チケットに は自動的にE2Eテスト開発のサブタス ク(チケット)が作成される • E2Eテスト作成完了までは原則開発チ ケットを完了できない仕組み Autify社での例 テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか - SpeakerDeck
46. 複雑さを征服する 05.
47. リファクタリング (Refactoring): ふるまいを変えずに中身を作り変えること 分割統治 (Divide and Conquer) : 複雑なものを小さく分けて 一つずつやっつけていくこと 複雑さへのアプローチ : リファクタリングと分割統治
48. 複雑になってしまったものでも • まず現状のふるまいに対する自動テストを書き • ふるまいを変えずに中身を整理・分割して • 分割したコンポーネントに更にテストを書く このようにして安全に少しずつ変えていける 複雑さへのアプローチ : リファクタリングと分割統治
49. リファクタリングと分割統治 ProcessOrder() - 発送先バリデーション - 在庫引当 - 支払 - 在庫更新 - 注文完了 在庫があり、有効な 支払い方法があれ ば、注文が完了する 在庫が無い場合、注 文できない 無効な発送先の場 合、注文できない 支払方法が無効な場 合、注文できない
50. StockService OrderService リファクタリングと分割統治 ProcessOrder() 在庫があり、有効な 支払い方法があれ ば、注文が完了する 在庫が無い場合、注 文できない 無効な発送先の場 合、注文できない 支払方法が無効な場 合、注文できない validateAddress() reserveStock() processPayment() useReservedStock() updateOrderStatus()
51. StockService OrderService リファクタリングと分割統治 ProcessOrder() 在庫があり、有効な 支払い方法があれ ば、注文が完了する 在庫が無い場合、注 文できない 無効な発送先の場 合、注文できない 支払方法が無効な場 合、注文できない validateAddress() reserveStock() processPayment() useReservedStock() updateOrderStatus() 東京都千代田区千代田1 は有効 横浜県神奈川市1 は無効 未注文→注文済にできる 注文済→注文済にできない 在庫が1のとき1つ予約できる 在庫が1のとき2つ予約できない 予約済みの在庫を減らせる 予約していない在庫は減らせない
52. まとめ
53. • 事業を続けているうちにソフトウェアは変化を繰り返す • 変化を繰り返したソフトウェアは複雑で予測しづらくなることがある • 使い方（使われ方）を具体的に示すコードが自動テスト • 事業と共にアプリケーションと自動テストも変化させる ここまでで話したこと
54. 複雑になってしまったアプリケーションを自動テストで守り アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
55. 内部構造を保守しやすくする アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
56. ユースケースの増大に応じて E2Eテストも増やす アプリケーション サードパーティー コンポーネント ユーザー E2Eテスト UI 公開 API APIテスト
57. システムそのものの複雑さや信頼性を 自動テストで担保するには限界がある もちろん、銀の弾丸はない どちらもAutifyの同僚が訳しています
58. なに、上司や同僚が品質の大事さを理解してくれない？
59. お、自動テスト興味ありますか？
60. え、自動テスト挫折しちゃったんですか？ AIを用いたノーコードテスト自動化ツール
61. ご清聴ありがとうございました Enjoy Testing! おあとがよろしいようで