受け入れ条件を E2E テストにしてから実装する Outside-In 開発フローと、その運用

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

受け入れ条件を E2E テストにしてから実装する Outside-In 開発フローと、その運用グリーエックス株式会社ソフトウェアエンジニア松井寛太

Slide 2

Slide 2 text

松井寛太グリーエックス社ソフトウェアエンジニア 2017年よりゲーム・Webの両領域でエンジニアとしてキャリアを積み、2022年よりグリーエックス株式会社に所属。フロントエンドからインフラまで一貫して開発を担当している。 2

Slide 3

Slide 3 text

アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 3

Slide 4

Slide 4 text

AI で実装は速くなったが、確認が追いつかない動作確認待ち仕様 AI 人が仕様を渡す画面・機能がすぐできる中身をよく知らないまま動作確認だけする作るより、確かめるほうに時間がかかる 4

Slide 5

Slide 5 text

確認の判断と責任は人が持つ人が決める何を満たすか・どう確かめるか・受け入れるか機械に任せる記録に残す毎回同じ手順で繰り返せる確認自動も人の確認も、何をいつ確認したか何を確認したのか、後から説明できる状態を作る 5

Slide 6

Slide 6 text

仕様書や実装から E2E を生成する仕組み仕様書 E2E テスト期待する動き実装 AI 動作と確認箇所用意する手間は大きく減った 6

Slide 7

Slide 7 text

画面が真っ白でもテストが通っていた確認していたのは「詳細画面の項目が出ない」ことだけ example.com/items/2 このデータは表示できませんテスト成功正しい拒否 example.com/items/2 example.com/items/2 エラーが発生しました時間をおいて再度お試しくださいテスト成功テスト成功想定外のエラー白画面本当は失敗すべき本当は失敗すべきテストの成功だけでは、完成と判断できない 7

Slide 8

Slide 8 text

仕様・実装・E2E の対応を記録する変更仕様何を満たすか対応関係とハッシュ値を記録見直す見直す実装 E2E どう動かすか満たしたかを確かめるずれを見つけたら、AI が仕様に合わせて直し、人が差分を確認する 8

Slide 9

Slide 9 text

アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 9

Slide 10

Slide 10 text

受け入れ条件を実装の前にテストにする受け入れ条件＝クライアントと合意した、完成かどうかの判断基準今回：先に E2E にする条件に合意判断基準を、最後から最初へこれまで：最後に確かめる実装受け入れ判断合意した条件の E2E を、実装中も繰り返し実行する最後の受け入れ判断は、これまでどおり行う 10

Slide 11

Slide 11 text

受け入れ条件を E2E にしてから実装する案件での基本フロー ① 受け入れ条件残したい改善は次の受け入れ条件に人 ⑤ 継続検証触って改善自動テスト・人 ② E2E 作成失敗の確認 Outside-In AI・自動テスト利用者から見える動きを先に決めそこから実装へ進む ④ レビューマージ人 ③ 実装・PR 作成 AI 参考：Gojko Adzic『Speciﬁcation by Example』Manning, 2011 11

Slide 12

Slide 12 text

受け入れ条件を .feature にまとめる受け入れ条件他社のデータの詳細は表示されない Gherkin で書く日本語で書けるので、 PM やクライアントも読める company-data.feature # language: ja 機能: 他社のデータの詳細表示 @AC-001 @red-contract シナリオ: 他社のデータの詳細は見えない前提 A 社・B 社のデータがあるかつ A 社の利用者でログイン済みもし B 社のデータの詳細ページを開くならば拒否のメッセージが表示されるかつ B 社のデータの項目は表示されない前提操作期待結果 12

Slide 13

Slide 13 text

見えないことに加えて、拒否も確かめる example.com/items/2 example.com/items/2 example.com/items/2 このデータは表示できませんエラーが発生しました正しい拒否想定外のエラー白画面見えないことだけ確認成功成功（見逃し）成功（見逃し）拒否画面も確認成功失敗（気づける）失敗（気づける）前のページの company-data.feature よりならば拒否のメッセージが表示されるかつ B 社のデータの項目は表示されない ← 追加した確認 ← もともとあった確認 13

Slide 14

Slide 14 text

実装前に、テストが正しく失敗するか確かめる環境の問題なら、先に直す機能がない Red 機能がなく失敗する原因を確認実装 Green 条件を満たして成功する機能がないから失敗している → 実装へ期待値は、実装ではなく受け入れ条件から決める 14

Slide 15

Slide 15 text

タグは 2 種類：進み具合と、合否の決め方状態タグ：進み具合。完了したら外す @draft @red-contract 草案：まだ実行しない実装待ち：テストは失敗状態タグなし完了と宣言成功は実行結果で確かめる判定タイプのタグ：何で合否を決めるか。条件の ID（@AC-001 など）と同じく、完了後も残す画面タグなし（既定）数値・記録 @oracle:data 人間 @human E2E だけで確かめる E2E ＋人人だけで確認表示・遷移・権限などローカルの E2E で値を確かめ、検証環境の値は人が確認。両方そろって確認済み E2E の実行から外し、人が確認して記録を残す。例：外部システムへの反映 15

Slide 16

Slide 16 text

AI が書いた条件をツールが点検する人がレビューする前に 3 つ点検する点検こう書いてあるとツールが出す案否定だけの確認「表示されない」「遷移しない」だけ拒否のメッセージなど、正しく起きたことを肯定で確かめる行を足す期待する値を書いていない「件数が表示される」だけで、何件なら正しいかが無い前提でデータを固定し、期待する値を具体的に書く。値は仕様から取り、無ければ仕様への加筆を頼むテストで用意できない前提外部システムの状態、共有データ、実際の時刻に依存環境を限るタグ、または @human（人が確かめて記録を残す）点検は提案だけ。条件そのものは書き換えず、取り入れるかどうかは人が決める 16

Slide 17

Slide 17 text

.feature の書き方は機械でチェックする自作ツールが警告として出す（AI は使わない）確認（ならば）の無いシナリオ前提・操作・確認の順番が逆の手順同じ手順のシナリオの重複前提と操作が同じで確認だけ違う（矛盾の候補）理由コメントの無い @out-of-scope テストを止めるタグ（@skip など）中身の判断は人、書き方のチェックは機械警告として出し、設定で CI を失敗させることもできる 17

Slide 18

Slide 18 text

自動確認と人の確認を分担した受託 Web サービス 1 案件の受け入れ条件 100 件超約6割約2割約2割 E2E だけ E2E ＋人人表示・権限作成・編集・削除集計値・件数監査ログ外部表示・反映時間旧システムとの一致確認方法を先に分けたので、人の確認を必要なところに絞れた 18

Slide 19

Slide 19 text

アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 19

Slide 20

Slide 20 text

壊れていないか E2E で確かめながら改善した通知・エラーメッセージ操作の流れ E2E 初回の実装見やすさ・文言 E2E E2E 約2週間同じ動作確認を人がやり直さずに、次の改善へ進めた 20

Slide 21

Slide 21 text

残したい改善は受け入れ条件に追加した受け入れ条件触ってみて必要だと判断最初クライアントと合意した条件追加送信済みのものを複製して、新しく作れる追加詳細画面から、宛先を指定して送れる追加更新したときは、必ず通知し直す次の変更でも確かめるので、改善を失いにくい 21

Slide 22

Slide 22 text

守りと攻めの両方で、品質を上げられた守り攻めリグレッションを出さない使いやすさを上げる差し戻しなし約2週間の改善改善を重ねても、前にできていたことを壊さずに受け入れ確認を通過操作の流れ、通知・エラーメッセージ、見やすさ・文言を改善 E2E で確かめ続ける人が触って改善する 22

Slide 23

Slide 23 text

守りを E2E に任せて、攻めに時間を使えた攻め：一元的品質・魅力的品質使いやすさや価値を高める例：操作の流れを改善する人が改善する同じ確認に使っていた時間を回す守り：当たり前品質欠けると強い不満になる例：他社のデータは見えない E2E で守る狩野モデル：品質を「当たり前品質」「一元的品質」「魅力的品質」などに分けて考える枠組み参考：狩野ほか「魅力的品質と当り前品質」品質 14巻2号, 1984 23

Slide 24

Slide 24 text

合意した品質は守り、使いやすさを良くしたい時間の使い方（イメージ）これまで実装：AI 守り：人が毎回触って確かめる攻め実装は AI で短くなったが、人の確認の時間は変わらない。むしろ増えることもある目指す姿実装：AI 守り：E2E 攻め：使いやすさや体験を良くする橙 = 人の時間青 = AI・機械そのために、確認を機械に任せる仕組みを作っている 24

Slide 25

Slide 25 text

進捗は、確認できた受け入れ条件の数で見る条件の一覧 E2E の実行結果成功・失敗・未実行人の確認記録確認済み・未確認二つを合わせた判定条件種類 E2E 人判定 AC-001 画面成功 ― 確認済み AC-014 数値成功未確認未確認 AC-031 人だけ ― 確認済み確認済み AC-042 画面未実行 ― 未確認確認済み 2 件 / 4 件（表示例） 25

Slide 26

Slide 26 text

毎日の結果を見て、次の作業を決める例: 平日 17:30 に Slack へ自動で投稿 E2E 定期実行 17:30 読み取って、次の作業を決める受け入れ条件の確認状況受け入れ条件 48 件（E2E 37 人 11） 48 件 → 仕様の増え方も見る E2E：成功 30 失敗 1 実装待ち 6 失敗 1 → 失敗した条件を調べる人の確認：OK 8 NG 0 未確認 3 未確認 3 → 人の確認を進める期日の見通し：順調順調 → 件数から出した参考の判定スレッド：要対応の条件の一覧数値は表示例 26

Slide 27

Slide 27 text

アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 27

Slide 28

Slide 28 text

受け入れ条件を満たすまで AI に実装させる自動化の検証フロー ① 受け入れ条件人 ⑤ 継続検証触って改善自動テスト・人 ②〜④ に人の手は入らない ② E2E 作成実装 AI・自動テスト人は ① で条件を決め ⑤ で結果を見る ④ レビューマージ自動 ③ PR 作成 AI 検証用アプリで試行中。受託案件での無人運用はまだ試していない 28

Slide 29

Slide 29 text

テストが通るまで AI が実装を繰り返す自動化の検証フロー ② の中身 ② E2E作成実装 ① 受け入れ条件 E2E テストすべて成功 AI が実装 E2E を実行人が確認済み ③ PR 作成 AI 失敗したら修正して、もう一度 AI・自動テストのみ 29

Slide 30

Slide 30 text

AI がテストを書き換えられないようにする 3 つを組み合わせて固定を守る固定する受け入れ条件 E2E 人が確認した基準 AI は書き換えない書き込み権限を絞る AI が書く作業後の差分を確認実装ハッシュ値を照合テストが通るまで実装を直す検知したら止めて、人の判断に戻す条件やテストを変えたいときも、人の判断に戻す 30

Slide 31

Slide 31 text

気づいたことを次の条件とテストに追加する AI が画面を探索気づきを記録して渡す人が触って確かめる人が振り分ける受け入れ条件に追加 E2E と実装へ不具合／条件の漏れ／問題なし残すと決めたものだけ次の変更でも確かめる使った感想・気づき先ほどの案件で、複製や通知の改善を条件に加えた流れと同じ残すかどうかは人が決めて、受け入れ条件に追加する 31

Slide 32

Slide 32 text

AI に画面を探索させて、条件の漏れを探す AI が画面を探索人が振り分け境界 0 件・ちょうど収まる件数・1 件あふれる不具合受け入れ条件ここから観点を少しずらす権限未ログイン・権限のない人が URL を開く事実を記録操作・画面動画条件の漏れ問題なし状態の組合せ期限切れ・退会済みが混ざる 32

Slide 33

Slide 33 text

触り心地や楽しさは人が判断する AI が手伝う人が判断する探索して、気づいたことを記録して人に渡す触り心地や楽しさ、使い続けたいか条件の漏れ機械で確かめやすい状態の組合せ連打・同時操作触り心地使って楽しいか使い続けたいか最終的に人が判断する 33

Slide 34

Slide 34 text

アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 34

Slide 35

Slide 35 text

自作ツールの 4 つの機能受け入れ条件 4 つの機能の共通の基準 AI で生成 17:30 投稿気づき仕様 E2E 実装 Green E2E 生成＋関連管理確認状況進捗の可視化自動実装ループ探索フィードバック支援仕様と実装から E2E を作り、変更を検知する実行結果と人の記録から毎日の現在地を投稿固定した条件に合格するまで実装 AI が画面を探索し気づきを人に渡す 35

Slide 36

Slide 36 text

まとめ受け入れ条件を軸に、合意した品質を守り、改善に時間を使う課題解決策受け入れ条件を、実装の前に E2E テストにする AI で作るのは速いが確認が追いつかない自動と人の確認を分け、結果を改善と進捗の把握に使う実装とフィードバックの自動化へ広げる 36

Slide 37

Slide 37 text

ご清聴ありがとうございました公開ツール specproof github.com/Pound79/specproof E2E 生成・関連管理条件の点検書き方のチェック参考：Gojko Adzic『Speciﬁcation by Example』Manning, 2011 狩野ほか「魅力的品質と当り前品質」品質 14巻2号, 1984 37

Slide 38

Slide 38 text

No content