yoshitake_1201’s diary

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

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

2020/10/3 JaSST Online Bergamot に参加した感想 #JaSSTOnline

■ この記事

2020/10/4に行われたJaSST Online Bergamot に参加したときのメモ & 感想です。
うろ覚えなので、何か間違ったことが書かれているかもしれません。
その時はごめんなさい。

jasst.jp

■ S1: 「探索的テストセッション」の内容

  • セッションの流れ
    • 「LIFULLさんの新人研修用システム(SNSっぽいサービス)」をnemorineさんが1時間探索的テストをした動画を流す
    • その動画をみんなで見る
    • 実行委員 & 質問者(3人)が気になったタイミングで動画を止めて質問をする
      • 動画の止めた方は早押しボタンを押す
    • nemorineさんが回答する
    • セッションの時間は2時間(前半1時間、休憩5分、後半1時間)
      → 動画が30分ぐらいたったところでちょうど1時間ぐらい
      → 残り30分も後半1時間(プラスちょっと)で終わった
  • nemorineさんがテストしたときのメタ情報
    • チャーターは用意していない
    • 仕様書は読み込んでいない(3分ぐらい読んだ状態)
      ※ 仕様書に引っ張られず初見の状態でやりたかった(と言われてた気がする)
    • テスト始める前の予定は「学習30分、探索30分」
    • 実際には学習に40~45分ぐらいかかってた
      ※ここでいう学習を「システムの全体像を知る、出来具合を感じる」という意味合いに感じた(よしたけの感想)
    • nemorineさんはこの動画では操作や感想を喋りながらテストをしていたが、普段はここまでの発話はしていない

■ セッション中のうろおぼえメモ(カッコ内敬称略)

・ 個人的にナイスと思った質問

  • 「20分ぐらい触ったときどんな気持ちになってましたか?」
    • 「1時間で動画を取り終わらないといけないけど、意外と時間がかかって焦ってきてました」
  • 「既存のサービスにすごくにてるシステムと思うですけど、他のサービスと比較しながらテストしてますか?」
    • 「そうですね。比較できるサービスは比較しながらテストしてます」
  • 「探索的テストしているときにビジネスとして成功するかも見てますか?」
    • 「普段は見ないです」
    • nemorineさんのお仕事的にはその観点は難しいらしい
  • 「削除したときの動作で『まぁ良いか』って言ってましたが、なんで『良いか』と思ったんですか?」
    • 「気になったけどスルーしちゃってた、削除はずっと気になってたけど…」
    • 触った感じ結構バグが出てたから、動画の時間を考えて少し浅めにテストしようとしてた(OSTでnemorineさんが教えてくれました)

・ 良いなぁと思ったフレーズ

  • 「最初に動かすときは普通のユーザーが動かす形で通したい」(nemorine)
  • 「なるべく初見の状態でシステムと対話しながらやっていきたい」(nemorine)
    • 今回探索的テストしたときに話されていたときの発言(だったと思う)
    • チャーターがあれば探索的テストというわけではなくて、システムの動きを見ながらやっていくのが探索的テストと考えている(nemorine)
  • 「仕様書が怪しくなってくる」(nemorine)
    • 数字の境界値?が仕様書と実装で違ったときに言われていた
    • 「ただの独立したバグ」と捉えずに「このレベルで、仕様書と実装で齟齬がある」という事象(?)として捉えた印象を受けた(←よしたけの感想)
  • 「操作を間違えた現象は大事」(miwa)
  • 「その瞬間しか再現しないバグもある(時間が経ったら再現しなくなるバグもある)」(miwa)
    • バグが起きたとき(& 再現方法がわからないとき)にどうする?っていう質問の流れだったと思う
    • だからそんなときはすぐに開発者(プログラマー)を呼んでログを見てもらっている(miwa)
  • 「探索的迷子」
    • nemorineさんが学習し終わってぐらいのタイミングでどこを(なにを?)テストしているかわからなくなったときにmiwaさんが言った発言(だったはず)
    • miwaさんが言ったわけではなくて、miwaさんの「迷子」というフレーズを拾ったコメントだったかもしれない
    • 「nemorineさんの頭の中にはシステム(or テスト)の全体像みたいなものができあがって、終わったところがわかっている状態なのかな?」っていった感じの質問も印象的だった
  • 「仕様書を見ると仕様にひっぱられる」&「仕様書も疑って良いんだよ」
    • nemorineさんが仕様書を見ないようにしてたのに対するのmiwaさんの発言
  • 「自分も信じられないんだよ」
    • 仕様書も疑って良いんだよ〜のくだりでmiwaさんが言っていた発言

・ 探索的テストをやるタイミングについてのメモ

けっこうバグが出ていたので、この状態で探索的テストするのか?といったコメントやちょっとしたディスカッションがあったのでそのメモ

  • 対応について
    • この状態なら先に「スクリプトテストを通す」(nemorine)
    • ここでいう「スクリプトテスト」は「テストケース/テスト項目所/チェックリスト」といった仕様書と照らし合わせる意味合いのものと思う
    • もし複数人でテストできるなら1人はスクリプトテスト、もう1人は探索的テストといったアプローチをする(nemorine/OTSでの回答)
    • 開発者に差し戻す(講演中に流れたコメント)
  • バグが多い状態での探索的テスト
    • バグが出すぎると探索まで行きつかないので、まだ早い
    • 探索的テストは思考(対話)を継続させるのが大事なので、バグが出すぎるとそっちに気を取られてなかなか難しい

■ 自分たちのチームだったらどうするか?

nemorineさんの今回のアプローチは、「1つの機能を深く」よりも「多くの機能を広く浅く」といった視点だなぁ感じました(もちろんシステムのメイン機能を優先されていました)。 おそらく「動画時間(1時間)という制約」「けっこうバグが多かった」というのを気にされていたんだろうなぁと思いました。 講演中も「この状態なら一旦スクリプトテストにかける」って言われていましたし。自分も「探索的テストにはまだ早い」という印象でした。

コメントでも「この状態なら開発に差し戻す」というのが流れていました。 そのアプローチができるのははとても素敵だなぁと思うんですが、自分たちのチームで考えてみると、この状態でテストを継続することが多々あるなぁと思いました(理由はこのブログでは割愛)。 せっかくなので自分たちのアプローチを少し書きます。

こういった状態でのアプローチは「目についたバグはすべてIssue登録(チケット登録/バグ票登録)してしまう」といった方針が多いです。 ですがこのアプローチは1人でやるととても大変です。 大変なポイントはいくつかありますが、自分が考える1番大変なことは「テスト実行の思考」と「Issue登録」で頭の切り替えが発生することだと思います。 バグバグしている状態でテストをすると切り替えが頻発するので、なかなかに大変なことだと思います。

なので、自分たちが今回のような状態のシステムを探索的テストをするときは、チームメンバーのsaeさんとペアテストという方法をとります。 役割分担はsaeさんが「テスト実行」自分が「バグを登録する」という感じです。 こうするとsaeさんは思考を継続した状態で深くテスト実行に向かいやすくなるし、見つけたバグも同時にIssue登録できるので、2人で別々にテストするよりも格段に良いと自分は感じています。 ペアテストをするときは、隣りあって話しながらテストするので、情報共有も楽ですし。

↑だけ読むと「自分はバグ登録だけしている」と思う方もいるかもしれませんが、そんなことはないです。 自分はバグ登録に集中しているわけではなくて「Issueを登録しつつ、少し離れた視点でシステムを学習している」状態になっています。 なので、saeさんの情報や出ているバグから気になることがあると「あ、〇〇も試してほしい」とか「こうしたらどうなる?」といった感じで自分が気になるテストをsaeさんにやってもらいます(「それ今やってる」って返ってくるときもよくあります)。 また、何かよくわからない現象(例えば、nemorineさんのセッションだと一覧がループ表示になったとき)とかは、自分もバグ登録の手を止めて、そのバグの原因を探すべく2人で深くテストをします。 バグ登録する側も学習しつつ状況に応じてテスト実行に加勢するという感じです。

こうすることで、先にあげた「思考の切り替え」が1人でやるときよりも小規模になり、また思考の手助けがほしいときはすぐに増員できるので、1人よりもだいぶ楽にそしてたくさんの学習をしながらテストをすることができているなぁと思いました(とはいえ、全く疲れないなんてことはなくて、ペアテストが終わった後はお互いに疲弊しています) 。 探索的テストは本当に頭を使うので、今回のnemorineさんは1人でしかも発話もしながらと本当にすごいかったです。

余談ですが、今回↑の文章を書いているときに「深い視点で考える」saeさんと「浅い視点で考える」自分とで、2つのアプローチを同時に行えていることに、改めて気づきました。 良い機会となりました。

※ (参考)以前ペアテストについて書いたブログ
ペアテストを1ヶ月間やり続けてみてよかったこと - yoshitake_1201’s diary

■ 質問者として参加した感想

  • 早押しボタンのおかげで動画を止めやすかった
    • はい!って声を出すよりも動画を止めやすかった(音のせいにできる)
  • ボタンの音が配信に載っているのが良かった
    • ボタンを押したことが全体に伝わる
    • ボタンに不具合があったら質問者にもそのことが伝わる
  • 他の方の質問にのっかりやすいのも良かった
  • 質問のあとに実行委員長が補足質問をしてくれることが多かった
    • おかげで質問しやすかった
    • 変なこと言っても救ってくれる安心感がありました
    • ありがとうございました
  • メントスクリーンで質問が流れるので、その質問を選択することもできる
    • 別画面に質問があっても、それを見るのは難しいだろうなぁと思ったので、この機能はとても良かった

■ 全体の感想

  • nemorineさんが何を気にしているのか(視線/視野?)が、録画越しでもなんとなくわかった
    • ここにバグがあるけど、nemorineさん今は気づいてないかも、っていうのをなんとなく感じた
    • 自分もこう言う感じなんだろうなぁと思った
  • 以下を同時にやっているnemorineさんとてもすごい
    • 収録中: 思考を維持しつつ、バグのメモとりつつ、気になったことを発話
    • 講演中: 当時を思い出しながらの質疑応答
  • 探索的テストはとても頭を使う(ものだと思う)ので、本当にすごいなぁと思った
    その上わかりやすいし…すごかった。講演中の動画がもう1回みたい
  • メントスクリーンが良かった
    • 参加者のコメントがコメントスクリーンで配信映像に乗るのでおもしろかった
    • コメントに書かれている観点についても、色々考えることができたので良かった
  • 質問が良い感じの休憩になっていた
    • ずっと見続けてしまうと自分は本当に疲れてしまうのでありがたかった

「実験的な試み」と会の始めに言われていたけど、コメントスクリーンや質問者オプションはとても考えられていて素敵だなぁと思いました。質問者も三者三様の質問だったので面白かったです。miwaさん、かみむらさんの質問の観点素敵でした。勉強になりました。

人がテストしているのに対して何も言わずに見るという経験がなかったので、とても新鮮でした。人がテストしていたらその場で話しちゃうし。考えてみたら「自分がテストしている」のを見ることもないですね。今度やってみようと思いました。1時間は大変なので30分ぐらい。

参加できてよかったです。ありがとうございました。