QAエンジニアってスクラムで何をすればいいの？

Regional Scrum Gathering Tokyo 2024
https://2024.scrumgatheringtokyo.org/
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19326/qa

Transcript

1. 2024/01/11 Regional Scrum Gathering Tokyo 2024 QAエンジニアって スクラムで何をすればいいの？ @rinchsan
2. 今日のキーワード
3. 「どこでもテスト」 「壁をこわす」 今日のキーワード
4. 「どこでもテスト」とは
5. “For me, testing fits at each and every single point in this model.” “DevOpsモデルのすべての ポイントでテストする” “Continuous Testing in DevOps...” (2016) https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
6. スクラムのサイクルでも考えてみる どこでテストすべきか？ 引用：https://www.slideshare.net/akienomoto/ss-2611775
7. すべてのイベントで テストする どこでテストすべきか？
8. スクラムでも「どこでもテスト」する この考え方が「QAEってスクラムで何をすればいいの？」の答えに繋がる
9. 「壁をこわす」とは
10. 「どこでもテスト」するとは言っても… 考えるべきことが多すぎて、QAエンジニアだけでは実現できない
11. 「壁をこわす」をQAEが推進する チームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるように PdM デザイナー 開発エンジニア アナリスト QAE
12. “アジャイル開発における品 質保証は、特定の段階で特定 の人々のみが取り組むという よりも、…(中略)…あらゆる 段階でチーム全体となって取 り組む活動となります。” 『QA to AQ』(2022)
13. “そこで、QA担当者を早い段 階から参加させる、…(中 略)…など、さまざまなアク ションを通じて、コミュニ ケーションを阻害する障壁を 取り払うことが必要です。” 「障壁の解体」(第2章)
14. CTO @SODA inc. ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE(2022/01) → CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ◦ 2019年新卒入社 バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan X@rinchsan
15. CTO @SODA inc. ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE(2022/01) → CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ◦ 2019年新卒入社 バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan QAEの経験は ありません！ X@rinchsan
16. 目次 プロダクトの急成長と組織の急拡大 1 急成長に伴うQA難易度の増加 2 QAEってスクラムで何をすればいいの？ 3
17. プロダクトの急成長と組織の急拡大 1
18. 鑑定付き 利用者数 No.1 スニーカー・トレカ フリマアプリ
19. MAU リクエスト数 ソースコード プロダクトの急成長
20. 3年で 100万人 → 500万人 MAU プロダクトの急成長
21. 負荷スパイク（人気スニーカー発売など） 1万〜2万 rps リクエスト数 プロダクトの急成長
22. ファイル数は1年で 4,400→7,300 コード行数は1年で 80万行→126万行 ソースコード - Go プロダクトの急成長
23. Dartファイル数 約3,700ファイル Dartコード行数 約417,000行 ソースコード - Dart プロダクトの急成長
24. プロダクト開発組織 デプロイ頻度 組織の急拡大
25. 3年で エンジニア 2名 → 45名 プロダクト開発組織全体では 4名 → 55名 プロダクト開発組織 組織の急拡大
26. Monthlyで 60回 〜 90回 Dailyで 3回 〜 4.5回 デプロイ頻度 組織の急拡大
27. 急成長に伴うQA難易度の増加 2
28. QAプロセスが整備されていく 2023/01に1人目のQAEがジョイン！
29. 「開発→テストケース設計→テスト実施」で不具合を事前に検知できることが増えた しかし、これだけでは品質を高めるためのコスパが次第に悪くなり… テスト実施 おねがいします！ テスト実施 していくぞ！ テストケース 設計できた！ まずは仕様の キャッチアップ からだ！ 開発チーム QAチーム
30. 何が正しい仕様か分からなくなってくる… この挙動って 正しいですか？ これはPdMに 聞かないとですね このケース どうしますか？ これPdMの人も 知らないってさ ドキュメント ないのか…
31. 振り返りもそれぞれでやってしまう… 開発チーム こんな不具合 出ちゃったね QAチームに お願いしますね 次はもう少し テストしますか 壁 QAチーム こんな不具合 出ちゃったね もっと早く 気づけたかも？ 似てるのが前も 出てましたね 一緒に議論したほうが絶対に品質が上がりそう… ※ 他にも課題ありそう
32. 仕様策定時点での考慮漏れに気づけなかったりも… 開発チーム このケース 漏れてましたね ちょっと想像と 違いましたね… こんな感じで 実装してました 壁 QAチーム このケース 漏れてましたね もっと早く 気づけたかも？ この機能に矛盾 してますもんね プロダクトにより詳しい人どうしが協力できれば… ※ 他にも課題ありそう
33. どうしてもコミュニケーション不足が発生したりも… 開発チーム コレもうQA できますね 開発完了なので QAしてほしい あ、もうQA 終わってたのか 壁 QAチーム コレもうQA 開始できるのか 準備完了なので 早くQAしたい いつの間に開発 完了してた？ 「コミュニケーション取ればいいだけ」って意外と難しい！ ※ 少し誇張しています
34. 「どこでもテスト」 「壁をこわす」 どうすれば改善できる？
35. QAEってスクラムで何をすればいいの？ 3
36. 価値提供をテストする QAEってスクラムで何をすればいいの？
37. 「どこでもテスト」 「壁をこわす」 価値提供をテストするには？
38. 「どこでもテスト」とは
39. スクラムでもすべてのイベントでテストする スクラムで「どこでもテスト」するとは例えば？
40. リファインメントでは、高いプロダクト理解をもってテストする こんな仕様で 作りたい！ この既存仕様と 矛盾してるかも エッジケース 漏れてるかも 過去事例的に テストケース 多くなりそう じゃあもう少し 仕様をシンプル にしますか ユーザ行動ログ はどう設計？ 不具合(広義)は発見するよりも予防する ※ すべてをQAEがやる必要はない
41. こんな仕様で 作りたい！ リファインメントでは、高いプロダクト理解をもってテストする この既存仕様と 矛盾してるかも エッジケース 漏れてるかも 過去事例的に テストケース 多くなりそう じゃあもう少し 仕様をシンプル にしますか ユーザ行動ログ はどう設計？ ※ すべてをQAEがやる必要はない スニダンのような5年以上の歴史があるプロダクトではなかなか難易度が高い…
42. プランニングでは、開発計画作りへの高い理解をもってテストする このEpicはこう Backlog Itemに 分割しよう ここまで開発 できたら一旦 テストしよう というのを 意識して計画を 作ろう Itemごとに テストケース 作ろう テスト計画の作り方だけでは知識が足りないことも
43. このEpicはこう Backlog Itemに 分割しよう ここまで開発 できたら一旦 テストしよう というのを 意識して計画を 作ろう プランニングでは、開発計画作りへの高い理解をもってテストする Itemごとに テストケース 作ろう 大きなEpicほどBacklog Itemごとにテストケースを作成する難易度が高い…
44. レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする 各イベントで完了の定義を作るイメージ この不具合を 再発防止 するには？ 良いタイミング でQA開始 できていたか？ もっと細かく Backlog Itemを 分割できたか？ ユーザへの価値 を考えると許容 してもよい？ そもそも予防 することは できなかった？ テストケースを 次はもっと 網羅するには？
45. ユーザへの価値 を考えると許容 してもよい？ もっと細かく Backlog Itemを 分割できたか？ 良いタイミング でQA開始 できていたか？ テストケースを 次はもっと 網羅するには？ 再発防止や予防にはSET領域のスキルも重要で難易度が高い… この不具合を 再発防止 するには？ そもそも予防 することは できなかった？ レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする
46. もっと細かく Backlog Itemを 分割できたか？ ユーザへの価値 を考えると許容 してもよい？ そもそも予防 することは できなかった？ この不具合を 再発防止 するには？ 良いタイミング でQA開始 できていたか？ テストケースを 次はもっと 網羅するには？ レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする やろうと思えば無限にテストできるからバランスも難しい…
47. 「どこでもテスト」する すべてが品質を高めるための取り組み
48. 「壁をこわす」とは
49. 「どこでもテスト」するとは言っても… すべてをQAエンジニアだけで実現するのは不可能
50. QAEが「壁をこわす」ことでチームメンバー全員で品質を高める文化を作る PdM デザイナー 開発エンジニア アナリスト QAE スクラムで「壁をこわす」とは例えば？
51. じゃあもう少し 仕様をシンプル にしますか ユーザ行動ログ はどう設計？ 過去事例的に テストケース 多くなりそう こんな仕様で 作りたい！ リファインメントでは、高いプロダクト理解をもってテストする この既存仕様と 矛盾してるかも エッジケース 漏れてるかも ※ すべてをQAEがやる必要はない 開発エンジニアはエッジケースを見つけるのが得意かも？
52. 頼っちゃいましょう じゃあ開発エンジニアに
53. ユーザ行動ログ はどう設計？ 過去事例的に テストケース 多くなりそう この既存仕様と 矛盾してるかも エッジケース 漏れてるかも こんな仕様で 作りたい！ リファインメントでは、高いプロダクト理解をもってテストする じゃあもう少し 仕様をシンプル にしますか ※ すべてをQAEがやる必要はない PdMはユーザへの価値を考慮したスコープの調整が得意かも？
54. 頼っちゃいましょう じゃあPdMに
55. 過去事例的に テストケース 多くなりそう この既存仕様と 矛盾してるかも エッジケース 漏れてるかも こんな仕様で 作りたい！ じゃあもう少し 仕様をシンプル にしますか リファインメントでは、高いプロダクト理解をもってテストする ※ すべてをQAEがやる必要はない データアナリストはユーザ行動ログ設計が得意かも？ ユーザ行動ログ はどう設計？
56. 頼っちゃいましょう じゃあデータアナリストに
57. というのを 意識して計画を 作ろう Itemごとに テストケース 作ろう このEpicはこう Backlog Itemに 分割しよう ここまで開発 できたら一旦 テストしよう プランニングでは、開発計画作りへの高い理解をもってテストする 開発エンジニアは開発を進めやすいBacklog Item分割が得意かも？
58. 頼っちゃいましょう じゃあ開発エンジニアに
59. ユーザへの価値 を考えると許容 してもよい？ もっと細かく Backlog Itemを 分割できたか？ 良いタイミング でQA開始 できていたか？ この不具合を 再発防止 するには？ テストケースを 次はもっと 網羅するには？ レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする 開発エンジニアはSET領域にも詳しいかも？ そもそも予防 することは できなかった？
60. 頼っちゃいましょう じゃあ開発エンジニアに
61. 全員で「どこでもテスト」する つまり「壁をこわす」ことで
62. One more thing...
63. 後押しするための組織デザイン そもそも「どこでもテスト」と「壁をこわす」はとても難しいこと
64. フルサイクルなチームを作る QAE含めたフルサイクルなチームで動くことも重要 引用：https://speakerdeck.com/rinchsan/huroxiao-lu-wozhong-shi-site-2nian-ban-deenzinia2ming-35ming-noji-kuo-da-zu-zhi-degao-isheng-chan-xing-woshi-xian-sitahua
65. フルサイクルなチームがバリューストリーム全体に関わる バリューストリーム全体でテストする 引用：https://speakerdeck.com/rinchsan/huroxiao-lu-wozhong-shi-site-2nian-ban-deenzinia2ming-35ming-noji-kuo-da-zu-zhi-degao-isheng-chan-xing-woshi-xian-sitahua QAE
66. フルサイクルなチーム バリューストリーム全体 「どこでもテスト」と「壁をこわす」を後押し
67. まとめ
68. 「どこでもテスト」 「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？
69. スクラムのすべてのイベントでテストする 「どこでもテスト」をQAエンジニアが推進する
70. チームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるようにする 「壁をこわす」をQAエンジニアが推進する PdM デザイナー 開発エンジニア アナリスト QAE
71. 「どこでもテスト」 「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？