はじめに

こんにちは、Zaim で iOS チームのリーダーをしている @y_sumida です。

以前のエントリ、大規模サービス開発で起こりがちな「やり直し」が激減した私たちの仕様確認フロー #Zaim   では、Zaim でやり直しを減らすために整備した仕様確認の流れをご紹介しました。

流れの中に 真剣にレビューする というものがあったのですが、もう少し掘り下げて、開発する上で見逃しがちな「細かい仕様」をどう発見し、手戻り少なく実装しているかについて共有したいと思います。

一口に「細かい仕様」と言っても色々あります。例えばサービス開発の中でも、入力フォームに文字数制限をかけたり、金額によって数字の色を変えたりと、値に関する仕様は基本かつ複雑になりがちです。これらを曖昧なままにしておくと、仕様には沿っているものの、不思議なバリデーションや、ユーザーから見て矛盾したデザインのままリリースされてしまうことも少なくありません。

そうならないためにも、私は複雑な仕様を整理検討する際には、テスト技法を取り入れることにしています。

テスト技法とは何か

テスト技法は、ソフトウェアテストにおいて効果的なテストケースを抽出するための方法やテクニックです。ありとあらゆる事象をチェックすることは不可能ですが、効率よく不具合を発見するためにパターンを洗い出し、実行することで網羅性の高いテストを実行できるようになります。テストケースを抽出し期待結果を考える過程において、副次的に仕様の曖昧な点を発見しやすくなるメリットがあります。

今回は入出力値に関する代表的なテスト技法である「境界値分析」と「同値分割」について、それぞれ簡単にご紹介します。

なお、デザイナーやディレクターの方にも「開発者はこんなことを考えているんだよ」とイメージしてもらえるよう、いくつかの説明は簡略化しています。

テスト技法（１）境界値分析

仕様の境界値付近に着目してテストケースを作成する方法です。

境界値とは、仕様の上限値・下限値、および仕様が切り替わる境界付近の値、具体的には境界そのものの値とその両隣の値のことです。

例えば「文字数制限が 0 文字以上 100 文字以下」という仕様の場合は、

0 文字
1 文字
99 文字
100 文字
101 文字

が境界値です。

「入力可能文字数が残り 10 文字以下になったら文字を赤くする」という仕様がある場合は、89, 90, 91 も境界値になるでしょう。

テスト技法（２）同値分割

データを同値とそれ以外（異値）に分類してテストケースを作成する方法です。

同値とは、仕様的に同じ扱いをする「集合」のことです。集合なので、必ずしも連続値ではありません。そのため境界値が存在しないこともあります。

例えば、全角指定の入力フォームの場合、

全角文字（厳密には全角文字という定義も曖昧ですが）すべてが同値
それ以外の半角英数記号などが異値

となります。

これが小学生向けのアプリだったりすると、必ずしも全角文字すべてが同値というわけではないかもしれません。ひらがな、カタカナ、学齢による使用可能漢字あたりが同値になりそうです。

値に関して明確にしておくべき点

仕様に対して境界値分析と同値分割を実施していくと、以下のような値の仕様を明確にする必要があることに気づきます。

（１）種別

入出力する値の種別です。

例えば電話番号の仕様なら、0 から 9 までの数値とハイフン、場合によってはプラス記号が仕様になります。

また、全角文字とひとくくりにしてしまいがちですが、固いシステム開発だと「JIS 第 3 水準まで入力可能」などと決まっていることがあります。

半角/全角
数値
整数/実数
10 進数/16 進数（カラーコードなど）
アルファベット
大文字/小文字
記号
マルチバイト文字
ひらがな/カタカナ/漢字/記号/絵文字
JIS 水準
学齢による使用可能漢字
英語以外の外国語
住所
国/都道府県/市区町村

（２）範囲

どこからどこまで入出力可能かという仕様です。

最大値や最大桁で表示や挙動がおかしくなるバグは発生しやすいです。

最小値/最大値
最小桁/最大桁
小数部の有効桁
マイナス含む/含まない

（３）境界値

値の範囲のうち、仕様が切り替わる値付近の仕様が曖昧になりがちなのでよく検討しておく必要があります。

ここの検討が足りていないと、レアケースでおかしな表示や挙動をしがちです。

以上、以下、未満、超など、日本語だけだと曖昧になりがちなので数直線などを書いて確認するとよいでしょう。

得点によってランク分けする場合など、境界値が上限下限周辺以外にも存在するケースもあります。例えば 100 点満点で以下のようなルールにおける境界値は、このようになります。

79 点以下は C
80 点以上 89 点以下は B
90 点以上 99 点以下は A
100 点は S
↓
0,1,78,79,80,81,89,90,91,99,100

（４）精度

小数点以下の数値が発生する場合や時刻を扱う場合の処理などを決めておきます。「常識的に考えればこう」というものに引っ張られがちな項目ですが、決めておかないと思わぬ不具合が発生してしまいかねません。

例えばランキング、ソートなど値を比較するような機能では、精度の仕様を誤って解釈していると、意図した結果にならないことがあります。

整数 N 桁まで
小数点以下 N 桁まで
四捨五入/切り捨て/切り上げ
年月日時分秒ミリ秒ナノ秒

（５）表示形式

データの範囲や精度などの仕様がしっかり決まっていても、最終的に表示する形式の仕様が曖昧だと意図通りになりません。以下のようなケースを考慮しておく必要があります。

ゼロパディング
ゼロサプレス
小数部のゼロ表示
数値のカンマ区切り
マイナス表示
日付の書式
未入力時の表示
省略時の三点リーダー表示

まとめ

いかがでしたでしょうか？値の仕様を考える際には、境界値や同値を意識しつつ、曖昧なところがないかをチェックすることを、ぜひお試しください。この他にも、状態に着目した状態遷移表や組み合わせに着目したデシジョンテーブルなどは、仕様の整合性確認に非常に有効です。

そして、仕様としての整合性を確認する際は、あわせてデザインの整合性も見直しましょう！開発者だけでなくディレクター、デザイナーなど仕様作りに関わる人が整合性を意識するだけで手戻りはかなり減るはずです。

細かいテスト大好き！そんなあなたと会ってお話したいです。