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
ドメインをスペックにしていく
Search
Koichi Nishide
March 07, 2017
Technology
1
8.1k
ドメインをスペックにしていく
Koichi Nishide
March 07, 2017
Tweet
Share
More Decks by Koichi Nishide
See All by Koichi Nishide
システムテスト自動化カンファレンス2018.pdf
knishide5
1
8.4k
Other Decks in Technology
See All in Technology
Engineer Career Talk
lycorp_recruit_jp
0
130
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
470
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
240
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
490
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
180
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
170
スクラムチームを立ち上げる〜チーム開発で得られたもの・得られなかったもの〜
ohnoeight
2
350
Terraform Stacks入門 #HashiTalks
msato
0
350
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
130
Featured
See All Featured
Making Projects Easy
brettharned
115
5.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Ruby is Unlike a Banana
tanoku
97
11k
Designing the Hi-DPI Web
ddemaree
280
34k
Why Our Code Smells
bkeepers
PRO
334
57k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Transcript
ドメインをスペックにしていく @ichikoich
@ichikoich • 2015年からfreeeでエンジニアしてます ◦ 入社から2年ほど、給与計算freeeのアプリエンジニア ◦ 2017年からQAチームへ • 前職は精密機器メーカーで働いてました
話すこと • 複雑なドメインへの立ち向かい方
freeeの紹介
給与計算freeeを2年間開発してました
給与ってどう計算されてるか知ってますか?
給与明細をみてみる
計算間違いはあってはならない • 従業員へ払う残業代が実際よりも少ない • 年末調整の還付額が少ない • 所得税を少なく計算してしまう etc..
そして、年々変わる料率・制度
散らばるスペック • 単体テストはたくさんあるが、 ◦ それが本当に正しいかはぱっとみわからない ▪ ドメインスペシャリストはコードを見れないし、エンジニアは複雑なドメイン 習得には難航するし、、 ◦ 散らばってるのでリファクタしようとしても、どのテストケースに影響あるかよく
わからない ▪ 制度の改正があるときも同じく テストはRSepcで書いてます
変更を恐れず、どんどんユーザに価値を届けたい
ここから自動化の話
ドメインスペシャリストによるテストが継続的に回る仕組み
フロー 社労士さん エンジニア テストケースの期待結果 テストケース csv - 会社A - 従業員X
- 2017年1月の 給与を計算す る 20,500円やで APIテスト - 従業員登録APIで事 前準備 - 給与明細取得API のレスポンスを確認 デプロイのたびにテ スト
ポイント1 • コードかけなくても自動テストデータを作成できる ◦ Googleスプレッドシート上で社労士さんとやりとりして、一緒にテストケースや データをつくる
ポイント2 • がんがん変更できるように、APIレベルで担保する • Request Specを採用
ドメインスペシャリストが APIテストを書いているイメージ 心強いでしょ?
さらなる効果 • 社労士さんと仲良くなれた • 開発の初期段階で要件漏れを防ぐ効果もでてきた ◦ こういうテストケースを考えてるんですが、他に例外系列やリスクがありそうなところ教えてください ◦ テストケースの結果が返ってき、自分の思ってるのと違うーってなる。よくよく聞いてみると、まだ理 解しきれていないところがあった
◦ 文献や国税庁のHPを読むだけでなく、話してみると気づきはある ◦ チームメンバもよくドメインスペシャリストに相談するようになった
まとめ • ドメインスペシャリストをテストに巻き込む仕組みを作るといいぞ ◦ 複雑なビジネスロジックを教えてもらえる ◦ さらに教えてもらったことが自動テストとして活きてくるので、いいエコサイクルになる ◦ チーム全体がドメインを知るきっかけになる
エンジニア募集中です