Slide 1
Slide 1 text
1
QAエンジニアがAcceptance Criteriaを書いて
みんなで読んだら、
いい感じに開発ができているよ（公開用）
Scrum Fest Fukuoka 2023
@____rina____
Slide 2
Slide 2 text
2
Souzoh
QAエンジニア、スクラムマスター
福岡うまれ福岡そだち
@____rina____
Slide 3
Slide 3 text
3
今日のおはなし
1 Acceptance Criteriaを読みあわせること
2 Acceptance Criteriaを充実させること
3 QAがAcceptance Criteriaを書いてみたこと
Slide 4
Slide 4 text
4
Acceptance Criteria(AC）を読
みあわせて共通認識が改善した
共通認識を持つのはむずかしい？
Slide 5
Slide 5 text
5
前回（ブログ）からのアップデート
スクラムチームが発足
QAはひとり
QAとSM
https://engineering.mercari.com/blog/entry/20220912-cf3da857e5/
Slide 6
Slide 6 text
6
わたしたちについて
わたしたちのスクラムチーム
Slide 7
Slide 7 text
7
わたしたちのチームについて
PO/PM デザイナー エンジニア QA/SM
EM
Slide 8
Slide 8 text
8
Acceptance Criteriaについて
Slide 9
Slide 9 text
9
Acceptance Criteria（AC）ってなに？
https://www.bing.com/
Slide 10
Slide 10 text
10
今日のおはなし
1 Acceptance Criteriaを読むこと
2 Acceptance Criteriaを充実させること
3 QAがAcceptance Criteriaを書いてみたこと
Slide 11
Slide 11 text
11
テストするなら
https://www.bing.com/
ユーザー名？
ユーザーIDじゃなくて？
ID？メールアドレス？
パスワードの桁数は？
使用可能な記号は？
エラーメッセージの文言は？
ログイン処理のトリガーは入力？
ユーザーは迷わない？
Slide 12
Slide 12 text
12
なんでQAがACを書いてみたの？
● プロジェクトごとにテスト設計をしていた
● テスト設計するのも実行するのも私
● 他の人が見る機会がでてこなかった
○ テスト実施に入ってからフィードバックすることがあった
テスト設計しても私しか見ない問題
Slide 13
Slide 13 text
13
なんでQAがACを書いてみたの？
● QAが何しているかわからない
● どの辺でQAに渡せばいいかわからない
QAって何をテストしているの？
Slide 14
Slide 14 text
14
なんでQAがACを書いてみたの？
● POはP(d)M兼任
● 要件定義するときにACはある
● プロジェクトとか複数抱えている
● 各関係者とも色々やることある
● 詳しく書いてもらうには負担すぎる
PO忙しい問題（と、わたしが勝手に思っている）
Slide 15
Slide 15 text
15
そうだ
ACとして書いてしまおう
Slide 16
Slide 16 text
16
ACの書き方
ACを書くまでにどんな作業成果物があるのか
Slide 17
Slide 17 text
17
P(d)Mが作成
プロジェクト
単位に作成
デザイナーが
作成
チームがつくっている作業成果物
エンジニアが作成
プロジェクト
単位に作成
Spec UI Design
Doc
Slide 18
Slide 18 text
18
1. Specを作成
2. デザインを作成
3. ユーザーストーリーマッピング
4. ユーザーストーリーからプロダクトバックログアイテムを書き出す
全体の流れ
Slide 19
Slide 19 text
19
1. Specを作成（PO）
2. デザインを作成（デザイ
ナー）
3. ユーザーストーリーマッピン
グ（みんな）
4. プロダクトバックログアイテ
ムを出す（PO/みんな）
ACをつくる前の流れ
PO
デザイナー
みんな
エンジニア
QA
PO
Slide 20
Slide 20 text
20
ACの書き方
rinaの場合
Slide 21
Slide 21 text
21
ACのつくりかた
１ ユーザーストーリーマッピングを見る
2 Spec、デザイン、Desgin Docを集める
3 ACを書く
4 プロダクトバックログアイテムの順番を見直す
Slide 22
Slide 22 text
22
● Spec
● デザイン
● ユーザーストーリーマッピン
グ
● Design Doc
ACを書くためにつかうもの
PO
デザイナー
みんな
エンジニア
QA
PO
Slide 23
Slide 23 text
23
2. Spec、デザイン、Desgin Docを集める
Slide 24
Slide 24 text
24
チケットを並び替える
4. プロダクトバックログアイテムの順番を見直す
ユーザーストーリー 2
バックエンドタスク2
フロントエンドタスク1
ユーザーストーリー 1
フロントエンドタスク2
リリース
ユーザーストーリー 2
バックエンドタスク2
フロントエンドタスク2
リリース
フロントエンドタスク1
ユーザーストーリー 1
Slide 25
Slide 25 text
25
ACのよみあわせ
ここがよかった
Slide 26
Slide 26 text
26
■
ACよみあわせてよかったこと
Epic（やそれにちかい大きな単位）でまとめてQAがくることが
ほぼなくなった
■ 待ち状態が減った
■ 受け入れ条件が明確になるのがよい（エンジニア）
■ 要求にブレがないか、整合性がとれているかを確認できる時間
になっている（PO）
Slide 27
Slide 27 text
27
ACよみあわせてよかったこと
ACなしじゃ開発できない（しめしめ）
Slide 28
Slide 28 text
28
ACを読み合わせて、共通認識を持って開発しよう
まとめ
ACを充実させて、あんしんして開発しよう
02
01