はじめに

回帰テストの現状

ノハナにはAndroid、iOS、決済(サーバー)の3つの回帰テストがあり、リリースのたびにAndroid、iOSの回帰テストを実施しています。
決済(サーバー)は修正が入ったときに、影響範囲を考慮し必要に応じて回帰テストを実施しています。
元々は全て手動でテストをしていたのですが、数年前からMagicPodを使い自動化を進めています。

自動化率(2022年5月時点)

Androidは2021年ごろから約1年半をかけて自動化率を約69%まで伸ばしました。Androidのケースでは、自動化前は8時間以上かかっていた回帰テストの工数が3時間弱となり、5時間以上の工数を削減することができました。また、自動テストを早朝にステージング環境で定期実行して問題がないことを確認しており、エラーがあれば都度対応しています。
ただ、決済に関しては半年ぐらい前までは未着手の状態でした。理由としては、回帰テスト自体の実施頻度が低く優先度が低かったからです。
iOSの自動化率も昨年末では20%ぐらいでしたが、シナリオの見直しをしたため、自動化率が低い状態が続いていました。

目標の自動化率

そこで、全体の自動化率を上げることを目標に、決済とiOSの自動化に着手することにしました。
決済の回帰テストのシナリオは30ぐらいあるので、3ヶ月(四半期)で50%を自動化することを目標としました。
iOSについても、70%の自動化を目標に進めました。

自動化についての過去の記事は**こちら**をご覧ください。

テスト自動化作業

決済の場合、注文内容や支払い方法などは異なるけど、操作自体は同じケースが多いので、共有ステップ を多用しました。以下の表は組み合わせのサンプルです(実際の組み合わせではありません)。このケースだと5シナリオあるので、それぞれで個別にテストコードを作成するとそれだけでも大変ですが、仕様変更時などのたびに5つのシナリオを修正する必要が出てきます。
このような時も、共有ステップだと1つのテストコードを修正するだけで対応できるので、大きなメリットだと思います。

画面ごとに共有ステップとして登録し、データパターンを各シナリオごとに設定し、共有ステップを組み合わせてテストコードを作成しています。
以下は実際のシナリオではないですが、このように注文フローを共有ステップとして管理しています。

共有ステップ内ではデータパターンの値をもとに条件分岐を入れています。
最初に共有ステップを作る時間はかかりましたが、結果として異なる条件でもデータパターンを変えるだけで良くなり、新規シナリオを作成するときも、テストコード自体の変更はほぼ必要なくなりました。

現段階での状況

このブログを書いている時点での状況は以下のようになっています(Sprint#18)。
Androidは変わりありませんが、決済とiOSの自動化が進んでいることがわかると思います。

全体では41%弱ぐらいまで自動化できましたが、まだまだ先があります。
一部自動化が難しいところもあるので、目標としては全体の80%ぐらいを自動化できればと考えています。

今後の予定

グラフの点線以降が次の四半期の自動化率の見込みです。
全体では75%を自動化し、決済については90%を自動化することを目標にしています。
決済については共有ステップを使いシナリオを作成できるため、自動化率の見込みがかなり高くなっています。

改善してほしいところ

MagicPodはほぼプログラミングの知識がなくても自動化が可能な強力なツールなのですが、いくつか改善してほしいところもあります。
まず、iOSは要素が見つからないケースや、エラーになるケースが多いです。
修正対象外の箇所で前回は問題なかったのに失敗するケースなどが多く、テストコード作成後のシナリオの確認作業に想定以上の工数がかかっているのが現状です(グラフでもiOSの伸びが若干鈍いことがわかると思います)。
また、Androidのケースでは実機だと成功するけど、エミュレータだと失敗するなどのケースもあり、このような課題が解決すると、さらにスピードアップできるのかなと感じています。

最後に

最終的なゴールは、ステージングにデプロイされたタイミングで回帰テストのシナリオを回すことです。
これによりバグを早いタイミングで検知でき、手戻りも少なくなり、常に安定した品質をキープしていきたいと思います。