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
「開発チーム」とQA /"Development Team" and QA
Search
akihisa1210
February 21, 2018
1
8.4k
「開発チーム」とQA /"Development Team" and QA
Cybozu Meetup #11 アジャイルQA で発表しました。
https://cybozu.connpass.com/event/79018/
akihisa1210
February 21, 2018
Tweet
Share
More Decks by akihisa1210
See All by akihisa1210
Four Keysに基づくリリースプロセス改善とその成果 / Release process improvement based on the Four Keys and its results
ak1210
0
1.2k
独立したQA担当者か開発チームか? あるプロダクトチームのQA体制の変遷 / Independent QA or Dev Team
ak1210
0
1.4k
ソフトウェアテスト 2022 / Software Testing 2022
ak1210
1
8k
E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと / Preconceptions and What Happened with E2E Testing
ak1210
7
2.9k
テストコードを書きたいけどテスト対象がない。どうする? / What to do to write test?
ak1210
2
920
ここからはじめるスクラムQA(増補改訂版) / Getting started with QA in Scrum (revised)
ak1210
2
880
ここからはじめるスクラムQA / Getting started with QA in Scrum
ak1210
2
1.2k
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
167
14k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
Adopting Sorbet at Scale
ufuk
73
8.9k
Building an army of robots
kneath
302
42k
How to name files
jennybc
75
98k
Navigating Team Friction
lara
183
13k
We Have a Design System, Now What?
morganepeng
48
7.1k
Speed Design
sergeychernyshev
21
420
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
Scaling GitHub
holman
458
140k
Designing for humans not robots
tammielis
248
25k
Bash Introduction
62gerente
608
210k
Transcript
「開発チーム」とQA Cybozu Meetup #11 サイボウズ株式会社 東京品質保証部 小山 晃久 1
About me • 小山 晃久 • 2016年4月 新卒入社(人文系院卒) • QAとしてGaroonのお問い合わせ対応
→ 2017年7月からス クラムチームに参加 • 趣味は読書 ◦ 最近読んだ: フロイト『精神分析入門』、ゴールドラット『ザ・ゴール』 ◦ 今読んでる: ギャロウェイ『プロトコル』 2
What is Scrum? 「スクラムガイド――スクラム公式ガイド: ゲームのルール」 著: Ken Schwaber and Jeff
Sutherland 訳: 角征典 http://www.scrumguides.org/docs/scrumguide/v2017/20 17-Scrum-Guide-Japanese.pdf 3
Garoon開発 • 中堅・大規模組織向けのグループウェア • 日本・ベトナム・中国で多拠点開発 • ウォーターフォール → スクラム 4
5
スクラムチームの構成 6
3拠点 / 8チーム • 日本3チーム・ベトナム4チーム・上海1チーム • 日本の3チームのうち1チームは “Nexus” ◦ チーム間を取り持つ
7
Our team 8 PG PG SM PG QA QA
開発プロセス 9
スクラム以前 • ウォーターフォール • リリースは6か月に1度 • 開発期間 → 試験期間(機能試験 →
回帰試験) 10
スクラム以後 • リリースは3か月に1度 • 1リリース = 約6, 7スプリント • 1スプリント
= 3週間 • 1スプリント内で開発も試験もやる • 各リリースの最終スプリントは(原則)新規開発しない 11
QAがやっていること 12
• スクラムイベントへの参加 • 仕様書レビュー • 試験設計・試験仕様書作成 • 試験実施 • 不具合管理
• リリース関連作業 • (場合によっては)仕様書作成 13
• スクラムイベントへの参加 • 仕様書レビュー • 試験設計・試験仕様書作成 • 試験実施 • 不具合管理
• リリース関連作業 • (場合によっては)仕様書作成 14
スクラムイベントへの参加 15
スプリントプランニング • 試験という観点からタスクの分割方法を提案 ◦ 「この機能を一度に実装するとテストケース数が膨大にな るので、分けて実装してほしい」 ◦ 「試験を簡単にするために、試験用の API を作るタスクを
追加したい」 16
リファインメント • 現段階で決めておくべき仕様に漏れがないか調査 ◦ 「このケースではバリデーションエラーを返す?それとも不 正な値が無視されるだけ?」 ◦ 「もしユーザーが◦◦の操作をしたらどうなる?」 • 過去の不具合情報を掘り出す
17
レトロスペクティブ (ふりかえり) • チーム内でふりかえり → KAIZEN ◦ 開発中のブランチで動作確認したい • →
開発環境の作り方をレクチャーしてもらう ◦ ◦◦の試験に時間がかかった • → 次スプリントでは試験する単位を変えてみる ◦ もっと情報共有したい • → Slack、分報の導入 18
試験設計・試験仕様書作成 19
• 実装と同時に開始 • できるだけ早く動くものを触ってみる ◦ 試験対象を学ぶ • よくわからないことがあれば都度聞く • 仕様の漏れが見つかったらフィードバック・提案
• 実装者にテストケースについて相談(ただしうのみにはしない) ◦ Aを試験すればBは試験しなくてもよい? ◦ これはすべての動作環境で確認すべき? 20
Good 21
• スケジュール(以前は試験期間にしわ寄せが) • チーム内での連携 ◦ 相談しやすい ◦ 品質への関心の向上 • QAのスキルを活かせている(気がする)
◦ 不具合が出そうな点を事前に指摘 ◦ ユーザーが機能をどう使うか考える ◦ あとで読んでも意味の分かる仕様書 22
課題 23
• 試験設計の成果物はスクラム以前のまま ◦ テスト対象・テスト目的・テストケースを含むスプレッドシ ート ◦ 自動テストと探索的テストで何ができるのか知る必要あり (銀の弾丸ではない) • チーム間での情報共有
• 明確な成果はまだこれから ◦ 適応に時間がかかる(一時的に生産性が下がる) ◦ 技術的負債との闘い ◦ ふりかえりで地道に KAIZEN を重ねる 24
最後に: 「開発チーム」とQA 25
スクラムガイドにおける「開 発チーム」 26
• ある人にしかできない作業があったとし ても、スクラムにおける開発チームのメ ンバーに肩書きはない。 • テスティング、アーキテクチャ、運用、ビジ ネス分析のような専門領域であっても、 スクラムは開発チームのサブチームを認 めていない。 27
(Ken Schwaber and Jeff Sutherland著、角征典訳「スクラムガイド」p.6 http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)
Our team 28 PG PG SM PG QA QA
Our team 29 開発チームの メンバー 開発チームのメンバー SM 開発チームのメンバー 開発チームのメンバー 開発チームのメンバー
30 Question • 開発チーム「の」QA は(役職・職能の意味では)存在 しない? • 開発チーム「と」QA(品質保証担当者あるいは品質 保証という活動)はどのように付き合っていけばよい のか?