テスト設計パターンを考える遊び #2 の話

より単純な、仕様スニペット002を考えてみました。#テスト設計パターン 検討のため、「思いつくテスト観点とその理由」を教えてください！ 勢いで書いたので、いろいろ足りないかも。
てか、これが実はわたしの副業（やってないけど）のアウトソースだったら面白いなｗ pic.twitter.com/UYWv3aDGe0

— Kazu SUZUKI (@kz_suzuki) May 3, 2024

Twitterで見かけた上記の課題、面白そうなので自分もやってみることにしました。

自力でこれっぽいフォームの実装……とか考え始めるときりがないのでテスト設計のほうを考え始めることにしました。
結論的にはなーんもわかりませんでした！（自分の脳内のことはちょっとわかった）

仕様の整理

とりあえずシステムの現物がないので、イメージをつかむために仕様を整理します。

1.ユーザはログインの際に、アカウント名とパスワードが求められます。

• とりあえずログイン画面のUIの話ですね。

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

• 本当は絶対この仕様は駄目だと思うんですが、userテーブルからアカウント名の入力情報を元にaccountカラムの内容が一致するデータを引っ張ってきて、passwordカラムの内容が入力したパスワードと一致したら通してあげるということにしましょう。

• MySQLのクエリで言うとselect password from user where acount = 'ここにアカウント名欄の入力内容';で出てきたやつ＝パスワード欄の入力情報と比較する感じです。他に表現が思い浮かばなかったので、こうしておきます。

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

• 2以外のときは失敗します。省略。

4.あるユーザ名に対し、ログインが3回連続で失敗した場合、アカウントがロックされます。

• ユーザ名はとりあえずアカウント名と同じということにしておきます。するのだ。

• とりあえずログインを試行したらuserテーブルで該当アカウント名のcountカラムを+1にするようにしておきます。

• さらにアカウントロックするときはlockedカラムが0→1になるようにしましょう。なんかこういうルールが多い気がするので。

• countカラムの値が3になったらlockedカラムが1に切り替わるイメージでいきます。

• countカラムの値は3とし、それ以上は増えないものとします。

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

• userテーブルのcountカラムの値が0に戻るということにします。

• アカウントロック解除の仕様はないらしいので、lockedカラムが1になったら0には戻らないはず。

文章で書くと分かりづらくなってきたので画像をくっつけます。
userテーブルはこんな感じ。

userテーブルのイメージ

テストの見ていきたいところの列挙

自分はこういうところを見たいなという気持ちです。気持ち。
↑で考えた仕様の焼き直しが入ります。

UI

• フォームはちゃんと動くか確認したい。

  • これはコンポーネントテスト。

• 空白で突破されないか確認したい。

  • これはコンポーネントテストなんだろうか。

• 回数ごとの「あとn回失敗でアカウントがロックされます」的なメッセージを出すならそれも確認しておきたい（そもそも何回目から出すのがいいんだろう）。

  • ログイン試行の許容回数にもよるけど、２回目失敗したら「あと1回失敗で（以下略）」になるのかな。

• すでにロックされたユーザーはエラーメッセージちゃんと出る？

  • count=3になったらこの動きでひたすらループする？

承認の動き

• passwordやcountの値は空白を許容しないようになっているか？

  • これはUIからのテストではなくテーブルの設定で確認したほうが良い気がする。こういうテストなんていうんだろう。

• ログイン成功したらちゃんとcountをリセットするか。

• ログイン試行回目の境界値のパーティションは以下の通り？＝境界値テスト

  • ログイン回数1回目　count=0（有効値の下限）

  • ログイン回数3回目　count=2（有効値の上限）

  • ログイン回数4回目　count=3（無効値の下限）

テストケースのようなものをまとめる

以上のことを踏まえて、UI以外の実際に入力してやる値とかはこんな感じでまとめます。
テストケースってこういうやつのことでいいんだっけ…？という謎はあるんですが、とりあえずこれでもテストはできるでしょうという気持ちです。
しかし微妙に見づらいな。（本当に微妙か？）

成果物

※のついてるところはエラーメッセージがあるならテストするかっていうところ、グレーアウトしているところはテーブルを直接いじらないとやれなさそうなデータ。
そこまでテストするかどうかはその時のテスト分析とか……気持ちとか……そういうのに合わせると思います。
でも「バッチで◯時になったらアカウントロック外すわよ～！」とか仕様が追加されたらめんどくさいので最初から入れておきたい気持ちが強いです。

そして…………

ほかの人は絶対もっときれいな表書いてるんだろうし参考にしようかな……と思ったんですが案の定かいりさんの表がめちゃくちゃキレイで笑いました。
言葉も理路整然としてそうだよそれそれと思ってぎりぎりコピペを思いと留まりました。あぶないあぶない。
そもそも多分考えてることが天と地ほど違うので……

とりあえずわたしはまずExcelなりスプシなりのセルを結合するのをやめようか……（結論）