22.12.3 ソフトウェアテスト自動化カンファレンス登壇資料
mablを活用した自動化の複数人での取り組み
View Slide
トピックス1 自己紹介と会社紹介2 メインターゲット3 mablとは4 取り組み時に決めたこと5 実際取り入れてみてどうだったか6 今後の展望
自己紹介塩濱 優 / shiohama yu@hcmn_hama2019年にhacomono入社入社~2年間はプロダクト側の開発エンジニアとして改善や新機能開発をしておりました。現在はQAチーム全体の管理や自動化をメインで担当しています。元々QAエンジニアは正社員私1人だったところから現在では3名になり、業務委託合わせると12名のチームになりました 🎉
会社紹介店舗ビジネスの未来を変える会員管理・予約・決済システムフィットネス・スクール向けのバーティカル SaaSとして、日本の社会課題解決、業界マーケットサイズ拡大に挑戦しています。
メインターゲットこれから自動化を開始しようとしている方1人で自動化をしていたが複数名で取り組み開始したいと考えている方ローコード自動化サービスを開始し始めたばかりの方
mablとは・E2Eテスト自動化ソリューション・非エンジニアでも簡単にテストが作成できる・また、エンジニアも使用しやすいUIで、変数管理も可能 複雑なケースにも対応しやすい・CI/CDに結合して、 開発プロセスに組み込むこともできる
取り組み時に決めたこと複数人で実装していくということを視野に入れてガイドラインを作成する
ガイドライン① -コーディング規則コーディング規則を定義し、どのように実装されるべきかを定め自動化していく上での「品質」「保守のしやすさ」の確保を大切にしました。
ガイドライン① -コーディング規則コーディング規則命名規則を定めていく
コーディング規則flowどの工程(操作)を行うのかbranchどこで作業をするかtestどのシナリオのテストなのか
コーディング規則branchどこで作業をするか(シナリオ分類)_(テストケースNo)_(パターンNo)_氏名例) TJ01_01_A_hama
コーディング規則testどのシナリオのテストなのか(シナリオ分類)_(テストケースNo)_(パターンNo)_テストケースタイトル(サブタイトル)例) TJ01_01_A_会員登録導線(仮登録ステータスをSkipする)
コーディング規則flowどの工程(操作)を行うのかtestどのシナリオのテストなのかbranchどこで作業をするか何がどのシナリオに入っているのかを目視しやすいことを目的とした
コーディング規則flowどの工程(操作)を行うのかPrefixをつけるページ内動作の場合、そのページでのみ実行可能なフローであることを明確化するため、【サイト名】もしくは【サイト名/ページ名】を記載します。例1) 【管理サイト】【予約サイト/マイページ】例2) 【管理サイト/メンバー詳細/プラン/プラン一覧】
コーディング規則flowどの工程(操作)を行うのか名称は○○する, ○○かどうか確認するといったシンプルな形にするフロー名に含まれるページ名称 .. 「...」で括るフロー名に含まれるページ内文言 .. "..."で括る例) 【予約サイト/マイページ】「所持チケット」へ遷移する
コーディング規則testどのシナリオのテストなのかbranchどこで作業をするかflow作成の重複を防ぐことを目的としたflowどの工程(操作)を行うのか
コーディング規則 すでにどのflowが用意されているかを目視しやすくなりました
ガイドライン② -ルール何を元に自動化の実装をしていくのか
ガイドライン② -ルールリグレッションテスト
リグレッションテストと自動化の関係性 テスト管理ツールQaseスプレッドシートマスタ情報テストケース 自動化ケース内容を実装同じ状態を保つ自動化済/未の状態を反映
ガイドライン②-ルール自動化できないパターンのルール決め
ガイドライン②-ルールどうしても自動化できない/難しい手順やシナリオはある
ガイドライン②-ルール テストケース(スプレッドシート) テスト管理ツール(Qase) xxxの表示確認✅ [手動]xxxの表示確認自動化できなかった部分だけを抜き出す
ガイドライン③ - レビューフローレビューフローを定めました
ガイドライン③ - レビューフローアサイン~実装誰がどのケースを担当するかを管理 ブランチの作成実装レビュー~マージレビュー依頼を出す コーディング規則のチェックコンフリクトの解消
実際取り入れてみてどうだったか良かった点
実際取り入れてみてどうだったか 良かった点 💮・ガイドラインがあることによって、スムーズにオンボーディングが進む・誰が参加しても同じ状態を保ちながら、実装を増やしていける・メンテナンスがしやすくなる・エンジニア、非エンジニアともに同様の実装方法になる・他に良い取り組み事例があった場合に、置き換えやすい
実際取り入れてみてどうだったか改善したい点
実際取り入れてみてどうだったか 改善したい点・コーディング規則があるとはいえ、間違うことは誰にでもある。 一定のメンテナンス時間は確保したい。・機能のアップデートに合わせて期待値を変えないといけない場合がある 機能のキャッチアップを効率よくできる仕組みを用意が必要・テストの実行時間や自動化に対する分析も行っていきたい
今後の展望・目下は、リグレッションテストの自動化をしていくが、機能リリース時に初めからmablで実装もしていきたい。・まだチャレンジできていない分野も進めていきたい。(APIテストにも着手したい)・一緒に自動化を推進してくださる方の採用頑張る
最後にもっと良い取り組み方あるよ!などなど何かあれば、お気軽にTwitterでもご連絡ください @hcmn_hama