Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
カイゼンと僕とE2Eテスト
02
November 30, 2019
Programming
0
46
カイゼンと僕とE2Eテスト
2019/11/30 システムテスト自動化カンファレンス2019 LT枠にてお話ししたスライドです。
02
November 30, 2019
Tweet
Share
More Decks by 02
See All by 02
コミットメッセージ規約 「Conventional Commits」を導入してみよう! / Let's use Conventional Commits
cocoeyes02
5
5.8k
Composer 2.0 新機能概論 / New feature introduction of Composer 2.0
cocoeyes02
1
1.6k
「登壇できない」それ本当ですか? / You cannot become conference speaker ... Is it true?
cocoeyes02
0
1.3k
事業フェーズから見る若手エンジニアの生存戦略 / Survival strategy of youth engineer from the point of view of business phase
cocoeyes02
0
1.1k
リーダブルコミットのすゝめ / Recommendation of Readable Commit
cocoeyes02
5
4k
テストピラミッドを意識したテストコード実装戦略
cocoeyes02
0
630
オンラインホワイトボードサービスmiroが最高すぎるはなし
cocoeyes02
0
110
WACATEとテストと開発エンジニア
cocoeyes02
1
970
PHPerのための テストコード入門.
cocoeyes02
1
2.5k
Other Decks in Programming
See All in Programming
RustのWebフレームワーク周りの概観
hayao
0
180
kintone × LINE Bot で餃子検定Botを作った話
naberina
0
330
atama plusの開発チームはどのように「不確実性」に向き合ってきたか〜2022夏版〜
atamaplus
3
610
테라폼으로 ECR 관리하기 (How to Manage ECR with Terraform)
posquit0
0
520
SwiftUI+TCAに挑戦!NewsPicks iOSアプリのリアーキテクチャ/re-architecture-newspicks-ios-app-with-swiftui-and-tca
takehilo
0
400
ECサイトの脆弱性診断をいい感じにやりたい/OWASPKansaiNight_LT1_220727
owaspkansai
0
290
20220706_Google Apps Scriptを実演で学ぶ~ GAS × Slack ~
apachan
2
620
ゴーファーくんと辿るプログラミング言語の歴史/history-of-programming-languages-with-gopher
iwasiman
11
5k
このタイミングで知っておきたい 開発生産性の高いエンジニア組織の特徴とは / dev-sumi-20220721-productivity-features
findyinc
7
2.6k
Google IO 2022 社内LT会 / What's new in Android development tools
shingo_kobayashi
0
400
SRE NEXT 2022に学ぶこれからのSREキャリア
fukubaka0825
2
390
サーバーレスパターンから学ぶデータ分析基盤構築 / devio2022
kasacchiful
0
490
Featured
See All Featured
Optimizing for Happiness
mojombo
365
64k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
213
11k
We Have a Design System, Now What?
morganepeng
35
3k
Designing the Hi-DPI Web
ddemaree
272
32k
Building Better People: How to give real-time feedback that sticks.
wjessup
344
17k
The Pragmatic Product Professional
lauravandoore
19
3.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
316
22k
Build your cross-platform service in a week with App Engine
jlugia
219
17k
The Illustrated Children's Guide to Kubernetes
chrisshort
18
40k
Bash Introduction
62gerente
598
210k
A designer walks into a library…
pauljervisheath
196
16k
Designing for Performance
lara
597
63k
Transcript
カイゼンと僕と E2E テスト 02 ( 大津 和槻) システムテスト自動化カンファレンス 2019
自己紹介 02 ( 大津 和槻) Twitter: cocoeyes02 株式会社ウィルゲート(新卒2 年目) バックエンドエンジニア
QA 領域にも興味がある(QA エンジニア) 趣味:ジャズ鑑賞、カホン、ゲーム
今日は私が業務で触っている プロダクトの改善について お話をします
テストコード( 主にE2E テスト) メインのお話です
触っているプロダクト 去年リリースされた BtoB 向けの案件管理システム リリース当初から 「業務が止まってしまうような障害が多い」 という大きな問題を抱えていた 当時のマネージャーからも 「なかなかシステム品質が悪い」の一言
触っているプロダクト 去年リリースされた BtoB 向けの案件管理システム リリース当初から 「業務が止まってしまうような障害が多い」 という大きな問題を抱えていた 当時のマネージャーからも 「なかなかシステム品質が悪い」の一言 「よし、カイゼンだ!」
問題:バグが多い バグの発見は手動のシステムテスト頼り 漠然と「システム品質が悪い」と思う状況だった ので、どの機能に問題があるのかわからない
問題:バグが多い バグの発見は手動のシステムテスト頼り 漠然と「システム品質が悪い」と思う状況だった ので、どの機能に問題があるのかわからない 「よし!カイゼンだ!」
対応:E2E テストを導入した 素早く確実にバグを見つけたい、品質を可視化したい → テストコードの導入を検討 しかし、当時ユニットテストを書くにはリファクタリ ングが必要だとされていた 内部処理が複雑になっている リファクタリングの心理的障壁が高い ユニットテストと比べると
内部的なコードをあまり気にせずテストができる E2E テスト(puppeteer) を用意することにした
問題:E2E テスト作る時間が あんまりないよ! 時間がないのはしょうがないとして、そもそも テストコードを作る優先順位がきまってなかった 当時はそもそもテストを使って何を担保したいのか、 テストの目的が定まっていない状況だった
問題:E2E テスト作る時間が あんまりないよ! 時間がないのはしょうがないとして、そもそも テストコードを作る優先順位がきまってなかった 当時はそもそもテストを使って何を担保したいのか、 テストの目的が定まっていない状況だった 「よし!カイゼンだ!」
対応:主要機能の Never Must Want を定めた まず、事業部と開発で整理し、主要機能について以下 をスプレットシートに記入しました あってはならない(Never ) できなければならない(Must
) あったら良い(Want ) テストコードでは「Never が起きていないこと、 Must ができることを担保する」という目的を定めた
問題:E2E テストが全然運用 に乗っていなかった 運用し始めたあと、デザイン変更などが理由で 半分ぐらいの E2E テストが壊れていた
問題:E2E テストが全然運用 に乗っていなかった 運用し始めたあと、デザイン変更などが理由で 半分ぐらいの E2E テストが壊れていた 「よし!カイゼンだ!」
対応:修正 + 結果を見やすく 泥臭く修正した! ただ修正するだけじゃなくて、以下の改良も加えた テスト失敗したときには画面のスクリーンショッ トを取って保存する そもそも何を確認したいE2E テストなのか、 テストケース名を整理して結果に表示する
問題:バッチの挙動は E2E テストで担保できない! E2E テストで担保できている範囲も広くなったが、 流石にここはE2E テストでは担保できない
問題:バッチの挙動は E2E テストで担保できない! E2E テストで担保できている範囲も広くなったが、 流石にここはE2E テストでは担保できない 「よし!カイゼンだ!」
対応:リファクタリングをし て、ユニットテストを導入 バッチ処理をリファクタリングし、重要ロジック部分 をユニットテストで担保した 初めてユニットテストを導入するので、若干リファク タリングはした 改めて、E2E テストで担保すべき場所を見直すことに
問題: 「このプロダクト、 ユニットテスト書けないわけ ではないよ?」「えっ」 02 や設計者以外のチームメンバーが、設計に対する ユニットテスト導入のアプローチを勘違いしていた 大規模なリファクタリングをしなくても、 ユニットテストが導入できる
問題: 「このプロダクト、 ユニットテスト書けないわけ ではないよ?」「えっ」 02 や設計者以外のチームメンバーが、設計に対する ユニットテスト導入のアプローチを勘違いしていた 大規模なリファクタリングをしなくても、 ユニットテストが導入できる 「よし!カイz
「あ、02 くん来月から別のチーム と兼任になるので稼働半分ぐらい減るからね」 「えっ」
to be continued...
今後アプローチしたいこと
指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい ユニットテストにかかる工数を見積もりたい 優先度の高い機能から見積もりをし、チケット化 する E2E テストの範囲に含まれているところから手をつ けると良いかも
指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい テストコード指針を書きたい UI(E2E) テスト、結合(feature, API) テスト、ユニッ トテストで得意領域と苦手領域は違うはず Never
Must を見て、どの機能をどのテストで担保 するのかだけは書いておく
指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい 各テストの書き方マニュアルを用意する 簡単なハンズオンリポジトリみたいなのも用意し ても良いかも?
カイゼンに終わりはない オレたちのカイゼンは これからだ!!
Thank You For Listening! Twitter: cocoeyes02 Github: cocoeyes02