はじめに
Web系SaaSシステムエンジニアのKyukiです。
みなさんは、テスト仕様書を書いたことはありますか？
今回は、日々の業務の中で実際に経験したテストに関わるアンチパターンを紹介し、皆様のデバックライフに気づきを与えられればと思います。
あなたにとっての「正常」は何？
「正常に処理が終了する」
だとか
「正常な文言が表示される」
だとか。
そういったワードが期待結果として記載されているテスト仕様書を見た事がありませんか？
では、「正常」って何なのでしょうか？
辞書を引くと「普通、正しいとされる状態にあること。」といった説明があります。
なるほど！「普通」の状態。「正しい」状態という事なんだな！
とは、納得できないですよね。
具体的・明示的に、『何』が、『どうなれば』期待した結果となるのか、記載するようにしましょう。
例えば、「エラーが発生せず処理が終わる」とか「エラーが起こってもエラー画面に遷移する」とかそういった書き方になっていれば、誰が実施しても同じ結果が得られますよね。
「エラー」と言ってもエラー毎に処理が変わるのであれば、それぞれのエラー毎に記載すべきですが...。
A～zは本当に26個ですか？
項目を列挙する時、一つ一つ記載するのは面倒だと感じる方もいるでしょう。
「ABCDEFGHIJKLMNOPQRSTUVWXYZ」と書かなければならないところ「A～Z」と省略してしまう事も多いのではないでしょうか？
ですが、テスト仕様書において省略は危険です。
「A~Z」と書いていてあっても、書き出してみると「AXYZ」かもしれません。
私達はアルファベットが26字だと思っていますが、27文字だと思っている人もいるかもしれないですよね？
例はアルファベットなので、ググれば分かりますが、
実際は「ユーザーID、パスワード、登録日、登録者」の順番に表記されることを確認しなければならないケースだったりする事でしょう。
そんな時、『「ユーザーID～登録者」が表示される。』などといった期待結果が記載されていたら、果たしてそのテストで品質は保証できますか？
最後に
普通、当然、そんな思い込みが、バグを埋め込む原因となります。
テストではそれを検知する為に当たり前を再点検し、明文化する事が重要です。
是非、今回挙げた例以外にも、思い当たる節があれば改善していってくださいね。