Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト自動化ことはじめ
Search
tsuemura
September 13, 2024
3
270
テスト自動化ことはじめ
Forkwell Library #65 テスト自動化実践ガイド ー 継続的にWebアプリケーションを改善するための知識と技法
2024/09/11
tsuemura
September 13, 2024
Tweet
Share
More Decks by tsuemura
See All by tsuemura
E2Eテストのシナリオと抽象化の粒度の話.pdf
tsuemura
6
530
ようこそ、ソフトウェアテストの世界へ!
tsuemura
1
63
リーダブルなE2Eテストコードのための3つのC
tsuemura
7
1k
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
tsuemura
12
28k
60分で学ぶE2Eテスト(実装編)
tsuemura
0
380
全部乗せフレームワーク CodeceptJS でE2Eテストを楽にしよう
tsuemura
7
5.2k
10年前に初めてVBAで業務自動化したときの思い出
tsuemura
1
14k
テストを自動化するのをやめ、自動テストを作ろう
tsuemura
71
34k
How can we improve the testability of applications?
tsuemura
0
970
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
Site-Speed That Sticks
csswizardry
1
150
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Scaling GitHub
holman
458
140k
It's Worth the Effort
3n
183
27k
The Pragmatic Product Professional
lauravandoore
32
6.3k
We Have a Design System, Now What?
morganepeng
51
7.3k
How to Ace a Technical Interview
jacobian
276
23k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
890
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Transcript
テスト自動化ことはじめ 末村 拓也 @ Autify, Inc. 2024-9-11 Forkwell Library #65
自己紹介 末村 拓也 X: @tsueeemura Quality Evangelist at Autify, Inc.
開発からマーケティングまで全部やる方のフルスタ ックエンジニア テトリスとメカニカルキーボードが好き
ちょっとおしらせ 9/18(水 ) Developers Summit 2024 Kansai に行きます 一瞬だけ喋るのと、サイン会があります 気軽に声かけてください
テスト自動化実践ガイド 2024/7/31発売 三部構成で、テスト自動化を 始める前から運用まで広くカバー 第 1部 自動テストに取り組む前に 第 2部 アプリケーションに E2Eテ ストを導入する
第 3部 自動テストを改善するテク ニック 今なら翔泳社 SE Shop で 紙書籍 50%ポイント還元!
第 1部 自動テストに取り組む前に 第 1章 テストの目的 第 2章 開発を支える自動テスト 第 3章
見つけたいバグを明確にする 第 4章 E2Eテストとは何か
第 2部 アプリケーションに E2Eテ ストを導入する 第 5章 サンプルアプリケーションのセッ トアップ 第 6章
最小限のテストをデプロイする 第 7章 ビジネスプロセスをカバーするテ ストを作成する 第 8章 ユーザーストーリーをカバーする テストを作成する 第 9章 テストコードに意図を込める
第 3部 自動テストを改善するテク ニック 第 10章 トラブルシューティング 第 11章 もっと幅広く E2Eテストを使う
第 12章 成果を振り返る
こだわりポイント 自動テストを始める前のところにボリュ ームを割きました 手動テストをただ自動化するだけで は不十分です やり方だけでなく、考え方を身につ けるのが大事です レガシーなアプリケーションにも適用で きるように なるべく汎用的な書き方にしました
わざわざサンプルでレガシーコード を書いています ちゃんとテストしてないから、多分 すごいバグがあると思う ……
今日話すこと 書籍第一部〜第二部からかいつまんで話します テストとは何か どのテストを自動化したいのか 自動リグレッションテストの重要性 手動テストと自動テストのギャップ E2Eテストとは何か
テストとは何か
テストとは いろんなテストがあるよね プログラマーにとっては単体テスト(ホワイトボックステスト) テスターにとってはブラックボックステスト ビジネスサイドにとっては監視 マーケターにとっては A/Bテスト etc
アジャイルテスト の四象限 様々な観点から テスト =評価を 分類した図
どのテストを自動化したいのか
自動化したいテスト (1) 仕様通りに動作することをのチェック 単体テスト コンポーネントテスト 受け入れテスト
自動化したいテスト (2) ルールやアルゴリズムに基づいたチェック プロパティベースドテスト メタモルフィックテスト ビジュアルリグレッションテスト アクセシビリティテストの一部
手動でやりたいテスト ユーザビリティテスト 探索的テスト プロトタイプシミュレーション
何を自動化したいのかを見極める リリース前の単体・コンポーネントレベルの機能テストを自動化したい パフォーマンスの問題をユーザーより早く見つけたい ブラウザごとの画面表示の違いを効率よく検出したい etc
自動リグレッションテストの重要性
開発は続くよ、どこまでも 一度テストすれば終わりというわけではない バージョンが上がるたびにテストは必要になる 影響範囲が定められれば良いが、大抵の場合影響範囲を完全に特定するのは困難 例)フレームワークのアップデートは影響範囲が極めて大きいものの例
開発とテストの労力の不均衡
リソースとのせめぎあい 手動でテストしていると、どうしても範囲や頻度を狭めなくてはならないシーンが出てくる 毎日テストするのは無理だから、毎週、毎月、四半期ごとのテスト 全てのパスをテストするのは無理だから、ハッピーパスだけのテスト すると、自信をもって変更が出来なくなる ソフトウェアの 変更容易性 が低くなる
自動テストは変更容易性を保つためにある 自動テストの直接的な効能のうち、最も大きなものは 自信を持ってリリースするのに必要な量のテストを 現実的な作業量に抑えること
手動テストと自動テストのギャップ
手動テストは柔軟で発見的 手動テストは要件やテスト対象の変化に対して柔軟 手動テストは発見的な動きを取れる 「テストケースに書いてなくても、何かおかしいことあったら教えて!」
自動テストは厳密で保証的 自動テストは決められた要件やテスト対象の振る舞いを厳密に確認する 自動テストは保証的に動く
実行サイクルの違い
None
None
None
手動テストと自動テストの違い
レベル 1: 手動テストの自動化 手動でやっていたものをそのまま自動化する 手動でやっていたときほどバグが見つからなくなる 結果が非決定的で、動作が不安定 副作用が多い 遅い
レベル 2: 目的を絞った自動テスト テスト対象の機能や目的を絞ってテストする 結果が決定的で安定している 副作用が少ない /まったくない 早い
レベル 1とレベル 2は行ったり来たりする 自動テストの実装だけでなく、アプリケーション側のテスタビリティに依存する部分も ある データの準備やクリーンアップ 状態の再現 最初にレベル 1のテストを書いて、それを元にリファクタリングして、レベル 2のテスト
を増やしていく
E2Eテストとは何か
E2Eテストの特徴 ユーザーインターフェースを操作点・観測点として用いる ユーザーストーリーやユースケースなど、ユーザーが価値を達成する手順をテストベー スとする 完全、または大部分が統合されたシステムをテスト対象として用いる ユーザーストーリーの失敗など、ユーザーにとっての価値未達成の発見を主な目的とす
E2Eテストの良い点 幅広い用途に利用できる ブラウザやデバイスの 互換性テスト 仕様化テスト 生きたドキュメント 監視
E2Eテストの良い点 ユーザーにとっての価値をそのままテストできる 様々なレベルのテストベースを扱える 会員登録などの 機能 会員登録〜商品購入までの ビジネスプロセス
E2Eテストの辛い点 (1) 難易度 自動化そのものの難易度が高め テストツールが複雑 ブラウザ ブラウザ自動操作 複雑なシステムには当然バグがある テスト対象のバグと、テストツールのバグを両方扱わないといけない 自動テスト実行中だけ
Maximum call stack exceeded エラーが連発する、みた いな経験は大体の自動化エンジニアが経験している 辛い
E2Eテストの辛い点 (2) テスタビリティ テストしやすさに配慮する余地が少ない UIはどんなソフトウェアにもあるが、 UIを テストしやすくする のは難しい テストのために UXを犠牲にするなんてことはできない
E2Eテストの辛い点 (3) 可読性 どこのページにいるのか、どのユーザーでログインしているのか いまやっているのはテストなのか準備なのか 何を操作しようとしているのか E2Eテストは何も考えずに書くとゴリゴリの手続き型プログラミングになるので テストコードが長くなるほど覚えておくことが多くなる = 認知負荷が高い
E2Eテストを成功させるために テストベッドを出来るだけシンプルに設計し テスタビリティを考慮し ときには別のテストレベル(単体テスト等)に移譲し 可読性に気を配る
まとめ いろんな種類のテストがある 自動化したいテストとそうでないテストがある ただ自動化するでは開発を支えるようなテストにならない E2Eテストは一番ユーザー目線のテスト E2Eテスト特有の辛さを改善するには色々技術が要る
いかがでしたか?
他にもこんな話が書いてあります 自動テスト実装のハンズオン トラブルシューティング 高度なユースケース 振り返り
過去の資料もどうぞ テストを自動化するのをやめ、自動テストを作ろう 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?
感想・コメントをお寄せください サポートサイト https://github.com/tsuemura/practical-guide-for-test-automation-support 書籍冒頭に書いてあるんですが、意外と目立たないのか、気付かれていないことが多そう 良く分からないで ★1付けられるよりも たくさん質問して分かってもらったほうがありがたいです
Enjoy Testing!