yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

バグを逃してしまったときにチームでやること #テストアドカレ

qiita.com

この記事は、ソフトウェアテストアドベントカレンダー2021の1日目です。

先日友人に「バグを逃してしまったときどうしてる?」と聞かれました。 そこで自分たちのチームがバグに気づけなくて逃してしまったときはこんなことしてるよ、という話をしたのでその内容をブログに書くことにしました。

逃したとき

バグを逃してしまったとき、自分たちは「そもそもそのバグに気づくことができたかどうか」を考えます。 気づく実力があったかどうか、という意味合いが近いかもしれないです。 ただどちらにせよ、逃している時点でその実力はなかったと言われるとその通りです。 「他のプロジェクトでテストしたときは逃さなかったバグかどうか」を考える という感じが近いと思います。

自分たちの実力ではそもそも気づけなかった場合

自分たちの実力ではそもそも気づくことができなかっただろうものについては、以下を行います。

  • バグについてエンジニアに聞く
  • バグに関係することを調べる
  • どういうテストで見つけれるか考える
  • どうやったら↑のテストをするようになるか(したくなるか)を考える

「エンジニアに聞く」「調べる」は、何が原因だったのか、どんな条件で起きるのか、どんな対応をしたのか、このバグから他にどんな事が起きるのか考えるなどをやります。 自分たちが気づきようがなかったので徹底的に調べます。

それが終わると、次は「どんなテストで見つけれるか」「どうやったらそのテストをするようになるか」を考えます。 ここでどちらかというと難しいのが「どうやったらそのテストをするようになるか」です。 「このテストをやればこのバグはみつけられるぞ!」と思っても、そのテストをやるようにならないと意味がないですよね。 しかし、このとき考えたテストは自分たちにとって完全に新しい取り組みなので、うまいことやらないとなかなか自分たちの動きに馴染んでくれません。 そこで「どうやったらこのテストを自然に気付けるようになるか?自然にやるようになるか?やりたくなるか?」を話します。 話している途中にこれが決まらない場合は、また「どんなテストで見つけれるか」を考え直します。 「このテストをやれば見つけれるよね、意識して頑張ってやろう!」と言いたくなる気持ちはわかるんですが、現実問題そのテストをやるのが難しいということもよくあります。 また、意識しようと思っても体に染み付いた考え方を変えるのはなかなか難しいです。 なので、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込める/拡張するよう考えるようにしています *1

自分たちの実力で見つけれたかもしれない場合

次に「自分たちに気づく実力があったけど気づけなかった場合」の話です。 繰り返しになりますが「そもそも気づけてないのでその実力がなかった」のはごもっともです。 「他のプロジェクトでテストしたときは逃さなかったバグだけど逃してしまったバグの場合」です。

この場合、まず以下を考えます。

  • テスト中どの瞬間に気づけたか
  • なぜその瞬間にテストをしなかったのか

「普段なら気づけたはずなのに気づけなかったと思う」ということは、普段とは違う何かがあったということですよね。 なので、普段ならどの瞬間に気づけたんだろうかを探します。

その瞬間が見つかると次に「なんでそのテストをやらなかったのか」を思い出します。 その場面を思い出すと、自覚してやらないを選択したのか、無自覚にそのテストをやらなかったのかなどがわかるので、そこからさらに「その選択をした理由」または「そのテストをやらないようにさせた要因」を辿ります *2。 ここで出てくる例としては「データの準備が大変だからケースを減らした」「直前に大きなバグが直って安心してしまった(油断)」「既存のシステムをコピーするだけだから大丈夫(油断)」「余裕がなかった」などがありました。 そしてさらにこれらから「なんでその判断をしたの?」や「なんでその状況になったの?」をある程度繰り返し考えていきます。

例えば「無自覚にそのテストをやらなかった」要因が「余裕がなかった」としたとき「なんで余裕がなかったんだろう?」を考えます *3。 すると「デグレや再確認が多くて疲弊してた」とか「仕様変更が多くて…」とかそういったものが出てくるので、また「なんで?」を考えるという感じです。

ある程度繰り返して要因を出し終わると、それぞれの要因に対して「その状況にならないようにするにはどうするか」「その状況になってしまったときどうするか」「どうやったらその状況になっていることに気付けるか」を考えます。 先程まで挙げたものだと以下を考える感じです。

  • 余裕がない状況にならないようにするにはどうするか
  • 余裕がないときどうするか
  • 今余裕がない状況になっていることにどうやったら気付けるか
  • デグレが多いときどう立ち回るか
  • 疲弊してることにどうやったら気付けるか
  • 油断していることにどうやったら気付けるか

ここで特に気にしているポイントは「どうやったらその状況になっていることに気付けるか」です。 「余裕がない」「疲弊している」ときは 本人はその瞬間は自覚がないことが多くて、プロジェクトが終わった後にふりかえってみると「あー、あのとき余裕なかったな」と気づくことが多いです。 なので「余裕がないときこういう風に立ち回ろう」と決めても「余裕がない状況になってることに気づけてない」ため、せっかく立てた対策が実行できなくなってしまいます。

もちろんここで考える内容も、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込めるように話し合います *4

おわりに

ここまで自分たちのチームで、バグを逃してしまったときどうするかを書きました。 どちらの場合も時間はだいたい30分ぐらい、長くても1時間ぐらいで終わります。 かなり頭を使って話すので時間にすると意外と早く終わります。何より1時間以上は頭が持ちません。

今回は逃してしまったバグについて書きましたが、「このバグよく見つかったね」というのも↑のように考えたりします。 ものにもよるんですがラッキーで見つかったようなバグは特に。 運も実力の内とは言うけど、そういうのは次回は実力で見つけたいですよね。

そしてここまで淡々と書いてきたのですが、バグを逃すことはもう本当に絶対1番やりたくないことだなぁと思います。 申し訳ないし、悔しいし、もうその他色んな感情が吹き出して未だに取り扱いに困ります。 でも、そのバグを逃さないように新しく取り組みを始めたせいで、これまで普通に見つけれていたバグが見つけれなくなるのも嫌です *5。 テストのデグレ、イヤですね。 なので今できていることは守りつつ、ちょっとずつ丁寧に対策していけたらと思っています。

*1:根本的に変えないといけないこともありますが最近はあまりないです。どうやっても難しいときはあきらめてやります。

*2:なんでそのテストしたのか/どういう事考えてテストしたかなどその場面を事細かく覚えているのはテスターあるあるな気がする(もちろん覚えてないときもあるけど)。

*3:「余裕がなかった」で終わるふりかえりは苦手なんですが、「なんで余裕がなかったんだろう」を考えるのは好きです。でも「時間がなかった」「考慮漏れ」というワードが出てくるのはなんか苦手です。

*4:それぞれの役割で考えます。 テスト実行する役割だったら/テストを指示する役割だったらなど。

*5:チームメンバーのsaeさんが「新しく取り組むのは良いけどそれをやると今できていることができなくなる気がする。そのほうが嫌」と言ったことがあって確かに!と思った。

第157回テストラジオのメモ-シナリオテストとデータ移行の回 #テストラジオ

第157回テストラジオで話したことのメモです。
本編はこちら

話したこと

  • シナリオテストの話
  • データ移行でみつかった不具合の話

今回はなそさんと自分がそれぞれ話したいネタを1つずつ話しました。

シナリオテストの話

なそさんが今回のラジオで話したかった話。
ここではシナリオテストとは「業務シナリオや業務フローをもとにテストしていく」といった意味合いで使いました。
「シナリオテストを作って欲しい」となそさんがメンバーに依頼したら、お互いに想像していたものが違って「あれ?」となったというのがこの話。 「シナリオテストを作る」という経験が自分にはあまりないので、なかなか新鮮な話でした*1

自分は「シナリオテスト」というワードに引っ張られて、収録直前の週にある社内システムの仕様(操作)を教えてもらったという話をしました。 この社内システムの追加開発でテストが必要になったけど、テストチームがほぼ触ったことが無いシステムなので、 せっかくなら社内で実際に使っているメインユーザーに仕様と操作を教えてもらおうと思った、というのが経緯です。 自分たちがテストする時に「ユーザーはどんな操作をするだろう?」「どう思って操作するだろう?」と想像することはもちろんあるんですが、 「ユーザーが実際に触っているのを見る」機会がなかったので、レアな経験でした。

説明してもらいながら実際に普段の操作をしてもらったので仕様や動かし方を知ることができたのですが、 個人的にはそれよりもちょっとした操作の癖や入力の順番を見れたことがとてもよかったです。 (おそらく)開発した当時は想定してない部分から検索したり、 あるデータを登録するときには「最初に一部のフォームに値を入れて登録して、後日、編集画面から残りのフォームに値を入力する」などなど。

シナリオテストを考えるときにはこういった操作まで細かく想像することも大事なんだろうなぁと思いました。

※ メモ ISTAB(JSTQB)では「ユースケーステスト/シナリオテスト/ユーザシナリオテスト」として以下のように定義されている。

ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。

https://glossary.istqb.org/jp/search/%E3%83%A6%E3%83%BC%E3%82%B6%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA

データ移行でみつかった不具合の話

よしたけが今回のラジオで話したかった話。
ここで自分はデータ移行を「システムをリプレイスするときに既存のシステムからデータを移行する」 「現行システムがない場合は、新システム利用開始前にデータを注入する」といった意味合いで使いました。 自分のチームはデータ移行(のテスト)に関わることがあまりなかったのですが、珍しく関わって「データ移行らしい不具合」を見つけましたというのがこの話です。
※ 実際のデータ数はかけないですが、1レコード20カラムぐらいで500レコードぐらいあるといった感じざっくりな想像でOKです。

ラジオ本編では以下のバグの話をしました。

  • 必須のカラムが空になってるものがあった
    • システムを動かすと500エラーが起きたのでわかった。
  • あるカラムの数値データがおかしくなってるものがあった
    • システムを動かしていたら気づいた
    • データ注入前にエクセルでデータを弄ったらエクセルの書式によって値がおかしくなったっぽい。
  • あるカラムに改行が反映されてなかった
    • システムを動かしていたら明らかに改行されてそうなものが改行されてなかったので気づいた

自分たちがデータ移行のテストをする前に、もちろんエンジニアも注入するデータのチェックをしてくれてたので、基本は問題なかったんです。 一部のデータだけで起きていたので見つけれてよかった。

ラジオ本編やツイキャスのコメントで以下のようなこともありそう、というのをなそさんが教えてくれました。

  • 移行するとき、新システムへデータの入れ先がない(逆もありそう)
  • リレーション間違い(IDがくっつく予定がIDがないとか)
  • 売上データと思ったら明細は仕入れデータだった(データの勘違い)

また、自分が使っている「データ移行のテスト」というのは「現新比較」(現新比較テスト/現新比較検証)というそうですね。
知らなかったので勉強になりました。

ラジオ収録外で話したこと

・年が明けてから音声問題に悩まされいる
 収録ソフトのノイズキャンセルと使っている機材との相性問題なのかなんなのか、なかなか難しいですね。 この回はその調整に1時間ぐらいかかったので、なかなかもどかしい。 これが解決したときはすっごい気持ちいいんだろうなぁ。

*1:シナリオテストをしないわけではないけど、まだまだ甘いので今後やり方を極めたいなぁと思った

第156回テストラジオのメモ-雑談ベースドテストの回 #テストラジオ

第156回テストラジオで話したことのメモです。
本編はこちら

話したこと

  • オンラインで会話する時の音質問題
  • 雑談ベースドテストの話

オンラインで会話するときの音質問題

オンラインで会話するとき、自分の音声が正しく聞こえているかわかりにくいよね、というイントロでした。
特に答えはないんですが、難しいですよね。

雑談ベースドテストというなのながらテスト

前回のラジオの最後に「雑談ベースドテスト」というワードだけが出て終わったのでその説明をしました。
それっぽい感じで書いてますが「雑談しながらテストしたらバグが見つかった」ということを、冗談めかして「雑談ベースドテストだね」と笑っていたというものです。「雑談ベースドテスト」というワードは自分が作った造語です。

ただ、せっかくなので、このワードが生まれた時の状況を分解してみました。 詳細についてはラジオ本編で話したので、そちらをお聴きください。 雑談をする = 肩の力が抜けているというときだからみつかりやすいものもあるのかなぁと思いました。 ただ一応補足すると、テストは雑談しながら(ふざけながら?)できるものではないので、そのように捉えた方がいたらすみません。

また上記の状況の説明とはちょっと状況が異なりますが、テストを黙々とやっていてふっと休憩した時、何か新しいテストや不具合のありそうな場所をひらめくというのがあるよね、という話をしました。
自分がラジオ収録当日にたまたま見た「奇跡体験!アンビリーバボー」の再放送で「G-SHOCK」と「QRコード」の開発秘話を取り扱っていたので、それを例に出しました。

それぞれの開発秘話はすごい話だったので以下の記事などをぜひ読んでみてください。
www.itmedia.co.jp

toyokeizai.net

ラジオ収録外で話したこと

収録当時、時間がなかったので特になし

第155回テストラジオのメモ-Firefoxで見つけた不具合(挙動)の回 #テストラジオ

第155回テストラジオで話したことのメモです。
本編はこちら

話したこと

  • Firefoxで見つけた不具合(挙動)の話

Firefoxで見つけた不具合(挙動)の回

あるSPAのシステムをFirefoxで動かした時、「〇〇の取得に失敗しました」というエラーメッセージが大量に出るという不具合に遭遇しました。 その不具合の調査をしてもらったところ、ある操作をしたときにこのissue と同じような現象が発生していたそうで、そこを回避するように対応してもらいました。
ただこの不具合はChromeでも実は起きていたけど、Chromeが良い感じに表示しないようにしていて、Firefoxは素直にエラーを表側に表示していた、ということらしい。 これをかなりの短時間で調査して解決してくれたのですごいなぁ…という話でした。

また、原因がわかったあとに該当プロジェクトのチャットで「マイクロソフトの新「Edge」、グーグル「Chrome」との重要な相違点は」の記事の以下の部分を共有してくれたメンバーがいました。

かつてはW3Cのような独立した標準団体がウェブを取り仕切り、競合するブラウザはその標準に従う必要があった。今の「標準」はシンプルだ。「そのページはChromeで表示できるか?」

これを読んで「Chromeでは問題なかったからFirefox側がおかしいとテスト中の自分は思っていた」なぁと思いました。 無意識に先入観があったなぁと。 だからどうこうという話ではないですし、うまいこと言語化できないのでここでは書かないですが、印象的だったのでメモしました。

japan.cnet.com

ラジオ収録外で話したこと

収録当時、時間がなかったので特になしw

第154回テストラジオのメモ-RTA in Japanドラクエ3について話した回 #テストラジオ

第154回テストラジオで話したことのメモです。
本編はこちら

話したこと

RTA in JAPAN 2020 ドラクエ3 ホットプレートでバグコントロールの話

www.youtube.com

2020年12月27日 ~ 31日にかけてRTA in Japan 2020が開催されました。 その中のドラクエ3のany% RTAで新記録が出たのですが、 その新記録を出すために必要なバグを出すために、ホットプレートを使ってゲーム本体の温度をコントロールした、というのが話題になっていました。

ラジオ本編ではねとらぼさんの記事と電ファミニコゲーマーさんの記事を参考になそさんと盛り上がりました。

nlab.itmedia.co.jp

news.denfaminicogamer.jp

このバグ、ファミコン本体の個体差で起きる/起きないがあり、バグが起きる個体でも起きるときと起きないときがあるらしい。 そこで温度が密接に関わっている、っていうところまで突き詰めたのは本当にすごいなぁと思いました。 解説の方も「30分 ~ 1時間プレイするとバグり方が安定してくる」って言っているので、この点から原因を探っていったんですかね?
また、ひっしーさんは本体ガチャを行った桁数が3桁もあるとのこと。その熱量がすごい。 他の方もバグった画面のままでゲームを進行するのも普通にやっているのでやりこみ具合がすごいなぁと思いました。
※ ちなみにひっしーさんは電気工事系の資格をもっているらしい。

今年やりたいこと

  • こんな感じでラジオのメモをブログにする
  • 半期目標は国語辞典で知らない単語を100個調べる

国語辞典で知らない単語を調べる、っていのはチームメンバーのパクリです。 この目標、見ていてとても楽しかったので自分でもやってみようと思います。

ラジオ収録外で話したこと

鉄騎というゲームがかっこい
www.youtube.com

RTA in Japanの動画にあったのですが、操作している方のコントローラーがめっちゃかっこよかった。
調べたら専用コントローラーらしく、左右のスティックだけでなく、足のペダルまであるものらしい。
めっちゃかっこよかった。

www.famitsu.com

ソフトウェアテストで利用している便利なサイト7選

この記事は「ソフトウェアテストの小ネタアドベントカレンダー2020」17日目の記事です。
qiita.com

2018、2019とソフトウェアテスト小ネタアドベントカレンダーに参加してその年に使っているツールを紹介する記事を書いていました。今年はそこまで新しいツールを使っていないので、 今回はよく使っているサイトを7つ紹介します。
※ 過去の記事 yoshitake-1201.hatenablog.com qiita.com

■ 今回紹介するサービス

  1. 文字列ジェネレーター
  2. 文字数カウント
  3. 日数計算(日付−日付)
  4. いま(当時)、何歳?
  5. 疑似個人情報データ生成サービス
  6. 【ユーザーエージェント確認】ブラウザの種類とバージョンの確認
  7. Testaro (ダミー画像生成)

1. 文字列ジェネレーター

lazesoftware.com

LAZE SOFTWAREさんの、文字列を指定文字数分作成してくれるサイトです。
文字列の種類にサロゲートペアや機種依存文字も出力でき、URL エンコード/デコードもしてくれたりと多機能です。 サイト側で登録されている文章にすることもできるので面白いですよ。
ランダム生成される文章で自分のお気に入りは↓です。

雨ってゅうのゎ。。9割以上が水分。。。そしてきゅうりも、9割以上が水分。。。そぅ。。これゎもぅ。。。雨=きゅうりってゅうコト。。。空から降る一億のきゅうり。。。もぅマヂ無理。。。浅漬けにしょ。。。。

2. 文字数カウント

phonypianist.sakura.ne.jp

Sundry Streetさんの、フォームに入力した文字をカウントしてくれるサイトです。
改行を除いたケース、改行/空白を除いたケースや、バイト数なども表示してくれます。 フォームにコピペするだけでカウントしてくれるので便利です。

3. 日数計算(日付−日付)

keisan.casio.jp

Ke!sanさんの、日数をカウントしてくれるサイトです。
初日を含む/含まない設定はもちろんのこと、日数/週数/月数などもまるっと表示してくれるので便利です。 日数計算って難しいし、認識がずれやすいポイントですよね。だからこそしっかり計算しておきたいですね。

4. いま(当時)、何歳?

keisan.casio.jp

こちらもKe!sanさんのサイトです。
「生年月日」と「知りたい時点の日付」を入力すると年齢を教えてくれます。 誕生からの経過年数や、次の誕生日までの残り日数なども表示されるので、状況によって重宝しています。

Ke!sanさんは、他にもさまざな計算サイト(ツール)を運営してくれているので見てみると面白いですよ。 営業日や銀行のカレンダーなどもありますw

5. 疑似個人情報データ生成サービス

hogehoge.tk

hogehoge.tkさんの擬似的な個人情報を生成してくれるサイトです。
2017年の小ネタカレンダーで なそさんが テストデータの人名を「ああああ」とかにしてませんか?簡単にデータを作成してみませんか?という記事で紹介してくれてました。 この記事でこのサービスの存在を知り、活用させていただいてます。 このサービスのすごいところは、1つのデータ内の郵便番号/住所/電話番号の市外局番/がちゃんと対応づいてるところです。 ほんとに本物かと疑うレベルです。すごいですね。

最近うちのチームメンバーのsaeさんが投稿した話しかけると褒めてくれるSlack Botが賢くなったでも活用しています。

devtest.hatenablog.com

ito128.hatenablog.com

6.【ユーザーエージェント確認】ブラウザの種類とバージョンの確認

aprico-media.com

Apricoさんが公開しているユーザーエージェント情報を出力してくれるサイトです。
確認したいブラウザでアクセスするだけで、ユーザーエージェント情報を表示してくれます。 自分は以下の記事でiOSのバージョンとSafariのバージョンの対応を管理しているのですが、この記事をつくるときに利用しています。

qiita.com

7. testaro (ダミー画像生成)

testaro.somewhere.gq

@jesus_isaoさんが作ったサービスです。
今年のソフトウェアテストアドベントカレンダーの2日目に[個人開発] ありそうでなかった、ダミーファイル生成サービスを作ったという記事で紹介してくれてました。 ダミー画像の縦幅/横幅を良い感じに指定できるのがとても便利です。 早速使わせてもらい重宝しています。

qiita.com

おわりに

この17日目の記事ですが、12/17の70時30分00秒に記事を公開しましたということでひとつ… (公開が遅くなってしまって本当にごめんなさい。

他にもいくつかあるのですが、それはまたの機会に。 こうやっていろいろサービスを公開してくださっているので、日々楽にテストすることができています。 ありがたいです。

SPAのテストをするときに気にしたほうが良さそうなこと #テストラジオ #テストアドカレ

この記事は、ソフトウェアテストアドベントカレンダー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度アクセスしてみる」というのもやってみると良いかもです。

  1. ユーザー情報の編集ページを表示する
  2. いくつかのフォームの値を書き換える
  3. 更新ボタンを押さずに、「ユーザー情報の編集ページ」へのリンクをクリックする

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で使えばマクロ登録できたり特定のキーを組み合わせて登録などできるので便利です。