エムスリーエンジニアリンググループ QAチームの城本です。BIRでアンケートシステムのQAを担当しています。最近E2Eの自動テストを導入した際に、フレームワークの選定や作成後の運用で考えたことを紹介します。
E2E自動テスト導入の動機
今回E2Eテストの導入対象としたのは、ここ一年くらいで開発からサービスインに至ったアンケートシステムです。システムの仕組みはこちらの記事でも紹介されてますので、よかったらご覧ください。
www.m3tech.blog
当初このシステムに対しては、UIを変更する可能性も大きかったため修正コストの方がかさむと考えE2Eテストは導入していませんでした。サービスインしてしばらくすると、安定的に稼働し始めたこと、機能追加も回り始めたこともあって、E2E自動化の検討を始めました。
小さく始めることにし、E2E自動化の対象は以下2点をカバーすることとしました。
- アンケートの回答画面で必須回答項目が回答された状態で回答の提出ができること
- ありえそうな回答ミスをした際に正しく回答できないこと
失敗したときに特にリスクの高いところを選んでいます。
なぜQA Wolfを選んだのか
有償ツールも含めて調べた結果、QA Wolfというフレームワークを導入しました。
www.qawolf.com
QA Wolfを選んだ理由は次の通りです。
- OSS かつ環境構築が容易(QA Wolf は Node.js のモジュールとして提供されており、モジュール内で全ての依存性が解決されているため導入が容易である)
- ブラウザ上のオペレーションをレコードし、テストコードのボイラープレートとして生成可能(実際のテストコードとしては手を加える必要があるが、ブラウザオペレーションをそのままコード化できるためソフトウェアエンジニアでなくてもオペレーションのコード化が可能)
- 実際のテスト実施に採用されているライブラリの信頼性が高い( テストコードとしては Jest と Playwright のみに依存しており、ともに採用実績・信頼性が高く見込まれる)
- 使用しているCIツール(GitLab)をサポートしている
- オペレーション実行を適切に待機してくれる(従来の E2E テストコードでは手動で適宜やるしかなかったイベント発火の待機を自動的に行ってくれる、待機時間の調整や明示的な記述も可能)
当初私が選定に手間取っていたところ、開発チームのメンバーがいいものを選んできてくれました! 感謝!
選定した当時(2020年3月くらい)からQA Wolfがバージョンアップしたため、当時生成したコードと現行で記録されるものとは細かい差分が出てますが、今も特に問題なく動作しています。
使い方
インストール
Node.jsがインストールされていない場合は、事前にインストールが必要です。 テストを記録するディレクトリを作成して、コマンドラインから下記を実行します。
npm init qawolf
インストールに成功していると howl
コマンドで吠えてくれます。かわいい。
テストのレコーディング
以下の通りテスト対象のURLとテストケース名を指定して実行すると、ブラウザが起動するのでそこで操作を一通り実行します。サンプルとして簡単に、Googleで当社のテックブログを検索してみます。
npx qawolf create https://www.google.com/?hl=ja search_m3blog
実行し終わったら、コマンドラインに戻り、Save and Exit
を選択します。
これで .qawolf
フォルダの配下にテストケースとセレクタが保存されます。
.qawolf ├─selectors │ search_m3blog.json │ └─tests search_m3blog.test.js
tests/search_m3blog.test.js
の方に、セレクタとそれに対してどのようなアクションをするかが記述されています。セレクタの定義は selectors/search_m3blog.json
に保存されます。
search_m3blog.test.js
を見てみます。
const { launch } = require("qawolf"); const selectors = require("../selectors/search_m3blog"); describe('search_m3blog', () => { let browser; beforeAll(async () => { browser = await launch({ url: "https://www.google.com/?hl=ja" }); }); afterAll(() => browser.close()); it('can type into "q" input', async () => { await browser.type(selectors[0], "em"); }); it("can Enter", async () => { await browser.type(selectors[1], "↓Enter↑Enter"); }); it('can click " www.m3tech.blog" link', async () => { await browser.click(selectors[2]); }); it("can type into body", async () => { await browser.type(selectors[3], "↓AltLeft"); }); });
レコーディング時にブラウザ上で行った操作が記録されています。この例で行った操作にはありませんが、タイプミスやTabキーでの操作があればそれらも含まれます。
テストの実行
QA Wolfは現時点では、レコーディング時に全角文字を入力しても記録されないので、日本語入力が必要な個所は後からテストコードを修正しています。*1 先ほど記録したテストコードの次の部分ですが、記録時点では「em」と入力した後、半角から全角に直して「エムスリー テックブログ」と入力していました。しかし、全角入力した部分は記録されていません。
it('can type into "q" input', async () => { await browser.type(selectors[0], "em"); });
修正してから下記のコマンドで実行します
npx qawolf test search_m3blog
コマンド2つとレコーディングだけで、簡単なものだと実行できるようになるので最初のステップのハードルが低く楽です。
テストコードとするために必要な対応
レコーディングしただけでは、テストとして運用に回すためには不十分な個所があるので追加で対応します。
- 日本語入力
- アサーションの追加
- テストコードの可読性アップ(何を意図したものなのかコメントを付け加えたり、コードとして整えたり)
運用
QAには開発のバックグラウンドがないメンバーもいるため、現時点ではチーム内では次の通り役割分担をしています。
<QA担当>
- 必要なテストシナリオを選定
- レコーディング
- コメントにテストケースの意図を記載
<ソフトウェアエンジニア>
- アサーションの追加
- テストコードの可読性のアップ
- CI環境の整備
- テスト対象システム側のコードの改修
- 例:記述された DOM の定義が複数存在し得る場合は、必ず当てはまる DOM のうち1つ目のものが指定されるので、2つの DOM を区別するためuniqueな値を付与する
テストコードの安定性を上げるために、必要があればテスト対象のコードにも手を加えてくれる協力体制が取れているのはQAチームとしてすごくやりやすい点です。
使ってみてよかった点
自動テスト導入で良かった点としては、導入の動機であげた下記のケースが必ずカバーされるようになり、リリース時に安心感が持てるようになったことです。
- アンケートの回答画面で必須回答項目が回答された状態で回答の提出ができること
- ありえそうな回答ミスをした際に正しく回答できないこと
QA Wolfを使っていてよい点は、次の2点が大きいと感じています。
- 導入が楽
- 安定性が高い(体感ですが、原因不明で失敗していることは少ないと思います)
他のシステムのE2EテストでSeleniumを使っていますが、特にこの2点は差が大きいです。
一方運用としては、テストケースの追加やメンテナンスは手が空いたときとなりがちなので、こちらの体制はこれから整えていくところです。
We Are Hiring!
QAチームではバグを見つけるだけでなく顧客の利益にコミットしたい人、社内勉強会等を通じて共に成長したい人を募集しています!
社会に役立つシステムを高品質で素早く届けたいQAエンジニアの方、一緒に働きませんか? カジュアル面談でより詳しくお話ししましょう!
jobs.m3.com
*1:環境によっては日本語で入力した部分も日本語で記録されるようです。試した範囲では、Windows10では日本語入力部分は記録されませんでした。Mac(USキーボード)の日本語モードでは「emusuri- tekkuburogu」と記録されていました。