11
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

AIQVE ONE ゲームテスト/QAAdvent Calendar 2021

Day 8

テスト自動化は人間の心を癒してくれる

Last updated at Posted at 2021-12-07

#はじめに
主にE2Eでのゲームアプリのテスト自動化の導入にあたり、
内々で時折相談を受けることがあるが、
どういうわけか全テストケースの自動化が可能で、
簡単に工数削減ができると認識している状態で相談を受ける。
テスト自動化ツールは人間の代わりを務めることは難しい。
以下、理由を挙げていく。

#自動テストは人間の代わりにならない
日本国内でテストの標準になりつつあるJSTQBでのFLシラバスでは、
以下の主な活動がテスト実行として記載されている。

• テストアイテムまたはテスト対象、テストツール、テストウェアの ID とバージョンを記録する。
• 手動で、またはテスト実行ツールを使用してテストを実行する。
• 実行結果と期待結果を比較する。
• 不正を分析して、可能性のある原因を特定する(故障はコード内の欠陥によって発生する可能性があるが、偽陽性が発生することもある。
• 故障を観察し、観察に基づいて欠陥を報告する。
• テスト実行の結果(合格、不合格、ブロックなど)を記録する。
• 不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す(修正したテストケースによるテスト、確認テスト、および/またはリグレッションテストの実行)。
• テストベース、テスト条件、テストケース、テスト手順、テスト結果の間で双方向のトレーサビリティを検証し更新する。

活動としては「記録」「テスト実行」「結果比較」「不正を分析」「故障を観察」「報告」「トレーサビリティを検証し更新」といったところ。
普段テスターは上記活動を行いソフトウェアを検証している。

テスト自動化ツールは「記録」「テスト実行」「報告」は滞りなく実装出来るとは思う。
以下の機能についてはかなり工夫入れていかなければ以下のようになる。

「結果比較」は単純なパラメータ、値が一致しているかの確認しかできないし、
「報告」もまた成功・失敗程度の報告しかできない。
「不正を分析」「故障を観察」「トレーサビリティを検証し更新」を行おうとすると、
膨大な工数を割いて実装するためやはり現実的ではない。

2021年現在、テスト自動化ツールは一部分の活動でのみ支援することが可能であるが、
人間のテスト活動と同様の働きを見せることは難しいことが想定される。

#自動テストはそんな簡単に作れない
昨今テスト自動化ツールでは、ノーコード、ローコードで扱うことができ、
「誰でも簡単に自動ツールで動作確認・検証を作成・実行が出来る」と
謳われている時がある。
確かに一般的なWebサイトなら有用に扱えるだろうと思う。

しかし、他のコンテンツを例を挙げるとゲームアプリのようなオーダーメイドな
仕様が当たり前のアプリケーションにローコード・ノーコードツールはほぼ通用しない。

例えばスマホゲームでは標準的な実装がされていると思われる「最も単純な機能」である
「ガチャ機能」の確認を例にするだけでも以下の分岐が思いつく。
異常系・通信周りは除く。

・無償か有償か
・回数限定か無制限か
・ガチャを回す時、演出上で操作を挟むか
・高レアリティ排出時に演出が挟むか
・ガチャ結果画面の有無
・続けて回す機能の有無
・ガチャを回した際のオマケのプレゼントがあるか
・天井回数分ガチャを回した時、交換画面に遷移するか

上記分岐する機能を考慮しつつ実装することになるが、
この機能群をノーコード・ローコードツールで簡単に実装できるのだろうか。
「簡単に作れます」なんて営業トークか驕らない限り中々言い切れない。
「(時間をかけ、条件を満たせば比較的)簡単に作れます」かもしれないが…

#手動でのテストの効率化の先に自動化がある
それではテスト自動化ツールを導入し、
自動テストを十全に扱おうとする場合どうしたらいいか?となる。
その答えは至極単純なもので「最適化されたテストケース上でテスト自動化ツールが長時間動いても安定するものが自動化しやすいケース」になる。

テストケース中、人間が読み取ると解釈が変わるようなテストケースや、
1つのテストケースなのに2つ以上の期待結果があるようなテストケースがある場合は、
テスト自動化をする前」に手動でのテストの効率化の余地が大きくある。
なので手動テスト効率化を先に着手しても全く遅くはない。
むしろ手動テストと向き合う機会が来たと喜ぶべきだ。
品質は一歩にしてならず、品質というものに向き合い続け、
テストが成熟して初めて自動化に出会える。

#先に手動テストを効率化しても遅くない
なぜ手動テスト効率化を先に着手することを勧めるかというと、
手動テストの工数を効率化するのが比較的して容易であるのと、
自動テストを導入する際にテストケースを精査して
自動テストに向くか精査する工程があるため。

自動テストが手動で実施する場合のコストを確実に下回る状況を見極め、
適用して実装しようとする場合、
現状況では自動化エンジニアはテストケース・アプリを触らざるを得ない。

結局、最適化をするのであれば手動テストも最適化した後に、
自動化を導入することを検討する方がコスト・無駄が少なくなる。
勿論並行して行うという形でも個人的には良いと思う。

#テスト自動化ツールは人間以上になる時は限定的
テスト自動化ツール、万能ではないところばかり述べてきたが、
設定さえすれば勝手に動くツールなので、人間以上のパフォーマンスが出る時もある。

人間は休みなくして働き続けるのは困難だが、長時間稼働しても基本的に問題ない。
また、単調なテストにもエラーを吐かない限り文句ひとつ言わずに動いてくれる。

従業員の精神衛生の改善のための自動テスト導入は強くお勧めができます。
自動テスト導入により、テストエンジニアのストレス状況は改善され、
気持ちよくテストを行い、綺麗なバグ票が開発に送られる。よって現場のストレスは減る。
そしてより良い品質に製品が提供できるようになる。
ビジネスとしての結果は自然と後からついてくる。

#最後に
テスト自動化は人間の心を癒してくれる
テスト効率化を行おうとする導入が出来るということは、
テストの効率化が測れているということなので、
テスト環境を計る指標としては便利ではあるし、
テストツールに単調なテストを任せ、
テスターはクリエイティブなテストを行うことができ精神衛生上で良好な環境になる。

自動テスト導入を人が足らなくて…コスト減らしたくて…等、
金銭・時間など消極的な理由で検討するのではなく、
より良いテストを行い、良質なソフトを提供するための自動テストの導入はどうだろうか。

11
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?