この記事はAutify Advent Calendar 2021の22日目の記事です。

自己紹介

株式会社レコチョクでQAを担当している清崎（きよさき）と申します。
社内では独立したQAチームが組織横断として存在しており、自社サービス、toB向け、toC向けと展開しているサービスに対して、ビジネスチーム/開発チームとQAチームが協力しながらテストを実施しております。

株式会社レコチョクの紹介

当社は2001年に国内の主要レコード会社の共同出資で設立され、おかげさまで2021年で20周年を迎えました。
2002年に着うた(R)のサービスを開始し、現在はPC、Android/iOS、ゲーム機などの多様なデバイス向けにダウンロード配信やストリーミング配信を展開しております。
他にもtoB向けの事業に対しても積極的に行っており、タワーレコード社との協業提供にて定額音楽配信サービス「TOWER RECORDS MUSIC」、NTTドコモ社の「dミュージック、dヒッツ」、KDDI社の「Music Store」、USEN社との店舗用BGM配信サービス「OTORAKU-音・楽-」という協業サービスを運営しています。
2021年10月からアーティストがダイレクトにファンへアプローチするDtoF（ダイレクトtoファン）の潮流を背景に、レコード会社やアーティストマネジメントがオンラインストアを開設しデジタル商材を販売できるワンストップECソリューション（murket）を立ち上げており、今後もさらに新たな音楽体験を提供できるよう企画しております。

はじめに

まず、Autify導入前は手動テストのみでQAを行っておりました。
使い始めの頃は「シナリオをどんどん増やして動かそう」というモチベーションが高く、カバーする範囲を増やそうと試行錯誤しながら徐々にAutifyシナリオの作成に勤しむ日々を過ごしておりました。

起ったこと

しかし、便利ではある一方で運用して「うまくいかない」「しっくりこない」ことがあり「楽になったとは言い切れない」と感じはじめました。
これでは将来廃れてしまうかも・・・

手動テストを無理に自動へ置き換えようとしてステップ数が多いシナリオになってしまう
自動テストシナリオ起因のエラーで失敗して安定しない
手動で実行している場合の無意識アサーションが抜けている

その理由は？

主な原因は、どうしても手動テストで実施していた頃のテスト項目を自動へ置き換えることが手っ取り早いため、一生懸命「写経」をやっていたことが一番の理由でした。

1. 手動テストを無理に自動へ置き換えようとしてステップ数が多いシナリオになってしまう

シナリオの視認性が悪くなりメンテナンスが辛くなる問題がでてしまいます。
決めた範囲を置き換えることが目的になり「何をテストしたかったのか」観点がよくわからない意思がないテストが作成される状態でした。

2. 自動テストシナリオ起因のエラーで失敗して安定しない

失敗はソフトウェアの不具合ではなくシナリオに問題あることばかり
原因切り分けやシナリオ修正、リトライが増えてしまい自動テストではなく**「半自動テスト状態」**で保守コストがかかってしまい効果が得られにくくなりました。
1と関連しますが無理した結果、自動へ置き換える範囲をしっかり検討して設計できていませんでした。

3. 手動で実行している場合の無意識アサーションが抜けている

アサーションとはテストの応答結果が期待値と同じであるのかの真偽判定のことです。
テスト自動化の8原則の「自動テストは書いたことしかテストしない」にある通りですが、ここではテストケースに書かれていないことを暗黙的に自動テストで発見するという事ではありません。
テストケース毎に何をもって結果がOKなのか意識できていないため、手前のステップで既に期待する動きをしていないのに、そこでエラーにならず、後続でエラーになるということがありました。
原因はアサーションステップを適切に入れていないことで、実行結果のスクショを見ても欲しい部分が撮れていないことや、エラーが起きたときの前後が判りにくく、切り分けに時間がかかってしまうことなどありました。自分以外の担当者が作成したものだと余計に時間がかかってしまいます。

テスト自動化はテストを実施する手段の一つであり、向き不向きを理解した上で利用しなければならないと身を持って感じました。

見直しポイント

一言でいうと「無理しない」です。
それでは伝わらないと思いますので、自動テストで実施する範囲を次の内容を説明します。

目的を改めて整理・・・例）重要機能や主要機能が正常に動くこと

絶対に不具合を発生させたくない部分や、お客さまやユーザーへどの様な価値を提供したいのか明確であれば、そこを中心にして自動テストへ置き換えていくという判断ができます。
無意識アサーションは非常に難しい部分ですが、期待値をしっかりと考えてやや冗長でもシナリオへ落とし込む（実行しながらブラッシュアップする部分が大きいです）

繰り返し実行をする部分を切り出す

動かさないと廃れていきますし、しばらく動かさないと成功するか信用のないテストケースになるので、作成するシナリオは利用頻度を意識しました。

テストの実現性（容易性）を意識

テストプロセスを交えて説明します。

1.4.2 テストの活動とタスク
テストプロセスを構成する主な活動のグループは以下の通りである。
• テスト計画
• テストのモニタリングとコントロール
• テスト分析
• テスト設計
• テスト実装
• テスト実行
• テスト完了

参考）JSTQB Foundation Level シラバス Version 2018V3.1.J03

計画、実行、完了は本題と外れます。

テスト計画初期段階でこのテストは自動テストを利用するというアプローチが決まっている場合もあるかもしれませんが、途中の見直しで手段の採用や適用する範囲が決まって更新されるのが流れとして自然だと思います。(自動テストを採用する可能性が高ければ自動テストの実装スケジュールは確保しておいたほうが良いです)
テストの分析フェーズではテストベースや開発の中間成果物などを調査して抽象的なものから「何をテストするか」を具体化するフェーズで、手動と自動どちらも変わらないと考えております。
テスト設計ではより具体化していくので、テストアーキテクチャを意識しながら「手動でしかできないもの」「自動で実現できるもの」など、テストの前提条件、データ、手順などをもとに「テストの実現性（容易性）」を判断して手段を整理する考え方を入れました。
もちろん今までの手動のテストでも「テストの実現性（容易性）」は考えてはいましたが、手段ごとのメリット・デメリットを見極めることを意識しました。
「手動でしかできないもの」は使い勝手や、暗黙的なもの、期待値があいまいなものが挙げられます。
例としては、キャンペーン時期によって表示要素が変わる部分やソート順や表示要素が毎回固定されないものなど、サイトの作りや外的要因の部分が該当します。
「使い勝手」は利用時の品質のようなものがありますが、レコチョクのサービス例では楽曲再生や動画再生で「動きがカクカクする」というものも該当します。
また、「音飛び」や「コマ落ち」など何をもって音飛びなのか人間の感性が必要なものは自動では行わず目チェックします。（近い将来に自動で実現するかもですが）

こういった見直しをすることで、自動化する範囲を絞って徐々に広げていくことができ、さらに安定してきましたので成果はあったと感じております（弊社の場合）

まとめ

手動で実施しているテスト項目を無理して自動テストへ置き換えない。
テストの実現性（容易性）を意識して、自動では繰り返し実施するものやパターン化できるものなどシンプルなことを意識することをオススメします。