仕様スニペット002「アカウントロック」の #テスト設計パターンを考えてみる

5月3日に、2つ目の仕様スニペット・「002: アカウントロック」を公開しました。

docs.google.com

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

仕様スニペット002: 「アカウントロック」

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

ユーザはログインの際に、アカウント名とパスワードが求められます。
※アカウント名・パスワードの文字列長・文字種などについては、議論の対象外とする。

アカウント名とパスワードの組み合わせが正しい場合、ログインが成功します。

アカウント名とパスワードの組み合わせが正しくない場合、ログインが失敗します。

あるユーザ名に対し、ログインが3回連続で失敗した場合、アカウントがロックされます。
※アカウントロックの解除については、議論の対象外とする。

ログインが成功した際に、ログイン失敗回数はゼロにリセットされます。

001が、わたしの意図する仕様スニペットの位置づけに対して少し複雑だったように感じて、今回はかなりシンプルなものです。
今回も、何人かの方が検討をしてくれました。それぞれを読んで思ったのですが・・・、

優秀なQAの人たちの習慣として、仕様を提示されたら、

内部の作りがどうなっているかを想定し、それを開発者に確認しようとする
仕様自体も間違っている、網羅性が低い、考え漏れがある前提で、仕様のより良い姿を見つけようとする

んですよね。
もちろんこれは、いいことだとわたしは思います。ですがそのことが、「テスト設計パターン」の成立を難しくさせるなとも感じました。なぜなら、「シンプルで完全な仕様」というものは、提示し得ないからです。

それはさておき、先に進みましょう。

回答の例

かいりさんの記事

前回に続いて記事化してくださいました。

note.com

どの部分も頷けるものばかりなのですが、特にいいなあと思ったのが、「ロックに至る理由が、3回連続失敗とは限らない」と判断している点です。ユーザのミス以外にもロックさせる契機はありうると考えて、「連続失敗回数」と「ロックされている/いない」の情報は分離されていると想定しているんですね。仕様を鵜呑みにしているだけだと、そこまで考えられないかもしれません。
で、失敗回数・ロック有無の2つの情報と、ユーザ名とパスワードの組み合わせが正しいかという3点をもって、デシジョンテーブルを作成しています。

デシジョンテーブルを書かれる過程を読んでふと思っていたのですが、わたしとは思考の順番が逆かもな？と思いました。
わたしの場合、条件整理→テーブルじゃなくて、テーブルを書きながら条件整理をしているようなところがあります。

おいでさんのコメント

パスワードを忘れた場合のパスワードリセットの仕様を考慮するかしないかが悩みどころかもしれないですね。

パスワードリセット機能や、別の理由（サブスク料金未払いなど）でのアカウントロックについては今回は対象外としますが、これらもこれらで面白そうですよね。

アカウント名hide_ramen_sanのパスワードがpasswordだったとして、hide_ramen_sanでパスワード3回間違えたらロックかかるけど、パスワードpasswordに対してアカウント名を3回間違えても（hide-ramen-sanとかhideramensanとか入れても）ロックかからないという仕様になると思うんですよね。

「パスワード側を固定した不正ログインアタック」みたいなのはかいりさんも言及されていましたが、これも対象外で・・・。