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

© 2012-2019 BASE, Inc.
© 2012-2021 BASE BANK, Inc.
Agile Testingを夢見た
テスト自動化
1
第17回 Ques - November 18, 2021
〜ATDDへの挑戦から始まる1年間の試行錯誤〜
@hgsgtk Kazuki Higashiguchi

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
「CIのためのテスト自動化」について話すこと
１
２
３
Agile Testingの概要とその一つの取組みとしての
ATDDの実践をテスト自動化目線で
Agileチームにおけるテスト自動化の試行錯誤から得ら
れたしくじり
システムレベルの自動E2Eテストの作成・維持に焦
点を当てる
3

View Slide

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

View Slide

5
44% 開発者10人あたり担当者QA 1人未満

View Slide

6
12% BDDテクノロジーを使用している

View Slide

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

View Slide

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)

View Slide

© 2012-2019 BASE, 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事務局の皆様

View Slide

© 2012-2019 BASE, 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. 考察とその後

View Slide

© 2012-2019 BASE, Inc.
11
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践

View Slide

© 2012-2019 BASE, Inc.
Eコマースプラットフォーム「BASE」
「誰でもかんたんに使える」サービスで自分だけのネットショップを開設

View Slide

© 2012-2019 BASE, Inc.
即時に資金調達ができる
「YELL BANK」
ネットショップの売上がすぐ
に使える「BASE Card」
決済
BASEかんたん決済
6つの決済方法を
ショップに導入可能
EC
Eコマースプラット
フォーム「BASE」
誰でもかんたんに使える
ショップオーナーの活動を多方面からサポート
金融

View Slide

© 2012-2019 BASE, 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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
16
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践

View Slide

© 2012-2019 BASE, Inc.
「はじまり」の課題提起
API結合レベルの自動テストの仕組みを
用意する
● アジャイルテスティングを次に進める
● APIテストによる動作保証をする
● 短いイテレーションでリリース可能な品質のも
のを出す
● テストピラミッドを登る

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
テスト自動化のしくじり
HOWから
課題提起してしまう

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
書籍の補助輪を借りて自分の考えを言語化する
特に参考にした書籍

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
31
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践

View Slide

© 2012-2019 BASE, 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

View Slide

© 2012-2019 BASE, Inc.
テスト自動化基盤構築の思考アプローチ
33
Why: なぜやりたいのか
Who: 誰が作りたいのか
HOW: どのツールで
WHEN: どのタイミングで
What: どのレイヤで
Where: どのテスト環境に

View Slide

© 2012-2019 BASE, Inc.
Step1: アジャイルテストの4象限から目的を特定する
34

View Slide

© 2012-2019 BASE, 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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
Step2: テスト自動化レイヤを特定する
40

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
Step3: テスト作成ツールを選定する
43

View Slide

© 2012-2019 BASE, 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
顧客視点のシナリオテストの作成・実行の仕組みを用意するため、受け入れテスト自動化ツールを見回った。

View Slide

© 2012-2019 BASE, Inc.
© 2012-2021 BASE BANK, Inc. 45
gaugeのテスト記述・実装構造

View Slide

© 2012-2019 BASE, Inc.
gaugeの実行・結果イメージ
46
2. 実行結果
1. VSCode上で実行
3. 結果レポート表示
*.spec

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
Step4: テスト環境を決定する
49

View Slide

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

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
Step4: CI/CDへの導入、実行頻度の決定
53

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
CI/CD Pipelineに入れ込む
● 稼働中サービスは CircleCI を用いてCI/CD Pipelineを組んでいた
● 検証環境デプロイ後に「ストーリー受け入れテスト」の実行を入れ込む
55

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
テストデータの
用意が億劫で
心折れる

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
毎Scenarioごとにデータを作成・調整するようにした
※ gaugeにはシナリオ内でデータを伝搬させる方法として DataStore という機構が用意されている。
当機構でテストシナリオで作成したアカウント情報をscenario全体で使用することが出来る。

View Slide

© 2012-2019 BASE, Inc.
61
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
ATDDとは...
特に参考にした書籍

View Slide

© 2012-2019 BASE, 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
は、アジャイルチームのコアプラクティス

View Slide

© 2012-2019 BASE, Inc.
アジャイルテストの四象限における位置づけ
65
ATDD SBE
BDD
（外側のループ）
BDD
（内側のループ）
TDD
ATDD/SBE/BDD(外)は「ビジネス面 && チーム支援」の領域をカバーするテスト

View Slide

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を紹介しているが概ね同じものを指している

View Slide

© 2012-2019 BASE, 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)等が挙げられます。

View Slide

© 2012-2019 BASE, 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）

View Slide

© 2012-2019 BASE, 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）を参考に作成した、
内側と外側のフィードバックループ図

View Slide

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

View Slide

© 2012-2019 BASE, 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）を書いて自動化し開発を進め、自動化されたチェックに合格すると、探索的テスト等他テスト
を行う準備ができたとみなす

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, 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やインフラは別チー
ムも関わってくる”大きなシステム”

View Slide

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

View Slide

© 2012-2019 BASE, 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のページは参考になる
その他...

View Slide

© 2012-2019 BASE, 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のほうが優勢（所感）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
データの調整が必要なテストへの回避措置
直接SUT上の機能ではカバーできないテストデータを、別システムを裏口として事
前条件を整える
例: サービス管理画面から裏側の業務処理を行う
83

View Slide

© 2012-2019 BASE, Inc.
84
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
のスコープ

View Slide

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

View Slide

© 2012-2019 BASE, 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と
共にテスト自動化に取り組んできた
積み重ねが資産になってる

View Slide

© 2012-2019 BASE, Inc.
96
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
0. 前史
1. 構想
3. ATDDの実践
4. 大規模プロジェクトでのしくじり

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
1. 手動テストの省力化 -> コスト削減
自動E2Eテストの
ない世界
自動E2Eテストを
作る世界
自動E2Eテストと
同等の作業を
人力でやる世界
自動化による省力化
自動化を前提とした
テスト計画により
得られる論理的なコスト削減

View Slide

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

View Slide

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

View Slide

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

View Slide

© 2012-2019 BASE, Inc.
ご清聴ありがとうございました
102
2021 2021.11.18
2021.04
2021.09 2021.07 2021.10
2. 自動テスト
基盤の構築
1. 構想
、誤マシマシ... :(

View Slide

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

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

Kazuki Higashiguchi
PRO

More Decks by Kazuki Higashiguchi

Other Decks in Technology

Featured

Transcript

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

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

Kazuki Higashiguchi PRO

More Decks by Kazuki Higashiguchi

Other Decks in Technology

Featured

Transcript

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

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

Kazuki Higashiguchi
PRO