QAチーム立ち上げ記録第1回 - ロコガイドテックブログ

f:id:kishikeen:20210308115218p:plain

自己紹介

はじめまして。昨年12月にロコガイドに入社しました、きしけん（@takeya0x86）と申します。所属は技術部で役割はQAエンジニアです。前職では第三者検証の会社で主にE2Eテストの自動化やCI構築をやっていました。社外ではテスト自動化研究会への参加やSeleniumやAppiumなどテスト関連OSSへのコントリビュートなども行っています。

これまでのロコガイドにおけるQA・テストについて

ロコガイドにはこれまでQAを専任で担当するエンジニアはいませんでした。私が一人目のQAエンジニアとなります。これまではQAやテストに関する活動は開発エンジニアによって行われており、テックブログの「テスト」のカテゴリーにもその一部が紹介されています。こういった活動は続けられていましたが、個々で行われるために属人化していたり、組織としての体制の構築が不十分であるなどの課題が発生していました。

この記事ではこれらの課題の解決に向けて、私が入社してから3ヶ月の間に行ってきた活動を紹介したいと思います。

ヒアリングとアンケート

まずは現状の把握と最初の方針決めのためにヒアリングとアンケートを実施しました。ヒアリングはiOS、Androidのアプリエンジニアに対面（リモート）で、アンケートはエンジニアの他にデザイナー、ディレクターも含め少し範囲を広げて実施しました。

実際に聞いた内容としては、現状の開発プロセスにおけるテスト活動について、

現状の活動についての所感（〇〇は十分、△△は足らないなど）
実施している活動（ユニットテストや構築済みのCIなど）
実施したいができていない活動（時間・人員・ノウハウなどが不足しているなどの要因も）

などの項目です。結果としては、以下のような声があがりました。

テスト項目の網羅性が足らない
機能テスト、特にリリース対象の新機能以外の既存機能のテストが不十分
自動化をもっと広げたい
ユーザ、クライアントを巻き込んだテストをやりたい（ベータテストのようなもの）

現場が抱えている課題感ややりたいことがわかってきたので、これを踏まえて最初の活動を決めていきます。

まず、外部を巻き込んだ活動の前に内部を先に整えていくべきだろうという考えになりました。また、テスト設計に関する課題がある状態のテストを自動化しても意味がありません、課題がそのままのテストが自動で動くようになるだけです。そこで、トクバイアプリのリリースサイクルにおけるリグレッションテストの整備をやっていくことにしました。今動いている機能へのテスト設計を再検討することで品質保証の土台づくりをしたい。また、網羅性についての見直し（その基準もふくめて）も整理しながら進めていけそうという考えでした。

リグレッションテストの整備

リグレッションテストとは、機能追加・改修時に別の領域での意図しない変更・不具合が発生していないかを検出するためのテストです。毎回リリース時に同じ内容のテストを実施することで、新機能の開発による既存機能への意図しない影響がないかを確認します。

まずは、各機能を担当するディレクターを交えてどこを重点的にテストしていくかをディスカッションしました。リモートで話をしながら以下のような対象機能とテストの観点を貼り出した表を作成していきました。

前掲の表に加えて仕様、実アプリを確認しながらテスト設計書を作成していきました。

最終的には実行するときの見やすさを考えて手順をメインにしたフォーマットになりました。

細かい工夫点として、ケースごとに優先度を付与してフィルタできるようにしたり、テスト結果の名前や日付入力を補助するスクリプトを作成したりしています。このあたりは前職での経験を活かしているところです。

1月末のスプリントからこのテスト設計書をつかってリグレッションテストを実施しています。

トクバイアプリは1スプリント2週間で開発・リリースを行っています。スプリント2週目の水曜日にコードフリーズがあり、新機能が含まれたビルドが作成されます。リグレッションテストはその翌日木曜日に実施するようにサイクルに組み込みました。現在は自分の他にアプリエンジニアと一部のディレクターを実行担当としてアサインしています。

設計を見直したことにより、これまで実施者まかせだった手順や確認するポイント、前提条件が明確になったことで実施内容が統一されるようになりました。ただ、テストデータの整備がまだ不十分な点や、内容が手順に寄りすぎていて全体の見通しが良くないなど現時点でも多く課題があります。このあたりは少しずつブラッシュアップしていきたいと思っています。