ローコード自動テストを1ヶ月半で導入した話

こちらのイベントで発表した内容になります！
https://henry.connpass.com/event/275428/

ローコード自動テストツールを3回ほど導入した経験があり、スムーズにできるようになってきたので知見をシェアします。
真似していただければ、すぐに導入を始められます！

Transcript

1. Copyrights(c) Henry, Inc. All rights reserved. ローコード自動テストを 1ヶ月半で導入した話
2. Copyrights(c) Henry, Inc. All rights reserved. 自己紹介 @sumiren_t （発音：アルファベット読み） 仕事 • アーキテクト @ CIer • フルスタックエンジニア / SET @ Henry（フリーランス/副業） 強み • フルスタックエンジニア / アーキテクト (Next.js, Node.js, AWS) • 品質エンジニアリング • PM / マネージャ経験
3. Copyrights(c) Henry, Inc. All rights reserved. スコープ 話す • ローコード自動テストの導入プロセス ◦ SaaSスタートアップ、テスターの方による自動テスト 話さない • ツールの選定 • 導入後の運用 • 技術的詳細 • etc…
4. Copyrights(c) Henry, Inc. All rights reserved. アジェンダ • 導入の背景 • 導入プロセス • 導入で工夫したポイント
5. Copyrights(c) Henry, Inc. All rights reserved. アジェンダ • 導入の背景 • 導入プロセス • 導入で工夫したポイント
6. Copyrights(c) Henry, Inc. All rights reserved. Henryのリリースプロセスと受入テスト 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース
7. Copyrights(c) Henry, Inc. All rights reserved. 受入テストに課題がある 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース テスターの方が手動でリグレッションテスト • バグが見つかると手戻り大 • カバレッジも限界あり
8. Copyrights(c) Henry, Inc. All rights reserved. ローコード自動テストで解決する 環境 \ 曜日 金 月 火 水 木 Dev環境 QA環境 Prod環境 シームレスに開発 / デプロイ デプロイ 受入テスト リリース ローコード自動テストを作成 / 実行 バグを早期に摘出することで、手戻り減 自動テストのためカバレッジも向上しやすい ローコードなのでテスターの方ができる 手動でしかできないテストをやっていく
9. Copyrights(c) Henry, Inc. All rights reserved. Henryの自動テストモデルにおける位置づけ テストピラミッドを採用している。 今回の自動テストは E2Eレベルのテス トにあたるため、作りすぎないことを意 識
10. Copyrights(c) Henry, Inc. All rights reserved. アジェンダ • 導入の背景 • 導入プロセス • 導入で工夫したポイント
11. Copyrights(c) Henry, Inc. All rights reserved. スケジュール ユーザーが非エンジニア（テスター）であることを踏まえたスケジュールを作成した。 以降のスライドで、時系列でタスク内容を説明する。
12. Copyrights(c) Henry, Inc. All rights reserved. 1：キックオフ エンジニア、経営、テスター含め、関係者を全員招集して実施した。 アジェンダは以下。 • プロジェクトの目的 • ローコード自動テストツール（mabl）の説明 ◦ ツール概要、かんたんなデモ、心構え • プロジェクト計画 ◦ ゴール、プロジェクトリスク、スケジュール、体制
13. Copyrights(c) Henry, Inc. All rights reserved. 2：テストシナリオ洗い出し テスターの方と協力し、既存リグレッションテストを踏まえてテストケースを設計した。 【イメージ】
14. Copyrights(c) Henry, Inc. All rights reserved. 3〜4：素振り / 課題つぶし 主要なシナリオをmablで作れそうか一通り検証した。 テスタビリティが低い場合は対処する。 mablで作れそうか 一通り検証 技術的に難しいシナリオは、 • アプリ改修 • 手動に倒す • JSスニペットを作っておく • 運用で回避（Wiki）
15. Copyrights(c) Henry, Inc. All rights reserved. 5：オンボーディング テスターの方、フロントエンドエンジニア向けに1.5時間のハンズオンを実施。 … 【トレーニングメニューのイメージ】 …
16. Copyrights(c) Henry, Inc. All rights reserved. 6：テスト作成 テスターの方にてテスト作成を進めていただく。 詰まったときにフォローしたり、導入中は作成してもらったテストをレビューして品質担保。
17. Copyrights(c) Henry, Inc. All rights reserved. 7：ツール導入の判断 ここまでくれば、導入の判断ができる。 全てのテストケースを作成することは難しく、定量的な判断も難しい。 「やれそうか」というユーザーの直感で決めてしまうのがおすすめ。
18. Copyrights(c) Henry, Inc. All rights reserved. 8：運用設計 テストを作り切ることより、運用が回っている状態を作ることを優先する。 仕様に追従してテストを作成/修正している、パスすることを確認してリリースできている、etc 導入がテーマのため詳細は割愛するが、以下のようなことを定めるとよい。 • 運用体制 • Planと環境の構成 • テスト作成/修正フロー（開発プロセスの定義があれば、そちらに書いても良い） • ブランチ構成 • テストの実行タイミングと実行方法
19. Copyrights(c) Henry, Inc. All rights reserved. アジェンダ • 導入の背景 • 導入プロセス • 導入で工夫したポイント
20. Copyrights(c) Henry, Inc. All rights reserved. 導入で工夫したポイント 特に工夫した点を3点紹介します。 1. テストシナリオを先に洗い出す 2. 先回りしてテスタビリティを担保する 3. ナレッジベース
21. Copyrights(c) Henry, Inc. All rights reserved. 1：テストシナリオを先に洗い出す • テストの全体感や削減すべきテストを見える化したり、テストシナリオの作成進捗などを管理できる。 どのあたりに技術的な課題が出そうかの見当もつけやすくなる • テスト仕様書のように細かな手順を書かない。 Whatに集中する 価値の低い テストケースは まずは削減 コスパ悪いものは 無理に自動化しない 導入時の 進捗も管理できる 手順まで書かない 全体感が大事
22. Copyrights(c) Henry, Inc. All rights reserved. 2：先回りしてテスタビリティを担保する • 利用者が非エンジニアの場合、効率が大きく低下する懸念や、苦手意識が生まれてしまい導入中断になる懸念がある。 • そのため、先行してSET側で難しそうなシナリオは一通り検証し、テストが難しい部分は対策をする。 ◦ アプリ改修、手動に倒す、JSスニペット作っておく、Wikiに書いておく
23. Copyrights(c) Henry, Inc. All rights reserved. 3：ナレッジベース • 組織特有の考慮事項やQ&AをまとめるWikiを用意し、課題を自己解決してもらえるように努める ◦ 開発（テスタビリティ）に関する考慮事項もまとめられるとよい • 徐々にテスターの方がメンテナンスしていく文化を作っていけるように
24. Copyrights(c) Henry, Inc. All rights reserved. まとめ 1. 導入の目的を明確化する 2. スケジュールを引いてから進める 3. 自分がいなくても回るようにする