© LayerX Inc. ⼿動 × ローコード × コードベース： 3つのアプローチをつなぐ実践 JaSST’ 25 Tokyo LayerX 髙橋 諒 

© LayerX Inc. 2 株式会社LayerX 経歴 - バルテス株式会社(2019/04-2021/12) - 個⼈事業主(2022/01-2022/05) - 株式会社LayerX(2022/06-) 画像を入れてね ⾃⼰紹介 髙橋 諒 （hashi） ブログ等 - 「世の中に新たなQAの形をつくる」半年に1つ のペースで新規プロダクトが⽣まれるLayerXの QAのあり⽅ - JaSST’24 Tokyo ミニセッション ⾃動テストの成果と失敗談 

⽬次 Agenda ● はじめに ● 3つのテスト⼿段を組み合わせる中で直⾯した 課題‧⼯夫 ○ ローコードツールの導⼊ ○ コードベースの導⼊ ● LayerXでのテスト⼿段の使い分け ● おわりに 

はじめに 

5 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法⼈⽀出管理サービス「バクラク」や企業内業務のデジタル化を⽀援するサービスを提供しています。 はじめに バクラク事業 企業活動のインフラとなる法⼈⽀ 出管理（BSM）SaaSを開発‧提供 Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 ⽂書処理を中⼼とした、LLMの活⽤によ るプロセスのリデザイン 

6 © LayerX Inc. テストの進め⽅ はじめに - ⽉に2回のリリース - 1リリースにつき3⽇間のテスト期間 - QAエンジニアがメインで新機能テスト‧リグレッションテストを実施 2023/07 2024/11 ⼿動 ⼿動 × ローコード ⼿動 × ローコード × コードベース 2021/01 2021/04 2021/11 2022/04 2022/07 

3つのテスト⼿段を組み合わせる中で 直⾯した課題‧⼯夫 

ローコードツールの導⼊ 

© LayerX Inc. 9 ローコードツールの導⼊ 2023/07 ⼿動 ⼿動 × ローコード ⼿動 × ローコード × コードベース 2021/01 2021/04 2021/11 2022/04 2022/07 2024/11 - 新規プロダクトの増加 - 既存プロダクト機能数の増加 - テスト実施のリソース調整の負荷 - リグレッションテスト 350ケース程度 - Bizメンバーがテスターとして参加 

© LayerX Inc. 10 good / difficult ローコードツールの導⼊ 導⼊時 テスト拡充のしやすさ ‧⼿動テストの要領でテストを作成できるので1つのテストが作る時間が短 い ‧専⾨的な知識が不要（JSやCSSセレクターの知識があるとより◎） 運⽤時 good 稼働時間に依存しない ‧稼働時間外にテストが完了する ‧コードのデプロイが完了した時 点でテストを⾃動実⾏できる good difficult 不安定さ ‧ツールでよしなに画⾯操作をしてく れる反⾯、意図しない箇所を操作した り、意図しない箇所の期待結果の確認 をすることがある 実⾏時間の⻑さ ‧1つのテストに20~30分程度かかるも のもあり、計13時間程度かかっていた ‧テスト期間を調整する必要があった 

© LayerX Inc. 11 テストの不安定さの解消 ローコードツールの導⼊ ②時間軸でテストの失敗を観察する - 直近3回実⾏された中で2回以上失敗してい たら修正要否を確認する対象としている - 成功率が低いものほど、根本解決（場当た り的な修正で済まないもの）する必要があ るテストを⾒つけられる ①テストをピンポイントで修正する - ツールでよしなに操作してくれないところ は⼀定、発⽣したのでピンポイントで指定 するような変更を⼊れる - cssセレクタ or Xpathで要素を指定する - テストしたい場所でなけれ代替⼿段に変更 する など 

コードベースの導⼊ 

© LayerX Inc. 13 コードベースの導⼊ - ケースの増⼤（アイスクリームコーンの状態） - ローコードツールから発⽣した課題 - 実⾏時間 - 最⻑13時間くらい - 休⽇を考慮したテスト期間の設計 - 実⾏回数あたりのコスト - 最⾼1087ケース - メンテナンスコスト - 7.47%（約80ケースに相当） 2023/07 ⼿動 ⼿動 × ローコード ⼿動 × ローコード × コードベース 2021/01 2021/04 2021/11 2022/04 2022/07 2024/11 

© LayerX Inc. 14 good / difficult コードベースの導⼊ 導⼊時 実⾏時間の短縮 運⽤時 difficult 近しいテストが書きやすい ‧1つの処理をまとめて関数として実装 することでやりたいことが明確になる good difficult テスト修正の難易度 ‧テストが失敗している箇所の特定か ら修正する最適解がわかりづらい テスト作ること⾃体が難しい ‧サンプルコードがないと書き始めら れない ‧動くものは書けても正解（メンテナ ンスしやすいコード）かがわからない テスト実⾏のコスト ‧コードベースと⽐較しテスト実⾏あ たりのコストが低減 

© LayerX Inc. 15 テストを書ける⼈に⾒てもらいながら⾃分でコードを書いてテスト作成を進める - 不明点の解決が早い - ナビゲーターの思考を学びながら整理できる - どのような⼿順でコードを書いていくと効率がよいか - なぜそのコードが必要‧不要だと思ったのか など コードベースの導⼊ テストの上達法1: ペアプロ こう書こう ドライバー ナビゲーター なんでそう書こうと思ったの？ 書き⽅がわからない こう書くといいよ 

© LayerX Inc. 16 コードベースの導⼊ テストの上達法2: ナレッジ共有 ⼣会等で共有し知識をつける取り組み（下記は特に繰り返し参照したもの） セルフチェックリスト レビュー依頼するまでの確認事項 linter / Prettierの確認, コメントの漏れ, 要素名/変数名/メソッド名の命名規則など レビュアーの⽬線が慣れるまではなにを気にしていいかが わからないのでまとまっていると便利 Githubの操作⽅法 Pull Requestを作成するまでの流れ 実際のコマンド など 誤った操作をしたくない気持ちが強い中で調べてもやり⽅ がたくさん出てくるのでまとまっていると便利 有⽤なサイトのリンク集 各種サイトの⼀覧 公式ドキュメント, ブログ記事 など コードを記載する上で詰まった部分に関する記事等を記載 しておくと同じようなところで詰まったときに⾒返せる 

© LayerX Inc. 17 コードベースの導⼊ テストの上達法3: 読書会 QAチームで週1回30分の読書会を実施 各⾃が読んできた感想‧疑問点を共有する会 基本的なコードを書くためのインプット ‧コードがどう書かれているのか ‧コメントはなにをどう残すのか など ⾃動テスト全体に関するインプット ‧⾃動テストの特徴や簡単な設計運⽤ ‧Unit Test, APIテスト, E2Eテストの違い など ⾃動テスト全体に関するインプット ‧⾃動テストに関する基本的な知識 ‧E2E⾃動テストの実践⽅法 など 

© LayerX Inc. 18 コードベースの導⼊ PR Review コードレビュー コードに対する懸念点やテスト, ページの要素指定の仕⽅ について指摘があればFBする機能 ⼈間では⾒つけにくい点や今後のテストの拡張性についても知ること ができ, レビュアーの確認前にケアレスミス等も⾒つけることが可能 copilot コード補完, chat機能 workspaceの情報からコードの補完やコードの説明や⾃ 動修正まで⾏ってくれる 1つ正解を作ってくれるかつ理解ができなければチャットで不明点を 解消するのに役⽴つ chatgpt 調査 実装したいことに対する疑問に対する調査 実装したいことに対する解決法を複数出してくれる テストの上達法4: AI活⽤ 

LayerXでのテスト⼿段の使い分け 

© LayerX Inc. 20 LayerXでのテスト⼿段の使い分け コードベースのテストを追加するにあたりテスト全体をデザイン QAチームが主に実装している箇所 - E2E Scenario Test - お客様の実現したいユースケースが機能し ていることの確認 - テストの実⾏時間が⻑くなるため厳選した テストのみを⾃動化 - API Test - バックエンドのAPIが設計通りに動作するこ とを確認 - 個別のAPIが正しい値を返すこと、複数の APIを組み合わせた際に正常動作することな どの検証 

© LayerX Inc. 21 テスト⼿段 テストの位置づけ その他 E2E ⼿動テスト 探索的テスト ‧⾃動化できていないスクリプトテスト ‧技術的に⾃動化が難しいテスト ローコード Autify ‧代表的なシナリオテスト ‧シナリオテストを機能に分割した  代表的なユースケースのテスト ‧コードベースに置き換えるのに  ⼀定ハードルがあるテスト ‧リリースしてまもない機能のテスト コードベース Playwright E2Eレイヤーより下のレベルで 担保したい画⾯を確認するテスト API コードベース runn ユースケースを機能に分割した 各機能の網羅的なシナリオテスト 画⾯での確認に⼿間を要するテスト LayerXでのテスト⼿段の使い分け テスト⼿段の使い分け 

© LayerX Inc. 22 LayerXでのテスト⼿段の使い分け - 探索的テスト - 機能性の確認 - ユーザビリティの確認 - 実現したいことに対する機能の使い勝⼿を確認 - 開発チーム全体での探索的テストの実施 主として⾏っているテスト その他 - ⾃動化できていないスクリプトテスト - 新機能テスト - リグレッションテスト - 技術的に⾃動化ができないテスト - バッチ処理を要する - 実⾏環境に依存する など ⼿動テスト 

© LayerX Inc. 23 LayerXでのテスト⼿段の使い分け 主として⾏っているテスト ローコード / E2Eコードベース その他 ローコード - コードベースに置き換えるのに⼀定ハードルが あるテスト - メール受信を要する - 他社のプロダクトを要する など - コードベースに置き換えできていないテスト - リリースしてまもない機能のテスト - 特にUIの変更が⾒込まれている E2Eコードベース - E2Eレイヤーより下のレベルで担保したい画⾯を 確認するテスト - 画⾯単位で確認すべきテスト(≠シナリオ単位） - APIレスポンスをmockする形でも実装できるが現状はE2Eテス トとして部分的にカバーしている - リグレッションテスト - 代表的なシナリオテスト - ユーザーの⼀連の操作を確認する - シナリオテストを機能に分割した 代表的なユースケースのテスト - 1つの機能に着⽬した代表的なユース ケースを確認 - 各機能の中でユーザーがもっとも操作‧⼊⼒す る⽅法でテストを実装する 

© LayerX Inc. 24 - 画⾯での確認に⼿間を要するテスト - ファイルを出⼒しないと確認できないテスト - 確認項⽬が多量で⽬検では 正しく判断できないようなテスト - 認証‧認可 - 権限数 ✕ 機能数の組み合わせ - 画⾯からは確認できないバックエンド のバリデーション確認 LayerXでのテスト⼿段の使い分け - リグレッションテスト - 機能をAPI単位で分割した網羅的なテ スト - API単体‧組み合わせの中で⼊⼒パ ターンを網羅したテスト 主として⾏っているテスト その他 APIテスト 

© LayerX Inc. 25 テスト実装の例 シナリオ: 経理担当者が請求書データを作成し、ファイルを出⼒する 請求書データの作成 ファイル出⼒ 請求書仕訳 E2Eテスト: Playwright 代表的な1番シンプルなパターンで 疎通確認を⾏うテスト E2Eテスト: Playwright 1機能に注⽬したテスト ユースケースとして代表的なテストケース APIテスト: runn E2Eテストでは不⼗分なデータパターンでの 網羅的なテスト APIテスト: runn 出⼒されるデータの整合性を確認するテスト ⼿動テスト 機能改修や影響範囲にあたる場合は探索的テスト ⼀部⾃動化できていない部分は⼿動テスト E2Eテスト: Autify メール受信が発⽣するテスト 主要な テスト その他 

おわりに 

© LayerX Inc. 27 まとめ 今回は事例紹介としてテスト⼿段をローコード, コードベースと拡充させる中での課題‧⼯夫と 現在のLayerXでのテスト⼿段の使い分けについて紹介しました。 テスト実装を進める中でテスト全体の⾒直しも合わせて⾏ってきましたが、現状から更にアップデートす べき場所はたくさんあります。新機能テストも⾃動テストとして継続的な保証ができるようにしたい部分 があったり、よりテストピラミッドの下位のレイヤーで担保できるようなやり⽅を考えてテスト全体を最 適化していきたいと個⼈的に思っています。 おわりに