Copyrights(c) Henry, Inc. All rights reserved. ローコード自動テストを 1ヶ月半で導入した話

Copyrights(c) Henry, Inc. All rights reserved. 自己紹介 @sumiren_t （発音：アルファベット読み） 仕事 ● アーキテクト @ CIer ● フルスタックエンジニア / SET @ Henry（フリーランス/副業） 強み ● フルスタックエンジニア / アーキテクト (Next.js, Node.js, AWS) ● 品質エンジニアリング ● PM / マネージャ経験

Copyrights(c) Henry, Inc. All rights reserved. スコープ 話す ● ローコード自動テストの導入プロセス ○ SaaSスタートアップ、テスターの方による自動テスト 話さない ● ツールの選定 ● 導入後の運用 ● 技術的詳細 ● etc…

Copyrights(c) Henry, Inc. All rights reserved. アジェンダ ● 導入の背景 ● 導入プロセス ● 導入で工夫したポイント

Copyrights(c) Henry, Inc. All rights reserved. アジェンダ ● 導入の背景 ● 導入プロセス ● 導入で工夫したポイント

Copyrights(c) Henry, Inc. All rights reserved. Henryのリリースプロセスと受入テスト 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース

Copyrights(c) Henry, Inc. All rights reserved. 受入テストに課題がある 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース テスターの方が手動でリグレッションテスト ● バグが見つかると手戻り大 ● カバレッジも限界あり

Copyrights(c) Henry, Inc. All rights reserved. ローコード自動テストで解決する 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース ローコード自動テストを作成 / 実行 バグを早期に摘出することで、手戻り減 自動テストのためカバレッジも向上しやすい ローコードなのでテスターの方ができる 手動でしかできないテストをやっていく

Copyrights(c) Henry, Inc. All rights reserved. Henryの自動テストモデルにおける位置づけ テストピラミッドを採用している。 今回の自動テストは E2Eレベルのテス トにあたるため、作りすぎないことを意 識

Copyrights(c) Henry, Inc. All rights reserved. アジェンダ ● 導入の背景 ● 導入プロセス ● 導入で工夫したポイント

Copyrights(c) Henry, Inc. All rights reserved. スケジュール ユーザーが非エンジニア（テスター）であることを踏まえたスケジュールを作成した。 以降のスライドで、時系列でタスク内容を説明する。

Copyrights(c) Henry, Inc. All rights reserved. 1：キックオフ エンジニア、経営、テスター含め、関係者を全員招集して実施した。 アジェンダは以下。 ● プロジェクトの目的 ● ローコード自動テストツール（mabl）の説明 ○ ツール概要、かんたんなデモ、心構え ● プロジェクト計画 ○ ゴール、プロジェクトリスク、スケジュール、体制

Copyrights(c) Henry, Inc. All rights reserved. 2：テストシナリオ洗い出し テスターの方と協力し、既存リグレッションテストを踏まえてテストケースを設計した。 【イメージ】

Copyrights(c) Henry, Inc. All rights reserved. 3〜4：素振り / 課題つぶし 主要なシナリオをmablで作れそうか一通り検証した。 テスタビリティが低い場合は対処する。 mablで作れそうか 一通り検証 技術的に難しいシナリオは、 ● アプリ改修 ● 手動に倒す ● JSスニペットを作っておく ● 運用で回避（Wiki）

Copyrights(c) Henry, Inc. All rights reserved. 5：オンボーディング テスターの方、フロントエンドエンジニア向けに1.5時間のハンズオンを実施。 … 【トレーニングメニューのイメージ】 …

Copyrights(c) Henry, Inc. All rights reserved. 6：テスト作成 テスターの方にてテスト作成を進めていただく。 詰まったときにフォローしたり、導入中は作成してもらったテストをレビューして品質担保。

Copyrights(c) Henry, Inc. All rights reserved. 7：ツール導入の判断 ここまでくれば、導入の判断ができる。 全てのテストケースを作成することは難しく、定量的な判断も難しい。 「やれそうか」というユーザーの直感で決めてしまうのがおすすめ。

Copyrights(c) Henry, Inc. All rights reserved. 8：運用設計 テストを作り切ることより、運用が回っている状態を作ることを優先する。 仕様に追従してテストを作成/修正している、パスすることを確認してリリースできている、etc 導入がテーマのため詳細は割愛するが、以下のようなことを定めるとよい。 ● 運用体制 ● Planと環境の構成 ● テスト作成/修正フロー（開発プロセスの定義があれば、そちらに書いても良い） ● ブランチ構成 ● テストの実行タイミングと実行方法

Copyrights(c) Henry, Inc. All rights reserved. アジェンダ ● 導入の背景 ● 導入プロセス ● 導入で工夫したポイント

Copyrights(c) Henry, Inc. All rights reserved. 導入で工夫したポイント 特に工夫した点を3点紹介します。 1. テストシナリオを先に洗い出す 2. 先回りしてテスタビリティを担保する 3. ナレッジベース

Copyrights(c) Henry, Inc. All rights reserved. 1：テストシナリオを先に洗い出す ● テストの全体感や削減すべきテストを見える化したり、テストシナリオの作成進捗などを管理できる。 どのあたりに技術的な課題が出そうかの見当もつけやすくなる ● テスト仕様書のように細かな手順を書かない。 Whatに集中する 価値の低い テストケースは まずは削減 コスパ悪いものは 無理に自動化しない 導入時の 進捗も管理できる 手順まで書かない 全体感が大事

Copyrights(c) Henry, Inc. All rights reserved. 2：先回りしてテスタビリティを担保する ● 利用者が非エンジニアの場合、効率が大きく低下する懸念や、苦手意識が生まれてしまい導入中断になる懸念がある。 ● そのため、先行してSET側で難しそうなシナリオは一通り検証し、テストが難しい部分は対策をする。 ○ アプリ改修、手動に倒す、JSスニペット作っておく、Wikiに書いておく

Copyrights(c) Henry, Inc. All rights reserved. 3：ナレッジベース ● 組織特有の考慮事項やQ&AをまとめるWikiを用意し、課題を自己解決してもらえるように努める ○ 開発（テスタビリティ）に関する考慮事項もまとめられるとよい ● 徐々にテスターの方がメンテナンスしていく文化を作っていけるように

Copyrights(c) Henry, Inc. All rights reserved. まとめ 1. 導入の目的を明確化する 2. スケジュールを引いてから進める 3. 自分がいなくても回るようにする