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
テスト・設計研修【ミクシィ22新卒技術研修】
Search
MIXI ENGINEERS
PRO
April 14, 2022
Programming
10
91k
テスト・設計研修【ミクシィ22新卒技術研修】
22新卒技術研修で実施したテスト・設計研修の講義資料です。
動画:
https://youtu.be/T4sL4XXZ4Ug
MIXI ENGINEERS
PRO
April 14, 2022
Tweet
Share
More Decks by MIXI ENGINEERS
See All by MIXI ENGINEERS
スクラムマスターなしでもいい感じにスクラム開発している話
mixi_engineers
PRO
1
6
組織のデータリテラシー向上に向けて ~ MIXI データ活用ガイドラインができるまで 〜
mixi_engineers
PRO
5
73
MIXI配信取り組み
mixi_engineers
PRO
2
20
MIXIにおけるWebRTC技術の活用/Use of WebRTC Technology in MIXI
mixi_engineers
PRO
2
61
「人物ごとのアルバム」の精度改善の軌跡/Improving accuracy of albums by person
mixi_engineers
PRO
2
210
「モンスターストライク」の運営を支えるデータ分析基盤の歴史と進化 / History and evolution of the data analysis infrastructure supporting “Monster Strike” operations
mixi_engineers
PRO
3
260
【全貌公開】 MIXI の Atlassian Cloud 移行の裏側 / Behind MIXI's Migration to Atlassian Cloud
mixi_engineers
PRO
0
330
MIXI TECH NOTE #12
mixi_engineers
PRO
2
48
運営11年目タイトルを守る最強の盾の有効性と活用法
mixi_engineers
PRO
2
360
Other Decks in Programming
See All in Programming
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
880
CI改善もDatadogとともに
taumu
0
180
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1.1k
Datadog Workflow Automation で圧倒的価値提供
showwin
1
100
バッチを作らなきゃとなったときに考えること
irof
2
470
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
950
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
180
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
6
2.1k
SwiftUI Viewの責務分離
elmetal
PRO
2
260
Datadog DBMでなにができる? JDDUG Meetup#7
nealle
0
120
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
190
Writing documentation can be fun with plugin system
okuramasafumi
0
130
Featured
See All Featured
It's Worth the Effort
3n
184
28k
Code Review Best Practice
trishagee
67
18k
Music & Morning Musume
bryan
46
6.4k
A Philosophy of Restraint
colly
203
16k
Six Lessons from altMBA
skipperchong
27
3.6k
Visualization
eitanlees
146
15k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Bash Introduction
62gerente
611
210k
Navigating Team Friction
lara
183
15k
The Invisible Side of Design
smashingmag
299
50k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Transcript
2022/04/14 モンスト事業本部 開発室 モンストサーバG 岡住 和樹 2022 テスト・設計研修
• 岡住 和樹 (@zumin) • 19新卒 (4年目らしい) • モンスト事業本部 開発室
モンストサーバG • 好きなもの • お酒 • ゲーム • 好きなエディタ • Vim 自己紹介 2
• 加藤 修悟 (@shugo.kato) a.k.a. ろぐみ • 21新卒 • Vantage
スタジオ Romi 事業部 開発グループ • サーバ/フロント/インフラもひとつまみ • 好きなキーボード • HHKB • 好きなエディタ • VSCode 3 自己紹介
• 江畑 拓哉 (@takuya.ebata) • 21新卒 • 次世代エンターテイメント事業本部 TIPSTAR開発部 システム2G
アーキテクトT • 運用と開発、あと庶務 • 好きなキーボード • FILCO • 好きなエディタ • Emacs 4 自己紹介
1. 講義 2. 演習1 (ペアプログラミング) • 実装 • 各チーム同士でコードレビュー &
修正 3. 演習2, 3 … お昼は13:00頃〜を予定 5 本日の流れ
6 講義
• テスト・ソフトウェアテストとは • ソフトウェアの品質の話 • TDDの話 • テスト技法の話 • テストの7原則
• ペアプログラミング • コードレビューの仕方とされ方 7 本日の流れ
8 みなさん、テスト書いてますか?
9 テストと聞いて、 どのようなことを思い浮かべますか?
テスト != デバッグ テスト: 不具合があることを示すことができるだけ デバッグ: 不具合を取り除くまでの一連の開発活動のこと 10 テスト・ソフトウェアテストとは
テスト・ソフトウェアテストとは ソフトウェアテストはソフトウェアの品質 を評価して、 運用時の不具合を低減するための 1 つの手段です 11
12 ソフトウェアの品質の話
ソフトウェア品質特性 • 外部品質特性 • システムの利用者が触れる、見える部分の品質 • 内部品質特性 • システムの利用者からは見えない内側の部分の品質 13
ソフトウェアの品質
引用: 『つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活用のすすめ 』P23 図2.3-3 (https://www.ipa.go.jp/files/000044964.pdf) 14 ソフトウェアの品質
引用: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 15 ソフトウェアの品質
16 TDD
• TDD (Test-driven development / テスト駆動開発) • Red, Green, Refactor
のサイクルを回す 1. まずはテストを書く (Red) a. 実装はないのでもちろんテストは落ちる 2. テストを通すために、実装をする (Green) a. ここでは、まずはテストを通すことを考えてみる 3. リファクタリングする (Refactor) 17 TDD
• テストが落ちること • 落ちるはずのテストが通っちゃうと・・・? • テストを通すことをだけを考えてみる • 通るはずのテストが通らないときは・・・? 18 TDD
テスト駆動開発は、テストを書くことがゴールなのではなく、 開発中に感じる様々な不安を自身でコントロールしていく手法 19 TDD
• テストが書きづらいとき • 副作用が多くないか? • 責務を持ちすぎてないか? もしくは不明瞭ではないか? 20 TDDのこつ
21 ライブコーディング
22 テスト技法の話
• テストのレベル • 単体テスト (Unit testing) • もっとも小さなテスト • クラス、メソッド単位
(言語で異なる) • 統合テスト (Integration testing) • 単体テストよりも大きな範囲のテスト • システムテスト (System testing) • ソフトウェア全体のテスト • 受け入れテスト (User Acceptance Testing) • 顧客がソフトウェアを受け入れる時のテスト 23 テスト技法
• テストの種別 • ブラックボックステスト • 仕様や要件に基づいてテストを実施するテスト • 実装レベルの知識は必要としない • ホワイトボックステスト
• 実装レベルの知識に基づいて実施するテスト • ソフトウェアの内部パス、構造、実装 ... • グレーボックステスト • 実装をある程度調べた上で、ブラックボックステストのテストケースを効率的に選択していく 24 テスト技法
• ブラックボックステスト • 同値クラステスト • 境界値テスト • …. • ホワイトボックステスト
• 制御フローテスト • データフローテスト 25 テスト技法
同値クラステスト • 同値クラスに分け、代表値を選んでテストケースを作る • 例 • 入力値は0~100 • 0~19は未成年、20~100は成人 と返すプログラムを考える
26 テスト技法
境界値テスト • 同値クラステストを元に、境界値に注目したテスト • パーティションの最小値と最大値、または最初の値と最後の値を選んでテストする • -1, 0, 19, 20,
100, 101 27 テスト技法
1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. 殺虫剤のパラドックスにご用心
6. テストは状況次第 7. 「バグゼロ」の落とし穴 28 テストの7原則
29 ペアプログラミング
• ドライバー • 実際に操作する人 • ナビゲーター • ドライバーの操作を眺めつつ、助ける人 • 定期的に役割を入れ替えながら進める
30 ペアプログラミング
うまくやるこつ • ドライバー • 今、何をやろうとしているか、やっているかを明確にする (発言する) • ナビゲーター • 良い方法を思いついたり、ミスに気づいたりしたときに、積極的に発言する
• ドライバーが何をやろうとしていることが良くわからなくなったら、すぐに聞く commit & push してれば、役割交代はしやすいはず・・・? 31 ペアプログラミング
33 コードレビューの仕方とされ方
• チームごとにteam-A,B,C,D,E,F ブランチ向きにPRを作ってください • レビューするチーム • 演習1: A → B、
B → C、 C → D、 D → E、E → F、F → A • 演習2: A → C、 B → D、 C → A、 D → B … • 時間が余ったら他のチームをレビューしてもOK 34 コードレビューの仕方とされ方
• どうすれば、マージされやすいかを考えてみる • PRの説明をしっかり書く • どういう背景で、どういう理由で、どういうものを作った、など • 重点的にレビューして欲しいところや、実装していてよく分からなかったところ、など • JIRAのチケットや、関連PR,issueなど
• 背景の詳細や、仕様などを追いやすい • 監査などのときに、追いやすい、など • どういうタイミングでマージして欲しい、など (QAチームによるテストが終わってか ら、など) 35 コードレビューの仕方とされ方
• レビューは人格攻撃ではない (心理的安全性) • わからないところは聞こう • 褒めよう! • この人はこういうところをレビューしてくるだろうなぁと考えてみる 36
コードレビューの仕方とされ方
• SQuBOK Guide V3 • テスト駆動開発 • はじめて学ぶソフトウェアのテスト技法 • ソフトウェアテスト技法
37 参考文献
None