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

「CIのためのテスト自動化」というテーマで第17回QUESに招待いただいた際の資料です。

- Agileチームにおけるテスト自動化の試行錯誤から得られたしくじり
- Agile Testingの概要とその一つの取組みとしてのATDDの実践をテスト自動化目線で
- システムレベルの自動E2Eテストの作成・維持に焦点を当てる

Transcript

1. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Agile Testingを夢見た テスト自動化 1 第17回 Ques - November 18, 2021 〜ATDDへの挑戦から始まる1年間の試行錯誤〜 @hgsgtk Kazuki Higashiguchi
2. CIのためのテスト自動化 https://www.shutterstock.com/image-vector/developer-laptop-computer-open-robotic-soft-1241063605
3. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「CIのためのテスト自動化」について話すこと １ ２ ３ Agile Testingの概要とその一つの取組みとしての ATDDの実践をテスト自動化目線で Agileチームにおけるテスト自動化の試行錯誤から得ら れたしくじり システムレベルの自動E2Eテストの作成・維持に焦 点を当てる 3
4. 4 33% E2Eテストがあるプロジェクト ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/
5. 5 44% 開発者10人あたり担当者QA 1人未満 ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/
6. 6 12% BDDテクノロジーを使用している ※ JetBrains社による調査、回答者属性: テスター / QA エンジニアとして働いている OR 業務の一環としてテストに関与している https://www.jetbrains.com/ja-jp/lp/devecosystem-2021/testing/
7. 7 E2Eテストが 有る “専任”QA エンジニア 不在 BDD を使用し ている 多くの現場に共通しながら ちょっと珍しいチャレンジをした 開発チームの物語
8. 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)
9. © 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事務局の皆様
10. © 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. 考察とその後
11. © 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. 考察とその後
12. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Eコマースプラットフォーム「BASE」 「誰でもかんたんに使える」サービスで自分だけのネットショップを開設
13. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 即時に資金調達ができる 「YELL BANK」 ネットショップの売上がすぐ に使える「BASE Card」 決済 BASEかんたん決済 6つの決済方法を ショップに導入可能 EC Eコマースプラット フォーム「BASE」 誰でもかんたんに使える ショップオーナーの活動を多方面からサポート 金融
14. © 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
15. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. BASE BANKチームのプロダクト開発状況 即時に資金調達ができる 「YELL BANK」 ネットショップの売上がすぐに使える 「BASE Card」 ... ... • 短いイテレーションを回し、ユーザーストーリーベースの開発計画を行っている • ユニットテストを書き、その他静的解析やフォーマットも含めて、CIでの自動実行 を行う。CircleCI等を用いてCI/CD Pipelineを組みデプロイ自動化を行っている
16. © 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. 考察とその後
17. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「はじまり」の課題提起 API結合レベルの自動テストの仕組みを 用意する • アジャイルテスティングを次に進める • APIテストによる動作保証をする • 短いイテレーションでリリース可能な品質のも のを出す • テストピラミッドを登る
18. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 課題提起からうまく進まなかった • 「API結合レベルの自動テストの仕組みを用意する」ためのHOWの情報はたくさ ん集まった • 一方でWhyとの結びつきが弱く、選択肢の数々に対して落とし所がわからなくな る • Whyについてキーワードしかあげていない。キーワードだけで周りは理解できな い。おそらく自分自身もわかっていない。
19. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化のしくじり HOWから 課題提起してしまう
20. 20 根本に立ち戻る BASE BANKチームでは「技術戦略」を設定 短期的計画に依存しないエンジニアリング 組織としての戦略定義
21. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 書籍の補助輪を借りて自分の考えを言語化する 特に参考にした書籍
22. Agile Testingを夢見た https://www.shutterstock.com/image-photo/childhood-dream-about-big-famous-future-2006490497
23. 23 アジャイルテストの定義 “始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的 なテストの実践により、お客様への価値の頻繁な提供をサポートします。 テスト活動は、高速なフィードバックループを用いて理解を検証しながら、 プロダクトの品質を築くことに重点を置いています。 このプラクティスは、品質に対するチーム全体の責任という考え方を強化 し、サポートします。” “Our ever-evolving, never set-in-stone definition of ‘agile testing’” by Lisa Crispin and Janet Gregory
24. 24 継続的に実施される協調的なテストの実践 > Continuous Testing in DevOps DevOpsにおけるあらゆるフェーズにおい てTestingは存在している 「Continuous Testing（継続的テス ト）」という考え方 継続的かつ全体的なテストアプローチを重 要とする あらゆるフェーズにおいてテストが継続的 に実施され続ける “Continuous Testing in DevOps…” by DAN ASHBY (2016年10月19日)
25. 25 品質に対するチーム全体の責任 > TESTING Manifesto The Testing Manifesto - Growing Agile by Karen Greaves and Samantha Laing（2015年4月10日） 成功するアジャイルテストアプローチ に必要なマインドセット 1. 最後のテストではなく、全体を通して のテスト 2. バグを見つけることより、バグを防ぐ こと 3. 機能のチェックよりも理解度のテスト 4. システムを壊すことよりも、最高のシ ステムを構築すること 5. テスターの責任よりも品質に対する チームの責任
26. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストのPractices 26 26 Janet Gregory氏・Lisa Crispin氏によるアジャイルテストで行われる活動の整理 図: “Our ever-evolving, never set-in-stone definition of ‘agile testing’”をマインドマップに起こした
27. 27 特に注目した考え方 • コードの欠陥だけでなくフィーチャーの振る 舞いに関する誤解を防止する • 会話による共通の理解形成 • テストの自動化 • 具体的な例による開発のガイド “Our ever-evolving, never set-in-stone definition of ‘agile testing’”より
28. 28 考えの全体像を示す （当時の説明） 「柔軟」を実現するために、 • ソフトウェアのデリバリー速度と変更可能性を高める • イテレーションごとに作るサービスの外部品質・内部品質をどうあ げるか • Agile Testの考え方が全体像のヒントになる • その中で例によって駆動するEDD(Exapmle Driven Development) • ATDDに取り組むためのテスト自動化を実現したい
29. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. プロダクト開発における課題意識が明確に • ユーザーストーリーの受入条件が曖昧になりがち。「何をもって完成したのかを判 断する基準」が明確になっていない故、共通見解が取れてなかったこともあった • これまで完成した機能のデグレチェックはユニットレベルで収まらない変更の場合 は手動で同じシナリオを毎回テストしている “ストーリーは成功と失敗の2値で判断できるようテスト可能でなければならない。テスト可能に するとは、ストーリーに（満足条件として）関連付けられる適切な受け入れ条件があるというこ とだ。これは5.4節で述べたユーザーストーリーにおける確認という観点である。” 『エッセンシャル スクラム』より
30. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 課題設定のスコープを見直して変更した • 課題設定のスコープは「開発の進め方自 体」の改善 • ストーリー受入テストに着目する • その一つの施策としての「テスト自動化」 その後のISSUEコメント *1 ※1 完了条件・完成条件などの語彙の使い方がめちゃくちゃですね。当時の走り書きの文章で残 念なことになってるのでご勘弁くださいmm
31. © 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. 考察とその後
32. © 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 Staffs • 新規構築ではなくすでに本番稼働していたサービス • アプリケーション開発だけでなくインフラ・CI/CDもすべて自チームのみで運用し ている、意思決定のハードルが低いのでまずここで試した Database RDBMS KVS service B external API
33. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化基盤構築の思考アプローチ 33 Why: なぜやりたいのか Who: 誰が作りたいのか HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に
34. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Step1: アジャイルテストの4象限から目的を特定する 34 Why: なぜやりたいのか HOW: どのツールで Who: 誰が作りたいのか WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に
35. © 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
36. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストの四象限の「縦軸」 36 Designer Engineer PO Test engineer Business focus Technical Focus Business Focus: ビジネスの専門家が興味を持つ ような言葉で説明される Technical Focus: プログラマの領域の言葉で説明 されるテスト
37. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「誰の不安によって実施するのか」という問い 37 Designer Engineer PO Test engineer Business focus Technical Focus 誰の不安・関心によって実施 されるテストか 例： • エンジニアとしてビジネスロジックを 統合して本当に動作するのか知りたい • テストエンジニアとして実装されたシ ステムが受け入れ条件を満たしている のか確かめたい Who: 誰が作りたいのか Why: なぜやりたいのか おのずと見えてくる
38. 38 四象限ごとの自動テスト特性 Q1: Code levelでの開発者の関心をテストできる - 特にプログラマがテストを書きやすいこと - ローカル開発環境で実行できる体験 - システム異常系の再現といった例外系のニーズも強くなる Q2: 顧客視点でのテスト記述と頻繁な実行 - プログラマ・テストエンジニア・仕様定義者が書きやすい - 顧客視点で確認したい機能性をシステムレベルで統合的にみたいニーズが強い - シナリオベースでのテスト作成 Q3: 製品批評の一部自動化 - 本番環境テストなど定期的に本番システムをテストしたい（ex. New Relic Synthetics） Q4: 品質特性ごとのテスト要件 - 「パフォーマンステストであれば、本番同等環境を非定期に実行できればよい」と いったテストごとのテスト実行要件（頻度・統合レベル...etc）がある 補足
39. © 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 ユーザーストーリーの実装が受け入れ条 件を満たしているのか確かめたい
40. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Step2: テスト自動化レイヤを特定する 40 HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に Why: なぜやりたいのか Who: 誰が作りたいのか
41. 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
42. © 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の自動テスト実装においてどのレベルのテストが求められるかは、テスト対象システムの要件・テスト自動化 の費用対効果等によって変わります。
43. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Step3: テスト作成ツールを選定する 43 HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に Why: なぜやりたいのか Who: 誰が作りたいのか
44. © 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://fitnesse.org/FrontPage 顧客視点のシナリオテストの作成・実行の仕組みを用意するため、受け入れテスト自動化ツールを見回った。
45. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 45 gaugeのテスト記述・実装構造
46. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. gaugeの実行・結果イメージ 46 2. 実行結果 1. VSCode上で実行 3. 結果レポート表示 *.spec
47. 47 gauge Specification Syntax 補足 Markdown-likeなSpecification Syntax # Specification 仕様、xUnit系でのテストクラスに該当 * Contexts step 前処理、xUnit系でのSetUpに該当 ## Scenario 個別のテストシナリオ、xUnit系ではテストメソッド * Step テストシナリオ内で実行するステップ ___ 後片付け、xUnit系でのTearDown 定義後のStepは後片付け処理として実行される
48. © 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() でマッピング
49. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Step4: テスト環境を決定する 49 HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に Why: なぜやりたいのか Who: 誰が作りたいのか
50. 50 テスト環境の選択肢 API service service A RDBMS KVS service B テスト実行ごとに毎回新規環境を作 成する 自動テストのためのCI専用環境を用 意する 手動検証環境を利用する System Under Test A B C
51. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. A. テスト実行ごとに毎回新規 環境を作成する B. 自動テストのためのCI専用 環境を用意する C. 手動検証環境を利用す る 利点 完全にCI Job専用の環境 テスト実行結果は安定しやす い 手動テストなど人の操作の影 響を受けない独立性 すでに構築済みの環境を 用いるため始めやすい 欠点 構成が複雑であるほど 構築難易度は高い 稼働コスト 既存のCD pipelineへの組み込 み工数 手動テストの影響を受け る可能性がある *1 初期工数 テスト環境の選択肢それぞれの評価 51 *1 手動テスト環境と自動テスト環境を混ぜるリスクは『Specification by Example』のChapter 10. Validating frequently にて解説されている。 テスト失敗時に「テストが正しく失敗した」のか「手動テストの影響を受けた」のかわかりにくくなる点を指摘している。
52. 52 「C. 手動検証環境を利用する」を選択した まずは始めることを優先した やってみないことには 「本当に自分たちが必要なもの」 はわからない
53. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. Step4: CI/CDへの導入、実行頻度の決定 53 HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に Why: なぜやりたいのか Who: 誰が作りたいのか
54. CIのためのテスト自動化 https://www.shutterstock.com/image-vector/developer-laptop-computer-open-robotic-soft-1241063605
55. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. CI/CD Pipelineに入れ込む • 稼働中サービスは CircleCI を用いてCI/CD Pipelineを組んでいた • 検証環境デプロイ後に「ストーリー受け入れテスト」の実行を入れ込む 55
56. 56 CircleCIでのjob実行例 補足 .circleci/config.yml https://github.com/hgsgtk/gauge-python-circleci-sample/blob/v0.0.2/.circle ci/config.yml
57. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. データ準備の煩雑さでテスト増やすのに苦戦した 環境変数用ファイル テストA用 テストB用 *.properties.sample テストD用 テストC用 テスト作成者 Database 2. 作成したユーザーの情報をテスト用の環境変数ファイルに 記載する 1. 手動でアカウントデータを作成しておく 苦戦していた際のテストデータの作り方 テスト作成者 3. テスト自動化コードは環境変数からアカウント情報を取得する
58. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化のしくじり テストデータの 用意が億劫で 心折れる
59. 59 テストデータを作る タイミング2選 1 テスト環境に手動でデータを用意しておく 毎Scenarioごとにデータを作成・調整 • テスト自動化コードを書く前にひと手間発生 • テストシナリオとデータの関係性が暗黙的になり わかりづらくなる ◦ ex. ID=1のショップを使う（なぜ？ • 環境差異の影響を受けにくい • E2Eにおいて自動でデータを用意しにくいことも多い ◦ ex. 本人確認書類での本人確認を終えたショップを用意しよう • テスト速度が低下する ◦ ex. 毎回ネットショップを開設すると？ 2
60. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 毎Scenarioごとにデータを作成・調整するようにした ※ gaugeにはシナリオ内でデータを伝搬させる方法として DataStore という機構が用意されている。 当機構でテストシナリオで作成したアカウント情報をscenario全体で使用することが出来る。
61. © 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. 考察とその後
62. ATDDとは https://www.shutterstock.com/image-photo/close-top- view-young-business-people-1498583432
63. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDとは... 特に参考にした書籍
64. © 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 effectively. “ (『More Agile Testing』) → 「具体的な例による開発のガイド」となる Example-driven development は、アジャイルチームのコアプラクティス
65. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. アジャイルテストの四象限における位置づけ 65 ATDD SBE BDD （外側のループ） BDD （内側のループ） TDD ATDD/SBE/BDD(外)は「ビジネス面 && チーム支援」の領域をカバーするテスト
66. 66 ATDDに近い名前のプラクティス 補足 • 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を紹介しているが概ね同じものを指している
67. © 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)等が挙げられます。
68. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 2. 「ストーリー受け入れテスト」とは 68 • 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）
69. © 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）を参考に作成した、 内側と外側のフィードバックループ図
70. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 自動テストから得られるフィードバック 70 『実践テスト駆動開発 (Object Oriented SELECTION)』 第一章 テスト 駆動開発のポイントとは？ https://www.amazon.co.jp/dp/4798124583 外部品質のフィードバック - エンドツーエンドのテストの実行によってシステムの 外部品質へのフィードバックを多く得られる - ストーリー受け入れテストを書くことでドメインにつ いてチームがどれほど理解できているかについての知 見が得られる 内部品質のフィードバック - ユニットテストを書くことで、コードの質についての フィードバックを数多く得ることができる 外部品質: システムが顧客やユーザーのニーズにどれだけ応えられているか （機能を備えているか、信頼できるか、利用できるか、素早く反応するか...etc） 内部品質: 開発者や管理者のニーズにどれだけ応えられているか （理解しやすいか、変更は容易か...etc）
71. © 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）を書いて自動化し開発を進め、自動化されたチェックに合格すると、探索的テスト等他テスト を行う準備ができたとみなす
72. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 5. 厳密な言語・ルールのない例で開発を導く 72 • ユーザーストーリーに対して、具体的な例をビジネス・開発者・テスター等ステークホルダーで会話し特定す る • 関係者が理解でき会話できることが期待できる、事業領域の用語で受入テストとして具体化する ◦ その際の言語・記述ルールに対する厳密な規定はしていない 図：Cucumberを用いた場合は Gherkin 記法によってシナリオ記述 図：gaugeを用いた場合は Markdown 記法によってシナリオ記述
73. ATDDの実践 https://www.shutterstock.com/image-photo/new-year- 2021-start-straight-concept-1843332130
74. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 舞台は新規機能開発 74 for End user for administrator API service service A End users BASE Staffs Database RDBMS KVS service B external API new service • サービスの管理業務を担う”for admin”とエンドユーザー向けの”for end user” • アプリケーション開発までは自チームだけで完結するがCI/CDやインフラは別チー ムも関わってくる”大きなシステム”
75. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDの仕事の流れ 75 ユーザーストーリーを洗い出す １ １ 2 3 4 例を特定しユーザーストーリーの受入 条件に反映する 受入条件を受け入れテストに反映する 実装・受け入れテストを実行する 2 3 4 第17回QUESでは『CIのための自動化』がテーマなので概要レベルで割愛します。詳細を見たい方は『実践ATDD 〜TDDから更に歩みを進めたソフトウェ ア開発へ〜』をご覧ください。
76. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 自動化ステップ: ブラウザ自動テストツールの選定 76 HOW: どのツールで WHEN: どのタイミングで What: どのレイヤで Where: どのテスト環境に Why: なぜやりたいのか Who: 誰が作りたいのか
77. © 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のページは参考になる その他...
78. © 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("first name", toLeftOf("last name")) • gauge同様ThoughtWorks社がメンテナンスしていることもあり、「受け入れテストツール」での利用をより意 識されている（所感） • 相対的にマイナーではあるため、情報量は少ない 2つのSUTに対して playwright と taiko を使っているが、playwrightのほうが優勢（所感）
79. 79 TAIKOによるCUI上で の試行錯誤支援 補足 TAIKO ではCUI上でブラウザ操作する機 能が搭載されている > openBrowser() // ブラウザを開く > goto('https://fortee.jp/') // URLアク セス > click('PHPerKaigi 2021') // クリック > click('ログイン') 逐次的にAPIを試してテスト自動化コード を作成する
80. 80 Playwright Inspector の体験 補足 Playwright InspectorでUI操作 操作した過程がコードとしてレコーディ ングされる 生成されたコードを組み合わせてステッ プ実装を行う
81. 81 テストデータを作る タイミング2選 1 テスト環境に手動でデータを用意しておく 毎Scenarioごとにデータを作成・調整 • テスト自動化コードを書く前にひと手間発生 • テストシナリオとデータの関係性が暗黙的になり わかりづらくなる ◦ ex. ID=1のショップを使う（なぜ？ • 環境差異の影響を受けにくい • E2Eにおいて自動でデータを用意しにくいことも多い ◦ ex. 本人確認書類での本人確認を終えたショップを用意しよう • テスト速度が低下する ◦ ex. 毎回ネットショップを開設すると？ 2 再掲
82. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 「1. テスト環境に手動でデータを用意しておく」 • E2Eにおいて自動でデータを用意しにくいことがほとんど 例: 電話番号認証・本人確認書類提出・銀行口座を指定して振込申請 • 検証環境で手動テストと自動テストが両方行われる分、自動テスト専用アカウン トを作ることで相互に影響を与えるのを回避する 82
83. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. データの調整が必要なテストへの回避措置 直接SUT上の機能ではカバーできないテストデータを、別システムを裏口として事 前条件を整える 例: サービス管理画面から裏側の業務処理を行う 83
84. © 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. 考察とその後
85. 85 作成された自動テスト のその後 ATDDの取り組み実施時に作成 したE2Eテストは継続的に実行 され、リグレッションテストと して活躍し続けている 障害発生を防いだ例
86. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ATDDを継続しようとしたができなかった 86 型ができて後続の機能開発でも実施しようとしたが、着手に至らな かった。 特に意識しようとした点 • ユーザーストーリーの受入条件の策定にQA Engineerが参加する • テスト自動化出来るものは並走してテスト自動化コードを書く → 継続するには２つの前提条件がある。
87. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. ２ ATDD継続の２つの前提条件 *1 １ 仕様・受入条件策定者がテスト自動化に至る までの一連の取り組みに時間をさけること （あるいはエンジニアがテスト実装に時間をさけること） 専任の”QAエンジニア”がプロダクト開発の前 線に居続ける ※1 TDDからの拡張の歴史的経緯やBDDというカウンターカルチャー的側面などを中心に捉えるとこの条件は「間違ってる！」と思うかもしれません。より正確に は、当スライドで解説しているAgile Testingの文脈で語られるところの「Example-driven developmentを継続して実践するには」という表現でしょうか。
88. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 兼任でプロダクト開発の前線に居続けられるか？ 88 エンジニア採用 個人評価 ユ ー ザ ー ス ト ー リ の 受 入 条 件 を 作 成 す る 全体テスト計画 性能テスト設計・実施 結合テスト設計・実施 連携テスト設計・実施 システムテスト設計・実施 ...etc 開発チーム メンバーの増加 プロジェクト全般の 優先的なQA活動 Engineering Manager QA engineer イ テ レ ー シ ョ ン ご と に 自 動 テ ス ト を 積 み 上 げ る Managementの割合がより強くなるほどEMとの兼任者は難しい イテレーションに常にいる”QAエンジニア”にはなれなくなる
89. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化にハマっても時間をさく余裕？ 89 E2Eテスト自体はユニットテストと比較すると事前条件が多く作り にくい。さらにハマったときに原因判別も時間がかかる。 テストコードが悪いのか テストデータが悪いのか 仕様が間違ってるのか テストツールの バグなのか テストがなぜか通らない... 5月21日からDraftのテスト
90. 90 方向転換 「E2Eテストがほしいね」という 話があり、当初これを整備しよう としたが辞めた 自分がやらない決断も大事 適切にニーズを見極めよ 開発者自身が作ったほうが いい「E2Eテスト」もある ex. GoエンジニアがGoで書きやすいテスト基盤
91. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. テスト自動化のしくじり 「E2Eテスト」の 解像度で議論する
92. © 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
93. 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 のスコープ
94. © 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なのかが語彙に よって明らかになる
95. © 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と 共にテスト自動化に取り組んできた 積み重ねが資産になってる
96. © 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. 考察とその後
97. テスト自動化に 託そうとしたもの https://www.shutterstock.com/image-photo/woman-ha nds-holding-sun-dawn-freedom-1561794796
98. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 1. 手動テストの省力化 -> コスト削減 自動E2Eテストの ない世界 自動E2Eテストを 作る世界 自動E2Eテストと 同等の作業を 人力でやる世界 自動化による省力化 自動化を前提とした テスト計画により 得られる論理的なコスト削減
99. © 2012-2019 BASE, Inc. © 2012-2021 BASE BANK, Inc. 2. テスト自動化を切り口に始める開発全体の改善 Product Owner Frontend engineer Backend engineer ... 共通の理解が形成され、フィーチャに対する誤解がなくなる Product Owner Frontend engineer Backend engineer
100. 10 プロダクト開発の当初の課題と現況（１） 再掲 • ユーザーストーリーの受入条件が曖昧になりがち。「何をもって完成した のかを判断する基準」が明確になっていない故、共通見解が取れてなかっ たこともあった チーム人数の増加もともない潜在的な課題は顕在化 いくつかの施策で対応 • Agile Testingの3 amigosを参考にデザイナー・Frontendエンジニアでの密なコミュニ ケーションの実施（by sam8helloworld さん） • 結合/システムテストシナリオレビューによる仕様の認識整理 • リリースした機能に対する「システムテスト」を作成、自動リグレッションテスト
101. 10 プロダクト開発の当初の課題と現況（２） 再掲 • これまで完成した機能のデグレチェックはユニットレベルで収まらない変 更の場合は手動で同じシナリオを毎回テストしている デプロイされた環境に対する自動テスト実行によって 改善された 例：dependabotでの依存ライブラリアップデート対応
102. © 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年間の試行錯誤 、誤マシマシ... :(