Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
いかにしてテスト文化を醸成させたか.pdf
Search
takayuki-hayashi
November 11, 2019
Technology
1.6k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
いかにしてテスト文化を醸成させたか.pdf
SPEEDA Testing Dayでの発表資料です。
takayuki-hayashi
November 11, 2019
More Decks by takayuki-hayashi
See All by takayuki-hayashi
E2Eの過去・現在・未来 そしてE2Eにおいて重要なこと
takayukihayashi
1
520
リーダー、マネージャーが存在しない開発組織のつくり方
takayukihayashi
1
29k
AngularDartでDart入門
takayukihayashi
1
1k
E2Eテスト駆動開発実践記_-_Web用.pdf
takayukihayashi
2
3.5k
KubernetesとGaugeを活用したTDD開発事例
takayukihayashi
0
1k
FlutterとAngularDartを DIとClean Architectureで いい感じにする
takayukihayashi
3
2.3k
Gaugeによるe2eテスト
takayukihayashi
5
29k
Dartエコシステムの紹介
takayukihayashi
2
690
Other Decks in Technology
See All in Technology
Confitura 2026
logico_jp
0
110
営業オントロジーの作り方と、エージェントからの辿り方 ── ナレッジワークの現場から
kworkdev
PRO
1
210
MCPゲートウェイを作って運用してわかったこと — Agent時代の権限管理の現在地
mtpooh
6
1.8k
顧客の成果創出とプロダクトの成長を 両立するためのFDE
sansantech
PRO
0
520
高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜
maimyyym
2
830
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
240
大阪オフィスに Unitree Go2 がやってきたので Physical AI やってみた
dafujii
0
160
スキルを作る、その前に!複数人で使われるスキルを 作るためのプロセス
junkifurukawa
1
120
spanner-autoscalerに学ぶ CRD設計パターン 〜自動化と緊急時対応を両立する Kubernetesコントローラーの作り方〜
tkuchiki
0
210
Apache Iceberg が拓く AI 時代のオープンレイクハウス
tomtanaka
0
200
Coil3を内部実装から読み解く~キャッシュ戦略とAVIF画像の描画〜/nikkei-tech-talk50
nikkei_engineer_recruiting
0
180
いちAWSエンジニアのAI活用を振り返る #devio2026 / devio osaka 2026 kawahara
masahirokawahara
1
290
Featured
See All Featured
Optimizing for Happiness
mojombo
378
71k
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
910
Evolving SEO for Evolving Search Engines
ryanjones
0
300
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Designing for Timeless Needs
cassininazir
1
510
How to Ace a Technical Interview
jacobian
280
24k
The untapped power of vector embeddings
frankvandijk
2
1.9k
Building Applications with DynamoDB
mza
96
7.2k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
440
Transcript
いかにしてテスト文化を醸成させたか 〜SPEEDA事業におけるテストの話〜
自己紹介 • 林 尚之(はやし たかゆき) @t_hyssh • 株式会社ユーザベース ◦ SPEEDA事業
CTO • Agile(XP)、ペアプロ、TDD、DDD • 最近使ってる言語はDart、Kotlin、OCaml等
現在に至るまでの流れ
黎明期 2013年〜
黎明期 〜当時の状況〜 ビジネスをより加速させる上で開発生産 性を上げたいと思っている開発責任者 手動テストに疲弊して現状をなんとかしたいと 思っているQAメンバー 出典:いらすとや
黎明期 〜当時の状況〜 林さん、なにか 案ありません か? アジャイルやりましょ う!(ニヤリ) 出典:いらすとや 注)一応この時点でアジャイル開発 の経験は5年ほどありました。
黎明期 〜結果〜 • E2Eはアジャイル(XP)という文脈で始めた • 意欲のあるメンバーを集めて小さなチームで実施 ◦ 新機能の部分のみE2Eを書き始める • 結果は好評
◦ ただし、好評だったがゆえに次の停滞期を迎えることに・・・・
停滞期 2015年〜
停滞期 〜当時の状況〜 そうだ!E2Eとして自動化さ れてない部分(過去に作った 機能)は全部オフショアに出し ましょう! う〜ん、大丈夫だろうか・・・・ 出典:いらすとや
停滞期 〜結果〜 • 納品されたのはまともに動かないテストコード ◦ 動かすためにかなりのコストを掛ける事に・・・ ◦ この時の不安定なテストには今でも悩まされる事に • そもそもオフショアで正しく成果を出すための準備がこちら側に出来ていなかった
◦ 単に単価が低いからという理由で出してしまったオフショアのアンチパターン
成長期 2017年〜現在
成長期 Gaugeと出会う(ドキュメントとしての表現力がとても良い)
成長期 〜現在〜 • マイクロフロントエンドで新規開発する部分は全てGaugeでE2Eを記述 ◦ ドキュメントとしての表現能力の大幅向上 ◦ モノリシックの部分(オフショアに出した部分も含め)は最低限の保守のみ • Docker、k8sを活用し、再現性を高める
• デプロイメントパイプラインの整備 • 並列実行によるテスト時間の短縮 • コンシューマー駆動契約テストの取り組み(やりたい)
重視している事(3つ)
1. 成果(信頼)
2. 実感
3. 実践
成果(信頼) • 必ず成果を出す ◦ 成果とは「ある事をして得られた良い結果」 ◦ 特にビジネスサイドの人からもわかりやすい成果を出す ▪ 例:バグが少ない、手動テスト時間やリリースサイクルの短縮等 ◦
成果を出すためにも 小さく、細かく始める ▪ 可能であればスパイクを打つ • 成果を出すことによって信頼を得る ◦ 信頼を得られればより広い範囲で E2Eを適用出来るはず ◦ SeleniumとかGaugeがどうこうとかより重要な事 ▪ 自分(達)が今持っているスキルを最大限活かす ▪ 最初のタイミングでチャレンジしすぎると失敗する可能性が高まる
実感 • E2Eに直接関わる人に良さを実感してもらう ◦ ソフトウェアエンジニア、テストエンジニア等 ◦ E2Eを書く人自身が「書いた方が良い」と思える状態にしなければ上手く行かない • Greenを保つ ◦
難易度は高いがこれが実現出来なければ E2Eが形骸化してしまう • 頻繁に実行する ◦ デグレの早期発見 • リファクタリングをする ◦ ここでのリファクタリングはテストのソースコードではなく、テスト対象のソースコード ▪ 「Green維持すればいくらでもリファクタリング出来るね!」というのを実感してもらう
実践 • 何よりも自分自身が第一の実践者となる
まとめ
同じ志や課題感を持つ人を集め、少しずつ確実に成 果を出して実感、信頼を得られるように進める 「それができれば苦労はしないよ!」という声が聞こえてき そうです・・・・。でも、やっぱり「銀の弾丸」も無いのも事 実。。。
ご清聴ありがとうございました。