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

ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。
PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。

トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。

ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テストの整備につながり、直接的な顧客価値となる外部品質の明確化・維持・向上が期待できます。

このトークでは次の内容について話します。

- ATDDとはなにか、Example-driven Developmentの考え方
- 前提となる「Agile Testing」の考え方
- ATDDを実践する開発プロセス
- テスト自動実行基盤の構築プロセス・構築例
- ATDDを実現するツール選定とツールを用いた「受け入れテスト自動化」
- エンドツーエンドなテスト構築（APIサービスとブラウザベースサービス）
- TDDからATDDへ、自動化テストピラミッドを登っていく

内容は特定技術の実装からインフラ・CI基盤、開発文化・プロセス自体と多岐にわたりますが、ソフトウェアテストという側面で開発を駆動させるあり方として参考にしていただければ幸いです。

https://fortee.jp/phperkaigi-2021/proposal/74efffd2-0ac3-4591-beaf-541f48879d6e

Transcript

1. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. #AgileTesting #ATDD #TDD 実践ATDD 〜TDDから更に歩みを進めた ソフトウェア開発へ〜 1 2021.03.26 ~ 03.28 PHPerKaigi2021 @hgsgtk Kazuki Higashiguchi
2. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当発表で得られるもの １ ２ ３ ソフトウェアテスト活動全体における ATDDの位置づけを理解できる ATDDの考え方について理解できる ATDD を実践している現場の事例を通じて 明日から取り入れるイメージを得る 2
3. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 3 TDDからATDDへ歩みを進めるモチ ベーション １ 2 3 4 ATDDとは ケーススタディ PHPで作られた Web Service 全体像としてのアジャイルテスト 5 6 7 まとめ 付録 参考文献
4. © 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分） の発展版で、かなり内容を拡充しています。
5. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 5 TDDからATDDへ歩みを進めるモチ ベーション １ 2 3 4 ATDDとは ケーススタディ PHPで作られた Web Service 全体像としてのアジャイルテスト 5 6 7 まとめ 付録 参考文献
6. © 2012-2021 BASE, Inc. 6 1. TDDからATDDへ歩みをすすめる モチベーション
7. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームの概観・現状 • 不確実性をコントロールするためアジャイルな開発文化・プロセスを実践している • 短いイテレーション(※1) を回し、ユーザーストーリー(※2) ベースの開発計画を行ってい る • ユニットテストを書き、その他静的解析やフォーマットも含めて、CIでの自動実行 を行う。CircleCI等を用いてCI/CD Pipelineを組みデプロイ自動化を行っている ※1 イテレーションとは、一連の工程を短期間で繰り返す、開発サイクルのことを指します。設計・開発・テスト・改善のフィードバックサイクルを短期間で繰り返し 回すことで、問題の発見・改善につながることが一つの目的とされます。 ※2 ユーザーストーリーとは、ユーザー・顧客視点での使い手にとっての価値を記述したもの（ex. 「注文画面」という機能ではなく、「欲しい商品が注文できるこ と」）
8. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームでの歩み出し前のプロダクト開発課題 • ユーザーストーリーの受入条件が曖昧になりがち。「何をもって完成したのかを判 断する基準」が明確になっていない故、共通見解が取れてなかったこともあった • これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合 は手動で同じシナリオを毎回テストしている “ストーリーは成功と失敗の2値で判断できるようテスト可能でなければならない。テスト可能に するとは、ストーリーに（満足条件として）関連付けられる適切な受け入れ条件があるというこ とだ。これは5.4節で述べたユーザーストーリーにおける確認という観点である。” 『エッセンシャル スクラム』より https://www.amazo n.co.jp/dp/47981305 08
9. © 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
10. © 2012-2021 BASE, Inc. 10 - 1. TDDからATDDへ歩みをすすめる モチベーション - 四象限における Q2 を強化する
11. © 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
12. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの四象限 テスト活動を2つの軸で分類した 1. 技術面 or ビジネス面 a. プログラマの領域の言葉で説明される b. ビジネスの専門家が興味を持つような言葉で説 明される 2. 開発チーム支援 or 製品批評 a. 開発チームを支援するテストは、コーディング 前・進行中に作成され、欠陥の防止に役立つ b. 製品を批評するテストは、コーディング完了後 に行われ、欠陥の発見・欠落したフィーチャの 特定に役立つ 12
13. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 各象限におけるテスト Q1: 技術面 && チーム支援 - コードレベルのテスト - 自動化 Q2: ビジネス面 && チーム支援 - 顧客視点の高レベルのテスト - 自動化・手動を組み合わせる Q3: ビジネス面 && 製品批評 - ユーザー受け入れテストや探索的テスト...etc - 手動で行われるものが多い Q4: 技術面 && 製品批評 - パフォーマンステスト・セキュリティテスト....etc - ツールによる実施 13 ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019年)の定義に準拠
14. © 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へ歩みをすすめることで、ビジネス視点の機能に対するテストの 取り組みが強化される
15. © 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] • 非機能要件をユーザーストーリーの観点から解釈できる • プロジェクト目標のより高いレベルの説明にリンクさせ、ユーザーストーリーのビジネス価値の根拠を提供できる
16. © 2012-2021 BASE, Inc. 16 - 1. TDDからATDDへ歩みをすすめる モチベーション- テストピラミッドを登る
17. © 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”などのテストレイヤーは現在のテスト状況に対してシンプルすぎるた め、それらに固執する必要はなく、自分たちのプロダクト・開発チームに沿ったレ イヤー名で良いと指摘している
18. © 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/@fistsOfReason/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
19. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDDを通じてテストピラミッドを登る 19 • ATDD活動での自動テストはより高レベルなテスト が求められる傾向にある (※1) ◦ （ex. API経由・UI経由...etc） • 弊チームにおいても、ビジネス的関心のテストを表 現する自動テストの多くは、UIやAPI経由でのE2E Testである • 結果、ATDDで書かれる自動受入テストを通じて、 テストピラミッドを登っていける ※1 実際にATDDの自動テスト実装においてどのレベルのテストが求められるかは、テスト対象システムの要件・テスト自動化の費用 対効果等によって変わります。
20. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 20 TDDからATDDへ歩みを進めるモチ ベーション １ 2 3 4 ATDDとは ケーススタディ PHPで作られた Web Service 全体像としてのアジャイルテスト 5 6 7 まとめ 付録 参考文献
21. © 2012-2021 BASE, Inc. 21 2. ATDDとは
22. © 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
23. © 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)等が挙げられます。
24. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 2. 「ストーリー受け入れテスト」とは 24 • Acceptance Test（受け入れテスト）は、様々なイメージで分かれる ◦ ex. ユーザー受け入れテスト(UAT)・運用受け入れテスト...etc • ATDDにおけるAcceptance Testの定義 = ストーリー受け入れテスト ◦ 「各ストーリーが提供しなければならないビジネス意図を記述したテスト」 • 機能テストのみではなく、他の品質特性の要件（セキュリティやアクセシビリ ティ、パフォーマンスなど）もスコープに含む “We define 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）
25. © 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）を参考に作成した、 内側と外側のフィードバックループ図
26. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動テストから得られるフィードバック 26 『実践テスト駆動開発 (Object Oriented SELECTION)』 第一章 テスト 駆動開発のポイントとは？ https://www.amazon.co.jp/dp/4798124583 外部品質のフィードバック - エンドツーエンドのテストの実行によってシステムの 外部品質へのフィードバックを多く得られる - ストーリー受け入れテストを書くことでドメインにつ いてチームがどれほど理解できているかについての知 見が得られる 内部品質のフィードバック - ユニットテストを書くことで、コードの質についての フィードバックを数多く得ることができる 外部品質: システムが顧客やユーザーのニーズにどれだけ応えられているか （機能を備えているか、信頼できるか、利用できるか、素早く反応するか...etc） 内部品質: 開発者や管理者のニーズにどれだけ応えられているか （理解しやすいか、変更は容易か...etc）
27. © 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）を書いて自動化し開発を進め、自動化されたチェックに合格すると、探索的テスト等他テスト を行う準備ができたとみなす
28. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 5. 厳密な言語・ルールのない例で開発を導く 28 • ユーザーストーリーに対して、具体的な例をビジネス・開発者・テスター等ステークホルダーで会話し特定す る • 関係者が理解でき会話できることが期待できる、事業領域の用語で受入テストとして具体化する ◦ その際の言語・記述ルールに対する厳密な規定はしていない 図：Cucumberを用いた場合は Gherkin 記法によってシナリオ記述 図：gaugeを用いた場合は Markdown 記法によってシナリオ記述
29. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 29 TDDからATDDへ歩みを進めるモチ ベーション １ 2 3 4 ATDDとは ケーススタディ PHPで作られた Web Service 全体像としてのアジャイルテスト 5 6 7 まとめ 付録 参考文献
30. © 2012-2021 BASE, Inc. 30 3. ケーススタディ PHPで作られた Web Service
31. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 今回の実例で取り上げるSUT • 今回の実例で取り上げるテスト対象システム（SUT）はサービスの管理業務を担う ◦ ブラウザベースでアクセスするサービスであり、背後に内部APIやDB等が控える • すでに本番稼働しているシステムに対して、新機能を実現するための開発でATDDを実践 • PHP 7・CakePHP で構築されており、PHPUnitを用いたユニットテストを書いている • 2週間を1イテレーションとして漸進的に機能を実現していく仕事の流れ 31
32. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ケーススタディのエッセンス 32 ユーザーストーリーを洗い出す １ １ 2 3 4 例を特定しユーザーストーリーの受入 条件に反映する 受入条件を受け入れテストに反映する 実装・受け入れテストを実行する 2 3 4
33. © 2012-2021 BASE, Inc. 33 - 3. ケーススタディ - 3-1. ユーザーストーリーを洗い出す
34. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ユーザーストーリーを洗い出す 34 • 新機能リリースのために実現するユーザーストーリーを、業務フローや画面モッ ク・ユースケース等をインプットに、洗い出していく • ユーザーストーリーは、ソフトウェアを使う側の視点で記述される使い手にとっ ての価値を指す ◦ よくある記述Template: ▪ ＜ユーザー＞が、＜機能・性能＞にする。なぜなら＜ビジネス価値＞のため だ。 • ex. 「ショップオーナーが、入出金履歴で売上を見れるようにする。なぜな ら売上を確認するためだ。」 • ユーザーストーリーを実現するために、バーティカルスライスでのデリバリーが 必要になる
35. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. バーティカルスライスのデリバリー “短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチーム が養わなければならない。こうした活動をサポートするために用いられる設計アプローチは バーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデ リバリーするために各アーキテクチャ層で変更を行う、というものである。” 35 『More Effective 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
36. © 2012-2021 BASE, Inc. 36 - 3. ケーススタディ - 3-2. 例を特定しユーザーストーリー の受入条件に反映する
37. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 例を特定し受入条件に反映する 37 それぞれのユーザーストーリの具体的な例を特定していく中で、ストーリーの完成イメー ジを具体化し、受入条件として表現する • 例：とあるプロポーザル管理システムのユーザーストーリーと具体例(※1) ※1 実際の業務要件をそのままお見せできないので、当資料作成中ちょうど目の前にあった https://fortee.jp/ を題材とさせていただいており ますが、整理した具体例はなるべく実際に業務で行ったものに近づけています。
38. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームでの例特定とコミュニケーション 38 • GitHubのIssueでユーザーストーリーを作成している弊チームでは、Issueの説明内に見 つかった例を受入条件として書き加えている • たたき台として「受入条件」となりそうな具体例を載せておいて、イテレーション計画 時にProduct Manager・Developer間で実際に会話し、ユーザーストーリーの具体例の 確認・認識共有を行っている • 社内管理機能の場合、実際に使用するユーザーが社内にいるため、具体例を用いて業務 バリエーションの確認を行うのが要件整理において効果的だった ex. 「採択承諾のリマインドを送る機能って具 体的にはこういうことになりますかね〜？」 といった会話を行う (※1) ※1 実際の業務の会話はそのまま出せないので、属性の近いような別システムの要件を例に取っています。
39. © 2012-2021 BASE, Inc. 39 - 3. ケーススタディ - 3-3. 受け入れテストを書く
40. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 3. 受け入れテストを書く 40 自動受け入れテスト作成・実行ツール １ 2 3 具体例・受入条件から受け入れテストを作成する テスト実行手段としての、ユニットテスト・手動テストとの併用
41. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 3. 受け入れテストを書く 41 自動受け入れテスト作成・実行ツール １ 2 3 具体例・受入条件から受け入れテストを作成する テスト実行手段としての、ユニットテスト・手動テストとの併用
42. © 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://fitnesse.org/FrontPage
43. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. gauge実行・結果レポート 43 2. 実行結果 1. VSCode上で実行 3. 結果レポート表示 *.spec ※1 テスト実装の中身は仮実装です
44. © 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は後片付け処理として実行される
45. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. gaugeのSpecificationファイル 45 example.spec *.spec で定義したステップを選択したプログラミング言語で実装する API Client実装 webdriver selenium Pythonの場合は @step() でマッピング JavaScriptの場合は step() でマッピング
46. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 3. 受け入れテストを書く 46 自動受け入れテスト作成・実行ツール １ 2 3 具体例・受入条件から受け入れテストを作成する テスト実行手段としての、ユニットテスト・手動テストとの併用
47. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 具体例・受入条件から受け入れテストを作成する 47 • たとえば、次の受入条件の場合 • 具体的なUI操作方法・技術的実装をプ ログラミング言語によるステップ実装 で実現する • Specification に自然言語でステップとして表現する
48. © 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を操作した記録を元にコードを生成することも可能で、手 元での試行錯誤もしやすい
49. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. taiko demonstration 49 taiko でブラウザ操作する > openBrowser() > goto('https://fortee.jp/') > click('PHPerKaigi 2021') > click('ログイン')
50. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. UIテストの「テストファースト」 50 • 自然言語で書く Specification は受入条件をそのまま表すもの • テストファーストに受け入れテストを定義することで、「これから完成させるもの」について の共通認識へ • 一方で実際のUI操作をする技術的実装であるステップ実装は、作ってみないとわからない 要素もある ◦ そのままステップ実装まで作りきれるほど明確なのであれば作ってもいい ◦ UI実装が未確定であれば例外等でテストが落ちるようにして、実際にSUTを開発しなが らステップ実装を並行して行う
51. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 51 • 要件を明確に定義し、かつ自動化された受け入れテストにかんたんに変換できる言語とし て、Eric Evansのユビキタス言語の形成を取り入れる [ユビキタス言語とは] • ドメインエキスパートも開発者たちもプロジェクトチーム全体で、同じ用語を使い、ひと つの言語を共有する （『実践ドメイン駆動設計』1.3 DDDを行う方法） • ユビキタス言語を使って受け入れテストを記述する • テストを書いている際に “未定義な語彙” が出てくる。それらはドメインモデリング へフィードバックする ◦ 弊チームでは、ユビキタス言語の形成が必要な概念が出てきたら、GitHub Issueに「ドメインモデリング」 Issueを作成して、後ほどチームで話す機会がある際に取り上げる方式をとっている 受け入れテストにはユビキタス言語を使う
52. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 3. 受け入れテストを書く 52 自動受け入れテスト作成・実行ツール １ 2 3 具体例・受入条件から受け入れテストを作成する テスト実行手段としての、ユニットテスト・手動テストとの併用
53. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動化しにくいテストをどう扱うか 53 • ATDDがフォーカスするQ2領域はもともと手動・自動テストの両方が混在しやすいエリア • 受入条件の中には自動化しにくいシナリオや機能は存在する ◦ ex. メール送信をしてそのメール文面をチェックする • テスト効率を考えても手動でテストしたほうがよい場合もある。すべてを必ず自動化しない といけないわけではない
54. © 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で 手動テストと明示
55. © 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の下を通ることが優れたソリューションであることが多い 『Specification by Example』 Chapter 9. Automating validation without changing specifications より私訳 • ビジネスロジックをすべてUIテストで実現していくと 「アイスクリームコーン」アンチパターンになってしまう
56. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. PHPUnitを活用している現場における適応課題 56 • ATDDのツールではユニットレベルもサポート可能ではある ◦ たとえばBehatを用いれば同じPHP言語なので直接コードを呼ぶことも可能 ◦ 「ビジネス視点でのテスト」というのが本意にあるためテストレベルに制約はない • しかし、すでにPHPUnitでユニットテストは抑えておりそこを切り替えたい課題もない ◦ TDD Cycleでは引き続きPHPUnitを使っている ◦ 開発者の迷いを産まない点でも同一テストレベルで複数ツールを使い分けるのは微妙 • テスト自動化コードの実装言語にJavaScriptを選択しているので直接PHPプログラムを呼べ ない（この点を重要視したツール選定ではなかったため）
57. © 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
58. © 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. つねに実行される「生きているドキュメント」 ではなく、変更への追従が遅れる可能性がある 実装するまでは落ちるように テストを書いたら通るように修正
59. © 2012-2021 BASE, Inc. 59 - 3. ケーススタディ - 3-4. 実装・受け入れテスト を実行する
60. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 手元ではローカル開発環境・CIでは検証環境へ 60 • 手元の実行ではDockerローカル開発環境へ向けて 実行する ◦ 適宜動作確認したいタイミングで実行する • CIではデプロイされた「検証環境」に対して実行 する ◦ 受け入れテストコードの更新時に実行 ◦ cronで日次の定期実行 当テスト専用の環境・DBを用意するのがテストデータ準備の都合や失敗原因を局所化するために理想ではあるが、テスト対象システムの規模や事情の中でバランスを 取った結果、この実行方法となった。
61. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 受け入れテストを「仕掛中」と「完成」で区別する ATDDにおける「ストーリー受け入れテスト」はフェーズによって２つに区分される 1. 「仕掛中」 - 「まず最初に失敗する受け入れテストを書く」 - 進捗を測るテストであり失敗することがわかっている、CIフローには含めない 2. 「完成」 - リグレッションを検出するテスト - 完成したストーリーのテストは常に成功することが期待するためCIフローに含める 61 図: 『実践テスト駆動開発』（GOOS）を参考に作成した、 内側と外側のフィードバックループ図 「仕掛中のテストシナリオ」は実 行スキップされている
62. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 「仕掛中」と「完成」を区別する 62 • gaugeにはTagsというテストをフィルタリングする 機能がある ◦ （他のツールでも類似したものがあります） • “draft” Tagsを活用して「仕掛中」を明示する • CIフローでのテストスイート実行時は、 --tags=”!draft”オプションを設定し、draft以外を 実行する 「仕掛中のテストシナリオ」は実 行スキップされている
63. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 積極的なエラーレポーティングの意識 • 特にEnd2Endのテストレイヤになると失敗時の原因究明は難しい ◦ その時のネットワーク状況に応じて失敗することもある ◦ Flaky（同じコードで成功したり失敗したりする）になりがち 63 • 饒舌なエラーメッセージ ◦ 単に値の検証をするだけではなく、「なぜこの アサーションをしているのか」をエラーメッ セージに込める • 状況のスナップショット ◦ UIテストの場合は、アサーション対象のUI要素 をわかりやすくスクリーンショット ◦ APIの場合は返答されたレスポンスをテストレ ポートに記録する
64. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 64 TDDからATDDへ歩みを進めるモチ ベーション １ 2 3 4 ATDDとは ケーススタディ PHPで作られた Web Service 全体像としてのアジャイルテスト 5 6 7 まとめ 付録 参考文献
65. © 2012-2021 BASE, Inc. 65 4. 全体像としての アジャイルテスト
66. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. • ATDDはアジャイルテストの四象限におけるQ2をカバーする領域だった • 「アジャイルテスト」全体においてATDDはどのような立ち位置・重要性を持つ ものなのか？ アジャイルテストの四象限 66 ATDD
67. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの定義 “始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的なテストの実践 により、お客様への価値の頻繁な提供をサポートします。テスト活動は、高速なフィード バックループを用いて理解を検証しながら、プロダクトの品質を築くことに重点を置いてい ます。このプラクティスは、品質に対するチーム全体の責任という考え方を強化し、サポー トします。” 67 by Lisa Crispin and Janet Gregory (Our ever-evolving, never set-in-stone definition 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
68. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 「継続的に実施される」とはどういうことか 68 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ DevOpsにおけるあらゆるフェーズにおい てTestingは存在している 「Continuous Testing（継続的テス ト）」という考え方 継続的かつ全体的なテストアプローチを重 要とする あらゆるフェーズにおいてテストが継続的 に実施され続ける
69. © 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 成功するアジャイルテストアプロー チに必要なマインドセット • 開発プロセス全体をテスト • バグの防止 • 理解している価値をテスト • 最高のシステムを構築 • 品質に対するチーム全体の責任
70. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストのPractices 70 70 Janet Gregory氏・Lisa Crispin氏によるアジャイルテストで行われる活動の整理 図: “Our ever-evolving, never set-in-stone definition of ‘agile testing’”をマインドマップに起こした (https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/)
71. © 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 effectively. “ (『More Agile Testing』) → 「具体的な例による開発のガイド」となる Example-driven development は、アジャイルチームのコアプラクティスとなる
72. © 2012-2021 BASE, Inc. 72 5. まとめ
73. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 弊チームでの歩み出したプロダクト開発課題の先 • ユーザーストーリーの受入条件が曖昧になりがちで、「何をもって完成したのかを判断する基準」が明確に なっていない故、共通見解が取れてなかったこともあった →具体例によるユーザーストーリーの理解 →受け入れテストを作ることを意識することによる受入条件の明確化 • これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合は手動で同じシナリオを毎 回テストしている →受け入れテスト作成を通じた自動E2Eテストの整備につながった
74. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. まとめ • ATDDはExample-driven developmentの一種であり、コラボレーションを重視したソフ トウェア開発プロセス • ユーザーストーリーの受入条件を明確にしユーザーストーリー活用レベルアップを図る • gauge を用いたATDDプラクティスの活用事例・現場の試行錯誤をお伝えした • TDDからATDDへ歩みを進めることで、ソフトウェアテストの活動領域を拡大していこう 74
75. © 2012-2021 BASE, Inc. 75 6. 付録
76. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 付録目次 A. CIでのテスト実行基盤事例 B. Dan NorthのExample-guided developmentへのRename案 C. ATDDに類似するプラクティスについて D. ISTQBにおける「受け入れテスト駆動開発」の定義 76
77. © 2012-2021 BASE, Inc. 77 - 付録A - CIでのテスト実行基盤事例
78. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 実例：複数サービスで構成されたAPI Service • 今回の実例で取り上げるテスト対象システム（SUT）は Web API Service • 背後に内部APIやDB・Redis Server等が控える Public API • 新規構築ではなく、すでに本番稼働しているサービスに対して導入した 78
79. © 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 ...
80. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. CI/CD Pipelineに入れ込む • 稼働中サービスは CircleCI を用いてCI/CD Pipelineを組んでいた • 検証環境デプロイ後に「ストーリー受け入れテスト」の実行を入れ込む 80
81. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. CircleCIでのjob実行例 81 .circleci/config.yml https://github.com/hgsgtk/gauge-python-circleci-sample/blob/v0.0.2/.circleci/config.yml
82. © 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
83. © 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の実行内容をほぼそのまま持っていける
84. © 2012-2021 BASE, Inc. 84 - 付録B - Dan NorthのExample-guided developmentへのRename案
85. © 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共著者）
86. © 2012-2021 BASE, Inc. 86 - 付録C - ATDDに類似するプラクティス について
87. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ATDDに近い名前たち 87 類似する様々な名前たちがある。 • ATDD (Acceptance Test-Driven Development) (※1) • BDD (Behavior-Driven Development) • SBE (Specification 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を紹介しているが概ね同じものを指している
88. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの四象限における位置づけ 88 ATDD SBE BDD （外側のループ） BDD （内側のループ） TDD ATDD/SBE/BDD(外)は「ビジネス面 && チーム支援」の領域をカバーするテスト
89. © 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-KazcbMVCnRfih6zMSDBdtf90KviV7l2oxGyW M/edit?hl=en • Declan Whelan氏・Gojko Adzic氏らによる共通理解 整理 (2010) • 「インパクトマッピング」等を用いてストーリー回り のゴールを特定する • 「仕様ワークショップ」にて仕様となる主要な例を導 き出す
90. © 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
91. © 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
92. © 2012-2021 BASE, Inc. 92 - 付録D - ISTQBにおける 「受け入れテスト駆動開発」の定義
93. © 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 Qualifications Board)による「受け入れテ スト駆動開発の説明は以下の通りである
94. © 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
95. © 2012-2021 BASE, Inc. 95 7. 参考文献
96. © 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
97. © 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
98. © 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 definition of ‘agile testing’ https://agiletester.ca/ever-evolving-never-set-stone-definition-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
99. © 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 Specification tools https://jp-lambert.me/comparing-executable-specification-tools-b7081cc26315 アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- / Satoshi Masuda https://www.slideshare.net/satoshimasuda/ss-3241717 Open Source Test Automation Framework | Gauge https://gauge.org/ 99
100. © 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
101. © 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
102. © 2012-2021 BASE, Inc. Ask me at #phperkaigi