Tweet
Tweet

Slide 1

Slide 1 text

受け入れテスト駆動開発で 不確実性に段階的に対処する 2024/5/11 スクラムフェス新潟

Slide 2

Slide 2 text

2 ・「よくある用語」をチーム独自のニュアンスで用いる場合があります。 　　あらかじめご了承ください。 注意事項

Slide 3

Slide 3 text

3 藤原 考功(Takanori Fujiwara) ・株式会社ユーザベースの社員(テストエンジニア) ・JSTQB(Japan Software Testing Qualification Board)技術委員 ・XP祭り実行委員 自己紹介

Slide 4

Slide 4 text

4 ・前職以前：手動テストがメイン、最後にまとめてテスト 　 ・現職：自動テストがメイン、常に継続的にテスト 私自身の、テストへの関わり方の変遷

Slide 5

Slide 5 text

5 ベイビーステップでの継続的な開発活動 & 私なりの感想 今日お話しすること

Slide 6

Slide 6 text

不確実性 | 01 | 6

Slide 7

Slide 7 text

7 ・計画 が 変わらない こと この発表における「確実」

Slide 8

Slide 8 text

8 ・一度決めた計画は高確率で変わらない 不確実性が低い場合 新潟 自宅

Slide 9

Slide 9 text

9 ・計画がどんどん変わる 不確実性が高い場合 新潟 越後湯沢 あっち こっち そっち

Slide 10

Slide 10 text

10 ・SaaS(Software as a Service)事業 ・経済情報によって、ビジネスをする人々をアシストするサービス 私たちのビジネスについて https://www.uzabase.com/jp/about/

Slide 11

Slide 11 text

11 ・計画に従うことよりも変化への対応を 不確実性への対処 https://agilemanifesto.org/iso/ja/manifesto.html

Slide 12

Slide 12 text

12 ・ちょっとずつ進むやり方 ベイビーステップ

Slide 13

Slide 13 text

受け入れテスト駆動開発 | 02 | 13

Slide 14

Slide 14 text

14 ・受け入れテスト ・テスト駆動開発 受け入れテスト駆動開発

Slide 15

Slide 15 text

15 ・「何ができたら完成と言えるのか」をテストに落とし込んだもの ・開発チームが実施するテスト この発表における「受け入れテスト」

Slide 16

Slide 16 text

16 ・「動くものを少しずつ作りながら綺麗にする」プラクティス ・最初にユーザーストーリーをバックログとして積む ・ユーザーストーリーを選んで失敗する受け入れテストを1件だけ書き、 　続いて設計と実装をする 　 (Red→Green→Refactorの順序を守る) ・受け入れテストがすべて合格になったら、そのユーザーストーリーは完了 ・ユーザーストーリーを倒したら、 　バックログを見直したうえで次のユーザーストーリーに取り掛かる この発表における「テスト駆動開発」

Slide 17

Slide 17 text

17 開発活動の入れ子構造 受け入れテスト ユニットテスト ユーザーストーリー

Slide 18

Slide 18 text

開発の流れ | 03 | 18

Slide 19

Slide 19 text

19 ・ユーザーは「酒-WEB」画面で、分類を指定して検索すると、 　お酒の銘柄と、その銘柄に関する最新のニュースを見ることができる ユーザーストーリーを選ぶ

Slide 20

Slide 20 text

20 受け入れテストの例

Slide 21

Slide 21 text

21 ・画面上の要素をAssertするテストコードを書く ・自然言語で記述した受け入れテストと紐付ける 　(私たちの場合は、GaugeとSelenideを採用) 受け入れテストを自動テストにする

Slide 22

Slide 22 text

22 紐付けの例

Slide 23

Slide 23 text

23 受け入れテストができたぞ！

Slide 24

Slide 24 text

24

Slide 25

Slide 25 text

25 受け入れテストの例(ベイビーステップ違反)

Slide 26

Slide 26 text

26 受け入れテストの例(ベイビーステップ)

Slide 27

Slide 27 text

27 ・受け入れテストが想定通りRedになったら実装に移ります 受け入れテストの作成完了

Slide 28

Slide 28 text

28 アーキテクチャーの例 酒-WEB 酒-BFF(※) 酒-API 銘柄 API 酒ニュース API ※BFF : Backend For Frontend ・一気に実装だ！

Slide 29

Slide 29 text

29

Slide 30

Slide 30 text

30 ・テスト対象を1つずつ倒す ・実装は、失敗するユニットテストを起点としたTDDで進める ここでもベイビーステップ 酒-WEB 受け入れ テスト 実装 ↑まずはここだけ！ Red Refac tor Green

Slide 31

Slide 31 text

31 ・テスト対象を1つずつ倒す BFFやAPIも要領は同じ 酒-BFF テスト 実装 ←今はここだけ！ 酒-API ←今はここだけ！ テスト 実装

Slide 32

Slide 32 text

32 BFFやAPIのテストの例

Slide 33

Slide 33 text

33 外側から内側に向かって開発する 酒-WEB 酒-BFF(※) 酒-API 銘柄 API 酒ニュース API ※BFF : Backend For Frontend 受け入れ テスト 実装 テスト 実装 テスト 実装 テスト 実装

Slide 34

Slide 34 text

34 外側から内側に向かって開発する 酒-WEB 酒-BFF(※) 酒-API 銘柄 API 酒ニュース API ※BFF : Backend For Frontend 全体 E2E テスト 実装 個別 E2E テスト 実装 実装 実装 個別 E2E テスト 個別 E2E テスト

Slide 35

Slide 35 text

・全て本物を使った状態で 　受け入れテストがGreenになればOK ・全体を通すので、私たちは 　全体E2Eテストと呼んでいます 35 最後の仕上げ 酒-WEB 酒-BFF 酒-API 銘柄 API 全体 E2E テスト

Slide 36

Slide 36 text

36 ・個別E2Eテスト ・全体E2Eテスト ・リグレッションテスト CIで実行するテスト

Slide 37

Slide 37 text

37 ・人の目でないと気づけないことを探す ・自動テストの補足的な立ち位置になることが多い 手動テストについて

Slide 38

Slide 38 text

個人の感想 | 04 | 38

Slide 39

Slide 39 text

39 ・ベイビーステップは精神衛生上とても良い 　・変化への対応が容易 　・テスト対象の分析が容易 受け入れテスト駆動開発について

Slide 40

Slide 40 text

40 ・ベイビーステップのネガティブな面 　・変化についていくことはしんどい 　・意識的に全体を見ないと失敗する 受け入れテスト駆動開発について

Slide 41

Slide 41 text

41 ・受け入れテストを書くハードルは低いと感じた 　(従来の働き方の延長でこなせた) ・ユニットテストは難しかった 　(DDDなどの設計理論を理解する必要があった) ・CIは道半ば 　(kubernetesが難しい) 手動テスト業務歴の長い私が受け入れテスト駆動開発に関わってみた結果

Slide 42

Slide 42 text

42 ・手動テストが少ないのはちょっと寂しい ・手動テストをすると、ソフトウェアの使い方を学びやすい 　(手動テストがソフトウェアを学習する手段を兼ねていたことを自覚した) 手動テスト業務歴の長い私が受け入れテスト駆動開発に関わってみた結果

Slide 43

Slide 43 text

43 ・ぜひ皆さんとお話ししたいです！ 最後に