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

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide