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
85
カイゼンと僕と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
250
BASEにおける インシデント対応フローと工夫
cocoeyes02
0
640
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.4k
テスト駆動開発本をPHPで写経してみた / Copy Test Driven Development Code by PHP
cocoeyes02
0
300
テストコードリーディングのみで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
5
8.4k
Composer 2.0 新機能概論 / New feature introduction of Composer 2.0
cocoeyes02
1
2.2k
Other Decks in Programming
See All in Programming
VS Code をプロダクトにどう取り込むか
onomax
1
490
Introducing Kotlin Multiplatform in an existing mobile app - Workshop Edition | AndroidMakers Paris
prof18
0
120
Blue/Greenデプロイの導入による 運用フローの改善
kudoas
1
390
使ってみよう Azure AI Document Intelligence
kosmosebi
2
330
Micro Frontends for Java Microservices - Devnexus 2024
mraible
PRO
0
500
大規模Reactアプリのリアーキテクチャ~8万行のTanStack Query移行の軌跡~
kj455
4
980
スキーマ駆動開発による品質とスピードの両立 - 私達は何故、スキーマを書くのか
kentaroutakeda
0
170
PHP8.3の機能を振り返る / Review of PHP 8.3 features
seike460
PRO
1
110
Azure OpenAI Serviceのプロンプトエンジニアリング入門
tomokusaba
3
810
2 週間で Twitter Bot を作ってみた
contour_gara
0
680
デフォルトにして至高、RubyMineの大好きな所
ruzia
0
500
GitHub Copilotのススメ
marcy731
1
200
Featured
See All Featured
A designer walks into a library…
pauljervisheath
201
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Six Lessons from altMBA
skipperchong
22
3k
Producing Creativity
orderedlist
PRO
338
39k
From Idea to $5000 a Month in 5 Months
shpigford
378
45k
It's Worth the Effort
3n
180
27k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
Designing for Performance
lara
602
67k
Creatively Recalculating Your Daily Design Routine
revolveconf
211
11k
Why Our Code Smells
bkeepers
PRO
331
56k
How GitHub (no longer) Works
holman
305
140k
Facilitating Awesome Meetings
lara
43
5.6k
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