Kevin, yes. I just threw “Performance test” in there as a buzzword bingo. I’m like that, a bonus one “Security Testing”?
But I’m keen to work out a way to do what Ernie was hinting at, not get distracted writing code to inject random field contents and then validate. Because not only must you handle text fields, but you really want to handle tickboxes and radio buttons in those forms too, since they really are part of the data and state. This gets complicated quite quickly I guess though. There is merit in random input testing, but it’s not as valuable as a happy-path table-driven test suite that just happens to have a CSV file of inputs that contain “Robert’); DROP TABLE students;–');”
(disclaimer : other good attack example files do exist Good input datasets ) If you are not familiar with table driven testing for input validation, you have not used a GUI automation tool yet. The good tools all support CSV or tables, of input datas; but I’ve never found off-the-shelf GUI tools to work well in all contexts. One thing that table driven testing frameworks let you do is specify a column in the table that defines the outcome:
field1,field2,field3,ACCEPTED
Harry,Oppenheimer,0551234567,PASS
Harry,Oppenheimer,055-123-4567,FAIL
Harry,“Robert’); DROP TABLE students;–');”,0551234567,FAIL
Everyone has started testing an app only to find that there is just one form somewhere that always fails to save a single field hidden at the bottom of the form on the first submit of the form. Nobody ever reports it because it saves on the second time you click OK, but it’s still, a defect! And I guess that’s one of the class of bug you hope to catch this way.
I’d really like for other club members to chip in at this point with heuristics for form input validation testing.