Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自動テストの成果と失敗談
Search
hashi
March 13, 2024
0
220
自動テストの成果と失敗談
hashi
March 13, 2024
Tweet
Share
More Decks by hashi
See All by hashi
手動 × ローコード × コードベース: 3つのアプローチをつなぐ実践 @JaSST'25 Tokyo
ryotakahashi
1
2k
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.7k
Bash Introduction
62gerente
614
210k
Faster Mobile Websites
deanohume
308
31k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Visualization
eitanlees
146
16k
A designer walks into a library…
pauljervisheath
207
24k
We Have a Design System, Now What?
morganepeng
53
7.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
How STYLIGHT went responsive
nonsquared
100
5.7k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
880
Transcript
© LayerX Inc. 自動テストの成果と失敗談 JaSST’24 TOKYO Ryo Takahashi
目次 Agenda • 自己紹介 • 本日のテーマ • 3つの課題と改善したこと • よりよい自動テストを行うために
• まとめ
© LayerX Inc. 3 株式会社LayerX 経歴 -バルテス株式会社(2019/04-2021/12) -個人事業主(2022/01-2022/05) -株式会社LayerX(2022/06-) 画像を入れてね
自己紹介 髙橋 諒 (hashi)
4 © LayerX Inc. E2Eテスト自動化をすすめてきた課題感 本日のテーマ テストを しすぎてしまう 実行時間が かかりすぎてしまう
テストが 失敗する -たくさんテストを 作りすぎてしまう -1つのテストで 複数確認をしてしまう -効率よくテストが実行 できていない - テストをメンテナンスしても また失敗してしまう(flaky)
テストをしすぎてしまう
© LayerX Inc. 6 たくさんテストを作りすぎてしまう - 自動テストが増えるとマニュアルテストが楽になる - 失敗したテストが増えると確認する数が増えてしまう -
メンテナンス数も増えすべてのシナリオに目が行き届かなくなる 課題 1つのテストで複数確認をしてしまう - シナリオで”なにを”確認したいのかわからない - ほかの人がテストをみたときに確認内容がわからない - 本来確認したいところ以外でテストが失敗してしまう 課題1.テストをしすぎてしまう
© LayerX Inc. 7 - 目的は マニュアルテストを楽にする < クリティカルなバグを早く検知する こと
- なんでも自動化せず、必要なテストはなにかを開発チームを含め自動化の方針を決める - すでにたくさんある場合は実行しないテストも含めて検討する たくさんテストを作りすぎてしまう=>自動化すべきテストを見直す 改善 1つのテストで複数確認をしてしまう=>テストを分割して確認したいことを1つにする - 1つのテストで確認したいことを1つに決める - 意図しないテストの失敗の確認を減らすことにつながる 課題1.テストをしすぎてしまう
実行時間がかかりすぎてしまう
© LayerX Inc. 9 - 実行時間がかかることですぐにバグ報告があげられない - テスト期間の中でバグ修正が後ろに寄ってしまう バグの検知が遅れる 課題
スケジュールの工面が必要 - 実行時間がかかるので翌日にテストがすべて回りきっていない - 可能な限り休日等を挟むような運用をするなど考慮する場面が発生 課題2.実行時間がかかりすぎてしまう
© LayerX Inc. 10 バグの検知が遅れる=>並列・直列実行の見直し 改善 - テスト実行の仕方を見直す(本当に直列実行でないと回せないテストなのか) - ほかのテストに干渉しないような方法の模索
- テストユーザーを分ける - テスト実装の方法を変更する - 例)順番の制御が効かない->ほかになんらかユニークな情報をもたせることで順番を気に しなくてよいテストにする =>16時間->約9時間までに実行時間の短縮 特にテスト実行の仕方を見直すところで時間がかかっているテストを 並列で実行できるよう変更したことが大きな短縮に繋がった 課題2.実行時間がかかりすぎてしまう
テストが失敗する
© LayerX Inc. 12 テストをメンテナンスしてもまた失敗してしまう - 本来、プロダクトの挙動は問題がないのにテストが失敗しているので確認する工数がかさむ - テストしたいところ以外で失敗しておりテストしたい箇所の確認ができない -
場当たり的なメンテナンスになりやすい 課題 課題3.テストが失敗する
© LayerX Inc. 13 テストをメンテナンスしてもまた失敗してしまう=>シナリオごとに経過を観察する - シナリオごとに実行結果を時系列で確認する - メンテナンスをしているにもかかわらず失敗が続いているシナリオを検知することができる -
成功率を定義することで基準より下回ったテストの実装を見直しをする =>不安定なテストが1.75%減少 改善 課題3.テストが失敗する
よりよい自動テストを行うために
© LayerX Inc. 15 不具合を早く検知するための自動テストの拡充 - E2EテストからAPIテスト,ユニットテストで担保 - 実行時間の短縮 -
UIの変化による影響を受けにくい(テストの保守性) テスト全体のデザイン - テスト自動化有無の判断 - 自動化するテストはどのレイヤーで担保すべきか - プロダクトのフェーズに合わせた自動化方針 - リリース初期のタイミングでコードを書くのか,SaaS等のサービスを使うのかなど よりよい自動テストを行うために 引用:alisterbscott.com
まとめ
© LayerX Inc. 17 - 自動化する対象を決める - 1つのテストで確認したいことは1つに絞る - テストの実行方法を考慮する(並列実行ができないか模索する)
- シナリオごとに実行結果を観察する 自動化をするために まとめ
© LayerX Inc. 18 - 自動化する対象を決める - 1つのテストで確認したいことは1つに絞る - テストの実行方法を考慮する(並列実行ができないか模索する)
- シナリオごとに実行結果を観察する 自動化をするために まとめ とはいえ、まずは「動くテストを作る」ことが第一だと考えます。 テストが増えてきた段階で、もっとよく自動テストが運用できないかを考える際の材料になると幸いです。