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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text