Agile Testingを夢見たテスト自動化〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank

by Kazuki Higashiguchi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

CIのためのテスト自動化 https://www.shutterstock.com/image-vector/developer-laptop-computer-open-robotic-soft-1241063605

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 33% E2Eテストがあるプロジェクト ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/

Slide 5

Slide 5 text

5 44% 開発者10人あたり担当者QA 1人未満 ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/

Slide 6

Slide 6 text

6 12% BDDテクノロジーを使用している ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/

Slide 7

Slide 7 text

7 E2Eテストが有る “専任”QA エンジニア不在 BDD を使用している多くの現場に共通しながらちょっと珍しいチャレンジをした開発チームの物語

Slide 8

Slide 8 text

8 Engineering Manager @ BASE BANK （BASE 100%子会社） Kazuki Higashiguchi @hgsgtk Backend engineer Engineering Manager QA engineer Tech lead 商業誌執筆（寄稿） ● Software Design 2020年12月号コンテナアプリケーションの設計セオリー ● みんなのPHP (2019年) PHPにおけるユニットテストの育て方ソフトウェアテスト関連の社外向け資料 ● 実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 (PHPerKaigi 2021) ● 「質」のいいユニットテストを書くためのプラクティス (PHPerKaigi 2019)

Slide 9

Slide 9 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 今回の登壇にいたる経緯 9 2021.08.21 講演登壇のご相談をいただく 2021.01.24 『TDDからATDDへ歩みをすすめる』 @July Tech Festa 2021 2021.03.27 『実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜』 @PHPerKaigi 2021 2021.02.10 TDDとATDD 2021 kyon_mmさんとの公開雑談 2021.11.18 第17回QUES 「CIのためのテスト自動化」 QUES事務局の皆様

Slide 10

Slide 10 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 10 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 11

Slide 11 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 11 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. BASE BANKチームの概観 *1 *1: 2021年11月18日時点の概観です職能横断型チーム “専任QA engineer”はいない ○ hgsgtkがEMと兼任 ○ BASEにはProcess engineeringチームがあり専任で”QAを担う”、適宜知見をお借りしながら ※2 より詳しくBASEの開発組織が知りたい方はSpeakerDeckに公開されている「BASE株式会社エンジニア向け会社紹介資料」をご覧ください。 PdM/事業部長 (Product Owner) Biz/CS EM / QA Designer ... Data scientist Enginners SRE ... Process engineering (QA) ... ... ... ... Service Dev team xxx yyy zzz ※2

Slide 15

Slide 15 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. BASE BANKチームのプロダクト開発状況即時に資金調達ができる「YELL BANK」ネットショップの売上がすぐに使える「BASE Card」 ... ... ● 短いイテレーションを回し、ユーザーストーリーベースの開発計画を行っている ● ユニットテストを書き、その他静的解析やフォーマットも含めて、CIでの自動実行を行う。CircleCI等を用いてCI/CD Pipelineを組みデプロイ自動化を行っている

Slide 16

Slide 16 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 16 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 課題提起からうまく進まなかった ● 「API結合レベルの自動テストの仕組みを用意する」ためのHOWの情報はたくさん集まった ● 一方でWhyとの結びつきが弱く、選択肢の数々に対して落とし所がわからなくなる ● Whyについてキーワードしかあげていない。キーワードだけで周りは理解できない。おそらく自分自身もわかっていない。

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 根本に立ち戻る BASE BANKチームでは「技術戦略」を設定短期的計画に依存しないエンジニアリング組織としての戦略定義

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Agile Testingを夢見た https://www.shutterstock.com/image-photo/childhood-dream-about-big-famous-future-2006490497

Slide 23

Slide 23 text

23 アジャイルテストの定義 “始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的なテストの実践により、お客様への価値の頻繁な提供をサポートします。テスト活動は、高速なフィードバックループを用いて理解を検証しながら、プロダクトの品質を築くことに重点を置いています。このプラクティスは、品質に対するチーム全体の責任という考え方を強化し、サポートします。” “Our ever-evolving, never set-in-stone deﬁnition of ‘agile testing’” by Lisa Crispin and Janet Gregory

Slide 24

Slide 24 text

24 継続的に実施される協調的なテストの実践 > Continuous Testing in DevOps DevOpsにおけるあらゆるフェーズにおいてTestingは存在している「Continuous Testing（継続的テスト）」という考え方継続的かつ全体的なテストアプローチを重要とするあらゆるフェーズにおいてテストが継続的に実施され続ける “Continuous Testing in DevOps…” by DAN ASHBY (2016年10月19日)

Slide 25

Slide 25 text

25 品質に対するチーム全体の責任 > TESTING Manifesto The Testing Manifesto - Growing Agile by Karen Greaves and Samantha Laing（2015年4月10日）成功するアジャイルテストアプローチに必要なマインドセット 1. 最後のテストではなく、全体を通してのテスト 2. バグを見つけることより、バグを防ぐこと 3. 機能のチェックよりも理解度のテスト 4. システムを壊すことよりも、最高のシステムを構築すること 5. テスターの責任よりも品質に対するチームの責任

Slide 26

Slide 26 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストのPractices 26 26 Janet Gregory氏・Lisa Crispin氏によるアジャイルテストで行われる活動の整理図: “Our ever-evolving, never set-in-stone deﬁnition of ‘agile testing’”をマインドマップに起こした

Slide 27

Slide 27 text

27 特に注目した考え方 ● コードの欠陥だけでなくフィーチャーの振る舞いに関する誤解を防止する ● 会話による共通の理解形成 ● テストの自動化 ● 具体的な例による開発のガイド “Our ever-evolving, never set-in-stone deﬁnition of ‘agile testing’”より

Slide 28

Slide 28 text

28 考えの全体像を示す（当時の説明）「柔軟」を実現するために、 ● ソフトウェアのデリバリー速度と変更可能性を高める ● イテレーションごとに作るサービスの外部品質・内部品質をどうあげるか ● Agile Testの考え方が全体像のヒントになる ● その中で例によって駆動するEDD(Exapmle Driven Development) ● ATDDに取り組むためのテスト自動化を実現したい

Slide 29

Slide 29 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. プロダクト開発における課題意識が明確に ● ユーザーストーリーの受入条件が曖昧になりがち。「何をもって完成したのかを判断する基準」が明確になっていない故、共通見解が取れてなかったこともあった ● これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合は手動で同じシナリオを毎回テストしている “ストーリーは成功と失敗の2値で判断できるようテスト可能でなければならない。テスト可能にするとは、ストーリーに（満足条件として）関連付けられる適切な受け入れ条件があるということだ。これは5.4節で述べたユーザーストーリーにおける確認という観点である。” 『エッセンシャルスクラム』より

Slide 30

Slide 30 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 課題設定のスコープを見直して変更した ● 課題設定のスコープは「開発の進め方自体」の改善 ● ストーリー受入テストに着目する ● その一つの施策としての「テスト自動化」その後のISSUEコメント *1 ※1 完了条件・完成条件などの語彙の使い方がめちゃくちゃですね。当時の走り書きの文章で残念なことになってるのでご勘弁くださいmm

Slide 31

Slide 31 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 31 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 32

Slide 32 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 最初の舞台はMarket in済みのWeb APIサービス 32 for End user for administrator API service service A End users BASE Staﬀs ● 新規構築ではなくすでに本番稼働していたサービス ● アプリケーション開発だけでなくインフラ・CI/CDもすべて自チームのみで運用している、意思決定のハードルが低いのでまずここで試した Database RDBMS KVS service B external API

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストの四象限 35 http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1 2. Lisa Crispin氏・Janet Gregory氏によって「アジャイルテストの4象限」と命名された（『Agile Testing』2009） 1. Brian Marick氏による4象限の分類 (2003) ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019 年)の定義に準拠『テスト駆動開発』付録C での解説より https://www.amazon.co.jp/dp/4274217884

Slide 36

Slide 36 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストの四象限の「縦軸」 36 Designer Engineer PO Test engineer Business focus Technical Focus Business Focus: ビジネスの専門家が興味を持つような言葉で説明される Technical Focus: プログラマの領域の言葉で説明されるテスト

Slide 37

Slide 37 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「誰の不安によって実施するのか」という問い 37 Designer Engineer PO Test engineer Business focus Technical Focus 誰の不安・関心によって実施されるテストか例： ● エンジニアとしてビジネスロジックを統合して本当に動作するのか知りたい ● テストエンジニアとして実装されたシステムが受け入れ条件を満たしているのか確かめたい Who: 誰が作りたいのか Why: なぜやりたいのかおのずと見えてくる

Slide 38

Slide 38 text

38 四象限ごとの自動テスト特性 Q1: Code levelでの開発者の関心をテストできる - 特にプログラマがテストを書きやすいこと - ローカル開発環境で実行できる体験 - システム異常系の再現といった例外系のニーズも強くなる Q2: 顧客視点でのテスト記述と頻繁な実行 - プログラマ・テストエンジニア・仕様定義者が書きやすい - 顧客視点で確認したい機能性をシステムレベルで統合的にみたいニーズが強い - シナリオベースでのテスト作成 Q3: 製品批評の一部自動化 - 本番環境テストなど定期的に本番システムをテストしたい（ex. New Relic Synthetics） Q4: 品質特性ごとのテスト要件 - 「パフォーマンステストであれば、本番同等環境を非定期に実行できればよい」といったテストごとのテスト実行要件（頻度・統合レベル...etc）がある補足

Slide 39

Slide 39 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 今回のATDDを見据えたテスト活動においては... 39 Designer Engineer PO Test engineer Business focus Technical Focus ● Test engineer ● Product Owner ● Engineering program manager ...etc Who Why ユーザーストーリーの実装が受け入れ条件を満たしているのか確かめたい

Slide 40

Slide 40 text

Slide 41

Slide 41 text

2017年Katrina Clokie氏が『A Practical Guide to Testing in DevOps』にて紹介した自動テストの構成モデル。 Unit, Integration, E2E に加えて、本番環境で行われる Alerting, Monitoring, Logging が追加。フィルターの粒度の細かさ（細かいほど卵の段階で早期発見につながる） Unit > Integration > E2E Alerting < Monitoring < Logging 層のサイズ（より統合された環境でしか気がつけないバグもある） Unit < Integration < E2E < Alerting, Monitoring, Logging 41 DevOps Bug Filter

Slide 42

Slide 42 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 目的と既存のテスト資産をかけ合わせた意思決定 ● Test engineer ● Product Owner ● Engineering program manager ...etc Who Why ユーザーストーリーの実装が受け入れ条件を満たしているのか確かめたい Test asset すでにユニットテストは自然と開発者によって作成され、CIでの継続的な実行も行われている「E2E」をスコープとする ATDD活動での自動テストはより高レベルなテストが求められる傾向※1にあり、弊プロダクト事情としても、ビジネス的関心のテストを表現する自動テストの多くは、UIやAPI経由でのE2E Testであるため。 ※1 実際にATDDの自動テスト実装においてどのレベルのテストが求められるかは、テスト対象システムの要件・テスト自動化の費用対効果等によって変わります。

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスティングフレームワークを選択する 44 有名なBDDツール Gherkin Syntaxをサポート https://cucumber.io/ ThoughtWorks社がメンテしている Go製の受け入れテスト自動化フレームワーク https://gauge.org/ A php framework for autotesting your business expectations. https://docs.behat.org/en/latest/ 選ばれたのは... ● Markdownベースのシンプルな仕様記述Syntax ● ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポートしている ● メンテナンスが活発（Issueをあげたら数分後に返事が来た） ● Visual Studio Codeの拡張（新規PJ作成・テスト実行・コード補完・定義ジャンプ・フォーマット...etc） Uncle Bob氏により作成された Wikiで記述する http://ﬁtnesse.org/FrontPage 顧客視点のシナリオテストの作成・実行の仕組みを用意するため、受け入れテスト自動化ツールを見回った。

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

47 gauge Specification Syntax 補足 Markdown-likeなSpecification Syntax # Specification 仕様、xUnit系でのテストクラスに該当 * Contexts step 前処理、xUnit系でのSetUpに該当 ## Scenario 個別のテストシナリオ、xUnit系ではテストメソッド * Step テストシナリオ内で実行するステップ ___ 後片付け、xUnit系でのTearDown 定義後のStepは後片付け処理として実行される

Slide 48

Slide 48 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テストコード保守観点での利点 48 example.spec 「技術的なテスト自動化実装の都合」と「本当にテストしたい仕様」を切り離して考えられる ○ *.spec で定義したステップを選択したプログラミング言語で実装する ○ ex. placeholderやid・classで要素を特定する「実装の都合」はステップ実装内にカプセル化される API Client実装 webdriver ChromeDevTool Pythonの場合は @step() でマッピング JavaScriptの場合は step() でマッピング

Slide 49

Slide 49 text

Slide 50

Slide 50 text

50 テスト環境の選択肢 API service service A RDBMS KVS service B テスト実行ごとに毎回新規環境を作成する自動テストのためのCI専用環境を用意する手動検証環境を利用する System Under Test A B C

Slide 51

Slide 51 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. A. テスト実行ごとに毎回新規環境を作成する B. 自動テストのためのCI専用環境を用意する C. 手動検証環境を利用する利点完全にCI Job専用の環境テスト実行結果は安定しやすい手動テストなど人の操作の影響を受けない独立性すでに構築済みの環境を用いるため始めやすい欠点構成が複雑であるほど構築難易度は高い稼働コスト既存のCD pipelineへの組み込み工数手動テストの影響を受ける可能性がある *1 初期工数テスト環境の選択肢それぞれの評価 51 *1 手動テスト環境と自動テスト環境を混ぜるリスクは『Speciﬁcation by Example』のChapter 10. Validating frequently にて解説されている。テスト失敗時に「テストが正しく失敗した」のか「手動テストの影響を受けた」のかわかりにくくなる点を指摘している。

Slide 52

Slide 52 text

52 「C. 手動検証環境を利用する」を選択したまずは始めることを優先したやってみないことには「本当に自分たちが必要なもの」はわからない

Slide 53

Slide 53 text

Slide 54

Slide 54 text

CIのためのテスト自動化 https://www.shutterstock.com/image-vector/developer-laptop-computer-open-robotic-soft-1241063605

Slide 55

Slide 55 text

Slide 56

Slide 56 text

56 CircleCIでのjob実行例補足 .circleci/conﬁg.yml https://github.com/hgsgtk/gauge-python-circleci-sample/blob/v0.0.2/.circle ci/conﬁg.yml

Slide 57

Slide 57 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. データ準備の煩雑さでテスト増やすのに苦戦した環境変数用ファイルテストA用テストB用 *.properties.sample テストD用テストC用テスト作成者 Database 2. 作成したユーザーの情報をテスト用の環境変数ファイルに記載する 1. 手動でアカウントデータを作成しておく苦戦していた際のテストデータの作り方テスト作成者 3. テスト自動化コードは環境変数からアカウント情報を取得する

Slide 58

Slide 58 text

Slide 59

Slide 59 text

59 テストデータを作るタイミング2選 1 テスト環境に手動でデータを用意しておく毎Scenarioごとにデータを作成・調整 ● テスト自動化コードを書く前にひと手間発生 ● テストシナリオとデータの関係性が暗黙的になりわかりづらくなる ○ ex. ID=1のショップを使う（なぜ？ ● 環境差異の影響を受けにくい ● E2Eにおいて自動でデータを用意しにくいことも多い ○ ex. 本人確認書類での本人確認を終えたショップを用意しよう ● テスト速度が低下する ○ ex. 毎回ネットショップを開設すると？ 2

Slide 60

Slide 60 text

Slide 61

Slide 61 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 61 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 62

Slide 62 text

ATDDとは https://www.shutterstock.com/image-photo/close-top- view-young-business-people-1498583432

Slide 63

Slide 63 text

Slide 64

Slide 64 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDD in アジャイルテスト 64 64 「具体的な例」によって開発をガイドする第2象限のテストプラクティス “Example-driven development, whether you use ATDD, BDD, or SBE, is a core practice for agile teams, and it takes work and practice to learn how to do it eﬀectively. “ (『More Agile Testing』) → 「具体的な例による開発のガイド」となる Example-driven development は、アジャイルチームのコアプラクティス

Slide 65

Slide 65 text

Slide 66

Slide 66 text

66 ATDDに近い名前のプラクティス補足 ● ATDD (Acceptance Test-Driven Development) ※1 ● BDD (Behavior-Driven Development) ● SBE (Speciﬁcation by Example) ● Agile Acceptance Testing ● Story Testing ● Story test-driven development ● Functional test-driven development ● ...etc 2019年10月出版『Agile Testing Condensed: A Brief Introduction (English Edition)』では、ATDD/BDD/SBEの3つが語彙として取り上げられている。 ※1 『テスト駆動開発』（原著）では”application test-driven development”の略語としてATDDを紹介しているが概ね同じものを指している

Slide 67

Slide 67 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDとは ATDD: Acceptance test–driven development（受け入れテスト駆動開発）特徴 1. コラボレーションを重視したソフトウェア開発プロセス 2. ユーザーストーリーの受け入れテストである「ストーリー受け入れテスト」に着目する 3. 「入れ子のフィードバックループ」を回す 4. 例によって駆動する「Example-driven development」のひとつのバリエーション(※1) 5. 厳密な言語やルールのない例を使用して開発を導く、より一般的な形式 67 『More Agile Testing: Learning Journeys for the Whole Team』 Chapter 11. Getting Examples ※1 「Example-driven development」のバリエーションはATDDの他にBDD(Behavior-driven development)や SBE(Specification by Example)等が挙げられます。

Slide 68

Slide 68 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 2. 「ストーリー受け入れテスト」とは 68 ● Acceptance Test（受け入れテスト）は、様々なイメージで分かれる ○ ex. ユーザー受け入れテスト(UAT)・運用受け入れテスト...etc ● ATDDにおけるAcceptance Testの定義 = ストーリー受け入れテスト ○ 「各ストーリーが提供しなければならないビジネス意図を記述したテスト」 ● 機能テストのみではなく、他の品質特性の要件（セキュリティやアクセシビリティ、パフォーマンスなど）もスコープに含む “We deﬁne acceptance tests as the tests that describe the business intent each story must deliver. (omit) However, they may also include a broad range of tests that encompass everything except TDD at the unit and component level. They may include quality attributes such as usability and performance, although we prefer to think of those as constraints that apply to all stories.” （『More Agile Testing』 Chapter 11. Getting Examples）

Slide 69

Slide 69 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 3. 「入れ子のフィードバックループ」を回す 69 “システムレベルではATDDで開発を進め、各機能の実装ステップではTDDを採用する。TDDとATDDは密結合ではないが組み合わせて使うことで威力を発揮し、シームレスに調和する” （『Practical TDD and Acceptance TDD for Java Developers』 Chapter1: Big Picture） TDDとATDDを組み合わせて使うことで入れ子のフィードバックを作り出す。 [具体的な作業ステップ] 1. 失敗するストーリー受け入れテストを最初に書く 2. 「ストーリー受け入れテスト」を通す過程でTDDサイクルを回す 3. n回のチェックイン後、ストーリー受け入れテストを通す図: 『実践テスト駆動開発』（GOOS）を参考に作成した、内側と外側のフィードバックループ図

Slide 70

Slide 70 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 自動テストから得られるフィードバック 70 『実践テスト駆動開発 (Object Oriented SELECTION)』第一章テスト駆動開発のポイントとは？ https://www.amazon.co.jp/dp/4798124583 外部品質のフィードバック - エンドツーエンドのテストの実行によってシステムの外部品質へのフィードバックを多く得られる - ストーリー受け入れテストを書くことでドメインについてチームがどれほど理解できているかについての知見が得られる内部品質のフィードバック - ユニットテストを書くことで、コードの質についてのフィードバックを数多く得ることができる外部品質: システムが顧客やユーザーのニーズにどれだけ応えられているか（機能を備えているか、信頼できるか、利用できるか、素早く反応するか...etc）内部品質: 開発者や管理者のニーズにどれだけ応えられているか（理解しやすいか、変更は容易か...etc）

Slide 71

Slide 71 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 4. 例が駆動する「Example-driven development」 71 “Acceptance Test-Driven Development: Not as Optional as You Think” by Jennitta Andrea https://www.stickyminds.com/article/acceptance-test-driven-development-not-optional-you-think ● ストーリー開発前に、要求を具体的な例と期待値として表現する。この際、ビジネス・開発者・テスター等ステークホルダーによる共同作業を行う ● 例（Example）を書いて自動化し開発を進め、自動化されたチェックに合格すると、探索的テスト等他テストを行う準備ができたとみなす

Slide 72

Slide 72 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 5. 厳密な言語・ルールのない例で開発を導く 72 ● ユーザーストーリーに対して、具体的な例をビジネス・開発者・テスター等ステークホルダーで会話し特定する ● 関係者が理解でき会話できることが期待できる、事業領域の用語で受入テストとして具体化する ○ その際の言語・記述ルールに対する厳密な規定はしていない図：Cucumberを用いた場合は Gherkin 記法によってシナリオ記述図：gaugeを用いた場合は Markdown 記法によってシナリオ記述

Slide 73

Slide 73 text

ATDDの実践 https://www.shutterstock.com/image-photo/new-year- 2021-start-straight-concept-1843332130

Slide 74

Slide 74 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 舞台は新規機能開発 74 for End user for administrator API service service A End users BASE Staﬀs Database RDBMS KVS service B external API new service ● サービスの管理業務を担う”for admin”とエンドユーザー向けの”for end user” ● アプリケーション開発までは自チームだけで完結するがCI/CDやインフラは別チームも関わってくる”大きなシステム”

Slide 75

Slide 75 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDの仕事の流れ 75 ユーザーストーリーを洗い出す１１ 2 3 4 例を特定しユーザーストーリーの受入条件に反映する受入条件を受け入れテストに反映する実装・受け入れテストを実行する 2 3 4 第17回QUESでは『CIのための自動化』がテーマなので概要レベルで割愛します。詳細を見たい方は『実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜』をご覧ください。

Slide 76

Slide 76 text

Slide 77

Slide 77 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ブラウザ自動テストツールを選択する 77 ● microsoft/playwright ● Chronium, Firefox, WebKit, Microsoft Edgeブラウザ操作を自動化するAPIを提供している Node.jsライブラリ ● GUI操作を記録してコード生成する Inspector というツールの体験が良い ● Pupetteer ● Google製のChromeまたはChromiumを制御するためのAPIを提供しているNode.jsライブラリ ● TAIKO ● ThoughtWorks社がメンテナンスしているブラウザ経由のテストを行うためのNode.jsライブラリ ● コマンドでSUTを操作した記録を元にコードを生成する ● gaugeとの組み合わせを意識している ● cypress ● cypressを使っていなくてもBest Practicesのページは参考になるその他...

Slide 78

Slide 78 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. PlaywrightとTAIKOを試した 78 Playwright ● シンプルかつ抽象度の高いAPIで使いやすい ● Inspectorで生成されたコードを使って清書するようなテスト作成体験 ○ UIテストは変更に弱いが、壊れても再度変更後のGUI操作で復旧できる期待 ● 公式ドキュメント内の情報量・サンプルコードも多い、Frontend界隈での注目度も高い TAIKO ● より Easy よりなAPIでHTMLの詳細への依存度が低いテストコードを作りやすい ○ 相対的な位置関係からよしなにHTML要素を見つける ex. write(textBox("ﬁrst name", toLeftOf("last name")) ● gauge同様ThoughtWorks社がメンテナンスしていることもあり、「受け入れテストツール」での利用をより意識されている（所感） ● 相対的にマイナーではあるため、情報量は少ない 2つのSUTに対して playwright と taiko を使っているが、playwrightのほうが優勢（所感）

Slide 79

Slide 79 text

79 TAIKOによるCUI上での試行錯誤支援補足 TAIKO ではCUI上でブラウザ操作する機能が搭載されている > openBrowser() // ブラウザを開く > goto('https://fortee.jp/') // URLアクセス > click('PHPerKaigi 2021') // クリック > click('ログイン') 逐次的にAPIを試してテスト自動化コードを作成する

Slide 80

Slide 80 text

80 Playwright Inspector の体験補足 Playwright InspectorでUI操作操作した過程がコードとしてレコーディングされる生成されたコードを組み合わせてステップ実装を行う

Slide 81

Slide 81 text

81 テストデータを作るタイミング2選 1 テスト環境に手動でデータを用意しておく毎Scenarioごとにデータを作成・調整 ● テスト自動化コードを書く前にひと手間発生 ● テストシナリオとデータの関係性が暗黙的になりわかりづらくなる ○ ex. ID=1のショップを使う（なぜ？ ● 環境差異の影響を受けにくい ● E2Eにおいて自動でデータを用意しにくいことも多い ○ ex. 本人確認書類での本人確認を終えたショップを用意しよう ● テスト速度が低下する ○ ex. 毎回ネットショップを開設すると？ 2 再掲

Slide 82

Slide 82 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「1. テスト環境に手動でデータを用意しておく」 ● E2Eにおいて自動でデータを用意しにくいことがほとんど例: 電話番号認証・本人確認書類提出・銀行口座を指定して振込申請 ● 検証環境で手動テストと自動テストが両方行われる分、自動テスト専用アカウントを作ることで相互に影響を与えるのを回避する 82

Slide 83

Slide 83 text

Slide 84

Slide 84 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 84 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 5. 考察とその後

Slide 85

Slide 85 text

85 作成された自動テストのその後 ATDDの取り組み実施時に作成したE2Eテストは継続的に実行され、リグレッションテストとして活躍し続けている障害発生を防いだ例

Slide 86

Slide 86 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDを継続しようとしたができなかった 86 型ができて後続の機能開発でも実施しようとしたが、着手に至らなかった。特に意識しようとした点 ● ユーザーストーリーの受入条件の策定にQA Engineerが参加する ● テスト自動化出来るものは並走してテスト自動化コードを書く → 継続するには２つの前提条件がある。

Slide 87

Slide 87 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ２ ATDD継続の２つの前提条件 *1 １仕様・受入条件策定者がテスト自動化に至るまでの一連の取り組みに時間をさけること（あるいはエンジニアがテスト実装に時間をさけること）専任の”QAエンジニア”がプロダクト開発の前線に居続ける ※1 TDDからの拡張の歴史的経緯やBDDというカウンターカルチャー的側面などを中心に捉えるとこの条件は「間違ってる！」と思うかもしれません。より正確には、当スライドで解説しているAgile Testingの文脈で語られるところの「Example-driven developmentを継続して実践するには」という表現でしょうか。

Slide 88

Slide 88 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 兼任でプロダクト開発の前線に居続けられるか？ 88 エンジニア採用個人評価ユーザーストーリの受入条件を作成する全体テスト計画性能テスト設計・実施結合テスト設計・実施連携テスト設計・実施システムテスト設計・実施 ...etc 開発チームメンバーの増加プロジェクト全般の優先的なQA活動 Engineering Manager QA engineer イテレーションごとに自動テストを積み上げる Managementの割合がより強くなるほどEMとの兼任者は難しいイテレーションに常にいる”QAエンジニア”にはなれなくなる

Slide 89

Slide 89 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化にハマっても時間をさく余裕？ 89 E2Eテスト自体はユニットテストと比較すると事前条件が多く作りにくい。さらにハマったときに原因判別も時間がかかる。テストコードが悪いのかテストデータが悪いのか仕様が間違ってるのかテストツールのバグなのかテストがなぜか通らない... 5月21日からDraftのテスト

Slide 90

Slide 90 text

90 方向転換「E2Eテストがほしいね」という話があり、当初これを整備しようとしたが辞めた自分がやらない決断も大事適切にニーズを見極めよ開発者自身が作ったほうがいい「E2Eテスト」もある ex. GoエンジニアがGoで書きやすいテスト基盤

Slide 91

Slide 91 text

Slide 92

Slide 92 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 一般的なE2E（エンド・ツー・エンド）テストの定義 92 ● アプリケーションワークフローを最初から最後までテストする ● 実際のユーザーシナリオを再現することで、システムの統合性やデータの整合性を検証することを目的とする ● アプリケーションがハードウェア、ネットワーク接続、外部依存、データベース、および他のアプリケーションとどのように通信するかをテストする ”End To End Testing: A Detailed Guide” by BrowserStack https://www.browserstack.com/guide/end-to-end-testing

Slide 93

Slide 93 text

93 Frontend Backend service B service A Database Database Database external service external service Frontend engineer Yさん Service A engineer Zさん Test engineer Xさん ※ ウェブアプリケーションの場合人によって異なる E2Eスコープ例： Test engineer Xさん: エンドユーザーと同じインターフェースから機能仕様を満たすかについての関心がつよい Frontend engineer Yさん: 開発業務対象のFrontendシステムに対するテスト、ゆえにブラウザ操作自動化 = E2E になりがち Service A engineer Zさん: 開発業務対象がAPIサービス、”Service A”の範囲がE2E のスコープ

Slide 94

Slide 94 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「E2E」をブレークダウン、自分たちの語彙を作る自動テストの種類について辞書を作る E2Eらしきテストは次の3種類に言葉を定義 ● System Test: 今回の発表内で紹介しているテスト ● Simulation Test: 一連のイベントが時系列的に発生した際のシミュレーションを統合的に行う（by budougumi0617 さん） ● Visual Regression Test: frontend開発の中でローカル環境で作成・実行するテスト（by sam8helloworld さん）どのスコープでEnd2Endなのかが語彙によって明らかになる

Slide 95

Slide 95 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. gauge X playwright / taiko / python のその後 PdM/事業部長 (Product Owner) Biz/CS EM / QA Designer ... Data scientist Enginners SRE ... Process engineering (QA) ... ... ... ... Service Dev team xxx yyy zzz ● 作成したテストは継続して実行し続けている ● 新規に作成する”システムテスト”は BASEのProcess engineeringチームによって選定されたテスト自動化 SaaSを利用している ● 徐々に移行していってるが、gaugeと共にテスト自動化に取り組んできた積み重ねが資産になってる

Slide 96

Slide 96 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDへの挑戦から始まる1年間の試行錯誤 96 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 0. 前史 1. 構想 2. 自動テスト基盤の構築 3. ATDDの実践 4. 大規模プロジェクトでのしくじり 5. 考察とその後

Slide 97

Slide 97 text

テスト自動化に託そうとしたもの https://www.shutterstock.com/image-photo/woman-ha nds-holding-sun-dawn-freedom-1561794796

Slide 98

Slide 98 text

Slide 99

Slide 99 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 2. テスト自動化を切り口に始める開発全体の改善 Product Owner Frontend engineer Backend engineer ... 共通の理解が形成され、フィーチャに対する誤解がなくなる Product Owner Frontend engineer Backend engineer

Slide 100

Slide 100 text

10 プロダクト開発の当初の課題と現況（１）再掲 ● ユーザーストーリーの受入条件が曖昧になりがち。「何をもって完成したのかを判断する基準」が明確になっていない故、共通見解が取れてなかったこともあったチーム人数の増加もともない潜在的な課題は顕在化いくつかの施策で対応 ● Agile Testingの3 amigosを参考にデザイナー・Frontendエンジニアでの密なコミュニケーションの実施（by sam8helloworld さん） ● 結合/システムテストシナリオレビューによる仕様の認識整理 ● リリースした機能に対する「システムテスト」を作成、自動リグレッションテスト

Slide 101

Slide 101 text

10 プロダクト開発の当初の課題と現況（２）再掲 ● これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合は手動で同じシナリオを毎回テストしているデプロイされた環境に対する自動テスト実行によって改善された例：dependabotでの依存ライブラリアップデート対応

Slide 102

Slide 102 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ご清聴ありがとうございました 102 2021 2021.11.18 2021.04 2021.09 2021.07 2021.10 0. 前史 5. 考察とその後 2. 自動テスト基盤の構築 3. ATDDの実践 4. ATDD展開失敗と方向転換 1. 構想 ATDDへの挑戦から始まる1年間の試行錯誤、誤マシマシ... :(