QAチームの自動テスト推進 〜自動テストの開発編〜

  • このエントリーをはてなブックマークに追加
  • Pocket

こんにちは。
サーバーサイドエンジニア兼QAエンジニアの福山です。

QAチームでは、生産性高く、高品質なサービスを安定して提供するために
テスト自動化基盤の構築を進めてきました。

  1. 自動テストのツール選定
  2. 自動テストの開発
  3. 自動テストの運用

の3本立てで、前回、自動テストのツール選定についての記事を書かせていただきました。
QAチームの自動テスト推進 〜自動テストのツール選定編〜

自動テストのツール選定の結果、弊社では、Buckyを使うことに決定しました。

本日は、2. 自動テストの開発についてです。
以下の流れで説明します。

① システム構成
② ローカルの環境構築
③ リンクチェックの実装
④ E2Eで重要コンテンツの存在チェックの実装

Buckyの開発は、こちらの記事(自動テストフレームワーク「Bucky」入門)を参考に進めました。

① システム構成

現状のアーキテクチャは上の図の通りです。
QAサーバーにBucky-coreとBucky-managementをインストールし、
Jenkinsからテスト実行コマンドのシェルを叩き、STG環境/DEV環境へスクレイピングして、
エラーがあれば、slackに通知する、というシステムを構築しました。

日次でSTG環境で継続的に自動テストを実行することで、
自動テストでエラーが出れば、リリース前に、すぐに見つけられるようになりました!!

その構築と実装を②〜④で説明します。

② ローカルの環境構築

ローカルには、bucky-core 配下の .sampleフォルダとdocker上のファイルが同期されます。

③ リンクチェックの実装

テストコードを追加します。
以下に記載の例では1つのファイルに1つのcaseしかありませんが、
1つのサービス内に、複数の異なる作りのページが存在するときは、その全てをcasesの中に実装しました。

リンクチェック実行時のコマンド

基本的にはSTG環境でテストを定期実行しているのですが、
影響範囲が広い開発では、DEV環境でも自動テストを実行したい要件が出てきたため、
urls:のURLに環境変数を使うように途中から変更しました。

④ E2Eで重要コンテンツの存在チェックの実装

サイト内で、重要なコンテンツがちゃんと表示されているかをチェックするE2Eを実装しました。
※重要コンテンツ・・・絶対にバグを出してはいけない大事なコンテンツ

以下に記載の例でも1つのファイルに1つのcaseしかありませんが、
1つのサービス内に、複数の異なる作りのページが存在するときは、その全てをcasesの中に実装しました。
また、複数の重要コンテンツがあれば、それらをpartsに記載し、テストケースで1つ1つチェックしました。

(SPは省略)

E2E実行時のコマンド

E2Eはユーザから見える外部の振る舞いに着目して行うテストなので、内部処理の都合でidなどが変更されてもテストが通るように、外から見える要素の情報でテストを行うために、このようなチェック方法にしました。
verifyのassert_exist_partは、要素がページに存在することを検証しています。
他の検証リストはこちら(Verification List)。

まとめ

自動テストができたことで、重要なバグを未然に防げるようになったことはもちろん、
開発案件のテストの際も、より案件に集中してテストをして、回帰テストは自動テストに任せることができるようになりました。
自動テストをしっかり運用していくことで、開発全体の生産性の向上に寄与していると思います。
次回、最終章の運用編でどのように運用しているかをお伝えします。

  • このエントリーをはてなブックマークに追加
  • Pocket

SNSでもご購読できます。