Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Kazuki Higashiguchi
PRO

November 18, 2021
Tweet

More Decks by Kazuki Higashiguchi

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    「CIのためのテスト自動化」について話すこと



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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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)

    View Slide

  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事務局の皆様

    View Slide

  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. 考察とその後

    View Slide

  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. 考察とその後

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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. 考察とその後

    View Slide

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

    View Slide

  18. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    課題提起からうまく進まなかった
    ● 「API結合レベルの自動テストの仕組みを用意する」ためのHOWの情報はたくさ
    ん集まった
    ● 一方でWhyとの結びつきが弱く、選択肢の数々に対して落とし所がわからなくな

    ● Whyについてキーワードしかあげていない。キーワードだけで周りは理解できな
    い。おそらく自分自身もわかっていない。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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’”をマインドマップに起こした

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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. 考察とその後

    View Slide

  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

    View Slide

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

    View Slide

  34. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    Step1: アジャイルテストの4象限から目的を特定する
    34
    Why: なぜやりたいのか
    HOW: どのツールで
    Who: 誰が作りたいのか
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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
    ユーザーストーリーの実装が受け入れ条
    件を満たしているのか確かめたい

    View Slide

  40. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    Step2: テスト自動化レイヤを特定する
    40
    HOW: どのツールで
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に
    Why: なぜやりたいのか
    Who: 誰が作りたいのか

    View Slide

  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

    View Slide

  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の自動テスト実装においてどのレベルのテストが求められるかは、テスト対象システムの要件・テスト自動化
    の費用対効果等によって変わります。

    View Slide

  43. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    Step3: テスト作成ツールを選定する
    43
    HOW: どのツールで
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に
    Why: なぜやりたいのか
    Who: 誰が作りたいのか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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() でマッピング

    View Slide

  49. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    Step4: テスト環境を決定する
    49
    HOW: どのツールで
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に
    Why: なぜやりたいのか
    Who: 誰が作りたいのか

    View Slide

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

    View Slide

  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 にて解説されている。
    テスト失敗時に「テストが正しく失敗した」のか「手動テストの影響を受けた」のかわかりにくくなる点を指摘している。

    View Slide

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

    View Slide

  53. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    Step4: CI/CDへの導入、実行頻度の決定
    53
    HOW: どのツールで
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に
    Why: なぜやりたいのか
    Who: 誰が作りたいのか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  58. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    テスト自動化のしくじり
    テストデータの
    用意が億劫で
    心折れる

    View Slide

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

    View Slide

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

    View Slide

  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. 考察とその後

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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)等が挙げられます。

    View Slide

  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)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    5. 厳密な言語・ルールのない例で開発を導く
    72
    ● ユーザーストーリーに対して、具体的な例をビジネス・開発者・テスター等ステークホルダーで会話し特定す

    ● 関係者が理解でき会話できることが期待できる、事業領域の用語で受入テストとして具体化する
    ○ その際の言語・記述ルールに対する厳密な規定はしていない
    図:Cucumberを用いた場合は Gherkin 記法によってシナリオ記述 図:gaugeを用いた場合は Markdown 記法によってシナリオ記述

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  76. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    自動化ステップ: ブラウザ自動テストツールの選定
    76
    HOW: どのツールで
    WHEN: どのタイミングで
    What: どのレイヤで
    Where: どのテスト環境に
    Why: なぜやりたいのか
    Who: 誰が作りたいのか

    View Slide

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

    View Slide

  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のほうが優勢(所感)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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. 考察とその後

    View Slide

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

    View Slide

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

    View Slide

  87. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.

    ATDD継続の2つの前提条件
    *1

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

    View Slide

  88. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    兼任でプロダクト開発の前線に居続けられるか?
    88
    エンジニア採用
    個人評価


















    全体テスト計画
    性能テスト設計・実施
    結合テスト設計・実施
    連携テスト設計・実施
    システムテスト設計・実施
    ...etc
    開発チーム
    メンバーの増加
    プロジェクト全般の
    優先的なQA活動
    Engineering Manager QA engineer





















    Managementの割合がより強くなるほどEMとの兼任者は難しい
    イテレーションに常にいる”QAエンジニア”にはなれなくなる

    View Slide

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

    View Slide

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

    View Slide

  91. © 2012-2019 BASE, Inc.
    © 2012-2021 BASE BANK, Inc.
    テスト自動化のしくじり
    「E2Eテスト」の
    解像度で議論する

    View Slide

  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

    View Slide

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

    View Slide

  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なのかが語彙に
    よって明らかになる

    View Slide

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

    View Slide

  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. 考察とその後

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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年間の試行錯誤
    、誤マシマシ... :(

    View Slide