境界値テスト、どうやって運用していく。

ライフイズテックのサービス開発部でQAを担当しているotkyskです。

QAとして弊社が提供している塾プロダクト、学校プロダクトを高い品質にして提供するよう日々努めています。

前回は職歴・経歴をやや雑に書かせていただきましたが、今回はテストの１つについて、個人的な見解を述べたいと考えています。

境界値テストについて

境界値テストですが、テストの一般的な手法であり、具体例で言うと、氏名の入力フォームがUIにあったとして、何文字以上入力可能か？何文字まで入力可能か？といった仕様が定義された上で実装されたフォーム欄に対して、仕様を満たしているか？仕様範囲外の挙動はどうなるか？を検証する事です。

当然ながら仕様を満たせば入力内容をPOSTする事が出来る（期待値を満たす）が、仕様を満たさない入力内容をPOSTすると、エラーが出て不快になると考えられます。

その境界値テストですが、オーナーが誰か？で稀に議論が走るんですよね。。。
開発の単体テストで担保すべき！QAのシナリオテストで担保すべき！と。責任領域について議論したりもします。
ただ、ここで、考えられるのは、そもそもの境界値テストをやる前にどんなユーザビリティで仕様検討されたか？

ユーザビリティをまず先に置くべし

入力無制限のフリーフォームで文字数制限をかける
→これ、怖いです。実装コスト、テストコスト上がります。

入力制限が文字数制限に従って、文字数制限を超えるとアラートを出す。
→弊社の仕様ですが、実装コスト、テストコストは低いと考えられます。

そもそも文字数制限に合わせて入力制限を固定させる。
→あまり見たこと無い仕様で、実装コストが高いと考えられます。

結果論、エラーハンドリング、アラート通知、送信成功できればどんな仕様でも構いませんけれど、使い勝手を考えると、送信前に「文字数超えてますよ！」とアラート出してあげるのが優しいと考えられます。

ですので、要件定義できっちり仕様を策定して、開発だろうがQAだろうが、どちらでテストして、安定した状態に持っていけば良いのです。どちらがやる、やらを議論している暇があるならスピードを重視しなければなりません。

あと、開発素人目でもう１点、補足を加えると、この境界値テストというのは何度もやる必要あるか？という点ですが、個人的には無いと考えてます。

例えば、氏名を入力するにあたって５０文字の制限があるとしたら最初のテストで５０文字の境界値を検証しておけばOK。氏名に５０文字も入れるユーザーがいるとするなら、イタズラか外国人くらいでしょう。
それに、境界値を一度定義してしまえば、そこはif文が揺るがない限り、ロジックとしては固定される訳で、固定される以上、テストは不要だと考えてます。例外があるならソフトウェアが使っているモジュールが更新されたくらいでしょう。

最後に

以上が今回の記事です。また長くなってしまったな、と少し反省しながらも継続して投稿していきます。

ライフイズテック サービス開発部では、今後定期的なカジュアルなイベントを実施しています。
開催予定イベントの詳細はライフイズテックのconnpassからご確認ください。

Life is Tech！ライフイズテック

興味のあるイベントがあったらぜひ参加登録をお願いいたします！