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
カイゼンと僕とE2Eテスト
Search
02
November 30, 2019
Programming
0
87
カイゼンと僕とE2Eテスト
2019/11/30 システムテスト自動化カンファレンス2019 LT枠にてお話ししたスライドです。
02
November 30, 2019
Tweet
Share
More Decks by 02
See All by 02
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
0
310
BASEにおける インシデント対応フローと工夫
cocoeyes02
0
690
AWS Lambdaから始める Devチームの小さなDevOps改善 〜QCDどれも諦めない運用を目指して〜 / Start to improving small DevOps with AWS Lambda by Dev Team
cocoeyes02
0
1.1k
PHPUnit 10 概論 / Introduction of PHPUnit 10
cocoeyes02
2
5.7k
テスト駆動開発本をPHPで写経してみた / Copy Test Driven Development Code by PHP
cocoeyes02
0
320
テストコードリーディングのみでPHPUnitの仕様を理解してみる / Try to understand PHPUnit specification with test code reading only
cocoeyes02
1
2.3k
カンファレンススピーカー入門〜登壇するぞ!って決めてからトークするまで〜 / How to talk in Tech Conference
cocoeyes02
2
1k
コミットメッセージ規約 「Conventional Commits」を導入してみよう! / Let's use Conventional Commits
cocoeyes02
8
8.5k
Composer 2.0 新機能概論 / New feature introduction of Composer 2.0
cocoeyes02
1
2.2k
Other Decks in Programming
See All in Programming
WinActorの勉強を継続する方法
tamai_63
0
130
酒飲んでたらテックリードになった話
spbaya0141
0
210
mb_trim関数を作りました
youkidearitai
PRO
1
210
教えて!スクラムコーチ品質とスピードのバランスはどうすりゃいいの?
pinboro
0
110
otelcol receiver 自作RTA / Pepabo Tech Conference #22 春のSREまつり
arthur1
0
940
Sheets API使ってみた
toshi0383
2
180
GoでParserを書く
karupanerura
3
340
Deep Dive into React Stream/Serialize
mugi_uno
4
860
freeeのエンジニアが 就活で出そうな コーディングテストを 解説してみる
freee
1
170
An adventure of Happy Eyeballs
coe401_
1
140
TypeScriptの型とパフォーマンス (TSKaigi 2024)
ypresto
14
4.5k
ペパボOpenTelemetry革命
pyama86
2
1.1k
Featured
See All Featured
RailsConf 2023
tenderlove
9
580
The Power of CSS Pseudo Elements
geoffreycrofte
62
5k
Design by the Numbers
sachag
274
18k
Code Reviewing Like a Champion
maltzj
515
39k
The Straight Up "How To Draw Better" Workshop
denniskardys
228
130k
Adopting Sorbet at Scale
ufuk
69
8.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
Why Our Code Smells
bkeepers
PRO
331
56k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.7k
How to train your dragon (web standard)
notwaldorf
75
5.2k
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