この記事は、ソフトウェアテストアドベントカレンダー1日目の記事です。
qiita.com
先日、第147回テストラジオでSPAのテストについて語りました。
この記事はその話に少し追加をしたものです。
SPAのテストをする時の参考になると嬉しいです。
testradio.fm
twitcasting.tv
SPAとは？
Single Page Applicationの略で、単一のWebページのみから構成するアプリケーション(Webサイト)のことです。
SPAについて細かく知りたい方は以下の記事が参考になると思います。
SPAのテストで特に気にしたほうが良いところ
実体験 & 友人からの情報 & 公開されていた資料を参考にSPAのテストをする時、気にしたほうが良さそうなところを8つピックアップしました。
- ① ブラウザの更新ボタン（リロード）
- ② ブラウザの戻るボタン（ブラウザバック）
- ③ URLに直接アクセスする
- ④ 情報が更新されるタイミングは自然か？
- ⑤ ログインのセッション（有効期限）が切れた時どうなるか？
- ⑥ 右クリック > 新しいタブで開けるか？
- ⑦ URLを変える必要はないか？
- ⑧ よくあるWebシステムで問題ないと思っている動作を試してみる
- ⑨ 特定のリクエストのみが失敗したときに挙動が壊れないか？(追記)
- ⑩ フロントエンドとバックエンドでロジックが揃っているか？(追記)
① ブラウザの更新ボタン（リロード）
SPAはブラウザ上で状態やパラメータを管理しているため、リロードするとそれらが消えてしまいおかしな動作になりやすいみたいです（そうならないような作り込みが必要）。
Webシステムのテスターはブラウザリロードする癖が染み付いていそうなので、リロードが絡むバグは見つかりやすいと思います。
ですが、このバグを見つけてからバグが修正されるまでの間「ブラウザリロードしたらバグるから、リロードしないように、壊さないように気をつけてテストを進めよう」という場面になったときは要注意です。
このアプローチに慣れると「リロードしない癖/壊さない癖」がついている可能性があります。
そうなってしまうと、バグが修正されたあとにリロードをあまりしなくなりバグを見逃すという可能性も出てくるので気をつけてください。
② ブラウザの戻るボタン（ブラウザバック）
①と同じく、SPAはブラウザ上で状態やパラメータを管理しているため、ブラウザバックしたときにそれらが消えてしまいおかしな動作になりやすいみたいです。
もちろんブラウザの「進む」でも気をつけたほうが良いです。
テストラジオ中ではなそさんが「例えば商品購入で3ステップぐらいページを挟んだ時、ブラウザバックするとなにか起きそうだよね」と言ってましたが、まさにその通りだと思います。
もちろん、SPAではないWebシステムでもこの動作は気にすると思いますが、SPAでは特に気にしたほうが良いと思います。
余談ですが、検索結果がページネーションで表示される、ログイン/ログアウト機能がある場合は以下を試してみるのはありと思います。
- ページネーション
- 2ページ目→3ページ目と表示してブラウザバックする
（その後ブラウザ進むする）
- 2ページ目を表示→その中の1つの詳細画面を開いたあとブラウザバックする
- ログイン/ログアウト
- ログアウトしたあとにブラウザバック
- ログイン中しか見れないページを表示→ログアウト→ブラウザバック
③ URLに直接アクセスする
これも①、②と同じくブラウザ上で状態やパラメータを管理していることが理由のようです。
例えば「ページCは、ページAとページBを辿って表示される」という前提で作られていた場合、「AとBで取得しているはずの状態やパラメータがない」条件でページCが表示されることになるので、
意図しない挙動になりやすいです。
「アクセス権限がないページのURLに直接アクセスする」というのはSPAではないWebページでもテストすると思いますが、アクセス権限など関係なく試してみると何かが見つかるかもしれません。
④ 情報が更新されるタイミングは自然か？
APIを使ってサーバー上のデータを更新する時ブラウザに表示中のデータも更新する必要がありますが、この更新タイミングがずれ、見た目の情報が最新になっていないということもよくあるみたいです。
例えば「ユーザー情報の編集ページ」があり、このページは更新ボタンをクリックするとユーザー情報が更新されて同じページ(ユーザー情報の編集ページ)が表示される仕様とします。
この時、情報を変更して更新ボタンをクリックした時、以下を試してみるのをオススメします。
- ページ上の表示は切り替わっているか確認する
- ブラウザバック & ブラウザ進むしてみる
- 1度別のページに遷移 & ブウラウザバックしてみる
加えて、編集/新規登録ページを表示中に、サイドメニューやヘッダーに現在表示中のページに遷移するリンクがある場合、「表示中のページにもう1度アクセスしてみる」というのもやってみると良いかもです。
- ユーザー情報の編集ページを表示する
- いくつかのフォームの値を書き換える
- 更新ボタンを押さずに、「ユーザー情報の編集ページ」へのリンクをクリックする
SPAではないWebシステムではこの操作をすると、ページが新規読み込みされると思いますが、SPAではその挙動にならないこともあります。
※ どちらがいいかはシステム次第と思います。
⑤ ログインのセッション(有効期限)が切れた時どうなるか？
miwaさんから頂いたコメントの中に「1日放置してから動かす」とありました。
自分はまさにこの挙動でバグに遭遇しました。
ログインセッションが切れた状態で画面を操作すると、見た目は一見ログインできてしまっているようになっているんですが、
セッションの有効期限が切れているのでそれが必要なページを開くとフラッシュメッセージでエラーが表示されたり、403エラーが表示されたりとなっていました。
SPAではないWebシステムでもセッションの期限が切れた時どうなるか？のテストはもちろんするのですが、自分は割とテスト後半でやることが多いんですよね。
今回はたまたまかなり初期に見つけることができたのでラッキーでした。ログインのセッション管理は実装方法で動作がかなり変わってきそうですが、どの実装の場合でもこのテストは有効そうですね。
⑥ 右クリック > 新しいタブで開けるか？
www.slideshare.net
@ushiboyさんの上記のスライド34ページに書かれていたのをみつけて試したところ自分のテスト対象でも再現しました。
意識して作らないとSPAではないWebシステムのような挙動にならないみたいです。
このスライドはとても勉強になるので、読んでおいたほうが良いと思います。
①、②、③を実感していたときにこの資料を読むことができたので、①、②、③がSPAあるあるなんだなぁと思うことができました。
⑦ URLを変える必要はないか？
URLを変えずにシステムを作ることができるため、見た目上正しく動作していたとしても以下の点は気にしたほうが良いと思います。
- 詳細ページにidを入れてユニークなURLにする必要はないか？
- 検索結果を表示する場合、クエリストリングを表示される必要はないか？
ブラウザのブックマーク機能で特定のページにアクセスしたり、誰かにURLを共有するユースケースがある場合、この辺りは対応していないと不便そうです。
余談ですが、URLが全部共通の場合、バグ票(チケット/issue/課題/などなど)に記載するURLが全部同じものになってしまうので不便になることもありそうですね。
⑧ よくあるWebシステムで問題ないと思っている動作を試してみる
この8個目はこれまでと違ってふわっとしていますがとても大事なことだと思っています。
自分は基本的に「SPAではないWebシステム」をテストしています。
このテストではブラウザバックを連打してもほとんどバグは出ないです(出ないからやってないというわけではないですが、深くやることはあまりありません)。
ですが、SPAのシステムのテスト中、たまたまブラウザバックを連打したところ「特定の画面が自動繰り返し表示されるバグ」に遭遇しました。
SPAは普段やっているWebシステムとは一見変わりがないんですが、やはり別物なんだなぁと再認識しました。
普段問題ないって思ってることを疑うのは難しいですが、そういった点も気にしていけたらより良いと思います。
⑨ 特定のリクエストのみが失敗したときに挙動が壊れないか？(追記)
tsuemuraさん からコメント頂いたので⑨と⑩を追記しました。
tsuemuraさんの言っているのと同じケースかはわかりませんが、このコメントをみて以下の事象を思い出しました。
自分のテスト対象では1つのページを表示する際2つ以上の
APIにアクセスする必要があるページがありました。
そのとき片方のリク
エストは成功、片方のリク
エストは失敗というケースが発生し、画面の表示がおかしくなることがありました。
また、ある画面での
APIリク
エストに失敗した後に他のページに画面遷移するとエラーのフラッシュメッセージが出続ける/特定のボタンが反応しなくなる という事象にも遭遇しました。
APIリク
エストに失敗した後どうなるか？というのはSPAでは特に気にしたほうが良い気がします。エラーになった状態を保持した状態で画面遷移や操作をされると怖いですね。
⑩ フロントエンドとバックエンドでロジックが揃っているか？(追記)
こちらも⑨と同様にtusemuraさんからコメント頂いたので追記しました。
例えば「ある入力フォームには最大512文字までという入力数の制限をかける」という仕様があったとき、フロントエンド側とバックエンド側でバリデーションが揃っているか？というのは気にしたほうが良いです。フロント側で513文字入力できることもあれば、バックエンド側で255文字までしか受け付けないということになっているかもしれません。
SPAではないWebシステムの場合でも、ファイルアップロードする際のファイルサイズのバリデーションでnginx側とずれていたり、MySQLで最大文字数が決められている型を使っていてずれてしまうなんてこともありますが、SPAの場合はAPIを挟むことによって隙間が増えるのでより気をつけたほうが良いと思いました。
また余談ですが、バグ票の登録ルールを定めておくことも大事だと思います。
自分の場合は基本的にフロントエンド側のリポジトリにバグ票を登録し、バックエンド側で対応が必要なものはバックエンド側のリポジトリにバグ票をコピーしてもらっていました（もちろん、Devツールで分かる範囲の情報は添付してたり、登録前に会話してバックエンド側に登録するということもありました）。
おわりに
自分はこれまでSPAのテストをする機会が少なくて、テストラジオでSPAの話をしたときは通算4回目のSPAのテストでした。
この4回目自分がテストしたときは特に①、②、③が怖かったので、全部のページでこの3つを試しました。
そうしたこともありだいぶ不具合の傾向を掴むことができて、ようやくSPAに慣れることができた気がしています（ちなみに1 ~ 3回目ではなかなかテストするポイントが掴めず、ざっくりとブラウザバックや画面遷移に気をつけたほうが良さそうぐらいにしか思ってなかったです）。
これまでは「SPAはスマホアプリみたいなもの」と漠然と思っていたのですが、スマホアプリとはやはり別物ですね。
スマホアプリはWebシステムほど自由に画面遷移することはできないですし、どのページでも更新ができるということはないですし。
また、⑧にも書きましたがよくあるWebシステムとSPAは別物なので、当たり前ですがSPAのときはSPA用の対策を考えたほうが良いと思います。
SPAは少し苦手意識があったのですが慣れてくるとワクワクしてきますね。次またSPAのテストをするのが楽しみです。
もし、他にSPAテスト情報があったら教えていただけると嬉しいです。
(おまけ)たまたま不具合を見つけるきっかけになったマウス
Windowsで使えばマクロ登録できたり特定のキーを組み合わせて登録などできるので便利です。
