テスト自動化ことはじめ(202412_オープンロジ版) / Enter the testing automation (2024 Dec, for OPENLOGI)

Transcript

1. テスト自動化ことはじめ 末村 拓也 @ Autify, Inc. 2024-12-12 オープンロジ凱旋公演
2. 誰 末村 拓也 X: @tsueeemura Quality Evangelist at Autify, Inc. 開発からマーケティングまで全部やる方のフルスタ ックエンジニア テトリスとメカニカルキーボードが好き ex-OPENLOGI
3. 思い出と略歴
4. 略歴(1) 新卒〜エンジニア転身 2010年ぐらい 文系大学卒業後、ギリギリ内定が出た文具問屋に入社 総合職採用で「営業と倉庫どっちがいい？」と言われ、営業が嫌なので倉庫へ 後に倉庫が「営業で成績が出なかった人の受け皿」なのを知る 毎朝3時間ぐらいExcel作業があってキレたのでVBAで自動化、10分で終わるように なる 2015年ぐらい 味をしめてエンジニア転身 もともとは事業マネージャーとしての採用だったが、色々ありPHPコードのメンテ ナンスをするように 開発環境が無く、ステージングで修正して本番にコピペするデプロイにキレたので Git入れたり色々改善
5. 略歴(2) 物流スタートアップ 2017年ぐらい 「物流ドメイン知識とITスキルがあるな……」などと考えながら職探しを していたら偶然にも某物流スタートアップを見つけて転職 最初は倉庫を回るのが仕事だったが、徐々にQAに軸足を映す モダンな開発文化をたくさん知り、エンジニア人生の礎となった
6. 余談 - サイコパス疑惑
7. 略歴 (3) バズり〜Autify転職 バズった 我が名は神龍……どんなテストもひとつだけ自動化してやろう #JavaScript - Qiita これが名刺代わりになり色んなイベントに参加・登壇するように QAの友達が増えた 夜中にTwitter見てたらテスト自動化エンジニアの募集が ノリで応募したら受かってしまった 当初は自分含めて5人だけ
8. 略歴(4) フルスタックエンジニアへの道 初期はしっちゃかめっちゃかで、プリセールスから開発、サポートまでなんでもござれ その後徐々にテクニカルサポートに軸足を移す 自動テストあるあるの「なぜか動かない」にひたすらパッチを当てる作業 地味だが、競合優位となるmoat（堀）を作る重要な役目 後にQAになるが、開発チームが優秀すぎて「あれ、これQA要らなくね？」となり離脱 現在はマーケティングに軸足を置きつつ、再び何でも屋に
9. 本
10. テスト自動化実践ガイド 2024/7/31発売 三部構成で、テスト自動化を 始める前から運用まで広くカバー 第1部　自動テストに取り組む前に 第2部　アプリケーションにE2Eテ ストを導入する 第3部　自動テストを改善するテク ニック
11. 第1部　自動テストに取り組む前に 第1章 テストの目的 第2章 開発を支える自動テスト 第3章 見つけたいバグを明確にする 第4章 E2Eテストとは何か
12. 第2部　アプリケーションにE2Eテ ストを導入する 第5章 サンプルアプリケーションのセッ トアップ 第6章 最小限のテストをデプロイする 第7章 ビジネスプロセスをカバーするテ ストを作成する 第8章 ユーザーストーリーをカバーする テストを作成する 第9章 テストコードに意図を込める
13. 第3部　自動テストを改善するテク ニック 第10章 トラブルシューティング 第11章 もっと幅広くE2Eテストを使う 第12章 成果を振り返る
14. こだわりポイント 自動テストを始める前のところにボリュ ームを割きました 手動テストをただ自動化するだけで は不十分です やり方だけでなく、考え方を身につ けるのが大事です レガシーなアプリケーションにも適用で きるように なるべく汎用的な書き方にしました わざわざサンプルでレガシーコード を書いています ちゃんとテストしてないから、多分 めっちゃバグがあると思う
15. 今日話すこと 書籍第一部からかいつまんで話します どのテストを自動化したいのか 自動リグレッションテストの重要性 手動テストと自動テストのギャップ E2Eテストとは何か
16. どのテストを自動化したいのか
17. 自動化したいテスト (1) 仕様通りに動作することのチェック 単体テスト コンポーネントテスト 受け入れテスト
18. 自動化したいテスト (2) ルールやアルゴリズムに基づいたチェック プロパティベースドテスト メタモルフィックテスト ビジュアルリグレッションテスト アクセシビリティテストの一部
19. 手動でやりたいテスト ユーザビリティテスト 探索的テスト プロトタイプシミュレーション
20. 何を自動化したいのかを見極める リリース前の単体・コンポーネントレベルの機能テストを自動化したい パフォーマンスの問題をユーザーより早く見つけたい ブラウザごとの画面表示の違いを効率よく検出したい etc
21. 自動リグレッションテストの重要性
22. 開発は続くよ、どこまでも 一度テストすれば終わりというわけではない バージョンが上がるたびにテストは必要になる 影響範囲が定められれば良いが、大抵の場合影響範囲を完全に特定するのは困難 例）フレームワークのアップデートは影響範囲が極めて大きいものの例
23. 開発とテストの労力の不均衡
24. リソースとのせめぎあい 手動でテストしていると、どうしても範囲や頻度を狭めなくてはならないシーンが出てくる 毎日テストするのは無理だから、毎週、毎月、四半期ごとのテスト 全てのパスをテストするのは無理だから、ハッピーパスだけのテスト すると、自信をもって変更が出来なくなる ソフトウェアの 変更容易性 が低くなる
25. 自動テストは変更容易性を保つためにある 自動テストの直接的な効能のうち、最も大きなものは 自信を持ってリリースするのに必要な量のテストを 現実的な作業量に抑えること
26. 手動テストと自動テストのギャップ
27. 手動テストは柔軟で発見的 手動テストは要件やテスト対象の変化に対して柔軟 手動テストは発見的な動きを取れる 「テストケースに書いてなくても、何かおかしいことあったら教えて！」
28. 自動テストは厳密で保証的 自動テストは決められた要件やテスト対象の振る舞いを厳密に確認する 自動テストは保証的に動く
29. 実行サイクルの違い
33. 手動テストと自動テストの違い
34. E2Eテストとは何か
35. E2Eテストの特徴 ユーザーインターフェースを操作点・観測点として用いる ユーザーストーリーやユースケースなど、ユーザーが価値を達成する手順をテストベー スとする 完全、または大部分が統合されたシステムをテスト対象として用いる ユーザーストーリーの失敗など、ユーザーにとっての価値未達成の発見を主な目的とす
36. E2Eテストの良い点 幅広い用途に利用できる ブラウザやデバイスの 互換性テスト 仕様化テスト 生きたドキュメント 監視
37. E2Eテストの良い点 ユーザーにとっての価値をそのままテストできる 様々なレベルのテストベースを扱える 会員登録などの 機能 会員登録〜商品購入までの ビジネスプロセス
38. E2Eテストの辛い点 (1) 難易度 自動化そのものの難易度が高め テストツールが複雑 ブラウザ ブラウザ自動操作 複雑なシステムには当然バグがある テスト対象のバグと、テストツールのバグを両方扱わないといけない 自動テスト実行中だけ Maximum call stack exceeded エラーが連発する、みた いな経験は大体の自動化エンジニアが経験している 辛い
39. E2Eテストの辛い点 (2) テスタビリティ テストしやすさに配慮する余地が少ない UIはどんなソフトウェアにもあるが、UIを テストしやすくする のは難しい テストのためにUXを犠牲にするなんてことはできない
40. E2Eテストの辛い点 (3) 可読性 どこのページにいるのか、どのユーザーでログインしているのか いまやっているのはテストなのか準備なのか 何を操作しようとしているのか E2Eテストは何も考えずに書くとゴリゴリの手続き型プログラミングになるので テストコードが長くなるほど覚えておくことが多くなる = 認知負荷が高い
41. E2Eテストを成功させるために テストベッドを出来るだけシンプルに設計し テスタビリティを考慮し ときには別のテストレベル（単体テスト等）に移譲し 可読性に気を配る
42. まとめ いろんな種類のテストがある 自動化したいテストとそうでないテストがある ただ自動化するでは開発を支えるようなテストにならない E2Eテストは一番ユーザー目線のテスト E2Eテスト特有の辛さを改善するには色々技術が要る
43. いかがでしたか？
44. 他にもこんな話が書いてあります 自動テスト実装のハンズオン トラブルシューティング 高度なユースケース 振り返り
45. 過去の資料もどうぞ テストを自動化するのをやめ、自動テストを作ろう https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi- dong-tesutowozuo-rou コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう https://speakerdeck.com/tsuemura/kontekisutotosemanteikusuwoyi-shi- siteridaburunae2etesutokodowoshu-kou リーダブルなE2Eテストコードのための3つのC https://speakerdeck.com/tsuemura/ridaburunae2etesutokodonotameno3tunoc?
46. 感想・コメントをお寄せください サポートサイト https://github.com/tsuemura/practical-guide-for-test-automation-support 書籍冒頭に書いてあるんですが、意外と目立たないのか、気付かれていないことが多そう 「良く分からなかった、★1」が一番キツイです たくさん質問して分かってもらえるとありがたいです
47. Q&A
48. > 素朴なテスト自動化と開発を支える自動テストの違いがいまいちピンと来なかっ た。違いは実行するタイミング（実行頻度）のみ？ そもそも、手動テストの実行頻度、粒度は果たして最適なのだろうか 人的工数に対しての最適化を行っていないだろうか 開発やリリースを手動テストに合わせに行ってないだろうか 本来テストすべきタイミングでテスト出来ていないのではないか
49. ソフトウェアが「ちゃんと動く」状態になるべきなのはどのタイミング？ 理想的には、V字モデルの底に来た時点でちゃんと動くようになっていてほしい 手動テストをただ自動化するだけだと 手動テスト向けに最適化された実行頻度や粒度をそのまま持ってきてしまう 手動テストの制約に合わせた開発・リリースプロセスを変えずに進んでしまう （やり方によっては）手動テストよりもテストの質が落ちてしまう ダメではないが、とてももったいない
50. 開発を支える自動テストとは ソフトウェアがちゃんと動く（Production-ready）であることを 継続的 に確認す るためのもの 開発の非常に早い時期から実行可能で、開発者がセルフチェックに使えるようなも の V字モデルの底できちんとテストできるようなもの 違いは何？ 主に実行頻度とタイミング そしてそれらを支える実行速度、独立性、信頼性、可搬性 遅いテストは頻繁に実行できない 独立していないテストは並列実行できない 信頼できないテストは実行されなくなる 可搬性の低いテストは一部の環境でしか実行できない
51. > 単体テストであっても、開発者の関心事だけをテストしたいわけでは無いのでは？ ディスカッションしたいとのことなので、一旦考えを聞いてみましょう
52. > 単体テストであっても、開発者の関心事だけをテストしたいわけでは無いのでは？ 末村の考え 単体テストで扱う「単体」がユーザーに露出することは無い ユーザーにとっての関心事はUIを通してしか露出しない ここでの関心事とは、バリデーションロジックなどの詳細ではなく、バリデーションを通る/ 通らないを指す Tips: 単体テストを「ホワイトボックステスト」だと言うことがあるがこれは誤り テスト設計はブラックボックスでやるべき JSTQB FLシラバスからは「ホワイトボックス/ブラックボックステスト」が削除された
53. > ドキュメントを残すか問題はどこの会社でも起こることだけど、末村さん個人とし てはdocxなどで静的に残すべきか、仕様化テストなどの動くものとして残すべき か、見解があれば聞いてみたい 仕様はルール、テストは例なので、役割が違う。別々に残しておくべき。 しかし、マニュアルや仕様など開発の外側にあるものはたいていメンテされなくなる 仕様とテストをトレーサブルに残しておけるフレームワークが必要 現状の最適解はBDDだと思うが、もっと進歩させたやり方を模索していきたい
54. どのタイミングでどんなCIを行えばよいか気になる（アーキテクチャによると は思うけど） 理想はPRごとに全部回す、現実はTier付けをしてリリースごとに判断する P1は必ず回す、P2以下は状況に応じて回す
55. > E2Eのメンテナンスコストを下げるためのルールなどについての具体例があれば知 りたいと思った 作りすぎない 何をどのテストレベルで見つけるかルールを決める 開発者を巻き込む テスタビリティは開発者が作るもの
56. Enjoy Testing!