食べチョクの自動テスト改善活動〜これまでとこれから〜

みなさん初めまして。 QAエンジニアのujeです。

食べチョクでは、2022年4月から正式に自動テスト改善チームが発足いたしました。チームメンバーは機能開発との掛け持ちにはなりますが、Webエンジニア5名・QA1名で取り組んでいます。

自動テスト改善チームの発足に伴い、食べチョクのテストにまつわる振り返りと、改善チームが取り組んでいることをお話しいたします。

これまで

食べチョクはサービスリリースから5年がたつプロダクトです。特にここ1年半は食べチョクに参加してくれる仲間が増えており、サービス開発のスピードも上がっています。

食べチョクは2020年まで、テストカバレッジが低く、またなかなか向上しない状態でした。システム全体に影響がある改修をする際は、毎回全画面を一通り手作業で触りテストするなど労力のかかる状態でした。この状態を脱するため、2020年末から少しずつ自動テスト改善の動きが始まりました。

20年11月-バックエンドのRSpec積極拡張方針が決まる

これまでは機能開発が優先されていて重要なところだけ自動テストが書かれている状況でした。そのため、この時期から実装した機能のRSpecによるテスト実装を後回しにせず、並行して増やしていく方針に変わっていきました。

21年8月-カバレッジをデータ化して見える化が始まる

開発方針が変わったものの増やしていくだけとなっていたので、どの程度カバーされているかは把握できていませんでした。そのためこの時期からデータ化して定期的に展開するようになりました。数字が出たことで意欲が向上したためか、拡張速度が上がったと実感するのもこの時期でした。

21年9月-E2Eテストの本格導入が始まる

9月からWeb版のE2E導入、10月からAndroid版のE2E導入が始まりました。現在はリリース前にユニットテストの他に、1日1回の定期実行とリリース直前にE2Eが成功することを確認する仕組みになっています。なお、iOSについては今後、本格導入を検討しています。

22年1月からJestの本格導入が始まる

一時期フロントにまつわる不具合が増加しつつあったことに起因して、フロントエンドの単体テストの用途としてJest導入に踏み切りました。 E2Eはシステムテストの位置付けで外側から目的が達成できるか確認することとしています。 Jestはフロントエンドに特化した単体テストとしてパラメータ受け渡しなどのUI影響がある要素に影響がないかを重視して実装していっています。

これから

冒頭でお話した通り4月から正式に自動テスト改善活動チームが発足いたしました。各メンバー機能開発との掛け持ちしながらになりますが、webエンジニア5名・QA1名という体制になっています。

発足理由

まだまだ古くからあるコードは1テストすらないことが多いです。テストのない箇所が開発速度に影響が出たこともあり、解消を意識したのが1点目です。

またQCDバランスを意識したリリースするには自動テストが必要不可欠だと判断したことが2点目です。現在、アプリに関わらないバックエンド・フロントエンド要素は1日1回リリースしています。さらにメンバー拡大に伴い同時並行で進行する機能開発が増えてきました。この2つから、壊れた際の検知を早めることが格段に大事になってきました。

これらの要素を考慮した結果、組織的な積極対策を目的としてチーム発足へと繋がりました。

主な活動

自動テストの速度向上・自動テストの充実化を目標に取り組んでいます。ただし掛け持ちなので、やることはみんなで分担する＆週1日など無理のない範囲で改善活動に時間を当てるような形になっています。

具体的には実行速度の監視・速度改善の対策案を相談したり、充実化でもデータ化・方針策定などを始めています。

チーム運営

QAである私は主にMTG進行の役割を担っており以下のようなことに注意を払って運営しています。（書いてあることは基本的なことばかりです）

事前資料の準備＆事前展開・MTG近づいたらリマインド・事前に資料記載のお願い
レビューと計画を1セットにして1時間以内のMTG（時短できるなら時短を目指す）
OODAループを利用してネクストアクションを決める
- ※Observe、Orient、Decide、Actの4項目を軸にループを回す方法です。別手法にはPDCAサイクルがあります