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
100
カイゼンと僕とE2Eテスト
2019/11/30 システムテスト自動化カンファレンス2019 LT枠にてお話ししたスライドです。
02
November 30, 2019
Tweet
Share
More Decks by 02
See All by 02
PHP RFC: Deprecate implicitly nullable parameter types をサクッと話す
cocoeyes02
0
210
PHPUnit 11 概論
cocoeyes02
4
1.4k
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
1
690
BASEにおける インシデント対応フローと工夫
cocoeyes02
0
1k
AWS Lambdaから始める Devチームの小さなDevOps改善 〜QCDどれも諦めない運用を目指して〜 / Start to improving small DevOps with AWS Lambda by Dev Team
cocoeyes02
0
1.3k
PHPUnit 10 概論 / Introduction of PHPUnit 10
cocoeyes02
3
8.2k
テスト駆動開発本をPHPで写経してみた / Copy Test Driven Development Code by PHP
cocoeyes02
0
440
テストコードリーディングのみでPHPUnitの仕様を理解してみる / Try to understand PHPUnit specification with test code reading only
cocoeyes02
1
2.6k
カンファレンススピーカー入門〜登壇するぞ!って決めてからトークするまで〜 / How to talk in Tech Conference
cocoeyes02
2
1.2k
Other Decks in Programming
See All in Programming
Amazon S3 NYJavaSIG 2024-12-12
sullis
0
100
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
390
nekko cloudにおけるProxmox VE利用事例
irumaru
3
430
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
190
Zoneless Testing
rainerhahnekamp
0
120
バグを見つけた?それAppleに直してもらおう!
uetyo
0
180
tidymodelsによるtidyな生存時間解析 / Japan.R2024
dropout009
1
790
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
280
KMP와 kotlinx.rpc로 서버와 클라이언트 동기화
kwakeuijin
0
140
CSC305 Lecture 26
javiergs
PRO
0
140
たのしいparse.y
ydah
3
120
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
240
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
95
5.2k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Music & Morning Musume
bryan
46
6.2k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
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