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

2024/01/11 Regional Scrum Gathering Tokyo 2024 QAエンジニアってスクラムで何をすればいいの？ @rinchsan

今日のキーワード

「どこでもテスト」「壁をこわす」今日のキーワード

「どこでもテスト」とは

“For me, testing ﬁts 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/

スクラムのサイクルでも考えてみるどこでテストすべきか？引用：https://www.slideshare.net/akienomoto/ss-2611775

すべてのイベントでテストするどこでテストすべきか？

スクラムでも「どこでもテスト」するこの考え方が「QAEってスクラムで何をすればいいの？」の答えに繋がる

「壁をこわす」とは

「どこでもテスト」するとは言っても… 考えるべきことが多すぎて、QAエンジニアだけでは実現できない

「壁をこわす」をQAEが推進するチームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるように PdM デザイナー開発エンジニアアナリスト QAE

“アジャイル開発における品質保証は、特定の段階で特定の人々のみが取り組むというよりも、…(中略)…あらゆる段階でチーム全体となって取り組む活動となります。” 『QA to AQ』(2022)

“そこで、QA担当者を早い段階から参加させる、…(中略)…など、さまざまなアクションを通じて、コミュニケーションを阻害する障壁を取り払うことが必要です。” 「障壁の解体」(第2章)

CTO @SODA inc. ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE(2022/01) →
CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ◦ 2019年新卒入社バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan X@rinchsan

CTO @SODA inc. ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE(2022/01) →
CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ◦ 2019年新卒入社バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan QAEの経験はありません！ X@rinchsan

目次プロダクトの急成長と組織の急拡大 1 急成長に伴うQA難易度の増加 2 QAEってスクラムで何をすればいいの？ 3

プロダクトの急成長と組織の急拡大 1

鑑定付き利用者数 No.1 スニーカー・トレカフリマアプリ

MAU リクエスト数ソースコードプロダクトの急成長

3年で 100万人 → 500万人 MAU プロダクトの急成長

負荷スパイク（人気スニーカー発売など） 1万〜2万 rps リクエスト数プロダクトの急成長

ファイル数は1年で 4,400→7,300 コード行数は1年で 80万行→126万行ソースコード - Go プロダクトの急成長

Dartファイル数約3,700ファイル Dartコード行数約417,000行ソースコード - Dart プロダクトの急成長

プロダクト開発組織デプロイ頻度組織の急拡大

3年でエンジニア 2名 → 45名プロダクト開発組織全体では 4名 → 55名プロダクト開発組織
組織の急拡大

Monthlyで 60回〜 90回 Dailyで 3回〜 4.5回デプロイ頻度組織の急拡大

急成長に伴うQA難易度の増加 2

QAプロセスが整備されていく 2023/01に1人目のQAEがジョイン！

「開発→テストケース設計→テスト実施」で不具合を事前に検知できることが増えたしかし、これだけでは品質を高めるためのコスパが次第に悪くなり… テスト実施おねがいします！テスト実施していくぞ！テストケース設計できた！まずは仕様のキャッチアップ
からだ！開発チーム QAチーム

何が正しい仕様か分からなくなってくる… この挙動って正しいですか？これはPdMに聞かないとですねこのケースどうしますか？これPdMの人も知らないってさドキュメント
ないのか…

振り返りもそれぞれでやってしまう… 開発チームこんな不具合出ちゃったね QAチームにお願いしますね次はもう少しテストしますか壁 QAチーム
こんな不具合出ちゃったねもっと早く気づけたかも？似てるのが前も出てましたね一緒に議論したほうが絶対に品質が上がりそう… ※ 他にも課題ありそう

仕様策定時点での考慮漏れに気づけなかったりも… 開発チームこのケース漏れてましたねちょっと想像と違いましたね… こんな感じで実装してました壁 QAチーム
このケース漏れてましたねもっと早く気づけたかも？この機能に矛盾してますもんねプロダクトにより詳しい人どうしが協力できれば… ※ 他にも課題ありそう

どうしてもコミュニケーション不足が発生したりも… 開発チームコレもうQA できますね開発完了なので QAしてほしいあ、もうQA 終わってたのか壁 QAチーム
コレもうQA 開始できるのか準備完了なので早くQAしたいいつの間に開発完了してた？「コミュニケーション取ればいいだけ」って意外と難しい！ ※ 少し誇張しています

「どこでもテスト」「壁をこわす」どうすれば改善できる？

QAEってスクラムで何をすればいいの？ 3

価値提供をテストする QAEってスクラムで何をすればいいの？

「どこでもテスト」「壁をこわす」価値提供をテストするには？

「どこでもテスト」とは

スクラムでもすべてのイベントでテストするスクラムで「どこでもテスト」するとは例えば？

リファインメントでは、高いプロダクト理解をもってテストするこんな仕様で作りたい！この既存仕様と矛盾してるかもエッジケース漏れてるかも過去事例的にテストケース多くなりそう
じゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？不具合(広義)は発見するよりも予防する ※ すべてをQAEがやる必要はない

こんな仕様で作りたい！リファインメントでは、高いプロダクト理解をもってテストするこの既存仕様と矛盾してるかもエッジケース漏れてるかも過去事例的にテストケース多くなりそう
じゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？ ※ すべてをQAEがやる必要はないスニダンのような5年以上の歴史があるプロダクトではなかなか難易度が高い…

プランニングでは、開発計画作りへの高い理解をもってテストするこのEpicはこう Backlog Itemに分割しようここまで開発できたら一旦テストしようというのを意識して計画を
作ろう Itemごとにテストケース作ろうテスト計画の作り方だけでは知識が足りないことも

このEpicはこう Backlog Itemに分割しようここまで開発できたら一旦テストしようというのを意識して計画を作ろう
プランニングでは、開発計画作りへの高い理解をもってテストする Itemごとにテストケース作ろう大きなEpicほどBacklog Itemごとにテストケースを作成する難易度が高い…

レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする各イベントで完了の定義を作るイメージこの不具合を再発防止するには？良いタイミングでQA開始できていたか？もっと細かく Backlog
Itemを分割できたか？ユーザへの価値を考えると許容してもよい？そもそも予防することはできなかった？テストケースを次はもっと網羅するには？

ユーザへの価値を考えると許容してもよい？もっと細かく Backlog Itemを分割できたか？良いタイミングでQA開始できていたか？
テストケースを次はもっと網羅するには？再発防止や予防にはSET領域のスキルも重要で難易度が高い… この不具合を再発防止するには？そもそも予防することはできなかった？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする

もっと細かく Backlog Itemを分割できたか？ユーザへの価値を考えると許容してもよい？そもそも予防することはできなかった？
この不具合を再発防止するには？良いタイミングでQA開始できていたか？テストケースを次はもっと網羅するには？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストするやろうと思えば無限にテストできるからバランスも難しい…

「どこでもテスト」するすべてが品質を高めるための取り組み

「壁をこわす」とは

「どこでもテスト」するとは言っても… すべてをQAエンジニアだけで実現するのは不可能

QAEが「壁をこわす」ことでチームメンバー全員で品質を高める文化を作る PdM デザイナー開発エンジニアアナリスト QAE スクラムで「壁をこわす」とは例えば？

じゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？過去事例的にテストケース多くなりそうこんな仕様で作りたい！
リファインメントでは、高いプロダクト理解をもってテストするこの既存仕様と矛盾してるかもエッジケース漏れてるかも ※ すべてをQAEがやる必要はない開発エンジニアはエッジケースを見つけるのが得意かも？

頼っちゃいましょうじゃあ開発エンジニアに

ユーザ行動ログはどう設計？過去事例的にテストケース多くなりそうこの既存仕様と矛盾してるかもエッジケース漏れてるかもこんな仕様で
作りたい！リファインメントでは、高いプロダクト理解をもってテストするじゃあもう少し仕様をシンプルにしますか ※ すべてをQAEがやる必要はない PdMはユーザへの価値を考慮したスコープの調整が得意かも？

頼っちゃいましょうじゃあPdMに

過去事例的にテストケース多くなりそうこの既存仕様と矛盾してるかもエッジケース漏れてるかもこんな仕様で作りたい！じゃあもう少し
仕様をシンプルにしますかリファインメントでは、高いプロダクト理解をもってテストする ※ すべてをQAEがやる必要はないデータアナリストはユーザ行動ログ設計が得意かも？ユーザ行動ログはどう設計？

頼っちゃいましょうじゃあデータアナリストに

というのを意識して計画を作ろう Itemごとにテストケース作ろうこのEpicはこう Backlog Itemに分割しよう
ここまで開発できたら一旦テストしようプランニングでは、開発計画作りへの高い理解をもってテストする開発エンジニアは開発を進めやすいBacklog Item分割が得意かも？

ユーザへの価値を考えると許容してもよい？もっと細かく Backlog Itemを分割できたか？良いタイミングでQA開始できていたか？
この不具合を再発防止するには？テストケースを次はもっと網羅するには？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする開発エンジニアはSET領域にも詳しいかも？そもそも予防することはできなかった？

全員で「どこでもテスト」するつまり「壁をこわす」ことで

One more thing...

後押しするための組織デザインそもそも「どこでもテスト」と「壁をこわす」はとても難しいこと

フルサイクルなチームを作る 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

フルサイクルなチームがバリューストリーム全体に関わるバリューストリーム全体でテストする引用：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

フルサイクルなチームバリューストリーム全体「どこでもテスト」と「壁をこわす」を後押し

まとめ

「どこでもテスト」「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？

スクラムのすべてのイベントでテストする「どこでもテスト」をQAエンジニアが推進する

チームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるようにする「壁をこわす」をQAエンジニアが推進する PdM デザイナー開発エンジニアアナリスト QAE

「どこでもテスト」「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？

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

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

More Decks by Masaya Hayashi

Other Decks in Technology

Featured

Transcript