Webアプリテスト：実行時にしか現れない不具合

Webアプリテストが対象とすべき3つの実行時不具合

その大半を捉えるチェック

同じ操作を、異なる2人のユーザーとして、間にリロードを挟んで2回実行します。このパターンひとつで3つのカテゴリすべてに当たります。そして、1回目がうまくいったという理由で手動テストが省いてしまうのが、まさにこれです。

何を検証するか

• リロードすれば確認できること。 成功メッセージは、何かが永続化された証拠にはなりません。対象を取得し直して確かめます。

• あってはならないものが存在しないこと。 削除後は行が消えています。サインアウト後はデータが見えません。

• 別の人から見た挙動。 2つ目のアカウントから、1つ目のアカウントのレコードは見えません。

ローカル開発をどう位置づけるか

Webアプリの作業は、デプロイのはるか前からlocalhost上で進みます。公開URLに対してしか動かないチェックでは、作るものを変えるには遅すぎます。CLIはフロントエンドの実行時に自分のマシン上で動くアプリへトンネル接続できるため、作業中でもチェックを利用できます。詳細は CLIリポジトリ。

ローカルにインストールしたくない場合は、ダッシュボードが同じ範囲をカバーします。

2つのタブによるテスト

リリース前に手動で行う価値のあるチェックが1つあります。かける手間以上の発見があるのに、ほとんど誰もやっていません。アプリを2つのタブで開くことです。

1つ目のタブで何か操作し、2つ目のタブを見ます。多くのWebアプリはここで何らかのおかしな挙動を示しますが、そのおかしさには情報があります。リストが更新されないのは、たいてい問題ありません。古いままの操作が成功し、より新しいデータを上書きするのは、本物のバグです。一方のタブがトークンを更新したときにもう一方のタブがログアウトされるセッションも、本物のバグです。決して整合が取られない楽観的更新も、本物のバグです。

所要時間は2分、ツールも不要で、サーバーの状態、ブラウザの状態、ユーザーの期待が食い違う、まさにその継ぎ目を突きます。このページから習慣を1つだけ取り入れるなら、これにしてください。

継続的に実行する

実行時の不具合は、まさに再発する種類のものです。それを生む条件は、意図せず再び作り出されやすいからです。

• GitHub App は、TestSpriteのダッシュボードで設定するwebhookです。パイプラインがすでに発行しているデプロイイベントを監視するため、リポジトリ側は何も変わりません。

• GitHub Actions は、そのステップを自分のワークフローの中に組み込み、ターミナルから設定します。

TestSpriteが動作中のアプリをどう動かすか

デプロイ済みのアプリケーションを開き、人がするのと同じように操作します。残留した状態、データ到着前のレンダリング、2人目のユーザーの挙動を確認できるのは、この方法だけです。テストケースは平易な言葉で記述され、対象のプロダクトから生成されます。検証するのは、クライアントが表示したメッセージではなく、リロードすれば確認できる事柄です。

2人目のユーザーの確認は、準備作業ではなく一級のテストケースとして扱われます。これが重要なのは、権限に関する仮定が、顧客のもとに届く可能性が最も高く、その機能を作った本人が最も気づきにくい不具合だからです。

以後、チェックは変更のたびに実行され続けます。一度バグを生んだ3つの状態の食い違いが、ブランチのマージ後に静かに再発することはありません。