実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example

by Kazuki Higashiguchi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. @hgsgtk Kazuki Higashiguchi 東京に住まう Software Developer / BASE BANK, Inc. Manager, Tech Lead 自己紹介 4 (2020.12) Dockerアプリケーション開発実践ガイド > コンテナアプリケーションの設計セオリー (2019.12) PHPにおけるユニットテストとCI/CD > ユニットテストの育て方 PHPerKaigi Archives 2020: 自作して理解するxUnit 2019:「質」のいいユニットテストを書くためのプラクティス 2018: レビューをもらいやすい細かいプルリクの切り分け方今回の発表は July Tech Festa 2021 Winter (2021.01.24)で行った、「TDDからATDDへ歩みをすすめる」（20分）の発展版で、かなり内容を拡充しています。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームの概観・現状 ● 不確実性をコントロールするためアジャイルな開発文化・プロセスを実践している ● 短いイテレーション(※1) を回し、ユーザーストーリー(※2) ベースの開発計画を行っている ● ユニットテストを書き、その他静的解析やフォーマットも含めて、CIでの自動実行を行う。CircleCI等を用いてCI/CD Pipelineを組みデプロイ自動化を行っている ※1 イテレーションとは、一連の工程を短期間で繰り返す、開発サイクルのことを指します。設計・開発・テスト・改善のフィードバックサイクルを短期間で繰り返し回すことで、問題の発見・改善につながることが一つの目的とされます。 ※2 ユーザーストーリーとは、ユーザー・顧客視点での使い手にとっての価値を記述したもの（ex. 「注文画面」という機能ではなく、「欲しい商品が注文できること」）

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 課題に対して考えた2本の柱 ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』 (2019年)の定義に準拠『Agile Testing Condensed: A Brief Introduction』 https://www.amazon.co.jp/dp/B002TIOYWQ 四象限における Q2 を強化する１ 2 テストピラミッドを登る ATDD TDD 『初めての自動テスト――Webシステムのための自動テスト基礎』 https://www.oreilly.co.jp/books/9784873118161/ The Way of the Web Tester by Jonathan Rasmusson / Chapter 8 Climbing the Pyramid https://www.oreilly.com/library/view/the-way-of/9781680502251/f_ 0065.xhtml

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの四象限 11 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 12

Slide 12 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの四象限テスト活動を2つの軸で分類した 1. 技術面 or ビジネス面 a. プログラマの領域の言葉で説明される b. ビジネスの専門家が興味を持つような言葉で説明される 2. 開発チーム支援 or 製品批評 a. 開発チームを支援するテストは、コーディング前・進行中に作成され、欠陥の防止に役立つ b. 製品を批評するテストは、コーディング完了後に行われ、欠陥の発見・欠落したフィーチャの特定に役立つ 12

Slide 13

Slide 13 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 各象限におけるテスト Q1: 技術面 && チーム支援 - コードレベルのテスト - 自動化 Q2: ビジネス面 && チーム支援 - 顧客視点の高レベルのテスト - 自動化・手動を組み合わせる Q3: ビジネス面 && 製品批評 - ユーザー受け入れテストや探索的テスト...etc - 手動で行われるものが多い Q4: 技術面 && 製品批評 - パフォーマンステスト・セキュリティテスト....etc - ツールによる実施 13 ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019年)の定義に準拠

Slide 14

Slide 14 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. TDDからATDDへ歩みをすすめることでQ2を強化 14 TDDの領域 - Unit tests - (Component tests) ATDDの領域 - Story acceptance tests - Examples ● TDD ○ Q1 ○ 技術面のUnit Tests等で駆動する ● ATDD ○ Q2 ○ ビジネス面の「受け入れテスト」で駆動する TDDからATDDへ歩みをすすめることで、ビジネス視点の機能に対するテストの取り組みが強化される

Slide 15

Slide 15 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ユーザーストーリーのスキルレベルを高める ● Agile Allianceではユーザーストーリーのスキルレベルに3段階あることを示している ○ https://www.agilealliance.org/glossary/user-stories ● ATDDのプラクティスはスキルレベル Beginner から Intermediate への挑戦課題 15 [Beginner] ● ユーザーストーリーを表現するための標準的なフォーマットを1つ以上知っている ● ユーザーストーリーを例示して説明できる ● ...etc [Intermediate] ● 機能を目標をユーザーストーリーに分割・ギャップを残さないように ● ユーザーストーリーを表現するための標準的なフォーマットを複数知り、最適な選択ができる ● ユーザーストーリーの受入基準を、自動化された受入テストとして直接使える言葉で表現できる ● ...etc [Advanced] ● 非機能要件をユーザーストーリーの観点から解釈できる ● プロジェクト目標のより高いレベルの説明にリンクさせ、ユーザーストーリーのビジネス価値の根拠を提供できる

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テストピラミッド Mike Cohn氏が提唱した概念 (『Succeeding with Agile: Software Development Using Scrum』2009年）『martinfowler.com: The Practical Test Pyramid』では、テストピラミッドから学ぶべき点は次の2つだと言っている 1. 異なる粒度のテストを書く 2. 高レベルになるほど、持つべきテストは少なくなる 17 『Succeeding with Agile: Software Development Using Scrum』 https://www.amazon.co.jp/dp/B002TIOYWQ martinfowler.com: The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html ※ ”UI Tests”などのテストレイヤーは現在のテスト状況に対してシンプルすぎるため、それらに固執する必要はなく、自分たちのプロダクト・開発チームに沿ったレイヤー名で良いと指摘している

Slide 18

Slide 18 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 2. テストピラミッドを登るほとんどの開発チームはユニットテストから始めるそして「アイスクリームコーン」にならないように、必要に応じて上の階層に登っていく（『初めての自動化テスト』著者 Jonathan Rasmusson ） 18 アイスクリームコーン実行時間がかかり壊れやすい高レベルテストのほうが多くなってしまうアンチパターン ※ すべてのアイスクリームコーンが悪いわけではない（ex. そもそもテストが存在しないレガシーシステムでUIテストから始める） Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst / Stephen H Fishman https://medium.com/@ﬁstsOfReason/testing-is-good-pyramids-are-ba d-ice-cream-cones-are-the-worst-ad94b9b2f05f https://www.oreilly.com/library/view/the-way-of/9781680502 251/f_0065.xhtml

Slide 19

Slide 19 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDDを通じてテストピラミッドを登る 19 ● ATDD活動での自動テストはより高レベルなテストが求められる傾向にある (※1) ○ （ex. API経由・UI経由...etc） ● 弊チームにおいても、ビジネス的関心のテストを表現する自動テストの多くは、UIやAPI経由でのE2E Testである ● 結果、ATDDで書かれる自動受入テストを通じて、テストピラミッドを登っていける ※1 実際にATDDの自動テスト実装においてどのレベルのテストが求められるかは、テスト対象システムの要件・テスト自動化の費用対効果等によって変わります。

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. そもそもTDD(Test-Driven Development)とは ● 「動作するきれいなコード」をゴールとした、プログラミング中の不安をコントロールする方法 22 2つのシンプルなルール 1. 自動化されたテストが失敗したときのみ、新しいコードを書く。 2. 重複を除去する Red-Green-RefactorのTDD Cycleを回す 1. まずはテストを1つ書く 2. すべてのテストを走らせ、新しいテストの失敗を確認する 3. 小さな変更を行う 4. すべてのテストを走らせ、すべて成功することを確認する 5. リファクタリングを行って重複を除去する https://levelup.gitconnected.com/how-to-write-a-test-using-tdd-b282 8788d7ea

Slide 23

Slide 23 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDDとは ATDD: Acceptance test–driven development（受け入れテスト駆動開発）特徴 1. コラボレーションを重視したソフトウェア開発プロセス 2. ユーザーストーリーの受け入れテストである「ストーリー受け入れテスト」に着目する 3. 「入れ子のフィードバックループ」を回す 4. 例によって駆動する「Example-driven development」のひとつのバリエーション(※1) 5. 厳密な言語やルールのない例を使用して開発を導く、より一般的な形式 23 『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 24

Slide 24 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 2. 「ストーリー受け入れテスト」とは 24 ● 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 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 4. 例が駆動する「Example-driven development」 27 “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 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 今回の実例で取り上げるSUT ● 今回の実例で取り上げるテスト対象システム（SUT）はサービスの管理業務を担う ○ ブラウザベースでアクセスするサービスであり、背後に内部APIやDB等が控える ● すでに本番稼働しているシステムに対して、新機能を実現するための開発でATDDを実践 ● PHP 7・CakePHP で構築されており、PHPUnitを用いたユニットテストを書いている ● 2週間を1イテレーションとして漸進的に機能を実現していく仕事の流れ 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ユーザーストーリーを洗い出す 34 ● 新機能リリースのために実現するユーザーストーリーを、業務フローや画面モック・ユースケース等をインプットに、洗い出していく ● ユーザーストーリーは、ソフトウェアを使う側の視点で記述される使い手にとっての価値を指す ○ よくある記述Template: ■ ＜ユーザー＞が、＜機能・性能＞にする。なぜなら＜ビジネス価値＞のためだ。 ● ex. 「ショップオーナーが、入出金履歴で売上を見れるようにする。なぜなら売上を確認するためだ。」 ● ユーザーストーリーを実現するために、バーティカルスライスでのデリバリーが必要になる

Slide 35

Slide 35 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. バーティカルスライスのデリバリー “短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチームが養わなければならない。こうした活動をサポートするために用いられる設計アプローチはバーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデリバリーするために各アーキテクチャ層で変更を行う、というものである。” 35 『More Eﬀective Agile “ソフトウェアリーダー”になるための28の道標』 9.4 基本原則：バーティカルスライスでのデリバリー https://www.amazon.co.jp/dp/B089KFKB5H https://commons.wikimedia.org/wiki/File:The_Layers_of_Verti cal_Slicing.png#/media/File:The_Layers_of_Vertical_Slicing.png

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 例を特定し受入条件に反映する 37 それぞれのユーザーストーリの具体的な例を特定していく中で、ストーリーの完成イメージを具体化し、受入条件として表現する ● 例：とあるプロポーザル管理システムのユーザーストーリーと具体例(※1) ※1 実際の業務要件をそのままお見せできないので、当資料作成中ちょうど目の前にあった https://fortee.jp/ を題材とさせていただいておりますが、整理した具体例はなるべく実際に業務で行ったものに近づけています。

Slide 38

Slide 38 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームでの例特定とコミュニケーション 38 ● GitHubのIssueでユーザーストーリーを作成している弊チームでは、Issueの説明内に見つかった例を受入条件として書き加えている ● たたき台として「受入条件」となりそうな具体例を載せておいて、イテレーション計画時にProduct Manager・Developer間で実際に会話し、ユーザーストーリーの具体例の確認・認識共有を行っている ● 社内管理機能の場合、実際に使用するユーザーが社内にいるため、具体例を用いて業務バリエーションの確認を行うのが要件整理において効果的だった ex. 「採択承諾のリマインドを送る機能って具体的にはこういうことになりますかね〜？」といった会話を行う (※1) ※1 実際の業務の会話はそのまま出せないので、属性の近いような別システムの要件を例に取っています。

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動受け入れテストのためのツール 42 有名な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/ 弊チームで使用しているTool ● Markdownベースのシンプルな仕様記述Syntax ● ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポートしている ● メンテナンスが活発（Issueをあげたら数分後に返事が来た） ● Visual Studio Codeの拡張が便利 ○ （新規PJ作成・テスト実行・コード補完・定義ジャンプ・フォーマット...etc） Uncle Bob氏により作成された Wikiで記述する本体のメンテは続いているがPlugin のメンテが一部止まっている http://ﬁtnesse.org/FrontPage

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. gaugeのSpeciﬁcationファイル 45 example.spec *.spec で定義したステップを選択したプログラミング言語で実装する API Client実装 webdriver selenium Pythonの場合は @step() でマッピング JavaScriptの場合は step() でマッピング

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. UI操作を taiko を用いて自動化する 48 ● ブラウザ操作を用いる場合 Selenium, Puppeteer, playwright など様々なライブラリがあるが、技術的実装はどれを用いても構わない ● 弊チームでは taiko (https://taiko.dev/) を利用している [taiko] ● ThoughtWorks社がメンテナンスしているブラウザ経由のテストを行うための Node.jsライブラリ ○ 抽象化されたGUI操作のAPIを提供しているため、HTMLの詳細に依存しすぎないテスト実装が可能 ■ ex. openBrowser(), goto("example.com"), click("agree"), write("test") ○ コマンドでSUTを操作した記録を元にコードを生成することも可能で、手元での試行錯誤もしやすい

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. UIテストの「テストファースト」 50 ● 自然言語で書く Specification は受入条件をそのまま表すもの ● テストファーストに受け入れテストを定義することで、「これから完成させるもの」についての共通認識へ ● 一方で実際のUI操作をする技術的実装であるステップ実装は、作ってみないとわからない要素もある ○ そのままステップ実装まで作りきれるほど明確なのであれば作ってもいい ○ UI実装が未確定であれば例外等でテストが落ちるようにして、実際にSUTを開発しながらステップ実装を並行して行う

Slide 51

Slide 51 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 51 ● 要件を明確に定義し、かつ自動化された受け入れテストにかんたんに変換できる言語として、Eric Evansのユビキタス言語の形成を取り入れる [ユビキタス言語とは] ● ドメインエキスパートも開発者たちもプロジェクトチーム全体で、同じ用語を使い、ひとつの言語を共有する（『実践ドメイン駆動設計』1.3 DDDを行う方法） ● ユビキタス言語を使って受け入れテストを記述する ● テストを書いている際に “未定義な語彙” が出てくる。それらはドメインモデリングへフィードバックする ○ 弊チームでは、ユビキタス言語の形成が必要な概念が出てきたら、GitHub Issueに「ドメインモデリング」 Issueを作成して、後ほどチームで話す機会がある際に取り上げる方式をとっている受け入れテストにはユビキタス言語を使う

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動化しにくいテストをどう扱うか 53 ● ATDDがフォーカスするQ2領域はもともと手動・自動テストの両方が混在しやすいエリア ● 受入条件の中には自動化しにくいシナリオや機能は存在する ○ ex. メール送信をしてそのメール文面をチェックする ● テスト効率を考えても手動でテストしたほうがよい場合もある。すべてを必ず自動化しないといけないわけではない

Slide 54

Slide 54 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 手動テストも Specification には記載する 54 ● 手動テストを Specification に書かない場合 ○ ユーザーストーリーの例と受入条件は忘却されていく ○ 手動テストか自動テストかによって仕事の流れに分岐が生まれリズムも作りにくい ● 弊チームでは、手動テストも自動受け入れテストと同じ Specification ファイルに記述している(※1) ○ “manual” Tagsをつけて「手動テスト」を明示する ○ 受入条件を積み重ねるドキュメントを集約するメリット ○ 受け入れ条件はとりあえずATDDツールに起こしていくというシンプルな仕事の流れになる自動化可能かどうかで仕事の流れに分岐が生まれる ※1 このアイデアは2021年2月10日「TDDとATDD 2021」というオンラインイベント実施後のkyon_mmさんとの雑談の中で教えていただきました。 https://www.youtube.com/watch?v=QzawrfOqQW4 “manual” tagで手動テストと明示

Slide 55

Slide 55 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動化可能だがUIテストではコスパが悪い場合 55 ● 自動化可能だがUIテストで表現するのには費用対効果が悪い受入条件も存在する ○ ex. 現在日時と採択承諾締め切り日を比較してリマインドするべきかのビジネスロジック “Don’t check business logic through the user interface” - 実行可能な仕様（受け入れテスト）のための自動化ツールの殆どは、UIだけでなくアプリケーションプログラミングインターフェースと直接やりとりできる - UIテストの自動化は、サービス・APIレベルの自動化と比較して、時間がかかりメンテナンスコストも高くつく - 可能な限りビジネスロジックを検証する際はUIの下を通ることが優れたソリューションであることが多い『Speciﬁcation by Example』 Chapter 9. Automating validation without changing speciﬁcations より私訳 ● ビジネスロジックをすべてUIテストで実現していくと「アイスクリームコーン」アンチパターンになってしまう

Slide 56

Slide 56 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. PHPUnitを活用している現場における適応課題 56 ● ATDDのツールではユニットレベルもサポート可能ではある ○ たとえばBehatを用いれば同じPHP言語なので直接コードを呼ぶことも可能 ○ 「ビジネス視点でのテスト」というのが本意にあるためテストレベルに制約はない ● しかし、すでにPHPUnitでユニットテストは抑えておりそこを切り替えたい課題もない ○ TDD Cycleでは引き続きPHPUnitを使っている ○ 開発者の迷いを産まない点でも同一テストレベルで複数ツールを使い分けるのは微妙 ● テスト自動化コードの実装言語にJavaScriptを選択しているので直接PHPプログラムを呼べない（この点を重要視したツール選定ではなかったため）

Slide 57

Slide 57 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. TDDサイクルから拡張していく導入事例『Specification by Example』にて紹介されている「songkick社」の導入事例 TDDプロセスを拡張してビジネス機能をカバーするアプローチ - 要件の伝達とリグレッションを避けるための良い方法を探していた - 「Unit Test」によるTDDからSpecification by Example（ATDDと同じExample-driven developmentのバリエーションの一種）へユーザーストーリーで作業、ビジネスゴールからユーザーストーリーを導き出す - Cucumberによって「実行可能な仕様（Executable Specification）」を作成する - 最初、RailsのテストフレームワークとCucumberをミックスして使い、徐々にCucumberを多くのシーンで使うようになる 57 『Specification by Example』 Chapter 17. Songkick https://livebook.manning.com/book/specification-by-example/chapter-17/45

Slide 58

Slide 58 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. PHPUnitとの併用に関する弊チームの試験的試み 58 1. バリエーションのある受入条件の中で最もハッピーパス（正常系）をUIテストで実装 ○ ex. 複数バリエーションの中で1ケースだけUIを経由してテスト実装 2. ”unit” Tagで分類しPHPUnitで自動化する受け入れテストであることを明示 “unit” tagで PHPUnitで実装されるテストと明示 [Merit] 1. 開発者がTDD Cycleを回す前のビジネス視点での関心のInputとなる 2. ユーザーストーリーの受入条件がドキュメントとして集約できる [Demerit] 1. つねに実行される「生きているドキュメント」ではなく、変更への追従が遅れる可能性がある実装するまでは落ちるようにテストを書いたら通るように修正

Slide 59

Slide 59 text

Slide 60

Slide 60 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 手元ではローカル開発環境・CIでは検証環境へ 60 ● 手元の実行ではDockerローカル開発環境へ向けて実行する ○ 適宜動作確認したいタイミングで実行する ● CIではデプロイされた「検証環境」に対して実行する ○ 受け入れテストコードの更新時に実行 ○ cronで日次の定期実行当テスト専用の環境・DBを用意するのがテストデータ準備の都合や失敗原因を局所化するために理想ではあるが、テスト対象システムの規模や事情の中でバランスを取った結果、この実行方法となった。

Slide 61

Slide 61 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 受け入れテストを「仕掛中」と「完成」で区別する ATDDにおける「ストーリー受け入れテスト」はフェーズによって２つに区分される 1. 「仕掛中」 - 「まず最初に失敗する受け入れテストを書く」 - 進捗を測るテストであり失敗することがわかっている、CIフローには含めない 2. 「完成」 - リグレッションを検出するテスト - 完成したストーリーのテストは常に成功することが期待するためCIフローに含める 61 図: 『実践テスト駆動開発』（GOOS）を参考に作成した、内側と外側のフィードバックループ図「仕掛中のテストシナリオ」は実行スキップされている

Slide 62

Slide 62 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 「仕掛中」と「完成」を区別する 62 ● gaugeにはTagsというテストをフィルタリングする機能がある ○ （他のツールでも類似したものがあります） ● “draft” Tagsを活用して「仕掛中」を明示する ● CIフローでのテストスイート実行時は、 --tags=”!draft”オプションを設定し、draft以外を実行する「仕掛中のテストシナリオ」は実行スキップされている

Slide 63

Slide 63 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 積極的なエラーレポーティングの意識 ● 特にEnd2Endのテストレイヤになると失敗時の原因究明は難しい ○ その時のネットワーク状況に応じて失敗することもある ○ Flaky（同じコードで成功したり失敗したりする）になりがち 63 ● 饒舌なエラーメッセージ ○ 単に値の検証をするだけではなく、「なぜこのアサーションをしているのか」をエラーメッセージに込める ● 状況のスナップショット ○ UIテストの場合は、アサーション対象のUI要素をわかりやすくスクリーンショット ○ APIの場合は返答されたレスポンスをテストレポートに記録する

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 「継続的に実施される」とはどういうことか 68 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ DevOpsにおけるあらゆるフェーズにおいてTestingは存在している「Continuous Testing（継続的テスト）」という考え方継続的かつ全体的なテストアプローチを重要とするあらゆるフェーズにおいてテストが継続的に実施され続ける

Slide 69

Slide 69 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 「品質に対するチーム全体の責任」とは 69 http://www.growingagile.co.za/2015/04/the-testing-manifesto/ by Karen Greaves and Samantha Laing 成功するアジャイルテストアプローチに必要なマインドセット ● 開発プロセス全体をテスト ● バグの防止 ● 理解している価値をテスト ● 最高のシステムを構築 ● 品質に対するチーム全体の責任

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDD in アジャイルテスト 71 71 「具体的な例」によって開発をガイドする第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 72

Slide 72 text

Slide 73

Slide 73 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームでの歩み出したプロダクト開発課題の先 ● ユーザーストーリーの受入条件が曖昧になりがちで、「何をもって完成したのかを判断する基準」が明確になっていない故、共通見解が取れてなかったこともあった →具体例によるユーザーストーリーの理解 →受け入れテストを作ることを意識することによる受入条件の明確化 ● これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合は手動で同じシナリオを毎回テストしている →受け入れテスト作成を通じた自動E2Eテストの整備につながった

Slide 74

Slide 74 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. まとめ ● ATDDはExample-driven developmentの一種であり、コラボレーションを重視したソフトウェア開発プロセス ● ユーザーストーリーの受入条件を明確にしユーザーストーリー活用レベルアップを図る ● gauge を用いたATDDプラクティスの活用事例・現場の試行錯誤をお伝えした ● TDDからATDDへ歩みを進めることで、ソフトウェアテストの活動領域を拡大していこう 74

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 受け入れテスト記述リポジトリを準備する既存のアプリケーションリポジトリとは別にgauge専用のレポジトリ（gauge-tests）を用意した 79 [Merit] ● 特定リポジトリに依存しない、アーキテクチャ変更に対応しやすい ● 実装コードを参照しにくいためSUTに対して疎結合になる ● 複数あるAPIのCI/CDデプロイパイプラインに受け入れテストの実行を組み込み [Demerit] ● 別レポになると開発者の実装リズムの中で頻繁に書きづらい ○ ex. 1minごとにCycleを回す ATDDはTDDよりも大きなフィードバックループを回すプラクティスその前提に立つと、別レポのDemeritは許容できると判断した $ tree -L 1 gauge-tests ├── README.md ├── serviceA └── serviceB ...

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 設定情報・秘匿情報の扱い [環境ごとに可変な設定] ● ローカル・CIや複数環境への対応で環境ごとの設定が必要になる ● gaugeでは起動時に環境変数に設定する properties ファイルを活用した [秘匿情報] ● 受け入れテストをエンドツーエンドで用意しようとすると、テスト環境のAPI Keyやパスワードといった情報が含まれる ● CircleCIのcontextに保管し、ジョブから参照 ○ context: 環境変数を保護し、プロジェクト間で共有するためのメカニズム 82 env ├── ci │ └── ci.properties └── default ├── ...etc ├── local.properties ├── local.properties.sample └── default.properties

Slide 83

Slide 83 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. SUTのCI/CD Pipelineに組み込む 83 検証用環境にデプロイ後、自動受け入れテストを実行する ● SUTのCI/CD Pipeline内でgauge-testsをgit cloneして、デプロイ直後の検証環境に対して実行する ● contextによって実行に必要な設定情報が共有されているため、gauge-testsリポジトリで回しているJobの実行内容をほぼそのまま持っていける

Slide 84

Slide 84 text

Slide 85

Slide 85 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 余談: Example-guided developmentへのRename案 85 テスト駆動開発（TDD）、振る舞い駆動開発（BDD）、受け入れテスト駆動開発（ATDD）、実例による仕様（SBE）等の総称として “Example-guided development”へrenameしてはどうかという提案が、Daniel Terhorst-North氏（BDD発案者）からされた。（2018年） “もし私がタイムカプセルを持っていたら、過去に戻って”Example-Guided Design”と呼ぶでしょう。TDDは、強力な設計技術にしてはひどい名前です。BDDはそれよりもひどい名前です。どちらもコードと機能の両方のレベルで、同じプロセスを説明しています。”（私訳）議論のまとめは@cucumberbddの共同創設者 Matt Wynne 氏のブログエントリをぜひ見てみてください。 “Example-guided development: A useful abstraction for the xDD family?”(https://cucumber.io/blog/bdd/example-guided-development/) →その後のスレッドで”Example-guided Development”のほうがしっくり来るという話をしていた提案に対する指摘抜粋 1. renameによる混乱（Martin Fowler氏） 2. ファズテストなど判断的に選択された例を使用するテストは “Example-guided” なのか（Nat Pryce氏: GOOS共著者）

Slide 86

Slide 86 text

Slide 87

Slide 87 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDDに近い名前たち 87 類似する様々な名前たちがある。 ● 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 88

Slide 88 text

Slide 89

Slide 89 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. SBE as Example-driven development 89 SBEもExample-driven developmentのバリエーションであり、フィーチャ・ストーリー開発を導くために例を用いるアイデアである。その他特徴をあげる。 https://docs.google.com/drawings/d/1cbfKq-KazcbMVCnRﬁh6zMSDBdtf90KviV7l2oxGyW M/edit?hl=en ● Declan Whelan氏・Gojko Adzic氏らによる共通理解整理 (2010) ● 「インパクトマッピング」等を用いてストーリー回りのゴールを特定する ● 「仕様ワークショップ」にて仕様となる主要な例を導き出す

Slide 90

Slide 90 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. BDD as Example-driven development 90 BDDもExample-driven developmentのバリエーションと捉えられる。 ※1 “Introducing BDD” (2006) (https://dannorth.net/introducing-bdd/) ※2 GOOSとは『Growing Object-Oriented Software, Guided by Tests』の略です。『実践テスト駆動開発』の原著です。図: 『実践テスト駆動開発』（GOOS）を参考に作成した、内側と外側のフィードバックループ図 ● 自然な「ドメイン固有言語」で実例のシナリオを捉える ● 「Given / When / Then」構文 ● Dan North氏が発案者とされる (※1) ● 当初は従来のTDD（Q1）を守備範囲とした（GOOS(※2) でいう内側のループ） ● 語彙を整理し、ATDDを拡張したBDDの外側のループ https://twitter.com/t_wada/status/1370532742128050176 @t_wadaさんとのTwitter thread

Slide 91

Slide 91 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 歴史的経緯についての参考資料 91 更に詳細にこれらの歴史的経緯について知りたい方はこちらの資料をぜひご覧ください。 https://speakerdeck.com/twada/history-of-tdd-xpjug-2018-keynote 『テスト駆動開発の過去・現在・未来』 by @t-wadaさん（2018） https://www.amazo n.co.jp/dp/427421 7884 『テスト駆動開発』付録C 『自動テストの誤解とアンチパターン in 楽天 Tech Talk』（2014） by @kyon_mmさん https://www.slideshare.net/KyonMm/in-tech-talk

Slide 92

Slide 92 text

Slide 93

Slide 93 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ISTQBシラバスによるATDDの定義 “受け入れテスト駆動開発[Adzic09]は、ユーザストーリーの作成時に受け入れ基準とテストを定義する（1.2.2 項を参照）。受け入れテスト駆動開発はチーム間の協調を前提としたアプローチである。ソフトウェアコンポーネントがどのように振る舞うべきか、およびこの振る舞いを確実にするために、開発者、テスト担当者およびビジネス代表者は何をすべきかを、すべてのステークホルダが理解できるようにする。受け入れテスト駆動開発のプロセスは、3.3.2 項で説明する。受け入れテスト駆動開発では、回帰テスト用の再利用可能なテストを作成する。特定のツールが、継続的インテグレーションプロセス内で、そのようなテストを作成し実行することをサポートする。これらのツールは、アプリケーションのデータ層とサービス層に接続できるので、テストはシステムレベルまたは受け入れレベルで実行できる。受け入れテスト駆動開発では、フィーチャの振る舞いについて、欠陥を早期に解決し、妥当性を確認できる。また、フィーチャの受け入れ基準が満たされているかどうかを容易に確認できる。“ 93 ISTQB テスト技術者資格制度 Foundation Level Extension シラバスアジャイルテスト担当者 (2014.J01) http://jstqb.jp/dl/JSTQB-SyllabusFoundation-AgileExt_Version2014.J01.pdf ISTQB(International Software Testing Qualiﬁcations Board)による「受け入れテスト駆動開発の説明は以下の通りである

Slide 94

Slide 94 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ISTQBシラバスにおける「フィーチャ検証テスト」 94 イテレーション内で特定ストーリーに対して行われるテスト活動の中で、ATDDの中で自動化されるものは「フィーチャ検証テスト」であると言える。 ● ユニットテスト：一般的に開発者が実行する ● フィーチャ受け入れテスト：次の二つの活動に分割される場合がある ○ フィーチャ検証テスト：開発者またはテスト担当者が、ユーザストーリーの受け入れ基準に関する自動テストを実行する場合が多い ○ フィーチャ妥当性確認テスト：一般的に、開発者、テスト担当者、ビジネスステークホルダが協調して手動でテストする。フィーチャが利用に適しているかどうかを確認し、進捗の可視性を改善し、ビジネスステークホルダから実際のフィードバックを受け取る ISTQB テスト技術者資格制度 Foundation Level Extension シラバスアジャイルテスト担当者 (2014.J01) http://jstqb.jp/dl/JSTQB-SyllabusFoundation-AgileExt_Version2014.J01.pdf

Slide 95

Slide 95 text

Slide 96

Slide 96 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考書籍 96 https://www.manning.com/books/bd d-in-action-second-edition https://leanpub.com/agiletesting- condensed-japanese-edition https://www.amazon.co.jp/dp/47981 24583 https://www.oreilly.co.jp/books/9784 873118161/ https://www.amazon.co.jp/-/en/Jane t-Gregory-ebook/dp/B00O27V8DA https://www.manning.com/books/sp ecification-by-example https://www.amazon.co.jp/Agile -Testing-Practical-Addison-Wes ley-Signature/dp/0321534468 https://www.amazon.co.jp/dp/42742 17884 https://www.amazon.co.jp/ATDD-Ex ample-Test-Driven-Development-A ddison-Wesley/dp/0321784154 https://www.manning.com/books/te st-driven

Slide 97

Slide 97 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考書籍 97 https://www.amazon.co.jp/dp/B089 KFKB5H https://www.amazon.co.jp/dp/B002 TIOYWQ https://www.amazon.co.jp/dp/47981 30508 https://www.amazon.co.jp/-/en/Rob ert-C-Martin/dp/4048930745 https://www.amazon.co.jp/dp/B00G RKD6XU https://www.amazon.co.jp/dp/B00U X9VJGW https://www.amazon.co.jp/gp/produ ct/B004X1D36K?ref=dbs_p2d_P_R _kindle_available_T1

Slide 98

Slide 98 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考文献・資料 “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 Our ever-evolving, never set-in-stone deﬁnition of ‘agile testing’ https://agiletester.ca/ever-evolving-never-set-stone-deﬁnition-agile-testing/ martinfowler.com: The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html Agile Alliance: User Stories https://www.agilealliance.org/glossary/user-stories Marick Brian 2003. My Agile testing project http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1 98

Slide 99

Slide 99 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考文献・資料 The Testing Manifesto http://www.growingagile.co.za/2015/04/the-testing-manifesto/ Continuous Testing in DevOps… https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ Comparing Executable Speciﬁcation tools https://jp-lambert.me/comparing-executable-speciﬁcation-tools-b7081cc26315 アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- / Satoshi Masuda https://www.slideshare.net/satoshimasuda/ss-3241717 Open Source Test Automation Framework | Gauge https://gauge.org/ 99

Slide 100

Slide 100 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 参考文献・資料 Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst / Stephen H Fishman https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-bad-ice-cream-cones-are-the- worst-ad94b9b2f05f Google Testing Blog: Flaky Tests at Google and How We Mitigate Them https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html Introducing BDD” (2006) https://dannorth.net/introducing-bdd/ Specification by Example Diagram https://docs.google.com/drawings/d/1cbfKq-KazcbMVCnRfih6zMSDBdtf90KviV7l2oxGyWM/edit?hl =en The ABCs of Acceptance Test Design https://www.ranorex.com/blog/abcs-acceptance-test-design/ 100

Slide 101

Slide 101 text

© 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 関連公開資料振り返りで積み上げた開発プラクティス（2020年総まとめ） https://devblog.thebase.in/entry/bank-practices-2020 アジャイル開発におけるユーザーストーリー分割実践〜画面リニューアルの裏側〜 https://devblog.thebase.in/entry/2020/08/13/110000 少人数でのアジャイル開発への取り組み実例（一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート https://devblog.thebase.in/entry/2020/07/27/104144 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 https://devblog.thebase.in/entry/2020/07/08/162359 CircleCIとecspressoによるECSへのデプロイメントパイプライン by @fumikony https://devblog.thebase.in/entry/2019/04/10/110000 101