Web系テストエンジニアが選ぶ漏れがちなテストたち
この記事はcommmune Advent Calendar 2023の19日目として投稿されました。
Webアプリケーションのテストエンジニア(QAエンジニア)歴10年の私が独断と偏見で選んだ、漏れがちなテストを紹介します。
データの即時反映のテスト
Webの場合サーバーキャッシュを活用することがあるため、データ更新時にサーバーキャッシュも削除して欲しい場合はサーバーキャッシュを削除することの動作確認が必要になります。
例えば、通知アイコンの通知件数、ユーザーの保有ポイント、ニュース一覧に表示する記事など
データ更新・削除に関するテスト
機能Aが使っているデータ1を機能Bが更新・削除した場合に機能Aが正しく動くかのテストです。
特にデータ1を削除した場合に機能Aがデータ1が削除されることを前提とした作りになっていない場合、機能Aの画面を表示すると500エラーになるといったことが発生しがちです。
なお、上記のようなデータ不整合を防ぐために、機能Aで利用しているデータは機能Bで削除できない仕様にすることも多いです。
ブラウザの機能を用いた画面遷移のテスト
Webサービスの場合、UI以外の操作でも画面遷移できます。URLを直接入力する、戻るボタンを押す(ブラウザバック)、リロードなどです。これらの操作を使った画面遷移のテストを行います。
例えば、あるページに管理者しかアクセスできないようにする場合、一般ユーザーにはアクセスできないページへのリンクを非表示にするだけでなく、一般ユーザーがURLをブラウザに直接入力した場合もページを閲覧できないようにする必要があります。
複数人で同じデータを更新するテスト
Webサービスの場合、複数人が同じ画面を開き、同じデータを同時に更新しようとする、といったことが発生します。なので、複数人が同時に操作を行った時の動作確認も必要です。
例えば、ECサイトで在庫1個の商品を二人同時にカートに入れ、同時に購入手続きを進めるといった形です。(購入が完了するまで在庫が減らない前提)
複数ブラウザのテスト
Webサービスの場合、特定のブラウザがサポートしていないCSSやJavaScriptのAPIを使ってしまい、特定のブラウザでWebサイトが正しく動作しないことがありえます。
そのため、複数のブラウザでテストする必要がある場合があります。
Webページの描画速度のテスト
Webページの描画速度はUXに大きく影響するので動作確認が必要です。
特に普段からスペックの低い環境で手動テストを行っている場合、意識しないと時間効率性の問題に気づけないことがあります。
負荷テスト
Webサービスの場合、大多数のユーザーが同時にアクセスする可能性があります。
そのため、想定される大多数のユーザーが同時にアクセスしてもサービスを提供できることを確認する必要があります。
リリース前に作成されたデータがリリース後も使えるかのテスト
リリースの前後で既存機能の仕様が変わる場合に、リリース前に作成したデータがリリース後も動作することを確認する必要がある場合があります。
例えば、入力フォームの必須項目を任意項目に仕様変更した場合、必須項目だったカラムを参照する画面のコードで当該カラムがnullではない前提の実装をしていると問題が生じます。
本番環境でのテスト
理想は検証用の環境と本番環境は同一のものが望ましいですが、両者の環境を同一にするのが難しい場合があります。その場合、環境の差異に関連する改修を行った時に本番環境でのテストも必要になります。
特に環境変数は環境ごとに異なっている場合が多いため、環境変数に関係するテストは本番環境でのテストも必要になります。
Discussion