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
CO-OP Sapporo
August 25, 2021
Technology
2
3.4k
絶対にテストコードを書かないチームのテストルール
生活協同組合コープさっぽろ
ヒグ!(樋口修也)
CO-OP Sapporo
August 25, 2021
Tweet
Share
More Decks by CO-OP Sapporo
See All by CO-OP Sapporo
大量リダイレクトも怖くない!CloudFront KeyValueStoreでサービスサイトリニューアルを楽々乗り越えた話 / How we redirect large-scale web pages by CloudFront Functions and CloudFront KeyValue Store
coopsapporo
1
260
CloudNative Days Summer 2024-北海道全域で利用される宅配システムのクラウドネイティブ化
coopsapporo
0
270
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜 / School lunch for anywhere
coopsapporo
0
450
AWSアカウントをOrganizations配下に入れようとしたらVPCまるごとお引越しをした件 / JAWS PANKRATION 2021 / What makes me to migrate entire VPC
coopsapporo
1
2.6k
混沌から離脱までの道のり アウトソースをする事業会社がすべきことは?
coopsapporo
0
100
社会人2年目のエンジニアがPMになるとき
coopsapporo
2
300
KPTの空回りを防ぐ! エンジニアリングチーム 立ち上げの取り組み
coopsapporo
0
4.1k
あなたならどうする?DXの現場におけるエンジニアの葛藤
coopsapporo
0
1.9k
JAWS DAYS 2021 わたし達はなぜ「北海道で生きること」を選択したのか 〜移住を決めたエンジニア達のエトセトラ〜 / Why we choose "Living in Hokkaido" ~Our worries, decisions, and their fruits~
coopsapporo
2
2.1k
Other Decks in Technology
See All in Technology
グイグイ系QAマネージャーの仕事
sadonosake
0
300
PDF Viewer作成の今までとこれから
hunachi
0
400
Road to Single Activity
yurihondo
1
230
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
Discovering AI Models
picardparis
4
3.9k
Agile in Automotive Industry, puzzles and lights.
hiranabe
3
1.3k
Swift Testingのconfirmationを コードリーディング/Dive into Swift Testing confirmation
laprasdrum
2
250
JEP 480: Structured Concurrency
aya_ebata
0
130
疎通2024
sadnessojisan
5
1k
Next.js のページ遷移を全力で止める
ypresto
3
1.9k
『GRANBLUE FANTASY: Relink』最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
0
110
The XZ Backdoor Story
fr0gger
0
3.6k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
78
8.6k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
4 Signs Your Business is Dying
shpigford
179
21k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Code Review Best Practice
trishagee
62
16k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
How to Ace a Technical Interview
jacobian
274
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
401
65k
Transcript
絶対にテストコードを書かないチームのテストルール 生活協同組合コープさっぽろ ヒグ!(樋口修也)
発表者 フロントエンド,認証認可 2015年 旭川→岩手大学へ入学 2019年 東京のIT企業に新卒入社 2020年 コープさっぽろへ転職し札幌へ ダブルダッチ、筋トレ、ダンス AWS
CDK, Vue.js Youtubeはじめました! 樋口修也(24) 担当: 経歴: 趣味: 好み: 最近:
コープさっぽろDXとは? 小売業界の巨大組織 • 180万人以上の組合員 • 約3000億円の年間売上 • 1万人以上の従業員 コープさっぽろがもっと 使いやすく、買い物しやすく、働きやすく
デジタル集団 • 4人のAWS samurai認定者 • 16人の内製エンジニア • 20年以上付き合いがあるシ ステムベンダー デジタル(D)の力で巨大組織を変革(X)が昨年秋始動!
コープさっぽろ昔ばなし 昔って言っても半年ぐらい前まであった 怖い話 ※ごく一部のチームの話です
昔ばなし むかーしむかし、 あるところにテストコードどころか、 テストケースすら作成しないでリリースしてい るチームがありました。 ※フロントエンドです テストケース作ってやる のはメジャーリリースだ けな!
昔ばなし 理由はもちろんリソース不足のためです(笑)
昔ばなし メジャーリリースだけテストケースは作るもの の、軽微な改修に関してはエンジニアと担当 したディレクションが確認してリリースというこ とに もちろんお互い何を確認したか把握できてい ません ヨシ! ヨシ! エンジニア
ディレクション
昔ばなし そして鳴り止まぬコールセンターとお 叱りの声をたくさんいただきました。
昔ばなし 最終的に開発チームは更にふりかか るPJと問い合わせ対応、改修に追わ れて心が病みました。。 めでたしめでたし。
昔ばなし という怖い話が2度と起きないように この教訓を広げれればいいなと思います
そもそもなんでこんなことになったか? • 納期 ◦ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決め ていた ▪ 正確なシステムの見積もりができていない ▪ テストを工数に組み込んでいない
• 品質 ◦ 詳細な要件を固めないで制作に入っていた ▪ ファーストリリース分のみテストケースを作っていた ▪ リリース後に不具合を改修をすると決めていた ▪ リリース直前にIEを対応することになった
フォーカスポイント(他は今度たっぷり話します) • 納期 ◦ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決め ていた ▪ 正確なシステムの見積もりができていない ▪ テストを工数に組み込んでいない
• 品質 ◦ 詳細な要件を固めないで制作に入っていた ▪ ファーストリリース分のみテストケースを作っていた ▪ リリース後に不具合を改修をすると決めていた ▪ リリース直前にIEを対応することになった
リリース後の改修 お問い合わせ 改修内容選定 実装 テスト
テストどーする問題 • テストの形式は?(How) ◦ 運用テスト?結合テスト?単体テスト? • 何をテストする?(What) • レビューは誰が行う?(Who) •
いつ行う?(When) • 実施環境はどうするか?(Where) • なぜテストに工数をさかなくてはいけない?(Why) 一般IT企業ではルール化されているものが 立ち上げチームにはない><
リリース後の終わらない改修 お問い合わせ 改修内容選定 実装 テスト 更なるバグ
リリース後の終わらない改修 お問い合わせ 改修内容選定 実装 テスト 各人で行うので担当し たディレクションエンジ ニアによってばらつき が出る 更なるバグ
随時問い合わせか ら原因究明なので 効率も下がる
改善案 • テストの形式は? ◦ フロントチームはユーザーストーリーテストのみ絞って行う • 何をテストする? ◦ スプレッドシートをテンプレート化して使い回す •
レビューは誰が行う? ◦ コードレビューを行った人 • いつ行う? ◦ コードレビューの際 • 実施環境はどうするか? ◦ リリース直前の検証環境を必ず利用する • なぜテストに工数をさかなくてはいけない?(Why) ◦ 不具合を出して顧客の信頼不審やバグ改修による効率の低減を防ぐため (学び)
テストの形式 今までの中でIEによる不具合が 圧倒的に多かったので Chrome とIEのテストを絶対に実施する
テスト実施のタイミング バージョンインクリメント v1.3.4 main dev feature/.. feature/.. ・devへのPRでテスト ケース作成 ・マージ後検証環境でテ
スト実施 ・これをfeatureごとに行 う
devへのPRのテンプレート化 • PRの概要説明 • アーキ図への変更の有無 • GoogleMeetでの共有の有無 • 相談事項などあれば •
テスト項目のレビュー • webviewへの影響の有無 • IEでのテスト実施の有無
githubのPR作成時にテンプレ自動生成 プロジェクトフォルダのルートディレクトりに ./github フォルダを作って PULL_REQUEST_TEMPLATE.md ファイ ルを作ってマークダウン記法で書くと、PR 作成時に画像のような形でテンプレートが 生成されます。
こんな感じ
devからmainのマージのタイミング バージョンインクリメント v1.3.4 main dev feature/.. feature/..
devからmainへマージの時のテンプレート • マージしたPRのURL • IEとChromeでテストしたか否か?
成果 フロー作成前: 月2,3件 フロー作成後 : 月0件 改修に伴うバグ報告 ※ざっくり調べ
ちなみに featureからdevへのマージのテンプレート文章も devからmainへのマージのテンプレート文章も 同じPULL_REQUEST_TEMPLATE.mdに記載して必要に応じて削除しています
一応CI/CDのフローを真似て作りました main dev feature/.. feature/.. ・PRでテストのレビュー ・マージ後すぐにdevでテスト の実施 ・PRでlintの実施 ・マージのタイミングで自動テス
トの実施 今回のテスト運用フロー 一般的なCI/CD ※このフローはコープさっぽろ のエンジニア、岡部さん、和泉 さん、伊藤さんと共に考えまし た
そもそもテストとは コードの品質を担保するための仕組み 自動化も手動テストも仕組み次第
手動テストに絞ることでできること エンジニアがテストケースを作って 実行をお願いする
エンジニアがテストケースを作って実行をお願いする エンジニア 顧客体験 その他 負担 5 : 5 テストケース洗い出し テストケース作成
テストの実施 ユーザー体験の確認
無理にテストコードを書いた場合 エンジニア 顧客体験 その他 負担 10 : 0 テストケース洗い出し テストコード作成
テストコードのPRと修正...など
テストコードのいいところ テストを自動化して効率化 単体テストを入れることでコードの品質を評価 修正して再テストが容易
前職の時と比較して実感するメリット・デメリット • テストの工数を分担できる • テストケースも直しやすい • テストで不具合があった時の出戻 りが大きい • 利用規約の同意やユーザーの表
示など必ず間違えてはいけない場 所を毎回テストできる • こまめに走らせることでコアな部分 の不具合を早めに見つけられる • テスタビリティの観点からコードの 品質を確認できる • 実装コストが大きい • 全てのテストは自動化できない 手動テスト 自動テスト やっぱテストコード欲しい。。
最後に 自動テストデータの扱いやすさ 手動テストの柔軟性 双方の長所を活かして生産性の向上に繋げていきたい
本当に最後・・・ 「コープさっぽろDX」で検 索! Flutter大学KBOYさんと のマッチアップの話も!