こんにちは！ソウゾウのQA enginnerの@daisukeです。「メルカリShops [フライング] アドベントカレンダー2022」の12日目を担当します。

今回はタイトルにある通り、Cypressを触ったことがない初心者が入社４ヶ月でe2e自動テストのカバレッジを40%も上げることができたのか、をお話しします。

プログラミングが未経験、またはプログラミングに抵抗感を持っているQAエンジニアは沢山いるかと思います。そんな方でもブログを読み終わる頃には「自動テストってそんなに難しくないかも」と少しでも感じてもらえればと思います。

入社前の状況

まずは私daisukeの経歴を簡単に紹介します。
2011年からQAエンジニアとして主に組み込み系のテスト業務に従事しています。
工数管理、メンバーアサイン、課題解決、テスト実施、テスト設計の一通り経験済みです。
ちなみに自動テストの実装経験はありません。

ソウゾウの自動テストの状況についてですが、Cypressを使用してe2e自動テストを実装しています。
基本機能は一通り実装されていましたが、カバレッジ指標がないため自動テストとして充足しているか分からない状況でした。

入社後3ヶ月でやったこと

モブプログラミングで学んだCypress Tips
毎週水曜日にQAチーム内で自動テストのモブプログラミングを実施しています。
この時間を利用して環境構築やCypressの基本構文を有識者の教えのもと身につけていきました。

ここで学んだことを一部抜粋して紹介します。

ユーザー操作の流れをそのまま実装します。
自動テストはユーザー操作の流れをコードにしただけなので
構文さえ理解できれば流れはイメージしやすいと感じました。

例としてyahooで検索する時のケースを記載します。
手動で実行する場合は下記の１〜３の手順になります。

URLを指定してアクセス
検索ボックスにキーワードを入力
検索ボタンをクリック

次にCypressで実装する場合は下記のようなコードになります。

// https://www.yahoo.co.jp/にアクセスする
cy.visit('https://www.yahoo.co.jp/');

// 検索ボックスに'あいうえお'を入力する
cy.get('[type=”search]”]').type('あいうえお');

// 検索ボタンをクリックする
cy.get('[type=”submit”]').click();

visit(),get(), should(), type(), click()だけでテストは動く
Cypressに限らずe2eの自動テストを書くときはIDやClass、HTML要素を指定する必要があります。get(), should(), type(), click()はその要素を取得、検証、入力、クリックする関数になります。実際にユーザーが操作する流れをイメージすると分かりやすいかと思います。

＜サンプルコード＞

// #idの要素を取得してクリックする
cy.get('#id').click();

// textの要素が表示されているか検証する
cy.get('text').should('be.visible');

// inputの要素に'あいうえお'を入力する
cy.get('input').type('あいうえお');

// https://www.yahoo.co.jp/にアクセスする
cy.visit('https://www.yahoo.co.jp/');

＜参考URL＞
https://docs.cypress.io/api/commands/visit
https://docs.cypress.io/api/commands/get#Alias
https://docs.cypress.io/api/commands/should
https://docs.cypress.io/api/commands/type
https://docs.cypress.io/api/commands/click

テスト用のdata属性を要素につける。
画面内で一意のdata属性をつけることで要素をターゲットし易くなります。
data属性はIDのように使わず、UIコンポーネントに振ることで、メンテナンスのコストを下げることができます。例えばモーダルにdata属性を付けておくと、モーダル内の要素が増えた場合に新たにdata属性を付け直す必要はありません。
下記例のTab内のdata-testid=”modal”がその例です。

UIコンポーネント毎にdata属性の命名規則を共通化しておくとテストコードの可読性が上がります。モーダルの振る舞いを期待するコンポーネントであればdata-testid=”modal”で共通化することでテストコードの保守性が改善されます。例えばプロダクトコード側のリファクタリングでIDが変更されたとしてもテストが壊れることはありません。
下記のcy.get(‘[data-testid=”modal”]’).click();のようにdata属性を指定することで
コンポーネントのIDが変更されたとしても要素を取得できるようになります。

＜書き方の例＞

// Tabにdata-testid="modal"を追加する
<Tab
    fontSize="small"
    Click={{} => Status !== 'open'}
    data-testid="modal"
>

// data-testid="modal"の要素を取得してクリックする
cy.get('[data-testid="modal"]').click();

＜参考URL＞
https://docs.cypress.io/guides/references/best-practices#Selecting-Elements

実際に対応したこと

既存のテストケースのリファクタリングを行いました。
現存するテストケースには不安定なものが多数あったため、ひたすらリファクタリングを行いエラーの解消に集中していました。この作業で既存のテストコードがどのように書かれているか理解を深めることができました。

既存テストケースのリファクタリングに慣れてきたら、次は新規のテストケースを実装します。
この時点ではコードの構造がなんとなく理解できるようになってきたので、簡単なテストケースであれば苦労せず実装をすることができるようになりました。

上記を繰り返すことで自然とCypressの実装に慣れていき、入社3ヶ月ほどで一から実装することができるようになりました。（他にも学んだことはありますが今回は省きます）
特に今回モブプログラミングの時間をいただけたことで疑問を残すことなくコーディングの知識を身につけることができたかと思います。

次にカバレッジを定義しました。
入社直後のソウゾウのe2eテストはカバレッジが定義されておらず、とりあえずユーザーが操作するであろうシナリオをテストケースに起こしている、という状態のため定量的に品質を図ることができませんでした。また、主要な機能を持った一部の画面はテストしているがそれ以外の画面のテストケースがないことがわかり、この状況をQAチーム内で話し合った結果、”画面単位の通過率”をカバレッジと定義することとなりました。
カバレッジ定義後に実際どれほどのカバレッジなのかを計測したところ約半分の48%であることがわかりました。つまり全画面のうち半分の画面がテストケースがない状態です。
ここからテストケースのない画面の実装を進めていくことになりました。

入社4ヶ月後どうなったのか？

入社３ヶ月で学んだことを活かして、その後１ヶ月はカバレッジを上げるためにテスト実装に注力していました。以下の３つがその成果となります。

一つ目はカバレッジが48%→88%に上がりました。
最初の3ヶ月間でCypressの基礎を徹底的に叩き込んだことで自分の中で実装パターンが出来上がり、コーディングスピードが格段に向上しました。
それゆえ1ヶ月でカバレッジを40%も向上させることができました。

二つ目は実装をcommandで共通化し、コード量を削減しました。
各画面で共通している処理をcommand呼び出しにすることで複数行書いていた処理を１行で呼び出すようにリファクタリングしました。一つのテストケースに記述するコード量が減ったためコードが見やすくなりました。

三つ目は自動テスト実装作業をメインで任されるようになりました。
自動テスト未経験でありながらこんな短期間で任せてもらえるとは思っていなかったので責任も感じますが、認めてもらえて嬉しいという気持ちを一番強く感じています。
まずは全画面のテストケースの実装と定期実行の安定化を目指そうと思います。

今後の課題

テストケースのカバレッジ自体は40%上昇して全体で88%のカバレッジとなりました。
ただ、テスト実行するとPass率は50%ほどが現在の状況です。これはレイアウトの変更を伴うリリースが度々あったことが主な要因です。これにより今までpassしていた複数のテストケースがfailになりました。まずはこのPass率を100%に上げることを優先的に進めていきます。
そしてレイアウト変更が入ったとしても同時にテストケースがリファクタリングできるようリリースプロセスを改善していきます。
また、メルカリShopsでは新機能が続々リリースされているため画面も増え続けています。それゆえ新規画面のテストケースの実装も必要になります。
これらは一人でできないことはないですが、時間がかかりすぎるため他のQAメンバーだけではなく開発メンバーも巻き込んで課題解決に取り組んでいきます。

まとめ

自分がCypressを触った感想として実装はとてもシンプルだなと思いました。
そのため最低限のノウハウさえ身につけてしまえば、初心者でもテストケースの実装は十分可能です。
もちろん有識者メンバーがいたことや周りのメンバーが協力的だったことが短期間で成長できた大きな要因ではあります。ただこのブログにも書いたように最も大事なことはコツを掴むことだったと思います。
最小パターンのテストケースを一つ作ることができれば、あとはそれを拡大していくだけです。
これはCypressに限定した話ではなくSeleniumなど他のツールでも同じかと思います。
ぜひこの機会に自動テストに一歩踏み出してみてはいかがでしょうか。
このブログが少しでも自動テストの実装に悩まれている方や足踏みされている方の参考になれば幸いです。

さいごに

株式会社ソウゾウではメンバーを大募集中です。メルカリShopsの開発やソウゾウに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。
Software Engineer
Software Engineer, Site Reliability
Software Engineer (Internship) – Mercari Group （※新卒採用に応募するにはまずインターンへの参加をお願いしています。）
またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちら の申し込みフォームよりぜひご連絡ください！