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

by tsuemura

Slide 1

Slide 1 text

テスト自動化ことはじめ末村拓也 @ Autify, Inc. 2024-12-12 オープンロジ凱旋公演

Slide 2

Slide 2 text

誰末村拓也 X: @tsueeemura Quality Evangelist at Autify, Inc. 開発からマーケティングまで全部やる方のフルスタックエンジニアテトリスとメカニカルキーボードが好き ex-OPENLOGI

Slide 3

Slide 3 text

思い出と略歴

Slide 4

Slide 4 text

略歴(1) 新卒〜エンジニア転身 2010年ぐらい文系大学卒業後、ギリギリ内定が出た文具問屋に入社総合職採用で「営業と倉庫どっちがいい？」と言われ、営業が嫌なので倉庫へ後に倉庫が「営業で成績が出なかった人の受け皿」なのを知る毎朝3時間ぐらいExcel作業があってキレたのでVBAで自動化、10分で終わるようになる 2015年ぐらい味をしめてエンジニア転身もともとは事業マネージャーとしての採用だったが、色々ありPHPコードのメンテナンスをするように開発環境が無く、ステージングで修正して本番にコピペするデプロイにキレたので Git入れたり色々改善

Slide 5

Slide 5 text

略歴(2) 物流スタートアップ 2017年ぐらい「物流ドメイン知識とITスキルがあるな……」などと考えながら職探しをしていたら偶然にも某物流スタートアップを見つけて転職最初は倉庫を回るのが仕事だったが、徐々にQAに軸足を映すモダンな開発文化をたくさん知り、エンジニア人生の礎となった

Slide 6

Slide 6 text

余談 - サイコパス疑惑

Slide 7

Slide 7 text

略歴 (3) バズり〜Autify転職バズった我が名は神龍……どんなテストもひとつだけ自動化してやろう #JavaScript - Qiita これが名刺代わりになり色んなイベントに参加・登壇するように QAの友達が増えた夜中にTwitter見てたらテスト自動化エンジニアの募集がノリで応募したら受かってしまった当初は自分含めて5人だけ

Slide 8

Slide 8 text

略歴(4) フルスタックエンジニアへの道初期はしっちゃかめっちゃかで、プリセールスから開発、サポートまでなんでもござれその後徐々にテクニカルサポートに軸足を移す自動テストあるあるの「なぜか動かない」にひたすらパッチを当てる作業地味だが、競合優位となるmoat（堀）を作る重要な役目後にQAになるが、開発チームが優秀すぎて「あれ、これQA要らなくね？」となり離脱現在はマーケティングに軸足を置きつつ、再び何でも屋に

Slide 9

Slide 9 text

本

Slide 10

Slide 10 text

テスト自動化実践ガイド 2024/7/31発売三部構成で、テスト自動化を始める前から運用まで広くカバー第1部　自動テストに取り組む前に第2部　アプリケーションにE2Eテストを導入する第3部　自動テストを改善するテクニック

Slide 11

Slide 11 text

第1部　自動テストに取り組む前に第1章テストの目的第2章開発を支える自動テスト第3章見つけたいバグを明確にする第4章 E2Eテストとは何か

Slide 12

Slide 12 text

第2部　アプリケーションにE2Eテストを導入する第5章サンプルアプリケーションのセットアップ第6章最小限のテストをデプロイする第7章ビジネスプロセスをカバーするテストを作成する第8章ユーザーストーリーをカバーするテストを作成する第9章テストコードに意図を込める

Slide 13

Slide 13 text

第3部　自動テストを改善するテクニック第10章トラブルシューティング第11章もっと幅広くE2Eテストを使う第12章成果を振り返る

Slide 14

Slide 14 text

こだわりポイント自動テストを始める前のところにボリュームを割きました手動テストをただ自動化するだけでは不十分ですやり方だけでなく、考え方を身につけるのが大事ですレガシーなアプリケーションにも適用できるようになるべく汎用的な書き方にしましたわざわざサンプルでレガシーコードを書いていますちゃんとテストしてないから、多分めっちゃバグがあると思う

Slide 15

Slide 15 text

今日話すこと書籍第一部からかいつまんで話しますどのテストを自動化したいのか自動リグレッションテストの重要性手動テストと自動テストのギャップ E2Eテストとは何か

Slide 16

Slide 16 text

どのテストを自動化したいのか

Slide 17

Slide 17 text

自動化したいテスト (1) 仕様通りに動作することのチェック単体テストコンポーネントテスト受け入れテスト

Slide 18

Slide 18 text

自動化したいテスト (2) ルールやアルゴリズムに基づいたチェックプロパティベースドテストメタモルフィックテストビジュアルリグレッションテストアクセシビリティテストの一部

Slide 19

Slide 19 text

手動でやりたいテストユーザビリティテスト探索的テストプロトタイプシミュレーション

Slide 20

Slide 20 text

何を自動化したいのかを見極めるリリース前の単体・コンポーネントレベルの機能テストを自動化したいパフォーマンスの問題をユーザーより早く見つけたいブラウザごとの画面表示の違いを効率よく検出したい etc

Slide 21

Slide 21 text

自動リグレッションテストの重要性

Slide 22

Slide 22 text

開発は続くよ、どこまでも一度テストすれば終わりというわけではないバージョンが上がるたびにテストは必要になる影響範囲が定められれば良いが、大抵の場合影響範囲を完全に特定するのは困難例）フレームワークのアップデートは影響範囲が極めて大きいものの例

Slide 23

Slide 23 text

開発とテストの労力の不均衡

Slide 24

Slide 24 text

リソースとのせめぎあい手動でテストしていると、どうしても範囲や頻度を狭めなくてはならないシーンが出てくる毎日テストするのは無理だから、毎週、毎月、四半期ごとのテスト全てのパスをテストするのは無理だから、ハッピーパスだけのテストすると、自信をもって変更が出来なくなるソフトウェアの変更容易性が低くなる

Slide 25

Slide 25 text

自動テストは変更容易性を保つためにある自動テストの直接的な効能のうち、最も大きなものは自信を持ってリリースするのに必要な量のテストを現実的な作業量に抑えること

Slide 26

Slide 26 text

手動テストと自動テストのギャップ

Slide 27

Slide 27 text

手動テストは柔軟で発見的手動テストは要件やテスト対象の変化に対して柔軟手動テストは発見的な動きを取れる「テストケースに書いてなくても、何かおかしいことあったら教えて！」

Slide 28

Slide 28 text

自動テストは厳密で保証的自動テストは決められた要件やテスト対象の振る舞いを厳密に確認する自動テストは保証的に動く

Slide 29

Slide 29 text

実行サイクルの違い

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

手動テストと自動テストの違い

Slide 34

Slide 34 text

E2Eテストとは何か

Slide 35

Slide 35 text

E2Eテストの特徴ユーザーインターフェースを操作点・観測点として用いるユーザーストーリーやユースケースなど、ユーザーが価値を達成する手順をテストベースとする完全、または大部分が統合されたシステムをテスト対象として用いるユーザーストーリーの失敗など、ユーザーにとっての価値未達成の発見を主な目的とす

Slide 36

Slide 36 text

E2Eテストの良い点幅広い用途に利用できるブラウザやデバイスの互換性テスト仕様化テスト生きたドキュメント監視

Slide 37

Slide 37 text

E2Eテストの良い点ユーザーにとっての価値をそのままテストできる様々なレベルのテストベースを扱える会員登録などの機能会員登録〜商品購入までのビジネスプロセス

Slide 38

Slide 38 text

E2Eテストの辛い点 (1) 難易度自動化そのものの難易度が高めテストツールが複雑ブラウザブラウザ自動操作複雑なシステムには当然バグがあるテスト対象のバグと、テストツールのバグを両方扱わないといけない自動テスト実行中だけ Maximum call stack exceeded エラーが連発する、みたいな経験は大体の自動化エンジニアが経験している辛い

Slide 39

Slide 39 text

E2Eテストの辛い点 (2) テスタビリティテストしやすさに配慮する余地が少ない UIはどんなソフトウェアにもあるが、UIをテストしやすくするのは難しいテストのためにUXを犠牲にするなんてことはできない

Slide 40

Slide 40 text

E2Eテストの辛い点 (3) 可読性どこのページにいるのか、どのユーザーでログインしているのかいまやっているのはテストなのか準備なのか何を操作しようとしているのか E2Eテストは何も考えずに書くとゴリゴリの手続き型プログラミングになるのでテストコードが長くなるほど覚えておくことが多くなる = 認知負荷が高い

Slide 41

Slide 41 text

E2Eテストを成功させるためにテストベッドを出来るだけシンプルに設計しテスタビリティを考慮しときには別のテストレベル（単体テスト等）に移譲し可読性に気を配る

Slide 42

Slide 42 text

まとめいろんな種類のテストがある自動化したいテストとそうでないテストがあるただ自動化するでは開発を支えるようなテストにならない E2Eテストは一番ユーザー目線のテスト E2Eテスト特有の辛さを改善するには色々技術が要る

Slide 43

Slide 43 text

いかがでしたか？

Slide 44

Slide 44 text

他にもこんな話が書いてあります自動テスト実装のハンズオントラブルシューティング高度なユースケース振り返り

Slide 45

Slide 45 text

過去の資料もどうぞテストを自動化するのをやめ、自動テストを作ろう 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?

Slide 46

Slide 46 text

感想・コメントをお寄せくださいサポートサイト https://github.com/tsuemura/practical-guide-for-test-automation-support 書籍冒頭に書いてあるんですが、意外と目立たないのか、気付かれていないことが多そう「良く分からなかった、★1」が一番キツイですたくさん質問して分かってもらえるとありがたいです

Slide 47

Slide 47 text

Q&A

Slide 48

Slide 48 text

> 素朴なテスト自動化と開発を支える自動テストの違いがいまいちピンと来なかった。違いは実行するタイミング（実行頻度）のみ？そもそも、手動テストの実行頻度、粒度は果たして最適なのだろうか人的工数に対しての最適化を行っていないだろうか開発やリリースを手動テストに合わせに行ってないだろうか本来テストすべきタイミングでテスト出来ていないのではないか

Slide 49

Slide 49 text

ソフトウェアが「ちゃんと動く」状態になるべきなのはどのタイミング？理想的には、V字モデルの底に来た時点でちゃんと動くようになっていてほしい手動テストをただ自動化するだけだと手動テスト向けに最適化された実行頻度や粒度をそのまま持ってきてしまう手動テストの制約に合わせた開発・リリースプロセスを変えずに進んでしまう（やり方によっては）手動テストよりもテストの質が落ちてしまうダメではないが、とてももったいない

Slide 50

Slide 50 text

開発を支える自動テストとはソフトウェアがちゃんと動く（Production-ready）であることを継続的に確認するためのもの開発の非常に早い時期から実行可能で、開発者がセルフチェックに使えるようなもの V字モデルの底できちんとテストできるようなもの違いは何？主に実行頻度とタイミングそしてそれらを支える実行速度、独立性、信頼性、可搬性遅いテストは頻繁に実行できない独立していないテストは並列実行できない信頼できないテストは実行されなくなる可搬性の低いテストは一部の環境でしか実行できない

Slide 51

Slide 51 text

> 単体テストであっても、開発者の関心事だけをテストしたいわけでは無いのでは？ディスカッションしたいとのことなので、一旦考えを聞いてみましょう

Slide 52

Slide 52 text

> 単体テストであっても、開発者の関心事だけをテストしたいわけでは無いのでは？末村の考え単体テストで扱う「単体」がユーザーに露出することは無いユーザーにとっての関心事はUIを通してしか露出しないここでの関心事とは、バリデーションロジックなどの詳細ではなく、バリデーションを通る/ 通らないを指す Tips: 単体テストを「ホワイトボックステスト」だと言うことがあるがこれは誤りテスト設計はブラックボックスでやるべき JSTQB FLシラバスからは「ホワイトボックス/ブラックボックステスト」が削除された

Slide 53

Slide 53 text

> ドキュメントを残すか問題はどこの会社でも起こることだけど、末村さん個人としてはdocxなどで静的に残すべきか、仕様化テストなどの動くものとして残すべきか、見解があれば聞いてみたい仕様はルール、テストは例なので、役割が違う。別々に残しておくべき。しかし、マニュアルや仕様など開発の外側にあるものはたいていメンテされなくなる仕様とテストをトレーサブルに残しておけるフレームワークが必要現状の最適解はBDDだと思うが、もっと進歩させたやり方を模索していきたい

Slide 54

Slide 54 text

どのタイミングでどんなCIを行えばよいか気になる（アーキテクチャによるとは思うけど）理想はPRごとに全部回す、現実はTier付けをしてリリースごとに判断する P1は必ず回す、P2以下は状況に応じて回す

Slide 55

Slide 55 text

> E2Eのメンテナンスコストを下げるためのルールなどについての具体例があれば知りたいと思った作りすぎない何をどのテストレベルで見つけるかルールを決める開発者を巻き込むテスタビリティは開発者が作るもの

Slide 56

Slide 56 text

Enjoy Testing!