ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

仕様スニペット003「ログインパスワードの再設定」の #テスト設計パターン を考えてみる

テスト設計・技法

5月19日に、3つ目の仕様スニペット・「003: ログインパスワードの再設定」を公開しました。
2つ目まではわたし自身が作っていたのですが、3つめはかいりさんがネタを提供くださいました！

docs.google.com

「テスト設計パターン」「仕様スニペット」って何？という方は、こちらの記事を先にご覧くださいね。

www.kzsuzuki.com

仕様スニペット003: 「ログインパスワードの再設定」

以下の仕様に示されるアカウントロックについて、テスト観点を考えてください。

  1. メールアドレスを入力すると、そのメールアドレスに再発行URLが送信される。
  2. 再発行URLにアクセスすると、パスワードを再設定することができる。
  3. URLは、発行後30分間有効である。

002と比べても、かなりシンプルですよね。仕様スニペットがシンプルであるほど、テスト観点がソリッドになっていくと思うのですが、その分コンテキストが失われて議論しづらいというトレードオフ。。

回答の例

鈴木の場合

わたしの頭に浮かんのは、こんな感じです。
頭に浮かんだ順ではなく、ちょっと整理しています。

ハッピーパス
  • 実在する正当なユーザによるハッピーパス
    • 再設定したパスワードでログインできるか
  • 再設定は複数回行えるか
メールアドレスの有効・無効
  • 登録されていないメールアドレスに対しる再設定要求
    • 「登録されていないメールアドレスである」情報を開示するかどうかのポリシー確認
  • RFCには従っているけど通常は使われない記号の場合も対応できるか
設定パスワードの有効・無効
  • パスワードのルールはどうなっているか
    • 初期設定時と変更時でルールが違うとバグの予感がする
    • 変更「前」と同じパスワードは設定できるかのポリシーも確認したい
URLの有効・無効
  • URLが、30分以内は有効で、30分以降は無効になるか
    • 厳密な境界値テストはできないけれど、そこまで厳密さはいらないと想定
  • URL期限切れ前に再度、再設定要求した場合の挙動
    • 先にもらった方のURLは無効化されるのではないか
      • 無効化される前に開いておいた画面でパスワード変更できるのか？
セキュリティ
  • 故意に他人のメアドの再設定しようとする攻撃をされても、メアドの所有者に害はないか

みわさんの場合

個々の観点も良いのですが、「そのための行動」として過去チケットを検索するというのがとても良いですね。
バグチケットを蓄積してきた組織は、生成AIの普及に伴って強力な”チカラ”を手にするんじゃないかと思います。

以下が、過去事例として出たものとのこと。これを逆引きすればテスト観点にもなりますね。

・パスワードを自動生成する機能を利用すると画面がフリーズする
・パスワード再発行できない
・パスワード再発行してもログインできない
・パスワード再発行が利用できない
・パスワードリセットなど一部のメール送信に失敗していた
・自動ログインせず、ログイン画面になる
・再設定後、ログイン画面でパスワードを入れても認証エラーになる
・特定のブラウザでパスワードの再設定ができない
・言語設定が「日本語」だとパスワードが設定できない
・パスワード再発行のメール配信に大幅な遅延が発生した
・必須ではない項目をパスワード再発行の確認手続き項目に使用していた

この5つ目「メール送信に失敗」で思い出したのですが、送信ドメイン認証をパスしないメールを拒否している場合もあるよなあと。メールの不達ケースは重要なポイントですね。

Cazunari Murahoさんの場合

有効期限切れの URL にアクセスした時に、ユーザ向けの画面が表示されるか

これは基本パターンとして必須ですね。

やまずんさんの場合

・基本的に仕様コピペで確認しますが、再発行したあとのアカウントでのログインとか、再発行を2回した場合に1回目のURLはどうなるかとかは気になりそうです。
・「再設定後にそのURLが無効になるかどうか」は意外とまだないのか
・URLが無効になるきっかけが期限切れ以外にあるのか？(この場合設定した場合は？)
・再発行URL改ざんしたら別の発行URLに飛ぶと草

この2点目でハッとしたのですが、「Aの場合にBとなる」という仕様を見たら、「Bとなるケースはそれ以外にないのか」を考えるというのは良いテスター仕草という感じがしますね。002のアカウントロックでも、似た話がありました。

今回「払い出されたURLが無効になるのはどんなケース？」と考えると、以下のケースがありそうです。

  1. 30分の期限が切れた
  2. パスワードの再設定に一度利用された（仕様確認）
  3. 別のURLが新たに発行された（仕様確認）

𝓜𝓪𝓼𝓪𝔂𝓾𝓴𝓲 𝓣𝓪𝓬𝓱𝓲𝓫𝓪𝓷𝓪さんの場合

絶対にやれないと思いますが、入力されたパスワードが過去に漏洩したパスワードかをダークウェブ検索サービスで検索し警告を促すシステムかどうか。

これはまったくの想定外でしたね。パスワード設定機能において、こういうのが合ったら面白そうです。

おいでさんの場合

前のパスワードが使えなくなることの確認もしないといけないと思ってる

シンプルですが、まずハッピーパスの確認観点として必要なものですね。

rinoさんの場合

非機能（≒仕様スニペット外）
・複数リクエストで有効なURL
・メールアドレスが存在しなかったときの挙動（公開とイントラで出方変わるはず）
・再発行が要求できる時間間隔

他機能への影響
・ログイン中にパスワード再設定したときのログイン状態
・発行～再設定間で現行パスワードでのログイン

「他機能への影響」が、わたしの思いついた観点では漏れていました。次の画面遷移時の強制ログアウトが正しい気がしますが、仕様確認が必要ですね。

おわりに

仕様をここまでシンプルなものにしても、けっこう観点が出てくるものですねー。一方シンプルなだけに観点の方向性が発散せず、よい例題だなーと思いました。

実はかいりさんはもう1つネタをくれているので、近々004を公開したいと思います！