実は、異常操作への対応(端的に言えば、イタズラ対策)だったりします。
電話番号を入力する欄が有ったとして、
そこに英数字を入れるとどうなるか？
漢字を入れるとどうなるか？とか。
10文字の枠に、12文字入れるとどうなるか？とか。
それくらい対応しとけよ。と言われればその通りです。
しかし作っているのは人間。いつか間違えます。
人間なんて、ただの炭素生物。シリコンウエハーには叶いません。
いや、だって、神経細胞って、信号をアッチからコッチに流すだけですよ？
そのルールがどうやって決まってるのか、未だに判ってない。
アナログの極致です。間違えて当たり前。
そこでテストせざるを得ないわけですが。
入力項目やら入力画面やらが増えてくると、
馬鹿正直にやれば、その組み合わせは天文学的になり兼ねません。
しかしテストするのも人間なので、テスト自体が間違ってました、
なんてメタな問題もあったりとか。もう何が何だかね。
結論として、馬鹿正直にテストする工数も含めるなら、
制作費に含めて、「お見積もり」せざるを得ません。
しかし、このご時世。そうも行きません。
高い、と言われるでしょう。
何で「高い」と言われるのかというと、
自前のスタッフで作ったらどうなるか、という工数感があるからで、
そりゃ自前で作るんなら、バグってもゴメンなさいで済みますから。
でも受注開発ではそうはいかないでしょう。
バグらないのが、責任ですからね。
じゃあ、バグっても
「ゴメンなさい」で済ませてもらえるなら、安くできるのか？
YESです。
#直しません。と言ってるわけじゃないです。
#「バグだらけ」でもキレないでくださいね。と言っています。
「テストは余りやらずに提供しちゃいます」と言いきっちゃう。
テストの工数は大幅に減らせます。
もちろんそれだけじゃ済まないので、
クライアントもしくは中請けがテストしてくれる事が前提ですが。
手動テストは諦めて、自動化するのも手です。
webベースの案件であれば、Seleniumシリーズがいい感じです。
ただこれでも、
すべてのパターンを網羅するのは、依然として手間なので、
「直したと思ったら別の場所がバグった」、みたいな恥ずかしい問題を、
早期発見するためだと思った方が良いでしょう。
結論として、
案件としても、トラブっても一大事にならないような、
要件に落とし込まざるをえません。例えば、金勘定は勘弁。
ただし、金勘定案件は、経営上の都合やら、
色々な要因に振り回されまくるので、
CSVでエクスポートして、エクセルで何とかした方が便利でした、
というオチもあったりします。
発注側としては、中々納得しにくい点だと思いますが、
そういうものです。
